The reality of AUTOSAR and the way forward
The evolution of car software has reached a point where there needs to be a radical change. Fully electric, autonomous, and connected vehicles require many million lines of code, and the updates need to be made over the air.
Many car suppliers talk about their OS, and there is a need for an ecosystem, that makes it easier to access off-board and on-board systems, with alluring features such as dynamic discovery of services and network agnostic APIs.
Another trend is the arrival of centralized computing platforms, the need for a discrete microcontroller for each vehicle’s functions is not needed anymore.
Many, but not all of these microcontrollers ran Classic AUTomotive Open System ARchitecture (AUTOSAR) based operation systems. AUTOSAR is a development partnership of automotive interested parties founded in 2003.
AUTOSAR was preceded by the OEM’s desire to use OSEK -certified (Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen; English: “Open Systems and their Interfaces for the Electronics in Motor Vehicles”) operating systems (only the scheduling part to begin with). Many Tier-1s had to get rid of their mature, target optimized and efficient proprietary schedulers. Instead, they had to use bulky, sub-optimized operating systems which may carry many features not needed by their application.
The objective with AUTOSAR was to create and establish an open and standardized software architecture for automotive electronic control units (ECUs). This standardization was to provide scalability to different vehicle and platform variants, and to enable transfer of software components between different suppliers and target ECUs.
The main concept of the standardized ECU software architecture was the separation of hardware-independent application software and hardware-oriented basic software (BSW) by means of the software abstraction layer RTE (runtime environment). RTE is a middleware which abstracts from the network topology for the inter and intra-ECU information exchange between the application software components and between the Basic Software and the applications. One of the biggest problems with AUTOSAR is just the RTE. It is very complex and like a mini-OS with its own execution rates. The top abstraction layer above the RTE enables the development of OEM-specific software applications.
Now, this sounds like an appealing idea, but there are many drawbacks.
Since AUTOSAR is developed by a committee (consisting of OEMS, Tier-1s, various component vendors, etc.), most of their nice-to-have features are present in the standard. That means that instead of a lean standard in some cases the standard is bloated. The amount of configuration parameters is endless, and complexity-by-design often breeds problems and high CPU load.
A software developer, who experiences an AUTOSAR OS for the first time, can have great difficulties. These quotes pretty much sums it all up:
there are now AUTOSAR experts and AUTOSAR tools and AUTOSAR Tool Experts and within that tool there is an ARXML generator which is generated with another tool … (source: Reddit)
I was considered an “AUTOSAR expert” for a time, and that essentially meant having enough programming and systems knowledge to work on the entire stack; but never writing a single line of code, only clicking buttons in these tools and watching them crash continuously, loosing hours upon hours of work. (source: Hacker News)
First, AUTOSAR is just a standard, and you need an implementation of it. Often, different vendors have different interpretations of the standard, so if we mix vendors in the same car project, we might have some surprises. Then the standard would most likely break. On top of this, each vendor makes tools, always GUI based, for which you need to configure your OS. This in turn causes problems, because these tools are difficult to automate, if at all possible, and put in a modern Continuous Integration (CI) system. Also, it’s hard to know what code all the configurations and their combinations will produce.
You might have a promising idea that you want to test under limited time (e.g. in a spike, during a hackathon, etc.), but the whole DevOps experience drowns and delays this innovation in a myriad of clicks lost through thousands of different options while reading the manuals in a not so intuitive or stable GUI. The end result also might be unexpected due to an obscure option on an unrelated menu. There might even be cases where you click one option, and then the tool changes old settings silently, that you did not think it would do.
The typical AUTOSAR workflow is by modelling a GUI application resulting in a project in some database. Then, the GUI produces a descriptions recipe file in ARXML, which defines the formal exchange format (AUTOSAR Schema) and the semantic constraints which go along with the exchange format.
Often then, this ARXML file goes into another GUI tool and then finally is used to generate source code; .c and .h files.
A huge problem is that the ARXML files are enormous in size, and they are extremely difficult to parse and generate.
Overall, it is a manual process, which is both error-prone and results in long lead times.
Is there a way around this?
Well, you don’t need to use the RTE and all the manual steps producing ARXML. You could work with source files and machine-readable recipe files like .json or .YAML. Especially, if you implement a Complex Device Driver (CDD), then you could avoid a lot of manual ARXML productions.
A CDD is a software entity, not standardized by AUTOSAR, which can access or be accessed via AUTOSAR Interfaces and Basic Software Modules APIs. The main goal of the CDD is to implement complex sensor evaluation and actuator control with direct access to the microcontroller, using specific interrupts and complex microcontroller peripherals, that is, external devices like communication transceivers, ASIC, etc., to fulfill the special functional and timing requirements.
In addition, it might be used to implement enhanced services and protocols or encapsulate legacy functionality of a non-AUTOSAR system. So, this is a way out in some cases.
Of course, such an approach may be seen risky, since one needs to write code and not just trust the code generation of some tool. And it might indeed be problematic, if done in a less professional setting (e.g., lack of experience, lack of testing, low coverage, etc.). But, if a company owns the stack, they also need to own the code, so there might not be a way out of this.
CPU load
During the years of developing embedded software in vehicles, I had the chance to talk to one of the largest suppliers of ECUs and of embedded OS platforms. Their point of view was that sometimes there is a hard requirement to use AUTOSAR, but still, a cheap CPU had to be used. Due to this, they claimed that it is often necessary to have a team of experienced engineers (10 engineers or more) to work for significant amounts of time (years+) modifying their AUTOSAR implementation to optimize and trim the AUTOSAR performance.
Many engineers have told me, and I have observed firsthand, that different AUTOSAR OS’es add cpu load, how much cpu load that is added is dependent on the implementation.
On cars with combustion engines, the engine ECU was many times the one handling the most complex algorithms. When the requirement to convert these to AUTOSAR came, it was observed that the CPU load increased by more than 30%, in the same codebase just by running the COM stack. This led to solutions where one core ran just the OSEK OS and sometimes in combination with CDDs in some instances. Signaling between the different layers is handled by .c and .h files, configuration was done in .json and .csv and developers were still happy. These developers did not see how the developers working with ARXML files and databases suffered.
Still, there were some teams who had their algorithms distributed in pure manual ARXML populated development kits. During this time, we got a lot of support in offering a CI chain that could produce downloadable and tested software in less than 45 minutes, compared to 12–48h.
So, what could be the future? What are the alternatives?
As already written about, we at Volvo Cars Corporation implement a full ECU in RUST.
There is an interesting upcomer https://oxidos.io/ that offers a safe OS, written in RUST and based on Open-source.
Another interesting project is https://github.com/zephyrproject-rtos/zephyr. It might not be Safety Certified for some years, but it looks promising, and it is Open-source.
Then there is of course FreeRTOS. The FreeRTOS kernel was originally developed by Richard Barry around 2003 and was later developed and maintained by Barry’s company, Real Time Engineers Ltd. In 2017, the firm passed stewardship of the FreeRTOS project to Amazon Web Services (AWS) . Barry continues to work on FreeRTOS as part of an AWS team.
Then we have SAFERTOS®, that is based on the functional model of the FreeRTOS kernel. This is available and pre-certified to ISO 26262 ASIL D by TÜV SÜD, but not Open-source.
So, what is needed is a developer-friendly environment that uses source code, and machine-readable recipe files. It would be needed to be CPU efficient, and many solutions that are Opensource utilize shared memory solutions (example: https://iceoryx.io/latest/getting-started/what-is-iceoryx/#fast ).
When it comes to middleware and API standards, the Data Distribution Service (DDS™) is very much appealing. Configured correctly, it might even be used in embedded systems like car ECUs, and it could very well provide a scalable architecture of a car OS of the future. DDS conceptually sees a local store of data called the “global data space.” To the application, the global data space looks like local memory, accessed via an API; You write what looks like your local storage. In reality, DDS sends messages to update the appropriate stores on remote nodes. You read from what looks like a local store. Altogether, the local stores give applications the illusion of having access to the entire global data space.
The global data space shares data between embedded, mobile, and cloud applications across any transport, regardless of language or system,
sounds lovely right?
