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.
In this article
- What are CAN bus errors?
- The CAN error frame
- 5 CAN error types
- States & error counters
- 6 practical experiments
- LIN bus errors
- CAN error logging use cases
- FAQ
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. Так что подписывайтесь на обновления, буду рад снова видеть вас на нашем сайте 🤝
CAN (Control Area Network) —
последовательная
магистраль,
обеспечивающая
увязку в
сеть «интеллектуальных»
устройств
ввода/вывода,
датчиков и
исполнительных
устройств
некоторого
механизма
или даже
предприятия.
Характеризуется
протоколом,
обеспечивающим
возможность
нахождения
на
магистрали
нескольких
ведущих
устройств,
обеспечивающим
передачу
данных в
реальном
масштабе
времени и
коррекцию
ошибок,
высокой
омехоустойчивостью.
Система CAN
обеспечена
большим
количеством
микросхем,
обеспечивающих
работу
подключенных
к
магистрали
устройств,
разработку
которых
начинала
фирма BOSH для
использования
в
автомобилях,
и в
настоящее
время
широко
используемых
в
автоматизации
промышленности.
Цеколёвка
разема
приведена
на рисунке.
| Стандарт | ISO 11898 |
| Скорость передачи |
1 Мбит/с (максимум) |
| Расстояние передачи |
1000 м (максимум) |
| Характер сигнала, линия передачи |
дифференциальное напряжение, скрученная пара |
| Количество драйверов |
64 |
| Количество приемников |
64 |
| Схема соединения |
полудуплекс, многоточечная |
- Предназначен
для
организации
высоконадежных
недорогих
каналов
связи в
распределенных
системах
управления.
Интерфейс
широко
применяется
в
промышленности,
энергетике
и на
транспорте.
Позволяет
строить
как
дешевые
мультиплексные
каналы, так
и
высокоскоростные
сети. - Скорость
передачи
задается
программно
и может
быть до 1
Мбит/с.
Пользователь
выбирает
скорость,
исходя из
расстояний,
числа
абонентов
и емкости
линий
передачи.
| Расстояние, м |
25 | 50 | 100 | 250 | 500 | 1000 | 2500 | 5000 |
| Скорость, Кбит/с |
1000 | 800 | 500 | 250 | 125 | 50 | 20 | 10 |
- Максимальное
число
абонентов,
подключенных
к данному
интерфейсу
фактически
определяется
нагрузочной
способностью
примененных
приемопередатчиков.
Например,
при
использовании
трансивера
фирмы PHILIPS PCA82C250
она равна 110. - Протокол CAN
использует
оригинальную
систему
адресации
сообщений.
Каждое
сообщение
снабжается
идентификатором,
который
определяет
назначение
передаваемых
данных, но
не адрес
приемника.
Любой
приемник
может
реагировать
как на один
идентификатор,
так и на
несколько.
На один
идентификатор
могут
реагировать
несколько
приемников. - Протокол CAN
обладает
развитой
системой
обнаружения
и
сигнализации
ошибок. Для
этих целей
используется
поразрядный
контроль,
прямое
заполнение
битового
потока,
проверка
пакета
сообщения CRC-полиномом,
контроль
формы
пакета
сообщений,
подтверждение
правильного
приема
пакета
данных.
Хемминговый
интервал d=6.
Общая
вероятность
необнаруженной
ошибки 4.7×10-11. - Система
арбитража
протокола CAN
исключает
потерю
информации
и времени
при «столкновениях»
на шине. - Интерфейс
с
применением
протокола CAN
легко
адаптируется
к
физической
среде
передачи
информации.
Это может
быть
дифференциальный
сигнал,
оптоволокно,
просто
открытый
коллектор
и т.п.
Несложно
делается
гальваническая
развязка. - Элементная
база,
поддерживающая
CAN, широко
выпускается
в
индустриальном
исполнении.
CAN 2.0 А
1.
Введение
CAN (Controller Area Network) —
это
последовательный
протокол
связи с
эффективной
поддержкой
распределения
контроля в
реальном
времени и
очень
высоким
уровнем
безопасности.
Основное
назначение:
организация
передачи
информации
в сложных
условиях,
таких как
среды с
высоким
уровнем
различного
рода помех.
Этот
протокол
передачи
применяется
в
автомобильной
электронике,
машинных
устройствах
управления,
датчиках
при
передаче
информации
со
скоростями
до 1 Мбит/сек.
Протокол
CAN можно
разделить
на
следующие
уровни:
- объектный
уровень - канальный
уровень - физический
уровень
Объектный
и канальный
уровни
включают
весь сервис
и функции
передачи
данных
определяемых
ISO/OSI моделью.
Область
объектного
уровня
включает:
- Поиск
сообщений
для
передачи. - Фильтрация
сообщений,
полученных
от
канального
уровня - Обеспечение
связи
между
прикладным
уровнем и
аппаратными
средствами.
Объектный
уровень
можно
реализовывать
различными
способами.
Область
канального
уровня
главным
образом —
протокол
передачи, т.е.
управление
кадрами,
выполнение
арбитража,
проверка и
сигнализация
ошибок,
типизация
ошибок.
Внутри
канального
уровня
решается,
является ли
шина
свободной
для начала
новой
передачи.
Все что
находится
внутри
канального
уровня, не
имеет ни
какой
свободы к
модификации.
Область
физического
уровня —
фактическая
передача
бит между
различными
узлами.
Внутри
одной сети
физический
уровень
должен быть
одинаков
для всех
узлов.
Физический
уровень
можно
реализовать
различными
способами.
2.
Основные
характеристики
протокола
- каждое
сообщение
имеет
определенный
приоритет - существуют
гарантированные
времена
ожидания - гибкость
конфигурации - групповой
приём с
временной
синхронизацией - система
непротиворечивости
данных - multimaster
- обнаружение
и
сигнализация
ошибок - автоматическая
ретрансляция
разрушенных
сообщений - различие
между
временными
ошибками и
постоянными
отказами
узлов и
автономное
отключение
дефектных
узлов
Сообщения
Информация
по шине
посылается
в
фиксированном
формате
сообщений
различной,
но
фиксированной
длины. Когда
шина
свободна,
любой узел
может
начать
передачу
нового
сообщения.
Информационная
маршрутизация
В CAN
нет ни какой
информации
относительно
конфигурации
сети (например,
адреса узла).
Это имеет
несколько
важных
следствий:
Гибкость
системы:
Узел
может быть
добавлен в CAN —
сеть, без
каких либо
изменений в
программном
или
аппаратном
обеспечении,
какого — либо
узла в сети.
Маршрутизация
сообщений:
Содержание
сообщения
определяется
идентификатором.
Идентификатор
не
указывает
адреса
сообщения, а
описывает
значение
данных так,
чтобы все
узлы сети
были
способны
решить
фильтрацией
сообщений,
нужны им эти
данные или
нет.
Передача
группе:
Как
следует из
фильтрации
сообщений,
любое число
узлов может
одновременно
получать и
реагировать
на одно и
тоже
сообщение.
Непротиворечивость
данных:
Внутри
сети CAN
гарантировано,
что
сообщение
принято
всеми
узлами или
ни одним
узлом.
Скорость
передачи
информации
Скорость
передачи
информации
в CAN — сети
может быть
различной
для каждой
сети. Однако
в каждой
конкретной
сети
скорость
передачи
информации
фиксирована.
Приоритеты
Идентификатор
и RTR — бит
определяют
статический
приоритет
сообщения в
течение
доступа к
шине.
Удаленный
запрос
данных
Посылая
кадр
удаленного
запроса
данных, узел
может
потребовать
данные от
другого
узла. Кадр
данных и
кадр
удаленного
запроса
данных
должны
иметь
одинаковый
идентификатор.
Multimaster
Когда
шина
свободна,
любой узел
может
начать
передачу
сообщения.
Доступ к
шине
получает
узел,
передающий
кадр с
наивысшим
приоритетом.
Арбитраж
Когда
шина
свободна,
любой узел
может
начать
передачу
сообщения.
Если два или
больше узла
начинают
передавать
сообщения в
одно и тоже
время,
конфликт
при доступе
к шине будет
решен
поразрядным
арбитражем
используя
идентификатор
и RTR — бит.
Механизм
арбитража
гарантирует,
что ни время,
ни
информация
не будут
потеряны.
Если кадр
данных и
кадр
удаленного
запроса
данных
начинают
передаваться
в одно время,
то кадр
данных
имеет более
высокий
приоритет,
чем кадр
удаленного
запроса
данных. В
течение
арбитража
каждый
передатчик
сравнивает
уровень
переданного
бита с
уровнем,
считываемым
с шины. Если
эти уровни
одинаковы,
узел может
продолжать
посылать
данные
дальше. Если
был послан
уровень лог.
‘1’ (recessive), а с шины
считан
уровень лог.
‘0’ (dominant), то узел
теряет
право
дальнейшей
передачи
данных и
должен
прекратить
посылку
данных на
шину.
Безопасность
Чтобы
достичь
высокой
безопасности
передачи
данных,
приняты
мощные меры
нахождения
ошибок,
сигнализации
ошибок и
самотестирование
в каждом CAN —
узле.
Обнаружение
ошибок
Для
обнаружения
ошибок
приняты
следующие
меры:
- текущий
контроль (передатчики
сравнивают
уровни
битов,
которые
переданы, с
уровнями
на шине). - побитовое
заполнение - проверка
кадра
сообщения
Эффективность
обнаружения
ошибок
Механизмы
обнаружения
ошибок
имеют
следующие
возможности:
- обнаружение
всех
глобальных
ошибок - обнаружение
всех
локальных
ошибок
передатчиков - обнаружение
до 5
случайно
распределённых
ошибок в
сообщении - обнаружение
последовательной
группы
ошибок
длиной до 15 - обнаружение
любого
числа
нечетных
ошибок в
сообщении
Общая
остаточная
вероятность
ошибки для
необнаруженных,
разрушенных
сообщений,
меньше чем:
скорость
появления
ошибки * 4.7*10Е-11
Сигнализация
ошибки и
время
восстановления
Разрушенные
сообщения
помечаются
узлом,
обнаружившим
ошибку.
Такие
сообщения
прерываются
и будут
переданы
снова. Время
восстановления
от
обнаружения
ошибки до
начала
следующего
сообщения в
большинстве
случаев = 29 *
время
передачи
одного бита,
если не
имеется
никаких
дальнейших
ошибок.
Типизация
ошибок
Узлы
CAN способны
отличить
временные
ошибки от
постоянных
отказов.
Дефектные
узлы будут
отключены.
Соединения
Линия
связи по
протоколу CAN —
это шина, к
которой
может быть
подключён
ряд узлов.
Количество
узлов не
имеет
никакого
теоретического
предела.
Фактически
количество
узлов будет
ограничено
временами
задержек и/или
электрической
нагрузкой
на линии
шины. Способ,
которым
выполнена
шина, не
установлен
в данной
спецификации.
Например,
это может
быть
одиночный
провод (+земля),
два
дифференциальных
провода,
оптическое
стекловолокно.
Уровни
шины
Шина
может
принимать
одно из
дополняющих
друг друга
значений:
«dominant» и «recessive». В
случае
одновременной
подачи «dominant»
бита и «recessive»
бита,
возникающее
в
результате
значение
шины будет
«dominant».
(Прим.
переводчика:
далее
считается
что «recessive» = лог.
«1», а «dominant» = «0»).
Подтверждение
Все
приёмники
проверяют
непротиворечивость
принимаемого
сообщения и
подтверждают
непротиворечивое
сообщение.
Режим
«сна» /
пробуждения
Чтобы
уменьшить
потребляемую
мощность
системы,
узел CAN может
быть
переведен в
режим «сна».
Режим «сна»
заканчивается
при любом
действии на
шине или
внутреннем
состоянии
системы. При
пробуждении
запускается
внутренняя
синхронизация,
канальный
уровень
ждёт
стабилизации
генератора
системы, а
затем будет
ожидать
самосинхронизации
к действиям
на шине (синхронизация
к действиям
на шине
заканчивается
после
принятия
последовательности
11 битов с лог.
«1»). Для
пробуждения
узла из
режима
покоя может
использоваться
некоторое
сообщение
пробуждения
со
специальным
идентификатором.
3.
Передача
сообщений
При
передаче
информации
с помощью
протокола CAN
используется
четыре типа
кадров. Кадр
данных
содержит
данные,
передаваемые
передатчиком
приёмнику (ам).
Кадр
удаленного
запроса
данных
передается
на шину для
запроса
передачи
кадра
данных с тем
же самым
идентификатором.
Кадр ошибки
передаётся
при
обнаружении
ошибки на
шине. Кадр
перегрузки
используется
для
обеспечения
дополнительной
задержки
между
предшествующим
и
последующим
кадрами
данных или
кадрами
удаленного
запроса
данных.
Кадры
данных и
кадры
удаленного
запроса
данных
отделяются
от
предшествующих
кадров
межкадровым
пространством.
3.1
Кадр данных
(DATA FRAME)
Кадр
данных
состоит из 7
различных
полей: «Начало
кадра», «поле
арбитража»,
«поле
контроля», «поле
данных», «поле
CRC», «поле
подтверждения»,
«конец
кадра».
Начало
кадра (Start of Frame)
Отмечает
начало
кадра
данных или
кадра
удаленного
запроса
данных.
Состоит из
бита с лог. ‘0’.
Узлу
разрешено
начинать
передачу
только при
свободной
шине (см.
простой
шины). Все
узлы должны
быть
синхронизированы
по началу
фронта,
вызванного
полем «начало
кадра» (см.
аппаратная
синхронизация)
узла,
начавшего
работу
первым.
Поле
арбитража
(Arbitration Field)
Состоит из
идентификатора
и RTR-бита.
CRC-последовательность
(CRC Sequence):
Для
вычисления CRC
полинома,
полином,
коэффициенты
которого
задаются
потоком,
состоящим
из значений,
бит полей: «начало
кадра «, «поле
арбитража»,
«поле
контроля», «поле
данных» (если
имеется) (самые
младшие 15
коэффициентов
полинома =0),
должен быть
разделён
полином
следующего
вида:
x^15+x^14+x^10+x^8+x^7+x^4+x^3+1
Остаток
этого
полиномиального
деления
есть CRC-последовательность,
передаваемая
по шине.
CRC-разделитель
(CRC Delimiter):
CRC-последовательность
сопровождается
CRC-разделителем,
который
всегда
равен лог. «1».
Поле
подтверждения
(ACK FIELD)
Длина
2 бита.
Содержит
область
подтверждения
(1 бит) и
разделитель
подтверждения
(1 бит). В поле
подтверждения
передающий
узел
посылает
два бита с
лог. «1».
Приемник,
получивший
правильное
сообщение,
информирует
об этом
передатчик,
посылая бит
с лог. «0» (т.е.
перезаписывая
бит в
области
подтверждения
с лог. «1» на
бит с лог. «0»).
Область
подтверждения
(ACK Slot)
Все
узлы,
получившие
соответствующую
CRC-последовательность,
сообщают об
этом внутри
области
подтверждения
перезаписью
бита с лог. «1»
на бит с лог.
«0».
Разделитель
подтверждения
(ACK Delimiter)
Второй
бит области
подтверждения
должен быть —
лог. «1».
Следовательно,
область
подтверждения
окружена
битами с лог.
«1» (CRC-разделитель
и
разделитель
подтверждения).
Конец
кадра (END OF FRAME)
Каждый
кадр данных
и кадр
удаленного
запроса
данных
разграничены
последовательностью
флагов,
состоящей
из семи
битов с лог.
«1».
3.2
Кадр
удаленного
запроса
данных (REMOTE FRAME)
Узел
может
инициализировать
передачу
кадра
данных
другим
узлом,
посылая
кадр
удаленного
запроса
данных.
Этот кадр
состоит из 6
полей:
«Начало
кадра», «поле
арбитража»,
«поле
контроля», «поле
CRC», «поле
подтверждения»,
«конец
кадра».
В отличие от
кадра
данных , RTR бит =
«1». Здесь нет
поля данных,
зависящего
от значения
«кода длины
данных»,
внутри
этого поля
может быть
записано
любое из
допустимых
значений (0��.8).
Полярность RTR
бита
показывает,
является ли
передаваемый
кадр кадром
данных или
кадром
удаленного
запроса
данных
3.3.
Кадр ошибки
(ERROR FRAME)
Состоит
из двух
различных
полей.
Первое поле
является
суперпозицией
флагов
ошибки
различных
узлов,
второе поле —
поле
разделителя
ошибки.
Для
корректного
завершения
кадра
ошибки, узлу
в состоянии
«пассивной
ошибки»
может быть
необходим
доступ к
шине,
поэтому
шина должна
быть
свободной,
по крайней
мере, три
времени
передачи
бита.
Следовательно,
шина не
должна быть
загружена
на 100%.
Флаг
ошибки (Error Flag):
Существует
2 формы флага
ошибки:
активный и
пассивный
флаг ошибки.
1.
активный
флаг ошибки
состоит из 6
последовательных
бит с лог. «0».
2.
пассивный
флаг ошибки
состоит из 6
последовательных
бит с лог. «1,
если они не
перезаписаны
битами с лог.
«0» других
узлов.
Узел в
состоянии «активной
ошибки» при
обнаружении
ошибки
передает
активный
флаг ошибки.
Форма флага
ошибки
нарушает
закон
кодирования
битового
потока
методом
разрядного
заполнения (см.
раздел «Кодирование
битового
потока»).
Вследствие
этого все
узлы
обнаруживают
условие
ошибки и
начинают
передавать
флаг ошибки.
В
результате,
последовательность
бит с лог. «0»,
контролируемая
на шине
является
суперпозицией
флагов
ошибок
отдельных
узлов. Общая
длина этой
последовательности
— от 6 до 12 бит с
лог. «0».
Узел в
состоянии «пассивной
ошибки» при
обнаружении
ошибки
передает
пассивный
флаг ошибки,
он ждет
последовательности
из 6
одинаковых
бит,
определяющих
начало
флага
пассивной
ошибки.
Когда эта
последовательность
будет
обнаружена,
флаг
пассивной
ошибки
будет
завершен.
Разделитель
ошибки (Error Delimiter)
Разделитель
ошибки
состоит из 8
бит с лог. «1».
После
передачи
флага
ошибки
каждый узел
посылает
биты с лог. «1»
и
контролирует
шину, пока не
обнаружит
бит с лог. «1».
Впоследствии
он начинает
передавать 7
бит с лог. «1».
3.4.
Кадр
перегрузки
(OVERLOAD FRAME)
Кадр
перегрузки
содержит
два битовых
поля: флаг
перегрузки
и
разделитель
перегрузки.
Имеются
два вида
перегрузки,
которые оба
приводят к
передаче
кадра
перегрузки.
1.
Внутреннее
состояние
приёмника,
которое
требует
задержки
следующего
кадра
данных или
кадра
удаленного
запроса
данных.
2.
Обнаружение
бита с лог. «0»
в течение
поля
перерыва (см.
межкадровое
пространство).
Передача
кадра
перегрузки
из-за
состояния 1
возможна
только в
первом
битовом
интервале
перерыва, в
то время как
кадры
перегрузки
по
состоянию 2
начинают
передаваться
на
следующем
битовом
интервале
после
обнаружения
бита с лог. «0».
Для больших
задержек
может быть
послано
несколько
кадров
перегрузки.
Флаг
перегрузки
(Overload flag)
Состоит
из 6 бит с лог.
«0». Формат
соответствует
активному
флагу
ошибки.
Форма флага
перегрузки
нарушает
фиксированную
форму поля
перерыва.
Поэтому,
другие узлы
также
обнаруживают
состояние
перегрузки
и в свою
очередь
начинают
передавать
флаг
перегрузки.
В случае
обнаружения
бита с лог. «0»
в течение
третьего
бита
перерыва,
некоторые
узлы не
будут
корректно
интерпретировать
флаг
перегрузки,
первый (из
шести) бит с
лог. «0» будет
принят за
поле «начало
кадра».
Шестой бит
флага
перегрузки
с лог. «0»
нарушает
закон
кодирования
битового
потока
методом
разрядного
заполнения (см.
раздел «Кодирование
битового
потока
методом
разрядного
заполнения»).
Разделитель
перегрузки
(Overload Delimiter)
Состоит
из 8 бит с лог.
«1».
Разделитель
перегрузки
имеет такую
же форму, как
и
разделитель
ошибки.
После
передачи
флага
перегрузки
узел
контролирует
шину, пока не
обнаружит
бит с лог. «1».
В этой точке
времени все
узлы уже
закончили
передавать
флаг
перегрузки
и начинают
передавать 7
бит с лог. «1».
4.
Межкадровое
пространство
(INTERFRAME SPACE)
Кадры
данных и
кадры
удаленного
запроса
данных
отделяются
от
предшествующих
кадров
любого типа (кадра
данных,
кадра
удаленного
запроса
данных,
кадра
ошибки,
кадра
перегрузки).
Это
разделяющее
битовое
поле
называется
межкадровым
пространством.
Кадрам
перегрузки
и кадрам
ошибки не
предшествует
межкадровое
пространство;
несколько
кадров
перегрузки
также не
отделяются
межкадровым
пространством.
Межкадровое
пространство
содержит
поля «перерыв»
и «простой
шины», и для
узла в
состоянии «пассивной
ошибки»,
который был
передатчиком
предыдущего
сообщения,
дополнительное
поле — «приостановка
передачи» (поле
«приостановка
передачи»
находится
между
полями «перерыв»
и «простой
шины»).
Поле
перерыва (Intermission)
Состоит
из 3 бит с лог.
«1». В течение
перерыва
никакому
узлу нельзя
начинать
передачу
кадра
данных или
кадра
удаленного
запроса
данных.
Единственно
возможное
действие —
это
сигнализация
состояния
перегрузки.
Простой
шины (Bus Idle)
Простой
шины может
иметь
произвольную
длину. Если
шина
опознана
как
свободная,
любой узел,
который
имеет что —
либо для
передачи
может
начать
передачу.
Сообщение,
которое
было
задержано
для
передачи
другого
сообщения,
начинает
передаваться
в первом
бите после
поля
перерыва.
Обнаружение
бита с лог. «0»
на шине в
течение
этого поля
интерпретируется
как поле «начало
кадра».
Приостановка
передачи
Узел
в состоянии
«пассивной
ошибки»,
после
передачи
сообщения,
посылает 8
бит с лог. «1»
после поля
перерыва,
перед
началом
передачи
дальнейших
сообщений
или
определением
занятости
шины. Если
тем
временем
началась
передача (вызванная
другим
узлом), узел
станет
приёмником
этого
сообщения.
5.
Определение
передатчика
/ приемника
Передатчик
Узел,
передающий
сообщение
называется
передатчиком
этого
сообщения.
Узел
является
передатчиком
до тех пор,
пока он не
потерял
арбитраж.
Приёмник
Узел
называется
приёмником
сообщения,
если он не
передатчик
сообщения и
шина занята.
6.
Корректность
сообщения
Точка
времени, в
которой
сообщение
является
корректным,
различна
для
передатчиков
и
приёмников
сообщений.
Передатчик
Сообщения
пригодно
для
передатчика,
если нет
ошибок до
конца кадра.
Если
сообщение
разрушено,
ретрансляция
будет
происходить
автоматически
и согласно
приоритетам.
Чтобы
решить
приоритеты
доступа к
шине с
другими
сообщениями,
ретрансляция
должна
начаться,
как только
шина
освободится.
Приёмник
Сообщение
корректно
для
приёмника,
если нет
ошибок до
конца кадра.
7.
Кодирование
битового
потока
Следующие
поля: «начало
кадра», «поле
арбитража»,
«поле
контроля», «поле
данных» и «поле
CRC»
кодированы
методом
разрядного
заполнения.
Всякий раз,
когда
передатчик
передает
пять
последовательных
бит
идентичной
величины в
битовом
потоке, он
автоматически
вставляет
дополняющий
бит
противоположного
значения в
фактически
передаваемый
битовый
поток.
Оставшиеся
битовые
поля кадра
данных или
кадра
удаленного
запроса
данных («разделитель
CRC», «поле
подтверждения»
и «конец
кадра»)
имеют
фиксированную
форму и не
кодируются.
Кадр ошибки
и кадр
перегрузки
также имеют
фиксированную
длину и не
кодируются
методом
разрядного
заполнения.
8.
Обработка
ошибок
Существует
пять типов
не
взаимоисключающих
ошибок:
- разрядная
ошибкаУзел,
который
посылает
что — либо на
шину также
контролирует
шину.
Разрядная
ошибка
может быть
обнаружена
во время
передачи
бита, если
переданное
значение
отличается
от
значения,
прочитанного
с шины.
Исключение:
При
посылке
бита с лог.
«1» в
течение
поля
арбитража
или
области
подтверждения
разрядная
ошибка не
возникает,
если
контролируется
бит с лог. «0».
Передатчик,
посылающий
флаг
пассивной
ошибки и
обнаруживший
бит с лог. «0»
не
интерпретирует
его как
разрядную
ошибку. - ошибка
заполненияОшибка
заполнения
обнаруживается
во время
приема
последовательности
из шести
бит
одинакового
разрядного
уровня в
поле
сообщения,
которое
должно
быть
кодировано
методом
разрядного
заполнения. - ошибка CRC
Последовательность
CRC состоит из
результата
вычисленного
передатчиком.
Приёмники
вычисляют CRC
таким же
образом,
как и
передатчик.
Ошибка CRC
обнаруживается
при
несовпадении
расчетного
результата
CRC —
последовательности
в
приёмнике
и
присланной
CRC —
последовательности
передатчика. - ошибка
форматаОшибка
формата
обнаруживается,
когда
разрядное
поле
фиксированного
формата
содержит
один или
несколько
лишних бит. - ошибка
подтвержденияОшибка
подтверждения
обнаруживается
передатчиком
всякий раз,
когда нет
контроля
бита с лог.
«0» в
течение
области
подтверждения.9.
Сигнализация
ошибокУзел,
обнаруживший
состояние
ошибки
сигнализирует
об этом
передачей
флага
ошибки. Для
узла в
состоянии «активной
ошибки» это
передача
флага
активной
ошибки, для
узла в
состоянии «пассивной
ошибки» это
передача
флага
пассивной
ошибки.
Всякий раз
при
обнаружении
разрядной
ошибки,
ошибки
заполнения,
ошибки
формата и
ошибки
подтверждения
узел
начинает
передавать
флаг
ошибки в
следующем
бите.
Всякий раз,
когда
обнаружена
ошибка CRC,
передача
флага
ошибки
будет
начата
после
разделителя
подтверждения,
если не
была
начата
передача
флага
ошибки для
другого
состояния.10.
Типизация
ошибокУзел
может быть
в одном из
трех
состояний: - активной
ошибки - пассивной
ошибки - отключения
от шины
В
состоянии «активной
ошибки»
узел может
взаимодействовать
с шиной,
посылая
флаг
активной
ошибки при
обнаружении
ошибки. В
состоянии «пассивной
ошибки»
узел не
должен
слать флаг
активной
ошибки. Он
принимает
участие во
взаимодействии
с шиной, но
при
обнаружении
ошибки
должен
послать
флаг
пассивной
ошибки.
После
передачи
сообщения
об ошибке,
узел в
состоянии «пассивной
ошибки»
будет ждать
инициализации
дальнейшей
передачи (см.
приостановка
передачи).
В состоянии
отключения
от шины узлу
не
разрешено
оказывать
влияние на
шину.
Для
типизации
ошибок у
каждого
узла — CAN есть
два
счетчика:
1.
счетчик
ошибок
передачи
2.
счетчик
ошибок
приема
(Прим.
переводчика:
Правила
модификации
счетчиков
здесь не
приводятся.
Но хочется
обратить
внимание на
то, что при
наличии
ошибок,
счетчики
увеличиваются
быстрей, чем
уменьшаются
при приемах
или
передачах
без ошибок).
Узел
находится в
состоянии «пассивной
ошибки»,
если
счетчик
ошибок
передачи и /
или счетчик
ошибок
приема
больше или
равен 128.
Узел
отключается
от шины, если
счетчик
ошибок
передачи
или приема
больше или
равен 256.
Узел,
находившиеся
в состоянии
«пассивной
ошибки»
переходит в
состояние «активной
ошибки»,
если
счетчик
ошибок
передачи и
счетчик
ошибок
приема
меньше или
равен 127.
Узлу,
который
находится в
состоянии «отключения
от шины»,
разрешается
перейти в
состояние «активной
ошибки», с
установкой
обоих
счетчиков в 0,
после того,
как на шине
будут
проконтролированы
128
прохождений
11
последовательных
битов с лог.
«1».
Обратите
внимание:
1.
Величина
счетчика
ошибки
большая, чем
96 указывает
на
серьезные
нарушения
на шине. Это
можно
использовать
для
проверки
состояния
шины.
2. Запуск /
Пробуждение:
Если в
некоторый
момент
времени
активен
только один
узел, и если
этот узел
передает
некоторое
сообщение,
он не
получит
подтверждения,
обнаруживается
ошибка и
происходит
повтор
сообщения.
Из-за этого
он может
перейти в
состояние «пассивной
ошибки», но
не может
перейти в
состояние «отключения
от шины».
10.
Требования
к
синхронизации
Номинальная
скорость
передачи
информации
в битах
Номинальная
скорость
передачи
информации
в битах —
число битов
за секунду,
передаваемое
в
отсутствии
пересинхронизации
идеальным
передатчиком.
Номинальное
время
передачи
бита
номинальное
время
передачи
бита = 1 /
номинальную
скорость
передачи
информации
Номинальное
время
передачи
бита можно
представить
как время,
разделенное
на
отдельные
не
перекрывающиеся
сегменты
времени. Это
сегменты:
—
Сегмент
синхронизации
(SYNC_SEG)
—
Сегмент
времени
распространения
(PROP_SEG)
—
Сегмент TSEG1 (PHASE_SEG1)
—
Сегмент TSEG2 (PHASE_SEG2)
SYNC SEG
Эта
часть
времени
передачи
бита
используется,
чтобы
синхронизировать
различные
узлы на шине.
Ожидается,
что фронт
сигнала
находится
внутри
этого
сегмента.
PROP SEG
Эта
часть
времени
передачи
бита
используется,
чтобы
компенсировать
физическую
задержку
времён
внутри сети.
Это
удвоенная
сумма
времени
распространения
сигнала по
шине,
входной
задержки
компаратора,
и выходной
задержки
формирователей.
TSEG1 и TSEG2.
Эти
сегменты
используются,
чтобы
компенсировать
ошибки
смещения
фазы
сигнала. Эти
сегменты
могут быть
удлинены
или
укорочены
пересинхронизацией.
Точка
считывания
(Sample point)
Точка
считывания —
точка
времени, в
которой
уровень
шины
читается и
интерпретируется,
как
величина
соответствующего
бита. Ее
место — в
конце TSEG1.
Время
обработки
информации
Время
обработки
информации —
отрезок
времени,
начинающийся
с точки
считывания,
зарезервированный
для
вычисления
уровня бита.
Квант
времени
Квант
времени —
фиксированная
единица
времени,
полученная
из периода
генератора.
Существует
программируемый
делитель,
оперирующий
целочисленными
величинами,
изменяющимися,
по крайней
мере, от 1 до 32.
Начиная с
минимального
кванта
времени,
квант
времени
может иметь
длительность:
квант
времени = m *
минимальный
квант
времени ,где m
— величина
делителя.
минимальный
квант
времени = 1 / f
генератора.
Длительность
отрезков
времени
- SYNC_SEG — 1 квант
времени . - PROP_SEG —
программируем,
1,2, …, 8 квантов. - TSEG1 —
программируем,
1,2, …, 8 квантов. - TSEG2 — максимум
из TSEG1 и
времени
обработки
информации - время
обработки
информации
— меньше или
равно 2
квантам.
12.
Синхронизация
Аппаратная
синхронизация
После
аппаратной
синхронизации
внутреннее
время
передачи
бита
перезапускается
с SYNC_SEG. Таким
образом,
аппаратная
синхронизация
вынуждает
фронт
находиться
внутри
сегмента SYNC_SEG.
Ширина
перехода
пересинхронизации
В
результате
пересинхронизации
TSEG1 может быть
удлинен, или
TSEG2 может быть
сокращен.
Количество
удлинения
или
сокращения
сегментов TSEGx
(x=1,2) имеет
верхний
предел,
связанный с
шириной
перехода
пересинхронизации.
Ширина
перехода
пересинхронизации
должна быть
программируема
между 1 и min(4, TSEG1).
Синхронизация
информации
может быть
получена из
переходов
от одного
бита к
другому.
Максимальная
длина между
двумя
переходами,
которые
могут
использоваться
для
пересинхронизации
— 29 времен
передачи
бита.
Фазовая
ошибка
фронта
Фазовая
ошибка
фронта
определяется
позицией
фронта
относительно
SYNC_SEG,
измеряется
в квантах
времени.
Знак
фазовой
ошибки
определяется
следующим
образом:
- e = 0, если
фронт
сигнала
находится
внутри SYNC_SEG. - e> 0, если
фронт
сигнала
перед
точкой
считывания. - e < 0, если
фронт
сигнала
после
точки
считывания
предыдущего
бита.
Пересинхронизация
Эффект
пересинхронизации
— также как и
от
аппаратной
синхронизации,
когда
величина
фазовой
ошибки
фронта
сигнала,
которая
вызывает
пересинхронизацию
— меньше или
равна
программируемой
величине
ширины
перехода
пересинхронизации.
Когда
величина
ошибки фазы
больше чем
ширина
перехода
пересинхронизации,
- и если
ошибка
фазы
положительна,
то TSEG1
удлиняется
на время
равное:
время
передачи
бита *
ширину
перехода
пересинхронизации. - и если
ошибка
фазы
отрицательна,
то TSEG2 —
сокращается
на время
равное:
время
передачи
бита *
ширину
перехода
пересинхронизации.
Правила
синхронизации
Синхронизация
и
пересинхронизация
— две формы
синхронизации.
На них
действуют
следующие
правила:
1.
Позволяется
только одна
синхронизация
внутри
одного
интервала
передачи
бита.
2. Для
синхронизации
будет
использоваться
фронт
только, если
величина,
полученная
в
предыдущей
точке
считывания (предыдущая
величина на
шине)
отличается
от величины
на шине
сразу после
фронта.
3.
Синхронизация
выполняется
всякий раз,
по фронту «1»
-> «0» в
течение
простоя
шины.
4. Все
другие
фронты «1» ->
«0» (и фронты
«0» -> «1» в
случае
низких
скоростей),
выполняемые
по правилам 1
и 2, будут
использоваться
для
пересинхронизации.
|
CAN 2.0 В |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1. CAN — Область Задача
Обратите Область
Область Внутри 2.
Послойная
Сообщения Информация Информационная В Гибкость Маршрутизация Групповая Непротиворечивость Скорость Скорость Приоритеты Идентификатор Удаленный Посылая Multimaster Когда Арбитраж Всякий Безопасность Для Обнаружение Для Эффективность Сигнализация Искаженные Типизация Узлы Подключение Последовательная Канал Шина Уровни Шина Подтверждение Все Режим Для Генератор Требования 3. Форматы
Типы Кадр Кадр Кадр
Начало Начало Поле Формат
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Идентификатор Идентификатор Идентификатор Base ID Base ID Extended ID Extended ID Бит Бит Бит Заменитель Бит Бит Поле Поле
Код Число |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Допустимое Поле Поле Поле Последовательность Последовательность Последовательность Поле Поле Область Все Разделитель Разделитель Конец Каждый Кадр Узел, Кадр Кадр
Для Флаг Имеются Разделитель Разделитель Кадр Кадр Флаг Состоит Замечание: Разделитель Состоит Межкадровое Кадры Межкадровое
Перерыв Состоит Замечание: Если Простой Период Приостановка После Стандартный Стандартный Определение Передатчик: Приемник: 4. Фильтрация Если 5. Момент Передатчик: Приемник: 6. Кодирование 7. Обнаружение
Передача Узел, Всякий Всякий 8. Неисправный
Узел в Для Замечание: Замечание: 9. Для Замечание: 10. Номинальная Номинальная номинальное Номинальное
Сегмент Используется Сегмент Используется, Сегменты Эти Точка Момент Время Время Шаг Шаг шаг Длительность
Общее 11. После Переход В Перехода Ошибка Ошибка
12. Эффект
Правила Аппаратная |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
CAN |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
CAN OSI модель
|
| CANopen | DeviceNet | SDS (V2.0) | |
| Name of Communication Object | Process Data Object | I/O-Message | Multicast Channel APDU |
| Maximal Number of Communication Objects per Device | 512 Transmit PDOs 512 Receive PDOs | 27 I/O- Transmit Messages 1701 I/O Receive Messages per device 32 Multicast Channels for each of up to |
32 Embedded Objects per device |
| Maximal length of Data Field | 8 bytes | 8 bytes fragmented: Arbitrary length | 6 bytes fragmented: 64 * 4 bytes |
| Protocol | Unfragmented: No overhead, Notify/Read «Stored-Event»-protocol (CAL/CMS) Unacknowledged |
Unfragmented: No overhead, three «Transport Classes» supported:
|
Unfragmented: 2 byte protocol overhead, Unacknowledged |
| Fragmented: Unacknowledged fragmented protocol 1 byte protocol overhead per frame |
Fragmented: Acknowledged fragmented protocol with Acknowledge after reception of complete block 4 bytes protocol overhead per fragment |
||
| Message Production Triggering Modes |
|
|
Specified by object model |
| Mapping of Application Objects | Maximum number of mappable application objects/PDO dependent on data size of objects (1-bit objects: 64 application objects mappable) Definition of Application objects by means of «Mapping Parameter Record» (configurable) Dynamic mapping supported |
Arbitrary number of Application objects mappable with fragmented protocol. Definition of Application objects by means of Assembly Object (several Assembly Objects possible) Dynamic mapping supported |
Network Data Descriptor defines size, granularity and data type of I/O data of Embedded |
Вызов (triggering)
сообщений
Все
рассматриваемые
протоколы
поддерживают
различные
способы
вызова
сообщений.
DeviceNet
поддерживает
циклический
(Cyclic), по
состоянию
(Change-of-State) и
программный
(Application) способы
вызова.
Циклический
вызов
осуществляется
по
истечению
времени
таймера и
начинается
передача
сообщения.
Передача
по
состоянию
начинается,
когда
статус
определенного
объекта
изменяется.
В этом
случае
сообщение
также
передается,
когда
истекает
определенный
интервал
времени, в
котором не
осуществлялась
передача
сообщения.
Программным
способом
сам объект
решает,
когда
начать
передачу
сообщения.
В этом
случае
сообщение
также
передается,
когда
истекает
определенный
интервал
времени
без
передачи
сообщения.
Установление
соответствий
(mapping) для
программных
объектов
Сетевые
устройства
обычно
содержат
более
одного
программного
объекта и
передача I/O
сообщения
более чем
одному
программному
объекту
внутри
одного PDO
является
необходимым
требованием.
В DeviceNet
объединение
прикладных
данных
осуществляется
посредством
трансляционных
(assembly) объектов,
которые
определяют
формат
передаваемых
данных.
Устройство
может
содержать
более
одного I/O
трансляционного
объекта и
выбор
подходящего
(consumed/ produced_connection_path)
может быть
настраиваемой
опцией
устройства.
Прямые
(peer-to-peer)
коммуникационные
каналы
Для
конфигурации
устройств
посредством
конфигурационных
средств
требуются
специальные
функции у
устройств
или
программы,
обеспечивающие
многоцелевые
каналы
связи. Это
не
критичные
по времени
каналы
связи.
Передача
данных в
них
осуществляется
посредством
протокола
с
подтверждениями
и
фрагментацией.
Любой из
протоколов
высокого
уровня,
которые
поддерживают
некоторую
конфигурацию
устройств,
должны
обеспечивать
этот вид
связи.
DeviceNet
обеспечивает
многоцелевые
устройство
ориентированные
каналы и
сервисы.
Запись и
чтение
атрибутов
объектов,
контролирование
объектов (reset,
start, stop etc.),
сохранение/восстановление
атрибутов
объектов
осуществляется
посредством
явных (Explicit)
сообщений.
Намерение
использовать
данное
сообщение
определяется
в поле
данных CANа.
На рис. 7
показан
формат
поля
данных
фрагментированного
Explicit
сообщения.
В запросе
сервиса
указывается
номер
класса,
номер
экземпляра(instance),
номер
атрибута (в
поле Service specific arguments).
Рис. 6. DeviceNet Fragemented
Explicit Message Data Field Format (Request/Response)
Explicit(прямая)
связь
устанавливается
посредством
менеджера
сообщений
(Unconnected Message Manager (UCMM)). UCMM
предоставляет
два
сервиса
для
открывания
и
закрывания
подобных
соединений.
Каждое
устройство,
поддерживающее
UCMM,
резервирует
у себя
идентификаторы
сообщений
для
запросов и
ответов
для UCMM. Для
устройств 2-й
группы,
которые не
поддерживают
UCMM порт, master
устройство
сперва
должно
разместить
Explicit
соединение
в
предопределенном
множестве
соединений.
Запрос к
устройству
группы 2
передается
как Explicit
запрос без
предварительного
установления
соединения
(Unconnected Explicit Request ) с
зарезервированным
идентификатором
сообщения.
Сравнительные
характеристики
протоколов
CANopen, DeviceNet и SDS в
отношении
прямых (peer-to-peer)
коммуникационных
каналов
представлены
в таблице 2.
Таблица
2. Main Characteristics of Peer-to-Peer Communication Channels
| CANopen | DeviceNet | SDS (V2.0) | |
| Name | Service Data Channel | Explicit Message | Peer-to-peer Channel |
| Maximum number of channels | 128 Client SDOs, 128 Server SDOs per device | 27 Explicit Transmit Messages 1701 Explicit Receive messages per device |
4 channels per Embedded Object. 32 Embedded Objects per Logical Device |
| Protocol | < 5 byte: Acknowledged unfragmented 4 byte: Fragmented transmission (7 bytes per fragment) Each frame acknowledged Any length (CAL Multiplexed Domain protocol) |
< 7 byte: Acknowledged unfragmented 6 byte: Fragmented transmission. (6 bytes per fragment) Each frame acknowledged Any length |
< 6 bytes Acknowledged unfragmented 5 byte Fragmented transmission (3 bytes per fragment) Acknowledgement of complete data block. Max. 255 byte |
| Establishing of Connections |
|
|
|
| Connection Services and Arguments | Initiate, Abort Upload/Download Segment/Domain | Open/Close Creation, Configuration, Start, Stop, Reset etc. of Objects |
Open/Close Read, Write, Event, Action |
| Index and Subindex of addressed | Object Directory Entry Object attribute access path, Service arguments |
Channel Number, Attribute/Action/Event Identifier |
Установление
связей для
обмена
данных
процесса
Распределение
идентификаторов
для
передаваемых
сообщений
и ,
соответственно,
получаемых
сообщений
устанавливает
коммуникационные
пути в CAN
сети.
Установление
взаимодействия
возможно
через
использование
предопределенного
множества
сообщений
с уже
размещенными
идентификаторами
сообщений
или через
переменное
распределение
идентификаторов
для
сообщений.
В
системе с
предопределенным
множеством
сообщений
«функции»
и
идентификаторы
сообщений
уже
определены.
DeviceNet также
использует
предопределенное
множество
сообщений
для
системы со
структурой
1:n. Master
устройство,
предварительно
разместив
у себя
множество
связей со Slave
устройствами,
«знает» ID
сообщений
для
передачи
запроса и ID
сообщений
для
получения
ответа,
который
включает Slave
MAC-ID в
соответствии
с
предопределенным
множеством
связей.
Также
возможно
не
предопределять
идентификаторы
сообщений.
Сетевое
управление
Так
как в CAN-сети
мы имеем
дело с
распределенными
приложениями,
должны
отслеживаться
определенные
события(отказы
различных
частей
приложения
или отказ
устройств).
Поэтому
главными
задачами
сетевого
управления
становятся
обнаружение
и вывод
ошибок в
сети и
предоставление
сервисов,
позволяющих
контролировать
статусы
устройств
и вести
координацию
устройств.
В
зависимости
от
системных
решений
сетевое
управление
может
вестись
явным или
косвенным
путем.
В DeviceNet
каждое
соединение
контролируется.
Поэтому
каждая
ожидающая
сообщение
конечная
точка
имеет «Inactivity/Watchdog»
таймер,
чтобы
контролировать
прибытие
сообщения
согласно
предопределенному
времени
ожидания.
Если время
истекает,
соединение
выполняет
действие
«Timeout». На рис. 7
показана
диаграмма
изменения
состояний
у объекта I/O.
Рис. 7. Device Net I/O
Connection Object State Transition Diagram
После
получения
вызова CREAT ( Explicit
сообщение)
соединение
настраивается
при помощи
подходящей
последовательности
вызовов
явных
сообщений
и после
этого
устанавливается.
Перед
получением
доступа к
сети
каждое
устройство
должно
совершить
проверку
на
дубликат
своего MAC-ID.
Определенные
алгоритмы
выбора
гарантируют
уникальность
MAC-ID.
Контроль
может
осуществляться
также
посредством
Heartbeat
сообщения,
которое
может
посылаться
устройствам
посредством
UCMM в форме
сообщения.
В поле
данных
этого
сообщения
передается
состояние
устройства.
Heartbeat
сообщение
вызывается
объектом Idendity.
Профайлы
устройств
Для
открытых
автоматических
систем
помимо
обеспечения
связи от
входящих в
их состав
устройств
требуется
также
обеспечение
возможности
взаимодействия
и
взаимозаменяемости.
Поэтому
протоколы
высокого
уровня (такие
как DeviceNet)
описывают
функциональные
возможности
устройств
в виде
модели
устройства
(«Device Model»).
Помимо
описания
функциональности
устройств
модель
устройства
должна
также
содержать
ряд важных
параметров
(статус,
диагностическую
информацию,
коммуникационные
возможности,
конфигурационные
параметры
и т.д.). На рис. 8
показана
модель
устройства
DeviceNet.
Рис. 8. DeviceNet Object Model
DeviceNet
профайл
должен
содержать
следующую
информацию:
- модель
объекта
для
устройства - формат
данных I/O
для
устройства - конфигурационные
данные и
внешние
интерфейсы
для этих
данных
В
таблице 3
показаны
главные
функции
объектов в
DeviceNet.
Таблица
3. Objects of a DeviceNet node
| Object | Function |
| Connection | Instantiates connections (I/O or Explicit Messaging) |
| DeviceNet | Maintains configuration and status of physical attachments to DeviceNet. |
| Message Router | Routes received Explicit Messages to appropriate target objects |
| Assembly | Groups attributes of multiple objects into a single block of data, which can be sent and received over a single connection |
| Parameter | Provides a standard means for device configuration and attribute access |
| Identity | Provides general information about the identity of a device |
| Application | Supplies application-specific behaviour and data |
Заключение
Протокол
CAN
применяется
в real-time
системах
для
решения
различных
задач. В
настоящий
момент
развиваются
несколько
видов CAN
протоколов
высокого
уровня,
таких как CAL
,OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS ,CAN-Kingdom , в
основе
которых
лежит
канальный
протокол CAN2.0
(Bosch) , и на
основе
этих
протоколов
можно
решать
проблемы,
возникающие
в real-time
системах,
которые
невозможно
разрешить
при помощи
других
известных
протоколов,
скажем, TCP/IP.
2.6.1. Физический уровень
2.6.2. Канальный уровень
2.6.3. Прикладной уровень: CANopen
2.6.4. Электронные спецификации устройств CANopen
CAN (Controller Area Network — «область, охваченная сетью контроллеров») представляет собой комплекс стандартов для построения распределенных промышленных сетей, который использует последовательную передачу данных в реальном времени с очень высокой степенью надежности и защищенности. Центральное место в CAN занимает протокол канального уровня модели OSI. Первоначально CAN был разработан для автомобильной промышленности, но в настоящее время быстро внедряется в область промышленной автоматизации. Это хорошо продуманный, современный и многообещающий сетевой протокол. Начало развития CAN было положено компанией Bosch в 1983 г., первые микросхемы CANконтроллеров были выпущены фирмами Intel и Philips в 1987 году, в настоящее время контроллеры и трансиверы CANвыпускаются многими фирмами, в том числе Analog Devices, Inc., Atmel Corp. Cast, Dallas Semiconductor, Freescale, Infineon, Inicore Inc., Intel, Linear Technology, Maxim Integrated Products, Melexis, Microchip, National Semiconductor, NXP, OKI, Renesas Technology Corp., STMicroelectronics, Yamar Electronics, Texas Instruments.
В России интерес к CAN за последние годы сильно возрос, однако контроллерного оборудования для CAN в России крайне мало, в десятки или сотни раз меньше, чем для Modbus или Profibus. Среди протоколов прикладного уровня для работы с CAN наибольшее распространение в России получили CANopen и DeviceNet.
В настоящее время CAN поддерживается 11-ю стандартами ISO, в том числе [ISO — Diagnostics].
CAN охватывает два уровня модели OSI: физический и канальный (табл. 2.7). Стандарт не предусматривает никакого протокола прикладного (7-го) уровня модели OSI. Поэтому для его воплощения в жизнь различные фирмы разработали несколько таких протоколов: CANopen (организации CiA), SDS (фирмы Honeywell Micro Switch Division), CAN Kingdom (фирмы Kvaser), DeviceNet (фирмы Allen-Bradley, ставший Европейским стандартом в 2002 г.) и ряд других [Грибанов — Третьяков].
CAN характеризуется следующими основными свойствами:
- каждому сообщению (а не устройству) устанавливается свой приоритет;
- гарантированная величина паузы между двумя актами обмена;
- гибкость конфигурирования и возможность модернизации системы;
- широковещательный прием сообщений с синхронизацией времени;
- непротиворечивость данных на уровне всей системы;
- допустимость нескольких ведущих устройств в сети («многомастерная сеть»);
- способность к обнаружению ошибок и сигнализации об их наличии;
- автоматический повтор передачи сообщений, доставленных с ошибкой, сразу, как только сеть станет свободной;
- автоматическое различение сбоев и отказов с возможностью автоматического отключения отказавших модулей.
К недостаткам можно отнести сравнительно высокую стоимость CAN-устройств, отсутствие единого протокола прикладного уровня, а также чрезмерную сложность и запутанность протоколов канального и прикладного уровня, изложенных в стандартах организации CAN in Automation (CiA).
2.6.1. Физический уровень
Физический уровень [Robert — CAN] модели OSI обеспечивает надежную передачу битов, игнорируя содержание передаваемой информации. Основными понятиями физического уровня являются линии передачи (в большинстве случаев это витая пара, хотя допускается использовать плоский кабель или один провод и «корпусную землю», оптоволокно, радиоканал), временные диаграммы, система синхронизации, формат данных, обеспечение достоверности передачи (контрольная сумма, методы кодирования, обнаружение и восстановление ошибок). Характеристики передатчика и приемника стандартом не устанавливаются, поскольку они могут быть выбраны для каждого конкретного случая исходя из требований применения.
|
Табл. 2.7. CAN в соответствии с моделью OSI |
|||
|
№ |
Название уровня |
Подуровни CAN |
Примечание |
|
7 |
Прикладной |
Стандартом CAN не установлен. Определен стандартами , CANopen, DeviceNet, SDS, CAN, Kingdom и др. |
|
|
6 |
Представления |
Нет |
Нет |
|
5 |
Сеансовый |
Нет |
Нет |
|
4 |
Транспортный |
Нет |
Нет |
|
3 |
Сетевой |
Нет |
Нет |
|
2 |
Канальный (передачи данных) |
LLC |
Подтверждение фильтрации, уведомление о перегрузке, управление восстановлением данных |
|
МАС |
Формирование пакетов данных, кодирование, управление доступом, обнаружение ошибок, сигнализация об ошибках, подтверждение приема, преобразование из последовательной формы в параллельную и обратно |
||
|
1 |
Физический |
Физический |
Обеспечение надежной передачи на уровне байтов (кодирование, контрольная сумма, временные диаграммы, синхронизация). Требования к линии передачи |
Примечание: MAC — Medium Access Control — «управление доступом к каналу»; LLC — Logical Link Control — «управление логическими связями».
Электрические соединения в сети CAN
Кабель витой пары в сети CAN должен иметь общий (третий) провод; на обоих концах витой пары должны быть согласующие резисторы, сопротивление которых равно волновому сопротивлению кабеля. Максимальная длина кабеля составляет 1 км. Для увеличения длины, количества узлов или гальванической развязки могут быть использованы повторители интерфейса, сетевые мосты и шлюзы.
Витая пара может быть в экране или без, в зависимости от электромагнитной обстановки. Топология сети должна быть шинной, максимальная длина отвода от шины при скорости передачи 1 Мбит/с не должна превышать 30 см. Длину отвода можно рассчитать по формуле [CAN]
где 
— длительность переднего фронта передатчика. Основные требования к линии передачи и ее характеристикам близки к RS-485, однако в передатчиках CAN есть режим управления длительностью фронтов импульсов. Управление выполняется путем заряда емкостей затворов выходных транзисторов от источников тока, при этом величина тока задается внешним резистором. Увеличение длительности фронта позволяет снизить требования к согласованию линии на низких частотах, увеличить длину отводов и ослабить излучение электромагнитных помех.
Выводы «земли» всех передатчиков сети должны быть соединены (если интерфейсы гальванически не изолированы). При этом разность потенциалов между выводами заземлений не должна превышать 2 В. Гальваническая изоляция рекомендуется при длине линии более 200 м, но не является обязательным требованием стандарта.
Для электрического соединения устройств с CAN интерфейсом стандарт предусматривает два варианта. Первый вариант состоит в применении Т-образных разветвителей, которые состоят из трех 9-штырьковых разъемов D-sub, расположенных в одном корпусе, одноименные контакты которых соединены между собой. Разветвители имеют один разъем со штырьками и два — с гнездами.
Второй вариант требует наличия в каждом CAN-устройстве двух разъемов. Для включения устройства в сеть кабель разрезают и на его концах устанавливают ответные части разъемов. Устройство включается буквально в разрыв линии передачи. Такой подход позволяет наращивать количество устройств и изменять топологию сети путем добавления в разрыв кабеля новых устройств и кабеля с разъемами на концах. Один из разъемов должен быть со штырьками, второй — с гнездами. Подключение устройств к шине без разъемов не допускается. Согласующий резистор должен располагаться внутри разъема, который подключается к концу кабеля. Для присоединения модулей к CAN-шине должен использоваться 9-штырьковый разъем типа D- Sub. На модуле устанавливается разъем с гнездами, на соединяющем кабеле — со штырьками. Цоколевка разъемов показана в табл. 2.8.
Применение разъемов со штырьками или гнездами определяется следующим правилом: при «горячей» замене модулей питание должно оставаться только на разъемах с гнездами; это позволяет избежать случайного короткого замыкания.
Отметим, что в основанном на CAN стандарте CANopen предусмотрено гораздо большее разнообразие вариантов разъемов, в том числе для плоского кабеля, RJ-10, RJ45, разъемный винтовой клеммник, и еще около десяти вариантов специальной конструкции [Cabling]. Допускается применение и других разъемов.
|
Табл. 2.8. Цоколевка разъема D-sub для CAN |
||
|
Контакт |
Сигнал |
Примечание |
|
1 |
— |
Зарезервирован |
|
2 |
CAN_ L |
Сигнал линии |
|
3 |
CAN_ GND |
«Земля» |
|
4 |
— |
Зарезервирован |
|
5 |
(CAN_ SHLD) |
Экран кабеля (не обязательно) |
|
6 |
(GND) |
«Земля» (не обязательно) |
|
7 |
CAN_ H |
Сигнал линии |
|
8 |
— |
Зарезервирован |
|
9 |
(CAN_ V+) |
Внешнее питание (не обязательно, для питания передатчиков с гальванической изоляцией) |
Примечание. В каждом модуле контакты 3 и 6 должны быть соединены
Стандарт устанавливает следующие скорости обмена: 1 Мбит/с, 800 кбит/с, 500 кбит/с, 250 кбит/с, 125 кбит/с, 50 кбит/с, 20 кбит/с. CAN-модули могут поддерживать не все скорости, но желательно, чтобы их количество было наибольшим.
Трансивер CAN
Типовая структура трансивера CAN (на примере микросхемы LT1795 фирмы Linear Technology) приведена на рис. 2.20. При подаче уровня логического нуля на вход 
(вход является инвертирующим) оба транзистора выходного каскада передатчика открываются и через нагрузку (два резистора по 120 Ом) течет ток, создающий в линии состояние, соответствующее логической единице. При этом потенциал вывода 
всегда будет выше, чем вывода 
(рис. 2.21). Значения потенциалов, предусмотренные стандартом, приведены в табл. 2.9. При логической единице на входе передатчика его выход переходит в высокоомное состояние и дифференциальное напряжение на линии становится равным нулю.
Отметим, что наличие терминальных резисторов в CAN необходимо не только для согласования линии (как в случае RS-485), но даже для создания пути протекания тока.
|
|
|
Рис. 2.20. Структурная схема трансивера CAN |
CAN передатчик имеет очень важное свойство: если один из передатчиков устанавливает в сети логический ноль, а второй — логическую единицу, то это состояние не является аварийным, как в сети на основе интерфейса RS-485, поскольку сквозного тока не возникает. В случае CAN линия остается в состоянии логической единицы. Иначе говоря, логическая единица всегда доминирует над логическим нулем. Поэтому в стандарте CAN используется понятие «доминантное состояние« (доминирующее) состояние линии для обозначения состояния линии с током, и понятие «рецессивное состояние» как противоположное доминантному (рис. 2.21).
Это свойство CAN обеспечивает возможность получения доступа к линии, сравнивая посылаемые в линию логические уровни с тем уровнем, который фактически устанавливается в ней: если передатчик посылает в линию рецессивное состояние, а в ней при этом остается доминантное, значит линия занята. Доступ получает тот узел сети, который может предоставить ей доминантный уровень сигнала. Узлы с рецессивным уровнем покидают линию и ждут следующего случая. Этот метод доступа справедлив и при использовании оптоволоконного канала или беспроводной сети — в этих случаях наличие света или электромагнитной волны всегда будет доминировать над их отсутствием.
Вывод 
на рис. 2.20 позволяет установить пороговое напряжение для входа и уровень синфазного напряжения в линии, когда она находится в рецессивном состоянии. Обычно = 2,5 В. Чтобы установить уровень синфазного напряжения на линии, терминальные сопротивления делят на два по 60 Ом, соединяют их последовательно, а к точке соединения подключают вывод . При симметричной форме импульсов и относительно рецессивного состояния уменьшается уровень излучаемых помех, поскольку приращения токов в каждом из проводов витой пары при переключении логических уровней (см. рис. 2.21) оказываются равными по величине, но обратными по знаку и поэтому компенсируют друг-друга.
Вывод 
имеет несколько назначений. Если на нем установлено состояние логической единицы, трансивер переходит в спящий режим, при котором он потребляет очень малый ток от источника питания, а на выходе устанавливается высокоомное (рецессивное) состояние. «Разбудить» его можно сигналом, поступающим в приемник из линии передачи. Подключение этого вывода к «земле» через сопротивление позволяет установить нужную длительность фронтов импульсов передатчика. Некоторые трансиверы имеют два режима: резервный и спящий, которые отличаются уровнем потребляемого тока и способом перевода в активный режим. Режим пониженного энергопотребления предусмотрен стандартом для экономии заряда аккумуляторных батарей в припаркованном автомобиле.
|
|
|
Рис. 2.21. Пояснение понятий рецессивного и доминантного состояния |
Если сигнал является доминирующим слишком долго (более 1 мс), генератор импульса таймаута (на рис. 2.20 обозначен прямоугольником с импульсом) временно отключает передатчик, поскольку в противном случае модуль может быть навсегда блокирован средствами канального уровня как отказавший.
Стандартом предусмотрена возможность подключения к CAN сети любого количества устройств, однако практически оно ограничивается нагрузочной способностью передатчиков (100…200) или задержкой в повторителях.
В CAN-трансивере имеется генератор синхроимпульсов с частотой 16 МГц ±0,1%. Ширина одного бита программно устанавливается величиной от 8 до 25 импульсов синхрогенератора, обычно 8 импульсов при скорости передачи 1 Мбит/с и 16 импульсов при 20 кбит/с. Синхронизация всех узлов сети происходит в течение первого такта синхронизации. Процедура обработки битов в приемнике обеспечивает программируемую задержку импульсов синхронизации, необходимую для компенсации времени задержки прохождения сигнала в линии связи и сдвига фазы вследствие дрейфа частоты тактового генератора.
Различают два типа синхронизации: жесткую синхронизацию с помощью стартового бита в начале сообщения и ресинхронизацию во время передачи сообщения. С помощью ресинхронизации можно подстроить интервал времени от начала синхронизации до момента, в который измеряется логический уровень принимаемого импульса данных. Интервал подстройки может быть изменен на 1…4 такта.
Для определения логического состояния шины уровни принимаемых сигналов измеряются на расстоянии 6-ти тактов синхрогенератора от переднего фронта импульса (бита) при скорости 1 Мбит/с и на расстоянии 14-ти тактов при скорости 20 кбит/с [CAN] (для сравнения укажем, что в стандартных UART отсчеты берутся посередине импульса). Количество отсчетов может быть 1 или 3 (устанавливается программно). CAN использует синхронную передачу битов. Это повышает пропускную способность канала связи, но требует усложненного процесса синхронизации.
|
Табл. 2.9. Значения потенциалов на линии передачи CAN |
||||||
|
Параметр |
Обозначение |
Ед. измерения |
Мин. |
Ном. |
Макс |
Условие |
|
Для рецессивного состояния шины |
||||||
|
Потенциалы на выходе передатчика |
CAN_H |
В |
2,0 |
2,5 |
3 |
Без нагрузки |
|
CAN_L |
В |
2,0 |
2,5 |
3 |
||
|
Дифференциальное напряжение на выходе передатчика |
Vdiff |
мВ |
-500 |
0 |
50 |
Без нагрузки |
|
Дифференциальное напряжение на входе приемника |
Vdiff |
В |
-1 |
— |
0,5 |
Без нагрузки |
|
Для доминантного состояния шины |
||||||
|
Потенциалы на выходе передатчика |
CAN_H |
В |
2,75 |
3,5 |
4,5 |
С нагрузкой |
|
CAN_L |
В |
0,5 |
1,5 |
2,25 |
||
|
Дифференциальное напряжение на выходе передатчика |
Vdiff |
В |
1,5 |
2 |
3 |
С нагрузкой |
|
Дифференциальное напряжение на входе приемника |
Vdiff |
В |
-0,9 |
— |
5 |
С нагрузкой |
Напряжение питания устройств в сети CAN должно составлять от 18 до 30 В. Выходное напряжение на 9-м контакте разъема (внешнее положительное напряжение питания) должно быть от +7 В до +13 В при токе потребления модуля не более 100 мА. Не допускается, чтобы модули были источниками тока.
CAN использует NRZ кодирование (Non Return-to-Zero — «без возврата к нулю», «потенциальное кодирование»), при котором логическому нулю соответствует низкий уровень напряжения в линии (рецессивное состояние), логической единице — высокий уровень (доминантное состояние). Такой способ имеет следующий недостаток: в случае, когда через линию передачи транспортируется байт, который содержит все единицы (пауз между ними при NRZ кодировании нет), приемник не может отличить этот байт от паузы. Для устранения этой проблемы используется так называемый бит-стаффинг. Он состоит в том, что после каждой последовательности из 5-ти одинаковых символов подряд вставляется противоположный им символ. Например, после 5-ти единиц подряд вставляется логический ноль. Приемник, обнаружив 5 одинаковых символов подряд, удаляет следующий за ними символ, который является битом стаффинга.
Другими свойствами CAN-трансиверов, которые предусмотрены в стандарте, являются:
- защита от короткого замыкания проводов интерфейса между собой, на источник питания или землю. Из этих требования автоматически следует защита от изменения полярности подключения приемника и передатчика к линии, обрывов и передавливания кабеля;
- защита от электростатических разрядов;
- ослабление синфазного сигнала в лини;
- защита от перегрева выходных каскадов.
2.6.2. Канальный уровень
В соответствии с [CAN] канальный уровень CAN состоит из двух подуровней: LLC и MAC (см. табл. 2.7). Ниже описаны только главные идеи, положенные в основу их функционирования.
Адресация и доступ к шине
В CAN сети ни один из узлов не имеет адреса. Вместо этого сообщения посылаются «всем», но содержат идентификатор, который описывает смысл посылаемых данных. В соответствии с этим смыслом любой узел сети может принять это сообщение, если оно необходимо устройству для функционирования. Сообщение принимается узлом, если его идентификатор проходит через фильтр сообщений, имеющийся в каждом узле.
В CAN сети гарантируется, что сообщение будет принято любым из узлов в одно и то же время или не будет принято ни одним из них. Это достигается благодаря широковещательной передаче и использованным методом подтверждения приема сообщений.
Когда сеть свободна, любой узел может начать передачу сообщения. Но каждое сообщение имеет свой приоритет при получении доступа к шине. Поэтому передачу может осуществить только одно устройство — то, которое содержит сообщение с наивысшим приоритетом.
Борьба за доступ к шине происходит следующим образом. Если два или более устройств обнаружили, что линия свободна и начали передачу сообщений одновременно, то возникший конфликт разрешается путем побитного сравнения идентификатора передаваемого сообщения с состоянием линии. В процессе арбитража (урегулирования конфликта) каждое устройство сравнивает логический уровень передаваемого бита с логическим уровнем на шине. Если эти уровни одинаковы, устройства продолжают передавать следующий бит идентификатора. Если приемник устройства показывает, что на шине доминантный уровень, а передатчик в это же время передает рецессивный уровень, то устройство сразу прекращает передачу данного сообщения. Такой механизм арбитража гарантирует, что ни информация, ни время не будут потеряны.
Достоверность передачи
Для достижения максимальной надежности (достоверности) передачи данных протокол предусматривает специальные методы обнаружения ошибок, сигнализации об ошибках и самоконтроля, которые воплощены в каждом узле сети.
Для обнаружения ошибок приняты следующие меры:
- передатчик сравнивает каждый бит на шине с переданным битом для подтверждения правильности передачи на уровне битов;
- выполняется контроль циклическим избыточным кодом (CRC — Cyclic Redundancy Check);
- используется бит-стаффинг (см. выше);
- используется проверка каждого переданного фрейма.
Механизм обнаружения ошибок характеризуется такими свойствами:
- обнаруживаются все глобальные ошибки;
- обнаруживаются все ошибки, вносимые передатчиком;
- в сообщении обнаруживаются до 5 случайно распределенных ошибок;
- в сообщениях обнаруживается пакет следующих друг за другом ошибок длиной до 15 бит;
- обнаруживаются ошибки четности.
Вероятность наличия в сообщении необнаруженных ошибок составляет менее 
.
Сообщения с обнаруженными ошибками помечаются флагом в том узле, где они были обнаружены. Такие сообщения отклоняются и автоматически передаются повторно. Время от момента обнаружения ошибки до начала повторной передачи равно длительности 31-го бита, если не возникают новые ошибки.
CAN способен различать сбои и отказы. Если произошел отказ, то отказавшее устройство отключается от сети.
Все приемники сети проверяют целостность (непротиворечивость) полученных сообщений, подтверждают (квитируют) целостные сообщения и помечают флагом противоречивые сообщения.
Передача сообщений
Сообщения в CAN передаются с помощью фреймов (блоков данных). Используется два разных формата фреймов, которые различаются длиной поля идентификатора: стандартный фрейм с идентификатором длиной 11 бит и расширенный фрейм с длиной идентификатора 29 бит.
Существует 4 различных типа фреймов:
- DATA FRAME — «фрейм данных» — переносит данные от передатчика к приемнику;
- REMOTE FRAME — «дистанционный фрейм» (фрейм вызова) — передается одним из устройств для того, чтобы получить от другого устройства данные в формате DATA FRAME с тем же идентификатором, что и в REMOTE FRAME;
- ERROR FRAME — «фрейм ошибок» — передается любым устройством, обнаружившим ошибку на шине;
- OVERLOAD FRAME — «фрейм перегрузки» — используется для запроса дополнительной задержки между предыдущими и последующими данными.
Фрейм данных состоит из следующих полей (рис. 2.22): начало фрейма (Start Of Frame), поле арбитража (Arbitration Field), поле контроля (Control Field), поле данных (Data Field), поле циклического избыточного кода (CRC Field), поле уведомления о приеме (ACKnowledgement Field) и поле конца фрейма (End Of Frame). Поле данных может иметь нулевую длину.
Пространство между фреймами представлено рецессивным состоянием шины (которое соответствует высокому уровню на рис. 2.22, поскольку CAN-передатчики инвертируют логические уровни). Только при рецессивном состоянии шины устройство может начать передачу фрейма.
Начало фрейма кодируется одним доминантным битом. Все устройства сети одновременно синхронизируют свои приемники по переднему фронту импульса этого бита.
Формат поля арбитража различается для стандартного и расширенного формата фрейма. В стандартном фрейме поле арбитража состоит из идентификатора длинной 11 бит и RTR-бита (Remote Transmission Request — «запрос дистанционной передачи»).
В расширенном формате поле арбитража имеет идентификатор длиной 29 бит, SRR-бит (Substitute Remote Request — «заменяющий RTR-бит»), IDE-бит (Identifier Extension Bit — «бит идентификации расширенного формата») и RTR-бит. Поле идентификатора в расширенном формате состоит из базового идентификатора и расширенного идентификатора. Базовый идентификатор определяет приоритет расширенного фрейма. RTR-бит служит для того, чтобы отличить фрейм данных от фрейма вызова. IDE-бит служит для различения стандартного и расширенного формата фреймов.
|
|
|
Рис. 2.22. Структура фрейма данных |
Поле контроля включает в себя код, который указывает длину данных в поле данных, IDE-бит и один (в стандартном формате) или два (в расширенном) зарезервированных бита.
Поле данных состоит из данных, которые должны быть переданы фреймом данных. Он может иметь длину от 0 до 8 байт по 8 бит каждый. Данные передаются младшим разрядом вперед.
Поле CRC содержит циклический избыточный код, служащий для обнаружения ошибок во всех предшествующих ему полях фрейма, включая бит начала фрейма. Поле CRC оканчивается CRC-разделителем (рецессивное состояние) длиной в 1 бит. Стандарт CAN устанавливает алгоритм вычисления CRC [Robert]. Биты стаффинга перед вычислением удаляются.
Поле уведомления имеет длину 2 бита. Передающее устройство в этом поле посылает два рецессивных бита. Принимающее устройство отвечает доминантным битом, если сообщение принято без ошибок. Второй бит этого поля всегда является рецессивным.
Конец фрейма представляет собой последовательность из семи рецессивных бит.
Фрейм вызова выполняет функцию запроса данных. Он аналогичен фрейму данных, но отличается от него только отсутствием поля данных и другими значениями битов.
Фрейм ошибок используется любым принимающим узлом, чтобы сообщить всем участникам сети о том, что передаваемое в данный момент по сети сообщение содержит ошибку. Первым полем в фрейме ошибок является флаг ошибки. Сообщение об ошибке имеет наивысший в системе приоритет, поэтому передается сразу после обнаружения ошибки и принимается всеми устройствами одновременно. Все устройства также одновременно удаляют из своей памяти сообщение, содержащее ошибку.
Фрейм перегрузки состоит из двух полей: флага перегрузки и поля разделителя. Существуют следующие условия, при наступлении которых начинается передача фрейма перегрузки:
- перегрузка приемника, которая требует увеличить паузу между принимаемыми им фреймами;
- обнаружение доминантного бита на месте первого и второго бита в поле перерыва паузы между фреймами.
Пауза между фреймами
Между фреймами данных, фреймом вызова и любыми другими фреймами устанавливается пауза. В отличие от этого, перед фреймами перегрузки и ошибок паузы нет, это ускоряет их доставку.
Пауза содержит поле перерыва (3 бита) и поле простоя (произвольной длины) и, для пассивных к ошибке устройств, которые выполняли передачу предыдущего сообщения, поле приостановленной передачи.
Фильтрация сообщений
Фильтрация сообщений используется для выбора из всех сообщений на шине только тех, которые соответствуют маске, записанной в регистр приемника. Маска может быть настроена на отбор группы сообщений и использует идентификатор, входящий в состав поля арбитража на рис. 2.22. Отобранные сообщения помещаются в буфер приемника.
Валидация сообщений
Под валидацией понимается установление факта, что сообщение не содержит ошибок. Момент времени, в который устанавливается факт правильности сообщения, отличается для передатчика и приемника.
Сообщение считается достоверно переданным, если не было ошибок при передаче от начала до конца фрейма. Если сообщение содержало ошибку, оно автоматически повторяется в соответствии с текущими приоритетами.
Сообщение считается достоверно принятым, если не было обнаружен ошибок при его приеме. Если ошибка обнаружена, устройство посылает в шину флаг ошибки.
В CAN рассматривается 5 типов ошибок:
- ошибки передачи бита (контролируется уровень на шине и сравнивает с передаваемым. Ошибка обнаруживается во время передачи одного бита);
- ошибка стаффинга (обнаруживается при отсутствии бита стаффинга в 6-й позиции последовательности одинаковых битов);
- CRC-ошибка;
- ошибка формата (обнаруживается, если при заранее фиксированном формате фрейма поле с известным значением битов содержит неправильные биты);
- ошибка уведомления (обнаруживается трансивером, если он не находит доминантное состояние в поле уведомления о получении).
Устройство, обнаружившее любую из перечисленных ошибок, сигнализирует об этом с помощью флага ошибки.
2.6.3. Прикладной уровень: CANopen
Прикладной уровень модели OSI обеспечивает интерфейс между сетью и программным приложением, которое может взаимодействовать с аналогичными приложениями в других устройствах сети. На прикладном уровне реализуется также механизм синхронизации между устройствами.
К сожалению, разработка CAN закончилась на первых двух уровнях модели OSI. Это привело к появлению множества несовместимых между собой протоколов прикладного уровня, среди которых самыми распространенными и поддерживаемыми организацией CiA являются CANopen [CANopen — CANopen] и DeviceNet
Канальный уровень CAN, рассмотренный выше, практически невозможно использовать в SCADA-пакетах, поскольку он оперирует битами, фреймами, полями. Для написания же прикладных программ нужно использовать понятия: переменная, массив, событие, клиент, сервер, имя устройства и т. п.
Рассмотрим наиболее распространенный стандарт прикладного уровня CANopen [CANopen]. Для упрощения применения стандарта вводятся несколько специфических для CANopen понятий. Все функциональные возможности прикладного уровня делятся между так называемыми сервисами (элементами услуг). Программные приложения взаимодействуют между собой путем вызова соответствующих сервисов прикладного уровня. Сервисы обмениваются данными с равными им (одноранговыми) сервисами через CAN-сеть с помощью определенного протокола. Этот протокол описывается в спецификации протокола сервиса.
Вводится понятие сервисного примитива, который представляет собой средство (языковую конструкцию), с помощью которого программное приложение взаимодействует с прикладным уровнем. В CANopen существует четыре различных примитива:
- запрос приложения к прикладному уровню, публикуемый приложением для вызова сервиса;
- индикация, публикуемая прикладным уровнем для приложения, чтобы сообщить о внутренних событиях, обнаруженных прикладным уровнем или чтобы показать, что сервис запрошен;
- ответ, публикуемый приложением для прикладного уровня, чтобы ответить на ранее полученную индикацию;
- подтверждение, публикуемое прикладным уровнем для приложения, чтобы отчитаться о результатах ранее изданного запроса.
Cервисы также делятся на несколько типов сервисов:
- локальный сервис — который выполняет запрос приложения без взаимодействия с другими сервисами того же ранга;
- неподтвержденный сервис — который вовлекает в выполнение запроса один или более других одноранговых сервисов. Приложение посылает запрос к локальному сервису. Этот запрос передается далее сервису (сервисам) того же ранга;
- подтвержденный сервис может вовлечь только один сервисный объект того же ранга. Приложение издает запрос к его локальному сервису. Этот запрос передается сервису того же ранга, который передает его другому приложению как индикацию. Другое приложение издает ответ, который передается исходному сервису, который передает его как подтверждение запрашивающему приложению;
- сервис, инициированный провайдером — вовлекает только локальный сервис.
CANopen предлагает серию стандартизованных коммуникационных механизмов и функций, выполняемых устройствами в сети (профилей). Серия профилей доступна и поддерживается организацией CiA (CAN in Automation); для ее использования не требуется лицензий.
Устройство в сети CANopen представляется состоящим из трех частей:
- коммуникационный интерфейс (к шине CAN) и программный протокол обмена;
- словарь объектов;
- интерфейс к устройствам ввода-вывода и прикладная программа.
Коммуникационный интерфейс и программный протокол обеспечивают сервис по передаче и получению через сеть коммуникационных объектов. Словарь объектов описывает типы данных, коммуникационные объекты и прикладные объекты, использованные в устройстве для обмена через интерфейс к устройствам ввода вывода. Прикладная программа обеспечивает внутреннее управление функциями устройства и интерфейсом к устройствам ввода-вывода.
Наиболее важной частью устройства в CANopen является словарь объектов. Под объектами понимаются типы данных, профили устройств, коммуникационные объекты, регистр ошибок. Каждый объект в словаре адресуется 16-битным индексом.
В CANopen используются следующие типы данных: Boolean, Integer, UnsignedN, Float, Date, Time, которые имеют общепринятый смысл. Имеется также несколько сложных типов данных для PDO и SDO параметров ( Process Data Object — объект данных технологического процесса и Service Data Object — объект сервисных данных).
Объекты PDO и SDO используются для передачи данных. Сообщения PDO позволяют передавать данные в реальном времени. Существует два типа объектов PDO. Первый из них выполняет передачу данных ( Transmit-PDO или TPDO), второй — прием данных (Receve- PDO или RPDO). Коммуникационные параметры PDO определяют его коммуникационные возможности и описываются в словаре объектов.
Объект SDO обеспечивает доступ к словарю объектов. SDO может использоваться также для передачи групп данных от клиента к серверу и наоборот.
Имеются также объекты специального назначения (объекты для синхронизации, объекты меток времени, объекты аварийных ситуаций), а также объекты управления сетью (объекты начальной загрузки, объекты контроля ошибок и сообщения для управления сетью).
Коммуникационные модели
Коммуникационная модель CANopen определяет различные коммуникационные объекты и сервисы, а также доступные режимы запуска передачи сообщений, поддерживает передачу синхронных и асинхронных сообщений. Синхронные сообщения используются для сбора данных или управления исполнительными устройствами. Синхронные сообщения передаются относительно сообщений синхронизации, которые определяются заранее; асинхронные сообщения могут передаваться в любое время.
В CANopen используют три типа взаимодействий между передающим и принимающим устройством:
- ведущий/ведомый;
- клиент/сервер;
- производитель/потребитель.
2.6.4. Электронные спецификации устройств CANopen
Поскольку устройства, используемые в сети, являются программируемыми, перед их включением в сеть необходимо задать параметры, необходимые для их коммуникаций с сетью и функционирования. CANopen устанавливает для этого стандартизованный метод. Метод предполагает наличие электронного описания устройств в текстовом формате, для обработки которого достаточно несложного компилятора. CANopen определяет формат EDS (Electronic Data Sheet — «электронный список параметров»), который описывает конфигурацию и параметры устройств, в том числе контроллеров с модульной архитектурой.
EDS поддерживается и поставляется производителем устройства. В противном случае используется EDS «по умолчанию», общий для определенного класса устройств, например, модулей аналогового ввода.
EDS является текстовым файлом, использующим ASCII-коды (набор символов по стандарту ISO 646). Длина строки файла — 255 символов, строки должны оканчиваться символами CR или LF.
Файл содержит несколько секций:
- информация о самом файле (имя файла, версия, дата создания, версия EDS, описание, кем создан, дата модификации и др.);
- общая информация об устройстве (имя производителя, идентификационный код производителя, имя устройства, код устройства, номер версии, функции устройства, список поддерживаемых скоростей обмена, наличие программы начальной загрузки и др.);
- конфигурационные параметры (длительность цикла обмена, тип устройства, тип данных, нижний и верхний предел изменения переменных, значения по умолчанию, количество каналов ввода-вывода и др.).
Полное описание структуры EDS файла дано в стандарте [CAN].
Продолжая использовать наш сайт, вы даете согласие на обработку файлов cookies и персональных данных в соответсвии с политикой. Окей, не возражаю