BOSCH
`
`CAN Specification
`
`Version 2.0
`
`1991, Robert Bosch GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 1 of 72
`
`Petitioner's Exhibit 1010
`Page 1 of 72
`
`

`

`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.
`
`Petitioner's Exhibit 1010
`
`Page 2 of 72
`
`Petitioner's Exhibit 1010
`Page 2 of 72
`
`

`

`CAN Specification 2.0
`
`Sep. 1991
`page1
`
`Recital
`
`use of the extended format.
`
`The acceptance and introduction of serial communication to more and more
`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
`
`ROBERT BOSCH GmbH, Postfach 300240, D-7000 Stuttgart 30
`
`Petitioner's Exhibit 1010
`
`Page 3 0f 72
`
`Petitioner's Exhibit 1010
`Page 3 of 72
`
`

`

`PART A
`
`Petitioner's Exhibit 1010
`
`Page 4 of 72
`
`Petitioner's Exhibit 1010
`Page 4 of 72
`
`

`

`BOSCH
`
`Contents
`
`Sep. 1991
`
`Part A _ page 3
`
`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
`
`Protocol Modifications ........................................................................ 31
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 5 of 72
`
`Petitioner's Exhibit 1010
`Page 5 of 72
`
`

`

`BOSCH
`
`Introduction
`
`Sep. 1991
`
`Part A _ page 4
`
`1 INTRODUCTION
`
`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 CAN protocol on the surrounding 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
`
`-
`
`-
`
`-
`
`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 specification is to define the transfer layer and the consequences of
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 6 of 72
`
`Petitioner's Exhibit 1010
`Page 6 of 72
`
`

`

`BaSIC Concepts
`
`Sep. 1991
`part A . 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
`
`Physical Layer
`
`- Signal Level and Bit Representation
`- Transmission Medium
`
`
`
`- Message Framing
`- Transfer Rate and Timing
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 7 of 72
`
`Petitioner's Exhibit 1010
`Page 7 of 72
`
`

`

`338K: Concepts
`
`Sep. 1991
`part A . 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.
`
`handHng.
`
`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.
`
`Multicast: 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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 8 of 72
`
`Petitioner's Exhibit 1010
`Page 8 of 72
`
`

`

`338K: Concepts
`
`Sep. 1991
`part A . page 7
`
`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.
`
`- Message Frame Check
`
`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.
`
`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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 9 of 72
`
`Petitioner's Exhibit 1010
`Page 9 of 72
`
`

`

`BaSIC Concepts
`
`Sep. 1991
`part A . page 8
`
`Performance of Error Detection
`
`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'“.
`
`levels are not given in this specification.
`
`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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 10 0f 72
`
`Petitioner's Exhibit 1010
`Page 10 of 72
`
`

`

`338K: Concepts
`
`Sep. 1991
`part A . page 9
`
`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
`
`Petitioner's Exhibit 1010
`
`Page 11 of 72
`
`Petitioner's Exhibit 1010
`Page 11 of 72
`
`

`

`Message Transfer
`
`Sep. 1991
`Part A _ page10
`
`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.
`
`End of Frame
`
`lnterframe
`Space
`
`or
`
`Overload
`Frame
`
`lnterframe
`Space
`
`DATA FRAME
`
`
`
`|
`
`Start of Frame
`
`Arbitration Field
`
`Control Field
`
`|
`
`
`
`Data Field
`
`CRC Field
`
`ACK Field
`
`
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 12 of 72
`
`Petitioner's Exhibit 1010
`Page 12 of 72
`
`

`

`BOSCH
`
`Data Frame
`
`Sep. 1991
`
`PartA_page11
`
`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.
`
`Interframe
`Space
`
`Start
`of Frame
`
`Control
`Field
`
`
`ARBITRATION FIELD
`
`FIELD.
`
`‘ RTR Bit
`
`Identifier
`
`IDENTIFIER
`
`The IDENTIFIER‘s length is 11 bits. These bits are transmitted in the order from ID-1O
`to ID-O. The least significant bit is ID-O. The 7 most significant bits (ID-1O - 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.
`
`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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 13 of 72
`
`Petitioner's Exhibit 1010
`Page 13 of 72
`
`

`

`BOSCH
`
`Data Frame
`
`Sep. 1991
`
`PartA_page12
`
`Data
`Arbitration
`Field
`Field
`
`
`CONTROL FIELD
`
`or
`
`ORG
`Field
`
`reserved
`bits
`
`Data Length Code
`
`Coding of the number of data bytes by the DATA LENGTH CODE
`
`abbreviations:
`
`d ’dominant’
`
`r
`
`’recessive’
`
`Number of Data
`Data Length Code
`
`
`Bytes DLC1 DLCZ
`
`
`
`d d
`
`
`
`QQQQQQQQ.
`
`q
`
`Other values may not be used.
`
`DATA FRAME: admissible numbers of data bytes:
`
`{0,1 ,....,7,8}.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 14 of 72
`
`Petitioner's Exhibit 1010
`Page 14 of 72
`
`

`

`BOSCH
`
`Data Frame
`
`Sep. 1991
`
`PartA_page13
`
`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.
`
`Data
`or
`
`CRC FIELD
`
`Ack
`FIEId
`
`Control
`Field
`
`|
`
`‘ CRC Delimiter
`
`CRC Sequence
`
`// 1 position
`
`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 O. 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:O) 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 = O;
`REPEAT
`
`// initialize shift register
`
`CRCNXT = NXTBIT EXOR CRC_RG(14);
`CRC_RG(14:1) = CRC_RG(13:0);
`CRC_RG(O) = O;
`
`// shift left by
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 15 of 72
`
`Petitioner's Exhibit 1010
`Page 15 of 72
`
`

`

`BOSCH
`
`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’).
`
`CRC
`Field
`
`ACK FIELD
`
`End of
`Frame
`
`m ‘
`
`ACK Delimiter
`
`of seven ’recessive’ bits.
`
`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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 16 0f 72
`
`Petitioner's Exhibit 1010
`Page 16 of 72
`
`

`

`BOSCH
`
`Remote Frame
`
`Sep. 1991
`
`PartA_page15
`
`3.1.2 REMOTE FRAME
`
`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 O...8. The value is the DATA LENGTH
`CODE of the corresponding DATA FRAME.
`
`Inter
`Frame
`Space
`or
`Overload
`Frame
`
`(RTR bit ’dominant’) or a REMOTE FRAME (RTR bit ’recessive’).
`
`Inter
`Frame
`Space
`
`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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 17 0f 72
`
`Petitioner's Exhibit 1010
`Page 17 of 72
`
`

`

`Sep. 1991
`
`Part A - page 16
`
`3.1.3 ERROR FRAME
`
`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
`Frame
`
`ERROR FRAME
`
`Error Flag
`
`lnterframe
`Space or
`
`Overload
`Frame
`
`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.
`
`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 ovenNritten 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
`
`Petitioner's Exhibit 1010
`
`Page 18 of 72
`
`Petitioner's Exhibit 1010
`Page 18 of 72
`
`

`

`Overload Frame
`
`Sep. 1991
`
`Part A - page 17
`
`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.
`
`3.1.4 OVERLOAD FRAME
`
`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:
`
`The internal conditions of a receiver, which requires a delay of the next DATA
`FRAME or REMOTE FRAME.
`
`2.
`
`Detection ofa ’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.
`
`REMOTE FRAME.
`
`End of Frame or
`Error Delimiter or
`Overload Delimiter
`
`OVERLOAD FRAME
`
`Overload
`Flag
`
`Inter
`Frame
`Space or
`
`Overload
`Frame
`
`superposition of
`Overload Flags
`
`Overload Delimiter
`
`At most two OVERLOAD FRAMEs may be generated to delay the next DATA or
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 19 0f 72
`
`Petitioner's Exhibit 1010
`Page 19 of 72
`
`

`

`Overload Frame
`
`Sep. 1991
`Part A _ page 18
`
`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.
`
`TRANSMISSION.
`
`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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 20 0f 72
`
`Petitioner's Exhibit 1010
`Page 20 of 72
`
`

`

`lnterframe Space
`
`Sep. 1991
`Part A _ page 19
`
`For stations which are not ’error passive’ or have been RECEIVER of the previous
`message:
`
`Frame ar— INTERFRAME SPACE —>‘<7 Frame
`
`Intermission
`
`For ’error passive’ stations which have been TRANSMITTER of the previous message:
`
`INTERFRAME SPACE
`
`
`
`.
`.
`|ntermussuon
`
`Suspend Transmission
`
`Bus Idle
`
`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
`
`Petitioner's Exhibit 1010
`
`Page 21 of 72
`
`Petitioner's Exhibit 1010
`Page 21 of 72
`
`

`

`Transmitterl Receiver
`
`Sep. 1991
`
`Part A - page 20
`
`3.2 Definition of TRANSMITTER] 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
`
`Petitioner's Exhibit 1010
`
`Page 22 0f 72
`
`Petitioner's Exhibit 1010
`Page 22 of 72
`
`

`

`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
`
`Message Validation
`
`Sep. 1991
`Part A _ page 21
`
`4 MESSAGE VALIDATION
`
`END OF FRAME.
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 23 of 72
`
`Petitioner's Exhibit 1010
`Page 23 of 72
`
`

`

`Sep. 1991
`
`Part A - page 22
`
`5 CODING
`
`BIT STREAM CODING
`
`The frame segments START OF FRAME, ARBITRATION FIELD, CONTROL FIELD,
`DATA FIELD and CR0 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
`
`’dominant’ or ’recessive’.
`
`transmitted it automatically inserts a complementary bit
`stream.
`
`in the actual transmitted bit
`
`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
`
`ROBERT BOSCH GmbH, Postfach 50, D-7000 Stuttgart 1
`
`Petitioner's Exhibit 1010
`
`Page 24 of 72
`
`Petitioner's Exhibit 1010
`Page 24 of 72
`
`

`

`Error Handling
`
`Sep. 1991
`Farm _ 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 ’dom