ECU State Manager (EcuM)

Die synchrone und reentrante Funktion EcuM_GoDownHaltPoll weist das Modul ECU State Manager an, abhängig vom zuvor ausgewählten Shutdown-Ziel in einen Sleep-Modus, ein Reset oder den Zustand OFF überzugehen [SWS_EcuM_91002]. Sie ist über die Header-Datei EcuM.h verfügbar und besitzt die Service-ID 0x2c [SWS_EcuM_91002].

Parameter und Aufrufberechtigung

Als einziger Eingabeparameter wird UserID vom Typ EcuM_UserType übergeben. Dieser identifiziert den aufrufenden Benutzer. Ein Aufruf ist strikt reglementiert: Es dürfen ausschließlich vorkonfigurierte Benutzer diese Funktion ausführen [SWS_EcuM_91002].

Rückgabewerte und Ablaufverhalten

Das Rückgabeverhalten hängt maßgeblich von der Art des gesetzten Shutdown-Ziels ab [SWS_EcuM_91002]:

• E_NOT_OK: Die Anforderung wurde nicht akzeptiert [SWS_EcuM_91002].
• E_OK: Ist das Ziel SLEEP, kehrt die Funktion nach dem Verlassen des Schlafzustands erfolgreich mit diesem Status zurück [SWS_EcuM_91002].
• Keine Rückkehr: Wurde als Shutdown-Ziel RESET oder OFF gewählt, kehrt der Funktionsaufruf nicht mehr zum Aufrufer zurück [SWS_EcuM_91002].

Einschränkungen und Fehlerbehandlung

Obwohl die Funktion formal als reentrant deklariert ist, setzt ihre bestimmungsgemäße Ausführung die vorherige Festlegung eines gültigen Shutdown-Ziels voraus [SWS_EcuM_91002]. Spezifische DET- oder DEM-Fehlercodes sind in der Schnittstellenspezifikation nicht aufgeführt; ein Fehlschlag oder die Zurückweisung der Anforderung wird unmittelbar über den Rückgabewert E_NOT_OK angezeigt [SWS_EcuM_91002].

Die synchrone Service-Funktion EcuM_Init initialisiert den ECU State Manager und leitet den geordneten Startablauf des Steuergeräts ein ([SWS_EcuM_02811]). Sie wird über den Header EcuM.h mit der Service-ID 0x01 deklariert, nimmt keine Parameter entgegen und liefert keinen Rückgabewert ([SWS_EcuM_02811]). Formal als reentrant eingestuft, kehrt EcuM_Init nach dem Aufruf niemals zum Aufrufer zurück, da sie die Ausführung an das Betriebssystem übergibt, indem sie StartOS aufruft ([SWS_EcuM_02811]).

Im Rahmen ihrer Ausführung arbeitet die Funktion die definierte StartPreOS-Sequenz und deren Aktivitäten in der exakt vorgegebenen Reihenfolge ab ([SWS_EcuM_02411], [SWS_EcuM_02684]). Ein wesentlicher Bestandteil dieser Phase ist die Überprüfung der Konfigurationskonsistenz: Das Modul prüft innerhalb von EcuM_Init, ob das entsprechende Strukturfeld mit dem Wert von ECUM_CONFIGCONSISTENCY_HASH identisch ist ([SWS_EcuM_02798]).

Darüber hinaus steuert EcuM_Init die Initialisierung der Treiber auf Mehrkernsystemen ([SWS_EcuM_04145]). Die Funktion ruft auf jedem einzelnen Kern die Callouts EcuM_AL_DriverInitZero sowie EcuM_AL_DriverInitOne auf ([SWS_EcuM_04145]). Für die Callout-Implementierungen gilt die Vorgabe sicherzustellen, dass auf dem jeweils aktiven Kern ausschließlich diejenigen MCAL-Module initialisiert werden, die auch tatsächlich auf diesem Kern ausgeführt werden ([SWS_EcuM_04145]).

Die synchrone und nicht-reentrante Funktion EcuM_StartupTwo implementiert den Zustand STARTUP II des ECU State Managers [SWS_EcuM_02838]. Die Schnittstelle wird über die Header-Datei EcuM.h deklariert und besitzt die Service-ID 0x1a [SWS_EcuM_02838]. Gemäß der Funktionssignatur void EcuM_StartupTwo(void) nimmt der Aufruf weder Eingabeparameter noch Ein-/Ausgabe- oder Ausgabeparameter entgegen und liefert keinen Rückgabewert an den Aufrufer zurück [SWS_EcuM_02838].

Wird das ECU-Manager-Modul durch die Funktion EcuM_StartupTwo aktiviert, führt es die Aktionen der StartPostOS-Sequenz aus [SWS_EcuM_02932].

Für die Integration bestehen wesentliche Vorgaben bezüglich des Aufrufkontexts und der Nebenläufigkeit: Die Funktion muss zwingend aus einem Task aufgerufen werden, der direkt als Konsequenz von StartOS gestartet wird [SWS_EcuM_02806]. Dies erfordert, dass der Aufruf von EcuM_StartupTwo entweder aus einem Autostart-Task heraus erfolgt oder aus einem Task, der explizit gestartet wird [SWS_EcuM_02806]. Da die Funktion als nicht-reentrant spezifiziert ist, darf kein gleichzeitiger oder mehrfacher Aufruf stattfinden [SWS_EcuM_02838].

Die synchrone Service-Funktion EcuM_Shutdown (Service-ID 0x02) wird über die Header-Datei EcuM.h bereitgestellt und übernimmt die Ausführungssteuerung zur Durchführung der Aktivitäten der Phase „GO OFF II“ [SWS_EcuM_02812]. Sie dient der abschließenden Terminierung des Abschaltprozesses [SWS_EcuM_02953].

Aufrufkontext und Semantik

Typischerweise wird die Funktion aus dem Shutdown-Hook aufgerufen [SWS_EcuM_02812]. Dieser Hook ist gemäß den Anforderungen explizit verpflichtet, EcuM_Shutdown aufzurufen, um den Abschaltvorgang zu beenden [SWS_EcuM_02953].

• Signatur: void EcuM_Shutdown(void) mit Service-ID 0x02 [SWS_EcuM_02812].
• Parameter: Es existieren weder Eingabe- noch Ausgabe- oder Ein-/Ausgabeparameter [SWS_EcuM_02812].
• Rückgabewert: Die Schnittstelle liefert keinen Rückgabewert zurück [SWS_EcuM_02812].
• Synchronität: Der Aufruf wird synchron ausgeführt [SWS_EcuM_02812].

Nebenläufigkeit und Kontrollfluss

In der Spezifikation ist EcuM_Shutdown als reentrant deklariert [SWS_EcuM_02812]. Für den Programmablauf gilt jedoch die strikte Anforderung, dass EcuM_Shutdown nicht zum Aufrufer zurückkehren darf [SWS_EcuM_02953]. Nach der Abarbeitung schaltet die Funktion das Steuergerät endgültig ab oder löst alternativ einen Reset aus [SWS_EcuM_02953].

Verwendung und Aufrufkontext

Die synchrone Funktion EcuM_SetState dient dem BswM dazu, dem EcuM einen Zustandswechsel mitzuteilen [SWS_EcuM_04122]. Als Eingabeparameter wird state vom Typ EcuM_StateType übergeben, welcher den durch den BswM vorgegebenen Zustand spezifiziert [SWS_EcuM_04122]. Die Funktion besitzt keinen Rückgabewert [SWS_EcuM_04122].

Funktionsweise und Zusammenspiel

Beim Aufruf setzt die Funktion den internen Zustand des EcuM auf den Wert des Parameters state [SWS_EcuM_04123]. Setzt der BswM auf diese Weise einen Zustand des EcuM, zeigt der EcuM den korrespondierenden Modus an die RTE an [SWS_EcuM_04116].

Fehlerbehandlung

Ist der übergebene Wert des Parameters state ungültig, verändert EcuM_SetState den EcuM-Zustand nicht [SWS_EcuM_04123]. Sofern das Development Error Reporting aktiviert ist, meldet die Funktion in diesem Fehlerfall zusätzlich den Fehler ECUM_E_STATE_PAR_OUT_OF_RANGE an das DET-Modul [SWS_EcuM_04123].

Nebenläufigkeit und Schnittstelle

Die Ausführung ist synchron und reentrant [SWS_EcuM_04122]. Der Dienst wird über die Header-Datei EcuM.h deklariert [SWS_EcuM_04122].

Verwendung

Die synchrone und reentrante Funktion EcuM_RequestRUN dient dazu, den RUN-Zustand beim ECU State Manager anzufordern [SWS_EcuM_04124]. Als Parameter wird über user vom Typ EcuM_UserType die Kennung der anfordernden Entität übergeben; berechtigt sind ausschließlich Benutzer, die dem Zustandsmanager bereits zur Konfigurationszeit bekannt gemacht wurden [SWS_EcuM_04124]. Die Funktion liefert E_OK zurück, wenn der EcuM die Anforderung akzeptiert hat, andernfalls E_NOT_OK [SWS_EcuM_04124]. Der Dienst ist über den Header EcuM.h deklariert [SWS_EcuM_04124].

Fehlerbehandlung und Einschränkungen

Anforderungen dürfen nicht verschachtelt werden: Ein einzelner Benutzer kann zu einem Zeitpunkt höchstens eine aktive RUN-Anforderung halten [SWS_EcuM_04125]. Erkennt EcuM_RequestRUN wiederholte oder doppelte Aufrufe durch denselben Benutzer, wird bei aktivierter Entwicklungserkennung der Fehlercode ECUM_E_MULTIPLE_RUN_REQUESTS an das DET gemeldet [SWS_EcuM_03024], [SWS_EcuM_04125].

Zusammenspiel

Jede mit EcuM_RequestRUN erfolgreich gesetzte Zustandsanforderung muss nach Abschluss der Aktivität wieder freigegeben werden. Hierfür steht der komplementäre, ebenfalls synchrone und reentrante Dienst EcuM_ReleaseRUN bereit, dem dieselbe Benutzer-ID übergeben wird [SWS_EcuM_04127].

Verwendung

Die synchrone Funktion EcuM_ReleaseRUN (Service-ID 0x04) dient der Freigabe einer zuvor über EcuM_RequestRUN registrierten RUN-Zustandsanforderung [SWS_EcuM_04127]. Die Schnittstelle wird über den Header EcuM.h bereitgestellt und ist primär für die Implementierung von AUTOSAR-Ports vorgesehen [SWS_EcuM_04127]. Als Eingabeparameter erwartet die Funktion die Benutzerkennung user vom Typ EcuM_UserType, welche die freigebende Entität innerhalb des Moduls eindeutig identifiziert [SWS_EcuM_04127].

Der Rückgabewert vom Typ Std_ReturnType signalisiert mit E_OK, dass die Freigabeanforderung erfolgreich durch das Modul akzeptiert wurde [SWS_EcuM_04127]. Konnte die Freigabe nicht verarbeitet werden, gibt der Dienst den Fehlerwert E_NOT_OK zurück [SWS_EcuM_04127].

Fehlerbehandlung und Nebenläufigkeit

Spezifische Fehlercodes, Entwicklungsfehler (DET) oder Produktionsfehler (DEM) werden in der Spezifikation nicht aufgeführt; die Ablehnung einer Anforderung äußert sich ausschließlich über die Rückgabe von E_NOT_OK [SWS_EcuM_04127]. Es ist anzunehmen (Interpretation:), dass eine Rückgabe von E_NOT_OK vermutlich dann erfolgt, wenn für die angegebene Benutzer-ID keine aktive Anforderung vorliegt oder ein unzulässiger Parameterwert übergeben wurde. Frage Q-cbe9031cffe1be81 (offen)

Die Funktion ist als reentrant deklariert und darf somit in nebenläufigen Ausführungskontexten aufgerufen werden [SWS_EcuM_04127]. Als funktionale Reihenfolgebedingung setzt der Aufruf zwingend voraus, dass der entsprechende Benutzer zuvor den Zustand über EcuM_RequestRUN angefordert hat [SWS_EcuM_04127].

Zusammenspiel

Das Modul EcuM stellt diesen Dienst bereit, um über definierte Ports das Halten des RUN-Zustands zu beenden [SWS_EcuM_04127]. Für die RTE-Konfiguration und das Zusammenspiel mit dem lokalen RTE-Laufzeitverhalten definiert die Spezifikation das interne Verhalten des EcuStateManager mit mehreren nebenläufig ausführbaren Runnable Entities [SWS_EcuM_03018].

Verwendung

Die synchrone Funktion EcuM_RequestPOST_RUN dient dem Anfordern des Zustands POST RUN beim ECU State Manager ([SWS_EcuM_04128]). Der Aufrufer identifiziert sich über den Parameter user, wobei jede anfordernde Entität dem Zustandsmanager bereits zur Konfigurationszeit bekannt gemacht worden sein muss ([SWS_EcuM_04128]). Der Dienst ist im Header EcuM.h deklariert, für die Implementierung von AUTOSAR-Ports vorgesehen und quittiert eine erfolgreiche Annahme mit E_OK bzw. eine Ablehnung mit E_NOT_OK ([SWS_EcuM_04128]).

Fehlerbehandlung

Sofern die Erkennung von Entwicklungsfehlern aktiviert ist, führt ein erneuter Aufruf durch denselben Benutzer dazu, dass EcuM_RequestPOST_RUN den Fehler ECUM_E_MULTIPLE_RUN_REQUESTS an das DET meldet ([SWS_EcuM_03025]). Interpretation: Im Fall solcher Mehrfachanforderungen oder bei ungültigen Benutzer-IDs dürfte der Dienst mit E_NOT_OK antworten ([SWS_EcuM_04128]). Frage Q-b5bbd7d5b53e76ba (offen)

Nebenläufigkeit und Zusammenspiel

Die Funktion ist reentrant ausgelegt ([SWS_EcuM_04128]). Im Modul müssen die Anforderungen für RUN und POST RUN strikt unabhängig voneinander über zwei eigenständige Variablen nachverfolgt werden ([SWS_EcuM_04128]). Jede über diesen Dienst registrierte Anforderung hält den POST-RUN-Zustand aktiv, bis sie explizit durch den komplementären Aufruf von EcuM_ReleasePOST_RUN wieder zurückgenommen wird ([SWS_EcuM_04129]).

Verwendung und Semantik

Die synchrone und reentrante Funktion EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]) dient der Freigabe einer zuvor mittels EcuM_RequestPOST_RUN gesetzten POST-RUN-Anforderung. Über den Eingabeparameter user vom Typ EcuM_UserType wird die Kennung der Entität übergeben, welche den POST-RUN-Status wieder freigibt. Die Schnittstelle ist über die Header-Datei EcuM.h verfügbar und primär für die Realisierung von AUTOSAR-Ports ausgelegt ([SWS_EcuM_04129]).

Rückgabewerte und Fehlerbehandlung

Die Funktion liefert den Status Std_ReturnType zurück ([SWS_EcuM_04129]):

• E_OK: Die Freigabeanforderung wurde vom ECU State Manager erfolgreich akzeptiert.
• E_NOT_OK: Die Freigabeanforderung wurde abgewiesen. Interpretation: Eine Abweisung mit E_NOT_OK dürfte vorliegen, wenn für den angegebenen Benutzer keine aktive Anforderung registriert war oder ein ungültiger Benutzerbezeichner übergeben wurde. Frage Q-67bd8594612defca (offen)

Nebenläufigkeit und Zusammenspiel

Der Dienst ist als reentrant spezifiziert ([SWS_EcuM_04129]), sodass zeitgleiche Aufrufe durch mehrere Entitäten zulässig sind. Die Funktion ist Bestandteil des internen Verhaltens des Moduls EcuM ([SWS_EcuM_03018]). Der Aufruf setzt logisch voraus, dass die Entität zuvor die Phase POST RUN angefordert hat ([SWS_EcuM_04129]). Interpretation: Typischerweise dürfte der Aufruf aus Software-Komponenten über RTE-Ports erfolgen, sobald deren Nachlaufaktivitäten vor dem Abschalten abgeschlossen sind. Frage Q-81f71656d4debb4a (offen)

Die synchrone Service-Funktion EcuM_SelectShutdownTarget dient der Auswahl des Shutdown-Ziels für das Steuergerät und wird über die Header-Datei EcuM.h sowie als Teil des Port-Interfaces des ECU-Manager-Moduls bereitgestellt [SWS_EcuM_02822]. Durch den Aufruf wird das interne Shutdown-Ziel auf den Wert des übergebenen Parameters shutdownTarget gesetzt [SWS_EcuM_00624].

Die Funktion erwartet zwei Eingabeparameter [SWS_EcuM_02822]:

• shutdownTarget: Bestimmt das ausgewählte Ziel für das Herunterfahren [SWS_EcuM_02822].
• shutdownMode: Enthält die Kennung eines Sleep-Modus (wenn das Ziel ECUM_SHUTDOWN_TARGET_SLEEP ist) oder eines Reset-Mechanismus (wenn das Ziel ECUM_SHUTDOWN_TARGET_RESET ist) gemäß Konfiguration [SWS_EcuM_02822].

Der Aufruf stößt keine unmittelbaren Einrichtungs- oder Ausführungsaktivitäten (Setup) an, sondern speichert die Werte lediglich für die spätere Verwendung in der Phase SHUTDOWN oder SLEEP [SWS_EcuM_02585].

Hinsichtlich der Nebenläufigkeit ist die Funktion reentrant spezifiziert [SWS_EcuM_02822]. Im RTE-Internal-Behavior des ECU State Managers ist die korrespondierende Runnable Entity SelectShutdownTarget mit canbeInvokedConcurrently = TRUE deklariert [SWS_EcuM_03018], wodurch parallele Aufrufe zulässig sind.

Der Rückgabewert vom Typ Std_ReturnType signalisiert mit E_OK, dass das neue Shutdown-Ziel erfolgreich gesetzt wurde, und mit E_NOT_OK, dass die Übernahme fehlschlug [SWS_EcuM_02822]. Konkrete Fehlerursachen für E_NOT_OK oder DET-Meldungen nennt die Spezifikation an dieser Stelle nicht; vermutlich führen unzulässige oder nicht konfigurierte Kombinationen von Ziel und Modus zur Ablehnung. Frage Q-e916f3a6ac0bf47e (offen)

Die synchrone Funktion EcuM_SelectShutdownCause dient der Auswahl der Ursache für ein Herunterfahren des Steuergeräts und ist über die Header-Datei EcuM.h verfügbar [SWS_EcuM_04050].

Verwendung und Semantik:

• Parameter: Der Eingangsparameter target vom Typ EcuM_ShutdownCauseType übergibt die ausgewählte Abschaltursache [SWS_EcuM_04050].
• Rückgabewert: Ein Rückgabewert vom Typ Std_ReturnType signalisiert mit E_OK, dass die neue Ursache erfolgreich gesetzt wurde, und mit E_NOT_OK, dass das Setzen fehlgeschlagen ist [SWS_EcuM_04050].
• Ausführung: Der Dienst arbeitet synchron unter der Service-ID 0x1b und ist reentrant spezifiziert [SWS_EcuM_04050].

Nebenläufigkeit und Zusammenspiel:

Die Funktion ist Teil des Port-Interfaces des Moduls ECU Manager [SWS_EcuM_04050]. Für die Konfiguration der lokalen RTE ist im internen Verhalten EcuStateManager die Runnable Entity SelectShutdownCause mit dem Symbol EcuM_SelectShutdownCause definiert, wobei die Eigenschaft canbeInvokedConcurrently = TRUE vergeben ist [SWS_EcuM_03018].

Fehlerbehandlung:

Im Spezifikationsumfang sind keine spezifischen DET- oder DEM-Meldungen ausgewiesen; Fehlerzustände beim Setzen der Ursache werden ausschließlich über den Rückgabewert E_NOT_OK angezeigt [SWS_EcuM_04050].

Die synchrone Service-Funktion EcuM_ClearWakeupEvent (Service-ID 0x16) dient dem Zurücksetzen von Wakeup-Ereignissen und steht über die Header-Datei EcuM.h zur Verfügung [SWS_EcuM_02828]. Als Parameter nimmt sie die Bitmaske sources vom Typ EcuM_WakeupSourceType entgegen und besitzt keinen Rückgabewert [SWS_EcuM_02828].

Beim Aufruf werden alle in sources als Bit gesetzten anstehenden Ereignisse aus drei internen Variablen des Moduls gelöscht [SWS_EcuM_02683]:

• aus der internen Variablen für anstehende Wakeup-Ereignisse (pending wakeup events),
• aus der internen Variablen für validierte Wakeup-Ereignisse (validated events) sowie
• aus der internen Variablen für abgelaufene Wakeup-Ereignisse (expired events) [SWS_EcuM_02683].

Hinsichtlich des Aufrufkontexts darf EcuM_ClearWakeupEvent flexibel aus dem Interrupt-Kontext, aus dem regulären OS-Kontext sowie aus einem OS-freien Kontext aufgerufen werden [SWS_EcuM_02807]. Gleichzeitig ist die Funktion jedoch verbindlich als nicht reentrant (Non-Reentrant) und nicht unterbrechbar (Non-Interruptible) spezifiziert [SWS_EcuM_02828]. Interpretation: Da die Funktion in unterschiedlichen Kontexten zulässig, aber nicht unterbrechbar ist, dürfte der Integrator oder Aufrufer organisatorisch sicherstellen müssen, dass keine gleichzeitigen oder einander unterbrechenden Aufrufe stattfinden. Frage Q-71a4b1b218505a1c (offen)

Die synchrone Funktion EcuM_AbortWakeupAlarm dient dem Abbruch eines zuvor durch einen Benutzer gesetzten Wakeup-Alarms [SWS_EcuM_04061]. Die Schnittstelle ist über die Header-Datei EcuM.h verfügbar und bildet einen Bestandteil der Port-Schnittstelle des ECU-Manager-Moduls [SWS_EcuM_04061].

Parameter und Rückgabewerte

• user (In): Kennung des Benutzers vom Typ EcuM_UserType, welcher den Wakeup-Alarm stornieren möchte [SWS_EcuM_04061]. Ein-/Ausgangs- oder reine Ausgangsparameter existieren nicht [SWS_EcuM_04061].
• E_OK: Der Dienst wurde erfolgreich ausgeführt und der Alarm storniert [SWS_EcuM_04061].
• ECUM_E_NOT_ACTIVE: Es wurde kein aktiver Alarm gefunden, welcher dem übergebenen Benutzer gehört [SWS_EcuM_04061].
• E_NOT_OK: Die Ausführung des Dienstes ist fehlgeschlagen [SWS_EcuM_04061].

Nebenläufigkeit und Zusammenspiel

Die Funktion besitzt die Service-ID 0x24 und ist reentrant spezifiziert [SWS_EcuM_04061]. Aufrufe können somit für unterschiedliche Benutzer nebenläufig erfolgen. Das interne Verhalten des ECU-Managers definiert die ausführbaren Einheiten zur Konfiguration der lokalen RTE [SWS_EcuM_03018]; als Teil des Modul-Port-Interfaces dürfte der Aufruf typischerweise durch Software-Komponenten über die RTE initiiert werden. Frage Q-2c8f004d9f00bbd3 (offen)

Die synchrone und reentrante Funktion EcuM_SetClock dient gemäß [SWS_EcuM_04064] dazu, die interne Uhrzeit des ECU State Managers auf einen vorgegebenen Wert zu setzen. Als Teil des Port-Interfaces des ECU Managers kann die Funktion über die Header-Datei EcuM.h eingebunden und aufgerufen werden [SWS_EcuM_04064].

Haupteinsatzzweck der Schnittstelle ist das Testen von Alarmdiensten: Alarme, deren regulärer Ablauf Tage in Anspruch nehmen würde, können durch gezieltes Setzen der Uhrzeit im Testbetrieb verifiziert werden [SWS_EcuM_04064]. Hierbei werden zwei Eingabeparameter übergeben:

• user (Typ EcuM_UserType): Kennung des Aufrufers bzw. Nutzers, der die Uhrzeit setzen möchte.
• time (Typ EcuM_TimeType): Absolute Zeitangabe in Sekunden seit dem Anschließen der Batterie (Battery Connect).

Als Rückgabewert liefert der Dienst den Status Std_ReturnType mit E_OK bei erfolgreicher Ausführung oder E_NOT_OK im Fehlerfall [SWS_EcuM_04064]. Konkrete Fehlerursachen oder DET-Meldungen sind an der Schnittstelle nicht spezifiziert; vermutlich führt die Übergabe unberechtigter Nutzerkennungen oder ungültiger Zeitwerte zur Rückgabe von E_NOT_OK. Frage Q-248768580c0309e8 (offen)

Hinsichtlich des internen Modulverhaltens und der RTE-Konfiguration bindet sich die Funktion in die Struktur der Runnable Entities des EcuStateManager ein [SWS_EcuM_03018].

Die synchrone Funktion EcuM_SelectBootTarget dient der Auswahl eines Boot-Targets für das Steuergerät und ist Teil des Port-Interfaces des ECU Managers sowie über den Header EcuM.h verfügbar [SWS_EcuM_02835]. Das gewünschte Ziel wird über den Eingabeparameter target vom Typ EcuM_BootTargetType übergeben [SWS_EcuM_02835].

Als Rückgabewert signalisiert die Funktion E_OK, wenn das neue Boot-Target vom EcuM akzeptiert wurde, andernfalls E_NOT_OK [SWS_EcuM_02835]. Die Implementierung muss das gewählte Ziel auf eine Weise abspeichern, die mit dem Bootloader kompatibel ist [SWS_EcuM_02247]. Der aktuell gesetzte Wert kann über den komplementären Dienst EcuM_GetBootTarget abgefragt werden [SWS_EcuM_02836].

Die Funktion ist als reentrant spezifiziert [SWS_EcuM_02835]; im Rahmen des internen Verhaltens für die RTE-Konfiguration ist die Runnable Entity SelectBootTarget mit canbeInvokedConcurrently = TRUE deklariert [SWS_EcuM_03018]. Einschränkend gilt, dass dieser Dienst ausschließlich für Software-Komponenten (SW-Cs) mit Bezug zu Diagnose bzw. Boot-Management vorgesehen ist und vom konkret eingesetzten Bootloader abhängen kann [SWS_EcuM_03000].

EcuM_ValidateWakeupEvent ist ein synchroner Dienst (Service-ID 0x14), der dem ECU Manager signalisiert, dass die im Parameter sources übergebenen Weckquellen erfolgreich validiert wurden ([SWS_EcuM_02829]). Nach dem Aufwachen wartet der ECU State Manager in der Validierungssequenz auf diese Bestätigung. Beim Aufruf stoppt die Funktion den laufenden Timeout-Timer der Validierung ([SWS_EcuM_02710]) und trägt die übergebenen Ereignisse per ODER-Verknüpfung der Bitmaske in die interne Variable für validierte Weckereignisse ein ([SWS_EcuM_04078]).

Die Funktion ist reentrant ([SWS_EcuM_02829]) und darf sowohl aus dem Task- als auch aus dem Interrupt-Kontext aufgerufen werden ([SWS_EcuM_02345]). Befindet sich der ECU Manager im Zustand RUN, bleibt der Aufruf für alle Weckquellen ohne Wirkung, sofern es sich nicht um Kommunikationskanäle handelt ([SWS_EcuM_02790]). Für Quellen, die einem Kommunikationskanal zugeordnet sind, entfaltet der Dienst dagegen in jeder Phase der ECU uneingeschränkte Wirkung ([SWS_EcuM_02791]).

Im Gesamtablauf interagiert der Dienst eng mit der Weckvalidierung und dem Kommunikationsmanagement:

• Validierungsprüfung: Der ECU Manager ruft zur Prüfung den Callout EcuM_CheckValidation auf; wird ein gültiges Weckereignis erkannt, erfolgt die Rückmeldung über EcuM_ValidateWakeupEvent ([SWS_EcuM_02925]).
• Konfiguration: Ist für eine Weckquelle kein Validierungsprotokoll konfiguriert (EcuMValidationTimeout), impliziert bereits EcuM_SetWakeupEvent den Aufruf von EcuM_ValidateWakeupEvent ([SWS_EcuM_02566]).
• Benachrichtigung: Ist für die Weckquelle EcuMComMChannelRef konfiguriert, ruft der Dienst ComM_EcuM_WakeUpIndication auf ([SWS_EcuM_02645]). Bei konfigurierter EcuMComMPNCRef wird zusätzlich für jeden referenzierten PNC ComM_EcuM_PNCWakeUpIndication ausgelöst ([SWS_EcuM_04140]).

Die synchrone und nicht-reentrante Callback-Funktion EcuM_ErrorHook (bereitgestellt über EcuM_Externals.h) wird vom ECU State Manager aufgerufen, sobald schwerwiegende Fehler auftreten, die eine reguläre Weiterverarbeitung unmöglich machen und das Anhalten des Steuergeräts erfordern [SWS_EcuM_02904]. Über den Übergabeparameter reason wird die spezifische Fehlerursache übermittelt [SWS_EcuM_02904].

Zu den definierten Fehlerursachen zählen ECUM_E_RAM_CHECK_FAILED und ECUM_E_CONFIGURATION_DATA_INCONSISTENT [SWS_EcuM_02904]. Schlägt die RAM-Prüfung beim Wakeup fehl, ist der ECU Manager verpflichtet, EcuM_ErrorHook mit dem Grund ECUM_E_RAM_CHECK_FAILED auszulösen [SWS_EcuM_02987]. Zudem erfolgt die Fehlerbehandlung über diesen Hook, wenn ein Aufruf einer Betriebssystemfunktion fehlschlägt und keine andere Fehlerreaktion spezifiziert ist; der EcuM verbleibt in diesem Fall im bisherigen Zustand [SWS_EcuM_04139].

Für den Systemintegrator gelten bei der Implementierung folgende Rahmenbedingungen:

• Stopp-Modalität des Steuergeräts: Der Integrator wählt die Art und Weise, wie die ECU stillgelegt wird (z. B. Reset, Halt, Neustart oder sicherer Zustand) [SWS_EcuM_02904]. Interpretation: Bei drastischen Maßnahmen wie einem Reset oder Halt dürfte die Funktion typischerweise nicht mehr zur regulären Ablaufsteuerung zurückkehren. Frage Q-59c23e3a2569f670 (offen)
• Fehlermeldung an das DEM: Es liegt im Ermessen des Integrators, ob der Fehler an das DEM weitergeleitet wird, sofern sichergestellt ist, dass das DEM keine beschädigten NVRAM-Blöcke beschreibt [SWS_EcuM_02987].

Verwendung und Aufrufbedingungen

Die Callout-Funktion EcuM_AL_SetProgrammableInterrupts wird vom Modul ECU State Manager aufgerufen, um auf Steuergeräten mit programmierbaren Interrupt-Controllern die entsprechenden Interrupts zu konfigurieren und zu setzen [SWS_EcuM_04085]. Die Ausführung dieses Callouts erfolgt jedoch nur dann, wenn der Konfigurationsparameter EcuMSetProgrammableInterrupts auf den Wert true festgelegt ist [SWS_EcuM_04085]. Ist dieser Parameter nicht aktiviert, unterbleibt der Aufruf [SWS_EcuM_04085]. Für Integratoren und Plattformtreiber wird die Deklaration der Schnittstelle über die Header-Datei EcuM_Externals.h bereitgestellt [SWS_EcuM_04085].

Die Schnittstelle besitzt die Syntax void EcuM_AL_SetProgrammableInterrupts (void) und ist der Service-ID 0x4A zugeordnet [SWS_EcuM_04085]. Der Aufruf erfolgt vollständig parameterlos: Es werden weder Eingangs-, Ein-/Ausgangs- noch Ausgangsparameter übergeben, und die Funktion liefert keinen Rückgabewert an das aufrufende Modul zurück [SWS_EcuM_04085].

Nebenläufigkeit und Einschränkungen

Für EcuM_AL_SetProgrammableInterrupts ist in der Spezifikation ein asynchrones Ausführungsverhalten (Asynchronous) festgelegt [SWS_EcuM_04085]. In Bezug auf die Nebenläufigkeit ist die Funktion als nicht reentrant (Non Reentrant) klassifiziert [SWS_EcuM_04085]. Das bedeutet für die Integration, dass parallele oder verschachtelte Aufrufe der Schnittstelle unzulässig sind und die interruptbezogene Konfiguration ohne gleichzeitige Wiedereintritte ablaufen muss [SWS_EcuM_04085].

Verwendung

Die Callout-Funktion EcuM_AL_DriverInitZero (Service-ID 0x31) wird synchron aufgerufen, besitzt weder Parameter noch einen Rückgabewert und ist nicht reentrant [SWS_EcuM_02905]. Deklariert ist sie über den Header EcuM_Externals.h [SWS_EcuM_02905]. Die Funktion dient dazu, frühe Treiberinitialisierungen sowie grundlegende hardwarebezogene Startaktivitäten bereitzustellen, die zwingend notwendig sind, um nachfolgend die Post-Build-Konfigurationsdaten laden zu können [SWS_EcuM_02905].

Einschränkungen und Mehrkernbetrieb

Für die Implementierung und Ausführung gelten spezifische Vorgaben und Restriktionen:

• Konfigurationsklassen: Zu diesem frühen Zeitpunkt dürfen ausschließlich Module verwendet werden, die als Pre-Compile oder Link-Time konfigurierbar sind [SWS_EcuM_02905]. Post-Build-konfigurierbare Treiber stehen hier noch nicht zur Verfügung.
• Aufrufkontext: Die Funktion wird durch EcuM_Init auf jedem Core des Systems aufgerufen [SWS_EcuM_04145].
• Core-spezifische Initialisierung: Die Implementierung des Callouts muss sicherstellen, dass auf dem aktuell aktiven Core nur diejenigen MCAL-Module initialisiert werden, die tatsächlich auf diesem spezifischen Core ausgeführt werden [SWS_EcuM_04145].

Rückgabewerte, spezifische Fehlercodes oder Benachrichtigungen über DET oder DEM sind für diesen Callout nicht definiert [SWS_EcuM_02905].

Die Funktion EcuM_DeterminePbConfiguration ([SWS_EcuM_02906]) ist ein synchroner Callout des ECU State Managers, der über die Header-Datei EcuM_Externals.h bereitgestellt wird und die Service-ID 0x32 besitzt. Die Schnittstelle besitzt keine Eingangs-, Ausgangs- oder Ein-/Ausgangsparameter ([SWS_EcuM_02906]). Ihr zentraler Zweck besteht darin, während des Hochlaufprozesses anhand von Hardware- oder Speicherbedingungen festzulegen, welcher Post-Build-Konfigurationsdatensatz für den weiteren Verlauf des Systemstarts herangezogen werden soll ([SWS_EcuM_02906]).

Zur Festlegung der Konfiguration soll der Callout externe oder residente Kriterien wie den Status eines Port-Pins oder einen Wert im NVRAM auswerten ([SWS_EcuM_02906]). Anschließend muss die Funktion diese Konfigurationsdaten in ein Speichersegment laden, auf das sämtliche BSW-Module zugreifen können ([SWS_EcuM_02906]). Als Rückgabewert liefert sie einen Zeiger vom Typ const EcuM_ConfigType* auf die EcuM-Post-Build-Konfiguration zurück ([SWS_EcuM_02906]). Dieser Zeiger bildet die gemeinsame Ausgangsbasis für die gesamte BSW, da die Struktur Zeiger auf die jeweiligen Post-Build-Konfigurationen aller übrigen BSW-Module enthält ([SWS_EcuM_02906]).

Hinsichtlich des Aufrufverhaltens ist die Funktion als synchron und nicht reentrant (Non Reentrant) spezifiziert ([SWS_EcuM_02906]). Spezifische Fehlercodes, besondere Fehlerrückgabewerte sowie Schnittstellen zu DET oder DEM sind für diesen Callout nicht definiert ([SWS_EcuM_02906]). Es dürfte daher als Interpretation der Vorgaben gelten, dass eine anwendungsspezifische Callout-Implementierung Fehlerzustände eigenständig behandeln muss, da das Fehlen eines gültigen Konfigurationszeigers vermutlich das geordnete Hochfahren der abhängigen BSW-Module verhindern würde. Frage Q-b9487647fb39a2e2 (offen)

Verwendung und Semantik

Die Funktion EcuM_AL_DriverInitOne ist eine Callout-Funktion des ECU-Zustands-Managers (EcuM), die über die Header-Datei EcuM_Externals.h bereitgestellt wird [SWS_EcuM_02907]. Ihre primäre Aufgabe besteht darin, im Fall eines Power-on-Resets die Initialisierung von Treibern sowie weitere hardwarebezogene Startaktivitäten der Steuereinheit durchzuführen [SWS_EcuM_02907]. Da es sich um einen Callout handelt, dürfte die konkrete Implementierung der Hardware- und Treiberinitialisierung durch den jeweiligen Systemintegrator erfolgen. Frage Q-e22baf2fa31cf075 (offen)

Die Schnittstelle besitzt die C-Signatur void EcuM_AL_DriverInitOne (void) und ist der Service-ID 0x33 zugeordnet [SWS_EcuM_02907]. Sie akzeptiert keinerlei Eingangsparameter und liefert auch keinen Rückgabewert an den Aufrufer zurück [SWS_EcuM_02907].

Nebenläufigkeit und Einschränkungen

Für den Aufruf und das Laufzeitverhalten gelten nach [SWS_EcuM_02907] folgende Randbedingungen:

• Synchronität: Die Ausführung erfolgt synchron (Synchronous), sodass der Aufrufer auf den Abschluss der Startaktivitäten wartet.
• Reentranz: Die Funktion ist als nicht reentrant (Non Reentrant) definiert; ein gleichzeitiger oder unterbrechender Mehrfachaufruf ist unzulässig.
• Aufrufkontext: Die Aktivierung ist ausschließlich für die Initialisierungsphase unmittelbar nach einem Power-on-Reset spezifiziert.

Fehlerbehandlung

Da EcuM_AL_DriverInitOne den Rückgabetyp void aufweist, existiert auf Schnittstellenebene keine direkte Rückmeldung über Erfolg oder Fehler der Initialisierung [SWS_EcuM_02907]. Spezifische Fehlercodes, DET- oder DEM-Meldungen sind im vorliegenden Spezifikationsumfang für diesen Callout nicht definiert.

Die Funktion EcuM_LoopDetection ist ein Callout des ECU State Managers mit der Service-ID 0x4B, der über die Header-Datei EcuM_Externals.h bereitgestellt wird [SWS_EcuM_04137].

Verwendung und Aufrufkontext

Sofern der Konfigurationsparameter EcuMResetLoopDetection auf true gesetzt ist, wird dieser Callout bei jedem Hochlauf (Startup) synchron aufgerufen [SWS_EcuM_04137]. Die Funktion besitzt weder Eingabe-, Ein-/Ausgabe- noch Ausgabeparameter und liefert keinen Rückgabewert (Signatur: void EcuM_LoopDetection (void)) [SWS_EcuM_04137].

Nebenläufigkeit und Einschränkungen

Die Ausführung von EcuM_LoopDetection ist als synchron und nicht reentrant (Non Reentrant) spezifiziert [SWS_EcuM_04137]. Da es sich um einen Callout handelt, obliegt die konkrete Implementierung der Schleifenerkennung typischerweise dem Integrator oder Anwender, um wiederholte Reset-Schleifen beim Systemstart zu erfassen.

Verwendung

Die Funktion EcuM_OnGoOffOne dient dazu, das Erreichen des Systemzustands GO OFF I anzukündigen und dem Systemdesigner die Möglichkeit zu geben, unmittelbar vor dem Wechsel entsprechende Maßnahmen zu ergreifen [SWS_EcuM_02916]. Die Funktion wird synchron ausgeführt, erwartet keine Übergabeparameter (weder in noch inout) und liefert keinen Rückgabewert (void) [SWS_EcuM_02916]. Da die Schnittstelle über die Header-Datei EcuM_Externals.h deklariert wird, dürfte es sich nachvollziehbar um eine anwenderspezifische Callout-Funktion handeln, die im Integrationscode implementiert wird [SWS_EcuM_02916]. Frage Q-93de53c47a5a6142 (offen)

Fehlerbehandlung

In der Spezifikation zu EcuM_OnGoOffOne sind weder Entwicklungsfehler (DET) noch Produktionsfehler (DEM) oder spezifische Fehlerrückgabewerte aufgeführt [SWS_EcuM_02916]. Daraus lässt sich schließen, dass der Aufrufer kein standardisiertes Fehlermanagement erwartet und etwaige Ausnahmefälle innerhalb der anwenderspezifischen Implementierung autonom behandelt werden müssen [SWS_EcuM_02916].

Nebenläufigkeit und Einschränkungen

Für den Aufrufkontext und das Laufzeitverhalten sind folgende Eigenschaften festgelegt [SWS_EcuM_02916]:

• Reentranz: Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert und darf keinesfalls parallel oder verschachtelt aufgerufen werden [SWS_EcuM_02916].
• Synchronizität: Die Semantik ist strikt synchron (Synchronous), sodass der Aufrufer auf die vollständige Rückkehr der Funktion wartet [SWS_EcuM_02916].
• Service-ID: Der Dienst wird intern durch den hexadezimalen Bezeichner 0x3C repräsentiert [SWS_EcuM_02916].

Aufgrund des synchronen Verhaltens und des bevorstehenden Wechsels in den Zustand GO OFF I ist anzunehmen, dass blockierende Operationen vermieden werden sollten, um den Abschalt- bzw. Übergangsprozess nicht unzulässig zu verzögern [SWS_EcuM_02916]. Frage Q-93f5e23c581f0c38 (offen)

Die synchrone Funktion EcuM_OnGoOffTwo dient laut Spezifikation dazu, dem Systemdesigner die Benachrichtigung zu ermöglichen, dass der Zustand GO OFF II unmittelbar bevorsteht [SWS_EcuM_02917]. Der Aufruf erfolgt parameterlos ohne In-, Inout- oder Out-Parameter und liefert keinen Rückgabewert an den Aufrufer zurück [SWS_EcuM_02917].

Hinsichtlich des Ausführungskontexts und der Nebenläufigkeit ist die Schnittstelle mit der Service-ID 0x3D versehen und als nicht reentrant (Non Reentrant) spezifiziert [SWS_EcuM_02917]. Sie wird über den Header EcuM_Externals.h bereitgestellt [SWS_EcuM_02917]. Interpretation: Da die Deklaration in EcuM_Externals.h liegt und der Benachrichtigung des Systemdesigners dient, dürfte die Funktion als synchroner Callout des Steuergerätemanagements konzipiert sein, der vor dem Wechsel in den Zustand GO OFF II aufgerufen wird. Frage Q-bb0ae6e4632de827 (offen)

Aufgrund der Eigenschaft als nicht reentrante Schnittstelle darf der Aufruf nicht parallel oder unterbrechend wiederholt werden [SWS_EcuM_02917]. Spezifische Fehlercodes, Rückmeldungen an DET oder DEM sowie gesonderte Fehlerbehandlungsmechanismen sind im Spezifikationsumfang nicht definiert [SWS_EcuM_02917].

Verwendung

Die Callout-Funktion EcuM_AL_SwitchOff ist Teil des Moduls ECU State Manager (EcuM) und dient dazu, den anwenderspezifischen Code für das Abschalten der Spannungsversorgung des Steuergeräts aufzunehmen [SWS_EcuM_02920]. Die Schnittstelle ist synchron definiert, besitzt die Service-ID 0x3E und wird über die Header-Datei EcuM_Externals.h bereitgestellt [SWS_EcuM_02920].

Gemäß Spezifikation nimmt die Funktion weder Eingangs-, Ein-/Ausgangs- noch Ausgangsparameter entgegen und besitzt keinen Rückgabewert (void) [SWS_EcuM_02920]. Kann die Hardware des Steuergeräts sich nicht selbstständig stromlos schalten, sieht die Spezifikation vor, dass stattdessen das Auslösen eines Resets eine adäquate Reaktion darstellen kann [SWS_EcuM_02920].

Zusammenspiel und Nebenläufigkeit

Der Aufruf von EcuM_AL_SwitchOff erfolgt zwingend durch das Modul ECU Manager, sobald das gewählte Shutdown-Ziel OFF lautet [SWS_EcuM_04075]. Bezüglich des Nebenläufigkeitsverhaltens ist der Callout als nicht reentrant (Non Reentrant) festgelegt [SWS_EcuM_02920]. Interpretation: Da das Ziel der Funktion die vollständige Trennung der Stromversorgung bzw. hilfsweise ein Reset ist, dürfte dieser Callout den abschließenden Schritt der Abschaltsequenz darstellen, nach welchem keine weitere reguläre Programmausführung mehr stattfindet. Frage Q-e8a1aaa1413bbea9 (offen)

Fehlerbehandlung

Für den Callout sind in der Spezifikation weder spezifische Fehlercodes noch Fehlerbehandlungsmechanismen oder Meldungen an DET oder DEM vorgesehen [SWS_EcuM_02920].

Das Callout EcuM_AL_Reset dient der Aufnahme des integrationsspezifischen Codes, der für das Zurücksetzen des Steuergeräts zuständig ist ([SWS_EcuM_04065]). Die Schnittstelle wird über die Header-Datei EcuM_Externals.h deklariert und besitzt die Service-ID 0x4C ([SWS_EcuM_04065]).

Der Aufruf der Funktion erfolgt synchron und ist als nicht reentrant (Non Reentrant) definiert ([SWS_EcuM_04065]). Als einziger Eingabeparameter wird reset vom Typ EcuM_ResetType übergeben, der die konkrete Art des auszuführenden Resets festlegt ([SWS_EcuM_04065]). Die Funktion besitzt keinen Rückgabewert (void) und verfügt über keine Parameter für Ausgabe oder Ein-/Ausgabe ([SWS_EcuM_04065]).

Im Zusammenspiel der Shutdown-Phase ist festgelegt, dass das Modul ECU Manager das Callout EcuM_AL_Reset zwingend aufrufen muss, wenn das Ziel des Herunterfahrens auf RESET gesetzt ist ([SWS_EcuM_04074]). Für das Callout sind in der Spezifikation weder Fehlercodes noch Benachrichtigungen an DET oder DEM vorgesehen ([SWS_EcuM_04065]). Interpretation: Das Callout dürfte hardwarenahe Steuerbefehle ausführen, die direkt das Zurücksetzen der MCU bewirken. Frage Q-1e318404843faabd (offen)

Die Funktion EcuM_EnableWakeupSources ist ein synchroner Callout des ECU-Managers mit der Service-ID 0x3F, der über den Header EcuM_Externals.h deklariert wird [SWS_EcuM_02918]. Sie dient dazu, den Systementwickler darüber zu informieren, dass der Zustand SLEEP bevorsteht, damit die im Bitfeld wakeupSource (Typ EcuM_WakeupSourceType) angegebenen Weckquellen entsprechend vorbereitet und eingestellt werden können [SWS_EcuM_02918].

Verwendung und Zusammenspiel

Der ECU-Manager führt EcuM_EnableWakeupSources aus, um die Weckquellen für den nächsten Sleep-Modus zu konfigurieren; dies geschieht für jede Weckquelle, die in EcuMWakeupSourceMask für den anvisierten Sleep-Modus konfiguriert ist [SWS_EcuM_02389]. Die Funktion besitzt keinen Rückgabewert (void) und erwartet als Eingabeparameter das Bitfeld wakeupSource [SWS_EcuM_02918].

Nebenläufigkeit und Einschränkungen

• Reentranz: Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_EcuM_02918].
• Synchronizität: Die Abarbeitung erfolgt synchron [SWS_EcuM_02918].
• Fehlerbehandlung: Im Spezifikationsumfang der Schnittstelle sind keine spezifischen DET- oder DEM-Fehlermeldungen definiert [SWS_EcuM_02918].

Die Funktion EcuM_GenerateRamHash dient der Erzeugung eines RAM-Prüfwerts im Kontext des ECU State Managers, wobei die Spezifikation bezüglich der Funktionsweise auf EcuM_CheckRamHash verweist [SWS_EcuM_02919]. Der erzeugte Prüfwert dient vermutlich der späteren Integritätsprüfung des Arbeitsspeichers im Zusammenhang mit Schlaf- oder Ruhezuständen. Frage Q-7f316b389e1609c0 (offen)

Verwendung und Schnittstelle

Der Service besitzt die Service-ID 0x40 und die Signatur void EcuM_GenerateRamHash(void) [SWS_EcuM_02919]. Die Funktion besitzt weder Eingabe-, Ausgabe- noch Ein-/Ausgabeparameter und liefert keinen Rückgabewert. Die Ausführung erfolgt synchron.

Nebenläufigkeit und Einschränkungen

Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_EcuM_02919]. Sie darf folglich nicht unterbrechend oder parallel aus mehreren Kontexten aufgerufen werden. Bereitgestellt wird die Deklaration über die Header-Datei EcuM_Externals.h [SWS_EcuM_02919]. Interpretation: Durch die Definition in EcuM_Externals.h dürfte es sich um einen anwenderspezifisch zu implementierenden Callout handeln, der vom ECU State Manager zu einem passenden Zeitpunkt im Zustandsablauf aufgerufen wird. Frage Q-2f53f1a19cee079c (offen)

Fehlerbehandlung

Für EcuM_GenerateRamHash sind in [SWS_EcuM_02919] keine spezifischen Fehlercodes sowie weder DET- noch DEM-Meldungen definiert.

Verwendung und Aufrufkontext

Die Funktion EcuM_SleepActivity stellt einen Callout des ECU State Managers dar, der in der Header-Datei EcuM_Externals.h mit der Service-ID 0x41 bereitgestellt wird [SWS_EcuM_02928]. Der Aufruf erfolgt periodisch in allen Schlafmodi mit reduziertem Prozessortakt (reduced clock sleep modes) [SWS_EcuM_02928]. Die Funktion besitzt die Signatur void EcuM_SleepActivity(void), arbeitet synchron und nimmt weder Eingabe-, Ausgabe- noch Ein-/Ausgabeparameter entgegen [SWS_EcuM_02928].

Funktionale Aufgaben und Zusammenspiel

Zweck dieses Callouts ist die Durchführung von Aktivitäten während des Schlafs: Es ist explizit vorgesehen und gestattet, innerhalb von EcuM_SleepActivity Weckquellen zyklisch abzufragen (Polling) [SWS_EcuM_02928]. Zudem dürfen direkt aus dem Callout heraus Weck-Benachrichtigungsfunktionen aufgerufen werden, um dem ECU State Manager das Beenden des Schlafzustands anzuzeigen [SWS_EcuM_02928].

Nebenläufigkeit und Einschränkungen

Die Schnittstelle ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_EcuM_02928]. Da der Callout keinen Rückgabewert liefert und keine Fehlerparameter definiert sind, erfolgt über die Funktionsschnittstelle keine direkte Fehlerbehandlung über Fehlercodes oder Fehlermelder wie DET oder DEM [SWS_EcuM_02928].

Verwendung und Aufrufkontext

Die synchrone Schnittstelle EcuM_StartCheckWakeup wird laut [SWS_EcuM_04096] von der ECU-Firmware aufgerufen, um den Timer CheckWakeupTimer für eine bestimmte Weckquelle zu starten. Der Funktion wird hierzu der Parameter WakeupSource vom Typ EcuM_WakeupSourceType übergeben. Sie besitzt keinen Rückgabewert (void) und wird über die Header-Datei EcuM_Externals.h bereitgestellt.

Ablauf und Bedingungen

Die Ausführung der Funktion hängt von der Konfiguration der Weckquelle ab [SWS_EcuM_04096]:

• Ist für die betreffende Weckquelle EcuMCheckWakeupTimeout > 0 konfiguriert, wird der zugehörige CheckWakeupTimer gestartet.
• Gilt EcuMCheckWakeupTimeout <= 0, wird der Funktionsaufruf durch das EcuM vollständig ignoriert.

Nebenläufigkeit und Fehlerbehandlung

Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_EcuM_04096]. Der Aufrufer muss folglich sicherstellen, dass Aufrufe für dieselbe oder andere Weckquellen nicht nebenläufig stattfinden. Spezifische Fehlercodes sowie Benachrichtigungen an DET oder DEM sind für diesen Aufruf nicht spezifiziert; ein Aufruf bei nicht positivem Timeout bleibt laut Spezifikation folgenlos, was vermutlich als tolerantes Abfangen irrelevanter Timer-Prüfungen interpretiert werden darf [SWS_EcuM_04096]. Frage Q-19d98b03d3ee7504 (offen)

Der Callout EcuM_CheckWakeup dient der Prüfung und dem Polling von Weckquellen sowie der Konfiguration der PLL nach einem Weckereignis [SWS_EcuM_02929]. Die Funktion wird über die Header-Datei EcuM_Externals.h bereitgestellt und besitzt die Service-ID 0x42 [SWS_EcuM_02929].

Aufrufkontext und Semantik

• Signatur und Parameter: Die Funktion wird synchron ausgeführt (Synchronous), besitzt keinen Rückgabewert und erwartet als Eingangsparameter wakeupSource vom Typ EcuM_WakeupSourceType [SWS_EcuM_02929].
• Aufrufer: Der Callout wird vom EcuM aufgerufen, um eine Weckquelle zyklisch abzufragen. Zudem ist er zwingend von der Interrupt-Service-Routine (ISR) einer Weckquelle aufzurufen, um die PLL aufzusetzen und weitere Weckquellen zu prüfen, die am selben Interrupt angebunden sind [SWS_EcuM_02929].
• Polling-Schleife: In der Polling-Sequenz ruft der EcuM die Callouts EcuM_SleepActivity und EcuM_CheckWakeup wiederholt in einer blockierenden Schleife auf, bis ein Weckereignis als anstehend oder validiert gemeldet wird [SWS_EcuM_03020].

Einschränkungen und Fehlerbehandlung

Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_EcuM_02929]. Da Aufrufe sowohl aus dem blockierenden Ablauf der Polling-Sequenz als auch aus ISR-Kontexten erfolgen, dürfte die Integration sicherstellen müssen, dass keine unkoordinierten nebenläufigen Aufrufe stattfinden. Frage Q-8bc8f164670a0911 (offen) Spezifische Fehlercodes oder Fehlerbenachrichtigungen an DET oder DEM sind für diesen Callout nicht definiert.

Die synchrone Funktion EcuM_EndCheckWakeup wird von Software-Modulen aufgerufen, wenn die asynchrone Überprüfung einer Weckquelle (wie etwa bei einem asynchronen CAN-Transceiver-Treiber) ein negatives Ergebnis liefert, also kein Weckereignis durch diese Quelle vorliegt [SWS_EcuM_02927].

Verwendung und Parameter

Über den Eingangsparameter WakeupSource vom Typ EcuM_WakeupSourceType wird diejenige Weckquelle übergeben, für die der zugehörige Überwachungstimer abgebrochen werden soll [SWS_EcuM_02927]. Die Funktion liefert keinen Rückgabewert (void) und verfügt über keine Ein-/Ausgangs- oder Ausgangsparameter [SWS_EcuM_02927].

Funktionsweise und Nebenläufigkeit

• Die Funktion bricht den Timer CheckWakeupTimer für die spezifizierte Weckquelle ab; mit dem Abbruch dieses Timers gilt die Überprüfung der Weckquelle als abgeschlossen [SWS_EcuM_02927].
• Die Schnittstelle ist als synchron und nicht reentrant (Non Reentrant) definiert [SWS_EcuM_02927].
• Die Deklaration wird über die Header-Datei EcuM_Externals.h zur Verfügung gestellt [SWS_EcuM_02927].

Die Funktion EcuM_CheckRamHash ist ein synchroner, nicht reeintranter Callout (deklariert in EcuM_Externals.h), der einen Integritätstest des RAM-Speichers bereitstellt [SWS_EcuM_02921]. Die Funktion besitzt keine Parameter und liefert einen Statuswert vom Typ uint8 zurück: Der Wert 0 signalisiert ein Fehlschlagen des Tests, während jeder andere Wert ein erfolgreiches Bestehen anzeigt [SWS_EcuM_02921].

Gemäß [SWS_EcuM_02863] ruft das Modul EcuM vor dem Anhalten des Mikrocontrollers zunächst [SWS_EcuM_02919] auf und führt nach der Rückkehr aus dem Halt-Zustand EcuM_CheckRamHash aus. Ziel ist die Verifikation, dass der RAM-Inhalt auch nach einer langen SLEEP-Phase konsistent geblieben ist [SWS_EcuM_02921].

Für die Implementierung und den Ablauf gelten folgende Randbedingungen:

• Algorithmus und Prüfbereich: Die Prüffunktion wird vom System-Designer bereitgestellt; sie muss nicht erschöpfend sein, soll jedoch schnell ausführen und Fehler hinreichend sicher erkennen [SWS_EcuM_02921]. Zu prüfende Bereiche sind sorgfältig zu wählen; Stack-Inhalte des ausführenden Tasks können in der Regel nicht geprüft werden [SWS_EcuM_02921].
• Task-Struktur: Als bewährte Praxis gilt, Hash-Generierung und -Prüfung im selben, nicht unterbrechbaren Task bei minimaler Zwischenaktivität auszuführen [SWS_EcuM_02921].
• Multi-Core: Bei mehreren Prozessorkernen mit Satelliten-EcuMs wird der Callout ausschließlich durch den Master-EcuM aufgerufen und prüft nur Daten in dessen Reichweite [SWS_EcuM_02863], [SWS_EcuM_02921].

Spezifische DET- oder DEM-Meldungen sind für diesen Callout nicht definiert; die Fehlerreaktion bei Rückgabewert 0 dürfte vermutlich im Ermessen des übergeordneten System-Designs liegen [SWS_EcuM_02921]. Frage Q-473ef8617db29fe3 (offen)

Die synchrone Schnittstelle EcuM_DisableWakeupSources mit der Service-ID 0x44 dient dazu, die im Bitfeld-Parameter wakeupSource vom Typ EcuM_WakeupSourceType definierten Weckquellen so zu konfigurieren, dass diese das Steuergerät nicht mehr aufwecken können [SWS_EcuM_02922]. Die Funktionssignatur lautet void EcuM_DisableWakeupSources (EcuM_WakeupSourceType wakeupSource) [SWS_EcuM_02922].

Für den Aufrufkontext und die Integration gelten nach der Spezifikation die folgenden Eigenschaften:

• Aufrufer und Header: Die Funktion wird durch das Modul ECU Manager aufgerufen und über die Header-Datei EcuM_Externals.h bereitgestellt [SWS_EcuM_02922].
• Parameter und Rückgabewerte: Als einziger Eingabeparameter wird das Bitfeld wakeupSource übergeben. Die Funktion besitzt weder Ein-/Ausgangs- noch Ausgangsparameter und liefert keinen Rückgabewert (void) zurück [SWS_EcuM_02922].
• Ausführungssemantik und Nebenläufigkeit: Die Verarbeitung erfolgt synchron. Zudem ist die Funktion als nicht reentrant (Non Reentrant) spezifiziert, sodass gleichzeitige oder verschachtelte Aufrufe vermieden werden müssen [SWS_EcuM_02922].

Bezüglich der Fehlerbehandlung enthält die Spezifikation für diesen Funktionsaufruf weder spezifische Fehlercodes noch Benachrichtigungen an das DET oder DEM [SWS_EcuM_02922].

Der Callout EcuM_AL_DriverRestart wird über die Header-Datei EcuM_Externals.h deklariert und besitzt die Service-ID 0x45 [SWS_EcuM_02923]. Die Funktion besitzt die Signatur void EcuM_AL_DriverRestart (void), erfordert keine Übergabeparameter und liefert keinen Rückgabewert [SWS_EcuM_02923]. Zweck dieser Schnittstelle ist es, im Weckfall (Wakeup Case) die Treiberinitialisierung sowie weitere hardwarebezogene Aktivitäten während der Startphase bereitzustellen [SWS_EcuM_02923].

Für die Integration und das Zusammenspiel mit dem Modul EcuM gelten verbindliche Vorgaben:

• Für die Re-Initialisierung während der Phase WakeupRestart muss der Integrator einen Restart-Block in den Integrationscode für EcuM_AL_DriverRestart einbinden, welcher die konfigurierte Liste EcuMDriverRestartList verwendet [SWS_EcuM_02947] [SWS_EcuM_02923].
• Die Liste EcuMDriverRestartList kann Treiber enthalten, die als Weckquellen (Wakeup Sources) fungieren [SWS_EcuM_02562]. In diesem Fall muss EcuM_AL_DriverRestart den Auslösemechanismus des Callbacks zur Weckerkennung („wakeup detected“) dieser Treiber wieder scharfschalten (re-arm) [SWS_EcuM_02562].

Hinsichtlich des Laufzeitverhaltens ist die Funktion als synchron und nicht reentrant definiert [SWS_EcuM_02923]. Da es sich um anwendungsspezifischen Integrationscode handelt, definiert die Spezifikation an dieser Schnittstelle keine eigenen Fehlercodes sowie keine standardisierten Meldungen an DET oder DEM.

Die Callout-Funktion EcuM_StartWakeupSources dient dazu, die übergebene(n) Weckquelle(n) so zu starten und in Betrieb zu nehmen, dass sie für die anschließende Durchführung der Weckvalidierung (Wakeup Validation) vorbereitet sind [SWS_EcuM_02924].

Verwendung und Aufrufkontext

Die Funktion ist als synchroner Aufruf mit der Service-ID 0x46 spezifiziert, besitzt keinen Rückgabewert (void) und wird über die Header-Datei EcuM_Externals.h zur Verfügung gestellt [SWS_EcuM_02924].

• Parameter wakeupSource (in): Übergibt die zu startende Weckquelle beziehungsweise eine Bitmaske mehrerer Weckquellen vom Typ EcuM_WakeupSourceType an die Callout-Funktion [SWS_EcuM_02924]. Zusätzliche Ein- oder Ausgabeparameter (inout/out) existieren nicht [SWS_EcuM_02924].

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Ausführungsumgebung ist EcuM_StartWakeupSources als nicht reentrant (Non Reentrant) klassifiziert [SWS_EcuM_02924]. Aufrufer müssen daher sicherstellen, dass die Funktion nicht zeitgleich aus unterbrechenden Interrupt-Service-Routinen oder parallelen Tasks ausgeführt wird.

Zusammenspiel und Fehlerbehandlung

Da EcuM_StartWakeupSources als Callout deklariert ist, obliegt die hardwarenahe Aktivierung der betroffenen Quellen der anwendungsspezifischen Implementierung durch den Systemintegrator [SWS_EcuM_02924]. Die Spezifikation sieht für diese Schnittstelle weder Fehlermeldungen an DET oder DEM noch spezifische Fehler-Rückgabewerte vor [SWS_EcuM_02924]; eventuelle Fehlerzustände beim Starten der Quellen dürften daher vermutlich integrationsspezifisch innerhalb des Callouts abgefangen werden. Frage Q-b595e7175c34a831 (offen)

Die Funktion EcuM_CheckValidation dient als Callout-Schnittstelle des ECU State Managers zur Überprüfung einer Weckquelle [SWS_EcuM_02925]. Der EcuM ruft diese Funktion auf, um festzustellen, ob ein detektiertes Weckereignis valide ist [SWS_EcuM_02925].

Verwendung

Der Callout besitzt die Service-ID 0x47 und wird über die Header-Datei EcuM_Externals.h bereitgestellt [SWS_EcuM_02925]. Als Übergabeparameter dient wakeupSource vom Typ EcuM_WakeupSourceType, über den die zu validierende Weckquelle identifiziert wird [SWS_EcuM_02925]. Die Funktion liefert keinen Rückgabewert (void) und besitzt keine Ausgangs- oder Ein-/Ausgangsparameter [SWS_EcuM_02925]. Die Ausführung erfolgt synchron [SWS_EcuM_02925].

Fehlerbehandlung

Spezifische Fehlercodes, Rückgabewerte im Fehlerfall oder Meldungen an das DET oder DEM sind für diesen Callout in der Spezifikation nicht definiert.

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Nebenläufigkeit ist EcuM_CheckValidation als nicht reentrant (Non Reentrant) festgelegt [SWS_EcuM_02925]. Der aufrufende Kontext des EcuM muss gewährleisten, dass keine parallelen oder verschachtelten Aufrufe für dieselbe oder unterschiedliche Weckquellen stattfinden.

Zusammenspiel

Wurde bei der Ausführung ein valides Weckereignis erkannt, ist dieses zwingend über den Funktionsaufruf EcuM_ValidateWakeupEvent() an den EcuM zurückzumelden [SWS_EcuM_02925]. Interpretation: Die gerätespezifische Logik zur Überprüfung der Hardware sowie die Entscheidung zur Gültigkeit dürfte vollständig im Integrationscode implementiert werden. Frage Q-08061e09b474728d (offen)

Die Callout-Funktion EcuM_StopWakeupSources des Moduls EcuM (Classic Platform) dient dazu, die übergebene(n) Weckquelle(n) nach einer nicht erfolgreichen Weckvalidierung gezielt anzuhalten [SWS_EcuM_02926]. Die Deklaration dieser synchronen Schnittstelle ist über die Header-Datei EcuM_Externals.h verfügbar und führt die Service-ID 0x48 [SWS_EcuM_02926].

Verwendung und Schnittstellenparameter:

• Eingangsparameter: Als einziger Parameter wird wakeupSource vom Typ EcuM_WakeupSourceType übergeben, welcher die anzuhaltende(n) Weckquelle(n) spezifiziert [SWS_EcuM_02926].
• Rückgabewert und Ein-/Ausgänge: Es existieren weder Ein-/Ausgangsparameter (inout) noch Ausgangsparameter (out) [SWS_EcuM_02926]. Die Funktion liefert keinen Rückgabewert (void) an den Aufrufer zurück [SWS_EcuM_02926].
• Ausführungsverhalten: Die Funktionsabwicklung ist als synchron (Synchronous) festgelegt [SWS_EcuM_02926].

Nebenläufigkeit und Fehlerbehandlung:

Die Schnittstelle ist als nicht-reentrant (Non Reentrant) spezifiziert [SWS_EcuM_02926]. Parallele Aufrufe sind daher nicht zulässig und müssen vom Aufrufer vermieden werden. Die Spezifikation definiert für diesen Callout weder spezifische Fehlercodes noch Rückgabewerte oder Benachrichtigungen an das Default Error Tracer (DET) oder das Diagnostic Event Manager (DEM) Modul [SWS_EcuM_02926]. Interpretation: Da die Funktion als externer Callout über EcuM_Externals.h bereitgestellt wird, obliegt die hardwarebezogene Deaktivierung der betreffenden Weckhardware sowie die interne Fehlerbehandlung der anwenderspezifischen Implementierung. Frage Q-b537c805bed751ab (offen)

Verwendung und Aufrufkontext

Die Funktion EcuM_MainFunction besitzt die Signatur void EcuM_MainFunction(void) mit der Service-ID 0x18 und wird über die Header-Datei SchM_EcuM.h bereitgestellt [SWS_EcuM_02837]. Sie nimmt keine Parameter entgegen und liefert keinen Rückgabewert [SWS_EcuM_02837]. Ihre Aufgabe besteht darin, alle Aktivitäten des ECU State Managers abzuarbeiten, während das Betriebssystem läuft („OS is up and running“) [SWS_EcuM_02837]. Die Funktion dürfte dabei typischerweise periodisch durch den Scheduler aufgerufen werden (Interpretation: Einbindung über SchM_EcuM.h). Frage Q-ca471f22bdb1f11d (offen)

Zusammenspiel und Aufgaben

Im laufenden Betrieb übernimmt EcuM_MainFunction zentrale Koordinationsaufgaben:

• Validierung von Wakeup-Quellen: Sofern nach Abschluss der WakeupRestart-Sequenz eine Liste von Wakeup-Source-Kandidaten vorliegt, validiert das EcuM-Modul diese Kandidaten innerhalb der EcuM_MainFunction [SWS_EcuM_02539].
• Ablauf des Validierungs-Timeouts: Läuft das Validierungs-Timeout für ein anstehendes Wakeup-Ereignis ab, setzt die Funktion per ODER-Verknüpfung das zugehörige Bit in der internen Variable für abgelaufene Wakeup-Ereignisse [SWS_EcuM_04081]. Zudem benachrichtigt sie das BSW-Management über BswM_EcuM_Current_Wakeup mit einer EcuM_WakeupSourceType-Bitmaske des Ereignisses und dem Status ECUM_WKSTATUS_EXPIRED [SWS_EcuM_04082].
• Alarm Clock Service: Ist der Dienst über EcuMAlarmClockPresent vorhanden, aktualisiert die EcuM_MainFunction den Alarm Clock Timer [SWS_EcuM_04002].

Einschränkungen und Instanzen

Als wesentliche Randbedingung für Mehrkern- bzw. Mehrinstanz-Architekturen gilt, dass EcuM_MainFunction in allen Instanzen des EcuM ausgeführt werden muss [SWS_EcuM_04011].

Der Datentyp EcuM_RunStatusType ist als uint8 definiert und wird über den Header EcuM.h bereitgestellt ([SWS_EcuM_04120]). Er dient zur formalen Repräsentation des aktuellen Status des Run-Request-Protokolls im ECU-Manager und wird als Ergebnis an den Basic Software Mode Manager (BswM) übermittelt ([SWS_EcuM_04120]).

Der zulässige Wertebereich umfasst drei diskrete Zustände ([SWS_EcuM_04120]):

• ECUM_RUNSTATUS_UNKNOWN (Wert 0): Repräsentiert einen unbekannten Status und dient gleichzeitig als definierter Initialisierungswert (Init Value).
• ECUM_RUNSTATUS_REQUESTED (Wert 1): Kennzeichnet den Zustand, dass der RUN-Status vom ECU-Manager aktiv angefordert wurde.
• ECUM_RUNSTATUS_RELEASED (Wert 2): Signalisiert, dass der RUN-Status vom ECU-Manager wieder freigegeben wurde.

Hinsichtlich des Zusammenspiels verpflichtet die Anforderung [SWS_EcuM_04121] das ECU-Manager-Modul, den BswM verbindlich über den aktuellen Zustand des Run-Request-Protokolls anhand der in EcuM_RunStatusType aufgeführten Statuswerte zu informieren. Interpretation: Da die Anforderung keine spezifische Funktionssignatur oder Aufrufkonvention für den Meldungsfluss nennt, dürfte die Statusinformation typischerweise über eine interne Benachrichtigungsfunktion oder Callback-Schnittstelle an das BswM-Modul übergeben werden. Frage Q-e136b90c2edbc29c (offen) Spezifische Fehlercodes, DET- oder DEM-Meldungen sowie besondere Reentranzbedingungen sind für diesen elementaren Datentyp in den vorliegenden Anforderungen nicht vorgesehen.

Der Datentyp EcuM_WakeupStatusType beschreibt gemäß [SWS_EcuM_04041] die möglichen Zustände einer Weckquelle (Wakeup Source) im ECU State Manager. Der Typ ist vom Basistyp uint8 abgeleitet und wird über den Header EcuM.h bereitgestellt [SWS_EcuM_04041].

Der Wertebereich bildet den Lebenszyklus eines Weckereignisses über vier Zustände ab [SWS_EcuM_04041]:

• ECUM_WKSTATUS_NONE (Wert 0): Es wurde kein anstehendes Weckereignis erkannt [SWS_EcuM_04041].
• ECUM_WKSTATUS_PENDING (Wert 1): Ein Weckereignis wurde detektiert, ist jedoch noch nicht validiert [SWS_EcuM_04041].
• ECUM_WKSTATUS_VALIDATED (Wert 2): Das Weckereignis ist gültig und wurde erfolgreich bestätigt [SWS_EcuM_04041].
• ECUM_WKSTATUS_EXPIRED (Wert 3): Das Weckereignis wurde nicht rechtzeitig validiert und ist folglich abgelaufen [SWS_EcuM_04041].

Verwendung und Zusammenspiel: Der Typ dient als zentrale Statusrepräsentation für Weckquellen. Interpretation: Aufrufer dürften diesen Status im Rahmen von Statusabfragen auswerten, um zu ermitteln, ob eine Weckquelle aktiv validiert wird, bereits ein gültiges Aufwachen signalisiert hat oder das Validierungszeitfenster überschritten wurde. Frage Q-a3f721e8f1753eb1 (offen)

Der Typ EcuM_StateType ist ein von uint8 abgeleiteter Datentyp, der über den Header EcuM.h bereitgestellt wird und die Betriebszustände des ECU State Managers abbildet [SWS_EcuM_91005]. Das Modul EcuM ist verpflichtet, sämtliche in EcuM_StateType aufgeführten Zustände zu definieren [SWS_EcuM_02664]. Der Wertebereich umfasst die Teilzustandsmaske ECUM_SUBSTATE_MASK (0x0f) sowie die Hauptzustände ECUM_STATE_STARTUP (0x10), ECUM_STATE_RUN (0x32), ECUM_STATE_POST_RUN (0x33), ECUM_STATE_SHUTDOWN (0x40) und ECUM_STATE_SLEEP (0x50) [SWS_EcuM_91005].

Verwendung und Zusammenspiel

Der Datentyp fungiert als zentraler Parameter für die Zustandskommunikation zwischen dem BswM und dem EcuM:

• Zustandswechsel an EcuM: Über den synchronen und reentranten Funktionsaufruf EcuM_SetState(EcuM_StateType state) mit der Service-ID 0x2b benachrichtigt der BswM das EcuM-Modul über einen Zustandswechsel [SWS_EcuM_04122].
• Zustandsmeldung an BswM: Der EcuM meldet den aktuellen Zustand an den BswM durch Aufruf der Schnittstelle BswM_EcuM_CurrentState(EcuM_StateType State) [SWS_EcuM_04143].

Nebenläufigkeit, Reihenfolge und Fehlerbehandlung

Hinsichtlich der zeitlichen Reihenfolge gilt die Vorgabe, dass ein neuer Zustand vom EcuM erst dann gesetzt werden darf, wenn die RTE ihre Rückmeldung über den entsprechenden Acknowledgement-Port erteilt hat [SWS_EcuM_04143]. Spezifische Fehlercodes, Rückgabewerte oder DET-/DEM-Meldungen sind für diesen Datentyp in den vorliegenden Quellen nicht vorgesehen.

Der Typ EcuM_Mode ist als ModeDeclarationGroup gemäß [SWS_EcuM_04107] definiert und repräsentiert die zentralen Zustände des ECU State Managers. Als initialer Modus ist STARTUP festgelegt. Darüber hinaus umfasst die Gruppe die definierten Modi POST_RUN, RUN, SHUTDOWN sowie SLEEP [SWS_EcuM_04107].

Im Systemverbund dient EcuM_Mode als Typbasis für die Modegruppe currentMode innerhalb des Service-Interfaces EcuM_CurrentMode [SWS_EcuM_04108]. Über diese Schnittstelle kann der aktuelle ECU-Modus abgefragt oder über den RTE-Modus-Mechanismus an andere Software-Komponenten signalisiert werden.

Hinsichtlich des Aufrufkontexts und der Nebenläufigkeit enthält die Spezifikation des Typs selbst keine expliziten Einschränkungen zu Reentranz oder Fehlercodes; die Verwaltung der Zustandsübergänge erfolgt über die zugehörigen Service-Schnittstellen des EcuM.

Das Element currentMode ist als Provided-Port des Moduls EcuM definiert und stellt das Service-Interface EcuM_CurrentMode für die Software-Architektur bereit [SWS_EcuM_04112]. Dieses Service-Interface dient dem Auslesen des aktuellen ECU-Modus und kapselt die Modusgruppe currentMode auf Basis des Datentyps EcuM_Mode [SWS_EcuM_04108].

Im laufenden Systembetrieb erfolgt die Nutzung zur Signalisierung von Zustandsänderungen:

• Aufruf und Verwendung: Sobald ein Moduswechsel eintritt, meldet das EcuM diesen über RTE-Modus-Ports an Software-Komponenten (SW-Cs) [SWS_EcuM_04133]. Unter der Spezifikationsannahme des Portnamens currentMode und bei Nutzung der direkten RTE-API wird hierfür die Funktion Rte_Switch_currentMode_currentMode( Rte_ModeType_EcuM_Mode mode) aufgerufen [SWS_EcuM_04133].
• Parameter und Rückgabewert: Der Parameter mode übergibt den neu einzunehmenden Modus an die RTE [SWS_EcuM_04133]. Der von der Switch-API gelieferte Rückgabewert vom Typ Rte_StatusType wird nicht ausgewertet, sondern ist laut Spezifikation zwingend zu ignorieren [SWS_EcuM_04133].
• Zusammenspiel: Eine Software-Komponente, die über Modusänderungen informiert werden soll, muss das Modus-Switch-Interface EcuM_CurrentMode als Required-Port anfordern [SWS_EcuM_04133].

Verwendung und Wertebereich

Der Datentyp EcuM_ShutdownModeType basiert auf uint16 und wird über die Header-Datei Rte_EcuM_Type.h bereitgestellt [SWS_EcuM_04101]. Er bildet die im ECU State Manager konfigurierten Modi ab. Sein Wertebereich umfasst:

• die konfigurierten Sleep-Modi gemäß EcuMSleepModeId [SWS_EcuM_04101] sowie
• die konfigurierten Reset-Modi, berechnet aus dem Offset 256 + EcuMResetModeId [SWS_EcuM_04101].

Zusammenspiel und Aufrufkontext

Der Typ wird in synchronen und reentranten Diensten des ECU Managers verwendet:

• EcuM_SelectShutdownTarget übernimmt shutdownMode als Eingabeparameter, um den konkreten Sleep-Modus (bei Ziel ECUM_SHUTDOWN_TARGET_SLEEP) oder Reset-Mechanismus (bei Ziel ECUM_SHUTDOWN_TARGET_RESET) festzulegen [SWS_EcuM_02822].
• EcuM_GetShutdownTarget liefert über einen Zeigerparameter auf EcuM_ShutdownModeType zurück, welcher konfigurierte Sleep- oder Reset-Modus für das aktuelle Shutdown-Ziel gewählt ist [SWS_EcuM_02824].
• EcuM_GetLastShutdownTarget gibt den Shutdown-Modus des vorangegangenen Shutdown-Vorgangs über einen Ausgabeparameter aus [SWS_EcuM_02825]. Über das Service-Interface EcuM_ShutdownTarget steht diese Funktionalität auch Software-Komponenten (SW-Cs) zur Verfügung [SWS_EcuM_03011].

Fehlerbehandlung und Randbedingungen

Die Funktionen geben Std_ReturnType zurück. Wird beispielsweise ein NULL-Pointer an EcuM_GetShutdownTarget oder EcuM_GetLastShutdownTarget übergeben, schlägt der Aufruf mit E_NOT_OK fehl [SWS_EcuM_02824], [SWS_EcuM_02825]. Bei erfolgreicher Durchführung melden die Dienste E_OK [SWS_EcuM_02822], [SWS_EcuM_03011].