Consider that in a network we have some N number of ECU and all this ecu communicates with each other and also a Common ECU that can take input from any of the N Application ECU and give a response. How is the frame handled? Is it only using priority? Or some time scheduling is done?

I came across an approach where they have used Repetition time and Inhibit time? Inhibit time is understood the minimum possible time the data can change, this way the load of CAN bus can be reduced. but what is repetition time ? In document it is mentioned the standard transmission time for every frame when no signal is changed. What is the need to send a frame when nothing is changed?

  • 1
    \$\begingroup\$ Again, this is pretty senseless to discuss without a specific higher layer application protocol in mind. Which one are you talking about? J1939? CANopen? Some custom one? \$\endgroup\$
    – Lundin
    Jun 10 at 9:59
  • \$\begingroup\$ Taking into account j1939 \$\endgroup\$
    – priya91
    Jun 11 at 5:08

Generally there are two very different flavours of CAN networks.

  • Large networks with lots of nodes/sensors, such as industrial/factory automation applications.
  • Control system networks where something is responding fast and in real-time, such as cars, machines, general actuators. These are often mission-critical.

In the "large industrial network" version it becomes important to control bus load. If you have 100 different sensors reporting in to some data collector, they can't just chatter away or you'll get 100% bus load with timing destroyed. You will get starvation phenomenon where lower priority messages never gets access to the bus - eventually leading to nodes going error passive/bus off.

To avoid high bus load, nodes could be configured to only send data when it is changing. When you use such a setting, it can be combined with an inhibit time, to make sure that a node where data is changing a lot still keeps calm and only sends data with a minimum time interval.

Other mechanics such as a master sending out a "SYNC" message can be used. Then each node is configured to respond from the point where it gets "SYNC" until a certain amount of time has passed. With this method you could configure individual offsets per node, so that they all respond at different points in time, regardless of their internal clocks.

CANopen supports a lot of features like these. Many device profiles like CiA 401 for generic I/O are set by default to keep their data output low and only send when there's new data available.

In the "control system network" version however, you always send all data cyclically over and over, regardless if there were any changes. This means that in case of data corruption or lost communication, such errors will only last until the next data cycle. Only sending a message upon change becomes very dangerous in case a node misses to catch that one message for whatever reason.

Typically these cycles are set to once per 1ms, 10ms or 100ms. And it also becomes possible to calculate "hard" real-time response of everything on the bus. Every node will be designed with a time-out and revert to a safe mode in case new messages stop coming.

These kind of systems have a higher bus load overall, but are deterministic, with careful timing considerations made by the one who designed the bus.

"SYNC" messages can be used here too, but rather for the purpose of acting like a crude system clock. Suppose for example that you control two proportional actuators at once, but from different nodes, and they need to move in unison. You can achieve this with "SYNC" and the accuracy is quite high: basically the MCU clock accuracy plus a bit of propagation delay, both likely negligible (assuming external quartz oscillator).

  • \$\begingroup\$ Thank you for the response. One more question, In control system network example, consider that the user pressed a button(switch) input/touch on screen and this information need to go from a ECU to a corresponding Application ECU without getting lost because one time button is pressed a frame is send with button ON status but again after cyclic time the frame will be overwrite with 0xFF. How do you approach the frame timing here ? Is trigger approach take or frame is send cyclically. How do you ensure that button Status reaches the application ECU on press. \$\endgroup\$
    – priya91
    Jun 11 at 11:14
  • \$\begingroup\$ @priya91 "but again after cyclic time the frame will be overwrite with 0xFF" I don't understand what you mean by that. In such a system, the status of the on/off is always sent. It will be 1 or 0 depending on the status of the actual button. Humans are very slow, so if you sample & send the button once per 10ms or so, that's much faster than a human can notice or react. So if they press it for 1 second, there will be 100 messages transmitted where the button is flagged as active. \$\endgroup\$
    – Lundin
    Jun 11 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.