Figure 3.1: Default States in EcuM Flex make it possible to reuse legacy SWCs

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architektonisches Block- und Schnittstelleninteraktionsdiagramm (Schichten- und Kommunikationsmodell).
• Technischer Zweck: Das Diagramm spezifiziert die Rückwärtskompatibilitäts-Architektur (Backward Compatibility) zur nahtlosen Wiederverwendung von Legacy-Software-Komponenten (SWCs), die ursprünglich für den EcuM with fixed state machine (AUTOSAR 3.x / frühe 4.x-Releases) entworfen wurden.
• Funktionale Einordnung: Es visualisiert das Zusammenspiel zwischen EcuM Flexible, BswM und der RTE. Bei aktiviertem Feature ECU Mode Handling emuliert der EcuM Flex in Kooperation mit dem BswM die standardisierten EcuM-Zustände (u. a. RUN, POST_RUN, SHUTDOWN, SLEEP) vollautomatisch, wodurch eine proprietäre Compatibility SWC im Applikationslayer überflüssig wird.

2. Komponenten, Entitäten & Schnittstellen

• Application Layer (SWCs):
  • SWC 1 (EcuM User): Aktive Legacy-Komponente; besitzt Client-Ports zur Anforderung/Freigabe von Steuergeräte-Laufzeitzuständen sowie Mode-Consumer-Ports zur Zustandsüberwachung.
  • SWC 2: Reguläre Applikationskomponente; rein passiver Mode-Consumer ohne eigene EcuM-Benutzeranforderungen.
• Runtime Environment (RTE):
  • RTE: Vermittlungsschicht zwischen BSW und VFB/Application Layer.
  • EcuM Mode: In der RTE instanziierte Mode Declaration Group (z. B. Modusgruppe EcuM_Mode mit Zuständen wie RUN, POST_RUN, SLEEP).
• Basic Software (BSW):
  • EcuM (ECU State Manager, Flexible):
    • RUN Request Protocol: Modulinterner Arbitrierungsmechanismus zur Verwaltung und Zählung von User-Anforderungen (EcuM_RequestRUN / EcuM_ReleaseRUN pro EcuM_UserType).
    • State Machine: Flexibler interner Zustandsgraph zur Abbildung der emulierten Fixzustände.
  • BswM (Basic Software Mode Manager): Übergeordnete Regel- und Aktions-Engine für das systemweite Modemanagement.
• Schnittstellen & Interaktionspfade:
  • EcuM_StateRequest: Standardisiertes AUTOSAR Client-Server-Interface (C/S) zwischen SWC 1 und EcuM (Service-Port EcuM_StateRequest mit den Operationen RequestRUN, ReleaseRUN, optional RequestPOST_RUN, ReleasePOST_RUN).
  • BswM_EcuM_RequestedState: BSW-interne C-API (Indikation von EcuM an BswM); signalisiert aggregierte Zustandsänderungen der Applikationsanforderungen an den BswM.
  • EcuM_SetState: BSW-interne Steuerungs-API (C-Funktion von BswM an EcuM); weist den EcuM an, eine physische Zustandsüberführung in der State Machine vorzunehmen.
  • Rte_Switch_currentMode (bzw. SchM_Switch / Rte_Switch_<p>_<m>): BSW-Service-Aufruf des EcuM an die RTE/SchM zur Bekanntgabe eines vollzogenen Zustandswechsels.
  • Mode-Notification-Pfade (EcuM Mode → SWC 1 / SWC 2): Verteilung des Modusstatus über RTE-Mode-Switch-Ports an registrierte Runnables der Komponenten (Mode-Switch-Triggered Events oder Rte_Mode-Abfragen).

3. Dynamisches Verhalten & Sequenzablauf

1. Zustandsanforderung durch Legacy-SWC:
   • SWC 1 ruft über das C/S-Interface EcuM_StateRequest synchron die Operation RequestRUN() auf.
2. Arbitrierung im EcuM:
   • Das RUN Request Protocol inkrementiert den Zähler für die zugewiesene User-ID. Ändert sich der Gesamtstatus von „kein User“ auf „mindestens ein User fordert RUN“, triggert der EcuM die BSW-Schnittstelle BswM_EcuM_RequestedState(ECUM_STATE_APP_RUN) (oder dem äquivalenten konfigurierten Target State).
3. Entscheidung & Zustandsführung im BswM:
   • Der BswM evaluiert die zugehörige Rule (BswMRule mit Mode-Condition auf BswM_EcuM_RequestedState).
   • Bei erfüllter Bedingung führt die Action-List des BswM den Aufruf EcuM_SetState(ECUM_STATE_RUN) aus.
4. Zustandswechsel & RTE-Signalisierung:
   • Die EcuM-interne State Machine wechselt in den Zustand RUN.
   • Der EcuM setzt den RTE-Mode-Switch über Rte_Switch_currentMode(RTE_MODE_EcuM_Mode_RUN) ab.
5. Reaktion im Application Layer:
   • Die RTE verarbeitet den Moduswechsel und triggert ModeSwitchEvents in SWC 1 und SWC 2 (z. B. Start zyklischer Applikations-Runnables bei Eintritt in RUN).
6. Freigabe und Herunterfahren:
   • Nach Abarbeitung sendet SWC 1 ReleaseRUN(). Sobald der User-Count 0 erreicht, signalisiert EcuM via BswM_EcuM_RequestedState den Wegfall des Bedarfs; der BswM steuert via EcuM_SetState die Folgemodi (POST_RUN → PREP_SHUTDOWN → SLEEP/OFF) an.

4. Normative Relevanz & Entwickler-Hinweise

• EcuM-Konfiguration:
  • Der Konfigurationsparameter EcuMConfiguration/EcuMCommonConfiguration/EcuMModeHandling muss explizit auf TRUE gesetzt werden. Erst dadurch stellt der EcuM Flex die Default-Zustände, das Run-Request-Protokoll und die RTE-Service-Ports kompatibel bereit.
  • Jedem Legacy-Client muss eine gültige EcuM-User-ID (EcuMUserConfig) zugewiesen und im C/S-Port-Mapping hinterlegt werden.
• BswM-Regelwerk:
  • Der BswM muss explizit mit BswMModeRequestPort für EcuM-Requested-States sowie entsprechenden Action-Lists konfiguriert werden, die EcuM_SetState aufrufen. Ohne diese BswM-Regeln bleibt der Zustandsautomat des EcuM trotz Applikationsanforderung blockiert.
• Latenz- und Ausführungssemantik:
  • Zwischen dem Aufruf von RequestRUN() durch die SWC und dem tatsächlichen Eintreten des Moduswechsels in der RTE vergeht mindestens ein Verarbeitungszyklus des BswM (BswM_MainFunction), sofern die Mode-Indikation nicht auf IMMEDIATE-Abarbeitung konfiguriert ist. Zeitkritische Applikationslogik darf den Moduswechsel nicht unmittelbar synchron nach dem C/S-Call voraussetzen.
• Architektur-Benefit:
  • Vollständige Portierbarkeit von ASR 3.x/4.0-Legacy-SWCs auf moderne AUTOSAR 4.2+/4.3+ Stacks ohne Refaktorisierung der Applikations-Ports oder Zwischenschaltung manueller Wrapper-Komponenten.