`
`CAN Specification
`
`Version 2.0
`
`1991, Robert Bosch GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Liberty Mutual Exhibit 1030
`
`Liberty Mutual v. Progressive
`CBM2013-00009
`
`Page 00001
`
`Liberty Mutual Exhibit 1030
`Liberty Mutual v. Progressive
`CBM2013-00009
`Page 00001
`
`
`
`The document as a whole may be copied and distributed without
`restrictions. However, the usage of it
`in parts or as a whole in other
`documents needs the consent of Robert Bosch GmbH. Robert Bosch
`GmbH retains the right to make changes to this document without
`notice and does not accept any liability for errors.
`
`Imported into Framemaker 4 by:
`
`Chuck Powers, Motorola MCTG Multiplex Applications, April 5,1995.
`
`Page 00002
`
`Page 00002
`
`
`
`BOSCH
`
`N
`
`CAN Specification 2.0
`
`Sep. 1991
`
`page 1
`
`Recital
`
`communication to more and more
`serial
`The acceptance and introduction of
`applications has led to requirements that the assignment of message identifiers to
`communication functions be standardized for certain applications. These applications
`can be realized with CAN more comfortably,
`if the address range that originally has
`been defined by 11 identifier bits is enlarged
`Therefore a second message format ('extended format’) is introduced that provides a
`larger address range defined by 29 bits. This will relieve the system designer from
`compromises with respect to defining well-structured naming schemes. Users of CAN
`who do not need the identifier range offered by the extended format, can rely on the
`conventional 11 bit identifier range (‘standard format’) further on.
`In this case they can
`make use of the CAN implementations that are already available on the market, or of
`new controllers that implement both formats.
`In order to distinguish standard and extended format the first reserved bit of the CAN
`message format, as it is defined in CAN Specification 1.2, is used. This is done in such
`a way that the message format in CAN Specification 1.2 is equivalent to the standard
`format and therefore is still valid. Furthermore, the extended format has been defined
`so that messages in standard format and extended format can coexist within the same
`network.
`
`This CAN Specification consists of two parts, with
`
`-
`
`-
`
`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
`implementation be compatible with either Part A or Part B.
`
`is required that a CAN
`
`Note
`
`CAN implementations that are designed according to part A of this or according to
`previous CAN Specifications, and CAN implementations that are designed according to
`part B of this specification can communicate with each other as long as it is not made
`use of the extended format.
`
`ROBERT BOSCH GmbH, Postfach 300240, D-7000 Stuttgart 30
`
`Page 00003
`
`Page 00003
`
`
`
`
`
`PART APART A
`
`
`
`ooooooo 04ooooooo 04
`
`Page 00004
`
`
`
`BOSCH
`
`‘
`
`Contents
`
`Sep. 1991
`
`PartA_page3
`
`1
`
`2
`
`3
`
`3.1
`
`3.1.1
`
`3.1.2
`
`3.1.3
`
`3.1.4
`
`3.1.5
`
`3.2
`
`4
`
`5
`
`6
`
`6.1
`
`6.2
`
`7
`
`8
`
`9
`
`INTRODUCTION .............................................................................. ..4
`
`BASIC CONCEPTS .......................................................................... ..5
`
`MESSAGE TRANSFER ................................................................... ..10
`
`Frame Types .................................................................................... ..10
`
`DATA FRAME .................................................................................. ..10
`
`REMOTE FRAME ............................................................................ ..15
`
`ERROR FRAME ............................................................................... ..16
`
`OVERLOAD FRAME ........................................................................ ..17
`
`INTERFRAME SPACING ................................................................. ..18
`
`Definition of TRANSMITTER/RECEIVER ........................................ ..20
`
`MESSAGE VALIDATION ................................................................. ..21
`
`CODING ........................................................................................... ..22
`
`ERROR HANDLING ......................................................................... ..23
`
`Error Detection ................................................................................. ..23
`
`Error Signalling ................................................................................. ..23
`
`FAULT CONFINEMENT ................................................................... ..24
`
`BIT TIMING REQUIREMENTS ........................................................ ..27
`
`INCREASING CAN OSCILLATOR TOLERANCE ............................ ..31
`
`9.1
`
`Protocol Modifications ...................................................................... ..31
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00005
`
`Page 00005
`
`
`
`BOSCH
`
`|
`
`1 INTRODUCTION
`
`Introduction
`
`Sep. 1991
`
`PartA_page4
`
`is a serial communications protocol which
`The Controller Area Network (CAN)
`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 (CAN-) object layer
`
`the (CAN-) transfer layer
`
`the physical layer
`
`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
`
`-
`
`-
`
`-
`
`finding which messages are to be transmitted
`
`deciding which messages received by the transfer layer are actually to be used,
`
`providing an interface to the application layer related hardware.
`
`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 specificatign is to define the transfer layer and the conseguences of
`the CAN protocol on the surrounding layers.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00006
`
`Page 00006
`
`
`
`BOSCH
`
`Basic Concepts
`
`Sep. 1991
`
`PartA_page 5
`
`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
`
`Layered Structure of a CAN Node
`
`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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00007
`
`Page 00007
`
`
`
`BOSCH
`
`Basic Concepts
`
`Sep. 1991
`
`Pa“ _ page 6
`
`- 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.
`
`Message Routing: The content of a message is named by an IDENTIFIER. The
`IDENTIFIER does not indicate the destination of the message, but describes the
`meaning of the data, so that all nodes in the network are able to decide by
`MESSAGE FILTERING whether the data is to be acted upon by them or not.
`
`Multicastz As a consequence of the concept of MESSAGE FILTERING any
`number of nodes can receive and simultaneously act upon the same message.
`
`is guaranteed that a message is
`Data Consistency: Within a CAN network it
`simultaneously accepted either by all nodes or by no node. Thus data
`consistency of a system is achieved by the concepts of multicast and by error
`handhng.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00003
`
`Page 00008
`
`
`
`BOSCH
`
`Basic Concepts
`
`Sep. 1991
`
`Farm _ page 7
`
`Bit rate
`The speed of CAN may be different in different systems. However,
`the bitrate is uniform and fixed.
`
`in a given system
`
`Priorities
`
`The IDENTIFIER defines a static message priority during bus access.
`
`Remote Data Reguest
`By sending a REMOTE FRAME a node requiring data may request another node to
`send the corresponding DATA FRAME. The DATA FRAME and the corresponding
`REMOTE FRAME are named by the same IDENTIFIER.
`
`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.
`
`_S_afety
`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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00009
`
`Page 00009
`
`
`
`BOSCH
`
`Basic Concepts
`
`Sep. 1991
`
`Pa“ _page 8
`
`Perf rmance of Err r Dete ti n
`
`The error detection mechanisms have the following properties:
`
`- all global errors are detected.
`- all local errors at transmitters are detected.
`
`- up to 5 randomly distributed errors in a message are detected.
`- burst errors of length less than 15 in a message are detected.
`- errors of any odd number in a message are detected.
`
`Total residual error probability for undetected corrupted messages: less than
`
`message error rate * 4.7 * 10'“.
`
`Error Signalling and Recovery Time
`Corrupted messages are flagged by any node detecting an error. Such messages are
`aborted and will be retransmitted automatically. The recovery time from detecting an
`error until the start of the next message is at most 29 bit times,
`if there is no further
`error.
`
`Fault Confinement
`
`CAN nodes are able to distinguish short disturbances from permanent
`Defective nodes are switched off.
`
`failures.
`
`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.
`
`‘
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00010
`
`Page 00010
`
`
`
`BOSCH
`
`I
`
`Basic Concepts
`
`Sep. 1991
`
`PartA_page9
`
`Acknowledgment
`the message being received and will
`All
`receivers check the consistency of
`acknowledge a consistent message and flag an inconsistent message.
`
`Slee Mode / Wake-u
`
`To reduce the system's power consumption, a CAN-device may be set into sleep mode
`without any internal activity and with disconnected bus drivers. The sleep mode is
`finished with a wake-up by any bus activity or by internal conditions of the system. On
`wake-up, the internal activity is restarted, although the transfer layer will be waiting for
`the system's oscillator to stabilize and it will then wait until it has synchronized itself to
`the bus activity (by checking for eleven consecutive ’recessive’ bits), before the bus
`drivers are set to "on-bus" again.
`In order to wake up other nodes of the system, which are in sleep-mode, a special
`wake-up message with the dedicated,
`lowest possible IDENTIFIER (rrr rrrd rrrr;
`r =
`’recessive’ d = ’dominant’) may be used.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00011
`
`Page 00011
`
`
`
`BOSCH
`
`Message Transfer
`
`Sep. 1991
`
`Part A_ page 10
`
`3 MESSAGE TRANSFER
`
`3.1 Frame Types
`
`Message transfer is manifested and controlled by four different frame types:
`
`A DATA FRAME carries data from a transmitter to the receivers.
`A REMOTE FRAME is transmitted by a bus unit to request the transmission of the
`DATA FRAME with the same IDENTIFIER.
`
`An ERROR FRAME is transmitted by any unit on detecting a bus error.
`An OVERLOAD FRAME is used to provide for an extra delay between the preceding
`and the succeeding DATA or REMOTE FRAMES.
`
`DATA FRAMES and REMOTE FRAMES are separated from preceding frames by an
`INTERFRAME SPACE.
`
`3.1.1 DATA FRAME
`
`A DATA FRAME is composed of seven different bit fields:
`START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD, CRC
`FIELD, ACK FIELD, END OF FRAME. The DATA FIELD can be of length zero.
`
`DATA FRAME
`
`lnterframe
`-1- Space
`
`Of
`
`Overload
`Frame
`
`Start of Frame
`
`Arbitration Field
`
`Control Field
`
`CRC Field
`
`ACK Field
`
`End of Frame
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00012
`
`Page 00012
`
`
`
`BOSCH
`
`START OF FRAME
`
`I
`
`Data Frame
`
`Sep. 1991
`
`PartA_page11
`
`marks the beginning of DATA FRAMES and REMOTE FRAMEs.
`‘dominant’ bit.
`
`It consists of a single
`
`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.
`
`I-<~ Control
`
`Field
`
`IDENTIFIER
`
`The |DENT|F|ER’s length is 11 bits. These bits are transmitted in the order from ID-10
`to lD—0. The least significant bit is ID-0. The 7 most significant bits (ID-10 - lD—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.
`
`DATA LENGTH CODE
`
`The number of bytes in the DATA FIELD is indicated by the DATA LENGTH CODE.
`This DATA LENGTH CODE is 4 bits wide and is transmitted within the CONTROL
`FIELD.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00013
`
`Page 00013
`
`
`
`BOSCH
`
`Data Frame
`
`Sep.1991
`
`PanA_page12
`
`Arbitration T CONTROL FIELD L-—p~ Data
`4- Field
`
`r0
`
`DLC3
`
`DLC2
`
`DLC1
`
`DLCO
`
`or
`
`CRC
`Field
`
`bits
`
`reserved
`
`Data Length Code
`
`Coding of the number of data bytes by the DATA LENGTH CODE
`
`abbreviations:
`
`d ‘dominant’
`r
`‘recessive’
`
`Number of Data
`Bytes
`
`Data Length Code
`DLC2
`DLC1
`
`DLCO
`
`DLC3
`
`d d
`
`Q.Q.Q.Q.Q.Q.Q.Q.
`
`“I
`
`DATA FRAME: admissible numbers of data bytes:
`Other values may not be used.
`
`{0,1,....,7,8}.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page00014
`
`Page 00014
`
`
`
`BOSCH
`
`DATA FIELD
`
`I
`
`Data Frame
`
`Sep. 1991
`
`PartA_page13
`
`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.
`
`CRC FIELD
`
`-df Ack
`Field
`
`CRC Sequence
`
`CRC Delimiter
`
`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:
`
`X15+X14+X10+X8+X7+X4+X3+1.
`
`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:
`
`CRC_RG = 0;
`REPEAT
`
`// initialize shift register
`
`CRCNXT = NXTBIT EXOR CRC_RG(14);
`CRC_RG(14:1) = CRC_RG(13:0);
`CRC_RG(0) = 0;
`
`// shift left by
`// 1 position
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00015
`
`Page 00015
`
`
`
`BCSCH
`
`Data Frame
`
`Sep. 1991
`
`Part A - page 14
`
`IF CRCNXT THEN
`
`ENDIF
`
`CRC_RG(14:0) = CRC_RG(14:0) EXOR (4599hex);
`
`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.
`reports this to the
`A RECEIVER which has received a valid message correctly,
`TRANSMITTER by sending a ‘dominant’ bit during the ACK SLOT (it sends ’ACK’).
`
`CRCR ACK FIELD T <— End of
`Field
`Frame
`
`jlfil‘
`
`ACK Slot
`
`ACK Delimiter
`
`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.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00016
`
`Page 00016
`
`
`
`BOSCH
`
`1
`
`3.1.2 REMOTE FRAME
`
`Remote Frame
`
`Sep. 1991
`
`PanA_page15
`
`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.
`
`REMOTE 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’).
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00017
`
`Page 00017
`
`
`
`BOSCH
`
`1
`
`3.1.3 ERROR FRAME
`
`Error Frame
`
`Sep. 1991
`
`PartA_page16
`
`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.
`
`Data *I--Ga ERROR FRAME
`Frame
`
`-l—— Error Flag —
`
`-<- lnterframe
`Space or
`
`Overload
`Frame
`
`Error Delimiter
`
`-4— superposition of :5-
`Error Flags
`
`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.
`
`1.
`
`The ACTIVE ERROR FLAG consists of six consecutive ’dominant’ bits.
`
`2.
`
`The PASSIVE ERROR FLAG consists of six consecutive ‘recessive’ bits unless it
`
`is oven/vritten by ‘dominant’ bits from other nodes.
`
`An ‘error active’ station detecting an error condition signals this by transmission of an
`ACTIVE ERROR FLAG. The ERROR FLAG’s form violates the law of bit stuffing (see
`CODING) applied to all fields from START OF FRAME to CRC DELIMITER or destroys
`the fixed form ACK FIELD or END OF FRAME field. As a consequence, all other
`stations detect an error condition and on their part start transmission of an ERROR
`FLAG. So the sequence of ’dominant’ bits which actually can be monitored on the bus
`results from a superposition of different ERROR FLAGs transmitted by individual
`stations. The total
`length of this sequence varies between a minimum of six and a
`maximum of twelve bits.
`An ‘error passive‘ station detecting an error condition tries to signal this by transmission
`of a PASSIVE ERROR FLAG. The ‘error passive‘ station waits for six consecutive bits
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00013
`
`Page 00018
`
`
`
`BOSCH
`
`Overload Frame
`
`Sep. 1991
`
`PartA_page17
`
`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. Aften/vards it starts transmitting seven
`more ’recessive’ bits.
`
`3.1.4 OVERLOAD FRAME
`
`The OVERLOAD FRAME contains
`OVERLOAD DELIMITER.
`There are two kinds of OVERLOAD conditions, which both lead to the transmission of
`an OVERLOAD FLAG:
`
`fields OVERLOAD FLAG and
`
`the two bit
`
`1.
`
`The internal conditions of a receiver, which requires a delay of the next DATA
`FRAME or REMOTE FRAME.
`
`2.
`
`Detection of a ’dominant’ bit during INTERMISSION.
`
`is only allowed to
`The start of an OVERLOAD FRAME due to OVERLOAD condition 1
`be started at the first bit time of an expected INTERMISSION, whereas OVERLOAD
`FRAMES due to OVERLOAD condition 2 start one bit after detecting the ’dominant’ bit.
`
`End of Frame or
`Error Delimiter or
`Overload Delimiter
`
`F
`3:32: or
`
`Overload
`Frame
`
`Overload Delimiter
`
`-I— Overload —--
`Flag
`
`<l—— superposition of
`0Ve”03d H393
`
`-—b-
`
`At most two OVERLOAD FRAMEs may be generated to delay the next DATA or
`REMOTE FRAME.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00019
`
`Page 00019
`
`
`
`BOSCH
`
`Overload Frame
`
`Sep. 1991
`
`PartA_page18
`
`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.
`
`3.1.5 INTERFRAME SPACING
`
`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.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00020
`
`Page 00020
`
`
`
`BOSCH
`
`lnterframe Space
`
`Sep. 1991
`
`Pa“ _ page 19
`
`For stations which are not ’error passive’ or have been RECEIVER of the previous
`message:
`
`Frame ~»‘<j INTERFRAME SPACE
`
`For ’error passive’ stations which have been TRANSMITTER of the previous message:
`
`Frame AT} INTERFRAME SPACE
`l
`l W
`
`‘ Intermission
`Intermission
`
`_
`
`_
`
`Suspend Transmission
`
`INTERMISSION
`
`consists of three ‘recessive’ bits.
`
`During INTERMISSION no station is allowed to start transmission of a DATA FRAME
`or REMOTE FRAME. The only action to be taken is signalling an OVERLOAD
`condition.
`
`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
`it sends eight ’recessive’
`After an ’error passive’ station has transmitted a message,
`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.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00021
`
`Page 00021
`
`
`
`BOSCH
`
`Transmitter/Receiver
`
`Sep. 1991
`
`PartA_page2o
`
`3.2 Definition of TRANSMITTERI RECEIVER
`
`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.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00022
`
`Page 00022
`
`
`
`BOSCH
`
`Message Validation
`
`Sep. 1991
`
`Farm _ page 21
`
`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:
`if there is no error until the end of END OF
`The message is valid for the transmitter,
`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.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00023
`
`Page 00023
`
`
`
`N
`
`Coding
`
`Sep. 1991
`
`PartA-page22
`
`SCODNG
`
`BIT STREAM CODING
`
`The frame segments START OF FRAME, ARB|TRAT|ON FIELD. CONTROL FIELD,
`DATA FIELD and CRC SEQUENCE are coded by the method of bit stuffing. Whenever
`a transmitter detects five consecutive bits of identical value in the bit stream to be
`transmitted it automatically inserts a complementary bit
`in the actual transmitted bit
`stream.
`The remaining bit fields of the DATA FRAME or REMOTE FRAME (CRC DELIMITER,
`ACK FIELD, and END OF FRAME) are of fixed form and not stuffed. The ERROR
`FRAME and the OVERLOAD FRAME are of fixed form as well and not coded by the
`
`method of bit stuffing.
`The bit stream in a message is coded according to the Non—Return-to—Zero (NRZ)
`method. This means that during the total bit
`time the generated bit
`level
`is either
`‘dominant’ or ’recessive'.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Page 00024
`
`Page 00024
`
`
`
`BOSCH
`
`Error Handling
`
`Sep. 1991
`
`PartA_page 23
`
`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 ERRQR
`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.
`
`- ACKNQWLEDGMENT ERROR
`An ACKNOWLEDGMENT ERROR has to be detected by a transmitter whenever it
`does not monitor a ‘dominant’ bit during the ACK SLOT.
`
`6.2 Error Signalling
`A station detecting an error condition signals this by transmitting an ERROR FLAG. For
`an ‘error active‘ node it is an ACTIVE ERROR FLAG, for an ‘error passive‘ node it is a
`PASSIVE ERROR FLAG. Whenever a BIT ERROR, a STUFF ERROR, a FORM
`ERROR or an ACKNOWLEDGMENT ERROR is detected by any station, transmission
`of an ERROR FLAG is started at the respective station at the next bit.
`Whenever a CRC ERROR is detected, transmission of an ERROR FLAG starts at