The Controller Area Networks bus standards describe a two-wire, serial, multi-master, synchronized (but clockless), broadcast-only system designed for vehicles. CAN is one of the mandated transports for ODB-II on-board diagnostics, and is required in all US vehicles since 2008. CAN distance decreases with bit rate, but at low rates can run to the kilometers.
- CAN-1 (1986): Original Bosch protocol
- CAN-2.0 (1991): Bosch update, later standardized by ISO 11519 (1993)
- CAN-2.0A (ISO 11898-3, 2006): 11-bit identifiers, up to 125Kbit/s, up to 32 nodes (CAN-Lo, "Basic CAN", "Reliable CAN"). Star/linear bus.
- CAN-2.0B (ISO 11898-2, 2003): 29-bit identifiers, up to 1Mbit/s, up to 110 nodes (CAN-High, "Full CAN"). Linear bus, 120Ω at each end.
- CAN-FD (ISO 11898-2, 2015): Extension to CAN-2.0B for up to 64B messages + better CRC + 12Mbit/s
- ISO 11898-1: Data link layer common to CAN-2.0A and B
- ISO 15765-2 (2016): "Road vehicles: Diagnostic communication over CAN" ISO-TP L3/L4 for larger (up to 4095B) packets, 15Mbit/s
- ISO 11783 (2017): "ISOBUS" at 250Kbit/s, 4-wire terminating plug-and-play bias circuits (power, ground, CAN), 30 node max
The mechanical connector is not mandated by any CAN standard, and proprietary ones are regularly used. External interfaces will often provide e.g. DE-9 (female on the bus, male on the ECU).
The various nodes of a CAN are known as ECUs (Electronic Control Units). Each can be assumed to include a microprocessor, a (possibly integrated) ISO 11898-1 CAN controller, and a ISO 11898-2/3 transceiver ("medium access unit"). Each ECU must have its own ID unique among the nodes. Depending on the flavor of CAN, IDs are either 11 or 29 bits. Choice of transceivers to a large degree define the network. Some examples:
- PCA82C250 -- 1Mbit, unlikely to handle most ISO 11898-1 cable error modes
- PCA82C252/TJA1054A -- 125Kbit, highly tolerant of 11898 cable fault modes, very low EM emissions, single-wire capability
Lower IDs have priority over higher IDs, and form the 11-bit "Arbitration Field" in a CAN frame (there are 2 such fields in an Extended Frame, one of 11 and one of 18 bits, separated by two bits). While transmitting a message, each ECU must also listen. If it sees a 0 while sending a 1, it must cease to transmit until the current message ends. Logical 0 is the "dominant" signal:
- If multiple ECUs are transmitting at the same cycle, all must transmit recessive, or everyone will see dominant
- Transition to dominant is slower than transition from dominant
- Synchronization begins on the first recessive to dominant transition after an "interframe space" (3 consecutive recessive bits)
- This dominant signal is considered the "start bit" of frame
- Resynchronization occurs on each subsequent recessive to dominant transition
A frame begins with a transition from recessive to dominant, the "start bit". It is followed by:
- 11-bit base identifier, common to CAN-2.0A and B.
- All transmitting ECUs must be listening during this field, and MUST cease transmitting if preempted by a dominant signal
- RTR bit. Remote Transmission Requests (recessive) expect a response.
- Much more common are Data Frames (dominant), which carry payloads and expect no response
- Note that Data Frames will win arbitration against Remote Frames having the same ID
- If the subsequent Identifier Extension Bit is recessive, indicating 29-bit identifiers, this bit MUST be recessive, and the true RTR follows the extended identifier
- In this case, this bit is known as the "Substitute Remote Request" (SRR) bit
- IDE bit. Identifier Extension. Recessive if and only if an 18-bit extended identifier is to be provided, in which case:
- 18-bit extended identifier, combining to make a 29-bit arbitrating ID
- Real RTR bit
- A dominant reserved bit (must accept but not transmit recessive)
After the identifier (whether 11-bit or 29-bit) has been transmitted, it is only possible for one ECU to be transmitting in a compliant network (i.e., where all ECUs have distinct IDs). After this point, the two frame formats are unified:
- A dominant reserved bit
- 4-bit DLC. Data Length Code, specifying a number of data bytes 0--8.
- For Data Frames, this is the length of the subsequent Data Field
- For Remote Frames, this is the length of the expected response's Data Field
- Larger values (9--15) can appear, but are not used in ISO CAN.
- 0--8 byte Data Field (Data Frames only)
- 15-bit CRC
- A recessive reserved bit (CRC delimiter)
- 1-bit ACK slot. recessive for transmitter, dominant for receivers (who become transmitters for one clock)
- A recessive reserved bit (ACK delimiter)
- 7 recessive reserved bits (Frame delimiter)
Three error frames are defined:
- Active error: 6 dominant bits followed by 8 recessive bits
- Will typically destroy any ongoing message
- Provokes secondary error frames when sent due to a local problem
- Passive error: 6 recessive bits
- Overload frame: 6 dominant bits followed by 8 recessive bits, during the interframe space
Each ECU maintains an RX Error counter and TX Error Counter (REC/TEC), initialized to 0. Successful operations reduce the appropriate counter by 1, though never below 0. Errors increase the counters (usually TEC by 8, REc by 1). Depending on the values of these counters, each ECU is in one of three error states:
- Error-Active: Both counters are less than 128. The ECU will respond to errors with an Active Error Frame.
- Error-Passive: One or both counters are greater than 127. The ECU will respond to errors with (network-transparent) Passive Error Frames.
- The ECU must honor an 8-clock (as opposed to the standard 3) interframe space, the punitive Suspend Transmission Field
- An error causing the ECU to move into the Error-Passive state triggers an Active (not a Passive) Error Frame
- An Error-Passive ECU becomes Error-Active as soon as both counters fall below 128.
- Bus-Off: If the TEC exceeds 255, transmission is disallowed until the host renegotiates with the CAN controller.
- Even following renegotiation, a substantial delay is mandated (128 instances of 11 consecutive recessive bits).
The intent is error confinement: nodes which seem to see errors that no one else does ought remove themselves from the network.
- Bit monitoring -- if transmitting following victory in arbitration, the value read from the bus ought match what we transmit
- Bit stuffing -- five repeated transmitted bits must be followed by the opposite signal for one bit, which is removed from the data stream. if six consecutive bits of the same level are seen, it's an RX error
- Frame check -- invalid value of a specified frame bit
- ACK failure -- transmitter did not see a dominant signal in the ACK slot
- CRC failure -- received CRC did not match computed CRC