AUTOSAR Classic Operating System
Cluster GuideKI-GENERIERT
Stellt deterministisches Echtzeit-Scheduling, Speicherschutz, Mehrkern-Synchronisation und Fehlereindämmung bereit.
Stellt deterministisches Echtzeit-Scheduling, Speicherschutz, Mehrkern-Synchronisation und Fehlereindämmung bereit.
Das Modulcluster Operating System stellt das deterministische Echtzeit-Scheduling für Tasks und ISRs sowie Speicherschutz und Fehlerkapselung in partitionierten OS-Applications bereit [SWS_Os_00445]. Es unterstützt Mehrkernsysteme durch kernübergreifende Spinlocks, asynchrone Task-Aktivierung und den Inter-OS-Application Communicator (IOC) [SWS_Os_00686], [SWS_Os_00824]. Beim Auftreten von Schutzverletzungen ermöglicht das OS über konfigurierbare Hooks das gezielte Beenden oder kontrollierte Wiederanlaufen einzelner Partitionen zur Laufzeit ApplicationLevelErrorHandling S. 53.
Das Modulcluster „Operating System“ stellt in AUTOSAR Classic die fundamentale Ablauf- und Schutzinfrastruktur für Softwarekomponenten und Basissoftwaremodule bereit. Das Betriebssystem kapselt Ressourcen wie Tasks, ISRs, Alarme und Zähler in OS-Applications [SWS_Os_00445] und unterscheidet dabei zwischen vertrauenswürdigen (trusted) und nicht-vertrauenswürdigen Partitionen [SWS_Os_00446], um strikte Fehlereindämmung auf Basis von MPU-Speicherschutz zu gewährleisten SafetyConceptStatusReport S. 49. In Mehrkernsystemen verwaltet das OS logische Kerne über standardisierte Kern-IDs [SWS_Os_00790] und stellt für den daten- und ereignisbasierten Austausch zwischen Kernen und Partitionen den Inter-OS-Application Communicator (IOC) bereit [SWS_Os_00824].
Kontextdiagramm: Einbettung des OS-Clusters in die AUTOSAR-Basissoftwarearchitektur und Schnittstellen zu EcuM, StbM, RTE und Hardware. Quellen: [SWS_Os_00445], [SWS_Os_00790], SWS_BSWGeneral S. 48.
Neben dem ereignisgesteuerten Task-Scheduling ermöglicht das OS die zeitgesteuerte Ablaufverfolgung über Schedule Tables [SWS_Os_00783]. Diese können über den Synchronized Time-Base Manager (StbM) mittels SyncScheduleTable an globale Fahrzeug-Zeitbasen angepasst werden [SWS_Os_00199], SWS_SynchronizedTimeBaseManager S. 220. Zur Synchronisation über Kerngrenzen hinweg bietet das Modul hardwarenahe Spinlocks mit integrierter Deadlock-Erkennung [SWS_Os_00686], während kernübergreifende Task-Aktivierungen asynchron mit ActivateTaskAsyn ausgeführt werden können [SWS_Os_91022].
Im Fehlerfall (etwa bei Speicherüberschreitungen) aktiviert das OS den ProtectionHook [SWS_Os_00538]. Über dessen Rückgabewert kann eine fehlerhafte OS-Application isoliert und kontrolliert terminiert oder über einen dedizierten Restart-Task neu initialisiert werden, ohne das Gesamtsystem zurückzusetzen [SWS_Os_00787], ApplicationLevelErrorHandling S. 53.
Zustandsdiagramm: Lebenszyklus und Partitionierungszustände einer AUTOSAR OS-Application im Fehlerfall. Quellen: [SWS_Os_00773], [SWS_Os_00258], ApplicationLevelErrorHandling S. 53.
1. Systemarchitektur & Rolle des Modulclusters
Das Modulcluster „Operating System“ bildet im AUTOSAR-Schichtenmodell das fundamentale Fundament der System Services zur Ausführung und Koordination aller Echtzeit-Softwarekomponenten und Basissoftware-Module. Das Kernmodul [SWS_Os_00445] kapselt Tasks, Interrupt-Service-Routinen (ISRs), Alarme, Zähler (Counter) und Ablaufverfolgungstabellen (Schedule Tables) in konfigurierbaren Ausführungseinheiten, den sogenannten OS-Applications. Hierbei unterscheidet das Betriebssystem strikt zwischen vertrauenswürdigen (trusted) und nicht-vertrauenswürdigen (non-trusted) OS-Applications [SWS_Os_00446], um funktionale Sicherheit und Speicherschutz gemäß den geforderten Skalierbarkeitsklassen bereitzustellen SafetyConceptStatusReport S. 49.
In Mehrkernarchitekturen verwaltet das OS logische Kerne, die über eindeutige Bezeichner vom Typ CoreIdType referenziert werden [SWS_Os_00790]. Die Kern-IDs sind nullbasiert und fortlaufend angeordnet [SWS_Os_00825], wobei die Konstante OS_CORE_ID_MASTER den Master-Kern kennzeichnet SWS_OS S. 111. Über den integrierten Inter-OS-Application Communicator (IOC) stellt das Betriebssystem Mechanismen für die sichere, partitions- und kernübergreifende Datenübertragung bereit [SWS_Os_00824]. Durch die Standardisierung der Schnittstellen nach OSEK OS und deren AUTOSAR-spezifische Erweiterungen garantiert das OS deterministisches Echtzeitverhalten für übergeordnete Module wie den ECU State Manager (EcuM), den Synchronized Time-Base Manager (StbM) sowie die Laufzeitumgebung RTE SWS_BSWGeneral S. 48.
Kontextdiagramm: Einbettung des OS-Clusters in die AUTOSAR-Basissoftwarearchitektur und Schnittstellen zu EcuM, StbM, RTE und Hardware. Quellen: [SWS_Os_00445], [SWS_Os_00790], SWS_BSWGeneral S. 48.
2. Zusammenspiel & Interaktionspfade zwischen den Modulen
Die Interaktion zwischen den OS-Objekten und den Schichten der AUTOSAR-Architektur erfolgt über scharf abgegrenzte Kontroll- und Datenpfade. Für den partitionsübergreifenden Datenaustausch generiert der IOC typisierte Kommunikationsfunktionen mit unqueued („data“, IocWrite / IocRead) oder queued Semantik („event“, IocSend / IocReceive) [SWS_Os_00718], [SWS_Os_00738]. Bei Gruppenübertragungen kommen die Dienste IocSendGroup bzw. IocReceiveGroup zum Einsatz [SWS_Os_00728], [SWS_Os_00746]. Läuft ein interner Puffer des Empfängers voll, signalisiert der IOC dies mit dem Status IOC_E_LIMIT an den Sender und vermerkt für nachfolgende Leseoperationen ein IOC_E_LOST_DATA SWS_OS S. 225.
Wenn eine nicht-vertrauenswürdige OS-Application auf privilegierte Dienste einer vertrauenswürdigen Partition zugreifen muss, erfolgt der kontrollierte Kontextwechsel über den Systemdienst CallTrustedFunction [SWS_Os_00097]. Hierbei werden die Parameter über eine Zeigerstruktur vom Typ TrustedFunctionParameterRefType übergeben [SWS_Os_00776]. Das Betriebssystem wechselt temporär die MPU-Berechtigungen auf die der Ziel-Applikation SWS_OS S. 172. Die Funktion GetCurrentApplicationID gibt während dieser Ausführung die Kennung der aufgerufenen Trusted Application zurück, wohingegen GetApplicationID die ursprüngliche Aufrufer-Applikation liefert [SWS_Os_00797].
Zur zeitlichen Abstimmung mit externen Zeitbasen synchronisiert das Modul StbM über die OS-Schnittstellen explizit konfigurierte Schedule Tables. StbM fragt zunächst zyklisch über GetScheduleTableStatus den Synchronisationszustand ab [SWS_Os_00227] und übergibt anschließend den aktuellen Synchronisationswert mittels SyncScheduleTable an das OS [SWS_Os_00199]. Das Betriebssystem berechnet daraufhin die Abweichung zu den Ablaufpunkten (Expiry Points) und passt die Verzögerungszeiten schrittweise an, bis die Tabelle synchron zur globalen Zeitbasis läuft SWS_OS S. 57, SWS_SynchronizedTimeBaseManager S. 220.
Sequenzdiagramm: Explizite Synchronisation einer OS-Schedule-Table durch den Synchronized Time-Base Manager (StbM). Quellen: [SWS_Os_00199], [SWS_Os_00227], SWS_SynchronizedTimeBaseManager S. 220.
3. Synchronisation, Reentranz und Task-Kontexte
Das Laufzeitmodell unterscheidet klar zwischen Task-Ebene, Interrupt-Ebenen der Kategorie 1 (Cat 1 ISR) und Kategorie 2 (Cat 2 ISR) sowie Hook-Routinen. Während Cat 1 ISRs ohne Betriebssystem-Overhead ablaufen und keine OS-Dienste aufrufen dürfen, werden Cat 2 ISRs vollständig vom OS verwaltet [SWS_Os_00782]. Die aktive ISR-Kennung kann mittels GetISRID ermittelt werden; bei einem Aufruf außerhalb einer Cat 2 ISR liefert der Dienst INVALID_ISR zurück [SWS_Os_00511]. Einzelne Interrupt-Quellen lassen sich gezielt über EnableInterruptSource, DisableInterruptSource sowie ClearPendingInterrupt auf Interrupt-Controller-Ebene steuern [SWS_Os_91020], [SWS_Os_91019], [SWS_Os_91021].
Zur Synchronisation kritischer Abschnitte über Prozessorkerngrenzen hinweg stellt das OS Spinlocks zur Verfügung [SWS_Os_00791]. Ein Spinlock wird synchron blockierend mit GetSpinlock belegt [SWS_Os_00686] oder nicht-blockierend über TryToGetSpinlock abgefragt [SWS_Os_00703]. Die Freigabe erfolgt über ReleaseSpinlock [SWS_Os_00695]. Um Deadlocks auszuschließen, prüft das OS im erweiterten Status auf Verschachtelungs- und Überlappungsfehler (E_OS_INTERFERENCE_DEADLOCK, E_OS_NESTING_DEADLOCK) SWS_OS S. 199.
Für kernübergreifende Task-Aktivierungen und Event-Setzungen stellt das OS asynchrone API-Varianten bereit: ActivateTaskAsyn und SetEventAsyn kehren sofort zum Aufrufer zurück, ohne auf die Ausführung auf dem Zielkern zu warten [SWS_Os_91022], [SWS_Os_91023]. Mögliche Fehler werden dabei nicht an den Aufrufer zurückgegeben, sondern über konfigurierte Error-Hooks protokolliert [SWS_Os_00816], SWS_OS S. 203.
4. Typische Lebenszyklen und Betriebsmodi
Der Systemstart wird maßgeblich durch den ECU State Manager (EcuM) koordiniert. Auf dem Master-Kern startet EcuM vor dem Betriebssystemstart untergeordnete Kerne über den OS-Dienst StartCore [SWS_Os_00676], SWS_ECUStateManager S. 82. Anschließend ruft jeder gestartete Kern autark StartOS auf. Nach dem Aufruf von StartOS wechselt das Betriebssystem alle konfigurierten OS-Applications in den Zustand APPLICATION_ACCESSIBLE, bevor Startup-Hooks ausgeführt werden SWS_OS S. 62. Die Anzahl der erfolgreich hochgefahrenen Kerne kann zur Laufzeit mit GetNumberOfActivatedCores abgefragt werden SWS_OS S. 196.
Schedule Tables unterliegen einem klar definierten Zustandsautomaten. Sie können absolut über StartScheduleTableAbs [SWS_Os_00358], relativ über StartScheduleTableRel [SWS_Os_00347] oder synchron über StartScheduleTableSynchron gestartet werden [SWS_Os_00201]. Tabellen lassen sich verketten (NextScheduleTable, Zustand SCHEDULETABLE_NEXT) [SWS_Os_00191] oder mit StopScheduleTable sofort in den Ruhezustand SCHEDULETABLE_STOPPED überführen [SWS_Os_00006]. Eine laufende explizite Synchronisation kann mittels SetScheduleTableAsync abgebrochen werden, wobei die Abarbeitung der Expiry Points fortgesetzt wird [SWS_Os_00422].
Für Energiesparmodi im Leerlauf bietet das OS die Schnittstelle ControlIdle, womit der EcuM den Ruhezustand einzelner Kerne konfigurieren kann [SWS_Os_00769]. Beim Herunterfahren koordiniert der EcuM die Deinitialisierung aller Schichten und ruft schließlich ShutdownAllCores bzw. ShutdownOS auf, um das Gesamtsystem kontrolliert anzuhalten SWS_ECUStateManager S. 90.
5. Fehlerbehandlung, DET-Tracing und Degradation
Schutzverletzungen (wie Speicherüberschreitungen oder Timing-Verletzungen) führen zur Aktivierung des globalen ProtectionHook [SWS_Os_00538]. Anhand des Fehlers entscheidet der Hook über die Recovery-Strategie über einen Rückgabewert vom Typ ProtectionReturnType [SWS_Os_00787]: Terminierung der auslösenden Entität (PRO_TERMINATETASKISR), vollständige Terminierung der betroffenen Partition (PRO_TERMINATEAPPL), Einleitung eines kontrollierten Partitionsneustarts (PRO_TERMINATEAPPL_RESTART) oder Herunterfahren des Steuergeräts (PRO_SHUTDOWN) ApplicationLevelErrorHandling S. 60.
Wird eine OS-Application beendet oder neu gestartet, versetzt das OS diese aus dem Zustand APPLICATION_ACCESSIBLE in APPLICATION_RESTARTING bzw. APPLICATION_TERMINATED [SWS_Os_00773]. Alle aktiven Tasks, ISRs, Alarme und Schedule Tables der Partition werden unverzüglich gestoppt und alle Interrupts deaktiviert [SWS_Os_00447]. Im Zustand APPLICATION_RESTARTING wird exklusiv der OsRestartTask ausgeführt, um Bereinigungen durchzuführen, bevor der Normalbetrieb wieder freigegeben wird ApplicationLevelErrorHandling S. 53, ApplicationLevelErrorHandling S. 76.
Zustandsdiagramm: Lebenszyklus und Partitionierungszustände einer AUTOSAR OS-Application im Fehlerfall. Quellen: [SWS_Os_00773], [SWS_Os_00258], ApplicationLevelErrorHandling S. 53.
Zur präventiven Fehlervermeidung bietet das Betriebssystem Speicherschutz-Prüffunktionen wie CheckTaskMemoryAccess und CheckISRMemoryAccess [SWS_Os_00512], [SWS_Os_00513] sowie Zugriffsberechtigungsprüfungen via CheckObjectAccess und CheckObjectOwnership [SWS_Os_00256], [SWS_Os_00017]. Über diese standardisierten Prüfungen kann sichergestellt werden, dass nicht-vertrauenswürdige Komponenten keine unerlaubten Schreib- oder Ausführungszugriffe im Speicher vollziehen SWS_OS S. 73.
Kontext dieses Leitfadens: Erstellt auf Basis der AUTOSAR Classic Spezifikationen für das Release R20-11. Alle Schnittstellen und Zustandsübergänge sind strikt durch die referenzierten SWS-Anforderungen belegt.
Das AUTOSAR Operating System ist ein statisch konfiguriertes, echtzeitfähiges preemptives Betriebssystem nach OSEK/VDX mit Tasks, Events, Alarmen, Schedule-Tables und Speicherschutz.
Module im Cluster
Themenkarte
Os
79Für dieses Release liegen keine Elementdaten vor
Os
This callback function can be configured for the receiver of a communication. If configured, IOC calls this callback on the receiving core for each data reception. is the callback function name configured by the receiver in the Os Ioc Re ceiver Pull CB attribute to be called on data reception."
void <ReceiverPullCB> (void);This service determines if the OS - Applications, given by Appl ID, is allowed to use the IDs of a Task, Resource, Counter, Alarm or Schedule Table in API calls.
ObjectAccessType CheckObjectAccess (ApplicationType ApplID, ObjectTypeType ObjectType, void ...);Asynchronous version of the Activate Task() function. Intended to be used for cross core task activation. Possible errors are not returned to the caller, but may be reported via error hooks.
void ActivateTaskAsyn (TaskType id);This service sets the own state of an OS - Application from AP PLICATION_ RESTARTING to APPLICATION_ ACCESSIBLE.
StatusType AllowAccess (void);A (trusted or non - trusted) OS - Application uses this service to call a trusted function
StatusType CallTrustedFunction (TrustedFunctionIndexType FunctionIndex, TrustedFunctionParameterRefType FunctionParams);This service checks if a memory region is write/ read/ execute accessible and also returns information if the memory region is part of the stack space.
AccessType CheckISRMemoryAccess (ISRType ISRID, MemoryStartAddressType Address, MemorySizeType Size);This service determines to which OS - Application a given Task, ISR, Counter, Alarm or Schedule Table belongs
ApplicationType CheckObjectOwnership (ObjectTypeType ObjectType, void ...);This service checks if a memory region is write/ read/ execu te accessible and also returns information if the memory region is part of the stack space.
AccessType CheckTaskMemoryAccess (TaskType TaskID, MemoryStartAddressType Address, MemorySizeType Size);Service ClearPendingInterrupt.
StatusType ClearPendingInterrupt (ISRType ISRID);This API allows the caller to select the idle mode action which is performed during idle time of t he OS (e.g. if no Task/ ISR is active). It can be used to implement energy savings. The real idle modes are hardware dependent and not standardized. The default idle mode on each core is IDLE_ NO_ HALT.
StatusType ControlIdle (CoreIdType CoreID, IdleModeType IdleMode);Disables the interrupt source by modifying the interrupt controller registers.
StatusType DisableInterruptSource (ISRType ISRID);Service EnableInterruptSource.
StatusType EnableInterruptSource (ISRType ISRID, boolean ClearPending);This service determines the OS - Application (a unique identifier has to be allocated to each application) where the caller originally belongs to (was configured t o).
ApplicationType GetApplicationID (void);This service returns the current state of an OS - Application.
StatusType GetApplicationState (ApplicationType Application, ApplicationStateRefType Value);The function returns a unique core identifier.
CoreIdType GetCoreID (void);This service reads the current count value of a counte r (returning either the hardware timer ticks if counter is driven by hardware or the software ticks when user drives counter).
StatusType GetCounterValue (CounterType CounterID, TickRefType Value);This service determines the OS - Application where the caller of the service is currently executing. Note that if the caller is not within a Call Trusted Function() call the value is eq ual to the result of Get Application ID().
ApplicationType GetCurrentApplicationID (void);This service gets the number of ticks between the current tick value and a previously read tick value.
StatusType GetElapsedValue (CounterType CounterID, TickRefType Value, TickRefType ElapsedValue);This service returns the identifier of the currently executing ISR.
ISRType GetISRID (void);The function returns the number of cores activated by the Start Core function. This function might be a macro. AUTOSAR CP R20 - o f Document ID : AUTOSAR_SWS_OS
uint32 GetNumberOfActivatedCores (void);This service queries the state of a schedule table (also with respect to synchronization).
StatusType GetScheduleTableStatus (ScheduleTableType ScheduleTableID, ScheduleTableStatusRefType ScheduleStatus);Get Spinlock tries to occupy a spin - lock variable. If the function returns, either the lock is successfully taken or an error has occurred. The spinlock mechanism is an active polling mechanism. The function does not cause a de - scheduling.
StatusType GetSpinlock (SpinlockIdType SpinlockId);This service increments a software counter.
StatusType IncrementCounter (CounterType CounterID);This service initializes the data structures of the IOC. Tags: atp.Status=draft
void IocInit (void);This service modifies a given memory location () with the formula: * = ((* & ) | )
StatusType ModifyPeripheral16 (AreaIdType Area, uint16* Address, uint16 Clearmask, uint16 Setmask);This service modifies a given memory location () with the formula: * = ((* & ) | )
StatusType ModifyPeripheral32 (AreaIdType Area, uint32* Address, uint32 Clearmask, uint32 Setmask);This service modifies a given memory location () with the formula: * = ((* & ) | )
StatusType ModifyPeripheral8 (AreaIdType Area, uint8* Address, uint8 Clearmask, uint8 Setmask);This service switches the processing from one schedule table to another schedule table.
StatusType NextScheduleTable (ScheduleTableType ScheduleTableID_From, ScheduleTableType ScheduleTableID_To);The protection hook is always called if a serious error occurs. E.g. exceeding the worst case execution time or violating against the memory protection.
ProtectionReturnType ProtectionHook (StatusType Fatalerror);This service returns the content of a given memory location (
StatusType ReadPeripheral16 (AreaIdType Area, const uint16* Address, uint16* ReadValue);This service returns the content of a given memory location (
StatusType ReadPeripheral32 (AreaIdType Area, const uint32* Address, uint32* ReadValue);This service returns the content of a given memory location (
StatusType ReadPeripheral8 (AreaIdType Area, const uint8* Address, uint8* ReadValue);Release Spinlock releases a spinlock variable that was occupied before. Before terminating a TASK all spinlock variables that have been occupied with Get Spinlock() shall be released. Before calling Wait EVENT all Spinlocks shall be released.
StatusType ReleaseSpinlock (SpinlockIdType SpinlockId);Asynchronous version of the Set Event() function. Intended to be used for cross core event setting. Possible errors are not returned to the caller, but may be reported via error hooks.
void SetEventAsyn (TaskType id, EventMaskType m);This service stops synchronization of a schedule table.
StatusType SetScheduletableAsync (ScheduleTableType ScheduleTableID);After this service the OS on all AUTOSAR cores is shut down. Allowed at TASK level and ISR level and also internally by the OS. The function will never return. The function will force other cores into a shutdown.
void ShutdownAllCores (StatusType Error);It is not supported to call this function after Start OS(). The function starts the core specified by the parameter Core ID. The OUT parameter allows the caller to check whether the operation was successful or no t. If a core is started by means of this function Start OS shall be called on the core.
void StartCore (CoreIdType CoreID, StatusType* Status);The function start s the core specified by the parameter Core ID. It is allowed to call this function after Start OS(). The OUT parameter allows the caller to check whether the operation was successful or not. It is not allowed to call Start OS on cores activated by Start No n Autosar Core. Otherwise the behaviour is unspecified.
void StartNonAutosarCore (CoreIdType CoreID, StatusType* Status);This service starts the processing o f a schedule table at an absolute value "Start" on the underlying counter.
StatusType StartScheduleTableAbs (ScheduleTableType ScheduleTableID, TickType Start);This service starts the processing of a schedule table at "Offset" relative to the "Now" value on the underlying counter.
StatusType StartScheduleTableRel (ScheduleTableType ScheduleTableID, TickType Offset);This service starts an explicitly synchronized schedule table synchronously.
StatusType StartScheduleTableSynchron (ScheduleTableType ScheduleTableID);This service cancels the processing of a schedule table immediately at any point while the schedule table is running.
StatusType StopScheduleTable (ScheduleTableType ScheduleTableID);Service SyncScheduleTable.
StatusType SyncScheduleTable (ScheduleTableType ScheduleTableID, TickType Value);Service TerminateApplication.
StatusType TerminateApplication (ApplicationType Application, RestartType RestartOption);Try To Get Spinlock has the same functionality as Get Spinlock with the difference that if the spinlock is already occupied by a TASK on a d ifferent core the function sets the OUT parameter "Success" and returns with E_ OK.
StatusType TryToGetSpinlock (SpinlockIdType SpinlockId, TryToGetSpinlockType* Success);This service writes the to a given memory location (). Available vi a Os.h
StatusType WritePeripheral16 (AreaIdType Area, uint16* Address, uint16 WriteValue);This service writes the to a given memory location ().
StatusType WritePeripheral32 (AreaIdType Area, uint32* Address, uint32 WriteValue);This service writes the to a given memory location (). Available vi a Os.h
StatusType WritePeripheral8 (AreaIdType Area, uint8* Address, uint8 WriteValue);This type holds information how a specific memory region can be accessed.
This data type points to location where a Application State Type can be stored.
This data type identifies the state of an OS - Application. AUTOSAR CP R20 - o f Document ID : AUTOSAR_SWS_OS
This data type identifies the OS - Application.
App Mode of the core shall be inherited from another core.
Area Id Type identifies a peripheral area and is used by the API functions: Read Peripheral X, Write Peripheral X and Modify Peripheral X AUTOSAR CP R20 - o f Document ID : AUTOSAR_SWS_OS
Core Id Type is a scalar that allows identifying a single core. The Core Id Type shall represent t he logical Core ID
This data type identifies a counter.
This data type represents an event mask for extended tasks.
typedef uint32 EventMaskType;This data type identifies the idle mode behavior.
This data type identifies an interrupt service routine (ISR).
This data type holds the size (in bytes) of a memory region.
This data type is a pointer which is able to point to any location in the MCU address space.
This data type identifies if an OS - Application has access to an object.
This data type identifies an object.
This data type is used for values returned by the conversion macro (see SWS_ Os_00393) OS_ TICKS2_(). AUTOSAR CP R20 - o f Document ID : AUTOSAR_SWS_OS
This data type identifies a value which controls further actions of the OS on return from the protection hook.
This data type defines the use of a Restart Task after terminating an OS - Application.
This data type points to a variable of the data type Schedule Table Status Type.
This type describes the status of a schedule. The status can be one of the following: o The schedule table is not started (SCHEDULETABLE_ STOPPED) o The schedule table will be started after the end of currently running schedule table (sched ule table was used in Next Schedule Table() service) (SCHEDULETABLE_ NEXT) o The schedule table uses explicit synchronization, has been started and is waiting for the global time. (SCHEDULETABLE_ WAITING) o The schedule table is running, but is currently n ot synchronous to a global time source (SCHEDULETABLE_ RUNNING) o The schedule table is running and is synchronous to a global time source (SCHEDULETABLE_ RUNNING_ AND_ SYNCHRONOUS)
This data type identifies a schedule table.
Spinlock Id Type identifies a spinlock instance and is used by the API functions: Get Spinlock, Release Spinlock and Try To Get Spinlock.
This data type represents standard OSEK OS status codes (e.g. E_OK, E_OS_ACCESS).
typedef uint8 StatusType;-
The total number of cores
This data type identifies a trusted function.
This data type points to a structure which holds the arguments for a call to a trusted function.
The Try To Get Spinlock Type indicates if the spinlock has been occupied or not.
gemini-3.8-flash-medium· 2026-10-13