Checklist for embedded communication

Embedded systems – being embedded – talk to their environment quite intensively. And nowadays, as system complexity has increased, the environment doesn’t only consist of simple sensors and actuators which one could talk to via ADCs, DACs, PWMs or GPIOs; but of more complex peripherals to which the embedded systems talks via some protocols such as CAN, I2C/SMBus, SPI, EIA-232/422/485 and so on.[1]I can recommend John Catsoulis’ book Designing Embedded Systems for a walkthrough of these interfaces.

These protocols provide the design for the physical layer and some data link control layer. So, one has to implement his own design for the remaining layers if they are needed by the specific requirements. In my experience, development teams tend to underestimate the requirements on the protocols[2]“It’s just two microcontrollers talking.”, so high costs and delays occur when protocol designs – which are architectural – are being amended in later phases of projects.

For this reason, I think it would be helpful to have a checklist for embedded communication that one can compare his design against. So, here is the checklist organized by layers of the OSI model, feel free to add your questions in the comments:

  1. Data link layer
    1. How do you guard against data corruption, loss, duplication?
    2. How is access to media controlled to avoid or recover from collisions?
    3. In a master/slave architecture, how does a slave notify the master if necessary?
  2. Network layer
    1. Can there be multiple senders/receivers? How do you distinguish among them?
    2. Do you need multicast/broadcast messaging?
    3. Can a packet travel multi-hop? How do you handle routing?[3]Just use an existing protocol! This is heavy stuff.
  3. Transport layer
    1. Is the transport stream- or packet-oriented?
    2. How do you identify packets belonging to the same transaction (request-response or more complex)? How do you distinguish between simultaneous packets belonging to different transactions?
    3. Can a message be fragmented into multiple packets? How does the receiver combine them again?
    4. How do you ensure delivery of messages?
    5. How do you detect repeated packets to eliminate them?
  4. Session layer
    1. Do you need to maintain sessions comprising multiple transactions?
    2. How is a session built, how is it closed properly?[4]Strictly speaking, we also have this for connection-oriented protocols at the transport layer.
    3. How do partners detect that their counterpart is not in the session anymore?
    4. How do you distinguish different sessions in multiple simultaneous packets?
  5. Presentation layer
    1. How is the payload structured/serialized in the message?[5]First and unfortunately sometimes the last question of protocol design in embedded systems.
  6. Cross-cutting aspects
    1. If partners go out-of-sync, how do they re-sync again? Can master just reset a slave?
    2. Do you need security, in which layers?[6]Even though I use HTTPS to access my email, I also secure my data link layer in my Wi-Fi.
    3. Do you have time-critical messages? How do you handle prioritization?
    4. Are there challenging performance/resource-efficiency requirements? How do you handle them? Which other mechanisms discussed in this list could have an impact on them, e.g. packet repeat strategy?
    5. If the communication partners can evolve independently, how do you handle different versions? Which part has to be forward/backward-compatible?

Please keep in mind that using an existing protocol will save you from all this effort and risk. Higher-level protocols which we commonly find for Ethernet, USB and IEEE 802.15.x-based protocols may also exists for the simpler protocols such as DeviceNet and CANopen for CAN. “Buying” instead of making will give you a protocol that has been tested thoroughly, off-the-shelf implementations and tools. You can still use this checklist list for evaluating candidate protocols when “buying”.

I’d like to keep this checklist comprehensive and actual also in the future, so I will maintain it in a bliki fashion. Please comment on potential improvement points.

Footnotes

Footnotes
1 I can recommend John Catsoulis’ book Designing Embedded Systems for a walkthrough of these interfaces.
2 “It’s just two microcontrollers talking.”
3 Just use an existing protocol! This is heavy stuff.
4 Strictly speaking, we also have this for connection-oriented protocols at the transport layer.
5 First and unfortunately sometimes the last question of protocol design in embedded systems.
6 Even though I use HTTPS to access my email, I also secure my data link layer in my Wi-Fi.

Leave a Reply

Your email address will not be published. Required fields are marked *

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.