Professional Documents
Culture Documents
CAN Specification
Version 2.0
Recital
• Part A describing the CAN message format as it is defined in CAN Specification 1.2;
• Part B describing both standard and extended message formats.
In order to be compatible with this CAN Specification 2.0 it is required that a CAN
implementation be compatible with either Part A or Part B.
Note
1 INTRODUCTION................................................................................4
2 BASIC CONCEPTS............................................................................5
5 CODING .............................................................................................22
6 ERROR HANDLING...........................................................................23
6.1 Error Detection ...................................................................................23
6.2 Error Signalling...................................................................................23
7 FAULT CONFINEMENT.....................................................................24
1 INTRODUCTION
The Controller Area Network (CAN) is a serial communications protocol which
efficiently supports distributed realtime control with a very high level of security.
Its domain of application ranges from high speed networks to low cost multiplex wiring.
In automotive electronics, engine control units, sensors, anti-skid-systems, etc. are
connected using CAN with bitrates up to 1 Mbit/s. At the same time it is cost effective to
build into vehicle body electronics, e.g. lamp clusters, electric windows etc. to replace
the wiring harness otherwise required.
The intention of this specification is to achieve compatibility between any two CAN
implementations. Compatibility, however, has different aspects regarding e.g. electrical
features and the interpretation of data to be transferred. To achieve design
transparency and implementation flexibility CAN has been subdivided into different
layers.
The object layer and the transfer layer comprise all services and functions of the data
link layer defined by the ISO/OSI model. The scope of the object layer includes
There is much freedom in defining object handling. The scope of the transfer layer
mainly is the transfer protocol, i.e. controlling the framing, performing arbitration, error
checking, error signalling and fault confinement. Within the transfer layer it is decided
whether the bus is free for starting a new transmission or whether a reception is just
starting. Also some general features of the bit timing are regarded as part of the
transfer layer. It is in the nature of the transfer layer that there is no freedom for
modifications.
The scope of the physical layer is the actual transfer of the bits between the different
nodes with respect to all electrical properties. Within one network the physical layer, of
course, has to be the same for all nodes. There may be, however, much freedom in
selecting a physical layer.
The scope of this specification is to define the transfer layer and the consequences of
the CAN protocol on the surrounding layers.
2 BASIC CONCEPTS
CAN has the following properties
• prioritization of messages
• guarantee of latency times
• configuration flexibility
• multicast reception with time synchronization
• system wide data consistency
• multimaster
• error detection and signalling
• automatic retransmission of corrupted messages as soon as the bus is idle again
• distinction between temporary errors and permanent failures of nodes and
autonomous switching off of defect nodes
Application Layer
Object Layer
- Message Filtering
- Message and Status Handling
Transfer Layer
- Fault Confinement
- Error Detection and Signalling
- Message Validation
- Acknowledgment
- Arbitration
- Message Framing
- Transfer Rate and Timing
Physical Layer
- Signal Level and Bit Representation
- Transmission Medium
• The Physical Layer defines how signals are actually transmitted. Within this
specification the physical layer is not defined so as to allow transmission medium
and signal level implementations to be optimized for their application.
• The Transfer Layer represents the kernel of the CAN protocol. It presents
messages received to the object layer and accepts messages to be transmitted
from the object layer. The transfer layer is responsible for bit timing and
synchronization, message framing, arbitration, acknowledgment, error detection and
signalling, and fault confinement.
• The Object Layer is concerned with message filtering as well as status and
message handling.
The scope of this specification is to define the transfer layer and the consequences of
the CAN protocol on the surrounding layers.
Messages
Information on the bus is sent in fixed format messages of different but limited length
(see section 3: Message Transfer). When the bus is free any connected unit may start
to transmit a new message.
Information Routing
In CAN systems a CAN node does not make use of any information about the system
configuration (e.g. station addresses). This has several important consequences.
System Flexibility: Nodes can be added to the CAN network without requiring
any change in the software or hardware of any node and application layer.
Bit rate
The speed of CAN may be different in different systems. However, in a given system
the bitrate is uniform and fixed.
Priorities
The IDENTIFIER defines a static message priority during bus access.
Multimaster
When the bus is free any unit may start to transmit a message. The unit with the
message of higher priority to be transmitted gains bus access.
Arbitration
Whenever the bus is free, any unit may start to transmit a message. If 2 or more units
start transmitting messages at the same time, the bus access conflict is resolved by
bitwise arbitration using the IDENTIFIER. The mechanism of arbitration guarantees that
neither information nor time is lost. If a DATA FRAME and a REMOTE FRAME with the
same IDENTIFIER are initiated at the same time, the DATA FRAME prevails over the
REMOTE FRAME. During arbitration every transmitter compares the level of the bit
transmitted with the level that is monitored on the bus. If these levels are equal the unit
may continue to send. When a ’recessive’ level is sent and a ’dominant’ level is
monitored (see Bus Values), the unit has lost arbitration and must withdraw without
sending one more bit.
Safety
In order to achieve the utmost safety of data transfer, powerful measures for error
detection, signalling and self-checking are implemented in every CAN node.
Error Detection
For detecting errors the following measures have been taken:
- Monitoring (transmitters compare the bit levels to be transmitted with the bit
levels detected on the bus)
- Cyclic Redundancy Check
- Bit Stuffing
- Message Frame Check
Total residual error probability for undetected corrupted messages: less than
Fault Confinement
CAN nodes are able to distinguish short disturbances from permanent failures.
Defective nodes are switched off.
Connections
The CAN serial communication link is a bus to which a number of units may be
connected. This number has no theoretical limit. Practically the total number of units
will be limited by delay times and/or electrical loads on the bus line.
Single Channel
The bus consists of a single channel that carries bits. From this data resynchronization
information can be derived. The way in which this channel is implemented is not fixed
in this specification. E.g. single wire (plus ground), two differential wires, optical fibres,
etc.
Bus values
The bus can have one of two complementary logical values: ’dominant’ or ’recessive’.
During simultaneous transmission of ’dominant’ and ’recessive’ bits, the resulting bus
value will be ’dominant’. For example, in case of a wired-AND implementation of the
bus, the ’dominant’ level would be represented by a logical ’0’ and the ’recessive’ level
by a logical ’1’. Physical states (e.g. electrical voltage, light) that represent the logical
levels are not given in this specification.
Acknowledgment
All receivers check the consistency of the message being received and will
acknowledge a consistent message and flag an inconsistent message.
3 MESSAGE TRANSFER
3.1 Frame Types
DATA FRAMEs and REMOTE FRAMEs are separated from preceding frames by an
INTERFRAME SPACE.
Interframe Interframe
DATA FRAME
Space Space
or
Overload
Frame
Start of Frame
Arbitration Field
Control Field
Data Field
CRC Field
ACK Field
End of Frame
START OF FRAME
marks the beginning of DATA FRAMES and REMOTE FRAMEs. It consists of a single
’dominant’ bit.
A station is only allowed to start transmission when the bus is idle (see BUS IDLE). All
stations have to synchronize to the leading edge caused by START OF FRAME (see
’HARD SYNCHRONIZATION’) of the station starting transmission first.
ARBITRATION FIELD
The ARBITRATION FIELD consists of the IDENTIFIER and the RTR-BIT.
RTR Bit
Identifier
IDENTIFIER
The IDENTIFIER’s length is 11 bits. These bits are transmitted in the order from ID-10
to ID-0. The least significant bit is ID-0. The 7 most significant bits (ID-10 - ID-4) must
not be all ’recessive’.
RTR BIT
Remote Transmission Request BIT
In DATA FRAMEs the RTR BIT has to be ’dominant’. Within a REMOTE FRAME the
RTR BIT has to be ’recessive’.
CONTROL FIELD
The CONTROL FIELD consists of six bits. It includes the DATA LENGTH CODE and
two bits reserved for future expansion. The reserved bits have to be sent ’dominant’.
Receivers accept ’dominant’ and ’recessive’ bits in all combinations.
or
r1 r0 DLC3 DLC2 DLC1 DLC0 CRC
Field
abbreviations: d ’dominant’
r ’recessive’
0 d d d d
1 d d d r
2 d d r d
3 d d r r
4 d r d d
5 d r d r
6 d r r d
7 d r r r
8 r d d d
DATA FIELD
The DATA FIELD consists of the data to be transferred within a DATA FRAME. It can
contain from 0 to 8 bytes, which each contain 8 bits which are transferred MSB first.
CRC FIELD
contains the CRC SEQUENCE followed by a CRC DELIMITER.
Control
Field
CRC Delimiter
CRC Sequence
CRC SEQUENCE
The frame check sequence is derived from a cyclic redundancy code best suited for
frames with bit counts less than 127 bits (BCH Code).
In order to carry out the CRC calculation the polynomial to be divided is defined as the
polynomial, the coefficients of which are given by the destuffed bit stream consisting of
START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD (if
present) and, for the 15 lowest coefficients, by 0. This polynomial is divided (the
coefficients are calculated modulo-2) by the generator-polynomial:
The remainder of this polynomial division is the CRC SEQUENCE transmitted over the
bus. In order to implement this function, a 15 bit shift register CRC_RG(14:0) can be
used. If NXTBIT denotes the next bit of the bit stream, given by the destuffed bit
sequence from START OF FRAME until the end of the DATA FIELD, the CRC
SEQUENCE is calculated as follows:
IF CRCNXT THEN
CRC_RG(14:0) = CRC_RG(14:0) EXOR (4599hex);
ENDIF
UNTIL (CRC SEQUENCE starts or there is an ERROR condition)
After the transmission / reception of the last bit of the DATA FIELD, CRC_RG contains
the CRC sequence.
CRC DELIMITER
The CRC SEQUENCE is followed by the CRC DELIMITER which consists of a single
’recessive’ bit.
ACK FIELD
The ACK FIELD is two bits long and contains the ACK SLOT and the ACK DELIMITER.
In the ACK FIELD the transmitting station sends two ’recessive’ bits.
A RECEIVER which has received a valid message correctly, reports this to the
TRANSMITTER by sending a ’dominant’ bit during the ACK SLOT (it sends ’ACK’).
ACK Delimiter
ACK Slot
ACK SLOT
All stations having received the matching CRC SEQUENCE report this within the ACK
SLOT by superscribing the ’recessive’ bit of the TRANSMITTER by a ’dominant’ bit.
ACK DELIMITER
The ACK DELIMITER is the second bit of the ACK FIELD and has to be a ’recessive’
bit. As a consequence, the ACK SLOT is surrounded by two ’recessive’ bits (CRC
DELIMITER, ACK DELIMITER).
END OF FRAME
Each DATA FRAME and REMOTE FRAME is delimited by a flag sequence consisting
of seven ’recessive’ bits.
A station acting as a RECEIVER for certain data can initiate the transmission of the
respective data by its source node by sending a REMOTE FRAME.
A REMOTE FRAME is composed of six different bit fields:
START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, CRC FIELD, ACK
FIELD, END OF FRAME.
Contrary to DATA FRAMEs, the RTR bit of REMOTE FRAMEs is ’recessive’. There is
no DATA FIELD, independent of the values of the DATA LENGTH CODE which may
be signed any value within the admissible range 0...8. The value is the DATA LENGTH
CODE of the corresponding DATA FRAME.
Start of Frame
Arbitration Field
Control Field
CRC Field
ACK Field
End of Frame
The polarity of the RTR bit indicates whether a transmitted frame is a DATA FRAME
(RTR bit ’dominant’) or a REMOTE FRAME (RTR bit ’recessive’).
The ERROR FRAME consists of two different fields. The first field is given by the
superposition of ERROR FLAGs contributed from different stations. The following
second field is the ERROR DELIMITER.
superposition of
Error Flags Error Delimiter
In order to terminate an ERROR FRAME correctly, an ’error passive’ node may need
the bus to be ’bus idle’ for at least 3 bit times (if there is a local error at an ’error
passive’ receiver). Therefore the bus should not be loaded to 100%.
ERROR FLAG
There are 2 forms of an ERROR FLAG: an ACTIVE ERROR FLAG and a PASSIVE
ERROR FLAG.
2. The PASSIVE ERROR FLAG consists of six consecutive ’recessive’ bits unless it
is overwritten by ’dominant’ bits from other nodes.
of equal polarity, beginning at the start of the PASSIVE ERROR FLAG. The PASSIVE
ERROR FLAG is complete when these 6 equal bits have been detected.
ERROR DELIMITER
The ERROR DELIMITER consists of eight ’recessive’ bits.
After transmission of an ERROR FLAG each station sends ’recessive’ bits and
monitors the bus until it detects a ’recessive’ bit. Afterwards it starts transmitting seven
more ’recessive’ bits.
The OVERLOAD FRAME contains the two bit fields OVERLOAD FLAG and
OVERLOAD DELIMITER.
There are two kinds of OVERLOAD conditions, which both lead to the transmission of
an OVERLOAD FLAG:
1. The internal conditions of a receiver, which requires a delay of the next DATA
FRAME or REMOTE FRAME.
Overload Overload
Flag Frame
superposition of
Overload Flags Overload Delimiter
At most two OVERLOAD FRAMEs may be generated to delay the next DATA or
REMOTE FRAME.
OVERLOAD FLAG
consists of six ’dominant’ bits. The overall form corresponds to that of the ACTIVE
ERROR FLAG.
The OVERLOAD FLAG’s form destroys the fixed form of the INTERMISSION field. As
a consequence, all other stations also detect an OVERLOAD condition and on their
part start transmission of an OVERLOAD FLAG. (In case that there is a ’dominant’ bit
detected during the 3rd bit of INTERMISSION locally at some node, the other nodes
will not interpret the OVERLOAD FLAG correctly, but interpret the first of these six
’dominant’ bits as START OF FRAME. The sixth ’dominant’ bit violates the rule of bit
stuffing causing an error condition).
OVERLOAD DELIMITER
consists of eight ’recessive’ bits.
The OVERLOAD DELIMITER is of the same form as the ERROR DELIMITER. After
transmission of an OVERLOAD FLAG the station monitors the bus until it detects a
transition from a ’dominant’ to a ’recessive’ bit. At this point of time every bus station
has finished sending its OVERLOAD FLAG and all stations start transmission of seven
more ’recessive’ bits in coincidence.
DATA FRAMEs and REMOTE FRAMEs are separated from preceding frames
whatever type they are (DATA FRAME, REMOTE FRAME, ERROR FRAME,
OVERLOAD FRAME) by a bit field called INTERFRAME SPACE. In contrast,
OVERLOAD FRAMEs and ERROR FRAMEs are not preceded by an INTERFRAME
SPACE and multiple OVERLOAD FRAMEs are not separated by an INTERFRAME
SPACE.
INTERFRAME SPACE
contains the bit fields INTERMISSION and BUS IDLE and, for ’error passive’ stations,
which have been TRANSMITTER of the previous message, SUSPEND
TRANSMISSION.
For stations which are not ’error passive’ or have been RECEIVER of the previous
message:
For ’error passive’ stations which have been TRANSMITTER of the previous message:
Bus Idle
Suspend Transmission
Intermission
INTERMISSION
consists of three ’recessive’ bits.
BUS IDLE
The period of BUS IDLE may be of arbitrary length. The bus is recognized to be free
and any station having something to transmit can access the bus. A message, which is
pending for transmission during the transmission of another message, is started in the
first bit following INTERMISSION.
The detection of a ’dominant’ bit on the bus is interpreted as a START OF FRAME.
SUSPEND TRANSMISSION
After an ’error passive’ station has transmitted a message, it sends eight ’recessive’
bits following INTERMISSION, before starting to transmit a further message or
recognizing the bus to be idle. If meanwhile a transmission (caused by another station)
starts, the station will become receiver of this message.
TRANSMITTER
A unit originating a message is called “TRANSMITTER” of that message. The unit stays
TRANSMITTER until the bus is idle or the unit loses ARBITRATION.
RECEIVER
A unit is called “RECEIVER” of a message, if it is not TRANSMITTER of that message
and the bus is not idle.
4 MESSAGE VALIDATION
The point of time at which a message is taken to be valid, is different for the transmitter
and the receivers of the message.
Transmitter:
The message is valid for the transmitter, if there is no error until the end of END OF
FRAME. If a message is corrupted, retransmission will follow automatically and
according to prioritization. In order to be able to compete for bus access with other
messages, retransmission has to start as soon as the bus is idle.
Receivers:
The message is valid for the receivers, if there is no error until the last but one bit of
END OF FRAME.
5 CODING
BIT STREAM CODING
6 ERROR HANDLING
6.1 Error Detection
There are 5 different error types (which are not mutually exclusive):
• BIT ERROR
A unit that is sending a bit on the bus also monitors the bus. A BIT ERROR has to
be detected at that bit time, when the bit value that is monitored is different from the
bit value that is sent. An exception is the sending of a ’recessive’ bit during the
stuffed bit stream of the ARBITRATION FIELD or during the ACK SLOT. Then no
BIT ERROR occurs when a ’dominant’ bit is monitored. A TRANSMITTER sending
a PASSIVE ERROR FLAG and detecting a ’dominant’ bit does not interpret this as
a BIT ERROR.
• STUFF ERROR
A STUFF ERROR has to be detected at the bit time of the 6th consecutive equal bit
level in a message field that should be coded by the method of bit stuffing.
• CRC ERROR
The CRC sequence consists of the result of the CRC calculation by the transmitter.
The receivers calculate the CRC in the same way as the transmitter. A CRC
ERROR has to be detected, if the calculated result is not the same as that received
in the CRC sequence.
• FORM ERROR
A FORM ERROR has to be detected when a fixed-form bit field contains one or
more illegal bits.
• ACKNOWLEDGMENT ERROR
An ACKNOWLEDGMENT ERROR has to be detected by a transmitter whenever it
does not monitor a ’dominant’ bit during the ACK SLOT.
7 FAULT CONFINEMENT
With respect to fault confinement a unit may be in one of three states:
• ’error active’
• ’error passive’
• ’bus off’
An ’error active’ unit can normally take part in bus communication and sends an
ACTIVE ERROR FLAG when an error has been detected.
An ’error passive’ unit must not send an ACTIVE ERROR FLAG. It takes part in bus
communication but when an error has been detected only a PASSIVE ERROR FLAG is
sent. Also after a transmission, an ’error passive’ unit will wait before initiating a further
transmission. (See SUSPEND TRANSMISSION)
A ’bus off’ unit is not allowed to have any influence on the bus. (E.g. output drivers
switched off.)
For fault confinement two counts are implemented in every bus unit:
2. When a RECEIVER detects a ’dominant’ bit as the first bit after sending an ERROR
FLAG the RECEIVE ERROR COUNT will be increased by 8.
Exception 1:
If the TRANSMITTER is ’error passive’ and detects an ACKNOWLEDGMENT
ERROR because of not detecting a ’dominant’ ACK and does not detect a
’dominant’ bit while sending its PASSIVE ERROR FLAG.
Exception 2:
If the TRANSMITTER sends an ERROR FLAG because a STUFF ERROR occurred
during ARBITRATION whereby the STUFFBIT is located before the RTR bit, and
should have been ’recessive’, and has been sent as ’recessive’ but monitored as
’dominant’.
7. After the successful transmission of a message (getting ACK and no error until END
OF FRAME is finished) the TRANSMIT ERROR COUNT is decreased by 1 unless it
was already 0.
8. After the successful reception of a message (reception without error up to the ACK
SLOT and the successful sending of the ACK bit), the RECEIVE ERROR COUNT is
decreased by 1, if it was between 1 and 127. If the RECEIVE ERROR COUNT was
0, it stays 0, and if it was greater than 127, then it will be set to a value between 119
and 127.
9. A node is ’error passive’ when the TRANSMIT ERROR COUNT equals or exceeds
128, or when the RECEIVE ERROR COUNT equals or exceeds 128. An error
condition letting a node become ’error passive’ causes the node to send an ACTIVE
ERROR FLAG.
10. A node is ’bus off’ when the TRANSMIT ERROR COUNT is greater than or equal to
256.
11. An ’error passive’ node becomes ’error active’ again when both the TRANSMIT
ERROR COUNT and the RECEIVE ERROR COUNT are less than or equal to 127.
12. An node which is ’bus off’ is permitted to become ’error active’ (no longer ’bus off’)
with its error counters both set to 0 after 128 occurrence of 11 consecutive
’recessive’ bits have been monitored on the bus.
Note:
An error count value greater than about 96 indicates a heavily disturbed bus. It may be
of advantage to provide means to test for this condition.
Note:
Start-up / Wake-up:
If during start-up only 1 node is online, and if this node transmits some message, it will
get no acknowledgment, detect an error and repeat the message. It can become ’error
passive’ but not ’bus off’ due to this reason.
The Nominal Bit Time can be thought of as being divided into separate non-overlapping
time segments. These segments
Sample Point
Fig. 1 Partition of the Bit Time
SYNC SEG
This part of the bit time is used to synchronize the various nodes on the bus. An edge
is expected to lie within this segment.
PROP SEG
This part of the bit time is used to compensate for the physical delay times within the
network.
It is twice the sum of the signal’s propagation time on the bus line, the input comparator
delay, and the output driver delay.
SAMPLE POINT
The SAMPLE POINT is the point of time at which the bus level is read and interpreted
as the value of that respective bit. It’s location is at the end of PHASE_SEG1.
TIME QUANTUM
The TIME QUANTUM is a fixed unit of time derived from the oscillator period. There
exists a programmable prescaler, with integral values, ranging at least from 1 to 32.
Starting with the MINIMUM TIME QUANTUM, the TIME QUANTUM can have a length
of
TIME QUANTUM = m * MINIMUM TIME QUANTUM
The total number of TIME QUANTA in a bit time has to be programmable at least from
8 to 25.
SYNCHRONIZATION
HARD SYNCHRONIZATION
After a HARD SYNCHRONIZATION the internal bit time is restarted with SYNC_SEG.
Thus HARD SYNCHRONIZATION forces the edge which has caused the HARD
SYNCHRONIZATION to lie within the SYNCHRONIZATION SEGMENT of the
restarted bit time.
• e < 0 if the edge lies after the SAMPLE POINT of the previous bit.
RESYNCHRONIZATION
The effect of a RESYNCHRONIZATION is the same as that of a HARD
SYNCHRONIZATION, when the magnitude of the PHASE ERROR of the edge which
causes the RESYNCHRONIZATION is less than or equal to the programmed value of
the RESYNCHRONIZATION JUMP WIDTH. When the magnitude of the PHASE
ERROR is larger than the RESYNCHRONIZATION JUMP WIDTH,
SYNCHRONIZATION RULES
HARD SYNCHRONIZATION and RESYNCHRONIZATION are the two forms of
SYNCHRONIZATION. They obey the following rules:
2. An edge will be used for SYNCHRONIZATION only if the value detected at the
previous SAMPLE POINT (previous read bus value) differs from the bus value
immediately after the edge.
In order to increase the maximum oscillator tolerance from the 0.5% currently possible
to 1.5%, the following modifications, which are upwards compatible to the existing CAN
specification, are necessary:
[1] If a CAN node samples a dominant bit at the third bit of INTERMISSION, then it will
interpret this bit as a START OF FRAME bit.
[2] If a CAN node has a message waiting for transmission and it samples a dominant
bit at the third bit of INTERMISSION, it will interpret this as a START OF FRAME
bit, and, with the next bit, start transmitting its message with the first bit of the
IDENTIFIER without first transmitting a START OF FRAME bit and without
becoming a receiver.
[3] If a CAN node samples a dominant bit at the eighth bit (the last bit) of an ERROR
DELIMITER or OVERLOAD DELIMITER, it will, at the next bit, start transmitting an
OVERLOAD FRAME (not an ERROR FRAME). The Error Counters will not be
incremented.
In agreement with the existing specification, the following rules are still valid.
[5] All CAN controllers synchronize on the START OF FRAME bit with a hard
synchronization.
[6] No CAN controller will send a START OF FRAME bit until it has counted three
recessive bits of INTERMISSION.
This modifications allow a maximum oscillator tolerance of 1.58% and the use of a
ceramic resonator at a bus speed of up to 125 Kbits/second. For the full bus speed
range of the CAN protocol, still a quartz oscillator is required. The compatibility of the
enhanced and the existing protocol is maintained, as long as:
[7] CAN controllers with the enhanced and existing protocols, used in one and the
same network, have all to be provided with a quartz oscillator.
The chip with the highest requirement for its oscillator accuracy determines the
oscillator accuracy which is required from all the other nodes. Ceramic resonators can
only be used when all the nodes in the network use the enhanced protocol.
Ralf Schwering,
Schwering, Software Development Engineer
Vector Informatik GmbH www.lin-subbus.org
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
-1-
Slide 2
Agenda
Communication Principle
Message Format
Scheduling
Message Types
Data Assurance
Miscellaneous
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
-2-
Slide 3
LIN nodes do not have equal access to the bus due to Master-Slave
architecture
LIN Master delegates communication (Delegated Token Principle)
Message distribution based on message addressing
64 message addresses (Identifiers)
Producer Consumer
LIN Master
Daten
Data3 Slave-
Slave LIN- LIN- Daten
Data5 Slave-
Slave
Task
Task2 Task
Task3
Daten
Data1 Slave-
Slave Daten
Data4 Slave Slave Daten
Data6
Task
Task1
Daten
Data2
Master-
Master
Daten
Data Token
Task
LIN-Bus
LIN Bus
LIN Message
Daten
Data7 Slave-
Slave LIN-
Schedule Task
Task4
Schedule Slave
Schedule Daten
Data8
Consumer
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
-3-
The LIN network is based on a Master-Slave architecture. One network node is chosen to control all
communication. This is the LIN Master. The LIN Master performs the role of a bus arbiter with the
help of the so-called “Master Task” and “LIN Schedule”.
The LIN Schedule sets the send time point of the LIN message to be transmitted. According to the
LIN Schedule, the LIN Master places special messages referred to as Tokens on the bus at specified
time points. A Token can be understood as a Request, and it contains a message address. This is
evaluated by the LIN Slaves. A LIN Slave has three alternatives for reacting to the Token: Send
data, receive data, ignore data.
Token and data together are referred to as the LIN message. Up to 64 LIN messages may be
defined. Because of its message addressing method, each LIN message is available to be received by
any LIN node even by the LIN Master if it has a Slave Task. The LIN network is therefore a centrally-
controlled message distribution system.
Slide 4
Agenda
Communication Principle
Message Format
Scheduling
Message Types
Data Assurance
Miscellaneous
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
-4-
Slide 5
Message Header
Message Header
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
-5-
The Token is referred to as the Message Header in a LIN network. The entire Message Header is
transmitted by the LIN Master. It is made up of the Sync Break, Sync Field and PID (Protected
Identifier). Both the Sync Field and Sync Byte are used for initial synchronization. The PID is
comprised of the message address (Identifier) and two parity bits. According to the message
address the LIN nodes decide what they do immediately after the Message Header (send, receive or
ignore the message response).
Slide 6
Message Response
Message Response
...
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
-6-
The message response is sent by a Slave-Task delegated for this purpose based on the message
address. A maximum of eight data bytes may be transmitted with a message response. It should be
noted that byte transmission begins with the LSB. Transmitting a word the transmission begins with
the low byte (Little Endian transmission, Intel mode). In principle a message response may be
received and accepted by all Slaves-Tasks.
The data bytes are protected with the help of a checksum. Checksum formation is based on Modulo-
2 arithmetic and Carry Bit over all data bytes. The individual data bytes are added by Modulo-2
arithmetic. Overflow bits are carried. Finally the result is inverted.
Two different checksums exist: Classic and Enhanced checksums. With the Classic checksum only
the data bytes are protected. With the Enhanced checksum the data bytes and the identifier are
protected. For LIN 1.3 conformant LIN nodes the message responses to be transmitted are always
equipped with the Classic checksum, since the Enhanced checksum is unknown in LIN 1.3. It should
be noted that LIN messages with identifiers 60 and 61 (Diagnostics) are always protected with the
Classic checksum.
Slide 7
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
-7-
Slide 8
LIN Message
tHeader_Nom tResponse_Nom
tFrame_Nom
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
-8-
The LIN message is made up of the Message Header and Message Response. The Message Header is
always sent by the LIN Master. It contains synchronization information (Sync Field and Sync Byte),
the message address and two parity bits (Protected Identifier - PID). The Message Response
contains a maximum of eight data bytes and a checksum.
LIN message transmission is based on the SCI interface. A SCI character is made up of eight data
bits framed by a start bit and a stop bit. If the Sync Break must be 13 dominant bits and be
terminated by a recessive bit, then the LIN Message Header has a nominal length of 34 bits. The
length of the Message Response includes the number of data bytes and the checksum: Min. 20 bits
(one data byte), max. 90 bits (eight data bytes).
In the case of transmission of eight data bytes the LIN message has a nominal length of 124 bits
(Message Header: 34 bits, Message Response: 90 bits). The shortest LIN message contains 54 bits
(Message Header: 34 bits, Message Response: 20 bits).
Slide 9
LIN Message
Message Header Message Response
tHeader_Max tResponse_Max
tFrame_Max
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
-9-
A time reserve of up to 40 % is given for transmission of a LIN message. This is a very important
piece of information, above all for the dimensioning of a LIN network. This reserve compensates for
the fact that very low-performance controller chips might be used or the LIN Task might not be
executed immediately.
In other words, the LIN node is allowed to delay the start of the next UART character. However, the
sum of all delay times may not exceed the time reserve of 40 %. Differentiation is made between
two types of delay times: Interbyte Space and Response Space. The Response Space is located
between the Message Header and Message Response, and the Interbyte Space between any two
UART characters.
Slide 10
Agenda
Communication Principle
Message Format
Scheduling
Message Types
Data Assurance
Miscellaneous
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 10 -
Slide 11
Principle of Scheduling
Send times and identifiers are defined by the LIN Schedule; the
send times must be selected so that the transmission of the LIN
messages is guaranteed
tSende_n tSende_n+1
LIN Schedule
Message Message
Message
tSende_n Message Header (ID a) Header
Response
Header
(ID a) (ID b)
tSende_n+1 Message Header (ID b)
tFrame_Nom
tSende_n+2 Message Header (ID c)
tFrame_Max = 1.4 • tFrame_Nom
...
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 11 -
In a LIN network the LIN Master controls communications. This involves the LIN Master transmitting
very specific Message Headers at defined time points. The LIN Master takes both the send time and
identifier from the so-called LIN Schedule. The send times in the LIN Schedule must be selected
such that sufficient time is available for transmission of the LIN messages. 40 % additional time
according to the nominal time must always be permitted for transmission of a LIN message.
Slide 12
...
Frame Slot n Frame Slot n+1 Frame Slot n+2
tFrame Slot tFrame Slot tFrame Slot
Mini Mini Mini Mini Mini Mini Mini
Slot Slot Slot Slot Slot Slot Slot t
tn tn+1 tn+2 tn+3 tn+4 tn+5 tn+6 tn+7
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 12 -
The LIN Schedule is organized in Mini Slots. The length of these Mini Slots correspond to the
underlying time base of the LIN Schedule (e.g. 5 msec), and it represents the smallest time
resolution for processing the LIN Schedule. While sending a LIN message enough Mini Slots must be
provided to guarantee transmission of the specific LIN message. The sum of the necessary Mini Slots
is referred to as the Frame Slot.
Slide 13
Agenda
Communication Principle
Message Format
Scheduling
Message Types
Data Assurance
Miscellaneous
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 13 -
Slide 14
Message Types
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 14 -
Various frame types are available for data transmission in a LIN network: Unconditional Frame,
Event Triggered Frame, Sporadic Frame and Diagnostic Frame.
The Unconditional Frame is characterized in that there is exactly one sender of the Message
Response.
The Event Triggered Frame is characterized in that there are multiple senders of the Message
Response. Several unconditional frames from different LIN Slaves can be assigned to one event
triggered frame. The first data byte of such an unconditional frame must contain the PID.
The Message Response is only sent by the LIN Slave if a signal it contains has actually changed. Due
to its event-orientation collisions are not excluded and must be resolved by the LIN master.
In a Sporadic Frame Slot different Unconditional Frames from different LIN Slaves can be
transmitted. The Message Header in the Sporadic Frame Slot of an Unconditional Frame is sent by
the LIN Master if it knows that a signal it contains may have changed.
Two special LIN messages are used for diagnostics in a LIN network. The Master Request Frame with
identifier ID=0x3C and the Slave Response Frame with identifier ID=0x3D.
The identifiers 0x3D and 0x3F are reserved and not used in the actual specification.
Slide 15
Unconditional Frames
Header ID=0x12
Unconditional Frame 2 Frame
ID = 0x12 Slot 2 Response
Header ID=0x14
Unconditional Frame 4 Frame
ID = 0x14 Slot 4 Response
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 15 -
A sufficiently large frame slot is provided for transmission of an Unconditional Frame. The
Unconditional Frame belonging to a frame slot may be transmitted once or multiple times per
communication cycle depending on the application. The frame slot must be large enough to be able
to send the Message Header and the Message Response. There is exactly one sender for the
Message Response. Due to message addressing the Message Response is available for every LIN
Slave to receive.
In the example four different Unconditional Frames are sent sequentially according to the entries in
the Schedule. One frame slot is available for transmission of each Unconditional Frame. At the
beginning of the frame slot the LIN Master sends the Message Header. The relevant LIN Slave sends
the Message Response. Once all four frame slots have been processed, or all four Unconditional
Frames have been transmitted, execution of the Schedule is repeated.
Slide 16
Diagnostic Frames
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 16 -
Diagnostic handling in a LIN network is performed with the help of two special LIN messages: Master
Request Frame and Slave Response Frame. The Master Request Frame is characterized in that the
LIN Master sends both the Message Header and the Message Response. The Message Header of the
Master Request Frame is always sent with the identifier ID=0x3C. The Master Request Frame is used
for the so-called Diagnostic Request. This may consist of several Master Request Frames. This is
called a segmented Diagnostic Request.
The Slave Response Frame is characterized in that the LIN Master sends the Message Header, and a
LIN Slave sends the Message Response. The Message Header of the Slave Response Frame is
always sent with the identifier ID=0x3D. The Slave Response Frame is used for the so-called
Diagnostic Response. The Diagnostic Response may consist of several Slave Response Frames. In
that case one speaks of a segmented Diagnostic Response.
The Diagnostic Schedule is used for diagnostics. It must contain two frame slots: One for the Master
Request Frame, and one for the Slave Response Frame. The number of repeats depends on the
diagnostic implementation itself. For a segmented Diagnostic Request the Slave Response Frame is
suppressed, and for a segmented Diagnostic Response the Master Request Frame is suppressed.
Slide 17
Agenda
Communication Principle
Message Format
Scheduling
Message Types
Data Assurance
Miscellaneous
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 17 -
Slide 18
Data Assurance
Each LIN Slave monitors its operating state and creates a status
report
The status report is sent periodically to the LIN Master (LIN 2.0)
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 18 -
In a LIN network a LIN Slave has the task of monitoring its own operating state (since LIN 2.0). This
involves the LIN Slave checking, with the help of parity and checksum checks, to determine whether
the send and receive messages were transmitted correctly. The user is free to implement additional
error detection mechanisms. It is conceivable that the user might want to implement a check to
determine whether there is any bus activity at all, and if yes whether the expected Message
Response is transmitted and whether it satisfies the defined time requirements.
The results of monitoring are recorded in a status report. This is provided to the LIN Master. The LIN
Master evaluates the status report. This entire process is also referred to as Status Management.
LIN messages detected as incorrect are rejected by the LIN Slave.
Important: Error handling is not part of the LIN specification and must be defined by the user. This
generally takes into account the special constraints of the application area.
Slide 19
Agenda
Communication Principle
Message Format
Scheduling
Message Types
Data Assurance
Miscellaneous
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 19 -
Slide 20
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 20 -
Slide 21
Internet
http://www.vector-informatik.com/
http://www.lin-subbus.org
© 2004. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector.
V1.0 2004-12-03
02_Fundamentals of the LIN Protocol.ppt
- 21 -
Flexray Communication protocol
Flexray Communication protocol features
2 wire
Fault-tolerance
What is Flexray Node?
The FlexRay interface is made up of a communication controller and one or two bus
drivers, depending on the number of channels.
The primary tasks of the FlexRay controller include framing, bus access, error
detection and handling, synchronization, putting the FlexRay bus to sleep and waking
it up, as well as coding TX messages and decoding RX messages
.
Flexray transceiver ?
The FlexRay transceiver couples the FlexRay controller to the physical transmission
medium.
The primary task of the FlexRay transceiver is signal transformation. On the one hand, it
transforms the logical signal stream received by the FlexRay controller into a physical
signal stream. In the other direction, it transforms the received physical signal stream
into a logical signal stream.
FlexRay states
A FlexRay controller may enter eight different states depending on the progress of
communication. Each controller state is characterized by certain communication-
specific activities, in which very specific communication components are active. The
communication component protocol operation control (POC) is responsible for
controller state transitions.
FlexRay technology is designed for data rates up to 10 Mbit/s.
FlexRay physical layer defines certain mechanisms for increasing immunity against
high-frequency interference fields and electrostatic discharge (ESD) and for reducing
noise emissions.
Emissions are limited by the relatively low differential voltages (2 Volt for the bus
level ―Data_1‖, -2 Volt for the bus level ―Data_0‖).
Because of its differential signal transmission, the FlexRay bus consists of two
lines:Bus Plus (BP) and Bus Minus (BM).
Twisting of the two lines reduces the magnetic field considerably, so twisted line pairs
are typically used in practice — for cost reasons usually without shielding.
.
Because of finite signal propagation speed, the effects of transient responses
(reflections) increase with higher data rates and growing bus length.
Because the FlexRay specification specifies a load between 40 and 55 Ω, values of the
bus termination resistors must lie between 80 and 110 Ω. Therefore, a cable whose
impedance lies between 80 and 110 Ω should be used for transmission.
Physical signal transmission in a FlexRay cluster is based on transmission of voltage
differences (differential signal transmission). Therefore, the transmission medium
(FlexRay bus) consists of the two lines Bus Plus (BP) and Bus Minus (BM).
The Electrical Physical Layer Specification defines four bus levels, which are assigned
either to the recessive or the dominant bus state. The recessive bus state is
characterized by a differential voltage of 0 Volt. The dominant bus state, on the other
hand, has a differential voltage not equal to zero Volt.
Both, the idle bus level and the idle low power bus level, are recessive. The idle bus
level is characterized by the two lines exhibiting a 2.5 Volt potential, resulting in a
differential voltage of 0 Volt. The valid range for the idle bus level lies between 1.8 Volt
and 3.2 Volt.
The idle low power bus level appears on the FlexRay bus when all FlexRay
transceivers are in their low-power mode. This bus level is also characterized by a
differential voltage of 0 Volt, but in this case the lines exhibit a potential of 0 Volt. The
valid range here is between -0.2 Volt and 0.2 Volt
The two bus levels Data_1 and Data_0 are dominant bus levels. With the Data_1 bus
level the BP bus line exhibits a potential of 3.5 Volt, and the BM bus line a potential of
1.5 Volt. The resulting differential voltage is 2 Volt. The Data_1 bus level represents
logical one.
With the Data_0 bus level the BP bus line has a potential of 1.5 Volt, and the BM bus
line a potential of 3.5 Volt. The resulting differential voltage is -2 Volt. The Data_0 bus
level represents logical zero.
Bus states and bus levels can be seen in the figure ―FlexRay Bus Level‖. Also shown
are the relevant voltage thresholds for sender and receiver.
FlexRay is primarily used in extremely safety and time-critical automotive applications.
Organizing communication in the FlexRay cluster into static communication cycles and
linking time slots to the FlexRay nodes provide for a smooth deterministic
communication flow. FlexRay nodes that have gotten out of step with the pace may
disturb this harmony by unauthorized transmissions within time slots not assigned to
them. Preventing this is the task of the so-called bus guardians.
In the local bus guardian concept, a bus guardian (BG) is assigned to each FlexRay
transceiver. It only allows the FlexRay transceiver to place data received from the
FlexRay controller on the bus, if it conforms to the communication schedule.
The data is located in reserved slots in the static communication segment. Within the
dynamic communication segment, there cannot be such protection, since the messages
are only sent by the FlexRay nodes if an event occured. It is only possible to either
completely allow a FlexRay node to send in the dynamic communication segment or
completely prohibit it from sending.
To implement its functionality, the bus guardian must know the communication schedule
and the time in the FlexRay cluster. Ideally, the bus guardian does not rely on the local
time base generated by the FlexRay controller, but instead generates its time base
independent of the FlexRay controller. This is the only way a bus guardian can assure
that a FlexRay node can only send in its time slots, because in addition to checking the
time slots themselves, all errors of the FlexRay controller‘s clock are detected as well.
However, this means that the bus guardian must be equipped with nearly the same
functions as the FlexRay controller, giving the bus guardian a similar level of complexity,
which would result in increasing costs for FlexRay communication. Regardless of how a
bus guardian determines the time, there have not been any implementations of a local
bus guardian to date. The related specification node local bus guardian
specification is in Version 2.0.9 and its status is preliminary.
The same applies to Version 2.0.9 of the central bus guardian specification. The state
is preliminary and no implementations of a central bus guardian exist yet. The concept
here involves the bus guardian being located on an active star coupler. Within the
communication cycle, the central bus guardian always activates the communication
branch whose end is connected to the FlexRay node with authorization to send as
specified in the communication schedule. This provides a way to prevent signal
collisions.
Flexray Bus Access
In a FlexRay cluster, the FlexRay nodes are granted access to the communication
medium in two different ways: first by the TDMA method (Time Division Multiple
Access), and second by the FTDMA method (Flexible Time Division Multiple Access),
whose core consists of the TDMA method.
The communication cycle is then composed of the combination of a static segment and
a dynamic segment. The dynamic segment exhibits a fixed time length to assure
deterministic data communication in the static segment despite the addition of
dynamic message transmission.
The dynamic segment is based on the FTDMA method. The difference between the
FTDMA and the TDMA method is that the dynamic messages defined in the
communication schedule can be transmitted by the relevant FlexRay nodes as needed.
This means that the time point of message transmission is not predictable. Because the
dynamic segment has a finite length, there may be FlexRay nodes wishing to send that
will not be able to transmit their dynamic messages in the current cycle
Communication Cycle
Optionally, the communication cycle may be extended by adding the dynamic time
segment and a symbol window. The dynamic time segment is used for event-driven
message transmission; if it is included it follows the static segment.
The symbol window serves to transmit symbols. The collision avoidance symbol is used
to indicate the start of the first communication cycle to a FlexRay node. The media test
symbol is used for testing of a bus guardian, and the wake-up symbol for waking up the
FlexRay cluster.
Because only the static segment and the NIT segment are mandatory for a cycle,
four cycle variants can be distinguished. The figure ―Communication Cycle‖ shows a
cycle exhibiting all possible time segments: static segment, dynamic segment, symbol
window and NIT.
A communication cycle is made up of a defined number of macroticks, which are
assigned to the individual segments. The macroticks are composed of a number of
microticks, the smallest time unit of the local clocks. Due to differences in crystal
oscillator frequencies, which results in microticks of different lengths, the macroticks of
different FlexRay nodes may be composed of different numbers of microticks in order
to get a synchronized macrotick.
Data transmission in a FlexRay cluster is executed using a uniform message frame
(FlexRay message). Each FlexRay message is composed of three
parts: header,payload and trailer. The header consists of 40 bits. Of these, eleven bits
belong to the identifier (ID). This identifies a message and corresponds to a slot. All IDs
may be used freely. One exception is ID=0x00: this is used to identify invalid messages.
The ID is preceded by four indicator bits, which in turn are preceded by a reserved bit.
The indicator bits serve to specify a message more precisely. The payload preamble
indicator indicates whether a network management vector is being transmitted in the
payload of a static message or whether a message identifier is being transmitted in the
payload of a dynamic message.
In special cases the sender may transmit the payload of a message exclusively with
zeros. This is not a regular payload. To indicate whether the payload is regular or invalid,
there is the null frame indicator.
The sync frame indicator indicates whether messages transmitted in the static
segment are being used as sync frames in the context of synchronization.
The startup frame indicator indicates whether the message transmitted in the static
segment is being used as a startup frame in the context of startup.
The identifier is followed by the payload length. It shows the size of the payload in
words and consists of 7 bits. A total of 254 bytes may be transported with one message.
The header is completed by the cycle counter. This comprises six bits and represents
the number of the cycle in which the message is sent. The cycle counter always counts
up to 63.
A maximum of 254 user bytes (payload) can be transported by one message.
Thepayload length parameter shows the size of the payload in words. The payload
length exhibits the same value for all messages transmitted in the static segment. The
system designer must define this value during the configuration phase. Since dynamic
messages are not restricted to a fixed payload size, the payload length may assume
different values for such messages.
In a message transmitted in the static segment, it is possible to use the first twelve
bytes to transmit the network management vector. This requires setting thepayload
preamble indicator in the header. The network management vector is available for
implementing network management in a FlexRay cluster.
The message identifier gives the system designer a way to specify the payload more
precisely; it may be used as a basis for making finer distinctions in acceptance filtering.
In special cases, the sender may send the payload of a message exclusively with zeros.
Such a case exists if a FlexRay controller needs to send a static message according to
the communication schedule, but the buffer corresponding to the message is blocked by
the host. This might occur, for example, if the host is accessing this buffer itself at the
given moment. Because the FlexRay controller cannot access the data in the buffer, it
automatically transmits the static message as a null frame. In this case, the null frame
indicator assumes the value zero in the message header.
To protect the payload, the CRC method (CRC: Cyclic Redundancy Check) is used.
This is a very powerful error detection method. In the framework of the CRC method,
a CRC sequence is computed based on the header and payload and a generator
polynomial defined by the FlexRay specification. This CRC sequence is appended to
the header and payload as the trailer.
The CRC sequence for a message corresponds to a multiple of the header and the
payload. The receiver of the message can detect any transmission error with very high
reliability. An error is detected when division by the generator polynomial yields a
remainder. With a payload of up to 248 bytes, the CRC method guarantees a hamming
distance of six. For a larger payload the hamming distance is four, resulting in a lower
error detection capability.
Keyword Protocol 2000
Keyword Protocol 2000, abbreviated KWP2000, is a communications protocol used
for on-board vehicle diagnostics systems (OBD).
This protocol covers the application layer in the OSI model of computer networking.
KWP2000 also covers the session layer in the OSI model, in terms of starting,
maintaining and terminating a communications session.
The data rate is between 1.2 and 10.4 kbps, and a message may contain up to 255
bytes in the data field