* Open System Interconnection (OSI)
* Controller Area Network (CAN)
* What does a CAN bus look like in cars made in Japan?
The fleet of cars on our streets is rapidly rejuvenating, and at the same time we have to master and solve new problems associated with diagnostics and repair. More and more often in your daily work you encounter communication problems between various on-board vehicle systems. If a few years ago cars arriving for diagnostics with errors on the CAN bus (the first character in the classification of the diagnostic trouble code – U) were rare guests, now it is almost everyday practice. Information on this topic is, in principle, available and quite a lot, even a lot – which is good on the one hand, and on the other is a certain difficulty in finding the necessary information. First of all, I would like to give this article a general idea of the CAN (Controller Area Network) system for those who are just starting to get acquainted with it, and those who want to understand this more deeply..
Controller Area Network – this concept came into use after Robert Bosch GmbH developed an industrial network standard in the early 1980s, aimed primarily at combining various actuators and sensors into a single network. One of the first implementations in the automotive industry was carried out on several models of Mercedes-Benz cars in 1992. Until that moment, electronic control of executive functions was built according to the system – one control unit received electronic signals from various sensors and after processing them sent appropriate commands to executive devices (such as a gasoline pump, nozzles, ignition coils, etc.). The increase in the volume of vehicle control functions transmitted to the electronics has led to the appearance of such additional systems as ABS, SRS, AT, Immobilaser and others. The combination of these functions in one ECU would lead to its cumbersomeness and excessive complexity, as well as to a loss of reliability, when a failure of one system could lead to a loss of controllability of the entire car. Therefore, automakers have taken the path of separation of control functions and the allocation of all systems in separate blocks. And in order to integrate all the systems into a single whole for solving common tasks of driving a car, the CAN communication standard from Robert Bosch GmbH came to the rescue and it has become wider and wider applied in the automotive industry. Today, almost every new car is equipped with this system..
Everything is basically simple and understandable, but how is the CAN bus arranged and what is the principle of its operation based on? Here is one example of the relationship of electronic control units and devices tied into a single on-board communication network of a car – Fig. 1
Here we consider only the blocks connected to the wired network, but in the cars of the 21st century, wireless information transmission is also increasingly used. For example, a navigation system, tracking the location of a car (anti-theft protection), monitoring tire pressure, remote diagnostics and many others. In the near future, it can be expected that the merging together of the internal and external information flows in the on-board network of cars will take the vehicle to a new level of safety and comfort, especially in such areas as displaying warning information about dangerous situations on the roads and even actively mitigating the consequences of possible collisions cars, as well as a more rational distribution of traffic flows.
A bit of background – Open System Interconnection (OSI).
It is obvious that if two or more microprocessors are interconnected into one system, then a standard protocol should be used which determines how data should be transferred between network units. The most common example of such a protocol is TCP / IP (Transmission Control Protocol / Internet Protocol), which is used to connect hosting services on the Internet. The predecessor of TCP / IP was the protocol – Open System Interconnection (OSI). This protocol was developed in 1982 by the International Organization for Standardization (ISO 7498-1: 1994 (E)). The OSI protocol is sometimes referred to as the “seven-level” model because it consists of seven independent elements that define the requirements for interconnection at different levels of interaction.
These are the seven levels:
1) Application Level ( Application layer ) – this level determines which applications (programs) have access to the network. For example, email, file transfer, remote access terminals, and web browsers.
2) Data Presentation Level ( Presentation Layer ) – this level defines such moments as data compression and encryption standards.
3) Data transfer rate ( Transport layer ) – this level provides standards for transferring data between recipients, monitors errors and security.
4) Network layer ( Network layer ) – this level is responsible for routing network data traffic.
5) The level of communication channels ( Data link laye r ) – this level provides data transmission synchronization and error control.
6) The level of control over communication sessions ( Session layer ) – this level provides standardization of the beginning and end of communication sessions between various applications and network units.
7) Physical level ( Physical layer ) – this level defines the standards for the physical characteristics of devices in the network, including types of connections and connectors, electrical characteristics of cables, voltage level, current strength, etc..
But the tasks solved by the OSI protocol did not fully meet the needs of automotive electronics, and as a result, Robert Bosch GmbH engineers developed, in the development of the OSI protocol, a special CAN protocol that determined the standards of the physical and channel levels of the OSI model in silicon for serial transferring information between two or more devices.
Controller Area Network (CAN)
CAN was developed by Robert Bosch GmbH for the automotive industry in the early 1980s and officially publicly released for use in 1986. This Bosch CAN development was adopted as an ISO standard (ISO 11898), renamed CAN 2.0A in 1993, and expanded in 1995 to allow more network devices to be identified in CAN 2.0B. As a rule, the CAN bus connects modules (or nodes) to the network using two wires, twisted pair. Many companies, and not just automobile ones, are introducing the CAN protocol in their designs for the interconnection of various electronically controlled devices. In the unofficial classification of devices connected by CAN protocol and having processors of the MPC 5xx series, TouCAN modules are called; having MPC 55xx series processors are called FlexCAN modules. CAN is a serial, multi-sending, multicast protocol, which means that when the bus is free, any node can send a message (multi-sending device), and all nodes can receive and respond to the message (multicast is transmitted). The node that initiates the message is called the transmitter; any node that does not send the message is called the receiver. All messages are assigned static priorities, the transmitting node remains the transmitter until the bus becomes inactive or until a message from another node with a higher priority appears on the network, the process that determines the priority of the messages is called arbitration. A message on the CAN bus can contain up to 8 bytes of data. The message identifier describes the content of the data and is used by the receiving nodes to determine the destination on the network (in other words, the destination to which the message is addressed). In short networks (≤ 40 m), the transmission speed of messages can reach up to 1 Mbps. Longer network distances reduce the available transmission speed, for example, to 125 Kbps on a network up to 500 m long. High Speed CAN ( “ High speed ”CAN) network, considered a network with a data transfer rate of more than 500 Kbps.
Details of the CAN protocol specification are fully described in Robert Bosch GmbH , “ CAN Specification 2.0, ”1991 . You can view the PDF document at the following address: http://esd.cs.ucr.edu/webres/can20.pdf. Next I will give as brief a description as possible about how data is transmitted via CAN, how CAN messages are structured, and how message transmission errors are handled..
There are four types of CAN messages, or frames: a data frame ( Data frame ), remote frame ( Remote frame ), erroneous frame ( Error frame ) and the overload frame ( Overload frame ).
Data Frame – standard CAN message, broadcast data from the transmitter to other network nodes.
Remote Frame – a message broadcast by the transmitter to request data from a specific network node.
Error Frame – can be transmitted by any node that detects an error in the network.
Overload Frame – used as a request for an additional pause between received data (Data Frame) or requests for data reception (Remote Frame).
The differences between Data Frames for CAN 2.0A and CAN 2.0B standards are illustrated below, – fig. 2
The difference between the CAN 2.0 A and CAN 2.0B formats is that the data frame for CAN 2.0B supports both a standard data frame identifier – 11 bits, and an extended data frame identifier – about 29 bits. Standard and extended format frames can be transmitted without problems on one on the same bus, and even have a digital identifier equivalent.
In this case, the standard frame will have a higher priority, – fig. 3
Description of CAN 2.0A message frame
Start of message ( Start of Frame (SOF) ) – 1 bit, must be dominant.
ID ( Identi fi er ) – 11 bits, unique identifier, indicates priority.
Remote Transfer Request ( Remote Transmission Request (RTR) ) – 1 bit, dominant in the message and recessive in the message transfer request.
Reserved – 2 bits, must be dominant.
Data Code Length ( Data Length Code (DLC) ) – 4 bits, the number of data bytes (0-8).
Field of transmitted data ( Data field ) – from 0 to 8 bytes, the size is specified in the field DLC .
Cyclic Redundancy Check Code ( Cyclic Redundancy Check (CRC) ) – 15 bits.
Delimiter CRC – 1 bit, must be recessive.
The confirmation ( Acknowledge (ACK) ) – 1 bit, the transmitter sends a recessive; recipient confirms dominant.
ACK delimiter – 1 bit, must be recessive.
Message Completion ( End of Frame (EOF) ) – 7 bits, must be recessive, – fig. 4
Description of CAN 2.0V standard message frame
Start of Frame (SOF) – 1 bit, must be dominant.
Identifier of standard and extended formats (Identifier) - 11 bits, unique identifier, corresponds to the base ID in extended format.
Extended format identifier ( Identifier Filter – Extended Format ) – 29 bits, consists of 11 bits of the base ID and 18 bits of the extended ID .
Remote Transmission Request (RTR) standard and advanced formats – 1 bit, dominant in the message and recessive in the request for message transmission. In the standard format, 11 identifier bits follow the RTR bit .
Replacing a remote request ( Substitute Remote Request ( Srr ) ) For extended format – 1 bit, must be recessive. SRRs are transmitted in extended message formats at the RTR bit position in a standard message. In the arbitration between standard and advanced messages, recessive SRR gives priority to standard messages.
Field IDE – for standard and extended formats – 1 bit, must be recessive for extended format and dominant for standard.
Reserve ( Reserved r0 ) for the standard format – 1 bit, must be dominant.
Reserve ( Reserved r1, r0 ) for extended format – 2 bits, must be recessive.
Data Length Code (DLC) – 4 bits, number of data bytes (0-8).
Field of transmitted data (Data Field) – from 0 to 8 bytes, the size is defined in the DLC field .
Cyclic Redundancy Check (CRC) ) ) – 15 bits.
CRC delimiter – 1 bit, must be recessive.
Acknowledgment (ACK ) ) – 1 bit, the transmitter sends a recessive; recipient confirms dominant.
ACK delimiter – 1 bit, must be recessive.
End of Frame (EOF ) ) – 7 bits, should be recessive.
CAN data frame
The CAN data frame consists of seven fields: Start Frame (SOF), Arbitration, Control, Data Cyclic, Redundancy Check (CRC), Confirm (ACK), and End Frame (EOF). CAN message bits are designated as “dominant” (0) or “recessive” (1). The SOF field consists of one dominant bit. All network nodes synchronously wait for permission to send messages and begin to transmit simultaneously. The arbitration scheme determines which of the nodes trying to transmit messages has the highest priority and will actually control the bus.
The CAN message arbitration field consists of an 11-bit or 29-bit identifier and a remote transmission bit (RTR). The CAN arbitration scheme is called a “multiple access and collision detection control medium” or CSMA / CD, which ensures that the most important message with the highest priority will be transmitted throughout the network in the first place. The priority of the message is determined by the numerical value of the identifier in the arbitration field, the field with the lowest numerical value has the highest priority. Non-destructive, intelligent arbitration resolves conflicts among competing transmitters. This means that the bus can be considered acting as an AND gate. If a node writes a dominant sign (0) over the network, then each node reads the dominant bit, regardless of its purpose, as specified by the transmitting node. Each transmitting node always reads the response to each transmitted bit. If a node transmits a recessive bit of a message sending request and receives a dominant bit for reading a message, it immediately stops transmitting.
The priority of network arbitration is illustrated below, where the third node has the highest priority and the first lowest, – fig. 5
The RTR bit is turned on to distinguish between messages for transmission and remote requests for receiving messages. In standard messages for transmitting (Data Frame), the RTR bit must be dominant, and in remote requests for receiving messages (Remote Frame) it must be recessive.
Control field and data field in the message (Control and Data Fields)
The field that controls the length of the data code (DLC) consists of 6 bits (of which only the 4 least significant bits are used), they show the amount of data in the message. Since only up to 8 bytes of data can be sent in one message, the DLC field can take values in the range from 000000 to 000111. The data to be transmitted is contained only in the data field. The most significant byte (M ost significant byte (MSB)) of the data bytes is transmitted first..
CAN protocol has five levels of error detection. At the message level, a Cyclic Redundancy Check (CRC) is performed, message checks and a mandatory acknowledgment check (ACK). Level check bit consists of monitor and filling.
Cyclic redundancy errors are detected using a 15-bit CRC code computed by the transmitter from the message content. Each recipient receiving the message recalculates the CRC code and compares it with the transmitted value. The mismatch between the two calculations forces the flag (ﬂ ag) to be set. The messages to be checked in which the error flag will be set are the detection by the recipient of an invalid bit in the CRC delimiter, ACK delimiter, at the end of the EOF message, or in a 3-bit message-splitting space. Ultimately, each receiving node writes a dominant bit to the ACK delimiter cell, which is then read by the sending node. And if the message is not confirmed by the recipient (possibly because the receiving node has stopped working), then the confirmation error flag (ACK) is set.
At the bit level, we have already noted that each transmitted bit is read again by the transmitter of this message when monitoring the acknowledgment of receipt of a message sent by the recipient. If the monitored value differs from the sent value, then an error has been detected at the bit level. In addition, errors at the bit level are detected using “inserts”: After five consecutive identical bits that are transmitted in the message, “insert” follows, a bit of opposite polarity is inserted by the transmitter into the stream of transmitted bits (“insert” bits are inserted into the message from the SOF field to the field CRC). Recipients automatically check the message for “inserts”. If any of the receiving network nodes detects six consecutive identical bits in the received message, then an error is recorded (lack of an “insert”). In addition to detecting errors, “inserts” ensure that there are enough non-return to zero (non-return to zero (NRZ)) bits to support synchronization.
Error Message (The CAN Error Frame)
If the sending or receiving node detects an error, it immediately interrupts the reception or transmission of the current message. An error message called the error flag is made up of six dominant bits and an error message separator consisting of eight recessive bits. Since this bit string violates the “insertion” rule, all other nodes also send an error message. After a critical number of detected errors, the node eventually self-shuts down. Reliability, especially in manufacturing and automotive electronics that use CAN technology, requires that the network can separate random errors (due to power surges, noise, or other temporary causes) from the permanent ones that cause the node to malfunction due to equipment defects. Therefore, nodes store and track the number of errors detected. A node can be in one of three modes, depending on the number of errors recorded:
If the number of errors recorded in each transmission or reception buffer of the corresponding node is greater than zero and less than 128, the node is considered “active with an error” ( “ error active ” ), indicating that although the node remains fully functional, at least one error has been detected.
If the number of recorded errors is between 128 and 255, then the node goes into “passive with errors” (“error passive”) mode. In “passive with errors” mode, the node will transmit at a slower level, sending 8 recessive bits before sending the message again, recognizing that the bus is free.
If the number of recorded errors is more than 255, then the node goes into the “disconnected from the network” mode ( “ bus off ” ) by disconnecting yourself.
An error upon receipt adds 1 to the total number of errors taken into account, an error during transmission adds 8 to the total errors taken into account. Subsequent error-free messages gradually reduce the number of errors taken into account by 1, for each error-free message. If the total number of errors taken into account returns to zero, the node returns to normal operation. The node is in the current mode “ bus off ” can go into mode “ error active ” after 128 network entries of 11 consecutive recessive bits that have been monitored. A message is considered error-free if the transmitting node did not find errors in it up to the EOF field. Corrupted messages are resent immediately as soon as the bus becomes free..
Request data from a specific host (The CAN Remote Frame)
A node that needs data from another network node can request the transfer of such data by sending a corresponding request for data (Remote Frame). For example, the central locking control microprocessor on your car needs to know the position of the gearbox selector from the transmission ECU (whether it is in the “parking” position). The structure of the request for receiving data is similar to the structure of a standard message only without a data field and with a recessive RTR bit.
Request for an additional pause between received data and free space between messages (Overload Frames and Interframe Space)
If any host receives messages faster than it can process them, a request will be generated to provide an additional pause between received data (Overload Frames) to provide additional time between received data or requests for receiving messages (Remote Frame). Like an error message, Overload Frame has two fields with bits: ﬂ ag overload consisting of six dominant bits and an overload separator consisting of eight recessive bits. Unlike error messages, the total count of Overload Frames is not kept..
The space between messages consists of three recessive bits, as well as the bus idle time between messages or remote transmission requests. During a break, no node is allowed to initiate the transmission (if the dominant bit is detected during the Break, an Overload Frame will be generated). The bus idle time lasts until the node has something to transmit, and when the transmission begins, at this moment the appearance of the dominant bit on the bus signals the start of the transmission of the SOF message .
CAN provides a stable, simple and flexible network solution for industrial, automotive and many other applications. The main drawback of the CAN protocol is that the message delay is not defined (due to the existence of Error Frame s, Overload Frame s and retransmissions), and an increase in the delay leads to an increase in network traffic. In general, bus utilization should not exceed 30% of the bus maximum power and ensure that low priority messages do not experience unacceptable delay. Bus utilization is defined as the division of two quantities – the total number of bits used for transmitting divided by the total maximum amount available for transmitting bits, and is calculated as follows:
Step 1 – Select a unit of time ≥ the slowest recorded periodic message on the network (usually 1 second).
Step 2 – All periodic messages are determined.
Step 3 – To each of these messages of approximately the same size, 47 service bits are added (the size of the service data fields is SOF + Arbitration + RTR + Control + CRC + Acknowledgment + EOF +
Interframe Space = 1 + 11 + 1 + 6 + 16 + 2 + 7 + 3 = 47 bits).
Step 4 – Calculate the number of bits used in messages by multiplying the message size in bits by the number of transmissions performed per unit time.
Step 5 – Summation of all bits used in the transmitted messages to estimate the total amount of network traffic. Multiplying this value by a safety factor of 1.1 to get the worst forecast for network traffic.
Step 6 – In conclusion, divide the total number of bits used for transmission by the total maximum number of bits available (for example, 125 Kbit / s or 500 Kbit / s are multiplied by a unit of time) to obtain the estimated percentage of bus load, – fig. 6
For real-time control of the network, it would be desirable to implement a communication protocol that ensures that the time parameters are selected for messages regardless of the bus load. An example of such a protocol that controls the time level of CAN data communication is “time-triggered CAN,” or TTCAN (ISO 11898-4). TTCAN messages have two special types called “time windows”: exclusive time windows, and arbitrating time windows. Exclusive time windows are attached to special messages that are transmitted periodically. Thus, Exclusive time windows do not compete for access to the bus. Arbitrating time windows are used for messages that do not have strict time limits..
Arbitrating time windows, like normal CAN messages, compete for priority-based access to the bus through arbitration. Time-triggered CAN protocol requires the presence of a “master node” in the network, which periodically broadcasts the network time signal (called global time) in a special information message. To increase fault tolerance, the network should have several potential host nodes. If the main node stops working (the absence of a special informational message is detected), other potential main nodes compete for the status of the “main node” using arbitration and the node with the highest priority becomes the new “main node”. After that, the new main node starts broadcasting special informational messages – global time. Time-triggered CAN protocol does not relay damaged messages, nor does it cause Error Frames.
The TTCAN protocol has a competing FlexRay protocol, developed by a consortium of automotive manufacturers and suppliers. A FlexRay communication message (frame) consists of periodic, “static” and “dynamic” parts. A static segment is composed of the same length of time slots corresponding to networked nodes. Each node transmits its messages synchronously in its reserved slot. The static segment also transmits a “sync” frame to provide a global timebase for the network. Unlike CAN, there is no arbitration for the bus. A dynamic segment is essentially a “polling” mechanism where each node is given the opportunity to place the triggered event or asynchronous message on the bus in order of priority, using the “mini-separation into slots” synchronization mechanism. To increase fault tolerance, network nodes using the FlexRay protocol can be connected by two buses or channels simultaneously.
Well, in principle, all the basic information about the CAN protocol, and now a little about how the CAN bus looks on the example of cars made in Japan . I want to note right away that without proper diagnostic equipment, it is possible to diagnose and repair CAN bus faults in a very limited range. It all comes down to checking the physical integrity of the wires, checking the status of the connectors, checking the resistance of the wiring and Terminal resistor, checking the corresponding voltage level on the CAN low and CAN high lines. The use of dealer equipment in diagnostics will also only facilitate verification and narrow down the circle of troubleshooting, with a very great reluctance, automakers allow contact with software and their intellectual property. In case of problems at the program level, only reprogramming or replacing the corresponding computer is possible.
Example CAN tires of a Nissan car 2007g.v. – Fig. 7
Consult III program interface (Nissan), CAN bus diagnostics window, – fig. 8
Example CAN tires of a Mitsubishi 2004g.v car. – pic 9
The controller for the diagnosis of ESD
Without keyword Hello, our new and regular readers. Today we want to present our internal corporate interview with Alexander Nikonov, design engineer of…
CAN data bus
Without keyword Controller Area Network (CAN data bus) Or colloquially: “CAN bus”. In the period from 1984 to 1986, Robert Bosch GmbH invented, developed…
What “gestures” of the traffic controller “say”
What “gestures” of the traffic controller “say” Currently, traffic controllers are quite rare. It is precisely this rarity that is the reason that most…
Sale Ford Explorer – features and rules for the sale of Ford Explorer with mileage through the commission area
Selling a Ford Explorer – the advantages and disadvantages of selling a used Ford Explorer through a commission site Selling Ford Explorer through a…