LIN State Manager (LinSM)

Der LIN State Manager setzt die Kommunikationswünsche des ComM je LIN-Netzwerk in Aufrufe des LIN Interface um. Die resultierenden Zustände LINSM_FULL_COM und LINSM_NO_COM meldet er an ComM und BswM [SWS_LinSM_00126]. Aufwecken, Einschlafen und, nur beim Master, den Wechsel der Schedule-Tabelle startet er direkt und überwacht die Bestätigungen mit Timern in LinSM_MainFunction. Beim Slave bestimmt der Master das Einschlafen: Erst LinSM_GotoSleepIndication löst LinIf_GotoSleep aus [SWS_LinSM_00231]. Scheitert ein Übergang, meldet der LinSM den bisherigen Zustand erneut, damit die oberen Schichten konsistent bleiben.

mehr ›

Der LIN State Manager ist der Bus-State-Manager für LIN. Über ihn fordert der ComM die Kommunikationsfähigkeit eines Netzwerks an (SWS ComM S. 19). Moduswünsche nimmt er über LinSM_RequestComMode entgegen [SWS_LinSM_00126]. Er steuert das LinIf und meldet Zustände an ComM und BswM [SWS_LinSM_00229]. Welcher LIN-Treiber ein Netzwerk bedient, bleibt hinter dem LinIf verborgen (SWS LinSM S. 28).

Kontextdiagramm: ComM und BswM steuern den LinSM, der LinSM steuert das LinIf, und das LinIf meldet über Callbacks zurück. Quellen: [SWS_LinSM_00229], [SWS_LinSM_00138], SWS LinSM S. 28

Nach LinSM_Init ist jedes Netzwerk in LINSM_NO_COM [SWS_LinSM_00155]. ComM und BswM werden dabei nicht benachrichtigt (SWS LinSM S. 23). Kommuniziert werden darf nur in LINSM_FULL_COM. Beim Eintritt erhalten ComM und BswM eine Meldung, und der Unterzustand LINSM_RUN_COMMUNICATION wird betreten [SWS_LinSM_00301]. Für den BswM sind nur LINSM_FULL_COM und LINSM_NO_COM sichtbar [SWS_LinSM_00220].

Zustandsdiagramm: Je Netzwerk wechselt der LinSM durch Wakeup- und Schlafbestätigung zwischen LINSM_NO_COM und LINSM_FULL_COM. Quellen: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM S. 20

Aufwecken und Einschlafen startet der LinSM direkt im Aufruf. Die Bestätigungen des LinIf überwacht er mit Timern in LinSM_MainFunction [SWS_LinSM_00156] (SWS LinSM S. 28). Beim Master führt eine Anforderung auf COMM_NO_COMMUNICATION sofort zu LinIf_GotoSleep [SWS_LinSM_00036]. Beim Slave wird sie nur gespeichert [SWS_LinSM_00230]; erst LinSM_GotoSleepIndication löst das Einschlafen aus [SWS_LinSM_00231]. Ein Silence-after-Wakeup-Timer verzögert erneute Weckversuche [SWS_LinSM_00237].

Schedule-Wechsel gibt es nur beim Master [SWS_LinSM_00241]. Der LinSM reicht LinSM_ScheduleRequest direkt an das LinIf weiter und meldet das Ergebnis über BswM_LinSM_CurrentSchedule (SWS LinSM S. 26). Für Fehler gilt:

• Entwicklungsfehler meldet der LinSM an den DET, mit den Codes aus [SWS_LinSM_00053].
• Ein ausbleibender Callback des LinIf gilt als LINSM_E_CONFIRMATION_TIMEOUT [SWS_LinSM_00224].
• Nach einem misslungenen Übergang setzt der LinSM den bisherigen Zustand erneut, damit ComM und BswM konsistent informiert sind [SWS_LinSM_00177].

mehr ›

Rolle zwischen ComM, BswM und LIN Interface

Der LIN State Manager (LinSM) ist der Bus-State-Manager für LIN. Wie bei den anderen Bus-State-Managern fordert der ComM über ihn die Kommunikationsfähigkeit eines Netzwerks an (SWS ComM S. 19). Die zentrale Eingangsschnittstelle dafür ist LinSM_RequestComMode [SWS_LinSM_00126]. Den aktuellen Modus liefert LinSM_GetCurrentComMode [SWS_LinSM_00122]. Der LinSM arbeitet ausschließlich auf Netzwerken. Welcher LIN-Treiber ein Netzwerk bedient, verdeckt das LinIf. Deshalb betreffen Steuergeräte mit mehreren unterschiedlichen LIN-Treibern den LinSM nicht (SWS LinSM S. 28).

Zu den Pflichtschnittstellen gehören LinIf_GotoSleep und LinIf_ScheduleRequest nach unten sowie die Meldungen ComM_BusSM_ModeIndication, ComM_BusSM_BusSleepMode, BswM_LinSM_CurrentState und BswM_LinSM_CurrentSchedule nach oben [SWS_LinSM_00229] (SWS LinSM S. 41). LinIf_Wakeup ruft der LinSM im Aufweckablauf (SWS LinSM S. 27). Optional nutzt er Det_ReportError und LinIf_SetTrcvMode [SWS_LinSM_00138]. Das LinIf meldet über die folgenden Callbacks zurück:

• LinSM_WakeupConfirmation [SWS_LinSM_00132]
• LinSM_GotoSleepConfirmation [SWS_LinSM_00135]
• LinSM_GotoSleepIndication [SWS_LinSM_91000]
• LinSM_ScheduleRequestConfirmation [SWS_LinSM_00129]

Die importierten Typen wie ComM_ModeType, NetworkHandleType und LinIf_SchHandleType legt [SWS_LinSM_00219] fest.

Kontextdiagramm: Der LinSM vermittelt zwischen ComM und BswM oben und dem LinIf unten; die LIN-Treiber bleiben hinter dem LinIf verborgen. Quellen: [SWS_LinSM_00126], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00156], SWS LinSM S. 28, Mode-Management-Guide S. 54

Zustandsmodell je LIN-Netzwerk, Initialisierung und zyklischer Anteil

Beim Start ist vor jedem API-Aufruf der modulweite Zustand LINSM_UNINIT aktiv (SWS LinSM S. 22). LinSM_Init ist synchron und nicht reentrant [SWS_LinSM_00155]. Die Funktion erhält einen Zeiger auf die Post-Build-Konfiguration vom implementierungsspezifischen Typ LinSM_ConfigType [SWS_LinSM_00221]. Danach ist jedes Netzwerk im Unterzustand LINSM_NO_COM des Oberzustands LINSM_INIT. Diesen ersten Übergang meldet LinSM_Init weder an ComM noch an BswM, weil der ComM zu diesem Zeitpunkt noch nicht initialisiert sein muss (SWS LinSM S. 23). Im Beispiel des Mode-Management-Guides ruft eine BswM-Regel LinSM_Init(null) nach Lin_Init und LinIf_Init auf (Mode-Management-Guide S. 54).

In LINSM_NO_COM bleibt der Bus still (SWS LinSM S. 23). Nur in LINSM_FULL_COM darf auf dem Bus kommuniziert werden, und jedes Netzwerk erreicht diesen Zustand unabhängig von den anderen. Beim Eintritt geschieht Folgendes (SWS LinSM S. 23):

• ComM erhält eine Meldung mit COMM_FULL_COMMUNICATION, BswM eine Meldung mit LINSM_FULL_COM.
• Ist LinSMTransceiverPassiveMode konfiguriert, schaltet der LinSM den Transceiver per LinIf_SetTrcvMode aktiv.
• Der Unterzustand LINSM_RUN_COMMUNICATION wird betreten [SWS_LinSM_00301].

Der vorübergehende Unterzustand LINSM_GOTO_SLEEP überbrückt das Warten auf die Schlafbestätigung (SWS LinSM S. 20, SWS LinSM S. 21). Für den BswM sind nur zwei Werte von LinSM_ModeType sichtbar: LINSM_FULL_COM (0x01) und LINSM_NO_COM (0x02) [SWS_LinSM_00220].

Die Zeitüberwachung läuft in LinSM_MainFunction. Diese periodische Funktion führt die Timer der Anforderungs-Timeouts [SWS_LinSM_00156]. Dort laufen auch die Wakeup-Bestätigungstimer ab, mit einem eigenen Timer je Netzwerk (SWS LinSM S. 28). Die eigentlichen Busaktionen startet der LinSM dagegen direkt im Aufruf und wartet nicht auf den nächsten Main-Function-Zyklus [SWS_LinSM_00036] [SWS_LinSM_00231].

Zustandsdiagramm: Je Netzwerk wechselt der LinSM durch Wakeup- und Schlafbestätigung zwischen LINSM_NO_COM und LINSM_FULL_COM; LINSM_GOTO_SLEEP ist nur ein Wartezustand. Quellen: [SWS_LinSM_00155], [SWS_LinSM_00301], SWS LinSM S. 20, SWS LinSM S. 21, SWS LinSM S. 24

Aufwecken: von LINSM_NO_COM nach LINSM_FULL_COM

Ein LIN-Netzwerk wird geweckt, wenn ComM über LinSM_RequestComMode volle Kommunikation anfordert. Weckt ein anderer Knoten den Bus, behandelt das nicht der LinSM, sondern der EcuM; auch dieser Fall führt zu einer Anforderung durch ComM (SWS LinSM S. 27). Der LinSM ruft dann direkt LinIf_Wakeup und setzt den Zähler für die maximale Anzahl an Wiederholungen zurück. Ist das LinIf bereits wach, ignoriert es den Aufruf. Vor dem Aufruf startet der LinSM für den Kanal den Wakeup-Bestätigungstimer mit LinSMConfirmationTimeout. Dieser Wert muss 0 oder ein ganzzahliges Vielfaches der Main-Function-Periode sein (SWS LinSM S. 28).

Meldet LinSM_WakeupConfirmation success = TRUE, wechselt das Netzwerk nach LINSM_FULL_COM [SWS_LinSM_00132]. In allen anderen Fällen setzt der LinSM den Zustand vor der Anforderung erneut, damit ComM und BswM trotzdem eine Modusindikation erhalten (SWS LinSM S. 27). Beim Slave bestätigt das LinIf erst, wenn es den ersten LIN-Header des Masters empfängt. Beginnt der Master nicht mit dem Scheduling, bleibt die Bestätigung aus, und der Timeout des LinSM greift (SWS LinIf S. 52).

Sequenzdiagramm: Der LinSM weckt das Netzwerk sofort im Aufruf, die Zustandsänderung folgt aber erst mit der asynchronen Bestätigung des LinIf. Quellen: [SWS_LinSM_00126], [SWS_LinSM_00132], [SWS_LinSM_00224], SWS LinSM S. 42, SWS LinSM S. 27

Eine zweite Zeitgrenze ist der Silence-after-Wakeup-Timer mit LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Solange er läuft, verzögert der LinSM einen neuen Aufruf von LinIf_Wakeup, auch wenn ComM volle Kommunikation anfordert [SWS_LinSM_00237]. Nach seinem Ablauf startet der LinSM den Wakeup-Prozess neu, sofern ComM weiterhin COMM_FULL_COMMUNICATION anfordert [SWS_LinSM_00236]. Die Bedingung, die den Timer startet, steht in einer Anforderung, die hier nicht vorliegt. Sie wird deshalb nicht beschrieben.

Aktivitätsdiagramm: Eine Anforderung auf volle Kommunikation endet je nach Timerlage und Rückmeldung in LINSM_FULL_COM, im alten Zustand oder in einem Bestätigungs-Timeout. Quellen: [SWS_LinSM_00237], [SWS_LinSM_00236], [SWS_LinSM_00224], SWS LinSM S. 27, SWS LinSM S. 28

Einschlafen: Der Master fordert an, der Slave folgt dem Bus

Der Goto-Sleep-Ablauf unterscheidet sich zwischen Master und Slave. In beiden Fällen meldet der LinSM den Eintritt in den No-Communication-Modus an BswM und ComM, auch wenn ein Problem auftrat (SWS LinSM S. 24).

Beim Master gilt:

• Fordert ComM in LINSM_FULL_COM COMM_NO_COMMUNICATION an, ruft der LinSM LinIf_GotoSleep auf, der das Goto-Sleep-Kommando sendet [SWS_LinSM_10208].
• Der Aufruf erfolgt direkt [SWS_LinSM_00036]. In allen anderen Fällen unterbleibt er [SWS_LinSM_10209].
• Zulässig ist der Aufruf nur im Unterzustand LINSM_RUN_COMMUNICATION (SWS LinSM S. 24).
• Liefert LinIf_GotoSleep E_NOT_OK, gibt auch LinSM_RequestComMode E_NOT_OK zurück. Der bisherige Zustand wird erneut gesetzt, damit ComM und BswM eine Indikation erhalten [SWS_LinSM_00177].

Danach ruft das LinIf LinSM_GotoSleepConfirmation auf [SWS_LinSM_00135]. Steht der LinSM dann in LINSM_FULL_COM/LINSM_GOTO_SLEEP, wechselt er nach LINSM_NO_COM, unabhängig vom Parameter success. In jedem anderen Zustand ignoriert er die Bestätigung (SWS LinSM S. 24). Das Schaubild der Spezifikation startet einen Timer vor LinIf_GotoSleep und stoppt ihn nach der Bestätigung (SWS LinSM S. 47).

Sequenzdiagramm: Beim Master löst ComM das Einschlafen aus; LINSM_NO_COM wird erst mit der Schlafbestätigung erreicht, ein E_NOT_OK von LinIf_GotoSleep führt zur erneuten Meldung des alten Zustands. Quellen: [SWS_LinSM_00036], [SWS_LinSM_00177], [SWS_LinSM_00135], SWS LinSM S. 47, SWS LinSM S. 24

Beim Slave entscheidet der Master über das Einschlafen. Fordert ComM in LINSM_FULL_COM COMM_NO_COMMUNICATION an, speichert der LinSM den Wunsch nur und gibt E_OK zurück [SWS_LinSM_00230]. Das LinIf meldet LinSM_GotoSleepIndication, wenn ein Goto-Sleep-Kommando empfangen wurde oder ein Bus-Idle-Timeout eintrat [SWS_LinSM_91000]. Erst dann ruft der LinSM direkt LinIf_GotoSleep [SWS_LinSM_00231]. Wie es weitergeht, hängt vom gespeicherten Wunsch ab:

• Ist COMM_NO_COMMUNICATION angefordert und liefert LinIf_GotoSleep E_OK, erfährt ComM das Bus-Sleep-Ereignis über ComM_BusSM_BusSleepMode [SWS_LinSM_00233].
• Ist volle Kommunikation angefordert, startet der LinSM nach der Schlafbestätigung den Wakeup-Prozess neu [SWS_LinSM_00234].

Im LinIf versetzt der Slave-Ablauf den Controller und, falls unterstützt, den Transceiver in den Schlafmodus (SWS LinIf S. 137).

Sequenzdiagramm: Beim Slave wird der Schlafwunsch des ComM nur gespeichert, ausgelöst wird das Einschlafen durch die Indikation des LinIf. Quellen: [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234], SWS LinSM S. 48, SWS LinSM S. 24

Schedule-Tabellen wechseln (nur Master)

LinSM_ScheduleRequest [SWS_LinSM_00113] existiert nur, wenn mindestens ein Kanal als Master konfiguriert ist [SWS_LinSM_00241]. Dasselbe gilt für den Callback LinSM_ScheduleRequestConfirmation [SWS_LinSM_00242]. Die asynchrone Funktion reicht die Anforderung direkt an LinIf_ScheduleRequest weiter, ohne Umweg über die Main Function. Deren Rückgabewert gibt sie an den Aufrufer zurück (SWS LinSM S. 26). Aufrufer ist der BswM. Er verwendet LinSMScheduleIndex als symbolische Referenz, deren Wert dem Wert im LinIf entsprechen muss (SWS LinSM S. 52). Auch die Diagnose-Schedule-Wechsel des LIN-Transportprotokolls laufen über den BswM und LinSM_ScheduleRequest (SWS LinIf S. 142).

Das Ergebnis meldet der LinSM über BswM_LinSM_CurrentSchedule (SWS BswM S. 80). Welcher Schedule gemeldet wird, hängt vom Verlauf ab (SWS LinSM S. 26):

• Bestätigt LinSM_ScheduleRequestConfirmation [SWS_LinSM_00129] vor Ablauf des Timers, meldet der LinSM den neuen Schedule.
• Ist der Timer abgelaufen, meldet er den unveränderten Schedule.
• Liefert LinIf_ScheduleRequest E_NOT_OK, meldet er im nächsten Main-Function-Aufruf den alten Schedule.
• Auch einen Wechsel ohne vorherige Anforderung meldet er, etwa den Wechsel auf den NULL-Schedule, den das LinIf beim Einschlafen vornimmt.

Sequenzdiagramm: Der Schedule-Wechsel wird direkt weitergereicht und zeitüberwacht; der BswM erfährt in jedem Ausgang den tatsächlich gültigen Schedule. Quellen: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00156], SWS LinSM S. 26, SWS LinSM S. 48

Knotentyp, Konfiguration und Unterschiede zu späteren Releases

Der Parameter LinSMNodeType legt fest, ob für einen Kanal Master- oder Slave-Verhalten gilt. Davon hängt ab, ob LinSM_ScheduleRequest, LinSM_ScheduleRequestConfirmation und LinSM_GotoSleepIndication verfügbar sind [SWS_LinSM_00241] [SWS_LinSM_00242] [SWS_LinSM_00243]. Die wichtigsten Zeitparameter sind LinSMConfirmationTimeout (SWS LinSM S. 28) und LinSMSilenceAfterWakeupTimeout [SWS_LinSM_00235]. Die LinSMSchedule-Container referenzieren Schedules aus der LinIf-Konfiguration (SWS LinSM S. 52). Die DET-Prüfungen hängen an LinSMDevErrorDetect [SWS_LinSM_00239].

Viele Dokumentstellen stammen aus späteren Releases. Für R20-11 sind die Requirements maßgeblich, und an einigen Stellen weichen sie ab:

• Der zweite Parameter von LinSM_ScheduleRequest heißt in R20-11 schedule und wird als „Pointer to the new Schedule table“ beschrieben, obwohl sein Typ LinIf_SchHandleType ist [SWS_LinSM_00113]. Mit R22-11 wurde er umbenannt (SWS LinSM S. 1, Release Overview S. 50); in R24-11 heißt er ScheduleTableIdx (SWS LinSM S. 34).
• In R20-11 hat LinSM_GetCurrentComMode die Service-ID 0x11 [SWS_LinSM_00122] und LinSM_RequestComMode die Service-ID 0x12 [SWS_LinSM_00126]. Spätere Fassungen nennen 0x41 und 0x40 und erlauben Reentranz nur für verschiedene Netzwerke (SWS LinSM S. 35, SWS LinSM S. 36).
• Die ComM-Callbacks heißen in R20-11 ComM_BusSM_… [SWS_LinSM_00233], in R25-11 ComM_<Bus>SM_… (SWS LinSM S. 41).

Verhalten im Fehlerfall

Die Entwicklungsfehler legt [SWS_LinSM_00053] fest:

• LINSM_E_UNINIT (0x00)
• LINSM_E_NONEXISTENT_NETWORK (0x20)
• LINSM_E_PARAMETER (0x30)
• LINSM_E_PARAM_POINTER (0x40)
• LINSM_E_INIT_FAILED (0x50)

Bei aktivem LinSMDevErrorDetect prüfen die Callbacks Netzwerk und Initialisierung, so etwa LinSM_GotoSleepIndication [SWS_LinSM_00239] [SWS_LinSM_00240]. Callbacks haben keinen Rückgabewert, daher bleibt es dort bei der DET-Meldung (SWS LinSM S. 40, SWS LinSM S. 39). APIs mit Std_ReturnType liefern zusätzlich E_NOT_OK, zum Beispiel bei ungültigem Netzwerk, Modus oder Schedule oder im Zustand LINSM_UNINIT (SWS LinSM S. 36, SWS LinSM S. 34). Interpretation: Diese Prüfungen stammen aus Fassungen ab R24-11 und dürften für R20-11 inhaltlich gleich gelten. Frage Q-6b2d75dd286bdcb4 (offen) Auffällig ist, dass die spätere Fassung auch für das void-API LinSM_GetVersionInfo [SWS_LinSM_00117] bei NULL-Zeiger E_NOT_OK verlangt (SWS LinSM S. 34).

Als Laufzeitfehler ist LINSM_E_CONFIRMATION_TIMEOUT (0x00) für ausbleibende Callbacks des LinIf vorgesehen [SWS_LinSM_00224]. Vermutlich wird er über Det_ReportRuntimeError gemeldet, das spätere Fassungen als Pflichtschnittstelle führen (SWS LinSM S. 41). Frage Q-06b13a07d0d60152 (offen) Funktional sorgt der LinSM dafür, dass ComM und BswM immer einen konsistenten Zustand sehen:

• Nach einem fehlgeschlagenen Wakeup setzt und meldet er den alten Zustand erneut (SWS LinSM S. 27).
• Bei E_NOT_OK von LinIf_GotoSleep gilt dasselbe [SWS_LinSM_00177].
• Eine Schlafbestätigung führt auch bei success = FALSE nach LINSM_NO_COM (SWS LinSM S. 24).
• Bei einem misslungenen Schedule-Wechsel erhält der BswM den alten oder den unveränderten Schedule (SWS LinSM S. 26).

Weiterführende Detailbelege

• Moduswunsch des ComM und Einschlafen beim Master: [SWS_LinSM_00126], [SWS_LinSM_00036], [SWS_LinSM_10208], [SWS_LinSM_10209], [SWS_LinSM_00177].
• Einschlafen beim Slave: [SWS_LinSM_91000], [SWS_LinSM_00230], [SWS_LinSM_00231], [SWS_LinSM_00233], [SWS_LinSM_00234]; dazu der Ablauf in SWS LinSM S. 24.
• Aufwecken und Zeitüberwachung: [SWS_LinSM_00132], [SWS_LinSM_00235], [SWS_LinSM_00236], [SWS_LinSM_00237], SWS LinSM S. 28.
• Schedule-Wechsel: [SWS_LinSM_00113], [SWS_LinSM_00129], [SWS_LinSM_00241], [SWS_LinSM_00242].
• Initialisierung, Zustände und Typen: [SWS_LinSM_00155], [SWS_LinSM_00156], [SWS_LinSM_00220], [SWS_LinSM_00221], [SWS_LinSM_00301]; Meldung an den BswM in SWS BswM S. 72.
• Fehlercodes und Schnittstellen: [SWS_LinSM_00053], [SWS_LinSM_00224], [SWS_LinSM_00229], [SWS_LinSM_00138], [SWS_LinSM_00219].
• Rückverfolgung auf SRS-Anforderungen und Liste der nicht anwendbaren Anforderungen: SWS LinSM S. 18, SWS LinSM S. 55.