How to meet the requirements of the middleware in a centralized E/E architecture?
The massive introduction of software into the vehicle is reflected in many aspects of vehicle development: in the E/E architecture, corporate culture, development processes, and software architecture. Most future innovations in automobiles will be based on software or are implemented in software. This trend accompanies the centralization of electronic control units (ECUs) and, at the same time, enables vehicle manufacturers to take over the development and responsibility for vehicle functions and algorithms.
The layered architecture of a central computer consists of four layers: the processor, the operating system, the middleware, and the application software that implements the vehicle functions. The operating system and the middleware fulfill various tasks: the hardware abstraction between processor and application software, provision of system functions such as intra- and inter-ECU communication, and the framework or runtime environment on which the application software is executed. The processor of a central computer is usually a System on Chip (SoC), integrating multiple central processing units and specialized processing units, such as graphics processing units. In this abstract, we discuss whether the current middleware approaches meet the requirements of current and future central computers. Today's middleware, typically used on central computers, is based on the AUTOSAR standard [1] and its implementations of AUTOSAR Classic and AUTOSAR Adaptive.
In an automotive environment, the middleware plays a crucial role in facilitating communication and interaction between various components and systems within a vehicle. We focus here on the central computers. The hardware used is typically a System on Chip (SoC), which is a complete and self-contained electronic system that integrates multiple central processing units (CPUs) and specialized processing units, such as microcontrollers (MCUs), graphics processing units (GPUs), or even custom accelerators designed for specific tasks, onto a single integrated circuit or chip. The purpose of moving towards SoCs is to create a compact and highly integrated solution that can perform a wide range of tasks or functions, typically within a specific application or domain. Some SoC vendors also provide a complete software stack for their chips, typically specialized for use cases like AD/ADAS. Some of the stacks already contain a safety concept and are prequalified accordingly. We are seeing a trend towards customized SoCs based on chiplets. A chiplet is a concept in the semiconductor industry where multiple smaller integrated circuits (chips) are combined on a substrate or carrier to create a larger and more complex system. The chiplet concept aims to improve scalability, performance, and efficiency. In our context, this means that the number of hardware variants will continue to increase and that the middleware must support the transition and abstraction of new SoCs.
Various middleware implementations are used today to support the various processing units on an SoC. AUTOSAR Classic is mainly used on MCUs today. The CPU typically uses AUTOSAR Adaptive; on GPUs, there are manufacturer-specific interfaces and cross-manufacturer solutions. AUTOSAR has developed two standards: AUTOSAR Classic, which addresses classic ECUs and MCUs with hard real-time capability and small, static memory. AUTOSAR Adaptive, on the other hand, supports CPUs with dynamic memory management and high performance. Both standards offer different application frameworks: AUTOSAR Classic specifies the RTE (RunTime Environment) on which the corresponding software components (SW-Cs) run. With ara::com, AUTOSAR Adaptive has introduced a service-oriented interface that is incompatible with the RTE, however. Parallel computing on GPUs is decoupled from CPUs and MCUs. Several parallel computing APIs (Application Programming Interfaces) have been developed to enable efficient parallel programming of GPUs and other parallel hardware architectures. These APIs provide tools and libraries for developers to write parallel and concurrent code. Some of the most prominent ones are SYCL — a C++ abstraction layer for OpenCL that enables developers to write single-source code that can target both CPUs and GPUs, CUDA — a parallel computing platform and API developed by NVIDIA, and OpenCL — a framework for writing programs that execute across heterogeneous platforms.
A middleware for current and future central computers needs to fulfill functional and non-functional requirements. Functional requirements for automotive middleware define specific tasks and functions that the middleware must perform to enable communication and interaction between various components and systems within a vehicle. These requirements can vary depending on the specific needs of an automotive project. Some examples are communication management, software updates over the air, time synchronization, or diagnostics.
Non-functional requirements, often called "quality attributes" or "system qualities," are aspects of a software system or application that describe how it should perform rather than what it should do. These requirements focus on the characteristics and properties that determine the system's overall quality, usability, and performance. Unlike functional requirements, which specify specific features and functionalities, non-functional requirements emphasize the overall behavior and attributes of the system. Functional requirements are clearly defined in the specifications and must be met by every middleware. Therefore, we focus on the specific non-functional requirements or, better, the system qualities:
Maintainability focuses on the ease with which a software system can be updated, modified, extended, or repaired over its entire lifecycle.
Performance requirements define how well the system should perform under certain conditions. This includes aspects such as response time, throughput, and resource utilization.
Portability requirements refer to the ability of a software system to run on different hardware platforms or operating environments without significant modifications. This includes ensuring the software can be easily adapted and deployed across various target systems.
Scalability requirements describe how the system should handle increasing loads and user traffic. They may specify how resources should be added or removed dynamically.
Usability requirements focus on the user experience and interface design. They include aspects like user interface responsiveness, accessibility, and user guidance.
At first glance, these aspects seem less important than the functional requirements. They are also harder to quantify, but they contribute significantly to developing application software efficiently, effectively, and in a future-proof manner. How must middleware be designed to meet these non-functional requirements? When looking at today's approaches, we first notice that the different processing units use different solutions: MCUs rely on AUTOSAR Classic, CPUs use AUTOSAR Adaptive, and GPUs and other hardware accelerators use frameworks for parallel computing. They all use different APIs and different data models. Some hardware accelerator frameworks are even SoC vendor-specific, making porting software to other hardware more difficult. This model does not consider the requirements from the application developer's perspective. The application software in the software-defined vehicle is no longer developed for a specific production start-up. The goal is instead to set up continuous software development from which different vehicle models and vehicle versions can be served. Other vehicle models and versions mean the underlying E/E architectures, processors, and communication protocols can and will change. This is precisely the task of middleware – to decouple the application software from the operating system and hardware. It must enable the integrator to migrate the application software quickly and effectively to a new hardware platform. The integrator needs to optimize the overall system performance. This means repartitioning the application software, i.e., redistributing the applications to the different MCU, CPU, and GPU cores.
Our approach is to unify the interfaces and data models across the various processors and to enable transparent communication and interaction between these cores. Apex.AI’s middleware is based on ROS, an emerging framework for Robot Operating System and is an open-source framework used for developing and controlling robotic and autonomous mobility systems. Despite its name, ROS is not a traditional operating system like Windows or Linux; it is a middleware that runs on top of an existing operating system and provides tools and libraries. ROS was developed to address the complex challenges of creating and programming robots. It provides a structured way for various robot system components to communicate and collaborate, making it easier to design, prototype, and deploy robotic applications. ROS offers a modular and distributed architecture that promotes code reusability, scalability, and collaboration among developers. ROS is widely used in advanced development of AD/ADAS stacks. Solutions like Apex.OS provides automotive-grade, production-ready versions of ROS. With our solution, we offer a middleware that runs on the different cores contained on an SoC, i.e. on MCUs and on CPUs. The API is C++ based and identical on both core types. The data model and communication between different cores are also unified and based on shared memory and zero-copy data transport. In other words, a ROS node on an MCU core is the same as on a CPU core. With this approach, it is straightforward to relocate an application from an MCU core to a CPU core. It is even possible to run Apex.OS in parallel with AUTOSAR Classic and AUTOSAR Adaptive to ease the transition of legacy applications. Because Apex.OS is operating system agnostic it supports a variety of operating systems. Apex.AI’s support of MCUs was first announced at the Embedded World 2023 event [2].
SoCs are not just made up of MCUs and CPUs. Full support of the SOC must also take the hardware accelerators into account. Since a ROS-based API is not useful for hardware accelerators, we recommend established approaches such as SYCL or OpenCL. We aim to provide ROS nodes and communication mechanisms for GPUs and other hardware accelerators. This enables the best possible integration of parallel computing with the application software running on MCUs and GPUs.
Finally, let's evaluate the presented approach against the previously described non-functional requirements:
Usability is essential for the application developer to develop applications efficiently. Apex.OS is based on ROS, a development framework used by over 700 companies and tens of thousands of users. A variety of open-source and closed-source tools enable efficient and effective development. Apex.AI provides a production-ready and automotive-enabled implementation and offers professional support to its users.
Portability and maintainability are the core focus of our approach. Apex.OS is hardware and OS agnostic; it completely abstracts the underlying E/E architecture from the application software. It massively eases porting of the application software to new hardware like new SoCs based on chiplets. The maintainability of the application software is achieved through a stable and unified API.
Performance and scalability are achieved through state-of-the-art implementations such as the use of shared memory and zero-copy data transport procedures—the architecture of Apex.OS is designed for high loads and the provision of available hardware resources. All processors available on the SoC are supported and delivered through a unified development model. The system load can be balanced by relocating the applications. This approach meets the essential requirements for future middleware as it supports today's and tomorrow's needs of the software-defined vehicle.
Key takeaways
The software-defined vehicle (SDV) is undergoing a permanent change with respect to computing hardware, the transition to System on Chips (SoCs) and major changes in the E/E architecture.
At the same time, application and function development shall continuously support different models and generations of SDVs.
With the introduced middleware approach, Apex.AI is supporting the diversity of processing units of SoCs and at the same time, offering a unified framework for efficient application development.
If you are interested in Apex.AI products for your projects, contact us.
[2] Infineon and Apex.AI are integrating AURIX™ TC3x microcontroller and Apex.Grace to expedite software-defined vehicle development