Controller Are Network

Introduction

This report describes some of the di erent network protocols used in the automotive industry and then discusses similarities and di erences between them. The report is divided into three main sections. The rst describes the Controller Area Network (CAN), developed by Robert Bosch. This was identi ed as the most important network system for the project. There are several other protocols being developed for use in the industry, however, especially for \drive by wire” applications as well as earlier
protocols which might still be encountered. Some of these other protocols are described in the second section. The third section then considers similarities and di erences between these protocols from the point of view of the project, so discusses issues of interest for
modelling and simulating the networks. The references consulted are listed in a bibliography. Much of the investigation for this
report was done using the Web, so many of the sources are actually web-site urls rather than published papers. In the nature of the Web it is likely that some of these sources will become unavailable, but they have been checked during preparation of this report.
Many of the web sources have been downloaded and saved or printed, so if a reader of this report cannot nd a desired source, it might be worth getting in touch with the author.

 

Controller area Network

This section describes some of the features of the Controller Area Network of interest in modelling networks using the protocol and also brie y discusses these features from that point of view. It is therefore not a full description, the sources referred to should be
consulted for further information. Controller Area Network (CAN) is a network protocol developed by Robert Bosch
GmbH for vehicle systems, but which is coming into use for linking distributed controllers, sensors etc in other elds. Bosch have published a speci cation. The protocol has been adopted as a standard by the ISO, reference ISO11898. Any reference herein to the spec” means the Bosch speci cation, not the ISO one, which I have not seen (it costs!). CAN is a CSMA/CD protocol (some sources have CSMA/CR for similar protocols) that uses non-return to zero coding with bit stung. It supports speeds of up to 1Mb/s so is an SAE class C protocol, suitable for real time control applications. There is a brief explanation of the classes of protocols in section.
Messages are not addressed to intended recipients, but the sender’s identi er is included, and this tells the receivers what data it contains so the receiver ignores it if it is not interested. Messages’ identi ers give the priority of the message, so the priority of
messages is decided at the design stage.
In  there are two standards for CAN 2.0, imaginatively called A and B. These di er in message format (see section 2.2), B has an extended message format, with a 29 bit identi er, as opposed to A’s 11 bit one. In basic can (not to be confused with CAN \A”) each controller on the network is interrupted by every message on the bus. In full CAN, the CAN devices add ltration of
the messages, and will only pass messages with speci ed identi ers on to its associated controller, so a controller is only interrupted by those messages the CAN terminal passes, that is those of interest to that controller. The notes on CANbus in Automobile Electrical and Electronic Systems draw attention to the di erence between having a local intelligent control module (for example,for all functions located in the driver’s door) and having the intelligence actually in the actuators, so control is distributed, and each actuator (and each sensor) is on the bus itself.

  • Network access, collision detection and resolution

Binary zero is represented by a “dominant” state in the bus and binary one by a recessive state, so a binary zero takes precedence over a one, so lower numbered message identifier have priority over higher numbered ones. CAN is a CSMA/CD protocol. If the network is idle, any node can send a message. If two messages are sent simultaneously, the node that sends a recessive bit, but detects a dominant bit stops transmitting, leaving the network free for the higher priority message. The higher priority message is not corrupted (so-called non-destructive bitwise arbitration). As this strategy resolves collisions and does not merely detect them (as is the case with other CSMA/CD protocols, such as Ethernet), some sources describe protocols with a similar collision strategy as \CSMA/CR”, Carrier Sense Multiple Access/Collision Resolution. The identi er and RTR elds (see section 2.2) are used for collision arbitration. Therefore arbitration breaks down if two nodes can send data (as opposed to remote request) messages with the same identi er, as the clash will not be identi ed until later in the message, giving rise to a bit error. Each node must send data messages with a unique identifier. This has the side e ect that if, say, all four road wheels had rotation sensors (for ABS and traction control) they would each need their own identi er, so they would have an order of priority. It seems to me not unreasonable to suggest that this could lead to con icts in designing the system, which I do not propose to discuss here as it is outside the scope of the project. This is supposed to guarantee message latency, but surely can only do so for messages of high priority? Clearly this guarantees the highest priority message access to the network
once the current message transmission is complete. The second highest priority message is guaranteed access after that, provided the top priority message source doesn’t broadcast continuously, so this is pretty much guaranteed. Surely, however, as one moves down the order of priority, eventually one is going to reach a point where a high priority source might be ready to transmit again while a low priority source is still waiting, so its latency is not guaranteed. Is this one reason why the SAE J2284-500 standard is limited to 16 nodes? How well this limits message latency will inevitably depend on loading of the bus | how heavily used does it get, typically? It seems reasonable to suppose that rotation sensors (for wheel rotation, engine revs etc) cannot send data continually, as it takes time to nd the speed, so in practice this might limit bus load suciently for latency to be OK. I have seen a reference to a paper on Guaranteeing Message Latencies on CAN. I have not yet found a copy.

 

  • Message format

The format of the message frames is to be found in detail in the Bosch spec  or in less detail in the Omegas web-site  and the Kvaser web-site [10]. The standard CAN  frame has an 11 bit identi er, while an extended CAN  frame has a 29 bit identifier, for compatibility with other protocols used in the US vehicle industry. The standard identifier format allows for 2032 nodes on the network and the extended identifier allows more, but as the extra 18 identi er bits are needed for compatibility with other protocols, their use is restricted. The SAE J2284-500 standard allows for any number of nodes between 2 and 16, inclusive, which doesn’t seem many. devices are backward compatible, and can transmit and receive messages in either format. The \RTR” (transmission request) eld which is set to 1 if the message is a request for information follows the identi er. As such a \remote request” frame uses the identi er of the source of the required data, this means that data takes precedence over a request for that data, but a request for high priority data takes precedence over lower priority data. These remote request frames are apparently rarely used. The identi er eld and RTR eld are used in collision resolution. The data eld can contain from zero to eight bytes, its length being stated by a 4 bit DLC eld that immediately precedes the data eld. The data eld is followed by a 15 bit cyclic redundancy check (CRC), a delimiter, acknowledgement eld and end of frame and intermission elds. After these and a set idle time (which may be zero) another node can start transmission.

 

  •  Error detection

There are 5 error detection mechanisms:
1. Cyclic redundancy check. Each message contains a 15 bit CRC code computed by sender and checked by receivers, who will ag any errors. More in the spec.
2. Frame check. At certain points in the frame the current value is prede ned.
3. Acknowledgement Error Check. If the transmitter determines an error has not been
acknowledged, and ACK error is agged.
4. Bit monitoring. A transmitter checks the network and ags a \bit error” if the value on the bus is not that sent. This does not happen during transmission of the identi er eld, of course, as that is used for collision detection.
5. Bit stung. After ve consecutive bits of the same value, a bit of the opposite value is added to the frame. This avoids errors arising from poor synchronisation of the network nodes, necessary because non return to zero encoding means there is no change in network voltage during a succession of bits of similar value. If an error is detected, an error frame is sent, aborting the transmission.
Error con nement (which may be unique to CAN?) provides a mechanism for distinguishing between temporary and permanent errors. Each node has two error counters (for transmit and receive) which are incremented when errors are found. It is covered in more detail in the spec [19], but brie y each receive error increments its counter by one, and each transmit error increments its counter by 8. If either counter goes above 127 the node concerned goes into \error passive” mode. In this mode it can still transmit and receive messages, but is restricted in agging errors. If a device’s transmit error counter goes above 255, the device will go into \bus o ” mode and will cease to be active. This condition might need to be modelled in simulating CANbus systems for FMEA. This seems to imply that we must allow for the modelling of repeat errors or for modelling the network as though the counter(s) had reached a level such that devices were going into “bus o “ mode. A simpler approach, of course, would be simply to have \bus o ” as a failure mode  of the network terminal. This will allow the FMEA to test any mitigation strategy for this failure of the network. Error detection is thorough. Omegas’ material suggests that the undetected error probability is 10(expo 11) . Of course, detected errors will result in loss or delay to messages, which e ects might need modelling.

 

  • Bit timing and synchronisation

This is covered in the speci cation , of course, and there is an introduction to this in the Omegas material [16]. Brie y, a bit time consists of four non-overlapping segments, Sync-seg, Prop-seg, Phase-seg1 and Phase-seg2. An edge should lie within Sync-seg, while Prop-seg is used to compensate for delay times in the network. It is therefore the sum of twice the signal propagation time on the bus, the input comparator delay and the output driver delay, so is characteristic to the network. Phase-seg1 and Phase-seg2 are used to compensate for edge phase errors. They can be lengthened or shortened by resynchron-
isation. The sampling point is the boundary between Phase-seg1 and Phase-seg2. As non-return to zero encoding is used, there need not be an edge during Sync-seg, but bit stung ensures that there will be an edge after ve edge-free Sync-segs. There is a paper on The Con guration of the CAN bit timing [8] which describes the bit synchronisation algorithm and parameters to be considered in calculating the CAN bit time.

  • AN in the ISO/OSI stack and higher level protocols

The scope of the CANbus protocol covers the physical and data link layers of the ISO/OSI model. The speci cation  refers to three levels in the CANbus protocol | physical layer, transfer layer and object layer. The physical layer is not de ned in the Bosch spec, but is typically shielded or unshielded twisted pair. Idle state is both lines at +2.5 volts. A dominant bit reduces one line, known as CAN L, to zero, while increasing the other line (CAN H) to +5 volts while a recessive bit is close to the idle value, with CAN L slightly above CAN H, so is “over written” by a dominant bit. A standard for the physical layer of a 500 KBPS vehicle network is de ned in SAE J2284-500 . The transfer and object layers between them comprise all the services and functions of the ISO/OSI data link layer. These are discussed in the speci cation. Various higher level protocols might be added to CAN itself. Kvaser  has some material on this, and Omegas  have some links on their web-site. Of these the Kvaser
source is perhaps the more useful. I have also seen an article on higher level protocols that gives an overview of the most important higher layer protocols, especially those used in industrial automation.
The Can in Automation (CiA) trade organisation  supports various higher level protocols:
 CANopen
 DeviceNet
 CAL (CAN application layer)
 CAN Kingdom
 SDS (Smart Distributed System)CiA is an organisation mainly interested in using CAN for industrial automation so it may well be that the protocols listed above are more common in that eld than in the automotive sector. In addition to these, Kvaser list J1939 and OSEK. J1939 is an SAE standard for a Truck and Bus Control and Communications Network that uses the CAN protocol and includes documentation (though not explicit de nitions) for each layer in the ISO/OSI stack. There is a brief introduction to J1939 in section 3.5. OSEK is establishing standards for interfaces between hardware, network and software in the automotive eld. There is an introduction in appendix A. In addition there is FNOS (Ford Network Operating System) that appears to be a Ford alternative to OSEK. There is an introduction in appendix B. Both OSEK and FNOS provide higher level protocols for use with CAN, though their scope is broader than that. There appears to be a good deal of overlap between OSEK and FNOS.

 

See others Industrial Protocol