Figure 6: LIN Transport Protocol state-machine

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Zustandsautomat (State Machine Diagram) mit hierarchischer Zustandsschachtelung (Composite State).
• Architektur-Kontext: Spezifiziert den Lebenszyklus und die Kanalabwicklung des LIN Transport Protocol (LinTp), eingebettet im Communication Stack (ComStack) der AUTOSAR Classic Platform (SWS LIN Interface / LinTp).
• Funktionaler Zweck: Abwicklung segmentierter Diagnosenachrichten (UDS on LIN via MasterReq- / SlaveResp-Frames gem. ISO 17987 bzw. LIN 2.1). Vermittelt zwischen dem PDU Router (PduR) und der LIN-Treiber-/Interface-Schicht (LinIf / Lin).

2. Komponenten, Entitäten & Schnittstellen

• Modulzustände (Global Lifecycle):
  • LINTP_UNINIT: Modul ist nicht initialisiert; Speicher/Deskriptoren sind uninitialisiert.
  • LINTP_INIT: Zusammengesetzter Zustand (Composite State), repräsentiert das betriebsbereite Modul.
• Kanal-/Transaktionszustände (Sub-States innerhalb LINTP_INIT):
  • LINTP_CHANNEL_IDLE: Kanal ist betriebsbereit, wartet auf Sendeanforderungen oder eingehende Diagnose-Frames.
  • LINTP_CHANNEL_BUSY: Kanal wickelt eine aktive TP-Übertragung (Tx oder Rx) ab (Single Frame SF, First Frame FF oder Consecutive Frames CF).
• Schnittstellen & Transitionstrigger:
  • LinTp_Init: Synchroner Lebenszyklus-Aufruf (durch BSW Mode Manager / EcuM) zur Initialisierung der Steuerstrukturen.
  • LinTp_Shutdown: Synchroner Deinitialisierungs-Aufruf; führt zurück nach LINTP_UNINIT.
  • LIN TP message start: Interner Event-Trigger, initiiert via LinTp_Transmit() (Tx) oder Empfang eines SF/FF in LinIf_LinTpRxIndication() (Rx).
  • LIN TP message end: Interner Event-Trigger, ausgelöst durch erfolgreiche Übertragung/Empfang des letzten Frames, Fehlerabbruch oder Timer-Ablauf.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungsphase:
   • Nach Systemstart verharrt LinTp in LINTP_UNINIT.
   • Der Aufruf von LinTp_Init() versetzt das Modul in LINTP_INIT und nimmt den initialen Subzustand LINTP_CHANNEL_IDLE ein.
2. Kompression auf Kanalebene (Transaktionsbetrieb):
   • Start (LINTP_CHANNEL_IDLE → LINTP_CHANNEL_BUSY):
     • Tx-Pfad: Aufruf von LinTp_Transmit() durch den PduR. Sofern der Kanal IDLE ist, schaltet der Zustand auf BUSY; LinIf wird zur Bereitstellung der Diagnose-Schedule-Tabelle getriggert.
     • Rx-Pfad: LinIf signalisiert einen MasterReq- oder SlaveResp-Header; ein gültiger PCI-Header (SF oder FF) schaltet den Kanal auf BUSY.
   • Abwicklung im BUSY-Zustand:
     • Blockierende Segmentierung/Reassemblierung.
     • Iteratives Kopieren der Nutzdaten via PduR-Schnittstellen (PduR_LinTpCopyTxData / PduR_LinTpCopyRxData).
     • Überwachung der Protokoll-Timer (N_As, N_Ar, N_Cs, N_Cr).
3. Abschluss & Fehlerbehandlung (LINTP_CHANNEL_BUSY → LINTP_CHANNEL_IDLE):
   • Erfolg: Empfang/Versand des letzten CF quittiert via PduR_LinTpRxIndication(NTFRSLT_OK) bzw. PduR_LinTpTxConfirmation(NTFRSLT_OK).
   • Abbruchbedingungen: Timeout (N_Ax / N_Cx Expiry), falsche Sequence Number (SN), Pufferüberlauf (BUFREQ_E_NOT_OK) oder Abbruch über LinTp_CancelTransmit().
   • Alle Pfade emittieren LIN TP message end und setzen den Kanal zurück auf LINTP_CHANNEL_IDLE.
4. Terminierung:
   • Ausführung von LinTp_Shutdown() überführt das Modul unverzüglich zurück nach LINTP_UNINIT; laufende Sessions werden hart abgebrochen.

4. Normative Relevanz & Entwickler-Hinweise

• DET-Überwachung (LINTP_E_UNINIT):
  • Sämtliche API-Aufrufe (z. B. LinTp_Transmit, LinTp_GetVersionInfo) im Zustand LINTP_UNINIT müssen bei aktiviertem Development Error Detection (LINTP_DEV_ERROR_DETECT == STD_ON) mit dem Fehlercode LINTP_E_UNINIT an das DET gemeldet werden und E_NOT_OK zurückgeben.
• Single-Channel-Exklusivität & Reentrancy:
  • Auf einem LIN-Cluster existiert genau ein logischer TP-Kanal (Master-Slave-Bus). Im Zustand LINTP_CHANNEL_BUSY ist der Kanal nicht reentrant für neue Transaktionen.
  • Ein erneuter Aufruf von LinTp_Transmit() während BUSY muss synchron mit E_NOT_OK abgewiesen werden (BUFREQ_E_BUSY).
• Schedule-Synchronisation mit LinIf:
  • Der Übergang nach LINTP_CHANNEL_BUSY erfordert die koordinierte Umschaltung der LIN-Schedule-Tabelle im LinIf auf die Diagnose-Slots (0x3C/0x3D). Erst bei Rückkehr in LINTP_CHANNEL_IDLE kann die Applikations-Schedule wieder aktiviert werden.
• Versionsspezifische Normierung (R3.x / R4.0 vs. R4.2+):
  • Die gezeigte Schnittstelle LinTp_Shutdown() ist spezifisch für die frühen AUTOSAR-Releases (R3.0–R4.0). In späteren Releases (ab R4.1/R4.2) wurde die Shutdown-Sequenz im Zuge der BSW-Lifecycle-Harmonisierung weitgehend durch LinTp_DeInit() ersetzt bzw. direkt im LinIf gekapselt.