Abstract
In the project UNICARagil， an ECU was developed that is part of the novel UNICARagil brain architecture［1］. The so-called brainstem was dedicated for safety-critical real-time control of a fully automated vehicle via a service-oriented architecture. This paper describes the hardware and basic software architecture of the device and points out some of the safety measures. The focus is on the MPSoC and OS configuration， the update process of the ECU， and the boot process. A system of fallback instances protects the ECU against critical errors in the bootloader， kernel or root file system， as well during the development process as in the field. Finally， this paper points out the functionality of the device in the vehicle context. In numerous publications in science and on social media， it presents the vehicle going over the proving ground with the brainstem as a central component.
The automotive domain today faces great challenges of which automated driving， electric drive and novel E/E-architectures are just some examples. To take a step to the future and unify all these technological trends into experimental real-life vehicles we started the UNICARagil project. There the Institute of Automotive Engineering （IFS） of the University of Stuttgart developed the fail-operational real-time ECU “brainstem” which belongs to the novel brain-based E/E-architecture of our vehicles
Fig. 1 Brainstem hardware V5.0
In this paper we will describe its hardware and software structure and make a deep dive into the boot and update process， as it gives a good insight into the technological structure of this system.
The UNICARagil brainstem is a fail-operational embedded real-time system with two redundant internal instances. The main application is trajectory contro
Fig.2 Hardware structure of one brainstem instance
Fig.3 describes the toolchain that is required for Xilinx MPSoC development. The workflow starts with the MPSoC hardware configuration. The system enables flexible pin configuration and activation of interfaces like CAN and SPI. The integrated programmable logic （PL） supports the implementation of ultra-fast low-level functionality like hardware support for communication protocols. The Xilinx tool Vivado offers pre-implemented IP-cores for the PL， e.g. for integration of a second GbE MAC on the chip.
The APU software is based on an embedded Linux with PREEMPT_RT kernel. The command line tool “PetaLinux Tools” generates complete embedded Linux boot images， containing bootloader， kernel， device tree and root file system. As a next software layer the Automotive Service Oriented Architecture （ASOA） serves as a middleware for the equal communication between all ASOA services in the vehicle， independently if they are located on the same ECU or not. The application software on the APU， especially the ASOA services， can be developed with general purpose code editors like Visual Studio Code. Examples for ASOA services on the APU are a vehicle boot and shutdown service， a driving corridor monitoring （DCM）， a platform sensor adapter （PSA） and the trajectory preprocessing （TP） service
Fig.3 Toolchain for brainstem development
The RPU is the host for our most safety and time critical application： the vehicle trajectory control. It is also the ideal place for a system monitoring service. The applications on the RPU are， like all software applications in the UNICARagil vehicles， implemented as ASOA services. The corresponding ASOA middleware for the RPU was implemented on the FreeRTOS real-time O
The brainstem has two persistent flash memories： a QSPI flash for the boot loader and the kernel and an eMMC flash for the root file system.
The QSPI flash has a physical size of 128 MB of which 78.5 MB are used， separated into 6 partitions.
Bootloader （BOOT.BIN） | Boot environment | Kernel A （image.ub） |
|---|---|---|
| 7 MB | 256 KB | 32 MB |
|
Bootl. backup （BOOT.BIN） |
Boot env. backup |
Kernel B （image.ub） |
| 7 MB | 256 KB | 32 MB |
| Rootfs A | Rootfs B | Log partition |
|---|---|---|
| 3，3 GB | 3，3 GB | 400 MB |
When an update fails due to a structural error in the new file system， the bootloader automatically switches back to the last one. The third partition is meant for common data like log file
We will now describe the boot and update process of the brainstem， because this example points out some of the characteristic features of its basic software structure.
Fig.4 Update process from the embedded Linux side
The update functionality of the brainstem supports a one-step update of the complete root file system. For this purpose it downloads the corresponding image file from the server and copies it into the inactive partition on the eMMC flash （A or B）. Subsequently the definition of the active and inactive root file system partition has to be saved into the boot environment. Finally， after a reboot the bootloader loads the new file system in resilient way， see chapter 5.
The RPU firmware automatically loads its image from the directory /lib/firmware. So the brainstem just has to download the boot image， stop RPU， copy the image to the directory and start RPU again. In UNICARagil embedded Linux applications such as services are managed via git. We reproduced relevant parts of the folder structure such as /usr/bin and /usr/lib in a repository， so the brainstem can clone its content directly to the root directory “/”. All services have to be stopped during that process.
Our embedded Linux supports package management via the DNF tool， which is deeply integrated into the automatic update process to install， update and delete system packages in a defined manner.
The update processes of bootloader and kernel represent special cases， as they need access to the QSPI flash. This memory device is not directly accessible for embedded Linux - apart from discrete variables in the boot environment over the commands fw_setenv and fw_printenv. So first the update program places the corresponding images in the directory “/boot” in the root file system. Then it sets the corresponding bootloader or kernel update flag in boot environment and initializes a reboot. After the system reset the current bootloader performs the final installation of the image on the QSPI-Flash， which will be described in detail in the next chapte
The update of basic software components like bootloader， kernel or root file system is a critical process， as the installation of faulty images can put the whole ECU out of commission and make it hard to recover. So we implemented a resilient update support in the boot process of the brainstem， described in
Fig.5 Bootloader process with robust update support
Bootloader： The bootloader copies itself and its boot environment to the backup partition， loads the new bootloader image from the /boot directory on the eMMC flash to the bootloader partition on the QSPI flash and performs a reset. The new bootloader is per default marked as not executed and not approved.
Kernel： The bootloader copies the kernel image from the /boot directory on the eMMC flash to the inactive kernel partition， switches the active partition， marks the image as not executed and not approved and performs a reset.
Rootfs： As the update of the rootfs is performed from the embedded Linux side， the bootloader just checks， whether it was approved after the last boot process and switches the active partition in case of a kernel panic.
As a last step of the bootloader process， the bootloader approves itself. So， if the boot or update process crashes， after a reboot the bootloader will load its own backup and make the system bootable agai
As the UNICARagil project is still going on we continue to develop the brainstem basic software and its applications. The resilient boot and update process supports us in our work and enables a fluent and agile development process as we can quickly and easily test new implementations and recover the last working state in case of mistakes. This allowed us finally to test the main functions of the brainstem like trajectory control in the real vehicle and prove our concept on the test route（see
Fig.6 UNICARagil vehicle AUTOtaxi on test rout
The coming months will be characterized by the final commissioning of the four vehicles in the fully automated mode. We will demonstrate it on the test route in our final event on May 11， 2023 in Aachen.
Reference
KEILHOFF D， et al. UNICARagil―New architectures for disruptive vehicle concepts［C］//Proceedings of 19 Internationales Stuttgarter Symposium. Wiesbaden： Springer Vieweg， 2019. [Baidu Scholar]
HOMOLLA T， et al. Verfahren zur korrektur von inkonsistenten Lokalisierungsdaten in modularen technischen Systemen［C］//13 Workshop Fahrerassistenzsysteme und Automatisiertes Fahren. Walting： TUbiblio， 2020. [Baidu Scholar]
ACKERMANN S， et al. Modul und verfahren zur absicherung von solltrajektorien für automatisiertes fahren：Deutsche Patentanmeldung Anmeldenummer： 10 2019 125 401.9［S］.2019. [Baidu Scholar]
ACKERMANN S， WINNER H. Systemarchitektur und Fahrmanöver zum sicheren Anhalten modularer automatisierter Fahrzeuge［C］//13 Workshop Fahrerassistenzsysteme und Automatisiertes Fahren. Walting： TUbiblio， 2020. [Baidu Scholar]
MOKHTARIAN A， et al. The dynamic service-oriented software architecture for the UNICARagil project［R］. Aachen： Universitätsbibliothek der RWTH Aachen， 2020. [Baidu Scholar]
DECKER E. Optimierung des boot-und shutdownvorgangs in einem steuergerät für automatisierte fahrzeuge［D］. Stuttgart：IFS， University of Stuttgart， 2021. [Baidu Scholar]
