Figure 1. ECU Access to CAN bus

Transcription

1 Welcome to our 4th CAN Tech Tips feature (Sort of a Chinese New Year edition). In December we showed how the CAN frame is packaged before sending over the physical bus. In the edition we will cover the access method of the CAN bus, and how the protocol compensates for message collisions. For those who have missed the first 3 CAN Tech Tips, these can now be obtained from our archives on Also, this as a reminder that there are a few places available for our CAN and In-Vehicle Networks training on Wednesday February 19th. The January session was a sell-out, and with the addition of the Automotive lab using our Fiesta mock-up wiring harness station, it was a great success. There was a lot of stimulating discussion. For more info, please see our training page on: A date has been set for March as well 12 March 2014 Accessing the CAN bus Data bus, e.g. CAN ECU 1 ECU 2 ECU 3 ECU 4 Figure 1. ECU Access to CAN bus Last issue we talked about how the CAN frame is constructed into a nice small data package. Once this is done, the CAN controller will put this data package onto the CAN bus via the CAN transceiver. Before it does, the controller must check how busy the CAN bus is. All the ECUs are sharing this

2 virtual one wire system. As shown in the block diagram below (Figure 1), each ECU has access to this wire, and must contend for control of the wire (CAN bus). This is similar to a car trying to access a road at a junction. A node will access the road when there is space available. This newsletter will talk about how CAN messages access this contention-based bus architecture. We also discuss how CAN messages are prioritised, and how messages are dealt with when there is a collision between multiple messages. We also show an example of the result of a collision on a PicoScope display. Bus Access CSMA/CD Carrier Sense Multiple Access/Collision Detect When a node (ECU) is ready to send a CAN frame, it will sense the bus. If the bus is not busy with another message, the node will send the CAN message immediately, therefore taking command of the data bus. If the bus is already busy with a message from another ECU, the node will wait until that ECU if finished transmitting, and it will try to take over the bus with its CAN message. Figure 2 shows the flow of this access method, where node X is already transmitting on the bus when node Y attempts access the bus. Here node Y will sense that node X already has access to the bus, and node Y will wait until node X is finished. Then it will access the bus. From our notes in Tech Tip 3, we know that there is a minimum of 3 bits of interframe space after the EOF (End of Frame). This is to allow for a minor delay before other nodes can access the bus. Also interesting to note is the Network Latency Time in Figure 2. This shows the maximum delay a message will incur if the bus is busy. If we consider that Node Y tried accessing the bus just after Node X s SOF (Start of Frame), and consider that a typical CAN frame is between 100 to 150 bits long, the worst case delay due to busy bus is 150 x bit time. Now, in a typical powertrain configuration is operating at 500 Kbps. This means the bit time is 2 µsec (microseconds), and therefore the max latency will be approx. 150 x 2 µsec = 300 µsec. Figure 2. Access method to CAN bus

3 If two or more nodes attempt to transmit at the exact same time, a collision will occur. Every node senses the data it has transmitted. If there is a difference between what is transmitted and what is received, a collision is sensed. What happens next depends on the protocol. This is a typical data bus access method known as CSMA/CD Carrier Sense Multiple Access/Collision Detect. This method is used in Ethernet and CAN. In Ethernet, when a collision is detected, all nodes transmitting at the time will back off of the bus, go through a random time out, and retransmit their message. The random time out ensures these nodes do not retransmit at the same time. NDBA Non-Destructive Bitwise Arbitration CAN utilises CSMA/CD, but it also adds a method called Non-Destructive Bitwise Arbitration (NDBA). This is possible through the use of NRZ (Non-Return to Zero) digital signalling. This was covered back in Tech Tips 2. In CAN, the messages are prioritised by their respective identifiers. Recall back to Tech Tip 3, where we showed in the message format the Identifier (ID) was at the beginning, and it determined the priority of the message. The lower the ID value, the higher the priority. During Collision Detect in CAN, the message with the highest priority does not back off. It wins arbitration against the other nodes trying to transmit the same time as the high priority message. The lower priority messages will back off and retransmit when the highest priority message Is finished transmitting. An example of this method is shown in Figure 3. Here we can see that Nodes A (ID 1493), B ( ID 1501) and C (ID 2013) are accessing the CAN bus at the exact same time. They are arbitrating for the bus by matching each other bit for bit from Start of Frame (SOF). From my prior statement (the lower the ID, the higher the priority), it is obvious that Nodes A (ID 1493) will win arbitration.

4 Figure 3. Bitwise Arbitration At t1, it can be seen that Nodes A and B transmit a Dominant 0, and Node C transmits a Recessive 1. Since Dominant always overrides Recessive, Node C will see at its receiver a Dominant bit come back. At this point Node C has lost arbitration, and it will back off to become a receiver. It will attempt retransmission after this CAN frame. After t1, Nodes A and B are still on the bus, matching each other bit for bit. At t2, Node A transmits a Dominant 0 and Node B transmits a Recessive 1. Dominant overrides Recessive, and as a result, Node B will see the Dominant 0 come back to its receiver. At this point, Node B backs off to become a receiver to retransmit after this CAN frame. Node A has won arbitration and carries on transmitting its message without interruption. This ensures the throughput of high priority messages. Following Node 1 s finish of transmission, Nodes B and C will immediately access the bus, and they will arbitrate. Node B will win the arbitration, and when it finishes transmitting, Node C will access the bus. Using the timings mentioned earlier, Node C s worst case delay time will be approx. 600 µsec, so the whole process from the start of the collision to the EOF of Node C will be less than 1 msec (millisecond). The Oscilloscope illustration below in Figure 4 shows this back to back CAN frame relationship after and arbitration process. This is captured from a real situation our Ford Fiesta workshop mock up that we use in our training. Here you can see three back to back CAN messages as a result of a 3 way collision. Utilising the PicoScope s CAN decode feature, it can be seen that the first CAN message is ID 201 (highest priority), the second CAN message is ID 420, and the third CAN message is ID 620 (lowest priority).

5 Figure 4. CAN Collision Aftermath Here we illustrated how CAN frames (messages) access the CAN bus, and how the messages deal with collisions on the bus. The next CAN Tech Tip will discuss how this affects bus load, and the limitations of CAN. We will also talk about what happens when there is an error on the bus. Common Acronyms: CAN Controller Area Networks CAN_H CAN High CAN_L CAN Low CSMA/CD - Carrier Sense Multiple Access/Collision Detect ECU Electronic Control Unit EOF End of Frame Kbps Kilobits per Second ID - Identifier Inputs/Outputs of microcontrollers Mbps Megabits per Second NDBA Non-Destructive Bitwise Arbitration NRZ Non Return to Zero