AUTOSAR OS

Über den Systemservice CallTrustedFunction (Service-ID 0x02) kann eine vertrauenswürdige oder nicht-vertrauenswürdige OS-Application eine definierte Trusted Function zur Ausführung aufrufen [SWS_Os_00097]. Die Schnittstelle wird über den Header Os.h bereitgestellt [SWS_Os_00097].

Der Aufruf erfordert die Übergabe von zwei Eingabeparametern [SWS_Os_00097]:

• FunctionIndex (Typ TrustedFunctionIndexType): Bezeichnet den Index der aufzurufenden Funktion [SWS_Os_00097].
• FunctionParams (Typ TrustedFunctionParameterRefType): Übergibt einen Zeiger auf die Parameter der Zielfunktion; werden keine Argumente benötigt, muss zwingend ein NULL-Zeiger übergeben werden [SWS_Os_00097].

Hinsichtlich des Zeitverhaltens richtet sich die Ausführung nach der Zielroutine: Ist die aufgerufene Funktion synchron, verhält sich auch der Service synchron [SWS_Os_00097]. Die Funktion ist reentrant implementiert, kann jedoch während der Ausführung ein Rescheduling des Betriebssystems herbeiführen [SWS_Os_00097].

Als Rückgabewert liefert der Dienst einen Statuswert vom Typ StatusType [SWS_Os_00097]:

• E_OK: Die Ausführung war erfolgreich und fehlerfrei [SWS_Os_00097].
• E_OS_SERVICEID: Dem übergebenen Index ist keine gültige Funktion zugeordnet [SWS_Os_00097].

Die Funktion CheckISRMemoryAccess ist ein synchroner und reentranter Systemdienst des OS-Moduls ([SWS_Os_00512]). Sie dient dazu, die Speicherzugriffsrechte einer spezifizierten ISR für einen bestimmten Speicherbereich zur Laufzeit zu überprüfen.

Verwendung und Parameter

Der Aufruf von CheckISRMemoryAccess erwartet drei Eingabeparameter ([SWS_Os_00512]):

• ISRID: Referenz auf die zu prüfende ISR (ISRType).
• Address: Startadresse des zu untersuchenden Speicherbereichs (MemoryStartAddressType).
• Size: Größe des Speicherbereichs (MemorySizeType).

Als Rückgabewert liefert der Dienst den Typ AccessType. Dieser Rückgabewert enthält die Zugriffsrechte (Lesen, Schreiben, Ausführen) auf den spezifizierten Bereich und gibt zusätzlich Auskunft darüber, ob der Speicherbereich Teil des Stack-Bereichs ist ([SWS_Os_00512]).

Nebenläufigkeit und Integration

Gemäß Spezifikation besitzt die Funktion die Service-ID 0x03 und ist als reentrant deklariert ([SWS_Os_00512]). Sie steht über den Header Os.h zur Verfügung ([SWS_Os_00512]). Spezifische Fehlercodes oder explizite Rückmeldungen an DET/DEM werden im vorliegenden Spezifikationsauszug nicht aufgeführt.

Die Funktion CheckTaskMemoryAccess stellt einen synchronen Dienst des Betriebssystems dar, der über den Header Os.h bereitgestellt wird und die Service-ID 0x04 besitzt [SWS_Os_00513]. Sie dient dazu, die Speicherzugriffsrechte eines spezifischen Tasks für ein bestimmtes Speichersegment abzufragen [SWS_Os_00513].

Parameter und Rückgabewerte

Beim Aufruf nimmt der Dienst drei Eingangsparameter entgegen [SWS_Os_00513]:

• Task ID (vom Typ TaskType): Referenz auf den Task, dessen Zugriffsrechte überprüft werden sollen.
• Address (vom Typ MemoryStartAddressType): Die Startadresse des zu prüfenden Speicherbereichs.
• Size (vom Typ MemorySizeType): Die Größe des zu überprüfenden Speicherbereichs.

Als Rückgabewert liefert der Dienst eine Variable des Typs AccessType [SWS_Os_00513]. Dieser Rückgabewert enthält die Information, ob der angegebene Speicherbereich für den Task mit Schreib-, Lese- oder Ausführungsrechten zugänglich ist, und gibt zusätzlich an, ob der Bereich Teil des Stack-Bereichs ist [SWS_Os_00513]. Zusätzliche Fehlercodes oder DET-Meldungen sind für diesen Service nicht spezifiziert.

Nebenläufigkeit und Zusammenspiel

Der Dienst ist als reentrant spezifiziert und kann daher in nebenläufigen Ausführungskontexten sicher verwendet werden [SWS_Os_00513]. Während CheckTaskMemoryAccess die Berechtigungen für Speicherbereiche zur Laufzeit abfragt, definiert der AUTOSAR-Standard in ARTI-Modulbeschreibungen Schnittstellen und Datenstrukturen, über die Debugging-Werkzeuge Zustände und Attribute von Betriebssystemobjekten erfassen und auswerten können [SWS_Os_00829].

Verwendung und Semantik

Die Funktion CheckObjectAccess ([SWS_Os_00256]) ermittelt synchron, ob eine bestimmte OS-Application die Berechtigung besitzt, die ID eines Betriebssystemobjekts in API-Aufrufen zu verwenden. Zur Identifikation der Anwendung dient der Eingangsparameter ApplID vom Typ ApplicationType ([SWS_Os_00256]). Über ObjectType (Typ ObjectTypeType) wird festgelegt, welche Art von Objekt geprüft werden soll; unterstützt werden Task, Resource, Counter, Alarm und Schedule Table ([SWS_Os_00256]). Als dritter Parameter folgt das zu untersuchende Objekt selbst über die variable Parameterliste ... ([SWS_Os_00256]).

Als Rückgabewert liefert die Funktion den Typ ObjectAccessType: Ist der Zugriff der Anwendung auf das Objekt gestattet, wird ACCESS zurückgegeben, andernfalls NO_ACCESS ([SWS_Os_00256]). Der Dienst ist über den Header Os.h deklariert und besitzt die Service-ID 0x05 ([SWS_Os_00256]).

Nebenläufigkeit, Fehlerbehandlung und Zusammenspiel

Der Service ist als reentrant spezifiziert und kann daher in nebenläufigen Ausführungskontexten aufgerufen werden ([SWS_Os_00256]). Spezifische Fehlercodes, Rückgabewerte für Fehlerzustände oder Meldungen an DET oder DEM sind für diese Funktion in der Spezifikation nicht vorgesehen ([SWS_Os_00256]).

Interpretation: Das variable Argument ... dürfte in der Implementierung die konkrete Kennung des Objekts passend zu ObjectType übergeben. Frage Q-5cb52ff94bb07826 (offen) Die geprüften Betriebssystemobjekte spiegeln sich auch in den ARTI-Debugging-Informationen wider, welche Attribute und Zustände von Betriebssystemobjekten erfassen und auswerten ([SWS_Os_00829]).

Verwendung

Die synchrone Systemfunktion CheckObjectOwnership dient dazu festzustellen, zu welcher OS-Application ein bestimmtes Betriebssystemobjekt gehört [SWS_Os_00017]. Zu den über diesen Dienst abfragbaren Objekten gehören Tasks, Interrupt Service Routines (ISRs), Counter, Alarme sowie Schedule Tables [SWS_Os_00017].

Die Funktion ist über die Header-Datei Os.h verfügbar und besitzt die Service-ID 0x06 [SWS_Os_00017]. Bei der Verwendung nimmt die Funktion zwei Eingabeparameter entgegen:

• ObjectType: Kennzeichnet als Eingabeparameter vom Typ ObjectTypeType die Art des nachfolgend übergebenen Betriebssystemobjekts [SWS_Os_00017].
• ...: Übergibt das konkrete, zu untersuchende Objekt an den Dienst [SWS_Os_00017].

Als Rückgabewert liefert die Funktion den Datentyp ApplicationType [SWS_Os_00017]. Dieser enthält die Kennung derjenigen OS-Application, welcher das überprüfte Objekt zugeordnet ist [SWS_Os_00017].

Fehlerbehandlung und Ausführungseigenschaften

Sofern das abgefragte Objekt im System nicht existiert, liefert der Dienst den Rückgabewert INVALID_OSAPPLICATION zurück [SWS_Os_00017].

Hinsichtlich des Nebenläufigkeitsverhaltens ist CheckObjectOwnership als reentrant spezifiziert und arbeitet vollständig synchron [SWS_Os_00017]. Ein- und Ausgabeparameter (inout oder out) existieren neben dem Rückgabewert nicht [SWS_Os_00017].

Verwendung und Parameter

Der Systemdienst StartScheduleTableRel startet die Verarbeitung einer Schedule-Tabelle relativ zum aktuellen Zählerwert („Now“) des zugrundeliegenden Counters [SWS_Os_00347]. Der Aufruf wird synchron ausgeführt und ist über die Schnittstelle Os.h mit der Service-ID 0x07 verfügbar [SWS_Os_00347].

• ScheduleTableID (Eingabe, ScheduleTableType): Bezeichner der zu startenden Schedule-Tabelle [SWS_Os_00347].
• Offset (Eingabe, TickType): Relative Anzahl an Zählertakten auf dem Counter, bevor die Verarbeitung der Tabelle beginnt [SWS_Os_00347].

Rückgabewerte und Fehlerbehandlung

Die Funktion gibt einen Statuscode vom Typ StatusType zurück [SWS_Os_00347]:

• E_OK: Die Schedule-Tabelle wurde fehlerfrei gestartet [SWS_Os_00347].
• E_OS_STATE: Die angegebene Schedule-Tabelle wurde bereits gestartet [SWS_Os_00347].
• E_OS_ID (nur bei Status EXTENDED): Die angegebene ScheduleTableID ist ungültig [SWS_Os_00347].
• E_OS_VALUE (nur bei Status EXTENDED): Der Parameter Offset ist gleich 0 oder überschreitet den Wert (OsCounterMaxAllowedValue - InitialOffset) [SWS_Os_00347].

Nebenläufigkeit und Einschränkungen

Die Funktion ist reentrant spezifiziert [SWS_Os_00347]. Es existieren keine Aus- oder Ein-/Ausgabe-Parameter [SWS_Os_00347].

Die synchrone und reentrante Funktion StartScheduleTableAbs dient dem Starten einer Ablauf-Tabelle (Schedule Table) zu einem vorgegebenen absoluten Zählerstand auf dem zugrunde liegenden Zähler ([SWS_Os_00358]). Der Dienst ist über den Header Os.h verfügbar und wird über die Service-ID 0x08 identifiziert ([SWS_Os_00358]).

Beim Aufruf werden zwei Eingangsparameter übergeben ([SWS_Os_00358]):

• ScheduleTableID: Kennung der zu startenden Schedule Table.
• Start: Absoluter Zähler-Tickwert, an dem die Schedule Table gestartet wird.

Als Rückgabewert liefert die Funktion den Status vom Typ StatusType ([SWS_Os_00358]):

• E_OK: Der Startvorgang war erfolgreich.
• E_OS_STATE: Die angegebene Schedule Table wurde bereits zuvor gestartet.
• E_OS_ID: Die übergebene ScheduleTableID ist ungültig (wird nur im Status EXTENDED zurückgegeben).
• E_OS_VALUE: Der Wert von Start überschreitet den maximal zulässigen Zählerwert OsCounterMaxAllowedValue (wird nur im Status EXTENDED zurückgegeben).

Hinsichtlich des Zusammenspiels können der Zustand und die dynamischen Attribute von Betriebssystem-Objekten wie Schedule Tables über ARTI-Modulbeschreibungen von angeschlossenen Debug-Werkzeugen ausgewertet und dargestellt werden ([SWS_Os_00829]). Interpretation: Der Aufrufkontext dürfte vor allem Task-Ebenen umfassen, da im Spezifikationsauszug keine explizite Einschränkung angegeben ist. Frage Q-213de28d0345ccb1 (offen)

Die synchrone Systemfunktion StopScheduleTable ([SWS_Os_00006]) bricht die Abarbeitung einer laufenden Schedule-Tabelle zu jedem beliebigen Verarbeitungszeitpunkt unmittelbar ab. Der Dienst ist im Header Os.h deklariert und besitzt die Service-ID 0x09 ([SWS_Os_00006]). Als einziger Eingangsparameter dient ScheduleTableID vom Typ ScheduleTableType, welcher die zu stoppende Schedule-Tabelle spezifiziert; Ein-/Ausgangs- oder reine Ausgangsparameter existieren nicht ([SWS_Os_00006]).

Der synchrone Aufruf liefert als Rückgabewert einen Statuscode vom Typ StatusType ([SWS_Os_00006]):

• E_OK: Die Verarbeitung der Schedule-Tabelle wurde fehlerfrei gestoppt ([SWS_Os_00006]).
• E_OS_NOFUNC: Die angegebene Schedule-Tabelle befand sich bereits im Zustand gestoppt ([SWS_Os_00006]).
• E_OS_ID: Die übergebene Kennung ScheduleTableID ist ungültig. Dieser Rückgabewert wird laut Spezifikation nur im Status EXTENDED erzeugt ([SWS_Os_00006]).

Die Funktion ist als reentrant definiert ([SWS_Os_00006]). Interpretation: Angesichts der deklarierten Reentranz dürfte der synchrone Aufruf aus mehreren OS-Kontexten zulässig sein, obgleich konkrete Kontextbeschränkungen im vorliegenden Spezifikationsauszug fehlen. Frage Q-9cb147c4bc7dba7e (offen) Zur Laufzeitüberwachung können Zustand und dynamische Attribute von OS-Objekten wie Schedule-Tabellen über ARTI-Beschreibungsdateien an angeschlossene Debug- und Analysewerkzeuge übermittelt werden ([SWS_Os_00829]).

Die Funktion NextScheduleTable dient dem synchronen Umschalten der Verarbeitung von einer laufenden Schedule-Tabelle auf eine Folgetabelle [SWS_Os_00191]. Der Service ist reentrant ausgelegt und über den Header Os.h deklariert [SWS_Os_00191].

Parameter und Aufruf

Dem Aufruf werden zwei Eingabeparameter vom Typ ScheduleTableType übergeben [SWS_Os_00191]:

• ScheduleTableID_From: Kennung der gegenwärtig verarbeiteten Schedule-Tabelle [SWS_Os_00191].
• ScheduleTableID_To: Kennung der Schedule-Tabelle, welche die nachfolgende Folge von Ablaufpunkten (Expiry Points) bereitstellt [SWS_Os_00191].

Rückgabewerte und Fehlerbehandlung

Die Funktion liefert einen Statuswert vom Typ StatusType zurück [SWS_Os_00191]:

• E_OK: Der Wechselauftrag wurde fehlerfrei abgesetzt [SWS_Os_00191].
• E_OS_ID: Wird ausschließlich bei konfiguriertem EXTENDED-Status zurückgegeben, falls mindestens eine der übergebenen Tabellenkennungen ungültig ist [SWS_Os_00191].
• E_OS_NOFUNC: Die Ausgangstabelle ScheduleTableID_From befindet sich nicht im gestarteten Zustand [SWS_Os_00191].
• E_OS_STATE: Die Zieltabelle ScheduleTableID_To ist bereits aktiv gestartet oder bereits als Folgetabelle vorgemerkt [SWS_Os_00191].

Zusammenspiel und Diagnose

Zur Beobachtung und Analyse des Betriebssystems unterstützen ARTI-Modulbeschreibungen entsprechende ORTI-Container, womit Debug-Werkzeuge unter anderem dynamische Zustände von Betriebssystem-Objekten auswerten und darstellen können [SWS_Os_00829].

Verwendung

Der Systemdienst StartScheduleTableSynchron dient dazu, eine explizit synchronisierte Schedule-Tabelle synchron zu starten [SWS_Os_00201]. Die Funktion ist in der Header-Datei Os.h deklariert und besitzt die Service-ID 0x0b [SWS_Os_00201]. Als einzigen Übergabeparameter erwartet die Funktion den Eingabeparameter ScheduleTableID vom Typ ScheduleTableType, der die zu startende Tabelle eindeutig referenziert [SWS_Os_00201]. Ein-Ausgabe- oder reine Ausgabe-Parameter sind nicht vorhanden [SWS_Os_00201]. Die Verarbeitung erfolgt synchron und liefert einen Rückgabewert vom Typ StatusType zurück [SWS_Os_00201].

Fehlerbehandlung

Im fehlerfreien Ablauf gibt der Funktionsaufruf den Statuscode E_OK zurück [SWS_Os_00201]. Bei Fehlern sind folgende Rückgabewerte spezifiziert:

• E_OS_STATE: Die angegebene Schedule-Tabelle befindet sich bereits im gestarteten Zustand und kann nicht erneut synchron gestartet werden [SWS_Os_00201].
• E_OS_ID: Die übergebene ScheduleTableID ist ungültig [SWS_Os_00201]. Diese Fehlerprüfung und Fehlermeldung ist ausschließlich im EXTENDED-Status aktiv [SWS_Os_00201].

Nebenläufigkeit und Einschränkungen

Die Funktion ist als reentrant spezifiziert [SWS_Os_00201]. Da der wiederholte Aufruf für eine bereits aktive Tabelle mit E_OS_STATE abgewiesen wird, muss der Aufrufer sicherstellen, dass die Zieltabelle vor dem Aufruf nicht bereits läuft [SWS_Os_00201].

Zusammenspiel

Zustandsübergänge und dynamische Eigenschaften von Betriebssystemobjekten können für Test- und Diagnosewerkzeuge über ARTI-Modulbeschreibungsdateien und ORTI-Container nachvollzogen werden [SWS_Os_00829]. Externe Debugger nutzen diese Beschreibungen, um den internen Status der OS-Objekte zur Laufzeit auszuwerten [SWS_Os_00829].

Der synchrone und reentrante Betriebssystemdienst SyncScheduleTable dient dazu, einer Schedule-Tabelle einen Zählerwert zu übergeben und den Synchronisationsprozess zu starten ([SWS_Os_00199]). Die Funktion wird über die Header-Datei Os.h bereitgestellt ([SWS_Os_00199]).

Parameter und Rückgabewerte

Die Funktion erwartet zwei Eingabeparameter ([SWS_Os_00199]):

• Schedule Table ID: Kennung der zu synchronisierenden Schedule-Tabelle vom Typ ScheduleTableType ([SWS_Os_00199]).
• Value: Aktueller Zählerstand des Synchronisationszählers vom Typ TickType ([SWS_Os_00199]).

Der Rückgabewert vom Typ StatusType signalisiert mit E_OK die fehlerfreie Ausführung ([SWS_Os_00199]).

Fehlerbehandlung und Randbedingungen

Befindet sich die Tabelle zum Aufrufzeitpunkt im Zustand SCHEDULETABLE_STOPPED, wird der Fehler E_OS_STATE zurückgegeben ([SWS_Os_00199]). Ist das Betriebssystem im EXTENDED-Status konfiguriert, greifen weitere Prüfungen ([SWS_Os_00199]):

• E_OS_ID: Die angegebene Tabellen-ID ist ungültig oder die Tabelle kann nicht synchronisiert werden, weil Os Schedule Tbl Sync Strategy unkonfiguriert oder auf IMPLICIT gesetzt ist ([SWS_Os_00199]).
• E_OS_VALUE: Der übergebene Zählerwert Value liegt außerhalb des zulässigen Bereichs ([SWS_Os_00199]).

Zusammenspiel und Diagnose

Zustände und dynamische Attribute von Betriebssystemobjekten wie Schedule-Tabellen können über ARTI-Modulbeschreibungen und ORTI-Container durch angeschlossene Debug- und Diagnose-Werkzeuge ausgewertet werden ([SWS_Os_00829]).

Verwendung

Die synchrone Betriebssystemfunktion IncrementCounter dient dem expliziten Weiterschalten eines Software-Zählers [SWS_Os_00399]. Sie erwartet als Eingangsparameter die Kennung CounterID vom Typ CounterType, modifiziert keine weiteren Parameter und steht über den Header Os.h zur Verfügung [SWS_Os_00399]. Zu beachten ist, dass der Aufruf ein sofortiges Rescheduling des Betriebssystems veranlassen kann [SWS_Os_00399].

Fehlerbehandlung

Der Rückgabewert vom Typ StatusType gibt Aufschluss über den Erfolg der Operation: Im regulären Betriebsfall meldet E_OK die fehlerfreie Ausführung [SWS_Os_00399]. Bei aktivierter erweiterter Statusprüfung (EXTENDED-Status) liefert der Dienst E_OS_ID zurück, falls eine ungültige Zähler-ID angegeben wurde oder wenn der referenzierte Zähler in Hardware realisiert ist und sich folglich nicht per Software inkrementieren lässt [SWS_Os_00399].

Nebenläufigkeit und Diagnose

Die Funktion ist reentrant ausgelegt und darf somit nebenläufig aufgerufen werden [SWS_Os_00399]. Ein mögliches Rescheduling dürfte Interpretation: eintreten, wenn das Weiterschalten des Zählers abhängige Aktionen wie Alarmabläufe oder Task-Aktivierungen auslöst. Frage Q-9004b5ced9b96230 (offen) Zur Beobachtung von Betriebssystemobjekten wie Zählern sowie deren dynamischem Zustand unterstützen ARTI-Modulbeschreibungen angeschlossene Analysewerkzeuge bei der Laufzeitüberwachung [SWS_Os_00829].

Die synchrone und reentrante Funktion TerminateApplication dient dem Beenden einer OS-Application und steht über die Header-Datei Os.h zur Verfügung [SWS_Os_00258]. Der Aufruf ist aus dem Kontext eines Tasks, einer Kategorie-2-ISR sowie eines anwendungsspezifischen Error-Hooks zulässig [SWS_Os_00258].

Als Eingangsparameter werden die Kennung der Zielanwendung (Application) und das Neustartverhalten (Restart Option) übergeben [SWS_Os_00258]:

• Gehört der Aufrufer selbst zu der in Application angegebenen Anwendung, führt die Ausführung zu einer Selbstterminierung [SWS_Os_00258].
• Über Restart Option wird festgelegt, ob die OS-Application im Anschluss neu gestartet werden soll (RESTART) oder nicht (NO_RESTART) [SWS_Os_00258].

Die Funktion gibt einen Statuswert vom Typ StatusType zurück [SWS_Os_00258]:

• E_OK signalisiert eine fehlerfreie Terminierung [SWS_Os_00258].
• E_OS_STATE zeigt an, dass der aktuelle Zustand von Application das Beenden nicht erlaubt [SWS_Os_00258].
• Im EXTENDED-Status werden zusätzliche Fehlerprüfungen durchgeführt: E_OS_ID bei einer ungültigen Anwendungs-ID, E_OS_VALUE bei einem ungültigen Parameterwert für Restart Option sowie E_OS_ACCESS, falls dem Aufrufer die Berechtigung zum Beenden von Application fehlt [SWS_Os_00258].

Verwendung

Der synchrone Systemdienst AllowAccess (Service-ID 0x13) dient dazu, den Zustand der eigenen OS-Application von APPLICATION_RESTARTING auf APPLICATION_ACCESSIBLE zu setzen ([SWS_Os_00501]). Die Funktion ist über die Header-Datei Os.h verfügbar, erwartet keine Übergabeparameter und gibt einen Statuswert vom Typ StatusType zurück ([SWS_Os_00501]). Bei erfolgreicher Durchführung der Zustandsänderung liefert der Aufruf den Rückgabewert E_OK ([SWS_Os_00501]).

Fehlerbehandlung und Nebenläufigkeit

Falls sich die aufrufende OS-Application nicht im Zustand APPLICATION_RESTARTING befindet, schlägt die Ausführung fehl und die Funktion gibt den Fehlerwert E_OS_STATE zurück ([SWS_Os_00501]). Spezifische DET- oder DEM-Meldungen sind in der Spezifikation für diesen Dienst nicht definiert. Hinsichtlich des Nebenläufigkeitsverhaltens ist die Funktion als reentrant eingestuft und kann daher sicher in parallelen Abläufen ausgeführt werden ([SWS_Os_00501]).

Zusammenspiel und Diagnose

Interpretation: Der Aufruf dürfte typischerweise am Ende einer applikationseigenen Wiederanlaufphase erfolgen, sobald sämtliche Vorbereitungen abgeschlossen sind und andere Anwendungen wieder auf die Ressourcen zugreifen dürfen. Frage Q-f43a3f702d5d2428 (offen) Die dynamischen Zustände des Betriebssystems und der zugehörigen OS-Objekte können im Rahmen der Systemdiagnose über standardisierte ARTI-Beschreibungsdateien und zugehörige Debug-Tools ausgewertet und visualisiert werden ([SWS_Os_00829]).

Die synchrone Funktion StartCore startet den über den Parameter Core ID spezifizierten Prozessorkern [SWS_Os_00676]. Die Funktion besitzt keinen direkten Rückgabewert, sondern übergibt das Ergebnis der Ausführung über den OUT-Parameter Status an den Aufrufer [SWS_Os_00676]. Wurde ein Kern mittels dieser Funktion gestartet, muss auf dem betreffenden Kern nachfolgend Start OS aufgerufen werden [SWS_Os_00676].

Für den Aufrufkontext sowie die Nebenläufigkeit gelten feste Einschränkungen: StartCore ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Os_00676]. Ein Aufruf nach dem Starten des Betriebssystems über Start OS() wird nicht unterstützt [SWS_Os_00676]. Der Dienst ist synchron implementiert und wird über die Header-Datei Os.h mit der Service-ID 0x17 bereitgestellt [SWS_Os_00676].

Die Fehlerbehandlung erfolgt über den Parameter Status, der je nach Status-Konfiguration folgende Werte annehmen kann [SWS_Os_00676]:

• Im Standard-Status zeigt E_OK eine fehlerfreie Ausführung an [SWS_Os_00676].
• Im erweiterten Status (extended status) bestätigt E_OK ebenfalls einen erfolgreichen Start [SWS_Os_00676].
• E_OS_ID meldet, dass die übergebene Core ID ungültig ist [SWS_Os_00676].
• E_OS_ACCESS signalisiert einen unzulässigen Aufruf nach dem Start des Betriebssystems [SWS_Os_00676].
• E_OS_STATE zeigt an, dass der angeforderte Prozessorkern bereits aktiviert ist [SWS_Os_00676].

Verwendung und Aufrufkontext

Die synchrone und nicht reentrante Funktion StartNonCore startet den über den Parameter CoreID spezifizierten Prozessorkern [SWS_Os_00682]. Sie darf nach dem Start des Betriebssystems über StartOS() aufgerufen werden und ist über die Header-Datei Os.h verfügbar [SWS_Os_00682]. Über den Ausgangsparameter Status kann der Aufrufer überprüfen, ob der Startvorgang erfolgreich war [SWS_Os_00682].

Fehlerbehandlung und Statuswerte

Die Funktion besitzt keinen direkten Rückgabewert, meldet das Ergebnis der Ausführung jedoch über den Zeigerparameter Status zurück [SWS_Os_00682]:

• E_OK: Die Operation wurde erfolgreich und fehlerfrei ausgeführt [SWS_Os_00682].
• E_OS_ID: Die angegebene CoreID ist ungültig (im Standard-Status) [SWS_Os_00682].
• E_OS_STATE: Der angegebene Prozessorkern ist bereits aktiviert (im Standard-Status) [SWS_Os_00682].

Einschränkungen und Reihenfolgebedingungen

Als nicht reentrante Schnittstelle darf StartNonCore nicht nebenläufig ausgeführt werden [SWS_Os_00682]. Zudem gilt die strikte Vorgabe, dass auf Prozessorkernen, die über diese Funktion aktiviert wurden, keinesfalls StartOS aufgerufen werden darf; andernfalls ist das Systemverhalten unpezifiziert [SWS_Os_00682].

Die synchrone und reentrante Betriebssystemfunktion GetSpinlock ([SWS_Os_00686]) dient der Belegung einer Spinlock-Variablen über den Übergabeparameter SpinlockId (Typ SpinlockIdType). Bei der Ausführung nutzt die Funktion einen aktiven Polling-Mechanismus („busy waiting“), ohne dass ein De-Scheduling des aufrufenden Tasks ausgelöst wird ([SWS_Os_00686]).

Die Funktion kehrt erst zurück, wenn die Sperre erfolgreich akquiriert wurde oder ein Fehler aufgetreten ist. Als Rückgabewert liefert GetSpinlock den StatusType ([SWS_Os_00686]):

• E_OK: Die Sperre wurde fehlerfrei belegt (im Standard- und Extended-Status).
• E_OS_ID: Die übergebene SpinlockId ist ungültig (nur im Extended-Status).
• E_OS_INTERFERENCE_DEADLOCK: Ein Task versucht das Spinlock zu belegen, während es bereits durch einen Task auf demselben Core belegt ist (nur im Extended-Status).
• E_OS_NESTING_DEADLOCK: Ein Task versucht das Spinlock anzufordern, während ein Task desselben Cores bereits ein anderes Spinlock hält, was einen Deadlock verursachen könnte (nur im Extended-Status).
• E_OS_ACCESS: Auf das angegebene Spinlock kann nicht zugegriffen werden (nur im Extended-Status).

Im Rahmen der Systembeobachtung und Fehleranalyse stellt das Betriebssystem dynamische Zustandsinformationen über OS-Objekte bereit, welche gemäß [SWS_Os_00829] über ARTI- und ORTI-Container für Debug-Werkzeuge auswertbar sind; vermutlich lassen sich hierüber auch Blockadesituationen an Spinlocks nachvollziehen. Frage Q-bac194d4132f6e88 (offen)

Die synchrone und reentrante Funktion ReleaseSpinlock gibt eine zuvor belegte Spinlock-Variable frei ([SWS_Os_00695]). Über den Übergabeparameter SpinlockId vom Typ SpinlockIdType wird die freizugebende Spinlock-Instanz spezifiziert ([SWS_Os_00695]).

Reihenfolgebedingungen und Einschränkungen

Für den Aufruf gelten strikte zeitliche und strukturelle Vorgaben ([SWS_Os_00695]):

• Vor dem Beenden eines Tasks müssen sämtliche zuvor mittels GetSpinlock() belegten Spinlock-Variablen wieder freigegeben werden ([SWS_Os_00695]).
• Vor dem Aufruf von WaitEvent sind ausnahmslos alle gehaltenen Spinlocks freizugeben ([SWS_Os_00695]).
• Die Freigabe muss in der korrekten Schachtelungsreihenfolge erfolgen; ein Freigabeversuch bei noch belegten übergeordneten Spinlocks oder Ressourcen schlägt fehl ([SWS_Os_00695]).

Rückgabewerte und Fehlerbehandlung

Im Erfolgsfall liefert der Dienst sowohl im Standard- als auch im erweiterten Status E_OK zurück ([SWS_Os_00695]). Im erweiterten Status (Extended Status) sind spezifische Fehlercodes definiert ([SWS_Os_00695]):

• E_OS_ID: Die übergebene SpinlockId ist ungültig ([SWS_Os_00695]).
• E_OS_STATE: Der Spinlock ist nicht durch den aufrufenden Task belegt ([SWS_Os_00695]).
• E_OS_ACCESS: Auf den Spinlock kann nicht zugegriffen werden ([SWS_Os_00695]).
• E_OS_NOFUNC: Versuch, den Spinlock freizugeben, während zuvor noch ein anderer Spinlock oder eine Ressource freigegeben werden muss ([SWS_Os_00695]).

Die Funktion steht über den Header Os.h zur Verfügung ([SWS_Os_00695]). ARTI-Beschreibungsdateien unterstützen ORTI-Container zur dynamischen Zustands- und Performance-Auswertung von Betriebssystemobjekten ([SWS_Os_00829]).

Die synchrone und reentrante Betriebssystemfunktion TryToGetSpinlock dient dem nicht-blockierenden Belegen einer Spinlock-Instanz über den Header Os.h [SWS_Os_00703]. Sie übernimmt dieselbe Grundfunktionalität wie GetSpinlock, wartet jedoch nicht aktiv, falls der angeforderte Spinlock bereits durch einen TASK auf einem anderen Core belegt ist [SWS_Os_00703].

Parameter und Rückgabewerte

• SpinlockId (Eingabe): Referenziert die konkrete Spinlock-Instanz, die gesperrt werden soll [SWS_Os_00703].
• Success (Ausgabe): Zeigt über den Typ TryToGetSpinlockType* an, ob der Lock belegt werden konnte oder nicht [SWS_Os_00703]. Ist die Sperre auf einem anderen Core besetzt, setzt die Funktion diesen Parameter entsprechend und kehrt mit E_OK zurück [SWS_Os_00703].
• Rückgabewert: Liefert E_OK im Standard- und Extended-Status zurück, wenn kein Fehler vorliegt [SWS_Os_00703].

Fehlerbehandlung und Randbedingungen

Im Extended-Status prüft das Betriebssystem auf ungültige Aufrufe sowie Deadlock-Szenarien [SWS_Os_00703]:

• E_OS_ID: Die übergebene SpinlockId ist ungültig [SWS_Os_00703].
• E_OS_ACCESS: Auf den Spinlock kann nicht zugegriffen werden [SWS_Os_00703].
• E_OS_INTERFERENCE_DEADLOCK: Ein TASK versucht die Sperre zu belegen, während dieselbe Sperre bereits durch einen TASK auf demselben Core gehalten wird [SWS_Os_00703].
• E_OS_NESTING_DEADLOCK: Ein TASK versucht einen Spinlock zu belegen, während er bereits einen anderen Spinlock hält, was zu einem Deadlock führen könnte [SWS_Os_00703].

Die synchrone Systemfunktion ShutdownAllCores mit der Service-ID 0x1c dient dem kontrollierten und vollständigen Herunterfahren des AUTOSAR-Betriebssystems über alle vorhandenen Prozessorkerne hinweg ([SWS_Os_00713]). Sobald der Dienst aufgerufen wird, erzwingt die Funktion einen Shutdown auf sämtlichen anderen Cores, sodass das Betriebssystem auf allen AUTOSAR-Kernen heruntergefahren wird ([SWS_Os_00713]).

Aufrufkontext und Nebenläufigkeit

Die Funktion ist im Header Os.h deklariert und als reentrant spezifiziert ([SWS_Os_00713]). Der Aufruf von ShutdownAllCores ist sowohl auf Task-Ebene (TASK level) als auch auf Interrupt-Ebene (ISR level) uneingeschränkt zulässig ([SWS_Os_00713]). Zudem kann der Dienst auch betriebssystemintern direkt durch das AUTOSAR OS ausgeführt werden ([SWS_Os_00713]).

Parameter und Kontrollfluss

Die Schnittstelle erwartet als einzigen Eingangsparameter Error vom Typ StatusType ([SWS_Os_00713]). Für diesen Parameter muss zwingend ein gültiger, vom AUTOSAR-Betriebssystem unterstützter Fehlercode übergeben werden ([SWS_Os_00713]). Aus- oder Ein-/Ausgangsparameter existieren nicht ([SWS_Os_00713]). Da die Funktion nach dem Auslösen des systemweiten Shutdowns niemals zum Aufrufer zurückkehrt, besitzt sie keinen Rückgabewert (void) ([SWS_Os_00713]).

Die synchrone Funktion ControlIdle ermöglicht es dem Aufrufer, die Aktion festzulegen, die während der Leerlaufzeit des Betriebssystems (wenn weder ein Task noch eine ISR aktiv ist) ausgeführt wird [SWS_Os_00769]. Dies dient primär der Implementierung von Maßnahmen zur Energieeinsparung. Die realen Leerlaufmodi sind hardwareabhängig und nicht standardisiert; der Standardmodus auf jedem Prozessorkern lautet IDLE_NO_HALT [SWS_Os_00769]. Bereitgestellt wird die Schnittstelle über die Header-Datei Os.h [SWS_Os_00769].

Die Funktion erwartet zwei Eingabeparameter:

• CoreID (vom Typ CoreIdType): Wählt den Prozessorkern aus, dessen Leerlaufmodus gesetzt werden soll [SWS_Os_00769].
• IdleMode (vom Typ IdleModeType): Bestimmt den Modus, der in der Leerlaufzeit ausgeführt werden soll [SWS_Os_00769].

Wurden gültige Parameter übergeben und trat kein Fehler auf, gibt die Funktion E_OK zurück [SWS_Os_00769], [SWS_Os_00770]. Ist der angegebene CoreID oder IdleMode ungültig – beispielsweise weil der referenzierte Kern nicht existiert oder der Modus unbekannt ist –, liefert der Aufruf im EXTENDED-Status den Fehlercode E_OS_ID zurück [SWS_Os_00769], [SWS_Os_00771]. Auf Single-Core-Systemen wird die Überprüfung des Parameters CoreID ausgelassen [SWS_Os_00771].

Bezüglich der Nebenläufigkeit ist die Funktion als nicht reentrant (Non Reentrant) spezifiziert [SWS_Os_00769]. Interpretation: Aufrufer müssen daher sicherstellen, dass Aufrufe von ControlIdle nicht zeitgleich oder unkoordiniert aus verschiedenen Ausführungskontexten erfolgen. Frage Q-7f239cb54752e826 (offen)

Verwendung

Die Funktion ReadPeripheral (in der Deklaration als ReadPeripheral8 geführt) dient dem synchronen Auslesen einer Speicheradresse innerhalb eines definierten Hardware-Peripheriebereichs [SWS_Os_91013]. Die Schnittstelle ist über die Header-Datei Os.h verfügbar [SWS_Os_91013]. Als Eingabeparameter erwartet der Dienst die Bereichsreferenz Area vom Typ AreaIdType sowie die Zieladresse Address als Zeiger auf const uint8 [SWS_Os_91013]. Der ausgelesene Inhalt der Speicherstelle wird über den Ausgabeparameter ReadValue bereitgestellt [SWS_Os_91013].

Fehlerbehandlung

Der Dienst gibt einen Statuscode vom Typ StatusType zurück, wobei E_OK die fehlerfreie Durchführung anzeigt [SWS_Os_91013]. Bei aktivierter erweiterter Statusprüfung (EXTENDED status) werden fehlerhafte Aufrufe anhand spezifischer Fehlerwerte differenziert [SWS_Os_91013]:

• E_OS_ID: Die übergebene Bereichskennung Area liegt außerhalb des gültigen Bereichs [SWS_Os_91013].
• E_OS_VALUE: Die angegebene Speicheradresse Address gehört nicht zum angegebenen Peripheriebereich [SWS_Os_91013].
• E_OS_CALLEVEL: Der Aufruf erfolgte aus einem unzulässigen Kontext [SWS_Os_91013].
• E_OS_ACCESS: Die aufrufende Task oder ISR dürfte nicht über die erforderliche Berechtigung für den Zugriff auf den Bereich verfügen (Interpretation) [SWS_Os_91013]. Frage Q-19e2c22110352ebb (offen)

Nebenläufigkeit und Einschränkungen

Der API-Dienst besitzt die Service-ID 0x28, arbeitet synchron und ist reentrant ausgelegt [SWS_Os_91013]. Aufrufe sind nur aus zulässigen Task- oder ISR-Kontexten gestattet; unzulässige Aufrufe werden im erweiterten Status mit E_OS_CALLEVEL abgewiesen [SWS_Os_91013].

Die synchrone und reentrante Betriebssystemfunktion ReadPeripheral16 dient dazu, den 16-Bit-Wert einer spezifizierten Speicheradresse innerhalb eines definierten Peripheriebereichs auszulesen [SWS_Os_91015]. Der Systemdienst ist unter der Service-ID 0x29 definiert und über die Header-Datei Os.h verfügbar [SWS_Os_91015].

Verwendung und Parameter

Dem Dienst werden als Eingangsparameter die Referenz auf den Hardware-Peripheriebereich (Area vom Typ AreaIdType) sowie die Zieladresse im Speicher (Address vom Typ const uint16*) übergeben [SWS_Os_91015]. Über den Ausgabeparameter Read Value vom Zeigertyp uint16* wird der an der Speicheradresse ermittelte 16-Bit-Inhalt bereitgestellt [SWS_Os_91015]. Bei fehlerfreier Ausführung liefert die Funktion den Rückgabewert E_OK vom Typ StatusType zurück [SWS_Os_91015].

Fehlerbehandlung und Zugriffsbeschränkungen

Im erweiterten Status (EXTENDED status) überprüft das Betriebssystem die Gültigkeit des Aufrufs und meldet Fehler über spezifische Statuscodes [SWS_Os_91015]:

• E_OS_ID: Die übergebene Bereichskennung Area liegt außerhalb des gültigen Bereichs [SWS_Os_91015].
• E_OS_VALUE: Die angegebene Speicheradresse Address gehört nicht zu dem spezifizierten Peripheriebereich Area [SWS_Os_91015].
• E_OS_CALLEVEL: Der Aufruf erfolgte in einem für die API-Funktion unzulässigen Kontext [SWS_Os_91015].
• E_OS_ACCESS: Der aufrufende Task oder die Interrupt-Service-Routine (ISR) ist nicht berechtigt, auf den angegebenen Bereich zuzugreifen [SWS_Os_91015].

Verwendung

Die synchrone und reentrante Funktion ReadPeripheral32 liest den Inhalt einer angegebenen Speicheradresse aus ([SWS_Os_91014]). Der Aufrufer übergibt die Referenz auf den Hardware-Peripheriebereich über den Parameter Area und die gewünschte Speicheradresse über Address ([SWS_Os_91014]). Der an dieser Adresse ausgelesene 32-Bit-Wert wird synchron über den Ausgabeparameter ReadValue bereitgestellt ([SWS_Os_91014]). Die Schnittstelle wird über den Header Os.h zur Verfügung gestellt ([SWS_Os_91014]).

Fehlerbehandlung

Der Dienst gibt einen Statuswert vom Typ StatusType zurück. Bei fehlerfreier Ausführung liefert er E_OK ([SWS_Os_91014]). Ist der erweiterte Status konfiguriert (EXTENDED status), werden folgende Fehlercodes zurückgegeben ([SWS_Os_91014]):

• E_OS_ID: Die übergebene Bereichskennung Area liegt außerhalb des zulässigen Bereichs ([SWS_Os_91014]).
• E_OS_VALUE: Die angegebene Adresse Address gehört nicht zu dem angegebenen Bereich Area ([SWS_Os_91014]).
• E_OS_CALLEVEL: Die Funktion wurde in einem unzulässigen Aufrufkontext aufgerufen ([SWS_Os_91014]).
• E_OS_ACCESS: Der aufrufende Task oder die aufrufende ISR verfügt nicht über die erforderliche Zugriffsberechtigung; dies dürfte sich laut Interpretation auf den Peripheriebereich beziehen ([SWS_Os_91014]). Frage Q-e5893b29acc5133a (offen)

Nebenläufigkeit und Einschränkungen

ReadPeripheral32 ist als reentrant spezifiziert und kann parallel von mehreren Kontrollflüssen aufgerufen werden ([SWS_Os_91014]). Da der Dienst synchron arbeitet, kehrt der Aufruf erst nach Abschluss des Lesevorgangs zurück ([SWS_Os_91014]). Aufrufer müssen gültige Speicherzeiger übergeben und sicherstellen, dass der Aufruf aus einem für die OS-API zulässigen Kontext erfolgt ([SWS_Os_91014]).

Verwendung

Die Funktion WritePeripheral (in der Spezifikation auch als Write Peripheral8 bezeichnet) ist ein synchroner und reentranter Dienst des Betriebssystems, um einen Wert an eine angegebene Speicheradresse eines Peripheriebereichs zu schreiben [SWS_Os_91010]. Die Deklaration wird über die Header-Datei Os.h bereitgestellt [SWS_Os_91010]. Der Aufruf erwartet als Parameter die Referenz auf den Hardware-Peripheriebereich (Area vom Typ AreaIdType), die Speicheradresse (Address vom Typ uint8*) sowie den zu schreibenden Wert (Write Value vom Typ uint8) [SWS_Os_91010]. Interpretation: Obwohl Write Value im Spezifikationstext tabellarisch unter den Ausgabeparametern aufgeführt ist, dürfte es sich anhand der Wertübergabe in der Signatur und der Beschreibung um den zu schreibenden Eingabewert handeln. Frage Q-619c69ba7a85ed92 (offen)

Fehlerbehandlung

Die Funktion gibt einen Status vom Typ StatusType zurück [SWS_Os_91010]:

• E_OK: Der Schreibvorgang wurde fehlerfrei durchgeführt [SWS_Os_91010].
• E_OS_ID: Die übergebene Bereichs-ID liegt außerhalb des gültigen Bereichs (im erweiterten Status) [SWS_Os_91010].
• E_OS_VALUE: Die Zieladresse gehört nicht zum angegebenen Bereich (im erweiterten Status) [SWS_Os_91010].
• E_OS_CALLEVEL: Unzulässiger Aufrufkontext der API-Funktion (im erweiterten Status) [SWS_Os_91010].
• E_OS_ACCESS: Die aufrufende Task oder ISR besitzt keine Zugriffsberechtigung für den Bereich [SWS_Os_91010].

Nebenläufigkeit und Einschränkungen

Der Aufruf wird synchron abgearbeitet und ist reentrant [SWS_Os_91010]. Aufrufer müssen sicherstellen, dass die ausführende Task oder ISR aus einem gültigen Kontext heraus agiert und über die notwendigen Zugriffsrechte für den adressierten Peripheriebereich verfügt [SWS_Os_91010].

Die synchrone und reentrante Betriebssystemfunktion WritePeripheral16 ([SWS_Os_91012]) dient dem Schreiben eines 16-Bit-Werts an eine Speicheradresse eines Peripheriebereichs. Der Dienst wird über den Header Os.h bereitgestellt und besitzt die Service-ID 0x2c.

Verwendung und Parameter

Beim Aufruf von WritePeripheral16 übergibt der Aufrufer die Kennung des Ziel-Hardwarebereichs (Area vom Typ AreaIdType), die Zieladresse (Address vom Typ uint16*) sowie den zu schreibenden Wert (Write Value vom Typ uint16, der trotz tabellarischer Ausweisung als Out-Parameter in der Signatur vermutlich als Wertübergabe dient) gemäß [SWS_Os_91012]. Frage Q-2edc50ae2e7fd0b0 (offen) Der Dienst wird synchron ausgeführt und liefert einen Statuswert vom Typ StatusType zurück.

Fehlerbehandlung

Im Erfolgsfall gibt die Funktion E_OK zurück. Unter dem Status EXTENDED sind folgende Fehlercodes spezifiziert ([SWS_Os_91012]):

• E_OS_ID: Die übergebene Bereichskennung (Area) liegt außerhalb des gültigen Bereichs.
• E_OS_VALUE: Die Zieladresse (Address) gehört nicht zum angegebenen Peripheriebereich.
• E_OS_CALLEVEL: Die Funktion wurde aus einem unzulässigen Kontext aufgerufen.
• E_OS_ACCESS: Die aufrufende Task oder ISR besitzt vermutlich keine Berechtigung für den Zugriff auf den angegebenen Bereich. Frage (offen)

Einschränkungen und Zusammenspiel

Die Funktion ist reentrant ([SWS_Os_91012]), erfordert jedoch die Einhaltung des zulässigen Aufrufkontexts (Task oder ISR), um Fehlerzustände wie E_OS_CALLEVEL zu vermeiden. Zur Überwachung und Analyse von Betriebssystemobjekten sieht AUTOSAR die Bereitstellung von ARTI-Beschreibungsdateien vor ([SWS_Os_00829]).

Die synchrone und reentrante Funktion WritePeripheral32 aus dem Modul Os dient dem Schreiben eines 32-Bit-Werts an eine angegebene Speicheradresse eines Peripheriebereichs [SWS_Os_91011]. Der Service ist über den Header Os.h verfügbar und besitzt die Service-ID 0x2d [SWS_Os_91011].

Parameter und Aufruf

Für die Ausführung des Schreibzugriffs benötigt die Funktion drei Übergabeparameter [SWS_Os_91011]:

• Area (AreaIdType): Referenz auf den Ziel-Hardware-Peripheriebereich [SWS_Os_91011].
• Address (uint32*): Speicheradresse, an die der Wert geschrieben werden soll [SWS_Os_91011].
• Write Value (uint32): Der konkrete 32-Bit-Wert, der an die Zieladresse übertragen wird [SWS_Os_91011].

Rückgabewerte und Fehlerbehandlung

Der Aufruf liefert einen Statuswert vom Typ StatusType zurück [SWS_Os_91011]. Im Erfolgsfall wird E_OK gemeldet [SWS_Os_91011]. Bei aktivem EXTENDED-Status signalisiert E_OS_ID eine ungültige Bereichs-ID, E_OS_VALUE eine nicht zum Bereich gehörende Adresse und E_OS_CALLEVEL einen unzulässigen Aufrufkontext [SWS_Os_91011]. Falls der aufrufende Task oder die ISR keine Zugriffsberechtigung für den Bereich besitzt, wird E_OS_ACCESS zurückgegeben [SWS_Os_91011].

Nebenläufigkeit

Da WritePeripheral32 reentrant ist, kann der Dienst in nebenläufigen Ausführungskontexten genutzt werden, sofern der jeweilige Aufrufer zur Laufzeit über die erforderliche Zugriffsberechtigung verfügt [SWS_Os_91011].

Verwendung und Semantik

Die synchrone und reentrante Betriebssystemfunktion ModifyPeripheral8 ([SWS_Os_91016]) modifiziert ein Byte an einer angegebenen Speicheradresse Address. Dabei wird der bestehende Speicherinhalt bitweise über die Maske Clearmask per Und-Verknüpfung sowie über die Maske Setmask per Oder-Verknüpfung gemäß der Formel *Address = ((*Address & Clearmask) | Setmask) aktualisiert ([SWS_Os_91016]). Als Eingabeparameter erwartet die Funktion die Peripheriebereichs-Referenz Area vom Typ AreaIdType, die Zieladresse Address (Typ uint8*) sowie die beiden Maskenwerte vom Typ uint8. Die Funktion wird über die Header-Datei Os.h bereitgestellt und besitzt die Service-ID 0x2e ([SWS_Os_91016]).

Fehlerbehandlung und Rückgabewerte

Der Rückgabewert vom Typ StatusType signalisiert den Erfolg der Operation mit E_OK ([SWS_Os_91016]). Bei aktiviertem Extended-Status können spezifische Fehlerbedingungen auftreten:

• E_OS_ID: Die übergebene Bereichskennung Area liegt außerhalb des zulässigen Bereichs ([SWS_Os_91016]).
• E_OS_VALUE: Die Zieladresse Address gehört nicht zu dem angegebenen Bereich Area ([SWS_Os_91016]).
• E_OS_CALLEVEL: Der Dienst wurde in einem unzulässigen Aufrufkontext aufgerufen ([SWS_Os_91016]).
• E_OS_ACCESS: Der aufrufende Task oder die ISR besitzt keine Zugriffsberechtigung für den Zielbereich ([SWS_Os_91016]).

Nebenläufigkeit und Aufrufbedingungen

Da ModifyPeripheral8 als reentrant spezifiziert ist, kann der Aufruf sicher in parallelen Abläufen erfolgen ([SWS_Os_91016]). Aufrufer müssen sicherstellen, dass sowohl der Kontext als auch die Zugriffsrechte für Area und Address gültig sind, um Fehlerzustände zu vermeiden ([SWS_Os_91016]).

Die synchrone und reentrante Funktion ModifyPeripheral16 modifiziert eine 16-Bit-Speicherstelle innerhalb eines definierten Peripheriebereichs gemäß der Berechnungsformel *Address = ((*Address & Clearmask) | Setmask) [SWS_Os_91018]. Als Parameter werden die Peripheriebereichs-Referenz Area (Typ AreaIdType), die Zieladresse Address (Typ uint16*) sowie die Bitmasken Clearmask für ein bitweises UND und Setmask für ein bitweises ODER übergeben [SWS_Os_91018]. Die Deklaration ist über den Header Os.h verfügbar [SWS_Os_91018].

Im regulären Erfolgsfall liefert der Dienst den Rückgabewert E_OK [SWS_Os_91018]. Bei aktivierter erweiterter Statusprüfung (EXTENDED status) werden fehlerhafte Aufrufe anhand spezifischer Fehlercodes erkannt und abgewiesen [SWS_Os_91018]:

• E_OS_ID: Die übergebene Bereichskennung Area liegt außerhalb des gültigen Wertebereichs [SWS_Os_91018].
• E_OS_VALUE: Die übergebene Speicheradresse Address gehört nicht zu dem angegebenen Bereich Area [SWS_Os_91018].
• E_OS_CALLEVEL: Der Dienst wurde aus einem unzulässigen Kontext aufgerufen [SWS_Os_91018].
• E_OS_ACCESS: Der aufrufende Task oder die aufrufende ISR besitzt keine Zugriffsberechtigung für den angegebenen Bereich [SWS_Os_91018].

Aufrufer müssen vor der Ausführung sicherstellen, dass sowohl der Kontext als auch die Berechtigungen für den referenzierten Bereich vorliegen, um Zugriffsverletzungen zu vermeiden [SWS_Os_91018].

Die synchrone und reentrante Betriebssystemfunktion ModifyPeripheral32 dient gemäß [SWS_Os_91017] der gezielten bitweisen Manipulation einer 32-Bit-Speicheradresse. Über die Schnittstelle Os.h bereitgestellt, wendet die Funktion auf die Zieladresse Address die feste Berechnungsformel *Address = ((*Address & Clearmask) | Setmask) an. Hierbei werden zunächst über die Bitmaske Clearmask Bits per Und-Verknüpfung zurückgesetzt und anschließend über Setmask per Oder-Verknüpfung gesetzt.

Als Eingangsparameter erwartet der Dienst die Peripheriebereichs-Referenz Area, den Adresszeiger Address sowie die beiden 32-Bit-Masken [SWS_Os_91017]. Bei fehlerfreier Ausführung wird der Statuscode E_OK zurückgegeben. Im erweiterten Status (EXTENDED status) führt die Funktion Plausibilitätsprüfungen durch und meldet folgende Fehlercodes:

• E_OS_ID: Die übergebene Area liegt außerhalb des zulässigen Wertebereichs [SWS_Os_91017].
• E_OS_VALUE: Die Zieladresse gehört nicht zu dem angegebenen Peripheriebereich [SWS_Os_91017].
• E_OS_CALLEVEL: Die Funktion wurde aus einem unzulässigen Kontext aufgerufen [SWS_Os_91017].
• E_OS_ACCESS: Die aufrufende Task oder ISR besitzt keine Berechtigung für den Zugriff [SWS_Os_91017] (Interpretation: fehlende Zugriffsberechtigung auf den Peripheriebereich). Frage Q-b4d959765dc59c72 (offen)

Nebenläufige Aufrufe sind dank der Reentranz zulässig, sofern der Aufrufkontext gewahrt bleibt [SWS_Os_91017]. Im Gesamtsystem unterscheidet sich diese direkte Registermodifikation von Berechnungsformeln zur dynamischen Datenermittlung, die etwa im Rahmen von ARTI-Debug-Informationen gemäß [SWS_Os_00829] ausgewertet werden.

Die synchrone und reentrante Systemfunktion EnableInterruptSource aktiviert eine Interrupt-Quelle durch Modifikation der Register des Interrupt-Controllers [SWS_Os_91020], [SWS_Os_00811]. Das Betriebssystem stellt diesen Dienst für jede konfigurierte Kategorie-2-Interrupt-Quelle bereit [SWS_Os_00808].

Parameter und Aufruf

Über den Parameter ISRID wird der Bezeichner der Kategorie-2-ISR übergeben [SWS_Os_91020]. Der boolesche Parameter ClearPending bestimmt, ob ein anstehendes Interrupt-Flag bei der Aktivierung gelöscht werden soll (TRUE) oder unverändert bleibt (FALSE) [SWS_Os_91020], [SWS_Os_00811]. Die Funktion steht über die Header-Datei Os.h zur Verfügung [SWS_Os_91020].

Fehlerbehandlung und Rückgabewerte

Wird kein Fehler festgestellt, liefert der Aufruf E_OK zurück [SWS_Os_91020], [SWS_Os_00810]. Erkennt das Betriebssystem einen Fehler, gibt es den entsprechenden Statuscode vom Typ StatusType zurück und ruft den ErrorHook() auf [SWS_Os_00810]. Folgende Fehlerzustände sind definiert:

• E_OS_ID: Der Parameter ISRID ist kein gültiger Bezeichner einer Kategorie-2-ISR (im Status EXTENDED) [SWS_Os_91020].
• E_OS_CALLEVEL: Die Funktion wurde aus einem unzulässigen Aufrufkontext aufgerufen (im Status EXTENDED) [SWS_Os_91020].
• E_OS_ACCESS: Die aufrufende Applikation ist im Rahmen der Service Protection nicht Eigentümer der angegebenen ISRID [SWS_Os_91020].

Zusammenspiel

Die Funktion bildet gemeinsam mit DisableInterruptSource und ClearPendingInterrupt das API-Trio zur gezielten Steuerung einzelner Kategorie-2-Interrupt-Quellen (OsIsrCategory == CATEGORY_2) im Betriebssystem [SWS_Os_00808], [SWS_Os_00810].

Verwendung

Die synchrone und reentrante Funktion DisableInterruptSource deaktiviert eine spezifische Interruptquelle direkt über die Register des Interrupt-Controllers [SWS_Os_91019], [SWS_Os_00812]. Sie steht über die Header-Datei Os.h zur Verfügung und wird für jede Interruptquelle der Kategorie 2 (OsIsrCategory == CATEGORY_2) bereitgestellt [SWS_Os_91019], [SWS_Os_00808]. Als Parameter wird die Kennung der betreffenden ISR (ISRID) übergeben. Bei erfolgreicher Ausführung liefert der Dienst E_OK zurück [SWS_Os_91019], [SWS_Os_00810].

Fehlerbehandlung

Stellt das Betriebssystem während der Ausführung einen Fehler fest, wird der entsprechende StatusType zurückgegeben und der ErrorHook() aufgerufen [SWS_Os_00810]. Mögliche Fehlercodes sind:

• E_OS_ID: Die übergebene ISRID ist keine gültige Kennung einer Kategorie-2-ISR (im EXTENDED-Status) [SWS_Os_91019].
• E_OS_CALLEVEL: Unzulässiger Aufrufkontext der API-Funktion (im EXTENDED-Status) [SWS_Os_91019].
• E_OS_ACCESS: Die aufrufende OS-Application ist nicht Eigentümer der angegebenen ISR (Service Protection) [SWS_Os_91019].
• E_OS_NOFUNC: Die angeforderte Interruptquelle ist bereits deaktiviert (im EXTENDED-Status bei geschachtelten Aufrufen) [SWS_Os_00809].

Zusammenspiel und Randbedingungen

Die Funktion bildet gemeinsam mit EnableInterruptSource und ClearPendingInterrupt das API-Trio zur Steuerung von Kategorie-2-Interruptquellen [SWS_Os_00808]. Nebenläufige oder wiederholte Aufrufe werden im erweiterten Status durch die Rückgabe von E_OS_NOFUNC abgesichert, wodurch redundante Deaktivierungen kontrollierbar bleiben [SWS_Os_00809]. Aufrufer müssen zudem die passenden Zugriffsrechte besitzen, um Laufzeitfehler durch die Service-Protection zu verhindern [SWS_Os_91019].

Verwendung und Aufrufkontext

Die Funktion ClearPendingInterrupt dient dem Zurücksetzen eines anstehenden Interrupts für Quellen der Kategorie 2 [SWS_Os_00808]. Sie nimmt als einzigen Eingangsparameter die Kennung ISRID einer Kategorie-2-ISR entgegen und modifiziert direkt die zugehörigen Register des Interrupt-Controllers [SWS_Os_91021], [SWS_Os_00813]. Der Aufruf wird synchron verarbeitet und steht über die Header-Datei Os.h zur Verfügung [SWS_Os_91021].

Fehlerbehandlung und Rückgabewerte

Im fehlerfreien Fall wird der Statuscode E_OK zurückgegeben [SWS_Os_91021]. Stellt das Betriebssystem während der Ausführung einen Fehler fest, liefert der Dienst den entsprechenden Fehlercode vom Typ StatusType zurück und ruft zwingend den ErrorHook() auf [SWS_Os_00810]. Folgende Fehlerzustände sind für die Schnittstelle spezifiziert [SWS_Os_91021]:

• E_OS_ID: Der übergebene Parameter ISRID ist keine gültige Kennung einer Kategorie-2-ISR (wird im Status EXTENDED zurückgegeben) [SWS_Os_91021].
• E_OS_CALLEVEL: Die Funktion wurde aus einem unzulässigen Aufrufkontext aufgerufen (wird im Status EXTENDED zurückgegeben) [SWS_Os_91021].
• E_OS_ACCESS: Die aufrufende Applikation ist im Rahmen der Service Protection nicht als Eigentümer der übergebenen ISR autorisiert [SWS_Os_91021].

Nebenläufigkeit und Zusammenspiel im Betriebssystem

Die Schnittstelle ist als reentrant definiert und kann somit sicher nebenläufig aufgerufen werden [SWS_Os_91021]. Das Betriebssystem stellt ClearPendingInterrupt für jede Kategorie-2-Interruptquelle (OsIsrCategory == CATEGORY_2) als festen Bestandteil der Steuer-APIs bereit, zu denen auch DisableInterruptSource und EnableInterruptSource gehören [SWS_Os_00808].

Die Funktion ActivateTaskAsyn (Service-ID 0x33) stellt die asynchrone Variante zur Task-Aktivierung dar und wird über die Header-Datei Os.h bereitgestellt ([SWS_Os_91022]). Sie ist primär für die kernübergreifende Task-Aktivierung in Multicore-Systemen vorgesehen ([SWS_Os_91022]).

Als einziger Eingabeparameter wird id vom Typ TaskType übergeben, welcher den zu aktivierenden Task spezifiziert ([SWS_Os_91022]). Die Schnittstelle besitzt keinen Rückgabewert (void) und definiert weder Ein-/Ausgabe- noch reine Ausgabeparameter ([SWS_Os_91022]).

Mögliche Fehler bei der Aktivierung werden dem Aufrufer nicht zurückgemeldet ([SWS_Os_91022], [SWS_Os_00816]). Stattdessen werden auftretende Fehler ausschließlich über den globalen Error-Hook gemeldet, sofern ein solcher konfiguriert ist ([SWS_Os_00816]).

Hinsichtlich der Nebenläufigkeit ist die Funktion reentrant und arbeitet vollständig asynchron ([SWS_Os_91022]), womit der aufrufende Kontext nicht auf die Ausführung blockiert. Das Betriebssystem ist verpflichtet, diese Schnittstelle gemäß [SWS_Os_00816] bereitzustellen.

Verwendung und Funktionsweise

Die Funktion Ioc Init (im Release R20-11 als Entwurf gekennzeichnet) initialisiert die internen Datenstrukturen der Inter-OS-Application Communication (IOC) [SWS_Os_91026]. Der Aufruf erfolgt synchron, akzeptiert keine Übergabeparameter und besitzt keinen Rückgabewert [SWS_Os_91026]. Wird der Betriebssystem-Generator im „IOC mode“ ausgeführt, generiert dieser ausschließlich den IOC-Code in der Quelldatei Ioc.c und deklariert die zugehörigen Schnittstellen in der Header-Datei Ioc.h [SWS_Os_00834], über welche auch Ioc Init bereitgestellt wird [SWS_Os_91026].

Fehlerbehandlung und Nebenläufigkeit

Für Ioc Init sind in der Spezifikation weder spezifische Fehler-Rückgabewerte noch Fehlermeldungen an DET oder DEM vorgesehen [SWS_Os_91026]. Der Dienst ist explizit als nicht reentrant (Non Reentrant) definiert [SWS_Os_91026]. Interpretation: Aufgrund der fehlenden Reentranz und der Initialisierungsaufgabe dürfte der Dienst sequenziell während der Systemstartphase aufgerufen werden müssen, bevor nebenläufige Kommunikationszugriffe stattfinden. Frage Q-47f99a4725b57c89 (offen)

Zusammenspiel mit IOC-Kommunikationsfunktionen

Die ordnungsgemäße Initialisierung der Datenstrukturen bildet die Voraussetzung für die Nutzung der generierten IOC-Kommunikationsschnittstellen:

• Senden und Schreiben: Sender übertragen Daten asynchron über Einzelwert-Dienste wie Ioc Send [SWS_Os_00718] und Ioc Write [SWS_Os_91003] oder Gruppenfunktionen wie Ioc Send Group [SWS_Os_00728] und Ioc Write Group [SWS_Os_91004].
• Empfangen und Lesen: Empfänger rufen Daten synchron über Ioc Receive [SWS_Os_00738], Ioc Read [SWS_Os_91005] oder entsprechende Gruppendienste [SWS_Os_00746] [SWS_Os_91006] ab.
• Queue-Verwaltung und Benachrichtigung: Bei konfigurierter gepufferter Kommunikation kann der Inhalt einer internen Warteschlange mit Ioc Empty Queue synchron geleert werden [SWS_Os_00754]. Zusätzlich kann bei Datenempfang ein konfigurierter Empfänger-Callback <Receiver Pull CB> auf dem Zielkern ausgeführt werden [SWS_Os_00757].

Die Callback-Funktion <Receiver Pull CB> kann optional für den Empfänger einer Kommunikation konfiguriert werden und wird über den Header Os.h deklariert [SWS_Os_00757]. Ist dieser Callback eingerichtet, ruft der IOC (Inter-OS-Application Communicator) die Funktion auf dem empfangenden Core bei jedem Datenempfang synchron auf [SWS_Os_00757]. Der konkrete Bezeichner der Callback-Funktion wird empfängerseitig über das Konfigurationsattribut OsIocReceiverPullCB festgelegt [SWS_Os_00757].

Für den Aufruf und die Schnittstelleneigenschaften gelten folgende Vorgaben:

• Signatur und Parameter: Die Funktion besitzt den Prototyp void <Receiver Pull CB> ( void ); sie nimmt keine Parameter entgegen (weder Eingangs-, Durchgangs- noch Ausgangsparameter) und liefert keinen Rückgabewert [SWS_Os_00757].
• Synchronität und Reentranz: Der Aufruf durch den IOC erfolgt mit synchroner Semantik direkt auf dem Empfänger-Core [SWS_Os_00757]. Zudem ist die Callback-Funktion als reentrant spezifiziert [SWS_Os_00757].
• Fehlerbehandlung: Die Spezifikation sieht für diese Funktion weder Rückgabewerte noch spezifische Fehlercodes oder Fehlerbenachrichtigungen vor [SWS_Os_00757].

Da die Signatur keinerlei Nutzdaten übergibt, dürfte der Aufruf primär als Benachrichtigungssignal dienen, um den Empfänger über das Eintreffen neuer Daten zu informieren und das nachfolgende Abholen der Nutzdaten anzustoßen. Frage Q-2365bb46ad77a476 (offen) Entwickler sollten beachten, dass die Ausführung synchron auf dem Empfänger-Core erfolgt [SWS_Os_00757].

Die Funktion ProtectionHook dient als zentraler Callback des Betriebssystems und wird immer dann synchron aufgerufen, wenn ein schwerwiegender Fehler auftritt [SWS_Os_00538]. Als typische Fehlerszenarien nennt die Spezifikation explizit das Überschreiten der Worst-Case-Ausführungszeit (Worst Case Execution Time) sowie Verletzungen des Speicherschutzes [SWS_Os_00538]. Die Deklaration der Schnittstelle wird über den Header Os_Externals.h bereitgestellt [SWS_Os_00538].

Als Eingangsparameter nimmt die Routine Fatalerror vom Typ StatusType entgegen, welcher die auslösende Ursache des Hook-Aufrufs übergibt [SWS_Os_00538]. Zusätzliche Ein-/Ausgangsparameter oder reine Ausgabeparameter sind in der Signatur nicht definiert [SWS_Os_00538].

Über den Rückgabewert vom Typ ProtectionReturnType legt ProtectionHook verbindlich fest, welche Aktion das Betriebssystem nach Ausführung des Hooks zur weiteren Fehlerbehandlung einleiten soll [SWS_Os_00538]. Folgende Aktionen stehen als Rückgabewerte zur Verfügung [SWS_Os_00538]:

• PRO_IGNORE [SWS_Os_00538]
• PRO_TERMINATETASKISR [SWS_Os_00538]
• PRO_TERMINATEAPPL [SWS_Os_00538]
• PRO_TERMINATEAPPL_RESTART [SWS_Os_00538]
• PRO_SHUTDOWN [SWS_Os_00538]

In Bezug auf Nebenläufigkeit und Ablaufverhalten ist ProtectionHook als reentrant und synchron spezifiziert [SWS_Os_00538]. Der Aufruf erfolgt unmittelbar bei Eintritt des schwerwiegenden Fehlers, woraufhin das Betriebssystem die definierte Aktion ausführt [SWS_Os_00538].

Der Aufzählungstyp AppModeType ist in der Header-Datei Os.h definiert und dient der Festlegung des Anwendungsmodus im Betriebssystem [SWS_Os_91007]. In Mehrkernsystemen ermöglicht dieser Typ, dass der Anwendungsmodus eines Prozessorkerns von einem anderen Core geerbt wird [SWS_Os_91007].

Für den Wertebereich ist der Wert DONOTCARE spezifiziert [SWS_Os_91007]. Interpretation: Dieser Wert dürfte dazu dienen, einen Core explizit so zu konfigurieren, dass er keinen eigenständigen Modus startet, sondern das Verhalten des übergeordneten Cores übernimmt. Frage Q-2b7d9f1c8e5f1a3f (offen) Spezifische Fehlercodes oder Rückgabewerte sind für den Typ selbst nicht definiert.

Hinsichtlich der Diagnose und des Systemzustands ist das Zusammenspiel mit Analysewerkzeugen relevant. Gemäß [SWS_Os_00829] muss die ARTI-Modulbeschreibungsdatei alle ORTI-Container unterstützen, um angebundenen Debug-Tools die Auswertung und Anzeige von Informationen über das Betriebssystem und dessen Objekte zu ermöglichen. Die ARTI-Debuginformationen stellen dynamische Attribute bereit, die über Formeln aufgelöst werden [SWS_Os_00829]. Interpretation: Der Zustand des Anwendungsmodus dürfte somit auf Werkzeugebene über entsprechende ARTI-Objektattribute abgebildet und ausgelesen werden. Frage Q-410d011cbcf1b158 (offen)

Der Datentyp ApplicationStateType dient im Classic AUTOSAR Betriebssystem zur eindeutigen Identifikation des Zustands einer OS-Application [SWS_Os_00773]. Er ist als skalarer Basistyp spezifiziert und wird über die Header-Datei Os.h bereitgestellt [SWS_Os_00773].

Der zulässige Wertebereich von ApplicationStateType umfasst drei diskrete Zustände für eine OS-Application [SWS_Os_00773]:

• APPLICATION_ACCESSIBLE: Kennzeichnet, dass die OS-Application betriebsbereit ist und auf ihre Ressourcen zugegriffen werden kann [SWS_Os_00773].
• APPLICATION_RESTARTING: Signalisiert, dass sich die OS-Application gegenwärtig in einer Neustartphase befindet [SWS_Os_00773].
• APPLICATION_TERMINATED: Zeigt an, dass die OS-Application beendet wurde und keine weiteren Aktionen ausführt [SWS_Os_00773].

In Bezug auf die Verwendung und das Zusammenspiel mit anderen Komponenten dürfte der Typ vermutlich als Rückgabewert oder Ausgabeparameter in entsprechenden OS-Systemdiensten zur Zustandsüberwachung dienen, um Aufrufern den aktuellen Lebenszyklusstatus einer Anwendung mitzuteilen. Frage Q-9a4f2254f4013853 (offen) Da es sich um eine elementare Typdefinition handelt, spezifiziert der Standard hierfür keine eigenständigen Fehlercodes, DET- oder DEM-Meldungen und formuliert keine gesonderten Restriktionen bezüglich Aufrufkontext oder Reentranz [SWS_Os_00773].

Der Datentyp ApplicationStateRefType ist Bestandteil des Betriebssystems (Modul Os) in der AUTOSAR-Classic-Plattform und wird über die Header-Datei Os.h zur Verfügung gestellt [SWS_Os_00774]. Der Typ ist von einem Zeiger (Pointer) abgeleitet und verweist direkt auf eine Speicherstelle, an der ein Zustand einer OS-Anwendung (Application State) hinterlegt werden kann [SWS_Os_00774].

Hinsichtlich der praktischen Verwendung dient dieser Zeigertyp der Referenzierung von Anwendungszuständen: Interpretation: Als Zeigertyp dürfte ApplicationStateRefType primär als Referenz- bzw. Ausgabeparameter in Abfragefunktionen des Betriebssystems zum Einsatz kommen, über welche der Zustand einer OS-Anwendung an den Aufrufer übermittelt wird. Frage Q-948bb914d3672a38 (offen) Aufrufer müssen daher sicherstellen, dass vor der Parameterübergabe ein gültiger, beschreibbarer Speicherbereich für den Zielzustand reserviert ist, um fehlerhafte Zeigerzugriffe zur Laufzeit zu vermeiden.

Spezifische Fehlerbehandlungsmechanismen, Fehlercodes für DET oder DEM sowie gesonderte Vorgaben zur Reentranz und Nebenläufigkeit sind für diesen Basistyp in der Spezifikation nicht gesondert ausgewiesen [SWS_Os_00774]. Etwaige Restriktionen hinsichtlich des erlaubten Aufrufkontexts oder einzuhaltender Synchronisationspflichten ergeben sich ausschließlich aus denjenigen Betriebssystem-Schnittstellen, die diesen Typ in ihren Funktionssignaturen verwenden.

Der Typ ScheduleTableStatusType bildet gemäß [SWS_Os_00784] den aktuellen Ausführungs- und Synchronisationsstatus einer Schedule Table im AUTOSAR-Betriebssystem ab. Er wird über die Header-Datei Os.h bereitgestellt und basiert auf einem implementationsspezifischen Wertebereich.

Folgende Statuswerte sind spezifiziert:

• SCHEDULETABLE_STOPPED: Die Schedule Table ist nicht gestartet.
• SCHEDULETABLE_NEXT: Die Schedule Table wird nach Ablauf der gegenwärtig aktiven Schedule Table gestartet (Interpretation: dies erfolgt nach Übergabe an den Dienst NextScheduleTable()). Frage Q-8cbcfc83969eea23 (offen)
• SCHEDULETABLE_WAITING: Die Schedule Table verwendet explizite Synchronisation, wurde bereits gestartet und wartet auf den Abgleich mit der globalen Zeit.
• SCHEDULETABLE_RUNNING: Die Schedule Table befindet sich in Ausführung, ist jedoch aktuell nicht synchron zu einer globalen Zeitquelle.
• SCHEDULETABLE_RUNNING_AND_SYNCHRONOUS: Die Schedule Table läuft und ist mit der globalen Zeitquelle synchronisiert.

Als reiner Statusdatentyp definiert ScheduleTableStatusType keine eigenen Laufzeitfehler oder DET-/DEM-Meldungen. Im Zusammenspiel mit Analysewerkzeugen dient der Typ gemäß [SWS_Os_00829] zur ARTI-gestützten Auswertung und Darstellung dynamischer Betriebssystemobjekte, wodurch Zustands- und Synchronisationsabweichungen im System transparent erfasst werden können.

Verwendung und Definition

Der Datentyp ScheduleTableStatusRefType ist gemäß [SWS_Os_00785] als Zeigertyp auf eine Variable des Datentyps Schedule Table Status Type definiert. Der Typ wird über den Header Os.h bereitgestellt und dient im AUTOSAR-Betriebssystem als Referenztyp für den Status einer Ablaufverfolgungstabelle (Schedule Table) [SWS_Os_00785].

Einsatz und Randbedingungen

In typischen Betriebssystemaufrufen dürfte dieser Zeigertyp als Ausgabeparameter fungieren, über den eine OS-Systemfunktion den aktuellen Zustand der referenzierten Schedule Table an den Aufrufer zurückmeldet. Frage Q-53364f3a9953dae3 (offen) Da die Spezifikation lediglich die Typdefinition festlegt, müssen aufrufende Komponenten bei der Verwendung Folgendes beachten:

• Speicherbereitstellung: Vor der Übergabe einer Referenz dieses Typs muss der Aufrufer sicherstellen, dass der Zeiger auf einen gültigen und beschreibbaren Speicherbereich verweist, der während des gesamten Aufrufs gültig bleibt.
• Gültigkeit und Nullzeiger: Die Übergabe eines Nullzeigers (NULL) dürfte je nach Betriebssystem-Konfiguration (Standard- oder Extended-Status) zu entsprechenden Fehlerrückmeldungen der aufgerufenen OS-Dienste führen. Frage Q-63d77f8c7857e6c4 (offen)
• Speicherschutz: In sicherheitskritischen Mehrkern- oder speichergeschützten OS-Umgebungen muss der referenzierte Speicherbereich für den aufrufenden Task bzw. die OS-Instanz zugreifbar sein.

Da [SWS_Os_00785] keine weiteren Laufzeiteigenschaften oder spezifische Fehlercodes für den Basistyp ausweist, ergeben sich Reentranz und Aufrufkontext aus den jeweiligen OS-Diensten, welche diesen Zeigertyp als Parameter verwenden.

Verwendung und Wertebereich

Der Enumerationstyp TryToGetSpinlockType wird über die Header-Datei Os.h bereitgestellt und dient als Statusanzeige dafür, ob ein Spinlock durch den Aufrufer erfolgreich belegt werden konnte oder nicht [SWS_Os_00792]. Er definiert das Ergebnis entsprechender Belegungsoperationen im Betriebssystem [SWS_Os_00792].

Der Wertebereich umfasst genau zwei spezifizierte Literale [SWS_Os_00792]:

• TRYTOGETSPINLOCK_SUCCESS: Signalisiert, dass der Spinlock erfolgreich belegt werden konnte [SWS_Os_00792].
• TRYTOGETSPINLOCK_NOSUCCESS: Zeigt an, dass der Spinlock nicht belegt werden konnte [SWS_Os_00792].

Nebenläufigkeit und Systemkontext

Der Typ findet Einsatz bei der Synchronisation in Mehrkernsystemen. Interpretation: Der Aufrufer dürfte den Rückgabewert synchron auswerten, um unmittelbar festzustellen, ob der geschützte kritische Abschnitt betreten werden darf oder ob bei TRYTOGETSPINLOCK_NOSUCCESS ohne blockierendes Warten ein alternativer Programmzweig gewählt werden muss [SWS_Os_00792]. Frage Q-a04e72802dc41325 (offen) Eigene Fehlercodes oder Fehlermeldungen über DET oder DEM sind für diesen Typ nicht spezifiziert [SWS_Os_00792].

Zusammenspiel mit Diagnosewerkzeugen

Im Rahmen von Werkzeuganbindungen unterstützt die ARTI-Modulbeschreibungsdatei alle ORTI-Container, um Informationen über das Betriebssystem, dessen Zustände und Betriebssystemobjekte anzuzeigen und dynamische Werte zu ermitteln [SWS_Os_00829]. Interpretation: Über solche Schnittstellen dürften auch Spinlocks und deren Belegungszustände für Debugging- und Tracing-Werkzeuge visualisierbar sein [SWS_Os_00829]. Frage Q-a488e055eb7d402e (offen)

Verwendung und Wertebereich

Der skalare Datentyp IdleModeType wird über den Header Os.h bereitgestellt und dient der Spezifikation des Verhaltens eines Prozessorkerns im Leerlaufmodus [SWS_Os_00793]. Im definierten Wertebereich ist der Modus IDLE_NO_HALT festgelegt, bei dessen Wahl der Prozessorkern während der Leerlaufzeit keine gesonderten Aktionen ausführt [SWS_Os_00793].

Interpretation: Da IdleModeType von einem skalaren Basistyp abgeleitet ist, dürfte er im Betriebssystemkontext als Konfigurationswert oder Aufrufparameter für Steuerungsdienste des Kern-Leerlaufverhaltens dienen. Frage Q-911a39efb537f1bc (offen) Interpretation: Neben dem Standardwert IDLE_NO_HALT dürften konkrete Betriebssystem-Implementierungen oder Mikrocontroller-Architekturen potenziell zusätzliche Halte- oder Stromsparmodi vorsehen, wenngleich der Spezifikationsauszug lediglich das Ausbleiben spezifischer Aktionen benennt. Frage Q-b6688f74cacbab45 (offen)

Einschränkungen und Fehlerbehandlung

Für IdleModeType sind im vorliegenden Spezifikationsumfang keine spezifischen Fehlercodes, DET- oder DEM-Meldungen sowie keine Anforderungen an Reentranz oder Aufrufkontexte ausgewiesen [SWS_Os_00793]. Etwaige funktionale Einschränkungen oder Vorbedingungen ergeben sich daher ausschließlich aus den übergeordneten Betriebssystem-Schnittstellen, die diesen Typ verarbeiten.