Author | Chuguang

Produced by | Vehicle Terminal

Note | We are a technical sharing platform for intelligent automotive software and architecture. We insist on originality every day, growing together with you.

Knowledge Circle | Join the “Automotive Electronics and AutoSAR Development” group by adding WeChat “cloud2sunshine”

The design intent of embedded software architecture is often accompanied by assumptions based on personal experience. Software developers may view architectural design from the perspective of resource-constrained microcontroller-based systems. System personnel may consider architecture from the perspective of application processors. How to design architecture will depend on the classification of the system’s embedded software.

We can classify embedded software in various ways. I found five simple classifications of embedded software that can help me adjust my perspective to best understand the system at hand.

Let’s explore the 5 simple classifications of embedded software that you need to understand to successfully communicate and design your system.

01.Embedded Software Classification – BAREMETAL

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

You will 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.

For products with limited functionality, using resource-constrained microcontrollers, strict real-time requirements, and minimal scalability requirements, it is recommended to use bare-metal architecture and implementation.

02.Embedded Software Classification – Real-Time Operating System (RTOS)

The use of embedded software architecture based on real-time operating systems has dramatically increased in recent years. RTOS-based embedded systems typically have more complex timing requirements than bare-metal architecture. RTOS abstracts some low-level details such as task scheduling while providing developers with tools for task synchronization (semaphores and flags), data protection (mutexes), and communication (queues).

You will typically find RTOS software designs on 32-bit microcontrollers and small application processors. While you may find them on 16-bit processors, RTOS typically requires at least 24 KB of flash memory and 32 KB of RAM to be effectively used. These requirements set a lower limit on the effective use of RTOS.

RTOS adds additional complexity to the design, primarily when using preemptive task scheduling. If designers are not careful, it can lead to thread starvation, priority inversion, or even deadlocks. However, RTOS can provide you with the ability to quickly scale systems, improve maintainability, and gather more complex system performance than bare-metal systems.

For products with complex timing requirements, using modern microcontrollers, benefiting from multitasking, and requiring scalability or reuse of application portions, it is recommended to use RTOS-based architecture and implementation.

03.Embedded Software Classification – “General” Operating System

When using sufficiently complex processors (such as application processors), embedded software architecture can leverage an entire operating system. For example, embedded Linux can be considered a complete operating system. I do not categorize RTOS in this category because RTOS is a dedicated, resource-constrained operating system, unlike embedded Linux. Designers can fully access libraries and operating system resources as they would when developing desktop or mobile applications.

You will 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, this does not mean you cannot use bare-metal or RTOS; it just means that complexity and development time increase dramatically.

A complete operating system can relieve developers of memory constraint burdens. Additionally, you can often involve non-embedded software personnel. For applications built on operating systems, the specialized knowledge involved in software development is much less.

For products without strict real-time requirements, using modern microprocessors, benefiting from high-level abstractions, and requiring scalability or reuse of application portions, it is recommended to use complete operating system architecture and implementation.

04.Embedded Software Classification – 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 technologies differ.

Microservices

Microservices build applications as a collection of loosely coupled services that can be deployed independently and are easy to maintain (if done well). Microservices build applications as a collection of small autonomous services developed for specific business domains. Microservices provide loosely coupled services with specific functionalities.

Resource-constrained embedded systems (such as microcontrollers) can run microservices. However, they typically require at least the same amount of memory as required for running RTOS. Microservices include the services themselves, inbound and outbound message queues, and logging and state information.

The need for orchestrators and runtime environments increases the complexity of microservices design, requiring careful use of the resources you use and close monitoring of 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 field updates, scalability, modern agile processes, and benefit from distributed models.

Containers

Containers are an implementation paradigm that can host microservices. Each container is an independent sandbox capable of running one or more microservices. Containers are typically deployable independently and are easy to maintain. A series of containers lays the foundation for broader applications. Similarly, containers and microservices are closely related; containers provide an additional layer of isolation for running microservices.

A modern microcontroller is needed to leverage containers. Each technology vendor differs slightly, but some claim to be able to use as little memory as RTOS. However, most target IoT applications I have investigated expect 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 successfully used in other areas of software for years. The biggest limitations so far are size and performance.

I recommend using containers in applications that require field updates, scalability, additional security, and modern agile processes.

05.Embedded Software Classification – Hybrid Systems

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

Hybrid systems allow developers to benefit from various design methods across multiple system types. However, this flexibility often increases system complexity if the interactions between the various parts of its design are not carefully managed.

For products with complex processing and real-time requirements, it is recommended to use hybrid architecture and implementation that utilize multi-core processors, benefit from high-level abstractions, and require scalability or reuse of application parts.

06.Conclusion

Embedded software systems can be categorized into various types. How you design and build embedded software will depend on the classification you choose. Each classification will dictate the design patterns and tools you use to build and implement the system. When designing or discussing a system, please specify the type of system first before proceeding with the design.