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 identifiers 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 (Non-destructive bitwise arbitration). As this strategy resolves collisions and does not merely detect them, some sources describe protocols with a similar collision strategy as CSMA/CR, Carrier Sense Multiple Access/Collision Resolution. The identifier and RTR fields are used for collision arbitration. Therefore arbitration breaks down if two nodes can send data (as opposed to remote request) messages with the same identifier, as the clash will not be identified 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 effect that if, say, all four road wheels had rotation sensors (for ABS and traction control) they would each need their own identifier, so they would have an order of priority. It seems to me not unreasonable to suggest that this could lead to conflicts 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 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. This is perhaps one reason why the SAE J2284-500 standard is limited to so few nodes? LOOK HARDER. How well this works will inevitably depend on loading of the bus(?) - how heavily used does it get, typically? LOOK HARDER! It seems reasonable to suppose that rotation sensors (for wheel rotation, engine revs etc) cannot send data continually, as it takes time to find the speed, so in practice this might limit bus load sufficiently for latency to be OK. There is a paper on Guaranteeing Message Latencies on CAN I have not yet found a copy।
0 Comments:
Post a Comment