山东科技大学学士学位论文 文献翻译附录二 文献翻译CAN protocol M .J .SchofieldThe CAN protocol is an international standard defined in the ISO 11898. Beside the CAN protocol itself the conformance test for the CAN protocol is defined in the ISO 16845, which guarantees the interchangeability of the CAN chips.1. Principles of data exchangeCAN is based on the “broadcast communication mechanism”, which is based on a message-oriented transmission protocol. It defines message contents rather than stations and station addresses. Every message has a message identifier, which is unique within the whole network since it defines content and also the priority of the message. This is important when several stations compete for bus access (bus arbitration). As a result of the content-oriented addressing scheme a high degree of system and configuration flexibility is achieved. It is easy to add stations to an existing CAN network without making any hardware or software modifications to the present stations as long as the new stations are purely receivers. This allows for a modular concept and also permits the reception of multiple data and the synchronization of distributed processes. Also, data transmission is not based on the availability of specific types of stations, which allows simple servicing and upgrading of the network.2. Real-time data transmissionIn real-time processing the urgency of messages to be exchanged over the network can differ greatly: a rapidly changing dimension, e.g. engine load, has to be transmitted more frequently and therefore with less delays than other dimensions, e.g. engine temperature. The priority, at which a message is transmitted compared to another less urgent message, is specified by the identifier of each message. The priorities are laid down during system design in the form of corresponding binary values and cannot be changed dynamically. The identifier with the lowest binary number has the highest priority. Bus access conflicts are resolved by bit-wise arbitration of the identifiers involved by each station observing the bus level bit for bit. This happens in accordance with the wired-and-mechanism, by which the dominant state overwrites the recessive state. All those stations (nodes) with recessive transmission and dominant observation lose the competition for bus access. All those losers automatically become receivers of the message with the highest priority and do not re-attempt transmission until the bus is available again. Transmission requests are handled in order of their importance for the system as a whole. This proves especially advantageous in overload situations. Since bus access is prioritized on the basis of the messages, it is possible to guarantee low individual latency times in real-time systems.3. Message frame formatsThe CAN protocol supports two message frame formats, the only essential difference being in the length of the identifier. The “CAN base frame” supports a length of 11 bits for the identifier, and the “CAN extended frame” supports a length of 29 bits for the identifier. 4. CAN extended frame formatThe difference between an extended frame format message and a base frame format message is the length of the identifier used. The 29-bit identifier is made up of the 11-bit identifier (“base identifier”) and an 18-bit extension (“identifier extension”). The distinction between CAN base frame format and CAN extended frame format is made by using the IDE bit, which is transmitted as dominant in case of an 11-bit frame, and transmitted as recessive in case of a 29-bit frame. As the two formats have to co-exist on one bus, it is laid down which message has higher priority on the bus in the case of bus access collision with different formats and the same identifier / base identifier: The 11-bit message always has priority over the 29-bit message. The extended format has some trade-offs: The bus latency time is longer (in minimum 20 bit-times), messages in extended format require more bandwidth (about 20 %), and the error detection performance is lower (because the chosen polynomial for the 15-bit CRC is optimized for frame length up to 112 bits). CAN controllers, which support extended frame format messages are also able to send and receive messages in CAN base frame format. CAN controllers that just cover the base frame format do not interpret extended frames correctly. However there are CAN controllers, which only support the base frame format but recognize extended messages and ignore them.5. Detecting and signaling errorsUnlike other bus systems, the CAN protocol does not use acknowledgement messages but instead signals errors immediately as they occur. For error detection the CAN protocol implements three mechanisms at the message level (data link layer: OSI layer 2): Cyclic Redundancy Check (CRC): The CRC safeguards the information in the frame by