AUTOSAR Classic LIN

Das Modulcluster LIN Communication realisiert die standardisierte Anbindung von LIN-Subbussystemen über die Module LinSM, LinIf, LinTrcv und Lin (SWS COMManager S. 19). Es steuert die Schedule-basierte Übertragung von Frames bei Mastern sowie die reaktive Header-Auswertung und Datenübermittlung bei Slaves ([SWS_LinIf_91004], [SWS_Lin_00168]). Gleichzeitig koordiniert das Cluster den geordneten Wechsel zwischen Vollkommunikation und Schlafmodus sowie die autonome Fehlerbehandlung über das response_error-Signal ([SWS_LinIf_00763]).

mehr ›

Das Modulcluster LIN Communication stellt die vollständige AUTOSAR-Implementierung des LIN-Protokolls bereit und umfasst den Zustandsmanager LinSM, das Interface LinIf (inklusive Transportprotokoll LinTp), den Transceiver-Treiber LinTrcv sowie den MCAL-Treiber Lin (SWS COMManager S. 19). Es bindet Subnetzwerke, Sensoren und Aktoren an die AUTOSAR-Kommunikationsmatrix an und unterscheidet strikt zwischen Master-Knoten mit autonomer Schedule-Abarbeitung und rein reaktiv antwortenden Slave-Knoten ([SWS_LinIf_00197], [SWS_Lin_00272]).

Architekturdiagramm: Schichtenarchitektur und Schnittstellenbeziehungen des LIN-Clusters zwischen Kommunikationsdiensten, Abstraktionsschicht und MCAL. Quellen: SWS COMManager S. 19, AUTOSAR SWS LINInterface S. 133.

Die Datenübertragung erfolgt auf Master-ECUs durch periodische Ansteuerung des Treibers über Lin_SendFrame und nachfolgende Statusabfrage via Lin_GetStatus ([SWS_Lin_00168]). Am Slave hingegen führt die Erkennung eines Headers im Treiber zum synchronen Callback LinIf_HeaderIndication ([SWS_LinIf_91004]). Das Interface entscheidet anhand der PID über Empfang, Antwort oder Ignorieren und quittiert den Abschluss über LinIf_RxIndication bzw. LinIf_TxConfirmation ([SWS_LinIf_91005], [SWS_LinIf_91006]). Diagnosenachrichten wickelt das integrierte LinTp über automatisierte Umschaltungen der Schedule-Tabelle ab ([SWS_LinIf_00641]).

Im Betriebszyklus koordiniert LinSM die Zustandsübergänge zwischen LINSM_NO_COM und LINSM_FULL_COM ([SWS_LinSM_00026], [SWS_LinSM_00032]). Das Wecken erfolgt per Bus-Puls über Lin_Wakeup ([SWS_Lin_00169]). Der Übergang in den Schlafmodus erfolgt beim Master durch aktives Senden eines Sleep-Frames, beim Slave nach Empfang des Sleep-Befehls oder bei Bus-Idle via LinIf_GotoSleep, Lin_GoToSleepInternal und Transceiver-Schlafsteuerung ([SWS_LinSM_00231], [SWS_LinIf_00757]).

Sequenzdiagramm: Zusammenspiel der BSW-Module beim Eintritt eines LIN-Slaves in den Schlafzustand nach Bus-Sleep-Signal. Quellen: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager S. 48.

Kommunikationsfehler werden auf Slaves über LinIf_LinErrorIndication erfasst und autonom im response_error-Signal an den Master gemeldet ([SWS_LinIf_91007], [SWS_LinIf_00763]). Kanalübergreifende Synchronisationsbereiche und strikte Trennungen zwischen zyklischen Tasks (LinIf_MainFunction) und Treiber-ISRs sichern die Systemstabilität ([SWS_LinIf_00384]).

mehr ›

Systemarchitektur & Rolle des Modulclusters

Das Modulcluster LIN Communication stellt im AUTOSAR-Classic-Basissoftwarestapel die standardisierte Kommunikation über das Local Interconnect Network (LIN) nach ISO 17987 bereit. Es fungiert primär als kosteneffizientes Subbussystem zur Anbindung von Sensoren und Aktoren im Fahrzeugnetzwerk (AUTOSAR FO Features S. 58). Das Cluster erstreckt sich über mehrere Schichten der AUTOSAR-Architektur: Der LIN State Manager (LinSM) operiert auf der Ebene der Communication Services, das LIN Interface (LinIf) inklusive des integrierten Transportprotokolls (LinTp) bildet die Communication Abstraction, der LIN Transceiver Driver (LinTrcv) ist Teil der ECU Abstraction und der LIN Driver (Lin) residiert als hardwarenahes Modul im Microcontroller Abstraction Layer (MCAL) (SWS COMManager S. 19).

Architektonisch differenziert das Cluster strikt zwischen Master- und Slave-Knoten. Ein LIN-Master steuert über Schedule-Tabellen autark den Busverkehr und generiert alle Header, während LIN-Slaves rein reaktiv auf empfangene Header antworten oder Signale auswerten ([SWS_LinIf_00197], [SWS_Lin_00272]). Für Diagnose- und Transportaufgaben nach ISO 14229 kapselt das LIN Interface die TP-Funktionalität, welche segmentierte Diagnosenachrichten (Master Request Frame MRF und Slave Response Frame SRF) über PduR und DCM abwickelt ([SWS_LinIf_00351], [SWS_LinIf_00629]). Nach außen interagiert das Cluster intensiv mit dem Communication Manager (ComM), dem Basic Software Mode Manager (BswM), dem PDU Router (PduR) und dem ECU State Manager (EcuM) (SWS COMManager S. 19).

Architekturdiagramm: Schichtenarchitektur und Schnittstellenbeziehungen des LIN-Clusters zwischen Kommunikationsdiensten, Abstraktionsschicht und MCAL. Quellen: SWS COMManager S. 19, AUTOSAR SWS LINInterface S. 133.

Zusammenspiel & Interaktionspfade zwischen den Modulen

Die Interaktionspfade im Cluster unterscheiden sich fundamental je nach Knotenrolle. Im LIN-Master initiiert das LIN Interface über seine periodische Task die Abarbeitung der aktiven Schedule-Tabelle. Für fällige Sende-Frames holt LinIf die Nutzdaten über Trigger-Transmit-Mechanismen der oberen Schicht ab und übergibt die Lin_PduType-Struktur an den LIN-Treiber via Lin_SendFrame ([SWS_Lin_00232], SWS LINInterface S. 37). Der Treiber überträgt Header und Daten nicht-blockierend ([SWS_Lin_00027]). Nach Ablauf der maximalen Frame-Laufzeit ermittelt LinIf das Übertragungsergebnis über Lin_GetStatus ([SWS_Lin_00168], SWS LINInterface S. 35). Bei Empfangs-Slots holt LinIf die vom Treiber im Puffer abgelegten Daten ab und leitet sie an die oberen Schichten weiter ([SWS_Lin_00233]).

Auf einem LIN-Slave läuft der Datenpfad ereignisgesteuert ab: Erkennt der MCAL-Treiber Lin auf der Hardware einen gültigen Break-, Synch- und PID-Header, ruft er synchron den Callback LinIf_HeaderIndication auf ([SWS_Lin_00280], [SWS_LinIf_91004]). Das Interface prüft den geschützten Bezeichner (PID) anhand der internen PID-Tabelle ([SWS_LinIf_00816], [SWS_LinIf_00823]). Handelt es sich um einen Sende-Frame, holt LinIf die Nutzdaten ab, konfiguriert den Response-Typ auf LIN_FRAMERESPONSE_TX und stellt die Daten dem Treiber im Puffer bereit ([SWS_Lin_00230]). Ist der Frame als Empfang konfiguriert, meldet der Treiber nach vollständigem Byte-Empfang den Erfolg via LinIf_RxIndication ([SWS_LinIf_91005]), woraufhin LinIf die Daten an den PDU-Router weiterreicht. Bestätigungen gesendeter Slave-Responses erfolgen über LinIf_TxConfirmation ([SWS_LinIf_91006]).

Über das LIN-Interface wird zudem die Transceiver-Steuerung transparent gekapselt: Modusanforderungen wie LinIf_SetTrcvMode leitet das Interface synchron an LinTrcv_SetOpMode weiter ([SWS_LinIf_00544], [SWS_LinTrcv_00002]). Bei Transportprotokoll-Transaktionen steuert LinTp über BswM_LinTp_RequestMode die gezielte Umschaltung der Schedule-Tabelle des Masters zwischen Applikationsmodus (LINTP_APPLICATIVE_SCHEDULE), Diagnoseanforderung (LINTP_DIAG_REQUEST) und Diagnoseantwort (LINTP_DIAG_RESPONSE) ([SWS_LinIf_00641], [SWS_LinIf_00642], [SWS_LinIf_00643]).

Sequenzdiagramm: Dynamischer Steuer- und Datenfluss bei Header-Indikation, Sende-Triggerung und Empfangsquittierung an einem LIN-Slave. Quellen: [SWS_Lin_00280], [SWS_LinIf_91004], [SWS_LinIf_91005], AUTOSAR SWS LINInterface S. 133.

Synchronisation, Reentranz und Task-Kontexte

Die Ausführung innerhalb des Modulclusters ist auf zyklische Task-Kontexte und hardwarenahe Interrupt-Ebenen aufgeteilt. Kern der zyklischen Ablaufsteuerung im LIN Interface ist die geplante Funktion LinIf_MainFunction_<LinIfChannel.ShortName>, welche zwingend für jeden konfigurierten LIN-Kanal separat instanziiert wird ([SWS_LinIf_00384], [SWS_LinIf_00725]). Sie übernimmt das Weiterschalten der Schedule-Slots, die Statusabfragen beim Treiber und das Timeout-Handling des Transportprotokolls ([SWS_LinIf_00800], SWS LINInterface S. 119). Parallel dazu verwaltet LinSM_MainFunction die Countdown- und Bestätigungs-Timer für asynchrone Kanal- und Wakeup-Anforderungen ([SWS_LinSM_00162], [SWS_LinSM_00159]).

Im Gegensatz zur Task-Ebene laufen die Treiber-Routinen des MCAL-Moduls Lin bei Vorhandensein eines Interrupt-gesteuerten Controllers oder einer UART-Schnittstelle im Interrupt-Kontext (ISR) ab (AUTOSAR CP SWS LINDriver S. 53). Die Callbacks LinIf_HeaderIndication, LinIf_RxIndication und LinIf_TxConfirmation werden direkt aus diesem ISR-Kontext heraus synchron ausgelöst ([SWS_Lin_00280], [SWS_LinIf_91005], [SWS_LinIf_91006]). Dies erfordert eine strikte Absicherung kritischer Bereiche (Exclusive Areas) im LIN Interface: Steueraufrufe wie LinIf_Transmit, LinIf_GotoSleep, LinIf_ScheduleRequest oder LinIf_Wakeup dürfen interne Kanalstrukturen nur geschützt gegen parallele Zugriffe aus der LinIf_MainFunction oder ISR-Callbacks modifizieren (SWS LINInterface S. 119).

Hinsichtlich der Reentranz sind die API-Funktionen der Module LinIf und LinSM überwiegend reentrant für unterschiedliche Kanäle bzw. Netzwerke, jedoch nicht-reentrant für denselben Kanal konzipiert ([SWS_LinSM_00126], [SWS_LinIf_00201], [SWS_LinIf_00204]). Ebenso verhalten sich die Treiberdienste in Lin (z. B. Lin_Wakeup, Lin_GoToSleepInternal), die strikt pro physikalischem Kanal synchronisiert werden müssen ([SWS_Lin_00167], [SWS_Lin_00169]). Bei einfacher UART-Hardware ohne Mehrbyte-FIFO puffert der LIN-Treiber Bytes temporär in Software ([SWS_Lin_00026]), was Interpretation: bei hoher Buslast zu gesteigertem CPU-Interruptaufkommen auf Slave-Knoten führen dürfte. Frage Q-0d07d89d1ade6a01 (offen)

Typische Lebenszyklen und Betriebsmodi

Während des Systemstarts initialisiert der BswM die BSW-Module in einer vorgegebenen Kette: Zuerst werden die Basistreiber Lin_Init und LinTrcv_Init initialisiert, gefolgt von LinIf_Init, LinTp_Init und abschließend LinSM_Init (ModemanagementGuide S. 54). LinIf_Init setzt den Schedule aller Master-Kanäle standardmäßig auf NULL_SCHEDULE ([SWS_LinIf_00233]) und lädt bei Slaves die vorkonfigurierten NAD- und PID-Tabellen ([SWS_LinIf_00767], [SWS_LinIf_00768]). LinSM startet im Zustand LINSM_NO_COM, ohne bei der Initialisierung Callbacks an ComM oder BswM abzusetzen ([SWS_LinSM_00026], [SWS_LinSM_00166]).

Fordert der ComM über LinSM_RequestComMode(COMM_FULL_COMMUNICATION) die Kommunikationsfreigabe an, stößt LinSM direkt LinIf_Wakeup an und startet einen Überwachungs-Timer ([SWS_LinSM_00047], [SWS_LinSM_00100]). LinIf sendet über Lin_Wakeup den physischen Wakeup-Puls auf den Bus ([SWS_LinIf_00205], [SWS_Lin_00043]). Meldet LinIf den erfolgreichen Aufwachvorgang via LinSM_WakeupConfirmation(success=TRUE), wechselt der Zustand zu LINSM_FULL_COM ([SWS_LinSM_00049], [SWS_LinSM_00132]). Dies wird ComM via ComM_BusSM_ModeIndication und BswM via BswM_LinSM_CurrentState signalisiert ([SWS_LinSM_00033], [SWS_LinSM_00192]). Bei Slaves gilt der Bus erst als erfolgreich aufgewacht, wenn der Master den ersten LIN-Header sendet und dieser empfangen wird ([SWS_LinIf_00761], SWS LINStateManager S. 28).

Das Herunterfahren in den Schlafmodus (Go-to-Sleep) unterscheidet sich gravierend: Auf einem Master führt die Anforderung COMM_NO_COMMUNICATION zum Aufruf von LinIf_GotoSleep ([SWS_LinSM_00036], [SWS_LinSM_10208]). LinIf beauftragt den Treiber über Lin_GoToSleep, einen standardisierten Go-to-Sleep-Frame auf dem Bus zu senden ([SWS_Lin_00166], [SWS_Lin_00089]). Auf einem Slave hingegen empfängt das Interface den Go-to-Sleep-Befehl oder erkennt einen Bus-Idle-Timeout und informiert LinSM via LinSM_GotoSleepIndication ([SWS_LinSM_91000]). LinSM ruft daraufhin synchron LinIf_GotoSleep auf ([SWS_LinSM_00231]). Das Interface schaltet den Treiber über Lin_GoToSleepInternal lokal in den Zustand LIN_CH_SLEEP ([SWS_LinIf_00757], [SWS_Lin_00095]) und versetzt den Transceiver via LinIf_SetTrcvMode(LINTRCV_TRCV_MODE_SLEEP) in den Schlafzustand ([SWS_LinIf_00544], AUTOSAR CP SWS LINInterface S. 137). Nach der Bestätigung LinSM_GotoSleepConfirmation wechselt LinSM final zu LINSM_NO_COM ([SWS_LinSM_00046], [SWS_LinSM_00233]).

Sequenzdiagramm: Zusammenspiel der BSW-Module beim Eintritt eines LIN-Slaves in den Schlafzustand nach Bus-Sleep-Signal. Quellen: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager S. 48.

Fehlerbehandlung, DET-Tracing und Degradation

Das Cluster besitzt ein mehrstufiges Fehlererkennungs- und Diagnosekonzept. Entwicklungsfehler werden über den Default Error Tracer (Det) erfasst: Ungültige Kanal- oder Netzwerkparameter melden LIN_E_INVALID_CHANNEL ([SWS_Lin_00259]), LINIF_E_NONEXISTENT_CHANNEL ([SWS_LinIf_00539]) bzw. LINSM_E_NONEXISTENT_NETWORK ([SWS_LinSM_00127]). Aufrufe uninitialisierter Module ziehen LIN_E_UNINIT, LINIF_E_UNINIT oder LINSM_E_UNINIT nach sich ([SWS_Lin_00258], [SWS_LinSM_00128]). Transceiver-Fehler wie ungültige Netzwerknummern melden LINTRCV_E_INVALID_LIN_NETWORK an DET ([SWS_LinTrcv_00145]).

Im laufenden Betrieb auftretende Kommunikationsstörungen werden als Laufzeitfehler klassifiziert: Das Interface definiert LINIF_E_RESPONSE bei fehlerhaften Frames sowie LINIF_E_NC_NO_RESPONSE bei fehlenden Antworten auf Node-Configuration-Requests ([SWS_LinIf_00729]). Physische Bus- und Protokollfehler (Framing-Fehler, Checksummen-Fehler, Bit-Monitoring-Fehler) meldet der MCAL-Treiber am Slave über LinIf_LinErrorIndication mit dem Status Lin_SlaveErrorType ([SWS_LinIf_91007], [SWS_Lin_91140]). Auf Master-Knoten liefert Lin_GetStatus detaillierte Fehlercodes wie LIN_TX_HEADER_ERROR, LIN_TX_ERROR oder LIN_RX_ERROR an das Interface ([SWS_Lin_00168], [SWS_Lin_00233]).

Ein zentraler Fehlermechanismus für LIN-Slaves ist das standardisierte response_error-Signal. Das LIN-Interface verwaltet dieses 1-Bit-Signal autonom: Tritt ein Übertragungsfehler auf, setzt LinIf das Bit, welches im nächsten unkonditionierten Sende-Frame an den Master übertragen wird ([SWS_LinIf_00763], SWS LINInterface S. 58). Nach erfolgreicher Frame-Übertragung löscht LinIf das Flag selbsttätig ([SWS_LinIf_00747]). Im Diagnosekanal überwacht LinTp strikte Protokollzeitfenster: Bei Ausbleiben von N-PDUs brechen die Timer $N_{As}$ und $N_{Cr}$ die Transaktion definiert ab und melden E_NOT_OK an den PDU-Router ([SWS_LinIf_00799], [SWS_LinIf_00804], [SWS_LinIf_00806]). Fehlt am PDU-Router Pufferkapazität, bricht das Interface die Aufnahme ab und schaltet die Schedule-Tabelle des Masters zurück auf Applikationsbetrieb ([SWS_LinIf_00676], [SWS_LinIf_00792]).