PDF《BOSCH》

BOSCH CAN Specification Version 2.

0 1991, Robert Bosch GmbH, Postfach

30 02 40, D-70442 Stuttgart BOSCH ROBERT BOSCH GmbH, Postfach

30 02 40, D-70442 Stuttgart Sep.

1991 page

1 Recital 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 is required that a CAN implementation be compatible with either Part A or Part B. 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. CAN Specification 2.0 PART A BOSCH ROBERT BOSCH GmbH, Postfach

30 02 40, D-70442 Stuttgart Sep.

1991 Part A - page

3 1 INTRODUCTION.4

2 BASIC CONCEPTS.5

3 MESSAGE TRANSFER

10 3.1 Frame Types

10 3.1.1 DATA FRAME

10 3.1.2 REMOTE FRAME

15 3.1.3 ERROR FRAME.16 3.1.4 OVERLOAD FRAME.17 3.1.5 INTERFRAME SPACING.18 3.2 Definition of TRANSMITTER/RECEIVER

20 4 MESSAGE VALIDATION

21 5 CODING.22

6 ERROR HANDLING.23 6.1 Error Detection

23 6.2 Error Signalling.23

7 FAULT CONFINEMENT.24

8 BIT TIMING REQUIREMENTS

27 9 INCREASING CAN OSCILLATOR TOLERANCE.31 9.1 Protocol Modifications

31 Contents BOSCH ROBERT BOSCH GmbH, Postfach

30 02 40, D-70442 Stuttgart Sep.

1991 Part A - page

4 1 INTRODUCTION The Controller Area Network (CAN) is a serial communications protocol which efficiently supports distributed realtime control with a very high level of security. Its domain of application ranges from high speed networks to low cost multiplex wiring. In automotive electronics, engine control units, sensors, anti-skid-systems, etc. are connected using CAN with bitrates up to

1 Mbit/s. At the same time it is cost effective to build into vehicle body electronics, e.g. lamp clusters, electric windows etc. to replace the wiring harness otherwise required. The intention of this specification is to achieve compatibility between any two CAN implementations. Compatibility, however, has different aspects regarding e.g. electrical features and the interpretation of data to be transferred. To achieve design transparency and implementation flexibility CAN has been subdivided into different layers. ? the (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 specification is to define the transfer layer and the consequences of the CAN protocol on the surrounding layers. Introduction BOSCH ROBERT BOSCH GmbH, Postfach