AUTOSAR Classic Operating System

The module cluster Operating System provides deterministic real-time scheduling for tasks and ISRs as well as memory protection and fault containment in partitioned OS-Applications [SWS_Os_00445]. It supports multi-core systems through cross-core spinlocks, asynchronous task activation, and the Inter-OS-Application Communicator (IOC) [SWS_Os_00686], [SWS_Os_00824]. When protection violations occur, the OS enables the targeted termination or controlled restart of individual partitions at runtime via configurable hooks ApplicationLevelErrorHandling p. 53.

more ›

In AUTOSAR Classic, the module cluster "Operating System" provides the fundamental execution and protection infrastructure for software components and Basic Software modules. The Operating System encapsulates resources such as tasks, ISRs, alarms, and counters in OS-Applications [SWS_Os_00445] and distinguishes between trusted and non-trusted partitions [SWS_Os_00446] in order to ensure strict fault containment based on MPU memory protection SafetyConceptStatusReport p. 49. In multicore systems, the OS manages logical cores via standardized core IDs [SWS_Os_00790] and provides the Inter-OS-Application Communicator (IOC) for data- and event-based exchange between cores and partitions [SWS_Os_00824].

Context diagram: Embedding of the OS cluster into the AUTOSAR Basic Software architecture and interfaces to EcuM, StbM, RTE, and hardware. Sources: [SWS_Os_00445], [SWS_Os_00790], SWS_BSWGeneral p. 48.

In addition to event-driven task scheduling, the OS enables time-triggered execution tracking via Schedule Tables [SWS_Os_00783]. These can be adjusted to global vehicle time bases via the Synchronized Time-Base Manager (StbM) using SyncScheduleTable [SWS_Os_00199], SWS_SynchronizedTimeBaseManager p. 220. For synchronization across core boundaries, the module provides hardware-related spinlocks with integrated deadlock detection [SWS_Os_00686], while cross-core task activations can be executed asynchronously with ActivateTaskAsyn [SWS_Os_91022].

In case of an error (such as memory violations), the OS activates the ProtectionHook [SWS_Os_00538]. Via its return value, a faulty OS-Application can be isolated and terminated in a controlled manner or re-initialized via a dedicated restart task without resetting the overall system [SWS_Os_00787], ApplicationLevelErrorHandling p. 53.

State diagram: Lifecycle and partitioning states of an AUTOSAR OS-Application in case of an error. Sources: [SWS_Os_00773], [SWS_Os_00258], ApplicationLevelErrorHandling p. 53.

more ›

1. System Architecture & Role of the Module Cluster

In the AUTOSAR layered model, the module cluster "Operating System" forms the fundamental foundation of the System Services for executing and coordinating all real-time software components and Basic Software modules. The core module [SWS_Os_00445] encapsulates tasks, interrupt service routines (ISRs), alarms, counters, and schedule tables in configurable execution units, the so-called OS-Applications. Here, the Operating System strictly distinguishes between trusted and non-trusted OS-Applications [SWS_Os_00446] in order to provide functional safety and memory protection according to the required scalability classes SafetyConceptStatusReport p. 49.

In multicore architectures, the OS manages logical cores that are referenced via unique identifiers of type CoreIdType [SWS_Os_00790]. The core IDs are zero-based and consecutively arranged [SWS_Os_00825], where the constant OS_CORE_ID_MASTER designates the master core SWS_OS p. 111. Via the integrated Inter-OS-Application Communicator (IOC), the Operating System provides mechanisms for secure, cross-partition, and cross-core data transmission [SWS_Os_00824]. By standardizing the interfaces according to OSEK OS and their AUTOSAR-specific extensions, the OS guarantees deterministic real-time behavior for higher-level modules such as the ECU State Manager (EcuM), the Synchronized Time-Base Manager (StbM), and the runtime environment RTE SWS_BSWGeneral p. 48.

Context diagram: Embedding of the OS cluster into the AUTOSAR Basic Software architecture and interfaces to EcuM, StbM, RTE, and hardware. Sources: [SWS_Os_00445], [SWS_Os_00790], SWS_BSWGeneral p. 48.

2. Interplay & Interaction Paths between the Modules

The interaction between the OS objects and the layers of the AUTOSAR architecture takes place via sharply delimited control and data paths. For cross-partition data exchange, the IOC generates typed communication functions with unqueued ("data", IocWrite / IocRead) or queued semantics ("event", IocSend / IocReceive) [SWS_Os_00718], [SWS_Os_00738]. For group transmissions, the services IocSendGroup and IocReceiveGroup are used [SWS_Os_00728], [SWS_Os_00746]. If an internal buffer of the receiver becomes full, the IOC signals this to the sender with the status IOC_E_LIMIT and records a IOC_E_LOST_DATA for subsequent read operations SWS_OS p. 225.

When a non-trusted OS-Application needs to access privileged services of a trusted partition, the controlled context switch takes place via the system service CallTrustedFunction [SWS_Os_00097]. Here, the parameters are passed via a pointer structure of type TrustedFunctionParameterRefType [SWS_Os_00776]. The Operating System temporarily switches the MPU permissions to those of the target application SWS_OS p. 172. During this execution, the function GetCurrentApplicationID returns the identifier of the called Trusted Application, whereas GetApplicationID yields the original caller application [SWS_Os_00797].

For temporal coordination with external time bases, the module StbM synchronizes explicitly configured Schedule Tables via the OS interfaces. StbM first queries the synchronization state cyclically via GetScheduleTableStatus [SWS_Os_00227] and then passes the current synchronization value to the OS using SyncScheduleTable [SWS_Os_00199]. The Operating System then calculates the deviation from the expiry points and adjusts the delay times incrementally until the table runs synchronously with the global time base SWS_OS p. 57, SWS_SynchronizedTimeBaseManager p. 220.

Sequence diagram: Explicit synchronization of an OS Schedule Table by the Synchronized Time-Base Manager (StbM). Sources: [SWS_Os_00199], [SWS_Os_00227], SWS_SynchronizedTimeBaseManager p. 220.

3. Synchronization, Reentrancy, and Task Contexts

The runtime model clearly distinguishes between task level, interrupt levels of category 1 (Cat 1 ISR) and category 2 (Cat 2 ISR), as well as hook routines. While Cat 1 ISRs run without Operating System overhead and must not call any OS services, Cat 2 ISRs are completely managed by the OS [SWS_Os_00782]. The active ISR identifier can be determined using GetISRID; when called outside a Cat 2 ISR, the service returns INVALID_ISR [SWS_Os_00511]. Individual interrupt sources can be controlled selectively at the interrupt controller level via EnableInterruptSource, DisableInterruptSource, and ClearPendingInterrupt [SWS_Os_91020], [SWS_Os_91019], [SWS_Os_91021].

To synchronize critical sections across processor core boundaries, the OS provides spinlocks [SWS_Os_00791]. A spinlock is occupied in a synchronous blocking manner with GetSpinlock [SWS_Os_00686] or queried in a non-blocking manner via TryToGetSpinlock [SWS_Os_00703]. The release takes place via ReleaseSpinlock [SWS_Os_00695]. To prevent deadlocks, the OS checks for nesting and overlap errors (E_OS_INTERFERENCE_DEADLOCK, E_OS_NESTING_DEADLOCK) in extended status SWS_OS p. 199.

For cross-core task activations and event setting, the OS provides asynchronous API variants: ActivateTaskAsyn and SetEventAsyn return immediately to the caller without waiting for execution on the target core [SWS_Os_91022], [SWS_Os_91023]. Possible errors are not returned to the caller, but logged via configured error hooks [SWS_Os_00816], SWS_OS p. 203.

4. Typical Lifecycles and Operating Modes

The system startup is primarily coordinated by the ECU State Manager (EcuM). On the master core, EcuM starts subordinate cores prior to the Operating System startup via the OS service StartCore [SWS_Os_00676], SWS_ECUStateManager p. 82. Subsequently, each started core calls StartOS autonomously. After the call to StartOS, the Operating System transitions all configured OS-Applications into the state APPLICATION_ACCESSIBLE before startup hooks are executed SWS_OS p. 62. The number of successfully booted cores can be queried at runtime with GetNumberOfActivatedCores SWS_OS p. 196.

Schedule Tables are subject to a clearly defined state machine. They can be started absolutely via StartScheduleTableAbs [SWS_Os_00358], relatively via StartScheduleTableRel [SWS_Os_00347], or synchronously via StartScheduleTableSynchron [SWS_Os_00201]. Tables can be chained (NextScheduleTable, state SCHEDULETABLE_NEXT) [SWS_Os_00191] or transitioned immediately into the dormant state SCHEDULETABLE_STOPPED with StopScheduleTable [SWS_Os_00006]. An ongoing explicit synchronization can be canceled using SetScheduleTableAsync, whereby the processing of the expiry points is continued [SWS_Os_00422].

For power saving modes during idle state, the OS provides the interface ControlIdle, allowing the EcuM to configure the sleep state of individual cores [SWS_Os_00769]. During shutdown, the EcuM coordinates the de-initialization of all layers and finally calls ShutdownAllCores or ShutdownOS to stop the overall system in a controlled manner SWS_ECUStateManager p. 90.

5. Error Handling, DET Tracing, and Degradation

Protection violations (such as memory violations or timing violations) lead to the activation of the global ProtectionHook [SWS_Os_00538]. Based on the error, the hook decides on the recovery strategy via a return value of type ProtectionReturnType [SWS_Os_00787]: termination of the triggering entity (PRO_TERMINATETASKISR), complete termination of the affected partition (PRO_TERMINATEAPPL), initiation of a controlled partition restart (PRO_TERMINATEAPPL_RESTART), or shutdown of the ECU (PRO_SHUTDOWN) ApplicationLevelErrorHandling p. 60.

If an OS-Application is terminated or restarted, the OS transitions it from the state APPLICATION_ACCESSIBLE to APPLICATION_RESTARTING or APPLICATION_TERMINATED [SWS_Os_00773]. All active tasks, ISRs, alarms, and Schedule Tables of the partition are stopped immediately and all interrupts are disabled [SWS_Os_00447]. In the state APPLICATION_RESTARTING, the OsRestartTask is executed exclusively to perform cleanup before normal operation is enabled again ApplicationLevelErrorHandling p. 53, ApplicationLevelErrorHandling p. 76.

State diagram: Lifecycle and partitioning states of an AUTOSAR OS-Application in case of an error. Sources: [SWS_Os_00773], [SWS_Os_00258], ApplicationLevelErrorHandling p. 53.

For preventive error avoidance, the Operating System provides memory protection checking functions such as CheckTaskMemoryAccess and CheckISRMemoryAccess [SWS_Os_00512], [SWS_Os_00513] as well as access permission checks via CheckObjectAccess and CheckObjectOwnership [SWS_Os_00256], [SWS_Os_00017]. Via these standardized checks, it can be ensured that non-trusted components do not perform unauthorized write or execution accesses in memory SWS_OS p. 73.