By applying concepts from modern software development, embedded development can be faster and easier.
Despite the increased use of embedded devices, development techniques remain in the past. Still today, there are strong dependencies between software and hardware that typically use a monolithic design. This means starting from scratch every time and a complete lack of agility.
Hardware devices need to have more ubiquitous connectivity and code should be able to be reused — in a microservices approach. This means borrowing concepts from modern software development and applying those to the embedded world – in robotics, home automation, aviation, space, and many other domains – that would make development faster and easier.
The article will make a case for adopting modern software development and applying that to edge and embedded development – based on an open-source approach – and show how that is possible, along with how people can get started today. We will look at the advantages and potential obstacles to the use of microservices in an embedded project, as well as the variables to consider regarding throughput, latency, and security.
Starting to think microservices instead of monolith: an odyssey for embedded developers
It has been customary to think of a project as a whole set of interdependent, complex boards, drivers, and applications.
In my early days as a roboticist, I had to redo everything from scratch multiple times for every project I did. We were developing code for weeks, then someone changed a little thing somewhere, and we had to recode everything from the beginning.
In these times of increased focus on agility and cost control, it seemed unbelievable to me to continue to develop code that could not be reused as soon as you change a variable in the project. It became inconceivable to develop a project that would not be easily adaptable in time according to external variations (such as a semiconductors shortage, for example). Such a waste of time and energy could not continue like this.
So it was important for me to see if this lack of agility was the same in other areas outside of embedded development. Hardware is often compared to software, and for this case, it served as an example for me.
How, in nine years, has Docker democratized the development of portable software applications in containers? In small pieces of code that together build a system? Independent services that can be reused at will?
The microservices philosophy seemed obvious
In software development, partly thanks to the advent of microservices, many ideas could be launched quickly. When you have an idea for an application, software, or a web application, you don’t even think about what hardware is running behind it. It is transparent, fluid, and adaptable over time. But unfortunately, we don’t have this versatility in embedded systems, because they require a lot of heavy abstraction.
Microservices made their appearance during the year 2000. The topic has been talked about since 2014, according to Google Trends. Among the pioneers, Netflix has worked to popularize these architectures.
The idea was to divide this big cake into several small cakes, each being a service. A service is a self-contained unit that performs a specific task and communicates with other services to perform its mission.
Microservices have appeared in the hardware field with the rise of the Internet of Things. But for the moment, these are the only devices using microservices, probably because they have access to the internet. The internal networks of our devices, robots and systems are still very much anchored in the past.
The challenges of embedded development
The main challenge of embedded development is to defeat the strong coupling between software and hardware. In the software world, we have APIs that allow us to develop our code without dealing with the underlying hardware. We can change our application’s database without having to change the code that uses it. In the world of hardware, it is often necessary to have a very good knowledge of the boards used, their registers or the protocols used to be able to exchange information with the firmware that will make our system work.
This makes it difficult to reuse code from one project to another and to adapt quickly to changes. It is also often necessary to have a good knowledge of the tools used for development, which are often specific to a microcontroller or a family of microcontrollers.
All these factors make it difficult to find developers with the necessary skills and make development slower and more expensive.
The advantages of microservices for embedded development
The main advantage of microservices is that it allows developers to decouple the different pieces of software allowing a clean separation between applications and drivers. This makes it possible to reuse the same application code for different hardware platforms and to change hardware platforms without having to change the code except the concerned driver.
Microservices also have the advantage of being easier to test and deploy a specific configuration based on a collection of services revisions.
You can use open-source microservices orchestrators such as Luos to easily synchronize all the services across all your board or remote processes on a computer or the cloud.
The potential obstacles of microservices for embedded development
Microservices rely on communication between services. A good microservice architecture makes communication between services easy and fluid. The microservice architecture will take control of the network between your boards.
In any case, you have to exchange information so the microservice architecture will not have any impact on the network latency. But because it makes it easy and transparent, it’s easy to overuse it – implying more network data bandwidth is needed.
For multiple services running on the same microcontroller, this adds some operations that could impact your code performance. Agility has a cost, even the smallest RTOS have. For example, if a service needs to get data from a sensor, it has to send a request, wait for the sensor to respond, and then process the data.
Security can be an obstacle because the more services there are, the more potential attack there are. Also, microservices make pieces of code work together natively, malicious ones also. It is, therefore, important to carefully consider the security implications of using microservices.
For some applications, such as those that require real-time responses, throughput and latency are more important than security. Security is more important than throughput and latency for other applications, such as those that handle sensitive data.
Choose an orchestrator that organizes and simplifies exchanges
In the embedded domain there are a lot of existing operating systems like FreeRTOS, NuttX, or Zephyr, but not so many tools orchestrating your multiple boards in a coherent way. That is why I developed Luos as open source software.
The advantage of these tools is not only to open the doors of this philosophy but to provide useful tools to monitor, debug or update the system by accessing all the services’ information easily.
The case of the update is interesting. By using this kind of tool you will be able to remotely update all your boards remotely instead of requiring to physically disassemble the device finally update the specific board and reassemble it (preferably correctly and without mistakes). This avoids you having to create your own solution to maintain your product and track events after sale.
The use of microservices orchestrators makes this practical case much more agile. A hardware-agnostic bootloader would allow updating any board from any physical connection—no need to disassemble everything. We can connect to our STM32 to update our STM32.
We often use the example of Tesla, and maybe you have the video in mind. Without asking these customers to come to the garage, Tesla can remotely update their cars, facing security problems and particular conditions (Tesla’s example with the Irma storm), or propose the latest developed features.
We need to gain this agility in our embedded and edge projects
We are developing ever more modern and sophisticated systems, but we still prefer the old, perhaps painful but stable methods that constrain us in many ways. This is a long-term vision.
We have opened a community of embedded and edge developers who exchange and help each other on this kind of issue. If you are interested in your watch or want to discuss it, go on Discord.
|Nicolas Rabault is co-founder and CEO of Luos and has experience in robotics and as a research engineer in real-time embedded systems.|
For more Embedded, subscribe to Embedded’s weekly email newsletter.