In the current electronics driven world, embedded systems integrate advanced computing capabilities into devices for specialized functions, such as in automotive control systems, medical devices, and IoT gadgets. They often require real-time processing, low power consumption, and robust performance in diverse environments. Most of them need continuous improvement to the system to meet customer expectations and that calls for an upgrade and regress testing to the product. To achieve this smoothly without impacting other modules in the system, it is possible to leverage the Microservices architecture instead of the usual monolithic application architecture. Initially Microservices was introduced in cloud-based products to scale up and down the resources based on the user’s demand. Now it is possible to leverage the same for many embedded systems as well by having loosely coupled components and rolling out new features easily without impacting old features. In this article, we will look into microservices architecture, difference from legacy monolithic architecture along with an example.
Monolithic architecture in embedded systems
In conventional embedded product architecture, components/modules are closely interconnected where all functionalities and components are tightly linked, typically in a single process space. This approach has been benefited for its simplicity and efficiency, particularly in less complex applications.
Monolithic Architecture in embedded systems
In this architecture, all components of the system—for example, user interfaces, business logic, and data management—are combined into one single application. This design is straightforward to develop and deploy, making it an attractive choice for smaller embedded systems. For example, household appliances like microwave ovens or washing machines often use monolithic architectures. The software controlling the appliance's operations, such as timers, power levels, and modes, is developed as a single, integrated unit. This ensures reliability and minimal overhead, which is crucial for devices with limited processing power and memory.
But those devices lack modularity, making it difficult to isolate and fix issues without impacting the entire system. Scaling becomes a challenge, and updates or modifications can be time-consuming and risky. Any change in the system requires a full redeployment, increasing downtime and potential for errors. To address these limitations, it is possible to adopt Microservices Architecture for embedded systems.
Microservices Architecture for embedded systems
Microservices refers to a software architectural style where the application is composed of small, independent services that communicate over well-defined APIs. These services are developed, deployed, and scaled independently, allowing for greater modularity and flexibility compared to monolithic architectures. A typical microservices architecture is depicted below.
Microservices Architecture for embedded systems
As can be seen, the functional components are independent of each other and run in separate process spaces. They communicate among themselves using IPCs mechanism and since there is no build time linkage each of them can be developed by different teams and deployed together. Any one component can be updated without affecting the others after due validation.
Microservices modules communicate with each other via lightweight protocols (such as HTTP, MQTT, or other IPC mechanisms) and can use RESTful APIs, message queues, or other communication protocols.
Advantages of Microservices Architecture
For embedded systems, especially those within the Internet of Things (IoT) and automotive industries, microservices offer several advantages.
| Advantage | Description |
|---|---|
| Modularity | Each process is a discrete component that performs a specific function, making it easier to develop, test, and maintain. |
| Scalability | Individual services can be scaled independently based on demand, which can be particularly useful in resource-constrained embedded environments. |
| Resilience | The failure of one microservice does not necessarily bring down the entire system, enhancing overall reliability. |
| OTA Update | Each microservice can be deployed independently, allowing for more flexible updates and rollbacks. |
| Technology Diversity | Different microservices can be written in different programming languages or use different technologies, as long as they adhere to the defined communication protocols. |
| Ease of development | Teams can work on different components simultaneously, speeding up development and deployment making continuous integration and continuous delivery (CI/CD) practices more manageable |
| Reusability | Software components developed for one product that is proven, if possible, can be easily deployed without any changes drastically reducing development/testing times. |
| Security | Having independent isolated modules increases security as each of the modules can be provided access only to the relevant resources preventing cross functional attacks. |
While the initial time to deploy and inter module communication overhead are more compared to monolithic architecture, the advantages offered by microservices architecture far outweighs these.
Microservices adoption in embedded systems
Though microservices adoption in embedded systems has its own challenges. It requires a robust communication mechanism between components, often over constrained resources. Efficient management of these distributed services/component is critical to ensure seamless operation.
As we are aware, there are 3 types of embedded designs followed.
- BareMetal firmware
- RTOS based firmware
- OS based firmware
BareMetal applications are simple and dedicated for one operation/use case and are usually deployed on very smaller computing systems and have a small set of functionalities. In this case it is not prudent to adopt the microservices architecture. The same principle is mostly applicable for RTOS based design.
OS based embedded system, such as those based on Linux, can have multiple processes, and OS offers inter process communications between processes. In this case, it is possible to have the functionalities of each component well defined and run them as processes independent to each other. Thus, it is possible to go for a microservices architecture in such designs.
Once the components are made independently, a mechanism is required to deploy them. Mechanisms such as containers and snaps can be used to package code as a deployable component enabling microservices adoption in embedded systems.
For a better understanding, here we will take an example of interconnected IoT system (Smart IP Camera) in Monolithic design and how microservice can be adapted to it.
Monolithic architecture of Smart IP Camera
A typical smart IP camera captures video, stores it in a hard disk, runs advanced algorithms on video frames for motion detection, face recognition etc., raises an event to consumer based on alarm outcome.
Monolithic Architecture of IP Camera
For these features, software application usually contains following components implemented as threads
- Video capture - This module takes care of capturing sensor data as video and picture
- Video storage Manager - This module stores the video in a filesystem and memory fill protection
- Configuration Manager - This module takes care of all product configuration such as quality, recording duration, algorithm selection etc.
- Algorithm controller - This module runs configured algorithm on the video frames
- Firmware update Manager - This component takes care of upgrading the product
- Cloud Manager - This component is responsible for communicating the events to cloud
- Event Manager - This component perform event communication via sms, call, email etc.
- Webserver - This component provides a user interface to the product.
In a monolithic architecture, the run time snapshot of the system is as follows:
All the application components might run as a separate thread and interact with each other via IPC mechanisms available in the operating system such as queues, shared memory etc. To upgrade or fix a bug in one component, we need to upgrade the complete system.
Microservices architecture for IP Camera
In this architecture, each component shall be built as a separate process and packaged in a lightweight container. Container is basically mini kernel with process as its only application. Control and data path for each container are well defined and can be communicated using raw socket communication protocols such as GRPC.
The same Smart IP camera will look like the diagram below in the microservices architecture.
Microservices Architecture of IP Camera
In this approach, each component can maintain version details and features shall be rolled out tagged to a version number. By knowing other component’s version information, the features can be invoked supporting backward compatibility. Further, each component can be easily upgraded without impacting any other component feature.
Conclusion
Adopting a microservices architecture for embedded systems offers significant benefits, including enhanced scalability, improved fault isolation, and accelerated development cycles. While it presents challenges, such as managing inter-component/service communication and resource constraints, the advantages are greater compared to monolithic architecture. Microservices provide the flexibility and robustness required for modern, complex embedded applications, making them a viable alternative to traditional monolithic approaches.