Introduction
Over the past several years, automotive electronic architectures have been moving towards centralized architectures that shift more functionality into powerful microprocessor-based ECUs, consolidating as much as possible and attempting to reduce the total number of ECUs. Reasons for this include reducing total system cost, overall power consumption, and weight, and the growing performance demands of modern software, particularly driver assistance and autonomous driving functionality.
However, total functionality consolidation is impossible due to fundamental differences between microcontrollers and microprocessors. Microprocessors are general-purpose processing units that can run at high frequencies at the cost of higher energy consumption and heat production. Microcontrollers are typically smaller, more specialized integrated circuits designed to perform specific tasks. Control systems that require low latency, fast response times, and boot times within hundreds of milliseconds often prefer microcontrollers. They are favored in low-cost developments, as they are typically a fraction of the cost of microprocessors. For these reasons, microcontrollers are here to stay.
Hard Real-Time
Despite the trend towards microprocessors, one of the main reasons microcontrollers are still necessary for automobiles is their hard real-time processing capabilities within microsecond accuracy. Vehicle ECUs requiring these real-time capabilities include engine control, braking, and airbag. These microcontroller-based ECUs react to data from multiple sensors and activate actuators with strict deadlines. On the other hand, microprocessors handle complex, processing-intensive tasks that require external memory and are less suited than microcontrollers to respond to inputs in hard real-time to ensure that the car operates safely and efficiently.
Safe
Another advantage of microcontrollers is their reliability. Because they are optimized to perform dedicated low-power tasks and have fewer dependencies on external peripherals, they are less prone to failure than microprocessors. In an automobile, where safety is paramount, reliability is critical. Microcontrollers are less susceptible to glitches due to their typically lower operating frequency, reduced system complexity and smaller instruction set, leading to higher safety through reliability. Several microcontrollers are available up to the highest automotive safety integrity level (ASIL D), whereas only a few microprocessors are available. Furthermore, certifying software on microprocessors to ASIL-D is much more complicated than on microcontrollers. These reasons show why microcontrollers control many critical systems, such as engine management systems, advanced driver-assistance systems (ADAS), and electric powertrain control systems.
Simplified Software Development Process
There are several essential advantages of using open-source and open-source-based software in the automotive ECU development process:
Collaboration & Community
Open-source software allows developers worldwide to collaborate on software development. This collaboration enables contributions from a wide range of people, companies, and industries, leading to more perspectives, better ideas, and ultimately better products. Only a small group of developers work together when a company writes closed-source software, which can limit innovation, hamper efforts to keep up with industry trends and slow down the development process. On the other hand, it is beneficial for achieving safety certification by limiting changes in the software. At Apex.AI, we actively use and contribute to open-source software and offer functional and safety-relevant improvements as closed-source software to provide our customers with safety-certified and functionally-improved versions of open-source software.
Developers benefit from a passionate community surrounding open-source software. The community reviews feature development, bug fixes, and other improvements, eventually leading to improved and higher-quality software. Documentation and tutorials are typically readily available, and changes are easily and quickly made based on community feedback. Community members provide support by answering users’ questions on online platforms like GitHub. Users looking for help can search the forums or ask new questions.
The typical community surrounding closed-source software is limited to the company selling the software. Support is typically only available as paid support from the software vendor through extra support packages or subscription services. The company must drive innovation, and software bugs are often reported in terms of misbehavior by the customer since many proprietary software deliveries are in binary form with no source code. Purely closed-source software development can dramatically slow down the development process.
Cost-Effectiveness & Flexibility
Using open-source software can save many years of development time as developers can start immediately with established software that is free of cost. Many open-source software projects have permissive licenses that allow commercial use and modifications. Companies can add and modify code to run their products in minimal time without the obligation to open-source all of these extensions. Using established open-source software with permissive licenses saves a ton of development time and gives great flexibility to companies during their development process. Developers can focus on creating and validating their solutions on development PCs. When moving to production systems, migrating from a prototype to a safety-certified, production-ready version of the framework can be achieved quickly and efficiently.
At Apex.AI, we embrace open-source development and fully believe the benefits lead to faster software development, lower costs, and better products. Our Apex.Grace product enhances ROS 2 and Apex.Ida enhances Eclipse iceoryx™. With Apex.AI SDK for microprocessors, we build on top of open-source projects to provide additional features, improved functionality and added safety certification. With the new Apex.AI SDK for microcontrollers, we continue on this successful path with a further example based on an open-source project.
Apex.AI SDK for Microcontrollers
We use the same approach toward open-source software for our microcontroller development by adding support for microcontrollers to our software framework Apex.Grace. This support enables a seamless transition of applications between high-performance microprocessor systems and hard real-time microcontrollers without having to modify the code heavily, leading to better utilization of available computing resources and overall system optimization. Modern System-on-Chip (SoCs) integrate both microcontrollers and microprocessors into one system. The ability to relocate and execute applications on all available cores is highly beneficial for efficient software development and a rapid transition to software-defined vehicles.
Our Apex.AI SDK for microcontrollers enhances the open-source Micro-ROS project, an open-source, lightweight, and modular framework. It uses the same tools as ROS 2 and Apex.Grace and is built with the familiar ROS 2 command-line interface.
The build system supports creating firmware for various microcontroller platforms and RTOSes. Adding a new microcontroller platform is straightforward. Two examples of additional platforms we have added as internal projects are the Xilinx Ultrascale+ MPSoC and the Infineon AURIX™ TC399. In our experience, adding a new platform takes a few weeks.
Micro-ROS supports a few real-time operating systems out of the box, including FreeRTOS, Zephyr and NuttX. We have plans to integrate with SafeRTOS to show a path to safety certification. The modular architecture enables easy implementation of communication transport mechanisms like a serial port or inter-core shared memory transport on SoCs. The user can select the needed communication transport through the command-line interface.
We have ported the ROS 2 rclcpp API to enable open-source ROS 2 nodes to run on microcontrollers, opening up the possibility of seamlessly moving applications between microcontrollers and microprocessors.
Next, we will introduce the Apex.Grace CERT API on microcontrollers. This API will enable the same safety-certified applications to run on both microcontrollers and microprocessors running Apex.Grace. Customers can trivially move safety-relevant functionality between ECUs, making transitioning from distributed to centralized architectures a breeze. Freedom of deployment and using a single homogeneous development environment for microcontrollers and microprocessors dramatically increase developer productivity and efficiency.
Demonstration
To demonstrate these benefits, we implemented a demonstrator that shows how software developed with the Apex.AI SDK for microcontrollers seamlessly integrates with Apex.Grace and Apex.Ida running on two different ECUs. Our demonstrator represents a vehicle with two microprocessor-based ECUs running Apex.Grace and a microcontroller-based ECU running software made with the Apex.AI SDK for microcontrollers.
We simulate three different vehicle functions in an Apex.Grace application: gas pedal, volume control, and seat belt detection. Users can control the vehicle speed, set the requested volume, and modify the seat occupancy state by changing the settings in a graphical user interface on the Control ECU.
The Control ECU sends these signals via the Apex.Grace CAN Connector to the Central Processing ECU, a microcontroller platform running a Micro-ROS node written with the Apex.AI SDK for microcontrollers. The central processing node calculates a system volume based on the vehicle speed and the volume control setting. A seat belt warning signal indicates when a moving vehicle contains a passenger without a properly buckled seat belt. The Central Processing ECU sends these two calculated signals to the Dashboard ECU via DDS. The Dashboard ECU user interface then visualizes all the received signals.
Conclusion
This article argued why microcontrollers are still a crucial component in automotive development. We showed that the Apex.AI SDK for microcontrollers provides a developer-friendly, modular software ecosystem with full interoperability with Apex.Grace and our demonstration shows this in a hands-on experience. As automotive electronic architectures move towards centralized architectures, we envision a safety-certified application API and a shared development environment for microcontrollers and microprocessors. Together, both will enable easier architectural transitioning and significantly increase developer productivity.
Please contact us if you want to see the demo live!