CAN COMMUNICATION

 What is communication ?
 Why there is need for communication in vehicle?
 What are different types of communications?
 What is CAN ?
 Why CAN ?
 CAN Protocol
 CAN Layers
 CAN Applications
 CAN programming
What is communication ?

Communication is nothing but exchange of information

or data.

Why there is need for communication in a vehicle?

To reduce the cost.

To reduce size.
To reduce the complexity.
To improve the performance.
What are the different types of communications?

 Serial Communication

 Parallel Communication

 Advantages and Disadvantages of Both

Comparison of different protocols
Comparison of different protocols
What is CAN ?
Controller Area Network

Is a serial bus system used to communicate between several embedded 8-

bit and 16-bit

It was originally designed for use in the automotive industry but is used today
in many other systems (e.g. home appliances and industrial machines).

It is asynchronous serial transmission protocol.

 Highest Baud Rate is 1Mbit.

 CAN uses a message oriented transmission protocol.

 There are no defined addresses, just defined messages.

 Non-destructive arbitration system by CSMA with collision detection.

 Multi-master / Broadcasting concept

 Sophisticated error detection & handling system

 Why CAN ?

 Mature Standard
 CAN protocol more than 16 years
 Numerous CAN products and tools on the market
 Hardware implementation of the protocol
 Combination of error handling and fault confinement with high
transmission speed (up to 1Mb/s)
 Simple Transmission Medium
 Twisted pair of wires is the standard, but also just one wire will
work
 Other links works, too: Opto - or radio links
 Excellent Error Handling
 CRC error detection mechanism
 Fault Confinement
 Built-in feature to prevent faulty node to block system
 Most used protocol in industrial and automotive world
CAN Controller

CAN Transceiver
 CAN Protocol
There 4 types of frames

Data Frame

Remote frame

Overload frame

Error Frame
 CAN Protocol
DATA Frame

• SOF – Start of Frame

• Identifier – Tells the content of message and priority
• RTR – Remote Transmission Request
• IDE – Identifier extension (distinguishes between CAN
standard,11 bit identifier, and CAN extended, 29 bit identifier.)
• DLC – Data Length Code
• Data – holds up to 8 bytes of data
• CRC – “Cyclic Redundant Check” sum
• ACK – Acknowledge
• EOF – End of Frame
• IFS – Intermission Frame Space. Minimum number of bits
separating consecutive messages.
CAN Protocol

• Messages are
distinguished by
message identifiers.
• The identifier is unique
to the network and
defines the content &
priority of the message.
CAN Protocol

• When several messages

access the bus at the same
time, the one with the higher
priority “wins”.
• The identifier with the lowest
binary number has the
highest priority.
• The priority are specified
during system design and
cannot be changed
dynamically.
CAN Protocol

• Access conflicts on the

bus are resolved by a
“wired and” mechanism,
where the dominate state
overwrites the recessive
state.
• All “losers” automatically
become receivers and
they won’t try to send
another message until the
bus becomes available
again.
 CAN Protocol

• If one or more errors are detected, the transmission

is aborted. This prevents all other stations or nodes
from accepting the message.
• Re-transmission is automatic. If errors continue, then
the station or node may switch itself off to prevent the
bus from being tied up.
• Error detection is done on two levels:
– Message level
– Bit level
 CAN Protocol

• Message Level
– CRC = Cyclic Redundant Check sum
– Frame Check = compares message to fixed format and
frame size
– ACK errors = if transmitter does not receive an ACK
signal from the receivers
• Bit level
– Monitoring = The transmitter monitors the bus signal as
it sends the message and compares the bit sent to the
bit received.
– Bit Stuffing = After five consecutive equal bits, the
transmitter inserts a stuff bit with a compliment value
into the bit stream. The receivers remove this stuff bit.
 CAN Protocol

 Error Frame: sent after a violation frame format

 Overload Frame: prevents data overflow from a slower CAN

Overload Frames are not really used

  CAN Node Error States:
 Error Active: Normal state, node can send all frames (error frames
included)
 Error passive: Node can send all frames excluding error frames
 Bus off: Node is isolated from bus

 Internal Counters: TEC & REC

 TEC: Transmit Error Counter
 REC: Receive Error Counter

TEC and REC counters allows to prevent from faulty nodes

 CAN Protocol

‘1’ Recessive (r)

‘0’ Dominant (D)

Two logic states on the CAN bus

Node 1 Node 2 Node 3 Bus

D D D D Wired-AND Function
D D r D
D r D D
D r r D Bus in dominant state
r D D D
r D r D
r r D D
Bus in recessive state
r r r r
or idle
 TXD CAN_H
CAN_H

CAN Bus
µController CAN CAN
Controller Transceiver

RXD CAN_L
CAN_L
 CAN - High - Speed ( ISO 11898 ) :

node 1 node 30

CAN_H

120 120
Ohm
Ohm
CAN_L

V o lta g e

CAN_H
3 ,5 V

2 ,5 V

1 ,5 V
CAN_L

r e c e s s iv e d o m in a n t r e c e s s ic v e
tim e
C A N h ig h - s p e e d , n o m in a l b u s le v e ls
 LIN Consortium

Consortium formed in 1998.

Five Car manufacturers
ONE Semiconductor Supplier (Motorola)
BMW
One tool Supplier (VCT)

Specification finalised on 02/02/00

Official Launch at SAE March ‘00 Daimler- LIN Volvo
Open Specification. Chrysler Spec

Motorola Ready to support LIN with extensive

device families and new parts already in the VW
AUDI
discussion/ spec finalization loop.
VCT
First dedicated LIN part available Q3 ‘00
 Automotive Body Network Mirror

Lock Lock
Window Lift
Universal Light
CAN Light

Seat
Htng
Instruments
Htng Wiper
Power Train Central WHtg
ITS Body Ctrl Roof Interior
Light
Htng Trunk
Climate
x6
Seat
Light Seat
Htng
St-Wheel Panel CAN

Universal Motor
Lock Lock
1 backbone, 13 nodes
8 subnets, 1-8 local nodes Sub-Bus Universal Panel
52 nodes total
Mirror

LIN Sub Bus

W. Specks, H.-C. Wense
 Typical LIN Applications

Roof: Steering Wheel:

(very many controls are going to be
(high amount of wiring)
positioned on the steering wheel)
Rain Sensor, Light Sensor, Cruise Control, Wiper,
Light Control, Sun Roof Turning Light, …
… Optional: Climate Control,
(Rain Sensor needs to be
Radio, Telephone, etc.
interrogated every 10-20ms)

Seat:
many Seat Position Motors,
Occupancy Sensor,
Control Panel
•Door/window/seat:
Mirror,Central ECU,
Mirror, Switch, Window Climate:
Lift, many Small Motors
Seat Control Switch, Control Panel
Door Lock, etc.
 LIN Concept
• Technical Solution
– Low cost single-wire implementation (enhanced ISO 9141)
– Speed up to 20Kbit/s (limited for EMI-reasons)
– Single Master / Multiple Slave Concept
 No arbitration necessary
– Low cost silicon implementation based on common UART/SCI
interface hardware
 Almost any Microcontroller has necessary hardware on chip
– Self synchronization without crystal or ceramics resonator in the
slave nodes
 Significant cost reduction of hardware platform
– Guaranteed latency times for signal transmission
(Predictability)
 Master / Slave Protocol

• Master Task
– Determines order and priority of messages.
– Monitors Data and check byte and controls the error handler.
– Serves as a reference with its clock base (stable clock necessary)
– Receives Wake- Up Break from slave nodes

• Slave Task
– Is one of 2-16 members on the bus
– Receives or transmits data when an appropriate ID is sent by the master.
– The node serving as a master can be slave, too!
 Master / Slave Protocol
• Master
– has control over the whole Bus and Protocol
The master controls which message at what time is to be transferred over the
bus.
To accomplish this the master
• sends Sync Break
• sends Sync Byte
• sends ID-Field
• monitors Data Bytes and Check Byte, and evaluates them on consistance
• receives WakeUp Break from slave nodes when the bus is inactive and
they request some action.
• serves as a reference with it’s clock base (stable clock necessary)
 Master/Slave Protocol
• Slave
– Is one of 2-16 Members on the Bus and receives or transmits Data when an
appropriate ID is sent by the master.
• Slave snoops for ID.
• According to ID, slave determines what to do.
– either receive data
– or transmit data
– or do nothing.
• When transmitting the slave
– sends 1, 2, 4, or 8 Data Bytes
– sends Check-Byte
• The node serving as a master can be slave, too!
 LIN protocol offers message timing predictability

Time Triggered Approach

• Message Length is known
– Number of transmitted data bytes is known
minimum length can be calculated
– Each Message has length budget of 140% of it’s minimum length
maximum allowed length is known
distance between beginning of two messages
 Data Transmission
master control unit
polling slave control unit slave control unit

master task
slave task slave task slave task

inter-frame
13 bit synch identifier
spacing field field next synch
Next 13 field
bit break
Break
$55
Master Task
time
2 byte 1 byte
response
spacing data block parity

Slave Task
time
 Message Frame
• Synch Byte:
– Specific Pattern for Determination of Time Base
(Determination of the time between two rising edges)
– A Synch Byte precedes any Message Frame
• ID-Field:
– Message Identifier: Incorporates Information about the sender, the
receiver(s), the purpose, and the Data field length.
Length 6 Bit.
4 classes of 1/2/4/8 Data Bytes. The length coding is in the
2 LSB of the ID-Field. Each class has 16 Identifiers. A total of 64 Message
Identifiers are possible.
– 2 Parity Bits protect this highly sensitive ID-Field.
 Identifier
• The identifier field is sent by the master node to all LIN nodes
• This identifier normally contains one of 64 different values and
includes 2 parity bits in the 8 bit data
• The identifier is normally associated with a collection of signals that
are subsequently transmitted on the LIN bus
• In a specific case this can initiate SLEEP mode in the LIN slave nodes –
in this case no further data is transmitted on the LIN bus

message header

synch break synch field identifier

 13 bit
 LIN Communication - Data from Slave
to Master
Master Node Slave Node
identifier synch field synch break
LIN Master Task Slave Task Rec
quartz

Slave Task Rec Slave Task Trans

data byte data byte checksum
Slave Task Trans • Single-master / multi-slave protocol
• Time triggered, no arbitration
• Identifier denotes message content, not physical address
• Multicast messages
• Baud rate synchronization through protocol
• Power saving sleep mode
 LIN Communication - Data from
Master to Slave(s)
Master Node Slave Node A

LIN Master Task Slave Task Rec

quartz

Slave Task Rec Slave Task Trans

Slave Task Trans

Slave Node B

Slave Task Rec

Slave Task Trans

 LIN Communication - Data from Slave
to Slave
Master Node Slave Node A

LIN Master Task Slave Task Rec

quartz

Slave Task Rec Slave Task Trans

Slave Task Trans

Slave Node B

Slave Task Rec

Slave Task Trans

 LIN Message Frame
message header message response

synch break synch field identifier 0 to 8 data fields checksum

 13 bit

Synchronisation Identifier byte

frame

Synchronisation field Message

 LIN Physical Interface
Electronic Control Unit Bus Voltage

VBAT
8...18V
recessive
master: 1k logic ‘1’
slave: 30k 60%
controlled slope
Rx Bus ~2V/µs
UART 40%
Tx dominant
logic ‘0’

GND
Time
Example capacitances
master: 2.2nF
Note:
slave: 220pF
The LIN specification refers to the ECU connector voltages !
LIN FEATURES

The LIN is a serial communications protocol which efficiently supports the control of
mechatronics nodes in distributed automotive applications.

The main properties of the LIN bus are:

• single master with multiple slaves concept

• low cost silicon implementation based on common UART/SCI interface

hardware, an equivalent in software, or as pure state machine.

• self synchronization without a quartz or ceramics resonator in the slave nodes

• deterministic signal transmission with signal propagation time computable in

Advance

• low cost single-wire implementation

• speed up to 20 kbit/s.

• signal based application interaction

FRAME STRUCTURE
Each byte field is transmitted as a serial byte, as shown in Figure 2.2. The LSB
of the data is sent first and the MSB last. The start bit is encoded as a bit with
value zero (dominant) and the stop bit is encoded as a bit with value one
(recessive).
Break

The break is used to signal the beginning of a new frame. It is the only field
that does not comply with Figure 2.2:

A break is always generated by the master task(in the master node) and it shall be at
least 13 bits of dominant value, including the start bit, followed by a break delimiter,

as shown in Figure 2.3. The break delimiter shall be at least one nominal bit time long.
 FRAME TYPES
Unconditional frame
Unconditional frames always carry signals and their identifiers are in the range 0 to 59
(0x3b).
Event triggered frame
The purpose of an event triggered frame is to increase the responsitivity of the LIN
cluster without assigning too much of the bus bandwidth to the polling of multiple slave
nodes with seldom occurring events
Sporadic frame
The purpose of sporadic frames is to blend some dynamic behavior into the
deterministic and real-time focused schedule table without loosing the determinism in
the rest of the schedule table.
Diagnostic frames
Diagnostic frames always carry diagnostic or configuration data and they always contain
eight data bytes. The identifier is either 60 (0x3c), called master request frame, or
61 (0x3d), called slave response frame
User-defined frames
User-defined frames carry any kind of information. Their identifier is 62 (0x3e). The
header of a user-defined frame is always transmitted when a frame slot allocated to
the frame is processed.
Reserved frames
Reserved frames shall not be used in a LIN 2.0 cluster. Their identifier is 63 (0x3f).
 Further information

- Consortium
http://www.lin-subbus.org
Flexray Communication protocol
Flexray Communication protocol features

High data rates (up to 10 Mbit/s)

Time- and event-triggered behavior

2 wire

Differential voltage bus concept

Fault-tolerance
 What is Flexray Node?

 A FlexRay node is an electronic control unit (ECU), which is connected to a FlexRay

bus via a FlexRay interface.

 What is flexray interaface?

 The FlexRay interface is made up of a communication controller and one or two bus
drivers, depending on the number of channels.

 The communication controller is referred to as a FlexRay controller.

 The FlexRay controller executes the communication protocol defined in the

FlexRay specification.

 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 bus driver is referred to as a 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.

Physical signal transmission in the FlexRay cluster is based on the transmission of

differential voltages. This approach renders interference voltages induced by
motors, ignition units and switch contacts harmless.

 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.

Termination of the ends of the communication channel by termination resistors

prevents reflections in a FlexRay cluster.

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 TDMA method is based on a communication schedule, which is organized into a

number of time slots (static slots) of equal length, each assigned to a FlexRay node.
During communicative operation a FlexRay node is granted access to the
communication medium (bus) according to this schedule. From the first to the last static
slot, the FlexRay nodes assigned to the static slots obtain exclusive access to the
bus to transmit the messages assigned to the static slots.

The communication schedule is executed periodically by all FlexRay nodes during

communicative operation; as a result, all static messages are transmitted with a
specified period, i.e. deterministically. The communication schedule defines nothing
other than a communication cycle, or stated more precisely, the FlexRay
communication cycle.
For asynchronous processes,or for sporadic transmission of messages the TDMA
method is not an ideal solution. Therefore, FlexRay technology offers the option of
extending the cycle by a dynamic segment for messages in a FlexRay cluster that
should not only be transmitted on a fixed time schedule, but also on an event driven
basis.

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

Data communication in a FlexRay cluster is periodical and is based on a schedule.

The communication cycle is composed of at least two time segments, the static
segment and the network idle time (NIT) segment. The static segment is used for
deterministic transmission of messages. The NIT segment is needed to synchronize the
local clocks. No data communication occurs during the NIT segment.

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 identifier is protected by a CRC method. The payload length is followed by an

eleven bit long header CRC sequence whose calculation is based on the identifier,
payload length, sync frame indicator and startup frame indicator and a generator
polynomial defined by the FlexRay specification.

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.

 The protocol is standardized by International Organization for Standardization as

ISO 14230.

 KWP2000 also covers the session layer in the OSI model, in terms of starting,
maintaining and terminating a communications session.

 bidirectional serial communication on a single line called the K-line.

In addition, there is an optional L-line for wakeup.

 The data rate is between 1.2 and 10.4 kbps, and a message may contain up to 255
bytes in the data field
Functional addressing is an addressing scheme that labels
California messagesBoard
Air Resources based(CARB)
upon
their operation code or content. Physical addressing is an addressing scheme that
labels messages based upon the physical address location of their source and/or
destination