Error frame can bus - Исправление ошибок и поиск оптимальных решений проблем

Need a practical intro to CAN bus errors?

In this tutorial you’ll learn about the basics of CAN error handling, the 5 CAN bus error types, the CAN
error frame and CAN node error states.

To get practical, we’ll also generate & record CAN errors in 6 experiments.

What are CAN bus errors?

As explained in our simple intro
to CAN
bus, the Controller Area Network is today the de facto standard across automotives and industrial
automation
systems.

A core benefit is the robustness of CAN, making it ideal for safety critical
applications.
Here, it is worth noting:

Error handling is vital to the robustness of CAN.

CAN bus errors can occur for several reasons — faulty cables, noise, incorrect termination, malfunctioning
CAN nodes etc. Identifying, classifying and resolving such CAN errors is key to ensuring the continued
performance of the overall CAN system.

In particular, error handling identifies and rejects erroneous messages, enabling a sender to
re-transmit the message. Further, the process helps identify and disconnect CAN nodes that
consistently transmit erroneous messages.

How does CAN error handling work?

Error handling is a built-in part of the CAN standard and every CAN controller. In other words, every
CAN node handles fault identification and confinement identically. Below we’ve made a simple illustrative example:

CAN node 1 transmits a message onto the CAN bus — and reads every bit it sends
In doing so, it discovers that one bit that was sent dominant was read recessive
This is a ‘Bit Error’ and node 1 raises an Active Error Flag to inform other nodes
In practice, this means that node 1 sends a sequence of 6 dominant bits onto the bus
In turn, the 6 dominant bits are seen as a ‘Bit Stuffing Error’ by other nodes
In response, nodes 2 and 3 simultaneously raise an Active Error Flag
This sequence of raised error flags comprise part of a ‘CAN error frame’
CAN node 1, the transmitter, increases its ‘Transmit Error Counter’ (TEC) by 8
CAN nodes 2 and 3 increase their ‘Receive Error Counter’ (REC) by 1
CAN node 1 automatically re-transmits the message — and now succeeds
As a result, node 1 reduces its TEC by 1 and nodes 2 and 3 reduce their REC by 1

The example references a number of concepts that we will detail shortly: Error frames, error
types, counters and states.

The CAN bus error frame

In the illustrative example, the CAN nodes ‘raise Active Error Flags’, thus creating an ‘error frame’ in
response to detecting a CAN error.

To understand how this works, let us first look at a «normal» CAN frame (without errors):

CAN bus bit stuffing

Notice that we highlighted ‘bit stuffing’ across the CAN frame.

Bit stuffing is a subtle, but vital part of the CAN standard. Basically it states that whenever a CAN node
sends five bits of the same logic level (dominant or recessive), it must send one bit of the opposite level.
This extra bit is automatically removed by the receiving CAN nodes. This process helps ensure continuous
synchronisation of the network.

As per the previous example, when CAN node 1 detects an error during the transmission of a CAN message, it
immediately transmits a sequence of 6 bits of the same logic level — also referred to as raising an Active
Error Flag.

If we measure the transmission of a CAN frame via an oscilloscope and digitize the result, we can also
see the stuff bits in practice (see the red timestamp marks):

Active Error Flags

As we just learned, such a sequence is a violation of the bit stuffing rule — aka a ‘Bit Stuffing Error’.
Further, this error is visible to all CAN nodes on the network (in contrast to the ‘Bit Error’ that resulted
in this error flag being raised). Thus, the raising of error flags can be seen as a way of
«globalizing» the discovery of an error, ensuring that every CAN node is informed.

Note that the other CAN nodes will see the Active Error Flag as a Bit Stuffing Error. In
response they also raise an Active Error Flag.

As we’ll explain shortly, it is important to distinguish between the error flags. In particular, the first
error flag
(from the ‘discovering’ node) is often referred to as a ‘primary’ Active Error Flag, while
the error flags of
subsequent ‘reacting’ nodes are referred to as the ‘secondary’ Active Error Flag(s).

3 CAN error frame examples

Let’s look at three example scenarios:

Example 1: 6 bits of error flags

Here, all CAN nodes simultaneously discover that an error exists in a CAN message and raise their error
flags at the same time.

The result is that the error flags all overlap and the total sequence of dominant
bits lasts for 6 bits in total. All CAN nodes will in this case consider themselves the ‘discovering’ CAN
nodes.

This type of simultaneous discovery is less common in practice. However, it could e.g. happen as a
result of Form
Errors (such as a CRC delimiter being dominant instead of recessive), or if a CAN transmitter
experiences a bit error during the writing of a CRC field.

Example 2: 12 bits of error flags

Here, CAN node 1 transmits a dominant bit, but reads it as recessive — meaning that it discovers a Bit Error.
It immediately transmits a sequence of 6 dominant bits.

The other nodes only discover the Bit Stuffing Error
after the full 6 bits have been read, after which they simultaneously raise their error flags, resulting in
a subsequent sequence of 6 dominant bits — i.e. 12 in total.

Example 3: 9 bits of error flags

Here, CAN node 1 has already transmitted a sequence of 3 dominant bits when it discovers a Bit Error and
begins sending 6 dominant bits.

Once halfway through the primary Active Error Flag, nodes 2 and 3 recognize
the Bit Stuffing Error (due to the 3 initial dominant bits being followed by another 3 dominant bits) and
they begin raising their error flags. The result is that the sequence of dominant bits from error flags
becomes 9 bit long.

The above logic of raising error flags is reflected in what we call an ‘active’ CAN error frame.

Note in particular how the secondary error flags raised by various nodes overlap each other — and how the
primary and secondary flags may overlap as well. The result is that the dominant bit sequence from raised
error
flags may be 6 to 12 bits long.

This sequence is always terminated by a sequence of 8 recessive bits, marking the end of the error frame.

In practice, the active error frame may «begin» at different places in the erroneous CAN frame, depending on
when the
error is discovered. The result, however, will be the same: All nodes discard the erroneous CAN frame and
the
transmitting node can attempt to re-transmit the failed message.

Passive Error Flags

If a CAN node has moved from its default ‘active’ state to a ‘passive’ state (more on this shortly), it will only be
able to raise so-called ‘Passive Error Flags’. A Passive Error Flag is a sequence of 6 recessive bits as seen below.

In this case it’s relevant to distinguish between a Passive Error Flag raised by a transmitting node and a receiving
node.

Example 4: Transmitter is Error Passive

As shown in the illustration (Example 4), if a transmitter (such as CAN node 1 in our example) raises a
Passive Error Flag (e.g. in response to a Bit Error), this will correspond to a consecutive sequence of 6
recessive bits.

This is in turn detected as a Bit Stuffing Error by all CAN nodes. Assuming the other CAN
nodes are still in their Error Active state, they will raise Active Error Flags of 6 dominant bits. In other
words, a passive transmitter can still «communicate» that a CAN frame is erroneous.

Example 5: Receiver is Error Passive

In contrast, if a receiver raises a Passive Error Flag this is in practice «invisible» to all other CAN nodes
on the bus (as any dominant bits win over the sequence of recessive bits) — see also Example 5.

Effectively,
this means that an Error Passive receiver no longer has the ability to destroy frames transmitted by
other CAN nodes.

CAN error types

Next, let us look at what errors may cause CAN nodes to raise error flags.

The CAN bus protocol specifies 5 CAN error types:

Bit Error [Transmitter]
Bit Stuffing Error [Receiver]
Form Error [Receiver]
ACK Error (Acknowledgement) [Transmitter]
CRC Error (Cyclic Redundancy Check) [Receiver]

We’ve already looked at Bit Errors and Bit Stuffing Errors briefly, both of which are evaluated at the bit
level. The remaining three CAN error types are evaluated at the message level.

Below we detail each error type:

#1 Bit Error

Every CAN node on the CAN bus will monitor the signal level at any given time — which means that a
transmitting CAN node also «reads back» every bit it transmits. If the transmitter reads a different data
bit level vs. what it transmitted, the transmitter detects this as a Bit Error.

If a bit mismatch occurs during the arbitration process (i.e. when sending the CAN ID), it is not
interpreted as a Bit Error. Similarly, a mismatch in the acknowledgement slot (ACK field) does not cause
a Bit Error as the ACK field specifically requires a recessive bit from the transmitter to be
overwritten by a dominant bit from a receiver.

#2 Bit Stuffing Error

As explained, bit stuffing is part of the CAN standard. It dictates that after every 5 consecutive bits of
the same logical level, the 6th bit must be a complement. This is required to ensure the on-going
synchronization of the network by providing rising edges. Further, it ensures that a stream of bits are not
mis-interpreted as an error frame or as the interframe space (7 bit recessive sequence) that marks the end
of a message. All CAN nodes automatically remove the extra bits.

If a sequence of 6 bits of the same logical level is observed on the bus within a CAN message (between the
SOF and CRC field), the receiver detects this as a Bit Stuffing Error aka Stuff Error.

#3 Form Error

This message-level check utilises the fact that certain fields/bits in the CAN message must always be of a
certain logical level. Specifically the 1-bit SOF must be dominant, while the entire 8-bit EOF field must be
recessive. Further, the ACK and CRC delimiters must be recessive. If a receiver finds that any of these are
bits are of an invalid logical level, the receiver detects this as a Form Error.

#4 ACK Error (Acknowledgement)

When a transmitter sends a CAN message, it will contain the ACK field (Acknowledgement), in which the
transmitter will transmit a recessive bit. All listening CAN nodes are expected to send a dominant bit in
this field to verify the reception of the message (regardless of whether the nodes are interested in the
message or not). If the transmitter does not read a dominant bit in the ACK slot, the
transmitter detects this as an ACK Error.

#5 CRC Error (Cyclic Redundancy Check)

Every CAN message contains a Cyclic Redundancy Checksum field of 15 bits. Here, the transmitter has
calculated the CRC value and added it to the message. Every receiving node will also calculate the CRC on
their own. If the receiver’s CRC calculation does not match the transmitter’s CRC, the
receiver detects this as a CRC Error.

CAN node states & error counters

As evident, CAN error handling helps destroy erroneous messages — and enables CAN nodes to retry the
transmission of
erroneous messages.

This ensures that short-lived local disturbances (e.g. from noise) will not
result in
invalid/lost data. Instead, the transmitter attempts to re-send the message. If it wins arbitration
(and there
are no errors), the message is successfully sent.

However, what if errors are due to a systematic malfunction in a transmitting node? This could
trigger an endless loop of sending/destroying the same message — jamming the CAN bus.

This is where CAN node states and error counters come in.

In short, the purpose of CAN error tracking is to confine errors by gracefully reducing the privileges of
problematic CAN nodes.

Specifically, let’s look at the three possible states:

Error Active: This is the default state of every CAN node, in which
it is able to
transmit data
and raise ‘Active Error Flags’ when detecting errors
Error Passive: In this state, the CAN node is still able to
transmit data, but it now
raises
‘Passive Error Flags’ when detecting errors. Further, the CAN node now has to wait for an extra 8 bits
(aka
Suspend Transmission Time) in addition to the 3 bit intermission time before it can resume data
transmission (to
allow other CAN nodes to take control of the bus)
Bus Off: In this state, the CAN node disconnects itself from the
CAN bus and can no
longer
transmit data or raise error flags

Every CAN controller keeps track of its own state and acts accordingly.
CAN nodes shift state depending on the value of their error counters. Specifically, every CAN node
keeps track on a Transmit Error Counter (TEC) and Receive Error Counter
(REC):

A CAN node
enters the Error Passive state if the REC or TEC exceed 127
A CAN node
enters the Bus Off state if the TEC exceeds 255

How do the error counters change?

Before we get into the logic of how error counters are increased/reduced, let us revisit the CAN error frame
as well
as the primary/secondary error flags.

As evident from the CAN error frame illustration, a CAN node that observes a dominant bit after its
own
sequence of 6
dominant bits will know that it raised a primary error flag. In this case, we can call this CAN
node the
‘discoverer’ of the error.

At first, it might sound positive to have a CAN node that repeatedly discovers errors and reacts promptly by
raising
an error flag before other nodes. However, in practice, the discoverer is typically also the culprit causing
errors
— and hence it is punished more severely as per the overview.

There are some additions/exceptions to the above rules, see e.g. this overview.

Most are pretty straight-forward based on our previous illustrative example. For example, it seems clear that CAN
node 1 would increase the TEC by 8 as it discovers the Bit Error and raises an error flag. The other nodes in
this
case increase their REC by 1.

This has the intuitive consequence that the transmitting node will quickly reach the Error Passive and eventually
Bus
Off states if it continuously produces faulty CAN messages — whereas the receiving nodes do not change state.

The case where a receiver raises the primary error flag may seem counter-intuitive. However, this could for
example
be the case if a receiver CAN node is malfunctioning in a way that causes it to incorrectly detect errors in
valid
CAN messages. In such a case, the receiver would raise the primary error flag, effectively causing an error.
Alternatively, it can happen in cases where all CAN nodes simultaneously raise error flags.

CAN/LIN data & error logger

The CANedge1 lets you easily
record data from 2 x CAN/LIN buses to an 8-32 GB SD card — incl. support for logging CAN/LIN errors. Simply
connect it to e.g. a car or truck to start logging —
and decode the data via free
software/APIs.

Further, the CANedge2
adds WiFi, letting you auto-transfer data to your own server — and update devices over-the-air.

learn
about the CANedge

Examples: Generating & logging error frames

We have now covered the theoretical basics of CAN errors and CAN error handling. Next, let us look at generating and
logging errors in practice. For this we will use a couple of CANedge devices — and for some tests a
PCAN-USB device.

Tip: Download the MF4 data for the tests to view the data in asammdf or CANalyzer.

download data

Test #1: No CAN bus errors

As a benchmark, we start with a test involving no CAN bus errors. Here, a CANedge2 ‘transmitter’ sends
data to another CANedge2 ‘receiver’ — and both log CAN bus errors.

By loading the MF4 log
file in the asammdf GUI we
verify that no CAN errors occurred during this test, which is to be expected.

Test #2: Removing the CAN bus terminal resistor

In this test, we remove the CAN termination in the middle of a log session. This effectively corresponds to
immediately setting the bit level to dominant. As a result, the CANedge2 transmitter immediately starts
logging Bit Errors (which occur when it attempts to transmit a recessive bit, but reads a
dominant bit). The
CANedge2 Receiver logs Bit Stuffing Errors as it detects 6 consecutive dominant bits.
These errors are
recorded until the termination is added again.

Lack of termination is rarely a practical issue if you’re recording data from a vehicle, machine etc.
However, it’s a common issue when working with ‘test bench’ setups. Here, the lack of termination may
cause confusion as it can be difficult to distinguish from an inactive CAN bus. If in doubt, enabling
error frame logging on the CANedge can be useful in troubleshooting.

Transmitter Bit Errors

Receiver Bit Stuffing Errors

Test #3: Setting an incorrect baud rate

In this test we configure the CANedge receiver node to have a baud rate of 493.827K vs. the baud rate of the
transmitter of 500K. This is a fairly extreme difference and results in ACK Errors for the
transmitter and Bit
Stuffing Errors for the receiver.

In more realistic scenarios, smaller differences in the baud
rate
configuration of
various nodes may cause intermittent error frames and thus message loss.

This example is rather extreme. However, in practice we have sometimes seen CAN buses that use standard
bit rates
(250K, 500K, â€¦), but with specific bit timing settings that differ from the ones that are typically
recommended
(and hence used by the CANedge). This will not lead to a complete shut-down of the communication, but
rather
periodic frame loss of a few percentages. To resolve this, you can construct an ‘advanced bit rate’ in
the
CANedge configuration, essentially setting up the bit-timing to better match the CAN bus you’re logging
from.

Transmitter ACK Error

Receiver Bit Stuffing Errors

Test #4: Removing the acknowledging CAN node

In this test, we use three CANedge units configured as follows:

CANedge1: Configured to
acknowledge data
CANedge2 A:
Configured in ‘silent mode’ (no acknowledgement)
CANedge2 B:
Configured to transmit a CAN frame every 500 ms

In the default setup, data is transmitted by the CANedge2 B onto the CAN bus and recorded with no errors.
However, if we remove the CANedge1 from the bus there are no longer any CAN nodes to acknowledge the frames
sent by the transmitter.

As a result, the transmitter detects ACK Errors. In response, it increases its
Transmit Error Counter and raises Active Error Flags onto the CAN bus. These are in turn
recorded by CANedge2 A (which silently monitors the bus) as Form Errors.

This is due to the fact that the transmitter raises them upon identifying the lack of a dominant
bit in the ACK slot. As soon as a dominant bit is observed by the receiver in the subsequent EOF field
(which should be recessive), a Form Error is detected.

As evident, the transmitter broadcasts 16 Active Error Flags as its TEC is increased from 0 to 16 x 8 =
128.
The transmitter has now exceeded the threshold of a TEC of 127 and enters Error Passive mode. As a
result,
the transmitter still experiences ACK Errors, but now only raises Passive Error Flags (not visible to
the
receiver). At this point, the transmitter keeps attempting to transmit the same frame — and the receiver
keeps recording this retransmission sequence.

This type of error is one we often encounter in our support tickets. Specifically, users may be trying to
use our CAN loggers to record data from a single CAN node (such as a sensor-to-CAN module like our
CANmod). If they decide to enable ‘silent mode’ on the CANedge in such an installation, no CAN nodes
will acknowledge the single CAN node broadcasting data — and the result will either be empty log files,
or log files filled with retransmissions of the same CAN frame (typically at very high frequency).

Transmitter ACK Errors

Receiver Form Errors

Test #5: CAN frame collisions (no retransmission)

When setting up a CAN bus, it is key to avoid overlapping CAN IDs. Failing to do so can result in frame
collisions
as two CAN nodes may both believe they’ve won the arbitration — and hence start transmitting their frames at
the same time.

To simulate this, we use the same setup as in test #4. In addition, we connect a PCAN-USB device as a
secondary
transmitter.

The CANedge2 transmitter is now configured to output a single CAN frame every 10 ms with CAN ID 1 and a
payload of
eight 0xFF bytes. Further, we configure the CANedge2 to disable retransmission of frames that were disrupted
by
errors. The PCAN-USB outputs an identical CAN frame every 2 ms with the 1st byte of the payload changed to
0xFE. The
PCAN device has retransmissions enabled.

This setup quickly creates a frame collision, resulting in the CANedge and PCAN transmitters detecting a
Bit
Error.
In response to this, both raise an Active Error Flag, which is detected as a Bit Stuffing
Error by the
CANedge
receiver. The PCAN device immediately attempts a retransmission and succeeds, while the CANedge waits with
further
transmission until the next message is to be sent.

This type of error should of course never happen in e.g. a car, since the design and test processes will
ensure
that all CAN nodes communicate via globally unique CAN identifiers. However, this problem can easily
occur if
you install a 3rd party device (e.g. a sensor-to-CAN module) to inject data into an existing CAN bus. If
you do
not ensure the global uniqueness of the CAN IDs of external CAN nodes, you may cause frame collisions
and hence
errors on the CAN bus. This is particularly important if your external CAN node broadcasts data with
high
priority CAN IDs as you may then affect safety critical CAN nodes.

USB-to-CAN transmitter Bit Error

CANedge transmitter Bit Error

CANedge receiver Bit Stuffing Error

Test #6: CAN frame collisions (incl. retransmission)

In this test, we use the same setup as before, but we now enable retransmissions on the CANedge2 transmitter.

In this case, the frame collision results in a sequence of subsequent frame collisions as both the CANedge2
and the PCAN-USB device attempt to re-transmit their disrupted messages.

Due to the resulting Bit Errors, both raise a total of 16 Active Error Flags, which are detected as
Bit Stuffing Errors
by the silent CANedge2 receiver. Both transmitters then enter Error Passive mode and stop raising Active Error
Flags, meaning none of them can destroy CAN frames on the bus. As a result, one of the transmitters will
succeed in transmitting a full message, thus ending the retransmission frenzy — and enabling both devices to
resume transmission. However, this only lasts for a few seconds before another collision occurs.

The collision handling is a good example of how effective the CAN error handling is at ‘shutting down’
potentially
problematic sequences and enabling CAN nodes to resume communication. If a frame collision occurs, it is likely
that both CAN nodes will be set up to attempt retransmission, which would cause a jam if not for the error
handling and confinement.

USB-to-CAN transmitter Bit Errors x 16

CANedge transmitter Bit Errors x 16

CANedge receiver Bit Stuffing Errors x 16

Similar to CAN bus errors, the LIN protocol also specifies a set of four error types, which we outline briefly below.
The CANedge supports both CAN/LIN error frame logging.

As for the CAN CRC Error, this error type implies that a LIN node has calculated a different checksum vs. the one
embedded in the LIN bus frame by the transmitter. If you’re using the CANedge as a LIN Subscriber, this error
may indicate that you’ve configured the device ‘frame table’ with incorrect identifiers for some of the LIN
frames on the bus.

This can in turn be used to ‘reverse engineer’ the correct lengths and IDs of proprietary LIN frames via a
step-by-step procedure. See the CANedge Docs for details.

These occur if a specific part of the LIN message does not match the expected value, or if there is a mismatch
between what is transmitted vs. read on the LIN bus.

This error indicates an invalid synchronization field in the start of the LIN frame. It can also indicate a large
deviation between the configured bit rate for a LIN node vs. the bit rate detected from the synchronization
field.

Transmission errors can occur for LIN identifiers registered as SUBSCRIBER messages. If there are no nodes
responding to a SUBSCRIBER message, a transmission error is logged.

Example use cases for CAN error frame logging

CAN bus diagnostics in OEM prototype vehicles

An automotive OEM may have the need to record CAN error frames in the field during late stage prototype
testing. By deploying a CANedge, the OEM engineering team will both be able to troubleshoot issues based on
the actual CAN signals (speed, RPM, temperatures) — as well as issues related with the lower layer CAN
communication in their prototype systems. This is particularly vital if the issues of interest are
intermittent and e.g. only happen once or twice per month. In such scenarios, CAN bus interfaces are not
well suited — and it becomes increasingly relevant to have a cost-effective device to enable scalable
deployments for faster troubleshooting.

Remotely troubleshooting CAN errors in machinery

An OEM or aftermarket user may need to capture rare CAN error events in their machines. To do so, they deploy
a CANedge2 to record the CAN data and related error frames — and automatically upload the data via WiFi to
their own cloud server. Here, errors are automatically identified and an alert is sent to the engineering
team to immediately allow for diagnosing and resolving the issue.

FAQ

No, error frame logging is a highly specific functionality — and only relevant if you know that you need to
record this information. Typically, it’s mainly of value during diagnostics by OEM engineers — and less so for
aftermarket users. In addition, if systematic errors occur they can quickly bloat the log file size.

With the CANedge2 you can of course enable/disable error frame logging over-the-air.

Yes, the CANedge is able to record all CAN/LIN error types. It does, however, not currently record its own error
counter status as this is deemed less relevant from a logging perspective.

The CANedge is only able to raise error flags onto the CAN bus if it is configured in its ‘normal’ mode, in which
it is also able to transmit messages. If in ‘restricted’ mode it can listen to CAN frames and acknowledge CAN
frames — but not raise Active Error Flags onto the bus. In ‘monitoring’ mode (aka ‘silent mode’) it can listen
to the CAN bus traffic, but not acknowledge messages nor raise Active Error Flags.

The CANedge will always record internal CAN/LIN error frames.

If a CAN frame is erroneous, resulting in an error frame, the CANedge generally only records the error type —
without any data related to the erroneous frame (beyond the timestamp). One exception to this rule is for
acknowledgement errors, where the CANedge will still record unacknowledged CAN frames (incl. from retransmission
attempts).

Some researchers have pointed out the risk that ‘bad actors’ could utilize the CAN bus error handling
functionality to enforce remote ‘bus off’ events for safety-critical ECUs. This is a good example of why CAN bus
data loggers & interfaces like the CANedge2 with remote
over-the-air data transfer and updates need to be highly secure (see also our intro to CAN
cybersecurity). For a nice overview of a remote bus off attack, see this
intro by Adrian Colyer.

For more intros, see our guides section — or download the
‘Ultimate Guide’ PDF.

Need to log CAN bus data & errors?

Get your CAN logger today!

Recommended for you

Источник

Промышленная сеть реального времени CAN представляет собой сеть с общей средой передачи данных. Это означает, что все узлы сети одновременно принимают сигналы передаваемые по шине. Невозможно послать сообщение какому-либо конкретному узлу. Все узлы сети принимают весь трафик передаваемый по шине. Однако, CAN-контроллеры предоставляют аппаратную возможность фильтрации CAN-сообщений.

Каждый узел состоит из двух составляющих. Это собственно CAN контроллер, который обеспечивает взаимодействие с сетью и реализует протокол, и микропроцессор (CPU).

Рис. 1. Топология сети CAN.

CAN контроллеры соединяются с помощью дифференциальной шины, которая имеет две линии — CAN_H (can-high) и CAN_L (can-low), по которым передаются сигналы. Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L. Логическая единица — в случае когда сигналы CAN_H и CAN_L одинаковы (отличаются менее чем на 0.5 В). Использование такой дифференциальной схемы передачи делает возможным работу CAN сети в очень сложных внешних условиях. Логический ноль — называется доминантным битом, а логическая единица — рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN. При одновременной передаче в шину лог. нуля и единицы, на шине будет зарегестрирован только логический ноль (доминантный сигнал), а логическая единица будет подавлена (рецессивный сигнал).

Типы сообщений сети CAN.

Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:

Data Frame
Remote Frame
Error Frame
Overload Frame

Data Frame — это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей:

поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть. Поле арбитража состоит в свою очередь из:
- для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)
- для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)
Следует отметить, что поле идентификатора, несмотря на свое название никак не идентифицирует само по себе ни узел в сети, ни содержимое поля данных. Для Data кадра бит RTR всегда выставлен в логический ноль (доминантный сигнал).
поле данных (data field) содержит от 0 до 8 байт данных
поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок
слот подтверждения (Acknowledgement Slot) (1 бит), каждый CAN-контроллер, который правильно принял сообщение посылает бит подтверждения в сеть. Узел, который послал сообщение слушает этот бит, и в случае если подтверждение не пришло, повторяет передачу. В случае приема слота подтверждения передающий узел может быть уверен лишь в том, что хотя бы один из узлов в сети правльно принял его сообщение.

Рис. 2. Data frame стандарта CAN 2.0A.

Remote Frame — это Data Frame без поля данных и с выставленным битом RTR (1 — рецессивные бит). Основное предназначение Remote кадра — это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).

Error Frame — это сообщение которое явно нарушает формат солобщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Error Frame состоит из поля Error Flag, которое состоит из 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing, см. ниже), и поля Error Delimiter, состоящее из 8 рецессивных битов. Error Delimiter дает возможность другим узлам сети обнаружив Error Frame послать в сеть свой Error Flag.

Overload Frame — повторяет структуру и логику работы Error кадра, с той разницей, что он используется перегруженным узлом, который в данный момент не может обработать поступающее сообщение, и поэтому просит при помощи Overload-кадра о повторной передаче данных. В настоящее время Overload-кадр практически не используется.

Контроль доступа к среде передачи (побитовый арбитраж).

Поле арбитража CAN-кадра используется в CAN для разрешения коллизий доступа к шине методом не деструктивного арбитража. Суть метода не деструктивного арбитража заключается в следующем. В случае, когда несколько контроллеров начинают одновременную передачу CAN кадра в сеть, каждый из них сравнивает, бит, который собирается передать на шину с битом, который пытается передать на шину конкурирующий контроллер. Если значения этих битов равны, оба контроллера передают следующий бит. И так происходит до тех пор, пока значения передаваемых битов не окажутся различными. Теперь контроллер, который передавал логический ноль (более приоритетный сигнал) будет продолжать передачу, а другой (другие) контроллер прервёт свою передачу до того времени, пока шина вновь не освободится. Конечно, если шина в данный момент занята, то контроллер не начнет передачу до момента её освобождения.

Рис. 3. Побитовый арбитраж на шине CAN.

Методы обнаружения ошибок.

CAN протокол определяет пять способов обнаружения ошибок в сети:

Bit monitoring
Bit stuffing
Frame check
ACKnowledgement Check
CRC Check

Bit monitoring — каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается.

Bit stuffing — когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.

Frame Check — некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Т.е. протокол CAN точно определяет какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error.

ACKnowledgement Check — каждый узел получив правильное сообщение по сети посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.

CRC Check — каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы, не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.

Механизм ограничения ошибок (Error confinement).

Каждый узел сети CAN, во время работы пытается обнаружить одну из пяти возможных ошибок. Если ошибка обнаружена, узел передает в сеть Error Frame, разрушая тем самым весь текущий трафик сети (передачу и прием текущего сообщения). Все остальные узлы обнаруживают Error Frame и принимают соответствующие действия (сбрасывают принятое сообщение). Кроме того, каждый узел ведет два счетчика ошибок: Transmit Error Counter (счетчик ошибок передачи) и Receive Error Counter (счетчик ошибок приема). Эти счетчики увеличиваются или уменьшаются в соответствие с несколькими правилами. Сами правила управления счетчиками ошибок достаточно сложны, но сводятся к простому принципу, ошибка передачи приводит к увеличению Transmit Error счетчика на 8, ошибка приема увеличивает счетчик Receive Error на 1, любая корректная передача/прием сообщения уменшают соответствующий счетчик на 1. Эти правила приводят к тому, что счетчик ошибок передачи передающего узла увеличивается быстрее, чем счетчик ошибок приема принимающих узлов. Это правило соответствует предположению о большой вероятности того, что источником ошибок является передающий узел.

Каждый узел CAN сети может находится в одном из трех состояний. Когда узел стартует он находится в состоянии Error Active. Когда, значение хотя бы одного из двух счетчиков ошибок превышает предел 127, узел переходит в состояние Error Passive. Когда значение хотя бы одного из двух счетчиков превышает предел 255, узел переходит в состояние Bus Off.

Узел находящийся в состоянии Error Active в случае обнаружения ошибки на шине передает в сеть Active Error Flags. Active Error Flags сотстоит из 6 доминантных бит, поэтому все узлы его регистрируют. Узел в состоянии Passive Error передает в сеть Passive Error Flags при обнаружении ошибки в сети. Passive Error Flags состоит из 6 рецессивных бит, поэтому остальные узлы сети его не замечают, и Passive Error Flags лишь приводит к увеличению Error счетчика узла. Узел в состоянии Bus Off ничего не передает в сеть (не только Error кадры, но вообще никакие другие).

Адресация и протоколы высокого уровня

В CAN не существует явной адресации сообщений и узлов. Протокол CAN нигде не указывает что поле арбитража (Identification field + RTR) должно использоваться как идентификатор сообщения или узла. Таким образом, идентификаторы сообщений и адреса узлов могут находится в любом поле сообщения (в поле арбитража или в поле данных, или присутствовать и там, и там). Точно также протокол не запрещает использовать поле арбитража для передачи данных.

Утилизация поля арбитража и поля данных, и распределение адресов узлов, идентификаторов сообщений и приоритетов в сети является предметом рассмотрений так называемых протоколов высокого уровня (HLP — Higher Layer Protocols). Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.

Рис. 4. Логическая структура протокола CAN.

Существует множество таких высокоуровневых протоколов. Наиболее распространенные из них это:

DeviceNet
CAL/CANopen
SDS
CanKingdom

Физичекий уровень протокола CAN

Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411).

В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898. ISO 11898 в качестве среды передачи определяет двухпроводную дифференциальную линию с импедансом (терминаторы) 120 Ом (допускается колебание импеданса в пределах от 108 Ом до 132 Ом. Физический уровень CAN реализован в специальных чипах — CAN приемо-передатчиках (transceivers), которые преобразуют обычные TTL уровни сигналов используемых CAN-контроллерами в уровни сигналов на шине CAN. Наиболее распространенный CAN приемо-передатчик — Phillips 82C250, который полностью соответствует стандарту ISO 11898.

Махимальная скорость сети CAN в соответствие с протоколом равна 1 Mbit/sec. При скорости в 1 Mbit/sec максимальная длина кабеля равна примерно 40 метрам. Ограничение на длину кабеля связано с конечной скоростью света и механизмом побитового арбитража (во время арбитража все узлы сети должны получать текущий бит передачи одновременно, те сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети. Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице:

скорость передачи	максимальная длина сети
1000 Кбит/сек	40 метров
500 Кбит/сек	100 метров
250 Кбит/сек	200 метров
125 Кбит/сек	500 метров
10 Кбит/сек	6 километров

Разъемы для сети CAN до сих пор НЕ СТАНДАРТИЗОВАНЫ. Каждый протокол высокого уровня обычно определяет свой тип разъемов для CAN-сети.

Источник

Всех приветствую, сегодняшняя статья будет целиком и полностью посвящена обзору протокола CAN. А в одной из следующих статей мы реализуем обмен данными по CAN на практике. Но не буду забегать вперед…

CAN (Controller Area Network) — это промышленный стандарт, позволяющий осуществить объединение в единую сеть различных узлов, механизмов, датчиков и т. п. Протокол является широковещательным, это значит, что все устройства в CAN-сети принимают все передаваемые по шине сигналы. Режим передачи данных — последовательный, при этом байты сообщений формируют кадры определенного вида. Структуру этих кадров данных мы также обязательно разберем в этой статье.

Основные характеристики протокола CAN:

очень высокая надежность и защищенность
каждое сообщение имеет свой собственный приоритет
реализован механизм обнаружения ошибок
автоматическая повторная отправка сообщений, которые были доставлены с ошибкой
уже упомянутый широковещательный характер передачи данных
возможность присутствия нескольких ведущих (master) устройств в одной сети
широкий диапазон скоростей работы
высокая устойчивость интерфейса к помехам
кроме того, есть механизм обнаружения «сбойных» узлов с последующим удалением таких узлов из сети.

Первоначально стандарт был разработан для автомобильной промышленности. И занималась этим компания Bosch в 1980-х годах. Основная идея заключалась в том, чтобы уйти от использования огромного количества проводов, соединяющих многочисленные узлы автомобиля. И протокол CAN позволил этого достичь. С тех пор CAN является основным механизмом соединения устройств, узлов и датчиков автомобиля между собой. Помимо этого, интерфейс CAN активно используется в промышленной автоматизации, а также в системах «умного дома».

Давайте перейдем к физическому уровню протокола. В интернете можно найти много противоречивой информации на этот счет, но истина тут одна ) Стандарт CAN компании Bosch не регламентирует физический уровень передачи данных, поэтому могут использоваться абсолютно разные варианты, например, оптоволокно. На практике же чаще всего используется соединение посредством двухпроводной дифференциальной линии (витой пары). Ориентировочная максимальная длина линии для разных скоростей передачи данных составляет:

Скорость	Длина линии
1 Мбит/с	50 м
500 кбит/с	100 м
125 кбит/с	500 м
10 кбит/с	5 км

Важным условием работоспособности шины является наличие на концах витой пары согласующих резисторов, которые также называют терминаторами, с сопротивлением 120 Ом:

В отличие от многих других протоколов в CAN не рекомендуется описание битов данных как «логического нуля» и «логической единицы». Здесь используются понятия доминантный и рецессивный бит.

Важнейшим свойством является то, что если один из узлов сети хочет выставить на линии рецессивный бит, а другой доминантный, то в итоге на линии окажется доминантный бит. В общем-то отсюда и следует его название, от слова «доминировать» ) Очень хорошо этот процесс иллюстрирует пример с оптоволоконной линией. Как вы помните, в оптоволокне для передачи данных используется «свет», либо он есть (единица), либо его нет (ноль). При использовании в CAN-сети «свет» — доминантный бит, соответственно, отсутствие света или «темнота» — рецессивный.

Вспоминаем про важнейшее свойство передачи данных в сети. Пусть один узел выставляет на линии рецессивный бит, то есть «темноту». Второй узел, напротив, выставляет доминантный бит — «свет». В итоге на линии будет «свет», то есть доминантный бит, что в точности соответствует требованиям сети:

При использовании электрического сигнала устройство, желающее передать в линию доминантный бит, может подтянуть линию к земле. Это и приведет к тому, что на линии будет доминантный бит независимо от того, что выдают на линию другие участники коммуникации.

Это свойство используется для арбитража в сети CAN. Пусть несколько устройств хотят передать данные. Каждый из этих передатчиков сравнивает значение, которое он передает, со значением, фактически присутствующим на линии. В том случае, если передаваемое значение совпадает со считанным, устройство продолжает высылать свои данные. Если значения совпали у нескольких устройств, то все они продолжают передачу как ни в чем не бывало.

Продолжается это до того момента, когда значения станут различными. Если несколько устройств хотят передать рецессивный бит, а одно — доминантный, то в соответствии с правилом, которое мы обсудили выше, на линии окажется доминантный бит. В таком случае отправленные и считанные значения для устройств, пытающихся выдать на линию рецессивное состояние, не совпадут. В этом случае они должны прекратить передачу. А тот узел, который в этот момент передавал доминантный бит, продолжит свою работу. Доминирование в чистом виде )

Сигналы, которые передаются по витой паре, получили название CAN_H и CAN_L (High и Low). Доминантное состояние соответствует случаю, когда потенциал сигнала CAN_H выше потенциала CAN_L. Рецессивное — когда потенциалы равны (разница потенциалов не превышает допустимого отклонения, 0.5 В).

С этим вроде бы разобрались, давайте двигаться дальше! Пришло время определить, как биты объединяются в кадры. Протокол CAN определяет 4 вида кадров:

Кадр данных (data frame)
Кадр удаленного запроса (remote frame)
Кадр перегрузки (overload frame)
Кадр ошибки (error frame)

Для кадра данных возможны два варианта — базовый формат и расширенный. Вот так выглядит структура базового формата:

Поле	Длина	Описание
Начало кадра (SOF)	1 бит	Начало передачи кадра
Идентификатор (ID)	11 бит	Идентификатор сообщения
Запрос на передачу (RTR)	1 бит	Доминантный бит
Бит расширения идентификатора (IDE)	1 бит	Бит определяет длину идентификатора, для базового формата — доминантный бит
Зарезервированный бит	1 бит	Зарезервировано
Длина данных (DLC)	4 бита	Количество байт данных
Данные	0 — 8 байт	Данные
Контрольная сумма (CRC)	15 бит	Контрольная сумма
Разграничитель контрольной суммы	1 бит	Рецессивный бит
Промежуток подтверждения (ACK)	1 бит	Для приемника — доминантный бит, для передатчика — рецессивный
Разграничитель подтверждения	1 бит	Рецессивный бит
Конец кадра (EOF)	7 бит	Все биты рецессивные

А это структура расширенного:

Поле	Длина	Описание
Начало кадра (SOF)	1 бит	Начало передачи кадра
Идентификатор A (ID A)	11 бит	Первая часть идентификатора
Подмена запроса на передачу (SRR)	1 бит	Рецессивный бит
Бит расширения идентификатора (IDE)	1 бит	Бит определяет длину идентификатора, для расширенного формата — рецессивный бит
Идентификатор B (ID B)	18 бит	Вторая часть идентификатора
Запрос на передачу (RTR)	1 бит	Доминантный бит
Зарезервированные биты	2 бита	Зарезервировано
Длина данных (DLC)	4 бита	Количество байт данных
Данные	0 — 8 байт	Данные
Контрольная сумма (CRC)	15 бит	Контрольная сумма
Разграничитель контрольной суммы	1 бит	Рецессивный бит
Промежуток подтверждения (ACK)	1 бит	Для приемника — доминантный бит, для передатчика — рецессивный
Разграничитель подтверждения	1 бит	Рецессивный бит
Конец кадра (EOF)	7 бит	Все биты рецессивные

Результирующий идентификатор получается в результате объединения полей «Идентификатор A» и «Идентификатор B«.

Кадр удаленного запроса (remote frame) представляет из себя кадр данных, описанный выше, но без поля данных и с рецессивным битом RTR. Он используется в случае, когда один узел хочет запросить данные у другого узла.

Кадр ошибки (error frame) передает устройство, обнаружившее ошибку в сети. Фрейм ошибки имеет наивысший приоритет и принимается всеми устройствами сети в обязательном порядке.

Кадр перегрузки (overload frame) используется очень редко. Его идея и назначение заключаются в том, что с его помощью устройство, которое в данный момент не может принять данные, запрашивает повторную передачу этих же данных.

Давайте вернемся чуть назад, к арбитражу данных, и рассмотрим, что это может означать на практике. Итак, несколько устройств начинают передачу сообщения, а точнее кадра данных. Передается бит начала кадра и затем начинается передача идентификатора сообщения. Как вы помните, приоритет будет у того устройства, которое будет передавать доминантный бит, в тот момент, когда все остальные будут передавать рецессивный. То есть чем «позже» среди битов идентификатора появится «рецессивный бит», тем выше будет его приоритет. Другими словами: более высокий приоритет при использовании интерфейса CAN имеют сообщения с меньшим значением идентификатора.

Первые два типа кадров — кадр данных и кадр удаленного запроса — отделяются от других кадров специальным межкадровым промежутком (паузой). А для фреймов ошибки и перегрузки предусмотрена передача без пауз, чтобы обеспечить их скорейшую обработку узлами сети.

Итак, что у нас на очереди теперь? Конечно же контроль ошибок — важнейший аспект работы протокола CAN. Стандарт предусматривает несколько механизмов:

Во-первых, это контроль передачи битов — уровень сигнала в сети сравнивается с передаваемым для каждого бита.
Второй механизм заключается в использовании дополнительных битов (stuffing bit). После передачи любых пяти одинаковых битов автоматически добавляется передача бита противоположного значения. Таким образом, при передаче шести одинаковых битов диагностируется ошибка stuffing’а. Этот механизм используется для кодирования всех полей фреймов данных и запроса. Исключением являются только поля промежутка подтверждения, разграничителя контрольной суммы и EOF.
Стандартная процедура проверки контрольной суммы. Передатчик вычисляет контрольную сумму для текущего кадра и передает ее в линию. В свою очередь, приемник также вычисляет контрольную сумму для принимаемых данных и сравнивает ее с тем значением, которое было отправлено передатчиком. В случае не совпадения значений диагностируется ошибка CRC.
Также выполняется контроль битов фрейма, которые должны иметь заранее определенное значение. В случае, если реальное значение не совпадает с тем, которое ожидается, возникает ошибка.

Благодаря всем этим механизмам, вероятность необнаружения ошибки является очень низкой, что, конечно же, не может не радовать 👍

Кроме того, если один из узлов обнаружил ошибку в сообщении, он сообщает об этом в сеть CAN при помощи фрейма ошибки. А поскольку сеть у нас широковещательная, то о возникновении ошибки становится известно всем участникам коммуникации. И если в сообщении была обнаружена ошибка, его передача будет осуществлена еще раз.

И на этом еще не все! Каждый узел может находиться в одном из трех состояний:

Error Active
Error Passive
Bus Off

Протокол CAN предусматривает, что изначально, после старта, узел находится в первом из этих состояний — Error Active. Каждое устройство имеет два счетчика ошибок:

Счетчик ошибок передачи
Счетчик ошибок приема

Существуют определенные правила обслуживания этих счетчиков, которые сводятся к следующему. Передатчик, обнаруживший ошибку, увеличивает свой счетчик ошибок передачи быстрее, чем приемники увеличивают свои счетчики ошибок приема. Это связано с предположением, что при ошибке, вероятность того, что сбой произошел именно в передатчике, а не в приемнике, достаточно велика. На практике ошибка передачи увеличивает соответствующий счетчик на 8, а ошибка приема лишь на 1. При приеме или передаче корректного сообщения как счетчик ошибок передачи, так и счетчики ошибок приема уменьшаются на 1.

Если значение любого из этих двух счетчиков узла превысит значение 127, то узел переходит в состояние Error Passive. А если величина одного из счетчиков превысит 255, то узел перейдет в состояние Bus Off.

Разница между этими состояниями заключается в действиях узла при диагностировании ошибки:

Узел в состоянии Error Active при обнаружении ошибки передает в шину Active Error Flags — 6 доминантных бит. Поскольку биты доминантные, то это сообщение нарушает обычную работу шины и поэтому все устройства сети также фиксируют возникновение ошибки.
Узел в состоянии Error Passive при обнаружении ошибки передает в шину Passive Error Flags — 6 рецессивных бит, которые игнорируются всеми другими участниками обмена. Поэтому увеличивается только величина счетчика ошибок одного конкретного узла.
И, наконец, узел в состоянии Bus Off ничего не передает в сеть — ни фреймы ошибок, ни фреймы данных, ни какие-либо другие.

Как видите, протокол CAN крайне интересен для изучения, надежен, безопасен, и удобен в использовании. И на этой позитивной ноте на сегодня заканчиваем, скоро займемся практической реализацией протокола, также поговорим о микросхемах и устройствах, обеспечивающих работу с CAN. Так что подписывайтесь на обновления, буду рад снова видеть вас на нашем сайте 🤝

Источник

A Controller Area Network (CAN bus) is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other’s applications without a host computer. It is a message-based protocol, designed originally for multiplex electrical wiring within automobiles to save on copper, but it can also be used in many other contexts. For each device, the data in a frame is transmitted serially but in such a way that if more than one device transmits at the same time, the highest priority device can continue while the others back off. Frames are received by all devices, including by the transmitting device.

History[edit]

Development of the CAN bus started in 1983 at Robert Bosch GmbH.^[1] The protocol was officially released in 1986 at the Society of Automotive Engineers (SAE) conference in Detroit, Michigan. The first CAN controller chips were introduced by Intel in 1987, and shortly thereafter by Philips.^[1] Released in 1991, the Mercedes-Benz W140 was the first production vehicle to feature a CAN-based multiplex wiring system.^[2]^[3]

Bosch published several versions of the CAN specification and the latest is CAN 2.0 published in 1991. This specification has two parts; part A is for the standard format with an 11-bit identifier, and part B is for the extended format with a 29-bit identifier. A CAN device that uses 11-bit identifiers is commonly called CAN 2.0A and a CAN device that uses 29-bit identifiers is commonly called CAN 2.0B. These standards are freely available from Bosch along with other specifications and white papers.^[4]

In 1993, the International Organization for Standardization (ISO) released the CAN standard ISO 11898 which was later restructured into two parts; ISO 11898-1 which covers the data link layer, and ISO 11898-2 which covers the CAN physical layer for high-speed CAN. ISO 11898-3 was released later and covers the CAN physical layer for low-speed, fault-tolerant CAN. The physical layer standards ISO 11898-2 and ISO 11898-3 are not part of the Bosch CAN 2.0 specification. These standards may be purchased from the ISO.

In 2012, Bosch released CAN FD 1.0 or CAN with Flexible Data-Rate. This specification uses a different frame format that allows a different data length as well as optionally switching to a faster bit rate after the arbitration is decided. CAN FD is compatible with existing CAN 2.0 networks so new CAN FD devices can coexist on the same network with existing CAN devices. As of 2018, Bosch was active in extending CAN standards. ^[5]

CAN bus is one of five protocols used in the on-board diagnostics (OBD)-II vehicle diagnostics standard. The OBD-II standard has been mandatory for all cars and light trucks sold in the United States since 1996. The EOBD standard has been mandatory for all petrol vehicles sold in the European Union since 2001 and all diesel vehicles since 2004.^[6]

Applications[edit]

Passenger vehicles, trucks, buses (combustion vehicles and electric vehicles)
Agricultural equipment
Electronic equipment for aviation and navigation
Industrial automation and mechanical control
Elevators, escalators
Building automation
Medical instruments and equipment
Pedelecs
Model railways/railroads
Ships and other maritime applications
Lighting control systems
3D Printers

Automotive[edit]

The modern automobile may have as many as 70 electronic control units (ECU) for various subsystems.^[7] Traditionally, the biggest processor is the engine control unit. Others are used for Autonomous Driving, Advanced Driver Assistance System (ADAS), transmission, airbags, antilock braking/ABS, cruise control, electric power steering, audio systems, power windows, doors, mirror adjustment, battery and recharging systems for hybrid/electric cars, etc. Some of these form independent subsystems, but communications among others are essential. A subsystem may need to control actuators or receive feedback from sensors. The CAN standard was devised to fill this need. One key advantage is that interconnection between different vehicle systems can allow a wide range of safety, economy and convenience features to be implemented using software alone — functionality which would add cost and complexity if such features were «hard wired» using traditional automotive electrics. Examples include:

Auto start/stop: Various sensor inputs from around the vehicle (speed sensors, steering angle, air conditioning on/off, engine temperature) are collated via the CAN bus to determine whether the engine can be shut down when stationary for improved fuel economy and emissions.
Electric park brakes: The «hill hold» functionality takes input from the vehicle’s tilt sensor (also used by the burglar alarm) and the road speed sensors (also used by the ABS, engine control and traction control) via the CAN bus to determine if the vehicle is stopped on an incline. Similarly, inputs from seat belt sensors (part of the airbag controls) are fed from the CAN bus to determine if the seat belts are fastened, so that the parking brake will automatically release upon moving off.
Parking assist systems: when the driver engages reverse gear, the transmission control unit can send a signal via the CAN bus to activate both the parking sensor system and the door control module for the passenger side door mirror to tilt downward to show the position of the curb. The CAN bus also takes inputs from the rain sensor to trigger the rear windscreen wiper when reversing.
Auto lane assist/collision avoidance systems: The inputs from the parking sensors are also used by the CAN bus to feed outside proximity data to driver assist systems such as Lane Departure warning, and more recently, these signals travel through the CAN bus to actuate brake by wire in active collision avoidance systems.
Auto brake wiping: Input is taken from the rain sensor (used primarily for the automatic windscreen wipers) via the CAN bus to the ABS module to initiate an imperceptible application of the brakes whilst driving to clear moisture from the brake rotors. Some high performance Audi and BMW models incorporate this feature.
Sensors can be placed at the most suitable place, and their data used by several ECUs. For example, outdoor temperature sensors (traditionally placed in the front) can be placed in the outside mirrors, avoiding heating by the engine, and data used by the engine, the climate control, and the driver display.

In recent years, the LIN bus (Local Interconnect Network) standard has been introduced to complement CAN for non-critical subsystems such as air-conditioning and infotainment, where data transmission speed and reliability are less critical.

Other[edit]

The CAN bus protocol has been used on the Shimano DI2 electronic gear shift system for road bicycles since 2009, and is also used by the Ansmann and BionX systems in their direct drive motor.
The CAN bus is also used as a fieldbus in general automation environments, primarily due to the low cost of some CAN controllers and processors.
Manufacturers including NISMO aim to use CAN bus data to recreate real-life racing laps in the videogame Gran Turismo 6 using the game’s GPS Data Logger function, which would then allow players to race against real laps.^[8]
Johns Hopkins University’s Applied Physics Laboratory’s Modular Prosthetic Limb (MPL) uses a local CAN bus to facilitate communication between servos and microcontrollers in the prosthetic arm.
Teams in the FIRST Robotics Competition widely use CAN bus to communicate between the roboRIO and other robot control modules.
The CueScript teleprompter range uses CAN bus protocol over coaxial cable, to connect its CSSC – Desktop Scroll Control to the main unit
The CAN bus protocol is widely implemented due to its fault tolerance in electrically noisy environments such as model railroad sensor feedback systems by major commercial Digital Command Control system manufacturers and various open source digital model railroad control projects.
Shearwater Research have implemented the protocol as DiveCAN^[9] to use integrating their dive computers into Diving rebreathers from various manufacturers.

Architecture[edit]

Physical organization[edit]

CAN is a multi-master serial bus standard for connecting electronic control units (ECUs) also known as nodes (automotive electronics is a major application domain). Two or more nodes are required on the CAN network to communicate. A node may interface to devices from simple digital logic e.g. PLD, via FPGA up to an embedded computer running extensive software. Such a computer may also be a gateway allowing a general purpose computer (like a laptop) to communicate over a USB or Ethernet port to the devices on a CAN network.

All nodes are connected to each other through a physically conventional two wire bus. The wires are a twisted pair with a 120 Ω (nominal) characteristic impedance.

This bus uses differential wired-AND signals. Two signals, CAN high (CANH) and CAN low (CANL) are either driven to a «dominant» state with CANH > CANL, or not driven and pulled by passive resistors to a «recessive» state with CANH ≤ CANL. A 0 data bit encodes a dominant state, while a 1 data bit encodes a recessive state, supporting a wired-AND convention, which gives nodes with lower ID numbers priority on the bus.

High-speed CAN network. ISO 11898-2

ISO 11898-2, also called high-speed CAN (bit speeds up to 1 Mbit/s on CAN, 5 Mbit/s on CAN-FD), uses a linear bus terminated at each end with 120 Ω resistors.

High-speed CAN signaling. ISO 11898-2

High-speed CAN signaling drives the CANH wire towards 3.5 V and the CANL wire towards 1.5 V when any device is transmitting a dominant (0), while if no device is transmitting a dominant, the terminating resistors passively return the two wires to the recessive (1) state with a nominal differential voltage of 0 V. (Receivers consider any differential voltage of less than 0.5 V to be recessive.) The dominant differential voltage is a nominal 2 V. The dominant common mode voltage (CANH+CANL)/2 must be within 1.5 to 3.5 V of common, while the recessive common mode voltage must be within ±12 of common.

Low-speed fault-tolerant CAN network. ISO 11898-3

ISO 11898-3, also called low-speed or fault-tolerant CAN (up to 125 kbit/s), uses a linear bus, star bus or multiple star buses connected by a linear bus and is terminated at each node by a fraction of the overall termination resistance. The overall termination resistance should be close to, but not less than, 100 Ω.

Low-speed CAN signaling. ISO 11898-3

Low-speed fault-tolerant CAN signaling operates similarly to high-speed CAN, but with larger voltage swings. The dominant state is transmitted by driving CANH towards the device power supply voltage (5 V or 3.3 V), and CANL towards 0 V when transmitting a dominant (0), while the termination resistors pull the bus to a recessive state with CANH at 0 V and CANL at 5 V. This allows a simpler receiver which just considers the sign of CANH−CANL. Both wires must be able to handle −27 to +40 V without damage.

Electrical properties[edit]

With both high-speed and low-speed CAN, the speed of the transition is faster when a recessive to dominant transition occurs since the CAN wires are being actively driven. The speed of the dominant to recessive transition depends primarily on the length of the CAN network and the capacitance of the wire used.

High-speed CAN is usually used in automotive and industrial applications where the bus runs from one end of the environment to the other. Fault-tolerant CAN is often used where groups of nodes need to be connected together.

The specifications require the bus be kept within a minimum and maximum common mode bus voltage, but do not define how to keep the bus within this range.

The CAN bus must be terminated. The termination resistors are needed to suppress reflections as well as return the bus to its recessive or idle state.

High-speed CAN uses a 120 Ω resistor at each end of a linear bus. Low-speed CAN uses resistors at each node. Other types of terminations may be used such as the Terminating Bias Circuit defined in ISO11783.^[10]

A terminating bias circuit provides power and ground in addition to the CAN signaling on a four-wire cable. This provides automatic electrical bias and termination at each end of each bus segment. An ISO11783 network is designed for hot plug-in and removal of bus segments and ECUs.

Nodes[edit]

Each node requires a

Central processing unit, microprocessor, or host processor
- The host processor decides what the received messages mean and what messages it wants to transmit.
- Sensors, actuators and control devices can be connected to the host processor.
CAN controller; often an integral part of the microcontroller
- Receiving: the CAN controller stores the received serial bits from the bus until an entire message is available, which can then be fetched by the host processor (usually by the CAN controller triggering an interrupt).
- Sending: the host processor sends the transmit message(s) to a CAN controller, which transmits the bits serially onto the bus when the bus is free.
Transceiver Defined by ISO 11898-2/3 Medium Access Unit [MAU] standards
- Receiving: it converts the data stream from CAN bus levels to levels that the CAN controller uses. It usually has protective circuitry to protect the CAN controller.
- Transmitting: it converts the data stream from the CAN controller to CAN bus levels.

Each node is able to send and receive messages, but not simultaneously. A message or Frame consists primarily of the ID (identifier), which represents the priority of the message, and up to eight data bytes. A CRC, acknowledge slot [ACK] and other overhead are also part of the message. The improved CAN FD extends the length of the data section to up to 64 bytes per frame. The message is transmitted serially onto the bus using a non-return-to-zero (NRZ) format and may be received by all nodes.

The devices that are connected by a CAN network are typically sensors, actuators, and other control devices. These devices are connected to the bus through a host processor, a CAN controller, and a CAN transceiver.

Data transmission[edit]

CAN data transmission uses a lossless bitwise arbitration method of contention resolution. This arbitration method requires all nodes on the CAN network to be synchronized to sample every bit on the CAN network at the same time. This is why some call CAN synchronous. Unfortunately the term synchronous is imprecise since the data is transmitted in an asynchronous format, namely without a clock signal.

The CAN specifications use the terms «dominant» bits and «recessive» bits, where dominant is a logical 0 (actively driven to a voltage by the transmitter) and recessive is a logical 1 (passively returned to a voltage by a resistor). The idle state is represented by the recessive level (Logical 1). If one node transmits a dominant bit and another node transmits a recessive bit then there is a collision and the dominant bit «wins». This means there is no delay to the higher-priority message, and the node transmitting the lower priority message automatically attempts to re-transmit six bit clocks after the end of the dominant message. This makes CAN very suitable as a real-time prioritized communications system.

The exact voltages for a logical 0 or 1 depend on the physical layer used, but the basic principle of CAN requires that each node listen to the data on the CAN network including the transmitting node(s) itself (themselves). If a logical 1 is transmitted by all transmitting nodes at the same time, then a logical 1 is seen by all of the nodes, including both the transmitting node(s) and receiving node(s). If a logical 0 is transmitted by all transmitting node(s) at the same time, then a logical 0 is seen by all nodes. If a logical 0 is being transmitted by one or more nodes, and a logical 1 is being transmitted by one or more nodes, then a logical 0 is seen by all nodes including the node(s) transmitting the logical 1. When a node transmits a logical 1 but sees a logical 0, it realizes that there is a contention and it quits transmitting. By using this process, any node that transmits a logical 1 when another node transmits a logical 0 «drops out» or loses the arbitration. A node that loses arbitration re-queues its message for later transmission and the CAN frame bit-stream continues without error until only one node is left transmitting. This means that the node that transmits the first 1 loses arbitration. Since the 11 (or 29 for CAN 2.0B) bit identifier is transmitted by all nodes at the start of the CAN frame, the node with the lowest identifier transmits more zeros at the start of the frame, and that is the node that wins the arbitration or has the highest priority.

For example, consider an 11-bit ID CAN network, with two nodes with IDs of 15 (binary representation, 00000001111) and 16 (binary representation, 00000010000). If these two nodes transmit at the same time, each will first transmit the start bit then transmit the first six zeros of their ID with no arbitration decision being made.

	Start bit	ID bits	The rest of the frame
10	9	8	7	6	5	4	3	2	1	0
Node 15	0	0	0	0	0	0	0	0	1	1	1	1
Node 16	0	0	0	0	0	0	0	1	Stopped Transmitting
CAN data	0	0	0	0	0	0	0	0	1	1	1	1

When the 7th ID bit is transmitted, the node with the ID of 16 transmits a 1 (recessive) for its ID, and the node with the ID of 15 transmits a 0 (dominant) for its ID. When this happens, the node with the ID of 16 knows it transmitted a 1, but sees a 0 and realizes that there is a collision and it lost arbitration. Node 16 stops transmitting which allows the node with ID of 15 to continue its transmission without any loss of data. The node with the lowest ID will always win the arbitration, and therefore has the highest priority.

Bit rates up to 1 Mbit/s are possible at network lengths below 40 m. Decreasing the bit rate allows longer network distances (e.g.,500 m at 125 kbit/s). The improved CAN FD standard allows increasing the bit rate after arbitration and can increase the speed of the data section by a factor of up to ten or more of the arbitration bit rate.

ID allocation[edit]

Message IDs must be unique^[11] on a single CAN bus, otherwise two nodes would continue transmission beyond the end of the arbitration field (ID) causing an error.

In the early 1990s, the choice of IDs for messages was done simply on the basis of identifying the type of data and the sending node; however, as the ID is also used as the message priority, this led to poor real-time performance. In those scenarios, a low CAN bus use of around 30% was commonly required to ensure that all messages would meet their deadlines. However, if IDs are instead determined based on the deadline of the message, the lower the numerical ID and hence the higher the message priority, then bus use of 70 to 80% can typically be achieved before any message deadlines are missed
.^[12]

Bit timing[edit]

All nodes on the CAN network must operate at the same nominal bit rate, but noise, phase shifts, oscillator tolerance and oscillator drift mean that the actual bit rate might not be the nominal bit rate.^[13] Since a separate clock signal is not used, a means of synchronizing the nodes is necessary. Synchronization is important during arbitration since the nodes in arbitration must be able to see both their transmitted data and the other nodes’ transmitted data at the same time. Synchronization is also important to ensure that variations in oscillator timing between nodes do not cause errors.

Synchronization starts with a hard synchronization on the first recessive to dominant transition after a period of bus idle (the start bit). Resynchronization occurs on every recessive to dominant transition during the frame. The CAN controller expects the transition to occur at a multiple of the nominal bit time. If the transition does not occur at the exact time the controller expects it, the controller adjusts the nominal bit time accordingly.

The adjustment is accomplished by dividing each bit into a number of time slices called quanta, and assigning some number of quanta to each of the four segments within the bit: synchronization, propagation, phase segment 1 and phase segment 2.

An example CAN bit timing with 10 time quanta per bit.

The number of quanta the bit is divided into can vary by controller, and the number of quanta assigned to each segment can be varied depending on bit rate and network conditions.

A transition that occurs before or after it is expected causes the controller to calculate the time difference and lengthen phase segment 1 or shorten phase segment 2 by this time. This effectively adjusts the timing of the receiver to the transmitter to synchronize them. This resynchronization process is done continuously at every recessive to dominant transition to ensure the transmitter and receiver stay in sync. Continuously resynchronizing reduces errors induced by noise, and allows a receiving node that was synchronized to a node which lost arbitration to resynchronize to the node which won arbitration.

Layers[edit]

The CAN protocol, like many networking protocols, can be decomposed into the following abstraction layers:

Application layer
Object layer

Message filtering
Message and status handling

Transfer layer

Most of the CAN standard applies to the transfer layer. The transfer layer receives messages from the physical layer and transmits those messages to the object layer. The transfer layer is responsible for bit timing and synchronization, message framing, arbitration, acknowledgement, error detection and signaling, and fault confinement. It performs:

Fault confinement
Error detection
Message validation
Acknowledgement
Arbitration
Message framing
Transfer rate and timing
Information routing

Physical layer

CAN bus electrical sample topology with terminator resistors

CAN bus (ISO 11898-1:2003) originally specified the link layer protocol with only abstract requirements for the physical layer, e.g., asserting the use of a medium with multiple-access at the bit level through the use of dominant and recessive states. The electrical aspects of the physical layer (voltage, current, number of conductors) were specified in ISO 11898-2:2003, which is now widely accepted. However, the mechanical aspects of the physical layer (connector type and number, colors, labels, pin-outs) have yet to be formally specified. As a result, an automotive ECU will typically have a particular—often custom—connector with various sorts of cables, of which two are the CAN bus lines. Nonetheless, several de facto standards for mechanical implementation have emerged, the most common being the 9-pin D-sub type male connector with the following pin-out:

pin 2: CAN-Low (CAN−)
pin 3: GND (ground)
pin 7: CAN-High (CAN+)
pin 9: CAN V+ (power)

A male DE-9 connector (plug)

This de facto mechanical standard for CAN could be implemented with the node having both male and female 9-pin D-sub connectors electrically wired to each other in parallel within the node. Bus power is fed to a node’s male connector and the bus draws power from the node’s female connector. This follows the electrical engineering convention that power sources are terminated at female connectors. Adoption of this standard avoids the need to fabricate custom splitters to connect two sets of bus wires to a single D connector at each node. Such nonstandard (custom) wire harnesses (splitters) that join conductors outside the node reduce bus reliability, eliminate cable interchangeability, reduce compatibility of wiring harnesses, and increase cost.

The absence of a complete physical layer specification (mechanical in addition to electrical) freed the CAN bus specification from the constraints and complexity of physical implementation. However it left CAN bus implementations open to interoperability issues due to mechanical incompatibility. In order to improve interoperability, many vehicle makers have generated specifications describing a set of allowed CAN transceivers in combination with requirements on the parasitic capacitance on the line. The allowed parasitic capacitance includes both capacitors as well as ESD protection (ESD^[14] against ISO 7637-3). In addition to parasitic capacitance, 12V and 24V systems do not have the same requirements in terms of line maximum voltage. Indeed, during jump start events light vehicle lines can go up to 24V while truck systems can go as high as 36V. New solutions are emerging, allowing the same component to be used for CAN as well as CAN FD (see ^[15]).

Noise immunity on ISO 11898-2:2003 is achieved by maintaining the differential impedance of the bus at a low level with low-value resistors (120 ohms) at each end of the bus. However, when dormant, a low-impedance bus such as CAN draws more current (and power) than other voltage-based signaling busses. On CAN bus systems, balanced line operation, where current in one signal line is exactly balanced by current in the opposite direction in the other signal provides an independent, stable 0 V reference for the receivers. Best practice determines that CAN bus balanced pair signals be carried in twisted pair wires in a shielded cable to minimize RF emission and reduce interference susceptibility in the already noisy RF environment of an automobile.

ISO 11898-2 provides some immunity to common mode voltage between transmitter and receiver by having a 0 V rail running along the bus to maintain a high degree of voltage association between the nodes. Also, in the de facto mechanical configuration mentioned above, a supply rail is included to distribute power to each of the transceiver nodes. The design provides a common supply for all the transceivers. The actual voltage to be applied by the bus and which nodes apply to it are application-specific and not formally specified. Common practice node design provides each node with transceivers which are optically isolated from their node host and derive a 5 V linearly regulated supply voltage for the transceivers from the universal supply rail provided by the bus. This usually allows operating margin on the supply rail sufficient to allow interoperability across many node types. Typical values of supply voltage on such networks are 7 to 30 V. However, the lack of a formal standard means that system designers are responsible for supply rail compatibility.

ISO 11898-2 describes the electrical implementation formed from a multi-dropped single-ended balanced line configuration with resistor termination at each end of the bus.
In this configuration a dominant state is asserted by one or more transmitters switching the CAN− to supply 0 V and (simultaneously) switching CAN+ to the +5 V bus voltage thereby forming a current path through the resistors that terminate the bus. As such the terminating resistors form an essential component of the signaling system, and are included, not just to limit wave reflection at high frequency.

During a recessive state the signal lines and resistor(s) remain in a high impedances state with respect to both rails. Voltages on both CAN+ and CAN− tend (weakly) towards a voltage midway between the rails. A recessive state is present on the bus only when none of the transmitters on the bus is asserting a dominant state.

During a dominant state the signal lines and resistor(s) move to a low impedance state with respect to the rails so that current flows through the resistor. CAN+ voltage tends to +5 V and CAN− tends to 0 V.

Irrespective of signal state the signal lines are always in low impedance state with respect to one another by virtue of the terminating resistors at the end of the bus.

This signalling strategy differs significantly from other balanced line transmission technologies such as RS-422/3, RS-485, etc. which employ differential line drivers/ receivers and use a signalling system based on the differential mode voltage of the balanced line crossing a notional 0 V. Multiple access on such systems normally relies on the media supporting three states (active high, active low and inactive tri-state) and is dealt with in the time domain. Multiple access on CAN bus is achieved by the electrical logic of the system supporting just two states that are conceptually analogous to a ‘wired AND’ network.

Frames[edit]

A CAN network can be configured to work with two different message (or «frame») formats: the standard or base frame format (described in CAN 2.0 A and CAN 2.0 B), and the extended frame format (described only by CAN 2.0 B). The only difference between the two formats is that the «CAN base frame» supports a length of 11 bits for the identifier, and the «CAN extended frame» supports a length of 29 bits for the identifier, made up of the 11-bit identifier («base identifier») and an 18-bit extension («identifier extension»). The distinction between CAN base frame format and CAN extended frame format is made by using the IDE bit, which is transmitted as dominant in case of an 11-bit frame, and transmitted as recessive in case of a 29-bit frame. CAN controllers that support extended frame format messages are also able to send and receive messages in CAN base frame format. All frames begin with a start-of-frame (SOF) bit that denotes the start of the frame transmission.

CAN has four frame types:

Data frame: a frame containing node data for transmission
Remote frame: a frame requesting the transmission of a specific identifier
Error frame: a frame transmitted by any node detecting an error
Overload frame: a frame to inject a delay between data or remote frame

Data frame[edit]

The data frame is the only frame for actual data transmission. There are two message formats:

Base frame format: with 11 identifier bits
Extended frame format: with 29 identifier bits

The CAN standard requires that the implementation must accept the base frame format and may accept the extended frame format, but must tolerate the extended frame format.

Base frame format[edit]

A complete CAN bus frame, including stuff bits, a correct CRC, and inter-frame spacing

The frame format is as follows: The bit values are described for CAN-LO signal.

Field name	Length (bits)	Purpose
Start-of-frame	1	Denotes the start of frame transmission
Identifier (green)	11	A (unique) identifier which also represents the message priority
Stuff bit	1	A bit of the opposite polarity to maintain synchronisation; see Bit stuffing, below
Remote transmission request (RTR) (blue)	1	Must be dominant (0) for data frames and recessive (1) for remote request frames (see Remote Frame, below)
Identifier extension bit (IDE)	1	Must be dominant (0) for base frame format with 11-bit identifiers
Reserved bit (r0)	1	Reserved bit. Must be dominant (0), but accepted as either dominant or recessive.
Data length code (DLC) (yellow)	4	Number of bytes of data (0–8 bytes)^[a]
Data field (red)	0–64 (0-8 bytes)	Data to be transmitted (length in bytes dictated by DLC field)
CRC	15	Cyclic redundancy check
CRC delimiter	1	Must be recessive (1)
ACK slot	1	Transmitter sends recessive (1) and any receiver can assert a dominant (0)
ACK delimiter	1	Must be recessive (1)
End-of-frame (EOF)	7	Must be recessive (1)
Inter-frame spacing (IFS)	3	Must be recessive (1)

^ It is physically possible for a value between 9–15 to be transmitted in the 4-bit DLC, although the data is still limited to eight bytes. Certain controllers allow the transmission or reception of a DLC greater than eight, but the actual data length is always limited to eight bytes.

Extended frame format[edit]

The frame format is as follows on from here in the table below:

Field name	Length (bits)	Purpose
Start-of-frame	1	Denotes the start of frame transmission
Identifier A (green)	11	First part of the (unique) identifier which also represents the message priority
Substitute remote request (SRR)	1	Must be recessive (1)
Identifier extension bit (IDE)	1	Must be recessive (1) for extended frame format with 29-bit identifiers
Identifier B (green)	18	Second part of the (unique) identifier which also represents the message priority
Remote transmission request (RTR) (blue)	1	Must be dominant (0) for data frames and recessive (1) for remote request frames (see Remote Frame, below)
Reserved bits (r1, r0)	2	Reserved bits which must be set dominant (0), but accepted as either dominant or recessive
Data length code (DLC) (yellow)	4	Number of bytes of data (0–8 bytes)^[a]
Data field (red)	0–64 (0-8 bytes)	Data to be transmitted (length dictated by DLC field)
CRC	15	Cyclic redundancy check
CRC delimiter	1	Must be recessive (1)
ACK slot	1	Transmitter sends recessive (1) and any receiver can assert a dominant (0)
ACK delimiter	1	Must be recessive (1)
End-of-frame (EOF)	7	Must be recessive (1)

^ It is physically possible for a value between 9–15 to be transmitted in the 4-bit DLC, although the data is still limited to eight bytes. Certain controllers allow the transmission or reception of a DLC greater than eight, but the actual data length is always limited to eight bytes.

The two identifier fields (A & B) combine to form a 29-bit identifier.

Remote frame[edit]

Generally data transmission is performed on an autonomous basis with the data source node (e.g., a sensor) sending out a data frame. It is also possible, however, for a destination node to request the data from the source by sending a remote frame.
There are two differences between a data frame and a remote frame. Firstly the RTR-bit is transmitted as a dominant bit in the data frame and secondly in the remote frame there is no data field. The DLC field indicates the data length of the requested message (not the transmitted one).
I.e.,

RTR = 0 ; DOMINANT in data frame

RTR = 1 ; RECESSIVE in remote frame

In the event of a data frame and a remote frame with the same identifier being transmitted at the same time, the data frame wins arbitration due to the dominant RTR bit following the identifier.

Error frame[edit]

The error frame consists of two different fields:

The first field is given by the superposition of ERROR FLAGS (6–12 dominant/recessive bits) contributed from different stations.
The following second field is the ERROR DELIMITER (8 recessive bits).

There are two types of error flags:

Active Error Flag: six dominant bits – Transmitted by a node detecting an error on the network that is in error state «error active».
Passive Error Flag: six recessive bits – Transmitted by a node detecting an active error frame on the network that is in error state «error passive».

There are two error counters in CAN:

Transmit error counter (TEC)
Receive error counter (REC)

When TEC or REC is greater than 127 and less than 255, a Passive Error frame will be transmitted on the bus.
When TEC and REC is less than 128, an Active Error frame will be transmitted on the bus.
When TEC is greater than 255, then the node enters into Bus Off state, where no frames will be transmitted.

Overload frame[edit]

The overload frame contains the two bit fields Overload Flag and Overload Delimiter. There are two kinds of overload conditions that can lead to the transmission of an overload flag:

The internal conditions of a receiver, which requires a delay of the next data frame or remote frame.
Detection of a dominant bit during intermission.

The start of an overload frame due to case 1 is only allowed to be started at the first bit time of an expected intermission, whereas overload frames due to case 2 start one bit after detecting the dominant bit. Overload Flag consists of six dominant bits. The overall form corresponds to that of the active error flag. The overload flag’s form destroys the fixed form of the intermission field. As a consequence, all other stations also detect an overload condition and on their part start transmission of an overload flag. Overload Delimiter consists of eight recessive bits. The overload delimiter is of the same form as the error delimiter.

ACK slot[edit]

The acknowledge slot is used to acknowledge the receipt of a valid CAN frame. Each node that receives the frame, without finding an error, transmits a dominant level in the ACK slot and thus overrides the recessive level of the transmitter. If a transmitter detects a recessive level in the ACK slot, it knows that no receiver found a valid frame. A receiving node may transmit a recessive to indicate that it did not receive a valid frame, but another node that did receive a valid frame may override this with a dominant. The transmitting node cannot know that the message has been received by all of the nodes on the CAN network.

Often, the mode of operation of the device is to re-transmit unacknowledged frames over and over. This may lead to eventually entering the «error passive» state.

Interframe spacing[edit]

Data frames and remote frames are separated from preceding frames by a bit field called interframe space. Interframe space consists of at least three consecutive recessive (1) bits. Following that, if a dominant bit is detected, it will be regarded as the «Start of frame» bit of the next frame. Overload frames and error frames are not preceded by an interframe space and multiple overload frames are not separated by an interframe space. Interframe space contains the bit fields intermission and bus idle, and suspend transmission for error passive stations, which have been transmitter of the previous message.^[16]

Bit stuffing[edit]

CAN frame before and after the addition of stuff bits (in purple). An incorrect CRC is used for bit stuffing illustration purposes.

To ensure enough transitions to maintain synchronization, a bit of opposite polarity is inserted after five consecutive bits of the same polarity. This practice is called bit stuffing, and is necessary due to the non-return-to-zero (NRZ) coding used with CAN. The stuffed data frames are destuffed by the receiver.

All fields in the frame are stuffed with the exception of the CRC delimiter, ACK field and end of frame which are a fixed size and are not stuffed. In the fields where bit stuffing is used, six consecutive bits of the same polarity (111111 or 000000) are considered an error. An active error flag can be transmitted by a node when an error has been detected. The active error flag consists of six consecutive dominant bits and violates the rule of bit stuffing.

Bit stuffing means that data frames may be larger than one would expect by simply enumerating the bits shown in the tables above. The maximum increase in size of a CAN frame (base format) after bit stuffing is in the case

11111000011110000…

which is stuffed as (stuffing bits in bold):

111110000011111000001…

The stuffing bit itself may be the first of the five consecutive identical bits, so in the worst case there is one stuffing bit per four original bits.

The size of a base frame is bounded by

${displaystyle 8n+44+leftlfloor {frac {34+8n-1}{4}}rightrfloor }$

since is the size of the frame before stuffing, in the worst case one bit will be added every four original bits after the first one (hence the −1 at the numerator) and, because of the layout of the bits of the header, only 34 out of 44 of them can be subject to bit stuffing.

frame type	before stuffing	after stuffing	stuffing bits	total frame length
base frame		${displaystyle 8n+44+leftlfloor {frac {34+8n-1}{4}}rightrfloor }$
extended frame		${displaystyle 8n+64+leftlfloor {frac {54+8n-1}{4}}rightrfloor }$

An undesirable side effect of the bit stuffing scheme is that a small number of bit errors in a received message may corrupt the destuffing process, causing a larger number of errors to propagate through the destuffed message. This reduces the level of protection that would otherwise be offered by the CRC against the original errors. This deficiency of the protocol has been addressed in CAN FD frames by the use of a combination of fixed stuff bits and a counter that records the number of stuff bits inserted.

CAN lower-layer standards[edit]

ISO 11898 series specifies physical and data link layer (levels 1 and 2 of the ISO/OSI model) of serial communication category called Controller Area Network that supports distributed real-time control and multiplexing for use within road vehicles.^[17]

There are several CAN physical layer and other standards:

ISO 11898-1:2015 specifies the data link layer (DLL) and physical signalling of the controller area network (CAN).^[18] This document describes the general architecture of CAN in terms of hierarchical layers according to the ISO reference model for open systems interconnection (OSI) established in ISO/IEC 7498-1 and provides the characteristics for setting up an interchange of digital information between modules implementing the CAN DLL with detailed specification of the logical link control (LLC) sublayer and medium access control (MAC) sublayer.

ISO 11898-2:2016 specifies the high-speed (transmission rates of up to 1 Mbit/s) medium access unit (MAU), and some medium dependent interface (MDI) features (according to ISO 8802-3), which comprise the physical layer of the controller area network. ISO 11898-2 uses a two-wire balanced signalling scheme. It is the most used physical layer in vehicle powertrain applications and industrial control networks.

ISO 11898-3:2006 specifies low-speed, fault-tolerant, medium-dependent interface for setting up an interchange of digital information between electronic control units of road vehicles equipped with the CAN at transmission rates above 40 kbit/s up to 125 kbit/s.

ISO 11898-4:2004 specifies time-triggered communication in the CAN (TTCAN). It is applicable to setting up a time-triggered interchange of digital information between electronic control units (ECU) of road vehicles equipped with CAN, and specifies the frame synchronisation entity that coordinates the operation of both logical link and media access controls in accordance with ISO 11898-1, to provide the time-triggered communication schedule.

ISO 11898-5:2007 specifies the CAN physical layer for transmission rates up to 1 Mbit/s for use within road vehicles. It describes the medium access unit functions as well as some medium dependent interface features according to ISO 8802-2. This represents an extension of ISO 11898-2, dealing with new functionality for systems requiring low-power consumption features while there is no active bus communication.

ISO 11898-6:2013 specifies the CAN physical layer for transmission rates up to 1 Mbit/s for use within road vehicles. It describes the medium access unit functions as well as some medium dependent interface features according to ISO 8802-2. This represents an extension of ISO 11898-2 and ISO 11898-5, specifying a selective wake-up mechanism using configurable CAN frames.

ISO 16845-1:2016 provides the methodology and abstract test suite necessary for checking the conformance of any CAN implementation of the CAN specified in ISO 11898-1.

ISO 16845-2:2018 establishes test cases and test requirements to realize a test plan verifying if the CAN transceiver with implemented selective wake-up functions conform to the specified functionalities. The kind of testing defined in ISO 16845-2:2018 is named as conformance testing.

CAN-based higher-layer protocols[edit]

As the CAN standard does not include common communication features, such as flow control, device addressing, and transportation of data blocks larger than one message, and above all, application data, many implementations of higher layer protocols were created. Several are standardized for a business area, although all can be extended by each manufacturer. For passenger cars, each manufacturer has its own standard.

CAN in Automation (CiA) is the international users’ and manufacturers’ organization that develops and supports CAN-based higher-layer protocols and their international standardization.^[19] Among these specifications are:

Standardized approaches[edit]

ARINC 812 or ARINC 825 (aviation industry)
CANopen — CiA 301/302-2 and EN 50325-4 (industrial automation)
IEC 61375-3-3 (use of CANopen in rail vehicles)
DeviceNet (industrial automation)
EnergyBus — CiA 454 and IEC 61851-3 (battery–charger communication)
ISOBUS — ISO 11783 (agriculture)
ISO-TP — ISO 15765-2 (transport protocol for automotive diagnostics)
MilCAN (military vehicles)
NMEA 2000 — IEC 61162-3 (marine industry)
SAE J1939 (in-vehicle network for buses and trucks)
SAE J2284 (in-vehicle networks for passenger cars)
Unified Diagnostic Services (UDS) — ISO 14229 (automotive diagnostics)
LeisureCAN — open standard for the leisure craft/vehicle industry

Other approaches[edit]

CANaerospace — Stock (for the aviation industry)
CAN Kingdom — Kvaser (embedded control system)
CCP/XCP (automotive ECU calibration)
GMLAN — General Motors (for General Motors)
RV-C — RVIA (used for recreational vehicles)
SafetyBUS p — Pilz (used for industrial automation)
UAVCAN (aerospace and robotics)
CSP (CubeSat Space Protocol)
VSCP (Very Simple Control Protocol) a free automation protocol suitable for all sorts of automation tasks

CANopen Lift[edit]

The CANopen Special Interest Group (SIG) «Lift Control», which was founded in 2001, develops the CANopen application profile CiA 417 for lift control systems. It works on extending the features, improves technical content and ensures that the current legal standards for lift control systems are met. The first version of CiA 417 was published (available for CiA members) in summer 2003, version 2.0 in February 2010, version 2.1.0 in July 2012, version 2.2.0 in December 2015, and version 2.3.1 in February 2020.

Jörg Hellmich (ELFIN GmbH) is the chairman of this SIG and manages a wiki of the CANopen lift community with content about CANopen lift.

Security[edit]

CAN is a low-level protocol and does not support any security features intrinsically. There is also no encryption in standard CAN implementations, which leaves these networks open to man-in-the-middle frame interception. In most implementations, applications are expected to deploy their own security mechanisms; e.g., to authenticate incoming commands or the presence of certain devices on the network. Failure to implement adequate security measures may result in various sorts of attacks if the opponent manages to insert messages on the bus.^[20] While passwords exist for some safety-critical functions, such as modifying firmware, programming keys, or controlling antilock brake actuators, these systems are not implemented universally and have a limited number of seed/key pairs.

Development tools[edit]

When developing or troubleshooting the CAN bus, examination of hardware signals can be very important. Logic analyzers and bus analyzers are tools which collect, analyse, decode and store signals so people can view the high-speed waveforms at their leisure. There are also specialist tools as well as CAN bus monitors.

A CAN bus monitor is an analysis tool, often a combination of hardware and software, used during development of hardware which uses the CAN bus.

Typically the CAN bus monitor will listen to the traffic on the CAN bus in order to display it in a user interface. Often the CAN bus monitor offers the possibility to simulate CAN bus activity by sending CAN frames to the bus. The CAN bus monitor can therefore be used to validate expected CAN traffic from a given device or to simulate CAN traffic in order to validate the reaction from a given device connected to the CAN bus.

Licensing[edit]

Bosch holds patents on the technology, though those related to the original protocol have now expired. Manufacturers of CAN-compatible microprocessors pay license fees to Bosch for use of the CAN trademark and any of the newer patents related to CAN FD, and these are normally passed on to the customer in the price of the chip. Manufacturers of products with custom ASICs or FPGAs containing CAN-compatible modules need to pay a fee for the CAN Protocol License if they wish to use the CAN trademark or CAN FD capabilities.^[21]

References[edit]

^ ^a ^b «CAN History». CAN in Automation.
^ «Mercedes-Benz S-Class W 140». mercedes-benz.com. 23 February 2016. Retrieved 27 October 2017.
^ «CAN in Automation — Mercedes W140: First car with CAN». can-newsletter.org. Retrieved 27 October 2017.
^ «Bosch Semiconductor CAN Literature». Archived from the original on 2017-05-23. Retrieved 2017-05-31.
^ de Andrade, R.; Hodel, K. N.; Justo, J. F.; Laganá, A. M.; Santos, M. M.; Gu, Z. (2018). «Analytical and Experimental Performance Evaluations of CAN-FD Bus». IEEE Access. 6: 21287–21295. doi:10.1109/ACCESS.2018.2826522.
^ Building Adapter for Vehicle On-board Diagnostic Archived 2018-05-14 at the Wayback Machine, obddiag.net, accessed 2009-09-09
^ Comparison of Event-Triggered and Time-Triggered Concepts with Regard to Distributed Control Systems A. Albert, Robert Bosch GmbH Embedded World, 2004, Nürnberg
^ «NISMO Increases GT6 GPS Data Logger Functionality and Track Count». www.gtplanet.net. 25 October 2014.
^ «What is DiveCAN and why should I care?». 22 March 2016.
^ «ISO11783 a Standardized Tractor – Implement Interface» (PDF).
^ ISO 11898-1:2015 – Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling.
^
Daigmorte, Hugo; Boyer, Marc (2017), «Evaluation of admissible CAN bus load with weak synchronization mechanism», Proc. of the 24th Int. Conf. on Real-Time Networks and Systems (RTNS 2017), Grenoble, France: ACM
^ «Understanding Microchip’s CAN Module Bit Timing» (PDF).
^ «ISO7637-3 diodes protection for CAN bus».
^ «CAN bus ESD protection».
^ «CAN BUS MESSAGE FRAMES – Overload Frame, Interframe Space». 18 November 2009.
^ «Controller Area Network (CAN)». Vector Group. Archived from the original on 25 April 2016. Retrieved 25 Sep 2013.
^ «ISO 11898-1:2003 — Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling». ISO.
^ CiA: International standardization.
^ «We Drove a Car While It Was Being Hacked». www.vice.com. Archived from the original on 8 November 2019.
^ «License Conditions CAN Protocol and CAN FD Protocol» (PDF). Archived from the original (PDF) on 2016-03-16. Retrieved 2016-03-15.

External links[edit]

Specifications

ISO 11898-1 Standard (2015) — includes CAN and CAN-FD specifications
Bosch CAN Specification Version 2.0 (1991, 1997) — also known as «Classical CAN» and «CAN-Classic»
Bosch CAN-FD Specification Version 1.0 (2012) — increase data rates up to 8 Mbit/s
Bosch CAN-XL (future) — increase data rates up to 20 Mbit/s
Bosch CAN-FD-Light (future) — cost-optimized subset of CAN-FD

Other

Controller Area Network (CAN) Schedulability Analysis: Refuted, Revisited and Revised
Pinouts for common CAN bus connectors
A webpage about CAN in automotive
Controller Area Network (CAN) Schedulability Analysis with FIFO Queues
Controller Area Network (CAN) Implementation Guide
Freeware Bit-Timing calculator for Windows, supports a lot of microcontrollers, e.g. Atmel, STM32, Microchip, Renesas, … (ZIPfile)
Free e-learning module «Introduction to CAN»
ARINC-825 Tutorial (video) from Excalibur Systems Inc.
Website of CiA
CAN Newsletter Online
Understanding and Using the Controller Area Network from UC Berkeley
CAN Protocol Tutorial
ESD protection for CAN bus and CAN FD

Источник

Вернуться к статьям

По материалам компании Kvaser

Эта статья не претендует на полноту и абсолютную точность сведений, указанных в ней, и предназначена для ознакомления с протоколом CAN.

Содержание статьи

• Шина CAN – Введение.

• Сообщения CAN.

• Физические уровни CAN.

• Разъемы CAN.

• Тактовая синхронизация CAN.

• Обработка ошибок CAN.

Шина CAN – Введение

Протокол CAN является стандартом ISO (ISO 11898) в области последовательной передачи данных. Протокол был разработан с прицелом на использование в транспортных приложениях. Сегодня CAN получил широкое распространение и используется в системах автоматизации промышленного производства, а также на транспорте.

Стандарт CAN состоит из физического уровня и уровня передачи данных, определяющего несколько различных типов сообщений, правила разрешения конфликтов при доступе к шине и защиту от сбоев.

Протокол CAN

Протокол CAN описан в стандарте ISO 11898–1 и может быть кратко охарактеризован следующим образом:

• физический уровень использует дифференциальную передачу данных по витой паре;

• для управления доступом к шине используется неразрушающее bit–wise разрешение конфликтов;

• сообщения имеют малые размеры (по большей части 8 байт данных) и защищены контрольной суммой;

• в сообщениях отсутствуют явные адреса, вместо этого каждое сообщение содержит числовое значение, которое управляет его очередностью на шине, а также может служить идентификатором содержимого сообщения;

• продуманная схема обработки ошибок, обеспечивающая повторную передачу сообщений, если они не были получены должным образом;
• имеются эффективные средства для изоляции сбоев и удаления сбойных узлов с шины.

Протоколы более высоких уровней

Сам по себе протокол CAN определяет всего лишь, как малые пакеты данных можно безопасно переместить из точки A в точку B посредством коммуникационной среды. Он, как и следовало ожидать, ничего не говорит о том, как управлять потоком; передавать большое количество данных, нежели помещается в 8–байтное сообщение; ни об адресах узлов; установлении соединения и т.п. Эти пункты определяются протоколом более высокого уровня (Higher Layer Protocol, HLP). Термин HLP происходит из модели OSI и её семи уровней.

Протоколы более высокого уровня используются для:

• стандартизации процедуры запуска, включая выбор скорости передачи данных;

• распределения адресов среди взаимодействующих узлов или типов сообщений;

• определения разметки сообщений;
• обеспечения порядка обработки ошибок на уровне системы.

Пользовательские группы и т.п.

Одним из наиболее эффективных способов повышения вашей компетентности в области CAN является участие в работе, осуществляемой в рамках существующих пользовательских групп. Даже если вы не планируете активно участвовать в работе, пользовательские группы могут являться хорошим источником информации. Посещение конференций является ещё одним хорошим способом получения исчерпывающей и точной информации.

• Пользовательские группы и прочее из области CAN >>

Продукты CAN

На низком уровне принципиально различают два типа продуктов CAN, доступных на открытом рынке – микросхемы CAN и инструменты разработки CAN. На более высоком уровне – другие два типа продуктов: модули CAN и инструменты проектирования CAN. Широкий спектр данных продуктов доступен на открытом рынке в настоящее время.

• Ознакомьтесь с нашим перечнем продуктов CAN >>

Патенты в области CAN

Патенты, относящиеся к приложениям CAN, могут быть различных типов: реализация синхронизации и частот, передача больших наборов данных (в протоколе CAN используются кадры данных длиной всего лишь 8 байт) и т.п.

Системы распределённого управления

Протокол CAN является хорошей основой для разработки систем распределённого управления. Метод разрешения конфликтов, используемый CAN, обеспечивает то, что каждый узел CAN будет взаимодействовать с теми сообщениями, которые относятся к данному узлу.

Систему распределённого управления можно описать как систему, вычислительная мощность которой распределена между всеми узлами системы. Противоположный вариант – система с центральным процессором и локальными точками ввода–вывода.

Сообщения CAN

Шина CAN относится к широковещательным шинам. Это означает, что все узлы могут «слушать» все передачи. Не существует возможности послать сообщение конкретному узлу, все без исключения узлы будут принимать все сообщения. Оборудование CAN, однако, обеспечивает возможность локальной фильтрации, так что каждый модуль может реагировать только на интересующее его сообщение.

Адресация сообщений CAN

CAN использует относительно короткие сообщения – максимальная длина информационного поля составляет 94 бита. В сообщениях отсутствует явный адрес, их можно назвать контентно–адрессованными: содержимое сообщения имплицитно (неявным образом) определяет адресата.

Типы сообщений

Существует 4 типа сообщений (или кадров), передающихся по шине CAN:

• кадр данных (Data Frame);

• удаленный кадр (Remote Frame);

• кадр ошибки (Error Frame);

• кадр перегрузки (Overload Frame).

Кадр данных

Кратко: «Всем привет, есть данные с маркировкой X, надеюсь вам понравятся!»
Кадр данных – самый распространенный тип сообщения. Он содержит в себе следующие основные части (некоторые детали не рассматриваются для краткости):

• Поле арбитража (Arbitration Field), которое определяет очередность сообщения в том случае, когда за шину борятся два или более узла. Поле арбитража содержит:

• В случае CAN 2.0A, 11–битный идентификатор и один бит, бит RTR который является определяющим для кадров данных.

• В случае CAN 2.0B, 29–битный идентификатор (который также содержит два рецессивных бита: SRR и IDE) и бит RTR.

• Поле данных (Data Field), которое содержит от 0 до 8 байт данных.

• Поле CRC (CRC Field), содержащее 15–битную контрольную сумму, посчитанную для большинства частей сообщения. Эта контрольная сумма используется для обнаружения ошибок.

• Слот распознавания (Acknowledgement Slot). Каждый контроллер CAN, способный корректно получить сообщение, посылает бит распознавания (Acknowledgement bit) в конце каждого сообщения. Приемопередатчик проверяет наличие бита распознавания и, если таковой не обнаруживается, высылает сообщение повторно.

Примечание 1: Присутствие на шине бита распознавания не значит ничего, кроме того, что каждый запланированный адресат получил сообщение. Единственное, что становится известно, это факт корректного получения сообщения одним или несколькими узлами шины.

Примечание 2: Идентификатор в поле арбитража, несмотря на свое название, необязательно идентифицирует содержимое сообщения.

Кадр данных CAN 2.0B («cтандартный CAN»).

Кадр данных CAN 2.0B («расширенный CAN»).

Удаленный кадр

Кратко: «Всем привет, кто–нибудь может произвести данные с маркировкой X?»
Удаленный кадр очень похож на кадр данных, но с двумя важными отличиями:

• он явно помечен как удаленный кадр (бит RTR в поле арбитража является рецессивным), и

• отсутствует поле данных.

Основной задачей удаленного кадра является запрос на передачу надлежащего кадра данных. Если, скажем, узел A пересылает удаленный кадр с параметром поля арбитража равным 234, то узел B, если он должным образом инициализирован, должен выслать в ответ кадр данных с параметром поля арбитража также равным 234.

Удаленные кадры можно использовать для реализации управления трафиком шины типа «запрос–ответ». На практике, однако, удаленный кадр используется мало. Это не так важно, поскольку стандарт CAN не предписывает действовать именно так, как здесь обозначено. Большинство контроллеров CAN можно запрограммировать так, что они будут автоматически отвечать на удаленный кадр, или же вместо этого извещать локальный процессор.

Есть одна уловка, связанная с удаленным кадром: код длины данных (Data Length Code) должен быть установлен длине ожидаемого ответного сообщения. В противном случае разрешение конфликтов работать не будет.

Иногда требуется чтобы узел, отвечающий на удаленный кадр, начинал свою передачу как только распознавал идентификатор, таким образом «заполняя» пустой удаленный кадр. Это другой случай.

Кадр ошибки (Error Frame)

Кратко (все вместе, громко): «О, ДОРОГОЙ, ДАВАЙ ПОПРОБУЕМ ЕЩЁ РАЗОК»
Кадр ошибки (Error Frame) – это специальное сообщение, нарушающее правила формирования кадров сообщения CAN. Он посылается, когда узел обнаруживает сбой и помогает остальным узлам обнаружить сбой – и они тоже будут отправлять кадры ошибок. Передатчик автоматически попробует послать сообщение повторно. Наличествует продуманная схема счетчиков ошибок, гарантирующая, что узел не сможет нарушить передачу данных по шине путём повторяющейся отсылки кадров ошибки.

Кадр ошибки содержит флаг ошибки (Error Flag), который состоит из 6 бит одинакового значения (таким образом нарушая правило вставки битов) и разграничителя ошибки (Error Delimiter), состоящего из 8 рецессивных бит. Разраничитель ошибки предоставляет некоторое пространство, в котором другие узлы шины могут отправлять свои флаги ошибки после того, как сами обнаружат первый флаг ошибки.

Вот флаг ошибки:

Кадр перегрузки (Overload Frame)

Кратко: «Я очень занятой 82526 маленький, не могли бы вы подождать минуточку?»
Кадр перегрузки упоминается здесь лишь для полноты картины. По формату он очень похож на кадр ошибки и передается занятым узлом. Кадр перегрузки используется нечасто, т.к. современные контроллеры CAN достаточно производительны, чтобы его не использовать. Фактически, единственный контроллер, который будет генерировать кадры перегрузки – это ныне устаревший 82526.

Стандартный и расширенный CAN

Изначально стандарт CAN установил длину идентификатора в поле арбитража равной 11 битам. Позже, по требованию покупателей стандарт был расширен. Новый формат часто называют расширенным CAN (Extended CAN), он позволяет использовать не менее 29 бит в идентификаторе. Для различения двух типов кадров используется зарезервированный бит в поле управления Control Field.

Формально стандарты именуются следующим образом –

• 2.0A – только с 11–битными идентификаторами;
• 2.0B – расширенная версия с 29–битными или 11–битными идентификаторами (их можно смешивать). Узел 2.0B может быть

• 2.0B active (активным), т.е. способным передавать и получать расширенные кадры, или

• 2.0B passive (пассивным), т.е. он будет молча сбрасывать полученные расширенные кадры (но, смотрите ниже).

• 1.x – относится к оргинальной спецификации и её ревизиям.

В настоящее время новые контроллеры CAN обычно относятся к типу 2.0B. Контроллер типа 1.x или 2.0A прибудет в замешательство, получив сообщения с 29 битами арбитража. Контроллер 2.0B пассивного типа примет их, опознает, если они верны и, затем – сбросит; a контроллер 2.0B активного типа сможет и передавать, и получать такие сообщения.

Контроллеры 2.0B и 2.0A (равно, как и 1.x) совместимы. Можно использовать их все на одной шине до тех пор, пока контроллеры 2.0B будут воздерживаться от рассылки расширенных кадров.

Иногда люди заявляют, что стандартный CAN «лучше» расширенного CAN, потому что в сообщениях расширенного CAN больше служебных данных. Это необязательно так. Если вы используете поле арбитража для передачи данных, то кадр расширенного CAN может содержать меньше служебных данных, чем кадр стандартного CAN.

Основной CAN (Basic CAN) и полный CAN (Full CAN)

Термины Basic CAN и Full CAN берут начало в «детстве» CAN. Когда–то существовал CAN–контроллер Intel 82526, предоставлявший программисту интерфейс в стиле DPRAM. Потом появился Philips с моделью 82C200, в котором применялась FIFO–ориентированная модель программирования и ограниченные возможности фильтрации. Для обозначения различия между двумя моделями программирования, люди стали называть способ Intel – Full CAN, а способ Philips – Basic CAN. Сегодня большинство контроллеров CAN поддерживают обе модели программирования, поэтому нет смысла в использовании терминов Full CAN и Basic CAN – фактически, эти термины могут вызвать неразбериху и стоит воздержаться от их употребления.

В действительности, контроллер Full CAN может взаимодействовать с контроллером Basic CAN и наоборот. Проблемы с совместимостью отсутствуют.

Разрешение конфликтов на шине и приоритет сообщения

Разрешение конфликтов сообщений (процесс, в результате которого два или более контроллера CAN решают, кто будет пользоваться шиной) очень важно для определения реальной доступности полосы пропускания для передачи данных.

Любой контроллер CAN может начать передачу, когда обнаружит, что шина простаивает. Это может привести к тому, что два или более контроллеров начнут передачу сообщения (почти) одновременно. Конфликт решается следующим образом. Передающие узлы осуществляют мониторинг шины в процессе отправки сообщения. Если узел обнаруживает доминантный уровень в то время, как сам он отправляет рецессивный уровень, он незамедлительно устранится от процесса разрешения конфликта и станет приемником. Разрешение конфликтов осуществляется по всему полю арбитража, и после того, как это поле отсылается, на шине остается только один передатчик. Данный узел продолжит передачу, если ничего не случится. Остальные потенциальные передатчики попытаются передать свои сообщения позже, когда шина освободится. В процессе разрешения конфликта время не теряется.

Важным условием для благополучного разрешения конфликта является невозможность ситуации, при которой два узла могут передать одинаковое поле арбитража. Из этого правила есть одно исключение: если сообщение не содержит данных, то любой узел может передавать это сообщение.

Поскольку, CAN–шина является шиной с подсоединением устройств по типу «монтажное И» (wired–AND) и доминантный бит (Dominant bit) является логическим 0, следовательно сообщение с самым низким в численном выражении полем арбитража выиграет в разрешении конфликта.

Вопрос: Что произойдет в случае, если единственный узел шины попытается отослать сообщение?

Ответ: Узел, разумеется, выиграет в разрешении конфликта и успешно проведет передачу сообщения. Но когда наступит время распознавания… ни один узел не отправит доминантный бит области распознавания, поэтому передатчик определит ошибку распознавания, пошлет флаг ошибки, повысит значение своего счетчика ошибок передачи на 8 и начнет повторную передачу. Этот цикл повторится 16 раз, затем передатчик перейдет в статус пассивной ошибки. В соответствии со специальным правилом в алгоритме ограничения ошибок, значение счетчика ошибок передачи не будет более повышаться, если узел имеет статус пассивной ошибки и ошибка является ошибкой распознавания. Поэтому узел будет осуществлять передачу вечно, до тех пор, пока кто–нибудь не распознает сообщение.

Адресация и идентификация сообщения

Повторимся, нет ничего страшного в том, что в сообщениях CAN нет точных адресов. Каждый контроллер CAN будет получать весь траффик шины, и при помощи комбинации аппаратных фильтров и ПО, определять – «интересует» его это сообщение, или нет.

Фактически, в протоколе CAN отсутствует понятие адреса сообщения. Вместо этого содержимое сообщения определяется идентификатором, который находится где–то в сообщении. Сообщения CAN можно назвать «контентно–адрессовнными».

Определённый адрес работает так: «Это сообщение для узла X». Контентно–адресованное сообщение можно описать так: «Это сообщение содержит данные с маркировкой X». Разница между этими двумя концепциями мала, но существенна.

Содержимое поле арбитража используется, в соответствии со стандартом, для определения очередности сообщения на шине. Все контроллеры CAN будут также использовать всё (некоторые – только часть) поле арбитража в качестве ключа в процессе аппаратной фильтрации.

Стандарт не говорит, что поле арбитража непременно должно использоваться в качестве идентификатора сообщения. Тем не менее, это очень распространенный вариант использования.

Примечание о значениях идентификатора

Мы говорили, что идентификатору доступны 11 (CAN 2.0A) или 29 (CAN 2.0B) бит. Это не совсем верно. Для совместимости с определенным старым контроллером CAN (угадайте каким?), идентификаторы не должны иметь 7 старших бит установленных в логическую единицу, поэтому 11–битным идентификаторам доступны значения 0..2031, а пользователи 29–битных идентификаторов могут использовать 532676608 различных значений.

Заметьте, что все остальные контроллеры CAN принимают «неправильные» идентификаторы, поэтому в современных системах CAN идентификаторы 2032..2047 могут использоваться без ограничений.

Физические уровни CAN

Шина CAN

Шина CAN использует код без возвращения к нулю (NRZ) с вставкой битов. Существуют два разных состояния сигнала: доминантное (логический 0) и рецессивное (логическая 1). Они соответствуют определенным электрическим уровням, зависящим от используемого физического уровня (их несколько). Модули подключены к шине по схеме «монтажное И» (wired–AND): если хотя бы один узел переводит шину в доминантное состояние, то вся шина находится в этом состоянии, вне зависмости от того, сколько узлов передают рецессивное состояние.

Различные физические уровни

Физический уровень определяет электрические уровни и схему передачи сигналов по шине, полное сопротивление кабеля и т.п.

Существует несколько различных версий физических уровней: • Наиболее распространенным является вариант, определенный стандартом CAN, часть ISO 11898–2, и представляющий собой двухпроводную сбалансированную сигнальную схему. Он также иногда называется high–speed CAN.

• Другая часть того же стандарта ISO 11898–3 описывает другую двухпроводную сбалансированную сигнальную схему – для менее скоростной шины. Она устойчива к сбоям, поэтому передача сигналов может продолжаться даже в том случае, когда один из проводов будет перерезан, замкнут на «землю» или в состоянии Vbat. Иногда такая схема называется low–speed CAN.

• SAE J2411 описывает однопроводной (плюс «земля», разумеется) физический уровень. Он используется в основном в автомобилях – например GM–LAN.

• Существуют несколько проприетарных физических уровней.

• В былые времена, когда драйверов CAN не существовало, использовались модификации RS485.

• Несколько изображений с осциллографа поясняющие сообщения в деталях >>.

Различные физические уровни как правило не могут взаимодействовать между собой. Некоторые комбинации могут работать (или будет казаться, что они работают) в хороших условиях. Например, приемопередатчики high–speed и low–speed могут работать на одной шине лишь иногда.

Абсолютное большинство микросхем приемопередатчиков CAN произведено компанией Philips; в число других производителей входят Bosch, Infineon, Siliconix и Unitrode.

Наиболее распространен приемопередатчик 82C250, в котором реализован физический уровень, описываемый стандартом ISO 11898. Усовершенствованная версия – 82C251.

Распространенный приемопередатчик для «low–speed CAN» – Philips TJA1054.

Максимальная скорость передачи данных по шине

Максимальная скорость передачи данных по шине CAN, в соответствии со стандартом, равна 1 Мбит/с. Однако некоторые контроллеры CAN поддерживают скорости выше 1 Мбит/с и могут быть использованы в специализированных приложениях.

Low–speed CAN (ISO 11898–3, см. выше) работает на скоростях до 125 кбит/с.

Однопроводная шина CAN в стандартном режиме может передавать данные со скоростью порядка 50 кбит/с, а в специальном высокоскоростном режиме, например для программирования ЭБУ (ECU), около 100 кбит/с.

Минимальная скорость передачи данных по шине

Имейте в виду, что некоторые приемопередатчики не позволят вам выбрать скорость ниже определенного значения. Например, при использовании 82C250 или 82C251 вы можете без проблем установить скорость 10 кбит/с, но если вы используете TJA1050, то не сможете установить скорость ниже 50 кбит/с. Сверяйтесь со спецификацией.

Максимальная длина кабеля

При скорости передачи данных 1 Мбит/с, максимальная длина используемого кабеля может составлять порядка 40 метров. Это связано с требованием схемы разрешения конфликтов, согласно которому фронт волны сигнала должен иметь возможность дойти до самого дальнего узла и вернуться назад прежде чем бит будет считан. Иными словами, длина кабеля ограничена скоростью света. Предложения по увеличению скорости света рассматривались, но были отвергнуты в связи с межгалактическими проблемами.

Другие максимальные длины кабеля (значения приблизительные):

• 100 метров при 500 кбит/с;

• 200 метров при 250 кбит/с;

• 500 метров при 125 кбит/с;
• 6 километров при 10 кбит/с.

Если для обеспечения гальванической изоляции используются оптопары, максимальная длина шины соответственно сокращается. Совет: используйте быстрые оптопары, и смотрите на задержку сигнала в устройстве, а не на максимальную скорость передачи данных в спецификации.

Оконечное прерывание шины

Шина CAN стандарта ISO 11898 должна заканчиваться терминатором. Это достигается путем установки резистора сопротивлением 120 Ом на каждом конце шины. Терминирование служит двум целям:

1. Убрать отражения сигнала на конце шины.

2. Убедиться, что получает корректные уровни постоянного тока (DC).

Шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Я повторю: шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Для лабораторной работы может хватить и одного терминатора. Если ваша шина CAN работает даже при отсутствии терминаторов – вы просто счастливчик.

Заметьте, что другие физические уровни, такие как low–speed CAN, однопроводная шина CAN и другие, могут требовать, а могут и не требовать наличия оконечного терминатора шины. Но ваша высокоскоростная шина CAN стандарта ISO 11898 всегда будет требовать наличия хотя бы одного терминатора.

Кабель

Стандарт ISO 11898 предписывает, что волновое сопротивление кабеля номинально должно равнятся 120 Ом, однако допускается интервал значений сопротивления [108..132] Ом.

Немногие, из присутствующих сегодня на рынке, кабели удовлетворяют этим требованиям. Есть большая вероятность, что интервал значений сопротивления будет расширен в будущем.

ISO 11898 описывает витую пару, экранированную или неэкранированную. Идёт работа над стандартом однопроводного кабеля SAE J2411.

Продолжение статьи читать во II части .

Источник

Now when we have studied CAN bus protocol and its functioning, it would be easy to understand how it faces errors and deals with them. Of course, no system is an ideal system. Errors are always bound to happen, but a sound system will always know how to detect the Error, omit it and resend the rectified data. CAN bus in similar manner experiences such errors but fights them effectively.

Before we begin let’s understand the Data frame of the CAN bus:

A more detailed version of the Standard CAN data frame helps one understand how error bits are located and worked upon. Here the placement of Delimiter bits has been specified.

Delimiter Bit: these are recessive bits that usually serve to provide time/space for completing a particular action. These bits ensure that there are bit transitions in the fields that do not have bit-stuffing applied. The bit transitions are necessary to recover timing synchronization that might not be otherwise available due to NRZ encoding. Other than providing the time for synchronization, the delimiter serves a specific purpose in Error Detection. The delimiter bits must come at a predefined place so that the form of the CAN frame is maintained.

CRC Delimiter: a CRC delimiter bit gives time or space to the ECU to calculate the CRC.

ACK Delimiter: once the data is received, the receiving end sends an acknowledgement to the transmitting node, and it requires some time, and hence ACK delimiter is used.

Bit Stuffing: after transmitting five consecutive bits of the same level by a node, it adds a sixth bit of the opposite level to the outgoing bitstream. The receiver removes this extra bit. This not only avoids excessive DC components on the Bus but also enables receivers to detect errors. Since this is a general rule, the receiver doesn’t need extra information about the location of the stuffing bits to do the de-stuffing. Bit stuffing does not ensure that transmission errors do not corrupt the data; it ensures that the transmission starts and ends at the correct places.

CAN Bus Errors

Namely, five different types of errors may affect the transmission of bits over a CAN bus.

Bit Error: When the bit received is not the same as the bit transmitted. Every node that receives the data reads it bit-by-bit from the Bus and compares the transmitted bit value with the received. If the bit transmitted and the bit received are not of the same value, a «bit error» occurs.

Stuff Error: Following the bit stuffing process, if more than five consecutive bits of the same level occur on the Bus, a «Stuff Error» is signalled.

Form Error: this refers to the fixed form of the field. Form check checks the CAN frame sent/received for a standard format. Violation of fixed bit format results in a Form Error. E.g. CRCD, ACKD, EOF have to be recessive bits, and the presence of any dominant bit will automatically be treated as a Form Error. Also, delimiter bits must come at a predefined place so that the form of the CAN frame is maintained; if the receiver fails to find delimiter bits at a proper place, this also generates a Form Error Frame. In this case, the fixed forms of the fields will have to be retransmitted.

CRC Error: The transmitting node send a 15 bit CRC value onto the Bus. The receiving node then calculates a 15-bit number based on the payload it receives on its own. Then it compares it to the CRC delimiter it received as part of the message. If the received CRC does not match with the calculated code, the receiver knows that the 8 bytes of the payload were corrupted or modified during transmission, known as CRC Error.

ACK Error: The ACK bit is a defined recessive «1» (transmitted by the transmitter node), and the reply from the receiver is a defined dominant «0». But, if that is not the case and the transmitter does not receive a dominant acknowledgement bit in reply, it is termed ACK Error.

Below is the ASAM standard table for CAN error:

Error Frame Format

When a node detects an error in a message, a special message known as an «error frame» is transmitted. This special message violates the formatting rules of a CAN message and causes all other nodes (connected on the network) to send an error frame as well. This intentional violation of the CAN standard (i.e. the sending of 6 dominant bits) guarantees the destruction of a faulty data or remote frame. Thus, enabling the original transmitter to retransmit the message automatically.

Error Frame consists of «6» dominant or recessive bits, depending upon the error state of the node which transmits it. It is transmitted by the node/s that detect/s any communication error, resulting in an immediate termination of transmission, and is retransmitted later. Again, this is all controlled by a controller, not application software.

Error Flag: Every CAN controller along a bus tries to detect errors within a message as error handling is built into the CAN protocol. Every CAN controller along a bus will try to detect errors within a message. If an error is found, the discovering node transmits an Error Flag, thus destroying the bus traffic. Using the error counters, a CAN node can detect faults and perform error confinement.

Error States of CAN Bus

Depending on the specific error count, a CAN controller handles the switching of the error state.

Error Active

A node starts in Error Active mode. CAN controller assumes the normal state Error Active. In this state, the CAN controller sends six dominant bits after detecting an error. When the limit is below TEC[NM1] (Transmit Error Counter) <127 and REC (Receive Error Counter) <127, an Error Active node will transmit Active Error Flags when it detects errors.

Error Passive

The Error Passive state indicates a detected error by sending six homogeneous recessive bits only. This prevents the error-detecting receivers from globalizing detected errors. When any one of the two Error Counters raises above 127(TEC>127 and REC>127), the node will enter a state known as Error Passive.

In addition, when sending two consecutive data or remote frames, CAN controllers that are in the «Error Passive» state must wait the «Suspend Transmission Time» (8 bits). An Error Passive node will transmit Passive Error Flags when it detects errors.

Bus Off

When the Transmit Error Counter raises above 255(TEC>255 and REC>255), the node will enter the Bus Off state. It happens when the CAN controller fails or at times of extreme accumulations of errors. In this case, the CAN controller disconnects itself from the CAN bus. As a result, that particular CAN node will get switched off from the CAN network; Resulting in no communication at all.

«Influx data loggers’ supports CAN error Logging in ASAM standard format.» It makes sure that your data log is checked for these errors and quality data is delivered. Your data is essential. The CAN error logging functionality on Influx Devices is tested and benchmarked with other industry-leading CAN devices. For more information about our products, Click here.

Was this article helpful?Don’t love itNot greatGoodReally goodLove itWas this article helpful?

Your content has been submitted

Источник

Controller Area Network или, как более привычно звучит для автомобильной диагностики — CAN шина

* Что такое CAN?

* Взаимосвязь открытых систем (Open System Interconnection (OSI))

* Controller Area Network (CAN)

* Основные принципы CAN

* Как выглядит CAN шина на примере автомобилей произведённых в Японии

Парк автомобилей на наших улицах стремительно омолаживается и вместе с этим приходится осваивать и решать новые задачи связанные с диагностикой и ремонтом. Всё чаще и чаще сталкиваешься в своей повседневной работе с проблемами коммуникации между различными бортовыми системами автомобиля. Если ещё несколько лет назад приезжающие на диагностику автомобили с ошибками по CAN шине (первый символ в классификации диагностического кода неисправности — U) были редкими гостями, то сейчас это практически повседневная практика. Информация на эту тему в принципе доступна и её достаточно много, даже очень много — что с одной стороны хорошо, а с другой представляет собой определённую сложность в поиске необходимой информации. Этой статьёй хотелось бы в первую очередь дать общее представление о системе CAN (Controller Area Network) тем, кто только начинает с ней знакомство, и тем, кто желает в этом поглубже разобраться.

Что такое CAN?

Controller Area Network — это понятие вошло в обиход после того, как в начале 1980-х годов в Robert Bosch GmbH разработали стандарт промышленной сети, ориентированный прежде всего на объединение в единую сеть различных исполнительных устройств и датчиков. Одно их первых внедрений в автомобильной промышленности было осуществлено на нескольких моделях автомобилей Mercedes-Benz в 1992 году. До этого момента электронное управление исполнительными функциями строилось по системе — один блок управления принимал электронные сигналы с различных датчиков и после их обработки посылал соответствующие команды на исполнительные устройства (такие как бензонасос, форсунки, катушки зажигания и прочие…). Увеличение объёма функций управления автомобилем, передаваемое электронике, привело к появлению таких дополнительных систем как ABS, SRS, AT, Immobilaser и других… Совмещение этих функций в одном ЭБУ привело бы к его громоздкости и чрезмерной сложности, а так же к потере надёжности, когда выход из строя одной системы мог бы привести к потере управляемости всего автомобиля. Поэтому автопроизводители пошли по пути разделения функций управления и выделения всех систем в отдельные блоки. А для того, чтобы увязать все системы в единое целое для решения общих задач управления автомобилем, на помощь пришёл коммуникационный стандарт CAN от Robert Bosch GmbH и это всё шире и шире стало применяться в автомобилестроении. На сегодняшний день практически каждый новый автомобиль оснащён этой системой.

Всё в принципе просто и понятно, но как устроена CAN шина и на чём основывается принцип её работы? Вот один из примеров взаимосвязи электронных блоков управления и устройств завязанных в единую бортовую коммуникационную сеть автомобиля,- рис. 1

Здесь мы рассматриваем только блоки, связанные в проводную сеть, но в автомобилях 21 века находит всё большее применение и беспроводная передача информации. К примеру, система навигации, слежение за местонахождением автомобиля (защита от угона), контроль за давлением в шинах, удалённая диагностика и многие другие. В ближайшем будущем можно ожидать, что слияние воедино в бортовой сети автомобилей внутренних и внешних информационных потоков выведет управление транспортным средством на новый уровень безопасности и комфорта прежде всего в таких направлениях, как отображение информации предупреждения об опасных ситуациях на дорогах и даже активного смягчения последствий возможных столкновений автомобилей, а так же более рационального распределения транспортных потоков.

Немного предыстории — Взаимосвязь открытых систем (Open System Interconnection (OSI)).

Это очевидно, что если два или более микропроцессора взаимосвязаны в одну систему, то должен использоваться стандартный протокол который определяет, каким образом данные должны быть переданы между сетевыми блоками. Наиболее распространенным примером такого протокола является TCP/IP (Transmission Control Protocol / Internet Protocol), который используется для подключения хостингов в сети Интернет. Предшественником TCP/IP был протокол — Open System Interconnection (OSI). Этот протокол был разработан в 1982 году Международным бюро по стандартизации International Organization for Standardization (ISO 7498-1:1994 (E)). OSI протокол иногда называют как «семиуровневая» модель, поскольку он состоит из семи независимых элементов, которые определяют требования к взаимосвязи на различных уровнях взаимодействия.

Вот эти семь уровней:

1) Уровень приложений (Application Layer) — этот уровень определяет какие приложения (программы) имеют доступ к сети. Например — электронная почта, передача файлов, терминалы удалённого доступа и веб-браузеры.

2) Уровень представления данных (Presentation Layer) — этот уровень определяет такие моменты, как стандарты сжатия данных и их шифрования.

3) Уровень передачи данных (Transport Layer) — этот уровень обеспечивает стандарты передачи данных между адресатами, осуществляет контроль ошибок и безопасности.

4) Сетевой уровень (Network Layer) — этот уровень отвечает за вопросы маршрутизации сетевого трафика данных.

5) Уровень каналов связи (Data Link Layer) — этот уровень обеспечивает синхронизацию передачи данных и контроль ошибок.

6) Уровень контроля за сеансами связи (Session Layer) — этот уровень обеспечивает стандартизацию начала и завершения сеансов связи между различными приложениями и сетевыми блоками.

7) Физический уровень (Physical Layer) — этот уровень определяет стандарты физических характеристик устройств в сети, в том числе типы соединений и разъёмов, электрические характеристики кабелей, уровня напряжения, силы тока и тд.

Но задачи, решаемые протоколом OSI не в полной мере отвечали нуждам автомобильной электроники, и как следствие этого, инженерами Robert Bosch GmbH был разработан, в развитие протокола OSI, специальный протокол CAN, который определял стандарты физического и канального уровней модели OSI в кремнии для осуществления последовательной передачи информации между двумя или более устройствами.

Controller Area Network (CAN)

CAN был разработан Robert Bosch GmbH для автомобильной промышленности в начале 1980-х годов и официально публично выпущен в пользование в 1986 году. Эта разработка CAN от Bosch была принята в качестве стандарта ISO (ISO 11898), в 1993 переименована в CAN 2.0A, и расширена в 1995 году, чтобы позволить идентифицировать большее количество сетевых устройств в CAN 2.0B. Как правило, CAN шина соединяет в сеть модули (или узлы), используя два провода, витая пара. Многие компании и не только автомобильные, внедряют CAN протокол в свои разработки для взаимосвязи различных электронно-управляемых устройств. В неофициальной классификации устройства связанные протоколом CAN и имеющие процессоры серии MPC 5xx, называются TouCAN модули; имеющие процессоры серии MPC 55xx называются FlexCAN модули. CAN — последовательный, мульти-отправляющий, многоадресный протокол, это означает, что, когда шина свободна, любой узел, может отправить сообщение (мульти-отправляющее устройство), и все узлы могут получить и отреагировать на сообщение (многоадресно передано). Узел, который инициирует сообщение, называют передатчиком, любой узел не отправляющий сообщение называют получателем. Всем сообщениям присвоены статические приоритеты, передающий узел остаётся передатчиком до тех пор пока шина не станет неактивной или пока в сети не появилось сообщение от другого узла с более высоким приоритетом, процесс который определяет приоритет сообщений и называется — арбитраж. Сообщение по CAN шине может содержать до 8 байтов данных. Идентификатор сообщения описывает контент данных и используется получающими узлами для определения места назначения в сети (другими словами — адресата, узел которому это сообщение адресовано). В коротких сетях (≤ 40 м), скорость передачи сообщений может достигать до 1 Мбит/с. Более длинные сетевые расстояния уменьшают доступную скорость передачи, например до 125 Кбит/с в сети длиной до 500м. Высокоскоростной CAN (“High speed” CAN) сетью, считается сеть со скоростью передачи данных более 500 Кбит/с.

Основные принципы CAN

Детали спецификации CAN протокола полностью описаны в Robert Bosch GmbH, “CAN Speciﬁcation 2.0,” 1991. Ознакомиться с документом в формате PDF можно по следующему адресу. Далее я дам максимально возможно краткое описание того как данные передаются по CAN, как структурированы сообщения CAN и как обрабатываются ошибки передачи сообщений.

Есть четыре типа сообщений CAN, или фреймы (frames): фрейм данных (Data Frame), удаленный фрейм (Remote Frame), ошибочный фрейм (Error Frame) и фрейм перегрузки (Overload Frame).

Data Frame — стандартное сообщение CAN, широковещательно передаваемые данные от передатчика на другие узлы сети.

Remote Frame — широковещательно передаваемое передатчиком сообщение, на запрос данных от конкретного узла сети.

Error Frame — может быть передан любым узлом, который обнаруживает ошибку в сети.

Overload Frame — используются как запрос на предоставление дополнительной паузы между получаемыми данными (Data Frame) или запросами на получение данных (Remote Frame).

Ниже проиллюстрированы различия между Data Frames для стандартов CAN 2.0A и CAN 2.0B,- рис. 2

Различие между форматами CAN 2.0А и CAN 2.0B заключаются в том что фрейм данных для CAN 2.0B поддерживает как стандартный идентификатор фрейма данных — 11 бит, так и расширенный идентификатор фрейма данных — о 29 бит. Фреймы стандартного и расширенного формата могут без проблем передаваться по одной на той же шине, и даже иметь в цифровой форме эквивалентный идентификатор.

В этом случае у стандартного фрейма будет более высокий приоритет,- рис. 3

Описание фрейма сообщения стандарта CAN 2.0А

Начало сообщения (Start of Frame (SOF)) — 1 бит, должен быть доминантным.

Идентификатор (Identiﬁer) — 11 бит, уникальный идентификатор, указывает приоритет.

Удаленный запрос на передачу (Remote Transmission Request (RTR)) — 1 бит, доминантный в сообщении и рецессивный в запросе на передачу сообщения.

Резерв (Reserved) — 2 бита, должны быть доминантными.

Длина кода данных (Data Length Code (DLC)) — 4 бита, количество байтов данных (0-8).

Поле передаваемых данных (Data Field) — от 0 до 8 байт, размер определен в поле DLC.

Контрольный циклический избыточный код (Cyclic Redundancy Check (CRC)) — 15 бит.

Разделитель CRC — 1 бит, должен быть рецессивный.

Подтверждение (Acknowledge (ACK)) — 1 бит, передатчик отправляет рецессивный; получатель подтверждает доминантным.

Разделитель ACK — 1 бит, должен быть рецессивным.

Завершение сообщения (End of Frame (EOF)) — 7 бит, должны быть рецессивными,- рис. 4

Описание фрейма сообщения стандарта CAN 2.0В
Начало сообщения (Start of Frame (SOF)) — 1 бит, должен быть доминантным.

Идентификатор стандартного и расширенного форматов (Identiﬁer) — 11 бит, уникальный идентификатор, соответствует базовому ID в расширенном формате.

Идентификатор расширенного формата (Identiﬁer – Extended Format) — 29 бит, состоит из 11 бит базового ID и 18 бит расширенного ID.

Удаленный запрос на передачу (Remote Transmission Request (RTR)) стандартный и расширенный форматы — 1 бит, доминантный в сообщении и рецессивный в запросе на передачу сообщения. В стандартном формате 11 бит идентификатора следуют за битом RTR.

Замещение удалённого запроса (Substitute Remote Request (SRR)). Для расширенного формата — 1 бит, должен быть рецессивный. SRR передаются в расширенных форматах сообщений на позиции бита RTR в стандартном сообщении. В арбитраже между стандартными и расширенными сообщениями, рецессивные SRR обеспечивает приоритет стандартным сообщениям.

Поле IDE – для стандартного и расширенного форматов — 1 бит, должен быть рецессивным для расширенного формата и доминантным для стандартного.

Резерв (Reserved r0) для стандартного формата — 1 бит, должен быть доминантным.

Резерв (Reserved r1, r0) для расширенного формата — 2 бита, должны быть рецессивными.

Длина кода данных (Data Length Code (DLC)) — 4 бита, количество байтов данных (0-8).

Поле передаваемых данных (Data Field) — от 0 до 8 байт, размер определен в поле DLC.

Контрольный циклический избыточный код (Cyclic Redundancy Check (CRC)) — 15 бит.

Разделитель CRC — 1 бит, должен быть рецессивный.

Подтверждение (Acknowledge (ACK)) — 1 бит, передатчик отправляет рецессивный; получатель подтверждает доминантным.

Разделитель ACK — 1 бит, должен быть рецессивным.

Завершение сообщения (End of Frame (EOF)) — 7 бит, должны быть рецессивными.

Фрейм данных CAN

Фрейм данных CAN состоит из семи полей: Начало фрейма (SOF), арбитраж, управление, данные, цикличные, проверка по избыточности (CRC), подтверждение (ACK) и конец фрейма (EOF). Биты сообщения CAN обозначены как «доминирующие» (0) или «рецессивные» (1). Поле SOF состоит из одного доминирующего бита. Все сетевые узлы синхронно ожидают команды разрешения на передачу сообщений и начинают передавать одновременно. Арбитражная схема определяет, какой из узлов, пытающихся передавать сообщения имеет главный приоритет и фактически будет управлять шиной.

Арбитраж (Arbitration)

Арбитражное поле сообщения CAN состоит из 11-или 29-разрядного идентификатора и бита удаленной передачи (RTR). Арбитражную схему CAN называют “носителем контроля с множественным доступом и обнаружением коллизий” или CSMA/CD, которая гарантирует, что самое важное сообщение с наивысшим приоритетом будет передано по всей сети в первую очередь. Приоритет сообщения определен численным значением идентификатора в арбитражном поле, поле с самым низким численным значением имеет самый высокий приоритет. Неразрушающий, интеллектуальный арбитраж разрешает конфликты среди конкурирующих передатчиков. Это означает, что шина может считаться действующей как логический элемент И (AND gate). Если какой-либо узел пишет по сети доминантный признак (0), то каждый узел читает доминирующий бит независимо от его назначения, заданного передающим узлом. Каждый передающий узел всегда читает ответ на каждый переданный бит. Если узел передает рецессивный бит запроса на отправку сообщения и получает доминирующий бит для прочтения сообщения, он сразу же прекращает передавать.

Ниже проиллюстрирован приоритет сетевого арбитража где третий узел имеет высший приоритет и первый низший,- рис. 5

Бит RTR включён для того чтобы различать сообщения для передачи и удаленные запросы на приём сообщений. В стандартных сообщениях для передачи (Data Frame) бит RTR должен быть доминантным, а в удаленных запросах на приём сообщений (Remote Frame) должен быть быть рецессивным.

Контрольное поле и поле данных в сообщении (Control and Data Fields)

Поле управляющее длиной кода данных (DLC) состоит из 6 бит (из которых используются только 4 младших бита), они показывают количество данных в сообщении. Поскольку только до 8 байт данных может быть отправлено в одном сообщение, поле DLC может принимать значения в диапазоне от 000000 до 000111. Данные которые должны быть переданы содержатся только в поле данных. В первую очередь передается наиболее значимый байт (Most significant byte (MSB)) из байтов данных.

Обработка ошибок (Error Handling)

В протоколе CAN реализовано пять уровней обнаружения ошибок. На уровне сообщений, выполняется циклическая проверка избыточности (Cyclic Redundancy Check (CRC)), проверки сообщения и обязательное подтверждение проверок (Acknowledge (ACK)). Бит проверки уровней состоит из монитора и наполнения.

Циклические ошибки избыточности обнаруживаются, используя код CRC размером 15 битов, вычисленный передатчиком из контента сообщения. Каждый получатель, принимающий сообщение, повторно вычисляет код CRC и сравнивает его с переданным значением. Несоответствие между этими двумя вычислениями заставляет установить флаг (ﬂag) ошибки. Проверяемые сообщения, в которых будет установлен флаг ошибки, это обнаружение получателем недопустимого бита в разделителе CRC, разделителе ACK, в завершении сообщения EOF или в 3-х битном разделяющим сообщения пространстве. В конечном итоге каждый принимающий узел записывает доминантный бит в ячейку разделителя ACK, которая затем читается отправившим это сообщение узлом. И если приём сообщения получателем не подтверждён (возможно потому что получающий узел перестал работать) то устанавливается флаг ошибки подтверждения (ACK).

На уровне битов мы уже отметили, что каждый переданный бит считывается снова передатчиком этого сообщения при контроле подтверждения о получении сообщения, присланного получателем. Если контролируемое значение отличается от отправленного, значит на уровне битов обнаружена ошибка. Дополнительно, ошибки на уровне битов обнаруживаются при помощи «вставок»: После пяти последовательных идентичных битов, которые передаются в сообщении следует «вставка», бит противоположной полярности вставляется передатчиком в поток передаваемых битов (биты «вставки» вставляются в сообщение от поля SOF до поля CRC). Получатели автоматически проверяют сообщение на наличие «вставок». Если любой из принимающих узлов сети обнаруживает в полученном сообщении шесть последовательных идентичных битов, то фиксируется ошибка (отсутствия «вставки»). В дополнение для обнаружения ошибок, «вставки» гарантируют, что есть достаточно не нулевых окончаний в потоке битов (non-return to zero (NRZ)), чтобы поддержать синхронизацию.

Сообщение об ошибке (The CAN Error Frame)

Если передающий или принимающий узел обнаруживает ошибку, он немедленно прерывает приём или передачу текущего сообщения. Сообщение об ошибке называемое «флаг» ошибки, составляется из шести доминантных битов и разделителя сообщения об ошибке состоящего из восьми рецессивных битов. Так как эта строка битов нарушает правило «вставок», все другие узлы также передают сообщение об ошибке. После критичного количества обнаруженных ошибок, узел в конце концов само-отключается. Надежность, особенно в производстве и автомобильной электронике, где применяется технология CAN, требует, чтобы сеть могла отделять случайные ошибки (из-за скачков напряжения, шумов или других временных причин) от постоянных, являющихся причиной неисправности узла из-за дефектов в оборудовании. Следовательно, узлы хранят и отслеживают число обнаруженных ошибок. Узел может быть в одном из трех режимов в зависимости от количества зафиксированных ошибок:

Если количество зафиксированных ошибок в каждом буфере передачи или приёма соответствующего узла, больше чем нуль и меньше чем 128, узел считается «активным с ошибкой» (“error active”), указывая на то, что несмотря что узел остается полностью функциональным, по крайней мере одна ошибка была обнаружена.

Если количество зафиксированных ошибок между 128 и 255, то узел переходит в «пассивный с ошибками» (“error passive”) режим. В «пассивном с ошибками» режиме узел будет передавать на более медленном уровне, отправляя 8 рецессивных битов прежде чем снова отправить сообщение, распознав что шина свободна.

Если количество зафиксированных ошибок более 255, то узел переходит в режим «отключен от сети» (“busoff”), отключив себя самостоятельно.

Ошибка при получении добавляет в общее количество учтённых ошибок 1, ошибка при передаче добавляет в общее количество учтённых ошибок 8. Последующие безошибочные сообщения постепенно уменьшают количество учтённых ошибок на 1, за каждое безошибочное сообщение. Если общее количество учтённых ошибок возвращается к нулю, узел возвращается в нормальный режим функционирования. Узел в находящийся режиме “busoff” может перейти в режим “error active” после 128 входов в сеть из 11 последовательных рецессивных битов, которые были проконтролированы. Сообщение считается безошибочным, если передающий узел не нашёл в нём ошибок вплоть до поля EOF. Повреждённые сообщения отсылаются повторно сразу как только шина становится свободной.

Запрос данных от конкретного узла сети (The CAN Remote Frame)

Узел, которому необходимы данные от другого узла сети, может запросить передачу таких данных, отправив соответствующий запрос на получение данных (Remote Frame). Например, микропроцессору управления центральным замком на вашем автомобиле необходимо знать положение селектора коробки передач от ЭБУ трансмиссии (является ли он в положении «паркинг»). Структура запроса на получение данных аналогична структуре стандартного сообщения только без поля данных (data ﬁeld) и с рецессивным RTR битом.

Запрос на предоставление дополнительной паузы между получаемыми данными и свободное пространство между сообщениями (Overload Frames and Interframe Space)

Если какой-либо узел сети будет получать сообщения быстрее, чем он может их обработать, то будет сгенерирован запрос на предоставление дополнительной паузы между получаемыми данными (Overload Frames) чтобы обеспечить дополнительное время между принимаемыми данными или запросами на получение сообщений (Remote Frame). Подобно сообщению об ошибке, Overload Frame имеет два поля с битами: ﬂag перегрузки состоящий из шести доминирующих битов и разделитель перегрузки, состоящий из восьми рецессивных битов. В отличие от сообщений об ошибке, суммарный подсчёт Overload Frames не ведётся.

Пространство между сообщениями состоит из трех рецессивных битов так же, как и время простоя шины между сообщениями или удаленными запросами на передачу. Во время перерыва никакому узлу не разрешают инициировать передачу (если доминирующий бит будет обнаружен во время Перерыва, то Overload Frame будет сгенерирован). Время простоя шины длится, пока у узла нет чего-то для передачи, а когда начинается передача, то в этот момент появление доминирующего бита на шине сигнализирует о начале передачи сообщения SOF.

Загрузка шины (Bus Loading)

CAN обеспечивает устойчивое, простое и гибкое сетевое решение для производственных, автомобильных и многих других приложений. Главный недостаток протокола CAN — что задержка сообщения не является определённой (из-за существования Error Frames, Overload Frames и повторных передач), и увеличения задержки ведёт к увеличению сетевого трафика. В целом использование шины не должно превышать 30% от максимальной мощности шины и гарантировать, что низкоприоритетные сообщения не испытывают недопустимую задержку. Использование шины определено как деление двух величин — общее количество использованных для передачи битов поделённое на общее максимально доступное количество для передачи битов , и вычисляется следующим образом:

Шаг 1 — Выбирается единица времени ≥ самого медленное зафиксированного периодического сообщение в сети (обычно 1 секунда).

Шаг 2 — Определяются все периодические сообщения.

Шаг 3 — К каждому из этих сообщений приблизительно одинакового размера, добавляются 47 служебных бит (размер служебных полей данных — SOF + Arbitration + RTR + Control + CRC + Acknowledgment + EOF +

Interframe Space = 1 + 11 + 1 + 6 + 16 + 2 + 7 + 3 = 47 bits).

Шаг 4 — Рассчитывается количество бит используемых в сообщениях путем умножения размера сообщения в битах на количество передач выполняемых в единицу времени.

Шаг 5 — Суммирование всех битов используемых в переданных сообщениях для оценки общего объёма сетевого трафика. Умножение этой величины на страховочный коэффициент 1.1 для получения наихудшего прогноза сетевого трафика.

Шаг 6 — В завершении, поделите общее количество использованных для передачи битов на общее максимально доступное количество для передачи битов (например, 125 Кбит/с или 500 Кбит/с умножаются на единицу времени) для получения предполагаемого процента загрузки шины,- рис. 6

Протоколы синхронизированные по времени (Time-triggered Protocols)

Для контроля над сетью в реальном времени было бы желательно реализовать такой протокол связи, который гарантирует, что для сообщений выбираются крайние временные параметры независимо от нагрузки на шину. Пример такого протокола, который контролирует временной уровень связи CAN данных, это “time-triggered CAN,” или TTCAN (ISO 11898-4). TTCAN сообщения имеют два специальных типа, называемые «окна времени» (time windows): привилегированные окна времени (exclusive time windows), и арбитражные окна времени (arbitrating time windows). Еxclusive time windows прикреплены к специальным сообщениям, которые передаются периодически. Таким образом, Еxclusive time windows не конкурируют за доступ к шине. Аrbitrating time windows используются для сообщений не имеющих строгих ограничений по времени.

Аrbitrating time windows, как нормальные сообщения CAN, конкурируют за доступ к шине на основе приоритета через арбитраж. Тime-triggered CAN протокол, требует наличия в сети «главного узла» (master node), который периодически широковещательно передает сигнал времени сети (называемый глобальным временем (global time)) в специальном информационном сообщении. Для повышения отказоустойчивости в сети должны быть несколько потенциальных главных узлов. Если главный узел перестал работать (обнаружено отсутствие специального информационного сообщения), другие потенциальные главные узлы конкурируют за статус «главного узла» при помощи арбитража и новым «главным узлом» становится узел с самым высоким приоритетом. После этого новый главный узел начинает широковещательно передавать специальные информационные сообщения — global time. Тime-triggered CAN протокол не ретранслирует повреждённые сообщения, и при этом это не вызывает Error Frames.

У протокола TTCAN есть конкурирующий протокол FlexRay, разработанный консорциумом автомобильных производителей и поставщиков. Коммуникационное сообщение (фрейм) FlexRay состоит из периодических синициированных «статических» и «динамических» частей. Статический сегмент составлен из одинаковой длины временных интервалов, соответствующих соединенным в сеть узлам. Каждый узел передает свои сообщения синхронно в его зарезервированном слоте. Статический сегмент также передает «синхронизирующий» кадр, чтобы обеспечить глобальную переменную (timebase) для сети. В отличие от CAN, нет никакого арбитража для шины. Динамический сегмент — по существу механизм «опроса» где каждому узлу дают возможность поместить инициированное событие или асинхронное сообщение в шину в порядке приоритетов, используя механизм синхронизации «миниразделения на слоты». Для повышения отказоустойчивости, узлы сети использующей протокол FlexRay, могут быть связаны двумя шинами или каналами одновременно.

Ну вот, в принципе, вся основная информация о протоколе CAN, а теперь немного о том, как выглядит CAN шина на примере автомобилей произведённых в Японии. Сразу хочу отметить, что без надлежащего диагностического оборудования проводить диагностику и ремонт неисправностей CAN шины можно в очень ограниченном диапазоне. Всё сведётся к проверке физической целостности проводов, проверки состояния соединительных разъёмов, проверки сопротивления проводки и Terminal resistor, проверки соответствующего уровня напряжения на CANlow и CANhigh линиях. Применение в диагностике дилерского оборудования тоже лишь облегчит проверку и сузит круг поиска неисправности, с очень большой неохотой автопроизводители допускают контакт с программным обеспечением, своей интеллектуальной собственностью. В случае проблем на программном уровне возможно только перепрограммирование или замена соответствующего ЭБУ.

Пример CAN шины автомобиля Nissan 2007г.в. — Рис. 7

Интерфейс программы Consult III (Nissan), окно диагностики CAN шины,- рис. 8

Пример CAN шины автомобиля Mitsubishi 2004г.в. – рис. 9

Пример CAN шины автомобиля Mazda 2004г.в. – рис. 10

Пример CAN шины автомобиля Toyota 2007г.в. – рис. 11

За дополнительной и полной информацией по системе каждого диагностируемого автомобиля следует обращаться к соответствующим документам автопроизводителей (WSM и TSB).

Удачных всем ремонтов и беспроблемного обслуживания своих автомобилей.

Задать вопрос или обсудить статью вы можете на форуме Легион-Автодата (нажать)

Автосервис «Япония Авто»
г. Калининград, ул.Портовая, 45
+7 [4012] 63 12 55, 65 60 99, +7(911) 475 9493
japanauto.ru /

Источник

На чтение 21 мин Просмотров 8.5к. Опубликовано 20.10.2022
Обновлено 20.10.2022

Из этой статьи вы узнаете, что такое CAN-шина, почему она появилась. Разберемся с блоками управления в автомобиле и с тем, как они общаются между собой. Расскажем, какие контроллеры соединяются быстрой CAN-шиной, а какие — медленной.

Узнаете, как устроена CAN-шина на физическом и цифровом уровне, из каких данных состоит сообщение, как происходит арбитраж трафика. Какая максимальная длина кабеля и скорость передачи информации, как реализована защита от помех.

Если интересует какой-то конкретный вопрос, пользуйтесь оглавлением.

Что такое CAN-шина?

Автомобиль подобен человеческому организму. Сеть контроллеров (шина CAN) это как нервная система у человека.

В свою очередь, «узлы» или «электронные блоки управления» (ЭБУ) подобны частям тела. Они соединены между собой через CAN-шину.

Шина CAN представляет собой витую пару проводов. С ее помощью все блоки управления в автомобиле соединены в единую информационную сеть.

Причины появления CAN-шины

Когда вы нажимаете выключатель в своем доме, чтобы включить свет, электричество проходит через выключатель к лампам.

Автомобили раньше использовали такое же подключение. С тех пор как в 1915 году Генри Форду пришла идея добавить в свои автомобили фары и электрический сигнал, электричество поступало от аккумулятора через выключатели к фарам и другим устройствам.

К 1960-м годам в каждом автомобиле были тысячи тяжелых проводов.

После нефтяного эмбарго 1970-х годов на автопроизводителей оказывалось все большее давление с целью повышения эффективности использования топлива. Поэтому они начали искать способы уменьшить вес выпускаемых автомобилей.

К началу 1980-х годов в автомобилях было все больше и больше электронных блоков управления. Сначала электронное управление получили самые важные системы, такие как системы управления двигателем, трансмиссией и тормозной системой. Но со временем электронное управление распространилось и на второстепенные либо периферийные системы, такие как климат-контроль, блоки комфорта и прочие.

В скором времени такое положение дел привело к тому, что производители столкнулись тремя проблемами:

Такие компании, как Bosch, искали тип шинной коммуникационной системы, которая могла бы использоваться в качестве системы связи между несколькими ЭБУ и системами автомобиля.

Они искали на рынке, но не могли найти именно то, что было нужно, поэтому они начали разработку «Controller Area Network» в партнерстве с Mercedes-Benz, Intel, а также несколькими университетами Германии.

Краткая история шины CAN

В 1986 году компания Bosch представила стандарт CAN на конгрессе SAE в Детройте. Год спустя корпорация Intel начала поставки первых микросхем контроллеров CAN, и автомобильный мир изменился навсегда.

До CAN: автомобильные ЭБУ использовали сложную проводку «точка-точка».
1986: Компания Bosch разработала протокол CAN.
1991: Bosch опубликовала CAN 2.0 (CAN 2.0A: 11 бит, 2.0B: 29 бит).
1993: CAN принят в качестве международного стандарта (ISO 11898).
2003: ISO 11898 становится серией стандартов.
2012: Bosch выпустила CAN FD 1.0 (передачи данных на двух скоростях).
2015: Протокол CAN FD стандартизирован (ISO 11898-1).
2016: Физический уровень CAN для скоростей передачи данных до 5 Мбит/с стандартизирован в ISO 11898-2.

Теперь, например, достаточно одного датчика температуры, который подключен к блоку управления двигателем. ЭБУ опрашивает датчик температуры для себя и отправляет эту информацию в виде сообщения в информационную шину данных для других блоков.

При таком подходе уменьшается количество проводов, нет дублирования датчиков. Появляется возможность ввода/вывода информации из электронных блоков управления, что позволяет диагностировать сложные системы с множеством электронных блоков управления.

Сегодня CAN является стандартом в автомобилях (легковых, грузовых, автобусах, тракторах, …), кораблях, самолетах, электромобилях и многом другом.

Что такое ЭБУ?

В автомобиле ЭБУ могут быть, например, блок управления двигателем, подушками безопасности, аудиосистемой и т. д.

В современном автомобиле может быть до 70 ЭБУ — и каждый из них может иметь информацию, которой необходимо поделиться с другими участниками сети.

Именно здесь на помощь приходит CAN-шина. Она позволяет каждому блоку управления общаться со всеми другими ЭБУ без сложной специальной проводки.

В частности, блок управления может передавать данные с датчиков по шине CAN. Переданные данные принимаются всеми другими контроллерами в сети CAN, после чего каждый ЭБУ может проверить данные и решить, принимать их или игнорировать.

Физический уровень шины CAN

Физический уровень CAN описан в стандарте ISO 11898 и регламентирует способ передачи данных. В случае с CAN-шиной это два провода витой пары. При этом CAN-шина вполне может работать и по одному проводу, а витая пара прежде всего используется для защиты от помех.

Однопроводная схема

Для того чтобы лучше понять как данные передаются по двухпроводной CAN-шине, давайте сначала рассмотрим как данные передаются по однопроводной схеме, которой, например, является K-линия.

Итак, есть один провод, с его помощью соединены блоки управления. Этот провод внутри блока соединен с 12 вольтами через резистор 5 килоом. Таким образом напряжение на проводе становится по умолчанию 12 В.

Каждый из подключенных блоков может стягивать это напряжение на массу, меняя его с 12 на 0 вольт. Таким образом, получаются прямоугольные импульсы на шине данных. Они могут принимать всего два уровня напряжения — 0 и 12 вольт.

Присвоим низкому уровню в ноль вольт логический ноль, а уровню 12 вольт — логическую единицу. Зададим тактовый сигнал шины, то есть обозначим сколько раз секунду блоки будут опрашивать шину и соответственно сколько времени будет длиться один бит.

То есть наименьшая часть цифровой информации вид может принимать только два значения 0 или 1. Таким образом, мы получили физическую возможность отправлять и принимать двоичные данные между блоками управления.

Витая пара. Как работает CAN high-speed

В CAN-шине тот же принцип, только сигнал считывается как разница между напряжениями проводов CAN-high и CAN-low, которые образуют витую пару.

Чтобы понять, как именно это происходит, давайте рассмотрим как могут меняться уровни напряжения на этих проводах.

По умолчанию на проводе CAN-high, как и на проводе CAN-low, напряжение соответствует величине в 2,5 В. При этом разница напряжений между проводами составляет 0 В. Такое состояние can-шины называется рецессивным (recessive) и интерпретируется как логическая единица.

Существует и второе состояние шины, при котором напряжение на проводе CAN-high будет 3,5 вольт, а на проводе CAN-low — 1,5 В. Разница напряжений между проводами составит 2 вольта. Это состояние называется доминантным (dominant) и соответствует логическому нулю.

Логическая 1 (рецессивное состояние):

2,5 вольта на проводе CAN_H;
2,5 вольта на проводе CAN_L;
дифференциальное напряжение 0 вольт.

Логический 0 (доминантное состояние):

3,5 вольта на проводе CAN_H;
1,5 вольта на проводе CAN_L;
дифференциальное напряжение 2 вольта.

Так работает высокоскоростная шина CAN high speed. Она описана в стандарте ISO 11898-2.

Работа CAN low speed

Устройство низкоскоростной шины CAN low speed описано в стандарте ISO 11898-3. Для нее уровни напряжения такие.

Логическая 1 (рецессивное состояние):

0 вольт на проводе CAN_H;
5 вольт на проводе CAN_L;
дифференциальное напряжение 5 вольт.

Логический 0 (доминантное состояние):

3,6 вольта на проводе CAN_H;
1,4 вольта на проводе CAN_L;
дифференциальное напряжение 2,2 вольта.

Защита от помех

Ведь и на одном проводе все работало, так зачем усложнять?

CAN-шиной объединены самые ответственные блоки управления автомобиля. От качества этой связи напрямую зависит безопасность движения. В связи с этим CAN-шине предъявляются высокие требования к надежности и безотказности.

Дело в том, что многие компоненты автомобиля являются источниками электромагнитных помех. Особенно система зажигания.

Использование витой пары позволяет в значительной степени решить эту проблему. Давайте посмотрим, как это происходит.

Представьте себе, что витая пара CAN-шины попадает в зону действия электромагнитной помехи. В медном проводе индуцируется напряжение, которое плюсуется или отнимается от напряжения, уже существующего на этом проводе.

Предположим, что на проводе CAN-high в рецессивном состоянии напряжение было 2,5 В. Помеха увеличила его на 1,1 В. Соответственно мы получили напряжение в 3,6 В, которое могло быть интерпретировано уже как доминантное состояние.

Но CAN-шина устойчива к таким помехам, потому что сигналом является не просто изменение уровня напряжения на одном из проводов, а именно изменение разницы между напряжениями на этих проводах. А разница как раз не изменилась из-за применения витой пары.

Таким образом, на проводе CAN_L напряжение поднимется на те же 1,1 В. А разница напряжений как была 2,5 — 2,5 = 0 В, так и осталась 3,6 — 3,6 = 0 В. Действие помехи на шину в доминантном состоянии аналогично.

Зачем нужен трансивер

Название Transceiver произошло от двух слов receiver (приемник) и transmitter (передатчик). Переводится как приемопередатчик.

Трансиверы обрабатывают дифференциальный сигнал, принимают и передают информацию. Трансивер связывает провода витой пары (CAN_H и CAN_L) с линиями Tx и Rx микропроцессора, который не умеет напрямую работать с CAN-шиной.

По линии Tx микропроцессор отправляет информацию в шину данных, а по линии Rx он считывает информацию.

В трансивере находится схемотехника, которая формирует разные уровни напряжения на проводах CAN_H и CAN_L для доминантного и рецессивного состояния шины.

Трансивер обычно устанавливается внутри электронного блока управления и представляет собой специализированную микросхему.

Оконечные сопротивления

Это еще одна часть физического уровня CAN-шины. Оконечные сопротивления используются для борьбы с отраженным сигналом так называемым эхом.

Отраженный сигнал препятствует нормальной передаче данных. Причем, чем больше будет длина проводов шины и чем выше будет скорость передачи данных, тем значительней будет проявляться этот негативный эффект.

Правильно подобранные конечные нагрузочные сопротивления компенсируют отраженный сигнал. Обычно это два резистора по 120 ом внутри блока управления. Они подключены к противоположным концам шины. Таким образом, сопротивление между проводами can-шины составляет около 60 ом.

У разных автопроизводителей величина оконечных сопротивлений может отличаться.

Где применяется CAN high speed, а где CAN low speed

HS-CAN и LS-CAN отличаются скоростью передачи данных и уровнями рабочих напряжений. Быстрый CAN применяется для связи блоков управления двигателя, автоматической коробки передач, тормозов, рулевого управления, подушек безопасности, полного привода, пневмоподвески и других важных систем, от которых напрямую зависит безопасность движения.

Медленный CAN используется для менее важных систем, таких как климат-контроль, системы комфорта, наружное освещение, электропривод сидений и т. п. в зависимости от комплектации автомобиля.

Особенностью медленного CAN является возможность сохранять работоспособность в однопроводном режиме, если второй провод витой пары поврежден.

Высокоскоростной и низкоскоростной CAN автопроизводители могут называть по-своему, а также пользоваться любой из доступных скоростей передачи данных.

Межсетевой шлюз (CAN gateway)

Часто есть необходимость передавать информацию от блока управления, подключенного к быстрой CAN-шине, к блоку, подключенному к медленной CAN-шине, и наоборот. Например, блоку управления климатом нужно знать температуру двигателя.

Так как напрямую разные CAN-шины не соединить, для этих целей используется межсетевой шлюз (CAN gateway). К нему подключаются шины с разными скоростями. Это могут быть не только CAN-шины, но и другие шины, присутствующие в автомобиле, к примеру, FlexRay или Ethernet.

Часто в CAN gateway хранится информация об автомобиле, VIN номер и комплектация. Именно из него сканеры получают информацию при автоопределении автомобиля.

Сам межсетевой интерфейс может быть выполнен как отдельным блоком, так и встроен в другие блоки. Обычно это приборная панель, электронный замок зажигания или блок управления бортовой сети (Body Control Module — BCM).

Межсетевой шлюз CAN

Мы разобрались физическим уровнем CAN-шины. Теперь вы знаете, как напряжение на витой паре становится единицами и нолями, как биты передаются от одного блока управления к другому.

Канальный уровень CAN-шины (передача данных)

CAN является широковещательной шиной последовательной передачи данных. То есть данные отправляются по очереди бит за битом и при этом между узлами сети реализован один общий эфир, когда каждый слышит каждого.

Блоки управления, как и диагностический сканер, выступают узлами в сети CAN-шины. Но для того, чтобы все это заработало мало просто подавать в шину единицы и ноли. Нужно определить, какой узел будет говорить, какой слушать, каков будет формат сообщения, кому это сообщение адресовано и как будет подтверждаться правильность приема.

Эту задачу решает канальный уровень (data link layer), описанный в стандарте ISO 11898-1. Каждый узел может отправлять и принимать информацию кадр за кадром.

Существует четыре типа сообщений-кадров:

Кадр данных (data frame). Передает информацию одному или нескольким узлам-приемникам.
Кадр удаленного запроса (remote frame). Запрашивает данные у других узлов.
Кадр ошибки (error frame). Сообщает об ошибках.
Кадр перегрузки (overload frame). Сообщает о состоянии перегрузки.

Из чего состоит кадр CAN-шины

Рассмотрим структуру самого распространенного кадра Data frame.

SOF. Начало кадра

Первый бит кадра (SOF — Start Of Frame) всегда доминантный логический ноль. Он выводит шину из состояния холостого хода и начинает передачу данных.

Арбитражное поле

Дальше следует арбитражное поле. Оно используется для того, чтобы определить, какой из узлов получит доступ к вещанию по шине. Ведь передача данных последовательная, бит за битом, кадр за кадром. Соответственно узлам приходится ждать своей очереди для отправки сообщения в шину, но при этом слушают шину они постоянно.

Зачем нужен арбитраж CAN-шины

Арбитраж сообщений это процесс, в котором два или более CAN-контроллеров договариваются о том, кто должен использовать шину.

Любой узел может начать передачу данных, когда обнаружит незанятую шину. Это может привести к тому, что два или более контроллеров начнут передачу сообщения почти одновременно.

Нет такого блока, который будет вещать всегда первым. Первым всегда будет передавать информацию тот блок, чьё сообщение имеет наивысший приоритет. И как раз этот спор и решается в арбитражном поле. Разберемся как именно.

Как происходит арбитраж CAN-шины и что такое идентификатор

Представим, что есть три узла, которые одновременно хотят получить доступ к CAN-шине. После бита «Start Of Frame» каждый из этих блоков начинает отправлять биты идентификаторов в шину данных.

Идентификатор присвоен каждому сообщению и определяет его приоритет, то есть определяет, какое сообщение более важное и должно быть отправлено в первую очередь.

Все узлы одновременно, бит за битом, начинают отправлять идентификаторы кадров в шину данных. В это же время все узлы также и считывают каждый новый появившийся бит на шине.

Пока отправляемые биты у всех блоков совпадают, все идет без изменений. Но рано или поздно случается конфликт, когда разные узлы одновременно отправят разные биты. И вот тут самое время вспомнить, что доминантный бит (логический 0) перебивает рецессивный бит (логическую 1) в конфликтных ситуациях. Это реализовано аппаратно в схемотехнике трансивера.

Это условие приводит к тому, что узел, у которого рецессивный бит (логическая единица) проигрывает арбитраж тому узлу, у которого оказался доминантный бит (логический ноль).

Проиграв арбитраж, блок утрачивает доступ к шине и ждет в режиме «только чтение» следующего арбитража. При этом остальные блоки продолжают арбитраж. Но при каждом очередном конфликте один из них отсеивается. И так до тех пор, пока не останется всего один блок, чье сообщение оказалось самым приоритетным и выиграло арбитраж.

Выигравшему блоку принадлежит право отправить сообщение в шину, а потому именно он будет продолжать начатый кадр.

Важным условием успешного битового арбитража является то, что никакие два узла не могут передавать одно и то же поле арбитража. Из этого правила есть одно исключение: если сообщение не содержит данных, то любой узел может передать это сообщение.

Поскольку шина является проводной, а доминирующий бит логически равен 0, следует, что в арбитраже победит сообщение с численно наименьшим Арбитражным полем.

11-bit и 29-bit идентификаторы

11 бит дают возможность использовать только 2048 идентификаторов, то есть 2048 параметров Этого иногда бывает недостаточно. В этом случае используется 29-битый ID. Таким образом, появляется возможность использовать миллионы идентификаторов.

Кадр с расширенным 29-битным идентификатором (CAN 2.0B) идентичен кадру с 11-битным идентификатором (CAN 2.0A), за исключением более длинного идентификатора. Он используется, например, в протоколе J1939 для большегрузных автомобилей.

Что произойдет, если узел будет один на шине и попытается передать сообщение?

Блок, конечно, выиграет арбитраж и с радостью продолжит передачу сообщения. Но когда придет время подтверждения… ни один узел не пошлет доминирующий бит подтверждения ACK (о нем ниже).

Передатчик почувствует ошибку ACK, пошлет флаг ошибки, увеличит свой счетчик ошибок передачи на 8 и начнет повторную передачу. Это произойдет 16 раз. Затем передатчик перейдет в режим пассивной передачи ошибок.

По специальному правилу алгоритма ограничения ошибок, счетчик ошибок передачи не увеличивается, если узел пассивен и ошибка является ошибкой ACK. Таким образом, узел будет продолжать передачу вечно, по крайней мере, до тех пор, пока кто-то не подтвердит сообщение.

RTR. Запрос на удаленную передачу.

Следующий бит Remote Transmission Request (RTR). Это бит запроса. Он определяет какого типа будет сообщение:

Dataframe, когда вещающий блок сообщает информацию или
Remote frame, когда передающий блок запрашивает информацию.

Поле Control

Дальше следует поле Control, в котором первый бит ID extension. Если в нем будет логический ноль, то будет использоваться стандартный 11-битный идентификатор, а если логическая единица, то расширенный 29-битный.

Каждый идентификатор это какой-то параметр. Например, обороты двигателя, температура, состояние замка зажигания, угол поворота руля, скорость автомобиля, запрос на включение кондиционера и так далее.

Биты DL3 — DL0 в поле Control используется для определения заранее количества байтов, которые будут передаваться в следующем поле Data. Чтобы не передавать лишние биты и сократить время фрейма, тем самым увеличив скорость передачи данных. По этой же причине по-умолчанию используется 11-битный идентификатор, чтобы без надобности не тратить время на лишние 18 бит.

Поле Data

В поле Data находится самая полезная информация, которую нужно передать. Обороты, скорость, нагрузка и т. п.

Ради передачи этой информации и строится весь фрейм. Это поле может составлять от 1 до 8 байт, то есть от 8 до 64 бит.

CRC. Контрольная сумма

Следующее поле это контрольная сумма CRC (Cyclic Redundancy Check). Представляет собой значение, вычисленное по определенной формуле, на основе битов из предыдущих полей.

То есть все эти биты обрабатываются определенным алгоритмам в блоке-отправителе. Результат этой отработки записывается в поле контрольной суммы кадра.

После этого уже блок-получатель повторно вычисляет контрольную сумму CRC таким же алгоритмом, но уже на базе полученной информации.

Если каждый из битов был распознан правильно, то контрольная сумма у блока-получателя будет такой же, как и у блока-отправителя. В этом случае данные считаются переданными без ошибок.

Если же контрольная сумма не сходится, распознается ошибка передачи данных и полученная информация игнорируется.

ACK. Бит подтверждения

Следующим идет бит подтверждения ACK (Acknowledge). Узел-отправитель выставляет в нем рецессивное состояние, но узел-получатель перебивает его доминантным в случае успешного приема, тем самым подтверждая передачу сообщения.

Отправитель проверяет наличие бита подтверждения и повторно передает сообщение, если подтверждение не было обнаружено.

Наличие бита подтверждения на шине не означает, что любой из предполагаемых адресатов получил сообщение. Единственное, что мы знаем, это то, что один или несколько узлов на шине приняли его правильно.

EOF. Конец кадра

Дальше идут 7 бит поля End of Frame (EOF). Это конец кадра, после которого кадр завершается и шина снова переходит состояние холостого хода.

И так до тех пор, пока один или несколько блоков снова не начнут отправлять сообщения.

Адресация и идентификация сообщений CAN-шины

Стоит еще раз отметить, что в CAN-сообщениях нет явного адреса. Каждый узел принимает весь трафик на шине. Используя аппаратные фильтры и программное обеспечение, он определяет, является ли сообщение «интересным» или нет.

Фактически, в CAN не существует понятия адреса сообщения. Вместо этого, содержимое сообщений идентифицируется по ID, который присутствует в кадре. Считается, что сообщения CAN имеют «адрес содержимого».

Обычный адрес сообщения будет выглядеть так: «Вот сообщение для узла N». Сообщение с адресом содержимого выглядит так: «Вот сообщение, содержащее данные с меткой N». Разница между этими двумя понятиями небольшая, но существенная.

Содержимое поля арбитража, согласно стандарту, используется для определения приоритета сообщения на шине. Все контроллеры CAN также используют все поле арбитража (некоторые используют только часть) в качестве ключа в процессе аппаратной фильтрации.

Стандарт не говорит, что поле арбитража должно использоваться в качестве идентификатора сообщения. Тем не менее это очень распространенное использование.

Что такое CAN FD (Flexible Data Rate CAN)?

С расширением функциональности автомобиля возрастает и нагрузка на CAN-шину. CAN FD (Flexible Data Rate) была разработана как шина CAN «следующего поколения».

Стандартная длина каждого сообщения была увеличена в 8 раз — с 8 до 64 байт, а максимальная скорость передачи данных была аналогично увеличена с 1 Мбит/с до 8 Мбит/с. Одним словом, CAN FD повышает скорость и эффективность. Поэтому она используется в современных автомобилях.

CAN FD обратно совместим и поддерживает протокол CAN 2.0, а также специальные протоколы, такие как SAE J1939.

CAN FD по сути является расширением оригинального стандарта CAN, как указано в ISO 11898-1, и полностью совместим с классическими CAN-шинами.

Отличия CAN FD от обычной CAN-шины

CAN FD работает одновременно на двух скоростях. Поле арбитража или заголовок кадра передается со стандартной скоростью, например 500 кбит/с. А поле данных передается на скорости в несколько раз выше, вплоть до 8 Мбит/с.
Размер сообщения увеличен до 64 байт. В обычной CAN-шине — максимум 8 байт.
Контроллер CAN FD способен принимать обычные CAN сообщения, а стандартный CAN узел не может принимать кадры формата CAN FD.
Для шины CAN FD нужны специальные микросхемы-трансиверы с повышенным быстродействием.

В настоящее время CAN FD используется в высокопроизводительных автомобилях, но по мере развития ЭБУ и снижения стоимости аппаратного обеспечения CAN FD, это лишь вопрос времени, когда CAN FD появится практически во всех автомобилях.

Будущее шины CAN

В будущем протокол шины CAN будет оставаться актуальным, хотя на него будут влиять основные тенденции:

Потребность во все более расширяющихся функциях автомобиля.
Рост облачных вычислений.
Развитие Интернета вещей (Internet of Things — IoT).
Развитие самоуправляемых автомобилей (без водителя).

В частности, рост числа подключенных автомобилей V2X и облачных вычислений приведет к быстрому росту автомобильной телематики и IoT CAN-регистраторов.

В свою очередь, перевод сети шины CAN в режим «онлайн» также подвергает автомобили рискам безопасности и может потребовать перехода на новые протоколы CAN, такие, как CAN FD.

Максимальная скорость CAN-шины

Максимальная скорость шины CAN, согласно стандарту, составляет 1 Мбит/с. Тем не менее некоторые CAN-контроллеры могут работать и с более высокими скоростями.

Медленный CAN low speed (ISO 11898-3) может работать на скорости до 125 кбит/с.

Однопроводной CAN может работать со скоростью около 50 кбит/с в стандартном режиме, а в специальном высокоскоростном режиме, используемом, например, для программирования ЭБУ, — до 100 кбит/с.

Максимальная длина кабеля в CAN-шине

При скорости 1 Мбит/с максимальная длина кабеля может составлять около 40 метров. Это связано с тем, что схема арбитража требует, чтобы волновой фронт сигнала успел распространиться до самого удаленного узла и обратно. Другими словами, длина кабеля ограничена скоростью света.

Другие максимальные длины кабелей (значения приблизительны):

100 метров при скорости 500 кбит/с;
200 метров — при 250 кбит/с;
500 метров — при 125 кбит/с;
6 километров — при 10 кбит/с.

Если для обеспечения гальванической развязки используются оптопары, максимальная длина шины соответственно уменьшается.

Источник

The following is an excerpt from
A Comprehensible Controller Area Network by Wilfried Voss.

This section will examine the exact structure of both data and remote message frames bit by bit.

Per definition, a CAN data or remote frame has the following components:

SOF (Start of Frame) — Marks the beginning of data and remote Frames
Arbitration Field – Includes the message ID and RTR (Remote Transmission Request) bit, which distinguishes data and remote frames
Control Field – Used to determine data size and message ID length
Data Field – The actual data (Applies only to a data frame, not a remote frame)
CRC Field — Checksum
ACK Field – Acknowledgement of checksum check
EOF (End of Frame) – Marks the end of data and remote frames
IFS – Interframe Space

Both, Data Frame and Remote Frame, are very similar. Basically, the Remote Frame is a Data Frame without the Data Field.

Data Frame

Remote Frame

The following picture shows the bitstream of a data frame in detail.

As shown in the previous picture, the entire frame has a length between 47 and 111 bits, depending on the length of the data field, which can be between 0 and 8 bytes (0 and 64 bits).

At a baud rate of 1 MBit/sec, this translates into a transmission time between 47 (remote frame) and 111 (data frame with 8 bytes of data) microseconds.[1]

The following components of a CAN data or remote frame are considered static fields since their data level is static (recessive):[2]

CRC Delimiter
ACK Delimiter
End of Frame Field
Intermission FieldThese components are also used to check the consistency of a data or remote frame (see also Chapter 8 — Error Detection and Fault Confinement).

Each CAN message frame, regardless of the message ID length, will be terminated by a sequence of 11 recessive bits: The ACK Delimiter bit in the Acknowledgement Field (1 bit), the End of Frame Field (7 bits), and the Intermission Field (3 bits).

The individual frame elements are:

SOF (1 Bit)

The dominant Start of Frame (SOF) bit represents the start of a Data/Remote Frame and, in all consequence, also starts the arbitration sequence (the arbitration field follows right after the SOF bit). Thus, before attempting to access the bus, a CAN node must wait until the bus is idle. A sequence of 11 recessive bits detects an idle bus, i.e., the sequence of ACK Delimiter bit in the Acknowledgement Field (1 bit), the End of Frame Field (7 bits), and the Intermission Field (3 bits).

The falling (leading) edge of the SOF bit (transition from recessive to dominant level), sent by the first node that attempts to access the bus, also serves as a mechanism to synchronize all CAN bus nodes.

Arbitration Field (12 or 32 Bits)

The arbitration field contains of two components:

11/29 Bit Message Identifier, first Bit is MSB. As will be explained later, the CAN message ID can be 11 or 29 bits long.
RTR (Remote Transmission Request) indicates either the transmission of a Data Frame (RTR = 0) or a Remote-Request Frame (RTR = 1).

A low message ID number represents a high message priority.

A Data Frame has higher priority than a Remote Frame.

The total length of the arbitration field is 12 bits when an 11 bit message identifier is used (see picture below).

As shown in the picture, the total length of the arbitration field will be 32 bit with a 29 bit identifier (see also
Chapter 4.6 – Extended CAN Protocol).

An 11 bit identifier (standard format) allows a total of 211 (= 2048) different messages. A 29 bit identifier (extended format) allows a total of 229 (= 536+ million) messages.

The IDE (Identifier Extension) bit belongs to:

– The Control Field of the standard format (11 bit message identifier)

– The Arbitration Field of the extended format (29 bit message identifier)

Control Field (6 Bits)

The 4 LSB bits of the Control Field specify the length of the data block (DLC = Data Length Code), the MSB bit (IDE = Identifier Extension) indicates either standard 11-Bit format (Bit = 0) or 29-Bit extended format (Bit = 1).

As will be explained in the following chapter, the CAN message ID can be 11 or 29 bits long. The IDE bit became active with the release of the CAN 2.0B standard (i.e., the extension of the message identifier from 11 to 29 bits). The previous standard CAN 2.0A referred to bits r0 and r1 (instead of IDE), which were, at the time, reserved for future purposes. Both bits, r0 and r1, were always sent as dominant (zero), which, according to standard CAN 2.0B, indicates an 11-bit identifier per default.

The Data Length Code (DLC) is usually set to a value between 0 and 8, indicating a data field length between 0 and 8 bytes. A value greater than 8 is permissible for application-specific purposes. In this case, the sending node must send 8 data bytes, while the receiving nodes expect 8 bytes.

Remote frames can only be transmitted with a DLC (Data Length Code) identical to the DLC of the corresponding data frame. Due to a limitation of contention-based arbitration, simultaneous transmission of remote frames with different DLCs will lead to irresolvable collisions.

Data Field (0 to 8 bytes)

Maximum 8 bytes, first Bit is MSB.

CRC Field (16 Bits)

The CRC (Cyclical Recovery Checking) Field contains the CRC Sequence and a CRC Delimiter Bit.

The 15 bit
CRC Segment contains the frame check sequence spanning from SOF (Start of Frame), through the arbitration field, control field and data field. Stuffing Bits are not included (see also Chapter 7.2 – Bit Stuffing).

The
CRC Delimiter Bit (always recessive, i.e., 1), following right behind the CRC Segment, allows for CRC processing time.

Acknowledgement Field (2 Bits)

The Acknowledgement Field contains a 1-bit Acknowledgement Slot plus the ACK Delimiter Bit (which is always recessive).

Unlike other serial communications, such as RS232, the acknowledgment field does not serve as a signal for the successful or unsuccessful reception of a message by a receiving node (consider that there may be numerous receiving nodes in a CAN network). The acknowledgment field serves as a confirmation of a successful CRC (checksum) check by the receiving nodes in the network.

During the ACK slot, the message transmitting node switches to receive mode by sending a recessive signal to the bus. At the same time, all other nodes in the network accomplish their individual CRC (checksum) check (according to the CAN standard, all nodes must determine the checksum in the same standardized way) and output a dominant signal to the bus when the check was successful.

The message transmitting node monitors the bus and expects a dominant level during the ACK slot. This will be the case when either one of the receiving CAN Bus nodes outputs a dominant level.

If all nodes in the network determine a checksum error, meaning the sending node monitors a recessive level in the ACK slot, it is clear that the sending node calculated a wrong checksum. The error is therefore local at the sending node.

Any receiving node detecting a checksum error will post an error frame to the bus, i.e., right after the completed acknowledgment field. With this scenario, it is possible to determine whether or not the actual malfunction is with that particular receiving node.

The ACK slot may remain dominant, while at the same time, an error is reported by only one receiving node, meaning this single node will send out an error frame. The error is therefore local at that particular receiving node.

The CAN standard allows the so-called “self-retirement” (or self-removal) of nodes from the network due to an excessive number of transmit or receive errors (see also
Chapter 8 – Error Detection and Fault Confinement).

The ACK Delimiter Bit is always recessive. This is necessary to distinguish a successful acknowledgment from an occurring error frame. An error frame starts with at least six successive dominant bits, meaning the first bit of an error frame will override the ACK Delimiter Bit (see also
Chapter 4.7 – Error Frame).

End-of-Frame Field (7 bits, recessive)

Each data or remote frame is terminated by a bit sequence of 7 recessive bits.

This last statement is true unless an Overload Frame occurs (see also Chapter 4.8 – Overload Frame).

More specifically: With the combination of the EOF Field and the preceding recessive ACK Delimiter Bit, each message (data and remote) frame is terminated by eight recessive bits plus, unless an overload frame occurs, the three recessive bits of the Intermission Field.

As shown in the following picture, the up to 11 recessive bits at the end of a message frame are not subject to bit stuffing error detection since the bit stuffing applies only between the SOF (Start Of Frame) bit and (including) the CRC Sequence (see also Chapter 7.2 – Bit Stuffing).

Interframe Space (3 bits, recessive)

The Interframe Space represents the minimum space between frames of any type (data, remote, error, overload) and the following data or remote frame. During the Interframe Space (intermission), no node can start transmitting a data or remote frame. Only the signaling of an overload condition is allowed (see Chapter 4.8 – Overload Frame). There is no Interframe space between error and overload frames. The Interframe Space can not necessarily be considered to be a part of a data or remote frame; however, in a well-functioning CAN network, it will always follow behind a data or remote frame. For more detailed information, see also Chapter 4.9 – Interframe Space.

[1] The information on frame length and the derived transmission times do not include any stuffing bits (See also Chapter 7.2 – Bit Stuffing). In all consequence, the number of average bit stuffing needs to be applied. For more detailed information on frame length and transmission time, refer to Chapter 4.10 – Frame Length and Transmission Times.

[2] The ISO 11898-1 and the Bosch/CiA standard refer to the static fields in various chapters but omit a precise definition.

PiCAN 2 — CAN Bus Interface for Raspberry Pi

This PiCAN2 board provides Controller Area Network (CAN) Bus capabilities for the Raspberry Pi. It uses the Microchip MCP2515 CAN controller with MCP2551 CAN transceiver. Connection are made via DB9 or 3-way screw terminal.

There is an easy-to-install
SocketCAN driver, and programming can be accomplished in C or Python.

The PiCAN board is fully compatible with the new Raspberry Pi 4 Model B.

More Information…

Источник

In this article

What are CAN bus errors?

How does CAN error handling work?

The CAN bus error frame

CAN bus bit stuffing

Active Error Flags

3 CAN error frame examples

Example 1: 6 bits of error flags

Example 2: 12 bits of error flags

Example 3: 9 bits of error flags

Passive Error Flags

Example 4: Transmitter is Error Passive

Example 5: Receiver is Error Passive

CAN error types

#1 Bit Error

#2 Bit Stuffing Error

#3 Form Error

#4 ACK Error (Acknowledgement)

#5 CRC Error (Cyclic Redundancy Check)

CAN node states & error counters

How do the error counters change?

CAN/LIN data & error logger

Examples: Generating & logging error frames

Test #1: No CAN bus errors

Test #2: Removing the CAN bus terminal resistor

Test #3: Setting an incorrect baud rate

Test #4: Removing the acknowledging CAN node

Test #5: CAN frame collisions (no retransmission)

Test #6: CAN frame collisions (incl. retransmission)

Example use cases for CAN error frame logging

CAN bus diagnostics in OEM prototype vehicles

Remotely troubleshooting CAN errors in machinery

FAQ

Recommended for you

Типы сообщений сети CAN.

Контроль доступа к среде передачи (побитовый арбитраж).

Методы обнаружения ошибок.

Механизм ограничения ошибок (Error confinement).

Адресация и протоколы высокого уровня

Физичекий уровень протокола CAN

History[edit]

Applications[edit]

Automotive[edit]

Other[edit]

Architecture[edit]

Physical organization[edit]

Electrical properties[edit]

Nodes[edit]

Data transmission[edit]

ID allocation[edit]

Bit timing[edit]

Layers[edit]

Frames[edit]

Data frame[edit]

Base frame format[edit]

Extended frame format[edit]

Remote frame[edit]

Error frame[edit]

Overload frame[edit]

ACK slot[edit]

Interframe spacing[edit]

Bit stuffing[edit]

CAN lower-layer standards[edit]

CAN-based higher-layer protocols[edit]

Standardized approaches[edit]

Other approaches[edit]

CANopen Lift[edit]

Security[edit]

Development tools[edit]

Licensing[edit]

See also[edit]

References[edit]

External links[edit]

Что такое CAN-шина?

Причины появления CAN-шины

Краткая история шины CAN

Что такое ЭБУ?

Физический уровень шины CAN

Однопроводная схема

Витая пара. Как работает CAN high-speed