Controller Are Network

Introduction

This report describes some of the dierent network protocols used in the automotive industry and then discusses similarities and dierences 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 dierences 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 dier 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 dierence 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 eect 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 eects 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.