An Intro to AUTOSAR Operating System
The real-time operating system in an embedded system builds the basis for the dynamic behavior of the software. It manages the scheduling of tasks and events, the data flow between different tasks, and provides features for monitoring and error handling.
However, in automotive systems, the requirements of an operating system are highly domain-specific. For instance, in the body (locking systems for trunks, windows, or the vehicle roof up to the latest light control systems), powertrain (the engine or motor and its internal components, such as the energy storage system, transmission and driveshaft), and chassis (including safety, comfort, dynamic and efficiency) domains, the focus is on efficient scheduling of tasks and alarms, handling of shared resources, and deadline monitoring. The used operating system has to be very efficient in runtime and small in memory footprint.
In multimedia and telematics applications, the feature set provided by the operating system and available computing resources are significantly different. Here, on top of pure task management, also complex data handling (e.g. streams, flash file systems, etc.), memory management and often even a graphical user interface are contained in the OS.
The classic domain of an automotive OS covers the core features of scheduling and synchronization only. In the AUTOSAR architecture, the additional features discussed above are outside the scope of the OS. Such features are covered by the other AUTOSAR Basic Software Modules. (e.g. COM provides a communication abstraction).
Integrating the feature sets of other OSs (e.g. QNX, VxWorks, Windows CE, etc.) into a monolithic OS/communication/drivers structure is not possible under the architectural constraints of AUTOSAR.
AUTOSAR OS builds upon the OSEK/VDX OS specifications and provided APIs are backward compatible with the OSEK/VDX OS. Before moving on let us understand What is OSEK/VDX.
What is OSEK/VDX Operating System?
The term OSEK means “Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug” (Open systems and the corresponding interfaces for automotive electronics.) The term VDX means “Vehicule Distributed eXecutive”.
Just like AUTOSAR, OSEK/VDX is a joint project of the automotive industry. It aims at an industry standard for an open-ended architecture for distributed control units in vehicles. A real-time operating system, software interfaces, functions for communication, and network management tasks are thus jointly specified.
Companies involved include Opel, BMW, DaimlerChrysler, IIIT — University of Karlsruhe, PSA, Renault, Bosch, Siemens and Volkswagen. For detailed OSEK/VDX OS specifications, please visit. This document describes the concept of a real-time operating system, OSEK OS, capable of multitasking, which can be used for motor vehicles.
The specification of the OSEK operating system is to represent a uniform environment that supports efficient utilization of resources for automotive control unit application software. The OSEK operating system is a single processor operating system meant for distributed embedded control units.
Automotive applications are characterized by stringent real-time requirements. Therefore the OSEK operating system offers the necessary functionality to support event-driven control systems. OSEK OS provided requirements for the following features:
- Processing levels
- Conformance classes
- Tasks & Task management
- Application modes
- Interrupts & Interrupt processing
- Event mechanism
- Resource management
- Event control
- Alarms & Alarm Management
- Counters
- Messages
- Error handling (Hooks), tracing and debugging
- Operating system services
You can also read up about these in a very informative blog here.
AUTOSAR OS Features
As already described, AUTOSAR OS builds upon OSEK/VDX OS by providing additional features or adding some deviations. Here you will understand AUTOSAR OS characteristics:
Statically Defined Scheduling
In many applications, it is necessary to statically define the activation of a set of tasks related to each other. This can be for guaranteeing data consistency in data-flow based designs, synchronizing with a time-triggered network, guaranteeing correct run-time phasing, etc. A time-triggered operating system is often proposed as a solution to this problem.
However, time is simply an event so any event-triggered OS, including OSEK OS, can implement a scheduler for statically scheduled real-time software in automotive electronic control units. The requirements for schedules tables provide an OSEK OS object that can be manipulated in the same way as an OSEKtime dispatcher table.
Monitoring Facilities
A monitoring function detects an error at an appropriate stage in execution and not the instant at which the error occurs. Consequently, any monitoring function is the detection of a failure at runtime rather than the prevention of a fault.
Protection Facilities
The AUTOSAR concept requires multiply-sourced OS-Applications to co-exist on the same processor. To prevent unexpected interaction between these OS-Applications it is necessary to provide mechanisms that protect them from one another. There are two major use-cases:
- For a safety-critical system, the development of a safety-case is made much easier if individual OS-Application safety cases can be integrated into an overall safety case. This is only feasible if it can be demonstrated that at least a fault in one OS-Application cannot propagate beyond its own boundary and cause a fault in another, unrelated, OS-Application.
- Suppliers can only be expected to take responsibility (and some liability) for their software components and/or basic software modules if they can be assured that their software cannot be incorrectly blamed for a processor-wide failure.
Both of these use-cases can be satisfied by the addition of protection mechanisms to OSEK OS.
Timer Services
Timer Services provide software timers for use in applications and basic softwares. The core of a timing mechanism is already provided by the counters and alarms in OSEK OS. Introducing an almost identical mechanism, in the form of Timer Services, is therefore unnecessary.
However, to provide general-purpose software timing a few supplementary features are added to AUTOSAR OS.
Scalability
For a particular application, the operating system can be configured such that it only comprises the services required for this application. Thus the resource requirements of the operating system are as small as possible.
Scalability for the core OS is provided by OSEK OS’s conformance classes. Scalability with regard to AUTOSAR OS features refers to configurable behavior via the use of a generator.
Application Error Handling
Some errors affecting an application may not lead to protection violations that are detectable by the OS but nevertheless result in an application entering a state where it cannot itself recover and continue executing. The detection of such errors is the responsibility of the application itself, but recovery from such errors requires interaction with the threads of control managed by the OS. The OS, therefore, needs to provide a mechanism upon which applications can build internal recovery mechanisms.
The core OSEK OS provides some support: tasks can detect internal errors and terminate themselves; the system can use the alarm mechanism to program timeouts, implement threshold-based error detection; internal errors can be detected and the system can be shut down, etc. However, the core OS does not provide the means to implement error recovery for logical applications that are defined by OS-Applications.
Thus, AUTOSAR OS introduces requirements to provide a framework of application-level and system-level control of OS-Applications.
General Multi-Core issues
The requirements are very general in this context they basically define the spirit of the MultiCore (MC) capability that will be supported by the AUTOSAR environment. From an architectural point of view, Multi-Core hardware can be managed in various different ways. On the one extreme, cores might be understood as almost separate ECU, on the other extreme, they can be presented to the user almost like a Single-Core (SC) system with the capability of true parallelism. In automotive systems, the requirements for MC support are very domain-specific. Efficient scheduling, low resource consumption, and short response time are essential.
Hence, these requirements are designed in a way that the introduction of Multi-Core does not change the overall AUTOSAR philosophy. The MC concept allows to handle several cores almost like a SC system, but gives freedom to use cores outside this concept, e.g. as a dedicated I/O controller.
Assignment of runtime objects to cores
One major question when defining a Multi-Core system is whether runtime objects (tasks and ISR) can change between cores dynamically or not. The ability to dynamically assign runtime objects to different cores would have a massive impact on all efficiency aspects (code size / data size / speed / response time / real time capability) of a system.
It is conceivable to bind OsApplications to cores or to define the core binding on the level of TASKS and ISRs. To minimize the impact and complexity of the Multi-Core support within AUTOSAR it was decided to define the core binding the level of OsApplications.
AUTOSAR OS defines requirements that state core binding as the way to handle runtime objects within a MC AUTOSAR environment.
Startup of Multi-Core systems
The standard defines only some high-level requirements on the start-up. Depending on the used microcontroller, the start-up or reset behavior of the microcontrollers can differ. The most common behavior after a reset is as follows:
- Only a so-called master core starts to execute while all other cores (slave cores) remain in a halt state. The slave cores need to be started by the master core.
- A different approach is conceivable with all cores starting to execute concurrently after a reset. A master core does not exist in this case.
The wakeup mechanism and bootstrap requirements vary across different microcontrollers and microcontroller derivates. The progress in the start-up code on the different cores is not reproducible; this is because the length of time for load and store operations depends on bus arbitration and other very timing sensitive effects of the HW. Therefore the boot code must be designed in a way that it does not rely on the knowledge of the boot progress on other core(s). It is required to synchronize the different cores during start-up.
Shutdown of Multi-Core systems
Similar to the startup, the shutdown behavior of a Multi-Core system is different from the behavior of a Single-Core system. If a run-time object with the proper rights calls “ShutdownOS”, the whole system (all cores controlled by the MC-OS) have to shut down. Once the shutdown procedure has been started, valid tasks cannot be activated. It is the responsibility of the developer/system integrator to make sure that any preparations for shutdown on application and basic software level are completed before calling “ShutdownOS”
Configuration of Multi-Core systems
The standard only contains high-level requirements on the system configuration with respect to Multi-Core. The rest is highly microcontroller dependent.
Services in Multi-Core systems
The standard defines a set of mechanisms/services that allow optimal usage of a Multi-Core environment. The services might be provided by different AUTOSAR BSW modules. The AUTOSAR_SWS_Multi-Core defines from which module which service can be accessed.
Debugging and Tracing
Debugging tools need internal information to visualize the state of the software. Components and modules implementing this requirement shall provide the necessary state information that can be used by internal and external tools. AUTOSAR OS enables this by generating and ARTI module description file.
Similarly, code shall incorporate ARTI hooks for tracing purposes. The OS generator exposes the hooks and the traceable variables in an ARTI module description file.
Want to learn more ?
I am Ali Taqweem, Embedded Software developer specialized in Automotive domain, I have in-depth knowledge about Automotive Comm stacks, Bootloaders, Diagnostics, RTOS and AUTOSAR.
DM @ https://www.linkedin.com/in/ali-taqweem/
