Figure 9.21: Process Jump to Bootloader

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm mit kombiniertem Fragment (alt).
• Funktionale Einordnung: Detaillierung des internen und externen Interaktionsablaufs im AUTOSAR Classic Platform Diagnostic Communication Manager (DCM, SWS BSW-Modul) beim Wechsel in die Programmiersitzung (UDS Service 0x10 DiagnosticSessionControl, Sub-Funktion 0x02 programmingSession) mit anschließendem Übergang in den Bootloader („Jump to Bootloader“).
• Architektur-Kontext: Koordination zwischen PDU Router (PduR), den drei DCM-Teilschichten (Dsl, Dsd, Dsp) und den anwenderspezifischen BSW-Callouts (Dcm_Callouts).

2. Komponenten, Entitäten & Schnittstellen

• Module & Teilschichten («module»):
  • PduR: PDU Router; Schnittstelle zwischen Transportprotokoll-Stack (CanTp/FrTp/DoIP) und DCM.
  • Dsl (Diagnostic Session Layer): Verwaltet Sitzungszustände, PDU-Empfang/-Sendung, Puffer und Protokolltimings (P2/P2*).
  • Dsd (Diagnostic Service Dispatcher): Prüft Identifier, Sitzungs-/Sicherheitsrechte und delegiert Service-Requests an DSP.
  • Dsp (Diagnostic Service Processing): Implementiert die UDS-Service-Handler (hier: Service-Interpreter für SID 0x10).
  • Dcm_Callouts: Integrationsschicht für ECU-spezifische Hardware-/Plattform-Aktionen (z. B. Bootloader-Flags, RAM-Spiegelung).
• Schnittstellen & Datentypen:
  • Dcm_TpRxIndication(PduIdType id, Std_ReturnType result): TP-Empfangsmeldung von PduR an DSL.
  • Data_Indication_functionality(): Schichtinterne Übergabe DSL → DSD.
  • DiagnosticSessionControl service interpreter(): Schichtinterner Aufruf DSD → DSP zur Service-Verarbeitung.
  • Dcm_TpTxConfirmation(PduIdType id, Std_ReturnType result): Sende-Bestätigung der positiven UDS-Response von PduR an DSL.
  • Data_Confirmation_functionality(): Schichtinterne Weiterleitung der Sende-Bestätigung DSL → DSD.
  • DspInternal_DcmConfirmation(Dcm_IdContextType idContext, PduIdType pduId, Dcm_ConfirmationStatusType status): DSD → DSP zur Bestätigung des abgeschlossenen Response-Versands.
  • Dcm_SetProgConditions(): Callout DSP → Plattform (Dcm_Callouts) zur Persistierung der Übergabeparameter (Dcm_ProgConditionsType).

3. Dynamisches Verhalten & Sequenzablauf

1. Request-Empfang & Dekodierung:
   • PduR signalisiert das vollständige Eintreffen des Diagnoserequests via Dcm_TpRxIndication(...) synchron an Dsl.
   • Dsl übergibt die Daten per Data_Indication_functionality() an Dsd.
   • Dsd identifiziert SID 0x10 und triggert den DiagnosticSessionControl service interpreter() in Dsp.
   • Der Service-Interpreter bereitet die positive UDS-Antwort vor (0x50 02 ...) und signalisiert die Bereitschaft zur Sitzungsänderung.
   • Der synchrone Aufrufstack kehrt über Dsd und Dsl bis zur Rückgabe von Dcm_TpRxIndication() an PduR zurück.
2. Response-Übertragung (implizit):
   • DCM veranlasst das Senden der Response PDU über DSL/PduR an den Bus (nicht explizit als Call dargestellt).
3. Bestätigung & Verzweigung (alt if Reset allowed):
   • Bedingung [TRUE] (Reset nach Response erlaubt/konfiguriert):
     • Sobald die positive Antwort vollständig auf dem Bus übertragen wurde, ruft PduR Dcm_TpTxConfirmation(PduIdType, Std_ReturnType) auf Dsl auf.
     • Dsl leitet dies via Data_Confirmation_functionality() an Dsd weiter.
     • Dsd ruft DspInternal_DcmConfirmation(idContext, pduId, status) auf Dsp auf.
     • Dsp setzt die Programmierbedingungen ab via Dcm_SetProgConditions() an Dcm_Callouts. Hier werden Tester-Adresse, Session-ID, Baudrate/Timing-Parameter in non-volatile/shared RAM geschrieben.
     • Nach Rückkehr des Callouts kehrt die Bestätigungskaskade synchron über Dsd und Dsl an PduR zurück. Der eigentliche ECU-Reset (über BswM/Mcu) wird typischerweise im Nachgang oder im Kontext des Callouts/BswM initiiert.
   • Bedingung [FALSE]:
     • Kein direkter Reset/Bootloader-Sprung nach Tx-Bestätigung (z. B. falls UDS-Service 0x11 ECUReset separat erwartet wird oder die ECU im Application-Mode verbleibt). Es erfolgt kein Callout-Aufruf.

4. Normative Relevanz & Entwickler-Hinweise

• Tx-Confirmation-Kopplung: Der Bootloader-Sprung darf erst nach vollständiger Bestätigung der Tx-PDU (Dcm_TpTxConfirmation mit E_OK) erfolgen, um sicherzustellen, dass der Diagnosetester die positive Antwort vor dem Reset vollständig empfangen hat.
• Implementierung von Dcm_SetProgConditions():
  • Muss thread-sicher und synchron ausgeführt werden.
  • Daten müssen in einem nichtflüchtigen Speicherbereich liegen, der durch den anschließenden Warmstart/Reset nicht überschrieben wird (z. B. uninitialisierter RAM-Bereich mit Checksumme / Retention-RAM).
• Zusammenspiel mit BswM & EcuM: Der DCM führt den Reset in der Regel nicht eigenmächtig per Mcu_PerformReset() aus, sondern signalisiert dem BswM über definierte Mode-Declaration-Groups (z. B. DcmEcuReset), dass die ECU in den Bootloader neu starten soll.
• Fehlerbehandlung: Schlägt die Tx-Confirmation fehl (result != E_OK), darf Dcm_SetProgConditions() nicht aufgerufen werden; die Session verbleibt im definierten Fehlerzustand bzw. fällt auf die Default-Session zurück.