Embedded Software Architecture

General catalog link ==>> AutoSAR entry and actual combat series general catalog

General catalog link ==>> AutoSAR BSW high-level configuration series general catalog

Embedded software architectural design intent is often accompanied by assumptions based on personal experience. A software developer might view architectural design from the perspective of a resource-constrained microcontroller-based system. A system person might think of the architecture in terms of an application processor. How to design the architecture will depend on the embedded software classification of the system.

We can classify embedded software in many different ways. I've found that there are five simple classifications of embedded software that help me adjust my perspective to best understand the system at hand.

Let's explore 5 simple categories of embedded software you need to know to successfully communicate and design your system.

1 Embedded Software Classification – BAREMETAL

Bare-metal embedded systems utilize a software architecture that does not depend on an operating system. Typically, bare-metal architectures will be event-driven, rely heavily on state machines, and/or use very simple cooperative task scheduling. Developers need to be very aware of the underlying processor, since no operating system can abstract away low-level details.

You'll typically find bare-metal software designs on resource-constrained devices such as 8-bit, 16-bit, and some 32-bit microcontrollers. However, resource availability is not a limiting condition for bare metal systems. You can design a bare metal architecture and implement it for any embedded processor. Unfortunately, the more complex the processor, the more complex the implementation.

Bare metal architectures and implementations are recommended for products with limited functionality, limited use of resource-constrained microcontrollers, strict real-time requirements, and minimal requirements for scalability.

2 Embedded software classification – real-time operating system (RTOS)

Embedded software architectures using real-time operating systems have increased dramatically over the past few years. RTOS-based embedded systems typically have more complex timing requirements than bare-metal architectures. An RTOS abstracts away low-level details such as task scheduling, while also providing developers with tools for task synchronization (semaphores and flags), data protection (mutexes), and communication (queues).

You'll typically find RTOS software designs on 32-bit microcontrollers and small application processors. While you may find them on 16-bit processors, RTOSs typically require at least 24 KB of flash memory and 32 KB of RAM to use effectively. These requirements place a lower limit on the effective use of an RTOS.

RTOSs add additional complexity to the design, mainly when using preemptive task scheduling. If the designer is not careful, it is possible to cause thread starvation, create priority inversions and even deadlocks. However, an RTOS can give you the ability to scale your system quickly, improve maintainability, and collect more complex system performance than a bare-metal system.

RTOS-based architectures and implementations are recommended for products with complex timing requirements, using modern microcontrollers, benefitting from multitasking, and needing to extend or reuse parts of the application.

3 Embedded Software Taxonomy – “General Purpose” Operating Systems

When using sufficiently complex processors, such as application processors, embedded software architectures can utilize entire operating systems. For example, Embedded Linux can be considered a complete operating system. I wouldn't put an RTOS in this category because an RTOS is a specialized, resource-constrained operating system, unlike embedded Linux. Designers have full access to libraries and operating system resources as they would when developing desktop or mobile applications.

You'll typically find this operating system software design on 32-bit application processors like the Raspberry Pi. However, these processors are very complex and require an operating system to manage all their resources. Now, that doesn't mean you can't use bare metal or use an RTOS; it just means that the complexity and development time increase dramatically.

A full operating system removes the burden of memory constraints from the developer. Also, you can often involve non-embedded software people. For applications built on top of an operating system, software development involves far less specialized knowledge.

Full OS architectures and implementations are recommended for products that do not have strict real-time requirements, use modern microprocessors, benefit from high-level abstractions, and need to extend or reuse parts of the application.

4 Embedded Software Taxonomy – Containers/Microservices

Microservices and containers are common design types in cloud, mobile, and desktop computing. However, they are quickly finding their way into embedded systems. I conflate the two because they use similar architectural design strategies, although the underlying technology is different.

microservice

Microservices structure an application as a set of loosely coupled services that are independently deployable and easy to maintain (if done well). Microservices structure an application as a collection of small autonomous services developed for a business domain. Microservices provide loosely coupled services with specific functionality.

Embedded systems with relatively constrained resources, such as microcontrollers, can run microservices. However, they typically require at least the same amount of memory as is required to run the RTOS. Microservices include the service itself, inbound and outbound message queues, and logging and status information.

Requiring an orchestrator and a runtime environment adds to the complexity of microservices design, and you must be careful about the resources you use and carefully monitor the system's real-time response. However, microservices can provide very scalable systems that are easy to maintain and update in the field.

I recommend using microservices in applications that require in-field updates, scalability, and modern agile processes and benefit from a distributed model.

container

Containers are an implementation paradigm that can host microservices. Each container is an independent sandbox that can run one or more microservices. Containers are usually self-contained and easy to maintain. A range of containers provides the basis for a wider range of applications. Likewise, containers and microservices are closely related; containers provide an additional layer of isolation for microservices to run.

At least one modern microcontroller is required to utilize containers. Every technology vendor is slightly different, but some claim to be able to use as little memory as an RTOS. However, most of the targeted IoT applications I surveyed expected around 256 KB of flash memory.

Containers are a modern architectural implementation that can add flexibility, scalability, and portability to embedded applications. They have been used successfully in other areas of software over the years. By far the biggest limitation is size and performance.

I recommend containers for applications that require in-field updates, scalability, extra security, and modern agile processes.

Figure 1 – Container Architecture Heap

5 Embedded Software Classification – Hybrid Systems

Hybrid systems utilize multiple classifications simultaneously. For example, you might have an application processor that uses embedded Linux. However, the processor may have a built-in microcontroller that uses a bare-metal approach to manage real-time response.

Hybrid systems allow developers to take advantage of multiple design approaches to benefit from multiple system types. This flexibility often increases the complexity of a system if the interactions between the various parts of its design are not carefully managed.

Hybrid architectures and implementations are recommended for products with complex processing and real-time requirements, which use multi-core processors, benefit from high-level abstractions and require scaling or reusing application parts.

6 Conclusion

Embedded software systems can be divided into several types. How embedded software is designed and built will depend on which classification you choose. Each classification will dictate the design patterns and tools you use to build and implement your system. When designing or discussing systems, specify the type of system before proceeding with the design.