Controller Area Network

from Wikipedia, the free encyclopedia

The CAN bus ( C ontroller A rea N etwork ) is a serial bus system and belongs to the field buses .

It was developed by Bosch in 1983 and presented in 1986 together with Intel . Its purpose is to reduce wiring harnesses and thereby save costs and weight. At that time, the total length of all cables in the motor vehicle without CAN could be up to 2 km.

CAN is  internationally standardized as ISO 11898 and defines layers 1 (physical layer) and 2 (data security layer) in the ISO / OSI reference model . The two most common realizations of the physical layers are according to ISO 11898-2 (high-speed CAN) and ISO 11898-3 (low-speed CAN). They differ in numerous properties and are not compatible with one another.

function

Transmission method

The CAN bus works according to the “multi-master principle”, ie it connects several control units with equal rights. A CSMA / CR method resolves collisions (simultaneous bus access) without damaging the winning, higher- priority message. For this purpose, the bits are - depending on the state - dominant or recessive (a dominant bit overwrites a recessive one). The logical 1 is recessive, so it can only prevail on the bus as long as no participant sends a logical 0, logically this corresponds to an AND operation , although a wired OR operation applies to the voltage level when one of the lines is considered. The data are NRZ -coded, with bit stoppers for continuous synchronization, even of bus participants with less stable oscillators . The cyclical redundancy check is used to increase the transmission security .

Voltage level in the high-speed CAN bus

In the case of copper lines, the CAN bus works with two twisted wires, CAN_HIGH and CAN_LOW ( symmetrical signal transmission ). CAN_GND (ground) as the third wire is optional, but often available together with a fourth wire for the 5 V power supply.

At higher data rates (high-speed CAN) the voltage swing between the two states is relatively small: In the recessive idle state the differential voltage is zero (both wires about 2.5 V above ground), in the dominant state it is at least 2 V (CAN_HIGH> 3, 5 V, CAN_LOW <1.5 V).

With the low-speed CAN, which is suitable for longer distances, a voltage swing of 7 V is used by setting the recessive quiescent level to 5 V (CAN_LOW) and 0 V (CAN_HIGH). If one of the two lines fails, the voltage on the other line can be evaluated against ground. In the case of slower buses (“comfort bus”, e.g. for the actuation of elements by the user), a single-wire system with the body as ground can therefore suffice. In practice, it is mostly designed as a two-wire system, but in the event of a wire break it uses the single-wire operation as a fall-back level in order to be able to continue operation. This is then called "Limp Home Mode" (German: "home-limping mode").

topology

Linear CAN bus

The CAN network is set up as a line structure. Branch lines are permitted to a limited extent. A star-shaped bus (e.g. for central locking in a car) is also possible. However, these variants have disadvantages compared to the linear bus:

  • The star-shaped bus is usually controlled by a central computer, since all information has to pass through it, with the result that no information can be passed on if the central computer fails. If an individual control unit fails, the bus continues to function.
  • For branch lines and star-shaped bus architecture, the line impedance is somewhat more complex to determine. The number of stub lines and their total length is estimated using empirical guidelines. The linear bus has the advantage that all control devices are connected to a central line in parallel. The bus will only stop working if this fails. This topology is often used in motor vehicles.

There should be a terminating resistor of 120 Ohm at each end of the line . For a single CAN bus participant on a branch line, this has the same effect as a single 60 ohm resistor that is inserted at the point of junction. This value is the central impedance of a star architecture.

Synchronization and time quanta

The nominal data transmission rate in the network must be known to all participants, possibly through automatic detection - CAN in Automation has issued an application note for this, CiA 801. The synchronization to the exact beginning of a message occurs with the change from the recessive idle level of the bus to the dominant synchronization bit with which every message begins. Any further level change from recessive to dominant can be used for dynamic re-synchronization of the receivers. The post-synchronization compensates for phase noise and drift between the local oscillators. Re-synchronization also takes place during the arbitration phase when a sender begins to send a message with a higher priority. This usually also causes a phase jump in relation to the previous message.

Maximum transmission rate and cable length

A distinction is made between a high-speed bus with a data rate of up to 1 Mbit / s and a low-speed bus with up to 125 kbit / s. However, these rates only apply to cable lengths of up to 40 m. The maximum permissible data rate also depends on the cable length. Longer lines are possible with lower data rates: at 500 kbit / s up to 100 m and at 125 kbit / s up to 500 m.

These maximum values ​​are based on the fact that the time that a signal is present on the bus (bit time, second / bit), the shorter the higher the transmission rate. However, as the cable length increases, the time it takes a signal to reach the other end of the bus increases ( speed of propagation ). It should be noted that the signal not only propagates, but the receiver must also react to the transmitter within a limited time (see ACK). In turn, the sender must be aware of any change in the bus level of the receiver (s) (see also arbitration). This is why calculating the maximum cable length is a bit more complex. Delay times on the line, the transceiver (transmitter and receiver), the controller (transmitter and receiver), oscillator tolerances and the set sampling time (transmitter and receiver) must be taken into account.

The further developed CAN FD standard allows the data rate to be increased after the connection negotiation. This allows the transmission speed of the data section to be increased by a factor of 10 or more.

According to ISO  11898-2 (High-Speed ​​Medium Access Unit), twisted pair cables with a characteristic impedance of 108–132 ohms are originally recommended as the bus medium . In the currently valid edition of ISO 11898-2 from 2003, the tolerance is specified as 95–140 Ohm (Section 7.5.1, Table 9).

The maximum number of participants on the physical level depends on the bus driver components used (transceiver, physical connection to the bus). With common modules, 32, 64 or up to 110 (with restrictions up to 128) subscribers per line are possible (expansion option via repeater or bridge).

Object identifier

The object identifier identifies the content of the message, not the device. For example, in a measuring system, the parameters temperature, voltage and pressure can each be assigned a separate identifier. Several parameters can be combined under one identifier as long as the sum of the data does not exceed the maximum possible length of the data field. The recipients use the identifier to decide whether the message is relevant to them or not.

In addition, the object identifier is also used to prioritize the messages.

The specification defines two identifier formats:

  • 11-bit identifier, also called "Base frame format" (CAN 2.0A)
  • 29-bit identifier, also called "Extended frame format" (CAN 2.0B).

A participant can be the recipient and sender of messages with any number of identifiers, but conversely, there may only be a maximum of one sender for an identifier so that the arbitration works.

The 29-bit identifier is primarily defined for the environment of commercial vehicles, ships, rail vehicles and agricultural machinery. The CAN standard requires that an implementation must accept the "Base frame format", but can accept the "Extended frame format", but must at least tolerate it.

The list of object identifiers including sender and receiver is part of the so-called communication matrix or K matrix .

Arbitration, priority

The bus access is resolved without loss by means of bit-by-bit arbitration based on the identifier of the messages to be sent. To do this, each transmitter monitors the bus while it is currently sending the identifier. If two participants send at the same time, the first dominant bit of one of the two overwrites the corresponding recessive bit of the other, which the latter recognizes and ends its attempt to transmit. If both participants use the same identifier, an error frame is not generated immediately (see frame structure), but only in the event of a collision within the remaining bits, which should be ruled out by the arbitration. The standard therefore recommends that an identifier should only be used by a maximum of one participant.

This process also creates a hierarchy of messages among each other. The message with the lowest identifier can always be transmitted. For the transmission of time-critical messages, a high-priority identifier (= low ID, e.g. 0x001; 0x000 for network management - NMT) can be assigned in order to give them priority during the transmission. However, even with high-priority messages, the time of transmission cannot be precisely determined beforehand, as messages currently being transmitted cannot be interrupted and the start time of a transmission can thus be delayed up to the maximum message length ( non-deterministic behavior ). Only the maximum transmission delay for the highest priority message can be calculated if the maximum message length is known. In general, it is not possible to make a statement about the transmission time for low-priority messages.

If a participant sends messages with a high priority continuously, this can lead to the bus being blocked, as the messages from the other participants lose their arbitration. This behavior is described as a babbling idiot . If this behavior is based on a malfunction, it can only be solved with additional hardware - so-called bus guardians .

Frame construction

CAN data frame with electrical levels without stuff bits
CAN data telegram in base frame format
CAN data telegram in extended frame format

Communication takes place with telegrams. There are control bits and useful bits (red area) within a telegram. The standardized structure of such a telegram frame is called a frame.

There are four different types of frames:

  • Data frame, is used to transport data
  • Remote frame, is used to request a data frame from another participant
  • Error frame, signals a recognized error condition in the transmission to all participants
  • Overload frame, serves as a compulsory break between data and remote frames

Data frame

A data frame is logically structured as follows:

  • Start of Frame (SOF) = a dominant bit
  • Arbitration field, consisting of an identifier segment (11 bit or 29 + 2 bit) plus an RTR bit (Remote Transmission Request, see below)
  • Control field (CTRL) = 6 bits
    • Identifier Extension (IDE) = 1 bit
    • reserved = 1 bit
    • Data Length Code (DLC) = 4 bits (number of bytes in the data field, 0 to 8 bytes, values ​​9 to 15 are not supported)
  • Data field (DATA) = 0 to 8 times 8 bits
  • Check sum field ( CRC ) = 15 bits ( generator polynomial ) followed by a recessive CRC delimiter bit
  • Acknowledgment field (ACK) = 2 bits, consisting of an ACK slot (see explanation below) plus a recessive ACK delimiter
  • End of Frame (EOF) = 7 Bit (recessive)
  • Intermission (IFS - Intermission Frame Space) = 3 bits (= min.number of bits that separate successive messages)

Remote frame

A set RTR bit (Remote Transmission Request) indicates a remote frame (recessive). With the help of a remote frame, a participant can request another to send his data.

In the case of an "Extended Identifier" (see above), the RTR bit is replaced by the SRR bit (Substitute Remote Request) and also sent in recessive form. In this case, the following IDE bit is also sent in a recessive manner, which signals an "Extended Identifier". The remaining 18 bits of the identifier and then the actual RTR bit are then sent. The IDE bit is part of the "arbitration field", although the control field still consists of 6 bits.

The data length must be set according to the expected data length (source of error: Many developers set the data length = 0 - this is wrong; there are also CAN controllers on the market which can only send RTR frames with data length 0). The object identifier is the same as that of the requested message.

Error frame

The error frame consists of two fields:

The first field is determined by the superposition of ERROR FLAGS that can be generated by the various stations.
The following field is the ERROR DELIMITER (8 recessive bits).

There are two types of error flags :

Active error flag
6 dominant bits, sent by a node that has detected an error in the network and is in the error status "error active".
Passive error flag
6 recessive bits, sent by a node that has detected an error in the network and is in the error status "error passive".

Overload frame

The overload frame is a forced pause between data and remote frames.
It contains two fields: Overload Flag and Overload Delimiter.

There are two types of overload that lead to the generation of the overload flag:

  1. The electronics of the receiver require a delay in the transmission of the next data frame or remote frame (e.g. due to a full receive buffer).
  2. Detection of a dominant bit on the bus during a transmission pause in its own transmission process.

An overload frame caused by the first case may only be generated in the first bit interval of an expected pause in transmission, while an overload frame caused by case 2 is sent one clock after the dominant bit has been recognized.

  • The overload flag consists of six dominant bits.
  • The general form corresponds to that of the active error flag: The form of the overload flag destroys the specified form of transmission because the bit stuffing is violated. As a consequence, all other devices also recognize the overload and in turn also generate an overload flag themselves.
  • The overload delimiter consists of eight recessive bits and corresponds to the form of the error delimiter.

ACK slot

The acknowledge slot is used to acknowledge receipt of a correct CAN frame. Every receiver that could not detect an error sets a dominant level at the position of the ACK slot and thus overwrites the recessive level of the sender. In the event of a negative acknowledgment (recessive level), the error-detecting node must apply an error flag after the ACK delimiter so that, firstly, the sender is informed of the transmission error and, secondly, to ensure network-wide data consistency. However, if the recessive level is overwritten by a dominant receiver, the sender cannot assume that the telegram was received by all other receivers.

Bit stuffing

CAN frame with levels with stuff bits.svg

Bit sequences with more than five identical bits are used in the CAN protocol for control purposes e.g. B. "End of Frame" is used. In other words, no more than five bits with the same level may appear in succession within the CAN frame. To prevent this, a bit with the inverse level is inserted after five bits with the same level. This bit is called the “stuff bit” or “stuff bit”. The picture shows the same CAN frame before and after inserting stuffing bits. The stuffing bits are colored purple. Bit stuffing ( bit stuffing ) the physical length can increase a frame. Bit stuffing affects the start of frame (SOF) up to and including the checksum field (CRC) of data and remote frames and is used to synchronize the participants within a frame.

data backup

If a recipient detects an error condition, it sends an error frame and thus causes all participants to discard the frame. If other participants have recognized this error condition, they in turn send another error frame immediately afterwards. This enables a further safety function of the CAN protocol. In order to avoid that individual participants permanently block the message transport due to erroneously recognized error conditions, each participant contains error counters. According to the rules of the specification, these counters allow a faulty subscriber to be separated from the bus in two stages of the operating status if it repeatedly detects errors that other subscribers do not recognize or repeatedly sends incorrect frames. The states are called error active (normal), error passive (subscriber may only send passive - i.e. recessive - error frames) and bus off (subscriber may no longer send).

The transmitter repeats its data transmission after the error frame. The transmitter can also be disconnected from the bus using the error counters mentioned above if the data transmission fails permanently. Different error cases lead to different increases in the error counter.

Standards

  • ISO 11898-1: 2015 Road vehicles - Controller area network - Part 1: Data link layer and physical signaling
  • ISO 11898-2: 2016 Road vehicles - Controller area network - Part 2: High-speed medium access unit
  • ISO 11898-3: 2006 Road vehicles - Controller area network - Part 3: Low-speed, fault-tolerant, medium dependent interface
  • ISO 11898-4: 2004 Road vehicles - Controller area network - Part 4: Time-triggered communication
  • ISO 11898-5: 2007 Road vehicles - Controller area network - Part 5: High-speed medium access unit with low-power mode
  • ISO 11898-6: 2013 Road vehicles - Controller area network - Part 6: High-speed medium access unit with selective wake-up functionality
  • SAE J2284-1: 2016 High Speed ​​CAN for Vehicle Applications at 125 kbps
  • SAE J2284-2: 2016 High Speed ​​CAN for Vehicle Applications at 250 kbps
  • SAE J2284-3: 2016 High Speed ​​CAN for Vehicle Applications at 500 kbps
  • SAE J2284-4: 2016 High Speed ​​CAN for Vehicle Applications at 500 kbps with CAN FD Data at 2 Mbps
  • SAE J2284-5: 2016 High Speed ​​CAN for Vehicle Applications at 500 kbps with CAN FD Data at 5 Mbps

Further development

In 2012, Bosch presented a proposal to increase the available bandwidth called CAN FD (Flexible Data Rate). This is achieved by shortening the bit times in the data phase and increasing the data field to up to 64 bytes. Overall, the process called "improved CAN" is currently promising an up to 8 times higher data throughput. Like the Classical CAN protocol, the CAN FD protocol can recognize all simple (single) bit errors. In addition, multiple (multiple) bit errors are discovered with an even higher probability.

CAN FD has been standardized internationally and is now part of ISO 11898-1: 2015.

Areas of application

CAN protocols have become established in various, especially security-relevant areas, where a high level of data security is important. Examples:

Higher protocols

ISO-TP

ISO 15765-2 , also known as ISO-TP for short, enables the transport of messages whose length exceeds the maximum of 8 bytes of user data of a CAN frame . In the OSI model , it covers layers 3 (network layer) and 4 (transport layer) and can transport up to 4095 bytes of user data per telegram. ISO-TP segments longer messages into several frames and supplements the data packets with metadata, which enables the recipient to interpret the individual frames.

CANopen

CANopen is a CAN-based Layer 7 communication protocol that was initially used in automation technology, but is now mainly used in embedded systems.

CANopen was mainly initiated by small and medium-sized German companies and developed as part of an ESPRIT project under the direction of Bosch. It has been maintained by CAN in Automation since 1995 and is now standardized as the European standard EN 50325-4. It is mainly used in Europe, followed by Asia.

DeviceNet

DeviceNet is a CAN-based layer 7 communication protocol that is mainly used in automation technology.

DeviceNet is mainly used in America. It was developed by Allen-Bradley (part of Rockwell Automation ) and later passed on to the ODVA (Open DeviceNet Vendor Association) as an open standard .

J1939 as well as the extensions NMEA2000 and ISOBUS

J1939 is a CAN-based protocol in the commercial vehicle sector. It is maintained by the Society of Automotive Engineers (SAE). An introduction to J1939 can be found in Application Note Introduction J1939

NMEA 2000 is an extension of SAE J1939 for the maritime sector. The protocol of the NMEA organization is spreading more and more. Predecessor is NMEA 0183 . NMEA2000 is an IEC standard: IEC61162-3.

In agriculture and municipal technology, the ISOBUS (ISO 11783), which is an extension of J1939, is used to control and monitor attachments.

CleANopen

A CAN in Automation working group , the CANopen Special Interest Group (SIG) “Municipal Vehicles”, is developing the CANopen application profile for refuse collection vehicles: CleANopen (DIN EN 50325-4).

CANopen lift

A CAN in Automation working group founded in 2001 , the CANopen Special Interest Group (SIG) “Lift Control”, is developing the CANopen application profile (CANopen CiA-417) for elevators . The first version of CiA 417 was published in summer 2003. Version 2.0 has been freely available on the CiA website since February 2010. The working group is working on the expansion of the CANopen-Lift functionality, refining technical content and ensuring compliance with current, legally prescribed standards for elevators in CiA-417. Version 2.1.0 was adopted in July 2012 and version 2.2.0 (available for CiA members) was adopted as a Draft Standard Proposal in December 2015. In 2016, version 2.3.0 (available for CiA members) was worked on.

Jörg Hellmich (ELFIN GmbH) is the chairman of this working group and operates a wiki for the CANopen Lift user community with content on CANopen Lift independently of the CiA.

SafetyBUS p

SafetyBUS p is a safe communication protocol based on CAN, which is mainly used in automation technology for the transmission of safety-related data. All bus participants have two or even three channels and check the data integrity. The transmission medium itself is not safe, safety is achieved through SafetyBUS p's own data protocol. The SafetyBUS p can be used up to SIL3 .

TTCAN

Time-Triggered Communication on CAN is based on the CAN bus and enables real-time control via higher protocol levels. TTCAN is standardized in ISO 11898-4.

CANaerospace

CANaerospace is an open source communication protocol, which was designed in 1998 especially for use in aviation with its special reliability and performance requirements. In 2000 the American NASA adopted CANaerospace as its own standard. CANaerospace is used in numerous research aircraft around the world and has established itself as the de facto standard in military flight simulation technology.

ARINC 825

ARINC 825 is an international aviation communication standard, which was developed in a technical working group (consisting of several aviation companies , including Boeing and Airbus ) on the basis of CANaerospace.

EnergyBus

EnergyBus logo

EnergyBus is a communication and energy transmission bus and the associated connector system for light electric vehicles such as pedelecs and e-bikes. EnergyBus is specified by a registered association, EnergyBus eV based in Tanna, together with CAN in Automation eV. Members are both individuals and manufacturers of plugs, batteries, controls and drive units (including Bosch , Panasonic , Sanyo , Deutsche Bahn AG , Philips and Varta ).

The communication protocol is defined in the CANopen application profile 454 "energy management systems".

FireCAN

FireCAN was founded in 2006 as a result of cooperation between Austrian and German fire service superstructure manufacturers and is now available as the DIN 14700 standard. FireCAN was originally developed as a free agreement between the major manufacturers on the market, and the editorial support for the joint specification is carried out by Rosenbauer . The presentation took place in the course of the DIN meeting of the NA 031-02-02 AA "Electrical Equipment" committee on October 29, 2009 in Berlin . This data bus definition is based on a simplified CANopen standard and regulates both the physical properties (plugs, cables, pin assignment), the type and number of participants, as well as the data formats and data content used. The ISOBUS, which was successfully introduced in agriculture, is to be understood as an essential predecessor .

Unified Diagnostic Services

Unified Diagnostic Services according to ISO 14229 is now very common in passenger cars . In older models, many manufacturers used their own standards, often based on the ultimately non-standardized standard for KWP on CAN (draft standard ISO / DIS 15765).

See also

literature

  • A list of published CAN books can be found on the CiA website.
  • Wolfhard Lawrenz (Ed.): CAN Controller Area Network - Basics and Practice. , 5th edition, VDE, Berlin / Offenbach 2011, ISBN 978-3-8007-3332-3 .
  • Konrad Etschberger (Ed.): CAN Controller Area Network - Basics, Protocols, Modules, Applications. Hanser, Munich 1994, ISBN 3-446-19431-2 .
  • Horst Engels: CAN bus - technology presented in a simple, clear and practical way. Franzis, Poing 2002, ISBN 3-7723-5146-8 .
  • Werner Zimmermann and Ralf Schmidgall: Bus systems in vehicle technology - protocols, standards and software architecture. 5th edition, Springer Vieweg, Wiesbaden 2014, ISBN 978-3-658-02418-5 .
  • Kai Borgeest: Electronics in vehicle technology. 3rd edition, Springer-Vieweg, Wiesbaden 2013, ISBN 978-3-8348-1642-9 .
  • Konrad Reif: Batteries, electrical systems and networking. Vieweg + Teubner Verlag, Wiesbaden 2010, ISBN 978-3-8348-1310-7 .
  • Gerhard Schnell and Bernhard Wiedemann: Bus systems in automation and process technology, Vieweg + Teubner Verlag, Wiesbaden 2008, ISBN 978-3-8348-0425-9 .

Web links

Individual evidence

  1. ^ Giuseppe Buja, Juan R. Pimentel, Alberto Zuccollo: Overcoming Babbling-Idiot Failures in the FlexCAN Architecture. A simple bus guardian. In: Emerging Technologies and Factory Automation. 2005, ISBN 0-7803-9401-1 , pp. 461-468 ( PDF file ).
  2. 13th iCC Conference Paper. (PDF; 215 KiB) Archived from the original on December 13, 2016 . ;
  3. CAN FD Specification Version 1.0. (PDF; 313 KiB) Archived from the original on July 2, 2017 .;
  4. http://www.can-cia.org/can-knowledge/
  5. An introduction to the protocol: Application Note Introduction J1939 (PDF; 284 kB)
  6. List of EnergyBus members
  7. (old) website FireCAN ( Memento from March 4, 2016 in the Internet Archive )
  8. List of published CAN books. In: can-newsletter.org. Retrieved August 24, 2016 .