Controller Area Network (CAN BUS)-Protocol (2023)

Index

1. Introduction: The CAN bus
2. CAN messages
3. CAN physical layer
4. CAN oscilloscope images
5. CAN connections
6. CAN-Bit-Sync
7. CAN error handling
8. upper layer records

To get into the details of CAN, the CAN bus is a type of transmission bus. This means that all nodes can "hear" all transmissions. There is no way to send a message only to a specific node; all nodes without exception will absorb all the traffic. However, the CAN hardware provides local filtering, so each node can only respond to messages of interest. We will discuss this later inSection 2, "CAN Messages".

We will also discuss how the bus uses Non-Return To Zero (NRZ) with bit padding. In this system, the modules are connected to the bus in an interconnected way: if only one node drives the bus to a logic 0, the entire bus will be in this state, regardless of the number of nodes transmitting a logic 1.

The CAN standard defines four different types of messages. The messages use a bitwise intelligent arbitration scheme to control access to the bus, and each message is assigned a priority.

The CAN standard also defines a sophisticated error handling and containment scheme, which is detailed inSection 7, “CAN Error Handling”.

Bit timing and clock synchronization are discussed inSection 6this walkthrough. Here's onebit time calculatorcan calculate CAN bus parameters and record configuration.

CAN bus wiring can be implemented through different physical layers (Section 3), some of which are described here, and there are also a variety of types of CAN bus connectors (Section 5) In use. We also provide several oscilloscope images (Section 4) for those interested in the details of a message.

The CAN bus is a type of transmission bus. This means that all nodes can "hear" all transmissions. There is no way to send a message only to a specific node; all nodes without exception will absorb all the traffic. However, the CAN hardware provides local filtering, so each node can only respond to messages of interest.

CAN messages
CAN uses short messages: the maximum payload is 94 bits. There is no explicit address in the messages; Instead, messages can be said to be content-addressed, which means that their content implicitly determines their address.

types of messages
There are four different types of messages (or "frames") on a CAN bus:

1. the data frame
2. the far frame
3. the error frame
4. the upper frame

Summary: "Hello everyone, here is some data labeled with X, I hope you like it!"

The data frame is the most common type of message. It consists of the following main parts (some details omitted for brevity):

• the arbitration field, which determines the priority of the message when two or more nodes dispute the bus. The arbitration panel includes:
  • For CAN 2.0A, an 11-bit, one-bit identifier, the RTR bit, which is dominant for data frames.
  • For CAN 2.0B, a 29-bit identifier (also including two recessive bits: SRR and IDE) and the RTR bit.
• o Data field that contains zero to eight bytes of data.
• the CRC field, which contains a 15-bit checksum calculated over the bulk of the message. This checksum is used for error detection.
• an acknowledgment slot; Each CAN controller that has received the message correctly sends an acknowledgment bit at the end of each message. The sender checks for the presence of the acknowledgment bit and resends the message if no acknowledgment is detected.

Note 1: It is worth noting that the presence of an acknowledgment bit on the bus does not mean that none of the intended recipients received the message. We only know that one or more bus nodes received it correctly.

Note 2: The identifier in the arbitration field, despite its name, is not necessarily an identifier of the message content.

Summary: "Hello everyone, can someone show the dates marked with X?"

The remote frame is the same as the data frame with two important differences:

• is explicitly marked as a remote frame (RTR bit in arbitration field is recessive) and
• There is no data field.

The intended purpose of the remote frame is to request the transmission of the corresponding data frame. For example, if Node A transmits a remote frame with the arbitration field set to 234, Node B, if initialized correctly, can respond with a data frame that also has the arbitration field set to 234.

Summary: (everyone, loudly) "OH LOVE, LET'S TRY AGAIN"

Simply put, the error frame is a special message that violates the framing rules of a CAN message. It is transmitted when a node detects an error and causes all other nodes to detect an error, so they also send error frames. The sender automatically attempts to resend the message. There is a sophisticated error counting scheme that ensures that a node cannot destroy bus traffic by repeatedly sending error frames.

Summary: "I'm a very busy little 82526, could you wait a minute?"

The previous framework is only mentioned here for completeness. It is very similar in format to the error frame and is transmitted by a heavily loaded node. The top board is not used very often because today's CAN controllers are smart enough not to use it. In fact, the only driver that generates Overload Frames is the now deprecated 82526.

The CAN standard originally defined the length of the identifier in the arbitration field as eleven (11) bits. Later, customer demand forced an extension of the standard. The new format is often referred to as Extended CAN and allows no fewer than twenty-nine (29) bits in the identifier. A reserved bit in the control field was used to distinguish between the two frame types.

The patterns are formally called

• 2.0A, only with 11-bit identifiers,
• 2.0B, improved version with full 29-bit (or 11-bit, you can mix them) identifiers. A 2.0B node can be
  • "Active 2.0B", that is, it can send and receive extended frames, or
  • "Passive 2.0B", i. h Incoming extended frames are silently discarded (see below).
• 1.x refers to the original specification and its revisions.

The current new CAN controllers are mostly of the 2.0B type. A driver of type 1.x or 2.0A gets very upset if it receives messages with 29 arbitration bits. A 2.0B passive driver tolerates them, acknowledges them if they are correct, and then discards them; an active 2.0B controller can send and receive them.

Drivers implementing 2.0B and 2.0A (and 1.x) are compatible, and can be used on the same bus, as long as drivers implementing 2.0B refrain from sending extended frames!

It is sometimes argued that Standard CAN is "better" than Extended CAN because Extended CAN messages have more overhead. This is not necessarily true. If you use the arbitration field to transfer data, Extended CAN may actually have less overhead than Standard CAN.

The terms "basic CAN" and "full CAN" come from the infancy of CAN. Once upon a time, the Intel 82526 CAN controller provided a DPRAM-style interface to the programmer. Then came Philips with the 82C200, which used a FIFO (queue) oriented programming model and limited filtering capabilities. To differentiate between the two programming models, the Intel mode was named "Full CAN" and the Philips mode "Basic CAN" for some reason. Today, most CAN controllers allow both programming models, so there is no reason to use the terms "full CAN" and "basic CAN"; these terms can even be confusing and should be avoided.

Obviously, a "Full CAN" controller can communicate with a "Basic CAN" controller and vice versa. There are no compatibility issues.

Message arbitration (the process by which two or more CAN controllers agree who should use the bus) is of great importance to the actual bandwidth available for data transmission.

Each CAN controller can initiate a transmission when it detects a free bus. This can lead to two or more controllers triggering a message (almost) simultaneously. The conflict is resolved as follows. The transmitting nodes monitor the bus while transmitting. If a node, while sending a recessive level, detects a dominant level, it immediately exits the arbitration process and becomes a receiver. Arbitration is performed over the entire arbitration field, and when this field is sent, exactly one sender remains on the bus. This node continues to transmit as if nothing had happened. The other potential senders will try to retransmit your messages the next time the bus is available. No time is wasted in the arbitration process.

An important condition for the success of this bitwise arbitration is that two nodes cannot transmit the same arbitration field. There is an exception to this rule: if the message does not contain any data, any node can transmit this message.

Since the bus is wired and a dominant bit is a logic 0, it follows that the message with the numerically lowest arbitration field wins the arbitration.

Q: What happens if a node is alone on the bus and tries to transmit?
A: Of course, the node will win the arbitration and will happily proceed with the transmission of the message. But when it's time to acknowledge... no node sends a dominant bit during the ACK slot, so the sender detects an ACK error, sends an error flag, increments its transmit error counter by 8, and starts retransmitting . This will happen 16 times; then the transmitter goes into a passive error. Due to a special rule in the error isolation algorithm, the transmission error counter is not incremented when the node is error passive and the error is an ACK error. So the node keeps sending forever, at least until someone acknowledges the message.

It should be noted again that there is no explicit address in CAN messages. Each CAN controller listens to all traffic on the bus and uses a combination of hardware and software filters to determine if the message is "interesting" or not.

In fact, CAN has no notion of message addresses. Instead, the content of the message is identified by an identifier present somewhere in the message. CAN messages are called "content-directed".

A conventional message address such as "Here is a message for node X" would be used. A content-addressed message is like "Here is a message containing data marked with an X." The difference between these two concepts is small but significant.

The content of the arbitration field is used according to the standard to determine the priority of the message on the bus. All CAN controllers also use the entire arbitration field (some use only a part) as a key in the hardware filtering process.

The standard does not say that the arbitration field should be used as a message identifier. However, it is a very common usage.

We said that 11 (CAN 2.0A) or 29 (CAN 2.0B) bits are available in the identifier. That is not entirely correct. Due to compatibility with a specific older CAN controller (guess which one?), the identifiers do not need to have all 7 most significant bits set, leaving only identifiers 0..2031 for 11-bit identifiers and 29-bit users. . Bit identifiers can use 532676608 different values.

Note that all other CAN controllers accept the "illegal" identifiers, so the identifiers 2032..2047 can be used without restriction in a modern CAN system.

A physical layer defines the electrical levels and signaling scheme on the bus, the impedance of the cable, and the like.

There are different physical layers:

• The most common type is defined by the CAN standard, part ISO 11898-2, and is a balanced two-wire signaling scheme. It is also sometimes referred to as "high speed CAN".
• Another part of the same ISO standard, ISO 11898-3, defines another balanced two-wire signaling scheme for lower bus speeds. It is fault tolerant so signaling can continue even if a bus wire is cut or shorted to ground or Vbat. Sometimes referred to as "Low Speed ​​CAN".
• SAE J2411 defines a single wire physical layer (plus ground of course). It is mainly used in cars, e.g. LAN GM.
• There are several proprietary physical layers.
• RS485 modifications were used in the old days, before CAN controllers existed.
• On page 6 there are several oscilloscope images for those interested in the details of a message.

Usually, the different physical layers cannot work together. Some combinations may work or appear to work under good conditions. For example, using "high speed" and "low speed" transceivers on the same bus can work...sometimes.

NXP makes many CAN transceiver chips; Alternative vendors are Bosch, Infineon, Texas Instruments, and Vishay Siliconix.

A very common type is the 82C250 transceiver, which implements the physical layer defined by ISO 11898. The 82C251 is an improved version.

A common transceiver for "Low Speed ​​CAN" is NXP's TJA1054.

According to the standard, the maximum speed of a CAN bus is 1 Mbit/second. However, some CAN controllers support speeds greater than 1 Mbit/s and may be considered for special applications.

Low speed CAN (ISO 11898-3, see above) can reach up to 125 kbit/s.

Single-wire CAN can reach up to around 50 kbit/s in standard mode and up to around 100 kbit/s with a special high-speed mode used for example for ECU programming.

At a speed of 1 Mbit/s, a maximum cable length of approximately 40 meters (130 feet) can be used. This is because the arbitration scheme requires that the signal wavefront be allowed to propagate to the furthest node and back before the bit is sampled. In other words, the length of the wire is limited by the speed of light. A proposal to increase the speed of light was considered but rejected due to its intergalactic implications.

Other maximum cable lengths are (these values ​​are approximate):

• 100 metros (330 pies) a 500 kbps
• 200 metros (650 pies) a 250 kbps
• 500 metros (1600 pies) a 125 kbps
• 6 kilometers (20,000 feet) at 10 kbps

When optocouplers are used for galvanic isolation, the maximum bus length is reduced accordingly. Tip: Use fast optocouplers and watch the delay at the device, not at the specified maximum bitrate.

An ISO 11898 CAN bus must be terminated. This is done with a 120 ohm resistor at each end of the bus. Termination has two purposes:

1. Eliminate signal reflections at the end of the bus.
2. Make sure the bus is getting the correct DC levels.

An ISO 11898 CAN bus must always be terminated, regardless of its speed. I'll say it again: an ISO 11898 CAN bus must always be terminated, regardless of its speed. For laboratory work, a single terminator may suffice. If your CAN bus works even though it doesn't have terminators, you're in luck.

Note that other physical layers such as "Low Speed ​​CAN", Single Wire CAN, and others may or may not require termination. However, your high speed ISO 11898 CAN bus always needs at least one terminating resistor.

learn more aboutCANbus termination in this article.

ISO 11898 requires the cable impedance to be nominally 120 ohms, but impedance in the range of [108..132] ohms is acceptable.

There are not many cables on the market today that meet this requirement. There is a good chance that the allowable impedance range will be widened in the future.

ISO 11898 is defined for unshielded or shielded twisted pair cables. The SAE J2411 single-wire standard is currently being worked on.

There is no standard for CAN bus connectors! Typically, each higher layer protocol (!) defines one or a few preferred types of CAN bus ports. Common types include

• 9-pin DSUB proposed by CiA.
• 5-pin Mini-C and/or Micro-C used by DeviceNet and SDS.
• German 6-pin connector proposed by CANHUG for mobile hydraulics. See page 7 for some different pin assignments.

1. First, the transmitter sends a start bit. This is a logical '0', that is, a dominant level.
2. The identifier is then passed. 300 decimal is 12c in hexadecimal or 001 0010 1100 in binary. The first two zeros are transmitted correctly. This explains the dominant level of 24 microseconds as seen in the figure.
3. A '1' should then be transmitted, but since the bus is not terminated, the rising edge is not what it should be. The sending node nowthinkI saw a 0 on the bus.
4. Since this happens during the arbitration phase, the sender stops sending; thinks another node is sending. The bus is now going recessive because no one is actually broadcasting.
5. After 6 recessive bits, the sender and receiver recognize amaterial defectand error handling begins. At this point, 80 microseconds have elapsed (one start bit, two zeroes, one misinterpreted bit, and six recessive bits, a total of 10 bits = 80 microseconds).
6. All nodes that detect the material error now start to transmit an error telegram. In this case, the error framepassivebecause several errors were generated before the above picture was taken, so the transmitterpassive error. A passive error frame is like an active error frame, but it is transmitted with a recessive level and is therefore not visible on the bus.
7. The passive error frame prevails for 6 bits.
8. Then all nodes wait for a period of 8 recessive bits callederror limiter.
9. Then all nodes wait for a period of 3 recessive bits calledrest.
10. Adding the above numbers, we get 1+6+6+8+3 = 24 recessive bits = 192 microseconds (see figure!).

Moral of the story: Always terminate the CAN bus!Reflections won't necessarily hurt, but malformed edges will destroy communications.

What happen?

1. As in the previous figure, three zeros are transmitted (takes 24 microseconds) and the next bit is misinterpreted, causing the sender to think it has lost the decision.
2. The transmitter waits 6 bits and then acknowledges a hardware error. The misinterpreted bit and the 6 bits take 56 microseconds.
3. The sender and receiver now start transmitting an error frame. There are 6 dominant bits (48 microseconds).
4. The nodes that sent the error frame now expect 8 recessive bits, but because the slope is bad, the first bit is misinterpreted. The nodes will think that this is another node sending an error frame and will ignore it.
5. When the bus returns to the recessive level, all nodes wait for 8 bits.
6. Then comes the 3-bit recessive gap.
7. 3+9 = 12 bits = 96 microseconds as shown in the figure.
8. The sender then tries again with the same result. After some time, the transmitter goes into passive error and behaves as described above.

So what happens?

1. First, the sender sends the entire message.
2. The sender expects a dominant level in the ACK slot, but since no one is listening, no ACK arrives, so the sender detects an acknowledgment error.
3. The sender then sends a passive error flag (passive because in the image above it has been trying to send for a few seconds, so it is no longer an active error).
4. The passive error flag is followed by an error delimiter and the range.
5. Because this node tried to send a message but failed, it must wait another 8 bits before starting a new transmission. This is called "Suspend Transmission" in the CAN specification.
6. The sending node must also increment its tx error counter by 8, but due to a special case in the CAN specification, this only happens while the sender is error active. If the sender becomes error passive, it will (in this case) not increment its transmission error counter and therefore the transmission will be repeated indefinitely.

used by bothdevice networkmiSDBand becomes compatible between these two protocols.

The modules have plugs. The supplied power is 24 V +- 1%.

Note: In version 1.x of the DeviceNet specification, the socket is numbered in the wrong order in Figure 9.13. Spec 2.0 and later got it right.

Recommended by CANHUG for use in mobile hydraulic applications.

Connector side module, female bus side. There is currently no recommendation for delivered performance.

The synchronization segment, which always has a quantum length, is used for clock synchronization. Here a bit of edge is expected when the data on the bus changes.

The spread segment is necessary to compensate for the delay on the bus lines.

To adapt the bus clock on the chip, the CAN controller can shorten or lengthen the length of a bit by an integer number of quanta. The maximum value of these bit timing adjustments is called the sync hop width, SJW.

hard syncoccurs at the recessive-dominant transition of the start bit. The bit time is reset from this edge.

neusynchronizationoccurs when a bit edge does not occur within the synchronization segment in a message. One of the phase sections is shortened or lengthened by an amount that depends on the phase error in the signal; The maximum amount that can be used is determined by the Sync Leap Width parameter.

Most CAN controllers allow the programmer to set the bit time with the following parameters:

• A clock prescaler value
• The number of quanta before the sampling point.
• The number of quanta after the sampling point
• The quantity number inSync Jump Distance, SJW

Two registers are usually provided for this purpose: btr0 and btr1. However, things vary a bit between different controllers, so read the datasheets carefully.

On the 82c200 and SJA1000, both from NXP (formerly Philips), the register layout looks like this:

• BRP0..BRP5 sets the value of the clock prescaler
• SJW0..SJW1 defines the length of the SJW
• TSEG10..TSEG13 defines the number of quanta before the sample point (the start bit is not included)
• TSEG20..TSEG22 defines the number of quanta after the sample point.
• SAM is set to 1 if three samples are taken and to 0 if one sample is enough.

Note: The actual value of these parameters is one higher than the value written to the registry.

Example: If the oscillator signal fed to the SJA1000 is 16MHz and we want a bitrate of 250kbps with a sampling point close to 62% of the total bit and an SJW of 2 quanta, we can define:

BRP = 4, giving a quantum length of 2 * 4/16000000 s = 500 ns, and
TSEG1 = 5, giving 5 quanta before the sample point, and
TSEG2 = 3, giving 3 quanta after the sample point.

• BRP0..BRP5 sets the value of the clock prescaler
• SJW0..SJW1 defines the length of the SJW
• TSEG10..TSEG13 defines the number of quanta before the sample point (the start bit is not included)
• TSEG20..TSEG22 defines the number of quanta after the sample point.
• SAM is set to 1 if three samples are taken and to 0 if one sample is enough.

Note: The actual value of these parameters is one higher than the value written to the registry.

Example: If the oscillator signal fed to the SJA1000 is 16MHz and we want a bitrate of 250kbps with a sampling point close to 62% of the total bit and an SJW of 2 quanta, we can define:

BRP = 4, giving a quantum length of 2 * 4/16000000 s = 500 ns, and
TSEG1 = 5, giving 5 quanta before the sample point, and
TSEG2 = 3, giving 3 quanta after the sample point.

So each bit consists of 5 + 3 = 8 quanta, giving the desired bit rate of 1/(8 * 500 ns) = 250 kbit/s. The registry values ​​should be as shown in the example here.

The sampling point is at 5/8 = 62.5% of a bit.

Error handling is built into the CAN protocol and is of great importance to the performance of a CAN system. Error handling is intended to detect errors in messages appearing on the CAN bus so that the sender can resend an incorrect message. Each CAN controller along a bus attempts to detect errors within a message. If an error is found, the discovery node sends an error indicator, which destroys the traffic on the bus. The other nodes detect the error caused by the error flag (if they have not yet detected the original error) and take appropriate action, ie they discard the current message.

Each node maintains two error counters: the transmit error counter and the receive error counter. There are several rules that determine how these counters are incremented and/or decremented. Essentially, a sender that detects an error increments its transmit error counter faster than listening nodes increment their receive error counter. This is because there is a good chance that the sender is to blame! If an error counter exceeds a certain value, the node first becomes "error passive", ie. h he does not actively destroy bus traffic when an error is detected, and then "turns off the bus", which means that the node does not participate in bus traffic.

With the help of error counters, a CAN node can not only detect errors, but also carry out error containment.

The CAN protocol defines no less than five different types of error detection. Two of them work at the bit level and the other three at the message level.

1. bit monitoring.
2. beak filler
3. frame control
4. recognition test
5. Cyclic redundancy check.

bit monitoring
Each transmitter on the CAN bus monitors (ie reads back) the level of the signal being sent. If the bit level actually read differs from that transmitted, a bit error is signaled. (No bit errors are generated during the arbitration process.)

stuffing pieces
When a node transmits five consecutive bits of the same level, it adds a sixth bit of the opposite level to the output bit stream. Receivers remove this extra bit. This serves to avoid excessive DC components on the bus, but also gives receivers an additional opportunity to detect errors: if more than five consecutive bits with the same level occur on the bus, a material error is indicated.

frame check
Some parts of the CAN message have a fixed format, i. h standard defines exactly which levels should occur and when. (These parts are the CRC delimiter, the ACK delimiter, the end of the frame, and also the interval, but there are some special error-checking rules for that.) If a CAN controller detects an invalid value in one of these fixed fields, a Der Error form is flagged.

recognition test
All bus participants who successfully receive a message (regardless of whether they are "interested" in its content or not) are expected to send a dominant level in the so-called acknowledgment space in the message. The transmitter sends a recessive level here. If the sender does not detect a dominant level in the ACK slot, an acknowledgment error is reported.

Cyclic Redundancy Check
Each message has a 15-bit CRC (Cyclic Redundancy Checksum), and any node that sees a different CRC in the message than the one it computed signals aerror CRC.

Any CAN controller on a bus will try to detect the errors described above in each message. If an error is found, the discovery node sends an error indicator, which destroys the traffic on the bus. The other nodes detect the error caused by the error flag (if they have not yet detected the original error) and take appropriate action, ie they discard the current message.

Each node maintains two error counters: the transmit error counter and the receive error counter. There are several rules that determine how these counters are incremented and/or decremented. Essentially, a sender that detects an error increments its transmit error counter faster than listening nodes increment their receive error counter. This is because there is a good chance that the sender is to blame!

A node starts in Active Error mode. If any of the error counters goes above 127, the node goes into a state known as passive error, and if the transmit error counter goes above 255, the node goes into the bus-off state.

• An active error node sends active error indicators when it detects errors.
• A passive error node transmits passive error indicators when it detects errors.
• A node whose bus is idle will not transmit anything on the bus.

The rules for incrementing and decrementing the error counters are a bit complex, but the principle is simple: transmit errors result in 8 error points and receive errors result in 1 error point. Messages sent and/or received correctly will cause the counters to decrease.

Example (slightly simplified): Let's say node A on a bus is having a bad day. Every time A tries to transmit a message, it fails (for whatever reason). Each time this happens, it increments its transmit error counter by 8 and sends an active error flag. Then it will try to resend the message... and the same thing happens.

When the transmission error count increases above 127 (ie, after 16 attempts), Node A becomes error passive. The difference is that passive error flags are now transmitted on the bus. A passive error flag has 6 recessive bits and will not destroy traffic on another bus, so the other nodes will not hear A complaining about bus errors. However, A continues to increment its transmission error counter. Eventually, if it rises above 255, node A gives in and gets off the bus.

What do other nodes think of node A? – For each active error flag sent by A, the other nodes increment their receive error counters by 1. When A closes the bus, the other nodes have a count in their receive error counters well below the error threshold passive, ie h 127. This counter is decremented by one for each successfully received message. However, node A will have closed the bus.

Most CAN controllers provide status bits (and corresponding interrupts) for two states:

• "Error Warning": One or both error counters are above 96
• Bus Off as described above.

Some, but not all! – The controllers also provide a bit for passive error status. Some drivers also provide direct access to error counters.

The CAN controller's habit of automatically resending messages when errors occur can be annoying at times. There is at least one controller on the market (the Philips SJA1000) that allows full manual control of error handling.

The ISO 11898 standard lists several failure modes for CAN bus cables:

1. CAN_H stopped
2. CAN_L interrupted
3. CAN_H shorted to battery voltage
4. CAN_L shorted to ground
5. CAN_H shorted to ground
6. CAN_L shorted to battery voltage
7. CAN_L shorted to CAN_H wire
8. CAN_H and CAN_L have stopped at the same place
9. Loss of connection to the terminating network

For failures 1-6 and 9, it is "recommended" that the bus survive with reduced S/N, and in the case of failure 8, that the resulting subsystem survive. It is "optional" for bug 7 to survive with a reduced S/N ratio.

In practice, a CAN system using 82C250 transceivers will not survive faults 1 through 7 and may or may not survive faults 8 through 9.

There are "fault tolerant" controllers like the TJA1053 that can handle any fault. Normally, this error tolerance is paid for with a limited maximum speed; with the TJA1053 it is 125 kbit/s.

The CAN standard defines hardware ("the physical layer", there are several) and communication at a basic level ("the data link layer"). The CAN protocol itself only defines how small data packets are transported from point A to point B over a common communication medium. But to manage communications within a system, a Higher Layer Protocol (HLP) is needed.

Higher layer protocols include common standards like J1939, CANopen, CCP/XCP, and more.