Applying a micro-service approach to embedded systems
Photo by Umberto on Unsplash

Applying a micro-service approach to embedded systems

Over the past few years I've been designing architectures for embedded systems and I've been able to make use of a micro-service approach. By embedded systems here I'm thinking about maybe an ARM or x86 board running an OS rather than bare metal.

There are some real advantages in using a micro-service rather than a monolithic design for some situations. What I mean by micro-service in this context is using multiple processes, each performing a simple task with the processes communicating typically via a publish and subscribe scheme.

So a hypothetical embedded system might have;

  • modules for handling sensor inputs / actuators
  • a module to manage the UI
  • a logger
  • a module for external communications

Rather than developing these modules as a monolithic application, an alternative is to create separate processes with simple, well-defined interprocess communications.

The advantages are;

  • language / technology independence - each service is developed using whatever language is most appropriate. Services simply need to communicate via a common protocol - eg. Google protocol buffers over MQTT.
  • robustness - failure of a single, non-critical service won't crash the whole system.
  • testability - it's easy to test services in isolation. With a suitable test harness, extensive automated tests can be implemented.
  • debugging - inter-process communication can easily be logged when troubleshooting and played back to replicate exactly the conditions that caused a fault. It's also possible to run a service under debug on a development PC and have it interact with the rest of the system.

There are downsides of course;

  • # latency - network communications is always going to be worse than a direct function call.
  • # static analysis can be harder
  • # in a pub/sub system like MQTT, the broker is a single point of failure, although I have used brokerless peer-to-peer systems where this isn't a problem.

This approach clearly isn't applicable in all cases but it's worked well for me on a couple of projects.


Good point. I like it. In some projects, I made the decision to use some ARM core boards powered by Linux rather than a microcontroller design approach. Using OS provide reasonable utility for debugging, logging and developing the whole system. As you mentioned we can not use these boards in all projects. I have got a good experience in developing software/firmware with C/C++ and python. Despite the performance, Python provides very nice libraries which help to implement the software easily. I tried to implement tasks by micro-service approach.

Like
Reply

To view or add a comment, sign in

More articles by Allan Jones

Others also viewed

Explore content categories