Controller Area Network. CAN History

Transcription

1 CAN History Bosch originally developed the Controller Area Network (CAN) in 1985 for in-vehicle networks. In the past, automotive manufacturers connected electronic devices in vehicles using point-to-point wiring systems. Manufacturers began using more and more electronics in vehicles, which resulted in bulky wire harnesses that were very heavy and expensive. They then replaced dedicated wiring with in-vehicle networks, which reduce wiring cost, complexity, and weight. CAN, a high-integrity serial bus system for networking intelligent devices, emerged as the standard in-vehicle network. The automotive industry quickly adopted CAN and, in 1993, it became the international standard known as ISO Since 1994, several higher-level protocols have been standardized on CAN, such as CAN open and Device Net. Other markets have widely adopted these additional protocols, which are now standards for industrial communications. This white paper focuses on CAN as an in-vehicle network. Milestones of CAN History 1983 Start of the Bosch internal project to develop an In vehicle network. DEPARTMENT OF COMPUTER SCIENCEPage 1

2 1986 Official introduction of CAN protocol 1987 First CAN controller chips from Intel and Philips semiconductors Bosch s CAN specification 2.0 published CAN kingdom CAN based higher layer protocol Introduced by Kvaser CAN in automation (CiA) international users And manufacturers group established CAN application layer (CAL) protocol Published by CiA First car s from Mercedes Benz used CAN Network ISO standard published First international CAN conference (icc) Organized by CiA Device net protocol introduction by Allen Bradley. DEPARTMENT OF COMPUTER SCIENCEPage 2

3 1995 ISO amendment (Extended Frame Format) published CAN open protocol published by CiA Development of the Time triggered Communication protocol for CAN (TTCAN). DEPARTMENT OF COMPUTER SCIENCEPage 3

4 INTRODUCTION The Controller Area Network (the CAN bus) is a serial communications bus for real-time control applications; operates at data rates of up to 1 Megabits per second, and has excellent error detection and confinement capabilities. CAN was originally developed by the German company, Robert Bosch, for use in cars, to provide a cost-effective communications bus for in-car electronics and as alternative to expensive, cumbersome and unreliable wiring looms and connectors. The car industry continues to use CAN for an increasing number of applications, but because of its proven reliability and robustness, CAN is now also being used in many other control applications. CAN is an international standard and is documented in ISO (for high-speed applications) and ISO (for lower-speed applications). Low-cost CAN controllers and interface devices are available as off-the-shelf components from several of the leading semiconductor manufacturers. Custom built devices and popular microcontrollers with embedded CAN controllers are also available. There are many CAN-related system development packages, hardware interface cards and easy-to-use DEPARTMENT OF COMPUTER SCIENCEPage 4

5 software packages that provide system designers, builders and maintainers with a wide range of design, monitoring, analysis, and test tools. CAN technology used in Cars To satisfy customer requirements for greater safety, comfort, and convenience, and to comply with increasingly stringent government legislation for improved pollution control and reduced fuel consumption, the car industry has developed many electronic systems. Anti-lock Braking, Engine Management, Traction Control, Air Conditioning Control, central door locking, and powered seat and mirror controls are just some examples. The complexity of these controls systems, and the need to exchange data between them meant that more and more hard-wired, dedicated signal lines had to be provided. Sensors had to be duplicated if measured parameters were needed by different controllers. Apart from the cost of the wiring looms needed to connect all these components together, the physical size of the wiring looms sometimes made it impossible to thread them around the vehicle (to control panels in the doors, for example). In addition to the cost, the increased number of connections posed serious reliability, fault diagnosis, and repair problems during both manufacture and in service. DEPARTMENT OF COMPUTER SCIENCEPage 5

6 A new solution was needed and, in the mid 1980s, the Robert Bosch company (a highly regarded supplier of components and sub systems to the automotive industry) provided the answer by specifying the Controller Area Network (CAN). Many of the world's chip manufacturers now offer a wide range of semiconductor devices that implement the protocol in small low-cost controllers and interface devices and most modern cars (certainly in Europe - and increasingly in the rest of the world) now use CAN. Industrial Applications of CAN CAN controllers and interface chips are physically small. They are available as low-cost, off-the-shelf components. They will operate at high, real-time speeds, and in harsh environments. All these properties have led to CAN also being used in a wide range of applications other than the car industry. The benefits of reduced cost and improved reliability that the car industry gains by using CAN are now available to manufacturers of a wide range of products. For example: Marine control and navigation systems Elevator control systems DEPARTMENT OF COMPUTER SCIENCEPage 6

7 Agricultural machinery Production line control systems Machine tools Large optical telescopes Photo copiers Medical systems Paper making and processing machinery Packaging machinery Textile production machinery even toys for children Using CAN to network controllers, actuators, sensors, and transducers, manufacturers of all the abovementioned computer controlled products have benefited from: Reduced design time (readily available, multi sourced components, and tools) Lower connection costs (lighter, smaller cables and connectors) Improved reliability (fewer connections.) Safety: The safety-related aspects of using CAN in cars attracted the attention of manufacturers of medical systems. Because of the inherent reliability of the data transmission and the stringent safety DEPARTMENT OF COMPUTER SCIENCEPage 7

8 requirements that need to be built into medical equipment such as X-ray machines and radio-therapy systems, CAN is now used in a range of these systems. User Groups: To cater for the growth in the use of CAN and to provide a forum for discussion, several User Groups have been formed. One of the first to be formed was the CAN Textile Users Group, but the principal international Users Group is CAN in Automation (CiA). Click here to access the CiA web site. How does CAN works? Principle: Data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any intended receiving node. Instead, the content of the message (e.g. Revolutions Per Minute, Hopper Full, X-ray Dosage, etc.) is labelled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node. If the message is relevant, it will be processed; otherwise it is ignored. The unique identifier also DEPARTMENT OF COMPUTER SCIENCEPage 8

9 determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. In situations where two or more nodes attempt to transmit at the same time, a non-destructive arbitration technique guarantees that messages are sent in order of priority and that no messages are lost. Bit encoding: CAN uses Non Return to Zero (NRZ) encoding (with bit-stuffing) for data communication on a differential two wire bus. The use of NRZ encoding ensures compact messages with a minimum number of transitions and high resilience to external disturbance. The physical bus: The two wire bus is usually a twisted pair (shielded or unshielded). Flat pair (telephone type) cable also performs well but generates more noise itself, and may be more susceptible to external sources of noise. Robustness: CAN will operate in extremely harsh environments and the extensive error checking mechanisms ensure DEPARTMENT OF COMPUTER SCIENCEPage 9

10 that any transmission errors are detected. See the 'Error Handling' section of this site for more details. The ISO11898 standard "Recommends" that bus interface chips be designed so that communication can still continue (but with reduced signal to noise ratio) even if: - Either of the two wires in the bus is broken - Either wire is shorted to power - Either wire is shorted to ground Network Flexibility and Expansion: The content-oriented nature of the CAN messaging scheme delivers a high degree of flexibility for system configuration. New nodes that are purely receivers, and which need only existing transmitted data can be added to the network without the need to make any changes to existing hardware or software. Measurements needed by several controllers can be transmitted via the bus, thereby removing the need for each controller to have its own individual sensor. Arbitrary Works on the CAN Bus: In any system, some parameters will change more rapidly than others. For example - parameters that change quickly could be the RPM of a car engine, or the current floor level of an elevator (US) - lift (UK). DEPARTMENT OF COMPUTER SCIENCEPage 10

11 Slower changing parameters may be the temperature of the coolant of a car engine. It is likely that the more rapidly changing parameters need to be transmitted more frequently and, therefore, must be given a higher priority. To determine the priority of messages, CAN uses the established method known as Carrier Sense, Multiple Access with Collision Detect (CSMA/CD) but with the enhanced capability of non-destructive bitwise arbitration to provide collision resolution, and to deliver maximum use of the available capacity of the bus. Non-Destructive Bitwise Arbitration: The priority of a CAN message is determined by the numerical value of its identifier. The numerical value of each message identifier (and thus the priority of the message) is assigned during the initial phase of system design. The identifier with the lowest numerical value has the highest priority. Any potential bus conflicts are resolved by bitwise arbitration in accordance with the wired-and mechanism, by which a dominant state (logic 0) overwrites a recessive state (logic 1). The Benefits: Non-destructive bitwise arbitration provides bus allocation on the basis of need, and delivers DEPARTMENT OF COMPUTER SCIENCEPage 11

12 efficiency benefits that cannot be gained from either fixed time schedule allocation (e.g. Token ring) or destructive bus allocation (e.g. Ethernet.) With only the maximum capacity of the bus as a speed limiting factor CAN will not collapse or lock up. Outstanding transmission requests are dealt with in their order of priority, with minimum delay, and with maximum possible utilization of the available capacity of the bus. CAN Message Format Message Frames: In a CAN system, data is transmitted and received using Message Frames. Message Frames carry data from a transmitting node to one, or more, receiving nodes. The Standard CAN protocol (version 2.0A), also now known as Base Frame Format, supports messages with 11 bit identifiers. The Extended CAN protocol (version 2.0B), also now known as Extended Frame Format, supports both 11 bit and 29 bit identifiers. Most 2.0A controllers transmit and receive only Standard format messages, although some (known as 2.0B passive) will receive extended format DEPARTMENT OF COMPUTER SCIENCEPage 12

13 messages - but then ignore them. 2.0B controllers can send and receive messages in both formats. 2.0A Format: A Standard CAN (Version 2.0A) Message Frame consists of seven different bit fields: A Start of Frame (SOF) field - which indicates the beginning of a message frame. An Arbitration field, containing a message identifier and the Remote Transmission Request (RTR) bit. The RTR bit is used to discriminate between a transmitted Data Frame and a request for data from a remote node. Fig.CAN 2.0A Message Frame A Control Field containing six bits: * two reserved bits (r0 and r1) and * a four bit Data Length Code (DLC). The DLC indicates the number of bytes in the Data Field that follows A Data Field, containing from zero to eight bytes. DEPARTMENT OF COMPUTER SCIENCEPage 13

14 The CRC field, containing a fifteen bit cyclic redundancy check code and a recessive delimiter bit The Acknowledge field, consisting of two bits. The first is the Slot bit which is transmitted as recessive, but is subsequently over written by dominant bits transmitted from any node that successfully receives the transmitted message. The second bit is a recessive delimiter bit The End of Frame field, consisting of seven recessive bits. Following the End of Frame is the Intermission field consisting of three recessive bits. After the three bit Intermission period the bus is recognized to be free. Bus Idle time maybe of any arbitrary length including zero. 2.0B Format: The CAN 2.0B format provides a twenty nine (29) bit identifier as opposed to the 11 bit identifier in 2.0A. Version 2.0B evolved to provide compatibility with other serial communications protocols used in automotive applications in the USA. To cater for this, and still provide compatibility with the 2.0A format, the Message Frame in Version 2.0B has an extended format. The differences are: DEPARTMENT OF COMPUTER SCIENCEPage 14

15 - In Version 2.0B the Arbitration field contains two identifier bit fields. The first (the base ID) is eleven (11) bits long for compatibility with Version 2.0A. The second field (the ID extension) is eighteen (18) bits long, to give a total length of twenty nine (29) bits. - The distinction between the two formats is made using an Identifier Extension (IDE) bit. - A Substitute Remote Request (SRR) bit is also included in the Arbitration Field. The SRR bit is always transmitted as a recessive bit to ensure that, in the case of arbitration between a Standard Data Frame and an Extended Data Frame, the Standard Data Frame will always have priority if both messages have the same base (11 bit) identifier. All other fields in a 2.0B Message Frame are identical to those in the Standard format. 2.0A and 2.0B Compatibility: 2.0B controllers are completely backward compatible with 2.0A controllers and can transmit and receive messages in either format. Note, however, that there are two types of 2.0A controllers: - The first is capable of transmitting and receiving only messages in 2.0A format. With this type of controller, reception of any 2.0B message will flag an error. DEPARTMENT OF COMPUTER SCIENCEPage 15

16 - The second (known as 2.0B passive) is capable of sending and receiving 2.0A messages. They will also acknowledge receipt of 2.0B messages - but then ignore them. Therefore, within the above mentioned constraints it is possible to use both Version 2.0A (with 2.0B passive capabilities) and 2.0B controllers on a single network. The number of unique identifiers available to users, on a single 2.0A network, is 2,032 (2 to the power 11-2 to the power 4). Leaving aside the use for compatibility purposes with American buses, the number of unique identifiers available on a 2.0B network is in excess of 500 million! Implementations of CAN Communication is identical for all implementations of CAN. However, there are two principal hardware implementations. The two implementation are known as Basic CAN and Full CAN. ***Note*** The terms Basic CAN and Full CAN must not be confused with the terms Standard CAN - also known as Base Frame Format (11 bit identifier, Version 2.0A DEPARTMENT OF COMPUTER SCIENCEPage 16

17 data format) and Extended CAN - also known as Extended Frame Format (29 bit identifier, or Version 2.0B data format). Suitably configured, each implementation (Basic or Full CAN) can handle both Base and Extended data formats. Basic CAN: In the Basic-CAN devices, only basic functions concerning the filtering and management of CAN messages are implemented in hardware. A Basic-CAN controller typically provides one transmit buffer for outgoing messages and one or two receive buffers for incoming messages. In the receive path, an acceptance filtering is available which allows that only certain CAN identifiers are stored in the receive buffer. Because there are only two buffers for the reception of messages the host controller is quite busy reading and storing the incoming messages before they get overwritten by the following ones which results in a quite high CPU load. Also the answering of Remote Frames with the corresponding Data Frame has to be handled by the host controller. Therefore Basic-CAN devices should only be used at low baud rates and low bus loads with only a few different messages. DEPARTMENT OF COMPUTER SCIENCEPage 17

18 Full CAN: Full-CAN devices provide the whole hardware for convenient acceptance filtering and message management. For each message to be transmitted or received these devices contain one so called message object in which all information regarding the message (e.g. identifier, data bytes etc.) are stored. During the initialisation of the device, the host CPU defines which messages are to be sent and which are to be received. Only if the CAN controller receives a message whose identifier matches with one of the identifiers of the programmed (receive-) message objects the message is stored and the host CPU is informed by interrupt. Another advantage is that incoming Remote Frames can be answered automatically by the Full- CAN controller with the corresponding Data Frame. In DEPARTMENT OF COMPUTER SCIENCEPage 18

19 this way, the CPU load is strongly reduced compared to the Basic-CAN solution. Using Full CAN devices, high baudrates and high bus loads with many messages can be handled. Many Full-CAN controller provide a "Basic-CAN Feature": One of their message objects behaves like a Basic-CAN Receive Buffer, i.e. it can be programmed in a way that every message is stored there that does not match with one of the other message objects. This can be very helpful in applications where the number of message objects is not enough to receive all desired messages. Network Sizes: DEPARTMENT OF COMPUTER SCIENCEPage 19

20 The number of nodes that can exist on a single network is, theoretically, limited only by the number of available identifiers. However, the drive capabilities of currently available devices impose greater restrictions. Depending on the device types, up to 32 or 64 nodes per network is normal, but at least one manufacturer now provides devices that will allow networks of 110 nodes. Data Rate vs. Bus Length: The rate of data transmission depends on the total overall length of the bus and the delays associated with the transceivers. For all ISO11898 compliant devices running at 1Mbit/sec speed, the maximum possible bus length is specified as 40 Meters, For longer bus lengths it is necessary to reduce the bit rate. To give some indication of this the following numbers are from the Device Net features list: 500 K bits per second at 100 meters (328 ft) 250 K bits per second at 200 metres (656 ft) 125 K bits per second at 500 metres (1640 ft) The OSI model ISO7498 defines a communications standard known as the Open Systems Interconnection (OSI) model. This model describes how communications should DEPARTMENT OF COMPUTER SCIENCEPage 20

21 occur between computers on any network, and has been adopted as a general "open" network communication standard. In principle - anything that conforms to the standard can communicate, electronically, with anything else that conforms to the standard. The OSI model defines seven independent "layers" of a protocol stack. Strict compliance with the standard requires that each layer is insulated from the others by well-defined interfaces. Few, if any, networks comply absolutely with the OSI model with regard to provision of all seven layers as distinct entities. Fig.OSI reference model. CAN and the OSI Model DEPARTMENT OF COMPUTER SCIENCEPage 21

22 The CAN specification (ISO11898) discusses only the Physical and Data-Link layers for a CAN network. The Data-Link Layer - is the only layer that recognizes and understands the format of messages. This layer constructs the messages to be sent to the Physical Layer, and decodes messages received from the Physical Layer. In CAN controllers, the Data-Link Layer is usually implemented in hardware. The Physical Layer - specifies the physical and electrical characteristics of the bus, and of the hardware that converts the characters of a message into electrical signals for transmitted messages - and electrical signals into characters for received messages. Although the other layers may be implemented in either hardware (as chip level functions) or software, the Physical Layer is always "real" hardware. CAN Applications Layers: Many applications of CAN require services that are beyond the basic functionality specified by the Data- Link Layer but which may be implemented at the Application Layer. For example, the transmission or reception of data units longer than eight bytes. To meet this need several organizations have developed Application Layers. Brief details about just a few of them and contact details are given below. CAL (CAN Application Layer): DEPARTMENT OF COMPUTER SCIENCEPage 22

23 Aptly named, and based on an existing and proven protocol originally developed by Philips Medical Systems, CAL is an application-independent application layer that has been specified and is now maintained by the CAN in Automation (CiA) user group. Anyone who implements CAL may do so free of any license royalty. The CAL specification (document reference CiA DS ) may be purchased from CiA. See the CiA web site for details. CAN open: CAN open is an implementation of CAL and is defined by the CAN open Communications Profile in CiA DS This document may also be purchased from CiA. Information about CAN open may be obtained from the CiA User Group You might also want to get hold of a copy of "Embedded Networking with CAN and CAN open" by Olaf Pfeiffer, Andrew Ayre and Christian Keydel. Published by RTC Books. ISBN: Price in the USA $ Device Net: Device Net is a CiA-approved application layer based on CAN 2.0A and is widely used in industrial automation applications. Device Net (originally developed by Rockwell/Allen-Bradley) is now an Open field bus regulated by an independent organization knows as the Open Device Net Vendors DEPARTMENT OF COMPUTER SCIENCEPage 23

24 Association, from who copies of the specification may be purchased. Purchasers of the specification receive an unlimited, royalty-free license to develop Device Net compatible products. See the ODVA web site for full details. NMEA 2000: An application layer used in the marine and pleasure craft sector. For details see the NMEA web site. SDS (Smart Distributed System): SDS is also a CiA-approved application layer. Developed by Honeywell, one of the main uses of SDS is for machine control applications. See the Honeywell web site for details. CAN Kingdom: Another CiA-approved application layer, named CAN Kingdom, is provided by a Swedish company named Kvaser AB. You can find out all about it if you search the Kvaser site. DEPARTMENT OF COMPUTER SCIENCEPage 24

25 Error Detection CAN implements five error detection mechanisms; three at the message level and two at the bit level. At the message level: Cyclic Redundancy Checks (CRC) Frame Checks Acknowledgment Error Checks (ACK) At the bit level: Bit Monitoring Bit Stuffing Cyclic Redundancy Check: Every transmitted message contains a 15 bit Cyclic Redundancy Check (CRC) code. The CRC is computed by the transmitter and is based on the message content. All receivers that accept the message perform a similar calculation and flag any errors. If node B detects a mismatch between the calculated and the received CRC sequence, then a CRC error has occurred. Node B discards the message and transmits an Error Frame to request retransmission of the garbled frame. DEPARTMENT OF COMPUTER SCIENCEPage 25

26 Frame Check: There are certain predefined bit values that must be transmitted at certain points within any CAN Message Frame. If a receiver detects an invalid bit in one of these positions a Form Error (also known as a Format Error) will be flagged. If a transmitter detects a dominant bit in one of the four segments: CRC Delimiter, Acknowledge Delimiter, End of Frame or Interframe Space DEPARTMENT OF COMPUTER SCIENCEPage 26

27 then a Form Error has occurred and an Error Frame is generated. The message will then be repeated. Acknowledgement (ACK) Error Check: If a transmitter determines that a message has not been acknowledged then an ACK Error is flagged. With the Acknowledge Check, the transmitter checks in the Acknowledge Field of a message to determine if the Acknowledge Slot, which is sent out as a recessive bit, contains a dominant bit. If this is the case, at least one other node, (here node B) has received the frame correctly. If not, an Acknowledge Error has occurred and the message has to be repeated. No Error Frame is generated, though. DEPARTMENT OF COMPUTER SCIENCEPage 27

28 Bit Monitoring: Any transmitter automatically monitors and compares the actual bit level on the bus with the level that it transmitted. If the two are not the same, a bit error is flagged. All nodes perform Bit Monitoring: A Bit Error occurs if a transmitter sends a dominant bit but detects a recessive bit on the bus line or, sends a recessive bit but detects a dominant bit on the bus line. An Error Frame is generated and the message is repeated. When a dominant bit is detected instead of a recessive bit, no error occurs during the Arbitration Field or the Acknowledge Slot because these fields must be able to be overwritten by a dominant bit in order to achieve arbitration and acknowledge functionality. DEPARTMENT OF COMPUTER SCIENCEPage 28

29 Bit Stuffing: CAN uses a technique known as bit stuffing as a check on communication integrity. After five consecutive identical bit levels have been transmitted, the transmitter will automatically inject (stuff) a bit of the opposite polarity into the bit stream. Receivers of the message will automatically delete (de-stuff) such bits before processing the message in any way. Because of the bit stuffing rule, if any receiving node detects six consecutive bits of the same level, a stuff error is flagged. If six consecutive bits with the same DEPARTMENT OF COMPUTER SCIENCEPage 29

30 polarity are detected between Start of Frame and the CRC Delimiter, the bit stuffing rule has been violated. A stuff error occurs and an Error Frame is generated. The message is then repeated. Error Frame: If an error is detected by any node, using any and all of the five mechanisms described above, the node that detects the error aborts the transmission by sending an Error Frame. This prevents any other node from accepting the message and ensures consistency of data throughout the network. Error Confinement: Error confinement is a mechanism which is understood to be unique to CAN and provides a method for discriminating between temporary errors and permanent failures. Temporary errors may be DEPARTMENT OF COMPUTER SCIENCEPage 30

31 caused by, spurious external conditions, voltage spikes, etc. Permanent failures are likely to be caused by bad connections, faulty cables, defective transmitters or receivers, or long lasting external disturbances. The general principle only is described here. More detailed information is available in the ISO standard, and in the data sheets from the device manufacturers. Error Counts: When an error is flagged, error counts are added to one of two dedicated error count registers within each CAN controller on each node. It's more complex than stated here, but - in principal - receive errors are given a weighting of 1 and are accumulated in a Receive Error Count register; transmit errors are given a weighting of 8 and accumulated in a Transmit Error Count register. If errors continue to occur, the error counts continue to increase. Any good messages decrement the Error Count registers and, if no further errors are detected, both Error Counts go back to zero. The accumulated error counts determine the error status of a node. DEPARTMENT OF COMPUTER SCIENCEPage 31

32 Error Active Mode: Nodes usually operate in a state known as Error Active mode. In this condition a node is fully functional and both the Error Count registers contain counts of less than 127. DEPARTMENT OF COMPUTER SCIENCEPage 32

33 Error Passive Mode: If the count in either Error Count register in a node exceeds 127, the node will go from Error Active mode to a heightened state of "alert" known as Error Passive mode. Error Passive nodes can still transmit and receive messages but are restricted in relation to how they flag any errors that they may detect. The ISO standard (and some of the device data sheets) explain the precise mechanisms in more detail. DEPARTMENT OF COMPUTER SCIENCEPage 33

34 Bus Off Mode: If an error condition persists, such that the Transmit Error Count of a device exceeds 255, the device will take itself off the bus by going to BusOff mode. This means that a permanently faulty device will cease to be active on the bus until reconnected under user control, but communications between the other nodes can continue unhindered. Error Detection Capabilities: Error detection on CAN is extremely thorough. DEPARTMENT OF COMPUTER SCIENCEPage 34

35 Global errors which occur at all nodes are 100% detectable. For local errors (i.e. errors which may appear at only some nodes) the CRC check alone has the following error detection capabilities: Up to 5 single bit errors are 100% detectable, even if the errors are distributed randomly within the code word All single bit errors are detected if their total number within the code word is odd The residual (undetected) error probability of the CRC check alone is 3 x 10 to the power -5. In conjunction with all the other error checking mechanisms, a more realistic value is 10 to the power -11. Bit time: As defined in ISO11898, the nominal time for each bit in a CAN message frame is made up of four nonoverlapping time segments as shown below. DEPARTMENT OF COMPUTER SCIENCEPage 35

36 Fig. Bit time segments Sync-seg is the segment that is used to synchronize the nodes on the bus. A bit edge (if there is a data change) is expected during this segment. Prop-Seg is a period of time that is used to compensate for physical delay times within the network. Phase-seg1 is a buffer segment that may be lengthened during resynchronization to compensate for oscillator drift and positive phase differences between the oscillators of the transmitting and receiving node(s). Phase-seg2 is a buffer segment that may be shortened during resynchronization (described below) to compensate for negative phase errors and oscillator drift. The Sample point is always at the end of Phase-seg1 and is the time at which the bus level is read and interpreted as the value of the current bit. Whether transmitting or receiving, all nodes on a single CAN bus must have the same nominal bit time. Bit time is programmable at each node on a CAN Bus DEPARTMENT OF COMPUTER SCIENCEPage 36

37 and is a function of the period of the oscillator local to each node, the value that is user-programmed into a Baud Rate Prescaler (BRP) register in the controller at each node, and the programmed number of time quanta per bit. One time quanta (Also known as the system clock period) is defined as the period of the local oscillator, multiplied by the value in the BRP. Each of the four time segments in one bit is one or more time quanta long. As stated in the Bosch CAN2 spec: Sync-Seg is always one time quantum long Prop-Seg is programmable from one to eight (or, optionally, more) time quanta long Phase-seg1 is programmable from one to eight (or, optionally, more) time quanta long Phase-seg2 is the maximum of Phase-seg1 and the Information Processing Time Where the Information Processing Time is less than or equal to 2 time quanta. Synchronization When any node receives a data frame or a remote frame, it is necessary for the receiver to synchronize with the transmitter. DEPARTMENT OF COMPUTER SCIENCEPage 37

38 Because there is no explicit clock signal that a CAN system can use as a timing reference, two mechanisms are used to maintain synchronization. The first is hard synchronization and occurs at Startof-Frame (SOF). To compensate for oscillator drift, and phase differences between transmitter and receiver oscillators, additional synchronization is needed. So - for subsequent bits in any received frame, if a bit edge does not occur in the Sync-Seg segment of bit time, resynchronization is automatically invoked and will shorten or lengthen the current bit time depending on where the edge occurs. The maximum amount by which the bit time is lengthened or shortened is determined by a user-programmable number of time quanta known as the Synchronization Jump Width (SJW). DEPARTMENT OF COMPUTER SCIENCEPage 38

39 The overview of Controller Area Network s Basics Is a high-integrity serial data communications bus for real-time control applications. Operates at data rates of up to 1 Mega bits per second Have excellent error detection and confinement capabilities Was originally developed for use in cars Is now being used in many other industrial automation and control applications CAN is documented in ISO (for applications up to 1 Mega bits per second) and ISO (for applications up to 125 K bits per second) DEPARTMENT OF COMPUTER SCIENCEPage 39

40 CONTROLLER AREA NETWORK (CAN) PROTOCOL The Controller Area Network (CAN) protocol, developed by ROBERT BOSCH GmbH, offers a comprehensive solution to managing communication between multiple CPUs. The CAN protocol specifies versatile message identifiers that can be mapped to specific. Control information categories. Communications may occur at a maximum recommended rate of 1 Mbit/sec (roughly a 40 meter bus length). The protocol has found wide acceptance in automotive in-vehicle applications as well as many non-automotive due to its low cost, high performance, and the availability of DEPARTMENT OF COMPUTER SCIENCEPage 40

41 various CAN protocol implementations. In-vehicle networking protocols must satisfy unique requirements not present in other networking protocols such as those found in telecommunications and data processing. These requirements include a high level of error detection, low latency times and configuration flexibility. The CAN protocol provides four primary benefits. First, a standard communications protocol simplifies and economizes the task of interfacing subsystems from various vendors onto a common network. Second, the communications burden is shifted from the host-cpu to an intelligent peripheral; the host-cpu has more time to run its system tasks. Third, as a multiplexed network, CAN greatly reduces wire harness size and eliminates point-to-point wiring. Lastly, as a standard protocol, CAN has broad market appeal which motivates semiconductor makers to develop competitively priced CAN devices. An example of an application well-served by the CAN protocol is automotive networking because many modules are inter-dependent. Sub-systems such as the engine, DEPARTMENT OF COMPUTER SCIENCEPage 41

42 transmission, anti-lock braking, and accident avoidance systems require the exchange of particular performance and position information within a defined communications latency. The engine transmits engine speed and acceleration parameters to the transmission to allow smoother shifting. Perhaps the transmission requests the engine to reduce fuel injection before a gear change. CAN is a CSMA/CD-A, or Carrier Sense Multiple Access by Collision Detection using Arbitration protocol. Through a multi-master architecture, prioritized messages of length 8 bytes or less are sent on a serial bus. Error detection mechanisms, such as a 15-bit Cyclical Redundancy Check (CRC), provide a high level of data integrity. For information on the CAN protocol, please read the CAN Specification, Version 2.0. The CAN 2.0 protocol was chosen by the SAE Truck & Bus Control and Communications Network Subcommittee of the Truck & Bus Electrical Committee to support its ``Recommended Practice for Serial Control and Communciations Vehicle Network CLASS C'' called the SAE J1939 specification. The SAE CLASS C passenger car subcommittee is currently evaluating CAN, DEPARTMENT OF COMPUTER SCIENCEPage 42

43 which is a candidate for its high speed networks. Products using CAN Version 2.0 are already in production. The previous CAN specification, Version 1.2, has been successfully implemented in passenger car, train and factory automation applications since CAN Version 2.0, which features an ``extended frame'' with a 29- bit message identifier, broadens the application base for this protocol by allowing J1850 message schemes to be mapped into the CAN message format. The Intel was the first implementation of the CAN protocol, in production since The Intel is a follow-on to the which implements CAN Version 2.0, provides greater message handling capability and implements a more flexible interface to CPUs. DEPARTMENT OF COMPUTER SCIENCEPage 43

44 Vehicle Applications of Controller Area Network Introduction DEPARTMENT OF COMPUTER SCIENCEPage 44

45 In the automotive industry, embedded control has grown from stand-alone systems to highly integrated and networked control systems [11, 7]. By networking electro-mechanical subsystems, it becomes possible to modularize functionalities and hardware, which facilitates reuse and adds capabilities. Figure shows an example of an electronic control unit (ECU) mounted on a diesel engine of a Scania truck. The ECU handles the control of engine, turbo, fan, etc. but also the CAN communication. Combining networks and mechatronic modules makes it possible to reduce both the cabling and the number of connectors, which facilitates production and increases reliability. Introducing networks in vehicles also make it possible to more efficiently carry out diagnostics and to coordinate the operation of the separate subsystems. Protocol extensions DEPARTMENT OF COMPUTER SCIENCEPage 45

46 CAN provides the basic functionality described above. In many situations, it is desirable to use standardized protocols that define the communication layers on top of the CAN. Such higher-layer protocols are described below together with CAN gateways and the time-triggered extension of CAN denoted TTCAN, which allows periodic access to the communication bus with a high degree of certainty. Higher-layer protocols In order to use CAN, protocols are needed to define the other layers. Field bus protocols usually do not define the session and presentation layers, since they are not needed in these applications. The users may either decide to define their own software for handling the higher layers, or they may use a standardized protocol. Existing higher-layer protocols are often tuned to a certain application domain. Examples of such protocols include SAE J1939, CAN open, and Device Net. It is only SAE J1939 that is specially developed for vehicle applications. Recently, attempts have been made to interface CAN and Ethernet, which is the dominant technology for local area networks and widely applied for connecting to the Internet. SAE J1939 is a protocol that defines the higher-layer communication control. It was developed by the American Society of Automotive Engineers (SAE) and is thus targeted to the automotive industry. The advantage of having a standard is considerable, since it enables DEPARTMENT OF COMPUTER SCIENCEPage 46

47 independent development of the individual networked components, which also allows vehicle manufacturers to use components from different suppliers. SAE J1939 specifies, e.g., how to read and write data, but also how to calibrate certain subsystems. The data rate of SAE J1939 is about 250 kbps, which gives up to about 1850 messages per second [6]. Applications of SAE J1939 include truckand-trailer communication, vehicles in agriculture and forestry, as well as navigation systems in marine applications. CAN open is a standardized application defined on top of CAN and widely used in Europe for the application of CAN in distributed industrial automation. It is a standard of the organization CAN in Automation (CiA). CAN open specify communication profiles and device profiles, which enable an application-independent use of CAN. The communication profile defines the underlying communication mechanism. Device profiles exist for the most common devices in industrial automation, such as digital and analog I/O components, encoders, and controllers. The device can be configured through CAN open independent of its manufacturer. CAN open distinguish real-time data exchange and less critical data exchange. It provides standardized communication objects for real-time data, configuration data, network management data, and DEPARTMENT OF COMPUTER SCIENCEPage 47

48 certain special functions (e.g., time stamp and synchronization messages).device Net is another standardized application defined on top of CAN for distributed industrial automation. It is mainly used in the U.S.A. and Asia and was originally developed by Rockwell Automation. Device Net, Control-Net, and transmission control protocol/internet protocol (TCP/IP) are open network technologies that share upper layers of the communication protocol, but are based on lower layers. Device Net is built on CAN, Control Net on a tokenpassing bus protocol, and TCP/IP on Ethernet. CAN Kingdom is a high-layer protocol used for motion control systems. It is also used in the maritime industry; CAN Kingdom allows the changing of network behavior at any time, including while the system is running. For example, CAN Kingdom allows the system troubleshooter to turn off individual nodes. The CAN node identifiers and the triggering conditions for sending messages can be changed while the system is running. One instance when real-time network reconfiguration is used is during failure conditions. An example is a loss of a radio link ECU in a maritime application. The network monitor, also known as the King, in that case first shuts off the radio node to keep it from sending any more commands, and then tells the appropriate nodes to get data from the King. DEPARTMENT OF COMPUTER SCIENCEPage 48

49 This operation eliminates the problem of a node receiving two simultaneous but conflicting commands. It also eliminates the problem of two nodes sending the same CAN id. The high-level protocols described above have been developed with different applications and traditions in mind, which is reflected, for example, in their support for real-time control. Although SAE J1939 is used for implementing control algorithms, it does not provide explicit support for time-constrained messaging. In contrast, such functionalities are provided by CAN Kingdom and CAN open, which handle explicit support for inter-node synchronization. CAN Kingdom and CAN open allow static and dynamic configuration of the network, whereas SAE J1939 provides little flexibility. CAN gateways Gateways and bridges enable CAN-based networks to be linked together or linked to networks with other protocols. A gateway between a CAN and another communication network maps the protocols of the individual networks. There exist many different types of CAN gateways, e.g., CAN-RS232 and CAN-TCP/IP gateways. The latter can provide remote access to a CAN through the Internet, which allows worldwide monitoring and maintenance. The networks connected through a gateway or a bridge are disconnected in terms of their real-time behavior, so obviously the timing and performance of DEPARTMENT OF COMPUTER SCIENCEPage 49

50 the complex inter-connected network can be hard to predict even if the individual networks are predictable. Ethernet (or rather Ethernet/IP) is quite a different communication protocol compared to CAN, but is still of growing importance in industrial automation either in constellations with CAN or on its own. Traditionally, Ethernet is used in office automation and multimedia applications, while CAN dominates in vehicles and in certain industrial automation systems. The strength of Ethernet is the ability to quickly move large amounts of data over long distances and that the number of nodes in the network can be large. CAN, on the other hand, is optimized for transmitting small messages over relatively short distances. A drawback with a network based on the Ethernet protocol is that the nodes need to be quite powerful and complex (and therefore more expensive) in order to handle the communication control. Another drawback with Ethernet is that during network traffic congestion the delay jitter can be severe and unpredictable, although at low network load Ethernet gives almost no delay. Time-triggered communication on CAN Traditional CAN communication is event based: asynchronous events are triggered by node applications that initialize each transmission session. In many cases, this strategy is an efficient way to DEPARTMENT OF COMPUTER SCIENCEPage 50

51 share the network resource. There are a variety of applications, however, that require a guaranteed access to the communication bus with a fixed periodic rate. This constraint is typical for sampleddata feedback control systems. In the automotive industry, x-by-wire systems are examples of such control systems with deterministic communication behavior during regular operation. By introducing the notion of global network time, the standard ISO define the extension Time-triggered communication on CAN (TTCAN). It is built on top of the traditional event-triggered CAN protocol and enables existing CAN nodes to work in parallel with TTCAN nodes. The global clock requires hardware implementation; otherwise, TTCAN is a pure software extension of CAN. The synchronization in TTCAN takes place through a periodic reference message, which all TTCAN nodes recognize and use to synchronize their clocks. The nodes are configured to know when to send their message after the reference message. The period time of the transmission of a periodic node should be a multiple of the reference period. Traditional CAN nodes (or event-based TTCAN nodes) compete for the access of the free windows between the reference messages, along the line of the conventional CAN protocol. This mechanism is thus the reason why time-triggered and even triggered scheduling is possible simultaneously in TTCAN. The sender of the reference message is obviously a crucial node in TTCAN to guarantee clock DEPARTMENT OF COMPUTER SCIENCEPage 51

52 synchronization. Therefore, an automatic procedure is provided for letting another node take over if the reference sender fails, and taking the reference back when the original clock master recovers. It is possible to use an external clock, for example, from the global positioning system (GPS). Control Applications Two vehicular control systems with loops closed over CAN buses are discussed in this section. The first example is a vehicle dynamics control system for passenger cars that is manufactured by Bosch. The second example is an attitude and orbit control system for the SMART-1 spacecraft discussed in the previous section. Vehicle Dynamics control system Vehicle dynamics control4 systems are designed to assist the driver in over steering, under-steering and roll-over situations [15, 9]. The principle of a vehicle dynamics control (VDC) system is illustrated in figure. The left figure shows a situation where over-steering takes place, illustrating the case where the friction limits are reached for the rear wheels causing the tire forces to saturate (saturation on the front wheels will DEPARTMENT OF COMPUTER SCIENCEPage 52

53 instead cause an under-steer situation). Unless the driver is very skilled, the car will start to skid, meaning that the vehicle yaw rate and vehicle side slip angle will deviate from what the driver intended. This is the situation shown for the left vehicle. For the vehicle on the right, the on-board VDC will detect the emerging skidding situation and will compute a compensating torque, which for the situation illustrated is translated into applying a braking force to the outer front wheel. This braking force will provide a compensating torque and the braking will also reduce the lateral force for this wheel. The central components of VDC are illustrated on the right in figure. In essence, the VDC will assist the driver by making the car easier to steer and by improving its stability margin. Illustration of behavior during over-steering for vehicle with and without VDC system (left figure). Central components of VDC (right figure). (Based on figures provided by the Electronic Stability Control Coalition.) DEPARTMENT OF COMPUTER SCIENCEPage 53

54 Attitude and orbit control system This section describes parts of the SMART-1 attitude and orbit control system and how it is implemented in the on-board distributed computer system. The control objectives of the attitude and orbit control system are to: follow desired trajectories according to the goals of the mission, point the solar panels toward the sun, and minimize energy consumption. The control objectives should be fulfilled despite the harsh environment and torque disturbances acting on the spacecraft, such as aero drag (initially when close to earth), gravitational gradient, magnetic torque, and solar pressure (mechanical pressure from photons). There are several phases that the control system should be able to handle, including the phase just after separation from the launcher, the thrusting phases on the orbit to the moon, and the moon observation phase. DEPARTMENT OF COMPUTER SCIENCEPage 54

55 Structure of SMART-1 spacecraft with sensors and actuators for the attitude And orbit control system. (Courtesy of the Swedish Space Corporation.) The attitude and orbit control system consists of a set of control functions for rate damping, sun pointing, solar array rotation, momentum reduction, three-axis attitude control, and electric propulsion (EP) thruster orientation. The system has a number of operation modes, which consist of a subset of these control functions. The operation modes include the following: Detumble mode: In this mode, rotation is stabilized using one P-controller per axis with the aid of the hydrazine thrusters and the rate sensors. Safe mode: Here the EP thruster is pointed toward the sun and set to rotate one revolution per hour around the sun vector. The attitude is controlled using a bang-bang strategy for large sun angles and a PID controller for smaller angles. Both controllers use the reaction wheels as actuators and the sun tracker as sensor. DEPARTMENT OF COMPUTER SCIENCEPage 55

56 The spacecraft rotation is controlled using a PI controller. When the angular velocity of the reaction wheels exceeds a Certain limit, their momentum is reduced by use of the hydrazine thrusters. Science mode: In this mode, ground provides the attitude set-points for the spacecraft and the star tracker provides the actual attitude. The reaction wheels and the hydrazine thrusters are used. Electric propulsion control mode: This mode is similar to the science mode apart from the additional control of the EP orientation mechanism. This mechanism can be used to tilt the thrust vector in order to off-load the reaction wheel momentum about the two spacecraft axes that form the nominal EP thrust plane. This reduces the amount of hydrazine needed. The EP mechanism is controlled in an outer and slower control loop (PI) based on the speed of the reaction wheels and the rotation of the spacecraft body. Sales of CAN Nodes in Automation The CAN protocol was internationally standardized in 1993 as ISO The development of CAN was mainly motivated by the need for new functionality, but it also reduced the need for wiring. The use of CAN in the automotive industry has caused mass production of CAN controllers. Today, CAN controllers are integrated on many microcontrollers and available at a low cost. Figure DEPARTMENT OF COMPUTER SCIENCEPage 56

57 shows the number of CAN nodes that were sold during The number of CAN nodes sold per year is currently about 400 million. (Data from the association CAN in Automation) Perspectives The development of vehicles is going through a dramatic evolution, in their transition from pure mechanical systems to mechatronic machines with highly integrated hardware and software subsystems. DaimlerChrysler estimates that 90% of the innovations in the automotive area lie in electronics and software. A challenge in the development of vehicular embedded control systems is safety and real-time DEPARTMENT OF COMPUTER SCIENCEPage 57