CAN Driver (Can)

Die synchrone, nicht reentrante Funktion Can_Init initialisiert das gesamte CAN-Treibermodul sowie die zugehörigen Hardware-Einheiten gemäß der übergebenen Konfiguration [SWS_Can_00223].

Verwendung und Aufrufkontext

Der Aufruf von Can_Init erfolgt während der Startphase des Steuergeräts verbindlich durch den ECU State Manager, noch bevor irgendeine andere Funktion des CAN-Treibers aufgerufen werden darf [SWS_Can_91012]. Als Parameter übernimmt die Funktion über Config einen Zeiger auf die Treiberkonfiguration (const Can_ConfigType*) und liefert keinen Rückgabewert zurück [SWS_Can_00223].

Initialisierungsumfang und Zustandsübergänge

Im Rahmen der Initialisierung setzt die Funktion alle erforderlichen Hardwareregister und initialisiert sämtliche CAN-Controller AUTOSAR_SWS_CANDriver S. 33:

• Initialisierung statischer Variablen und interner Flags [SWS_Can_91012],
• Konfiguration gemeinsamer Einstellungen für die vollständige CAN-Hardware-Einheit [SWS_Can_91012],
• controllerspezifische Einstellungen für jeden einzelnen CAN-Controller [SWS_Can_91012].

Durch den Funktionsaufruf werden Zustandsübergänge der CAN-Hardware ausgelöst AUTOSAR_SWS_CANDriver S. 10, wobei Can_Init die Registerkonfiguration vornimmt, um die Controller in den vorgesehenen Basiszustand zu überführen [SWS_Can_91010] AUTOSAR_SWS_CANDriver S. 36.

Nebenläufigkeit und Einschränkungen

Da Can_Init als nicht reentrant spezifiziert ist, darf kein paralleler oder wiederholter Aufruf während einer laufenden Initialisierung stattfinden [SWS_Can_00223]. Zudem können bestimmte globale Einstellungen der Hardware-Einheit ausschließlich innerhalb von Can_Init gesetzt werden AUTOSAR_SWS_CANDriver S. 33.

Die Funktion Can_DeInit dient der Deinitialisierung des CAN-Treibermoduls ([SWS_Can_91002]). Sie besitzt die Signatur void Can_DeInit(void), nimmt keine Parameter entgegen, liefert keinen Rückgabewert und wird synchron sowie nicht-reentrant ausgeführt ([SWS_Can_91002]). Die Schnittstelle ist über den Header Can.h verfügbar ([SWS_Can_91002]).

Der Aufruf stößt einen softwaregesteuerten Zustandsübergang an (AUTOSAR_SWS_CANDriver S. 10; AUTOSAR_SWS_CANDriver S. 41). Hierbei wechselt Can_DeInit den Modulzustand (AUTOSAR_SWS_CANDriver S. 33) und setzt alle CAN-Controller zurück (AUTOSAR_SWS_CANDriver S. 41).

Nebenläufigkeit und Einschränkungen

Für die Ausführung gelten strikte Vorbedingungen und Reihenfolgeanforderungen bezüglich der Hardware- und Modulzustände:

• Der Aufrufer muss sicherstellen, dass sich kein CAN-Controller in einem unzulässigen Zustand befindet (AUTOSAR_SWS_CANDriver S. 61); vermutlich müssen aktive Kommunikationsvorgänge vorab beendet sein. Frage Q-311343fa42add3a3 (offen)
• Befindet sich das CAN-Modul beim Aufruf nicht im geforderten Ausgangszustand (AUTOSAR_SWS_CANDriver S. 41), meldet die Funktion den Fehler CAN_E_TRANSITION (AUTOSAR_SWS_CANDriver S. 61).
• Ebenso wird der Fehler CAN_E_TRANSITION ausgelöst, wenn ein CAN-Controller in einem Zustand verbleibt, der die Deinitialisierung verhindert (AUTOSAR_SWS_CANDriver S. 61). Interpretation: Der Treiber dürfte vor dem Übergang einen gestoppten Zustand aller Controller voraussetzen. Frage Q-435095949dafba5c (offen)

Zusammenspiel

Das Fehler- und Übergangsverhalten spiegelt die bereinigten Treiberabläufe wider, nach denen ungültige Zustandsübergänge einheitlich abgefangen werden ([SWS_Can_00441]).

Die Funktion Can_SetControllerMode (bereitgestellt über Can.h mit der Service-ID 0x03) führt software-getriggerte Zustandsübergänge der CAN-Controller-Zustandsmaschine durch ([SWS_Can_00230], AUTOSAR_SWS_CANDriver S. 35). Sie nimmt die hardwarebezogenen Registereinstellungen vor, um die Übergänge zwischen den grundlegenden Controller-Zuständen UNINIT, STOPPED, STARTED und SLEEP herbeizuführen ([SWS_Can_91010], AUTOSAR_SWS_CANDriver §7.3 „CAN Controller State Machine“).

Verwendung und Semantik

Der Aufruf erfolgt mit dem Parameter Controller zur Identifikation des CAN-Controllers sowie Transition vom Typ Can_ControllerStateType zur Vorgabe des gewünschten Zustandsübergangs ([SWS_Can_00230]). Der Dienst ist als asynchron und nicht reentrant (Non Reentrant) definiert ([SWS_Can_00230]). Ein Rückgabewert von E_OK bestätigt, dass die Anforderung akzeptiert wurde; E_NOT_OK zeigt an, dass die Anforderung abgewiesen wurde und ein Entwicklungsfehler vorliegt ([SWS_Can_00230], [SWS_Can_00441]).

Ablauf und Zusammenspiel

Nach Setzen der Registerkonfiguration wird Can_SetControllerMode wieder verlassen (AUTOSAR_SWS_CANDriver S. 38). Da das Can-Modul die Zustandswechsel der Hardware selbst nicht speichert ([SWS_Can_91010]), übernimmt vermutlich die zyklische Funktion Can_Mainfunction_Mode die asynchrone Vollendung beziehungsweise Überprüfung des durch Can_SetControllerMode angestoßenen Übergangs (AUTOSAR_SWS_CANDriver S. 38). Frage Q-03edb1b665a1624b (offen)

Die synchrone und reentrante Funktion Can_DisableControllerInterrupts deaktiviert alle Interrupts für einen spezifizierten CAN-Controller ([SWS_Can_00231]). Die Übergabe erfolgt über den Parameter Controller ohne Rückgabewert ([SWS_Can_00231]).

Hinsichtlich des Aufrufkontexts und der Nebenläufigkeit ist die Funktion reentrant ausgelegt und unterstützt mehrfache Aufrufe (AUTOSAR_SWS_CANDriver §8.3 „Can_DisableControllerInterrupts“). Interpretation: Ein mehrfacher Aufruf dürfte einen internen Schachtelungszähler erhöhen, sodass die Interrupts erst nach einer entsprechenden Anzahl von Freigabeaufrufen wieder aktiv geschaltet werden (AUTOSAR_SWS_CANDriver §8.3 „Can_DisableControllerInterrupts“, AUTOSAR_SWS_CANDriver §8.3 „Can_DisableControllerInterrupts“). Frage Q-61be56207aa92ee0 (offen)

Im Bereich der Fehlerbehandlung fordert die Spezifikation das Auslösen des Fehlers CAN_E_UNINIT, falls das Treibermodul beim Aufruf noch nicht initialisiert ist (AUTOSAR_SWS_CANDriver §8.3 „Can_DisableControllerInterrupts“). Zudem verlangt die Spezifikation das Auslösen eines weiteren Fehlers (AUTOSAR_SWS_CANDriver §8.3 „Can_DisableControllerInterrupts“); vermutlich dient dies der Überprüfung auf eine ungültige Controller-Kennung. Frage (offen)

Im Zusammenspiel innerhalb des CAN-Treibers dient der Aufruf dazu, controllerbezogene kritische Bereiche abzusichern, während der Controller aktiv bleibt (AUTOSAR_SWS_CANDriver §7.5 „Interrupt handling“). Formale Bereinigungen und historische Schnittstellenänderungen des Treibers sind in den Release-Hinweisen dokumentiert ([SWS_Can_00441]).

Die synchrone und reentrante Funktion Can_EnableControllerInterrupts reaktiviert alle zulässigen Interrupts für den über den Parameter Controller angegebenen CAN-Controller ([SWS_Can_00232]). Sie besitzt keinen Rückgabewert und wird über die Header-Datei Can.h bereitgestellt ([SWS_Can_00232]).

Hinsichtlich des Ablaufs liest die Funktion softwareseitige Steuerflags aus (AUTOSAR_SWS_CANDriver S. 65). Wurden die Interrupts des Controllers zuvor mehrfach deaktiviert, muss Can_EnableControllerInterrupts vor der eigentlichen Freigabe ebenso oft aufgerufen werden (AUTOSAR_SWS_CANDriver S. 65). Interpretation: Der Treiber verwaltet geschachtelte Sperrabschnitte vermutlich über interne Zähler oder Flags, sodass die Hardware-Interrupts erst nach vollständigem Ausgleich aller Deaktivierungsaufrufe reaktiviert werden. Frage Q-6781f0fc9ad7d221 (offen)

Wird die Funktion aufgerufen, bevor der CAN-Treiber ordnungsgemäß initialisiert wurde, meldet sie den Fehler CAN_E_UNINIT (AUTOSAR_SWS_CANDriver S. 66). Dies dürfte im Treiberkontext als Development-Error behandelt werden ([SWS_Can_00441]). Frage Q-efbbcf03a2589e4e (offen) Im uninitialisierten Zustand führt die Funktion keine weiteren Aktionen am Controller aus (AUTOSAR_SWS_CANDriver S. 66).

Verwendung und Verhalten

Die synchrone Funktion Can_CheckWakeup prüft für einen bestimmten CAN-Controller, ob ein Wake-up-Ereignis erkannt wurde ([SWS_Can_00360], AUTOSAR_SWS_CANDriver S. 48, AUTOSAR_SWS_CANDriver S. 67). Sie ist über die Header-Datei Can.h verfügbar und besitzt die Service-ID 0x0b ([SWS_Can_00360]).

• Parameter: Controller (in) bezeichnet die Kennung des CAN-Controllers, dessen Zustand auf ein Wake-up geprüft werden soll ([SWS_Can_00360]).
• Rückgabewert: Gibt Std_ReturnType zurück. Der Rückgabewert E_OK signalisiert, dass der API-Aufruf akzeptiert wurde, während E_NOT_OK die Ablehnung anzeigt ([SWS_Can_00360]).
• Nebenläufigkeit: Die Funktion ist als nicht reentrant (Non Reentrant) definiert ([SWS_Can_00360]).

Konfiguration und Fehlerbehandlung

Die Verfügbarkeit der Funktion ist zur Vorkompilierzeit konfigurierbar; der Service Can_CheckWakeup kann darüber in den Code eingebunden oder aus ihm entfernt werden (AUTOSAR_SWS_CANDriver S. 67, AUTOSAR_SWS_CANDriver S. 97). Wird die Funktion aufgerufen, bevor der CAN-Treiber initialisiert wurde, meldet sie den Fehler CAN_E_UNINIT (AUTOSAR_SWS_CANDriver S. 67).

Zusammenspiel

Der Aufruf von Can_CheckWakeup wird typischerweise durch das CAN-Interface ausgelöst (AUTOSAR_SWS_CANDriver S. 48). Im Falle eines Wake-up-Ereignisses am Bus kann CanIf_CheckWakeup während der Abarbeitung von EcuM_CheckWakeup aufgerufen werden (AUTOSAR_SWS_CANInterface §7.18.4.1 „Wake-up detection“). Gemäß [SWS_CANIF_00395] fragt CanIf hierbei über Can_CheckWakeup() oder CanTrcv_CheckWakeup() ab, welches konkrete Hardwaregerät den Bus-Wake-up ausgelöst hat (AUTOSAR_SWS_CANInterface S. 55).

Verwendung und Semantik

Die Funktion Can_Write wird synchron vom Modul CanIf aufgerufen, um eine CAN-Nachricht zur Übertragung an den CAN-Treiber (CanDrv) zu übergeben ([SWS_Can_00233]). Der Aufrufer übergibt dabei zwei Parameter:

• Hth: Hardware-Sende-Handle, welches das zu verwendende Sendeobjekt festlegt und implizit den Controller bestimmt, da die Handle-Nummern innerhalb einer Hardware-Einheit eindeutig sind ([SWS_Can_00233]).
• PduInfo: Zeiger auf eine Struktur mit SDU-Nutzdaten, Datenlänge und CAN-Identifier ([SWS_Can_00233]).

Vor dem Senden prüft die Funktion das adressierte Hardware-Sendeobjekt (SWS_CANDriver S. 73) und sichert das übergebene swPduHandle (SWS_CANDriver S. 43). Über den Rückgabewert vom Typ Std_ReturnType (SRS_BSWGeneral §5.2.3.6 „Types and keywords“) signalisiert E_OK die Annahme des Auftrags, während CAN_BUSY anzeigt, dass kein Hardware-Sendepuffer verfügbar ist ([SWS_Can_00233], SWS_CANDriver S. 51).

Fehlerbehandlung

Tritt während der Ausführung ein Entwicklungsfehler auf, gibt die Funktion E_NOT_OK zurück ([SWS_Can_00233], [SWS_Can_00441]). Interpretation: Spezifische DET-Fehlercodes werden im verfügbaren Auszug nicht explizit genannt; fehlerhafte Handles oder ungültige Zeiger dürften jedoch zur Rückgabe von E_NOT_OK führen. Frage Q-ca947a7e0e4fd7d6 (offen)

Nebenläufigkeit und Einschränkungen

Can_Write ist als reentrant bzw. thread-safe spezifiziert ([SWS_Can_00233], SWS_CANDriver S. 49). Kann ein präemptiver Aufruf treiberseitig nicht reentrant ausgeführt werden, wird dies dem CanIf ebenfalls über den Rückgabewert CAN_BUSY gemeldet ([SWS_Can_00233]). Der Aufrufer muss gewährleisten, dass der PDU-Speicher bis zur Rückkehr des Funktionsaufrufs unverändert gültig bleibt (SWS_CANDriver S. 45).

Zusammenspiel

Über [SWS_Can_00416] wird beim Aufruf übermittelt, um welche PDU-Art es sich handelt (SWS_CANDriver S. 51), wobei der Treiber die Übertragung bis zur maximalen PDU-Länge unterstützt (SWS_CANDriver S. 52).

Verwendung und Aufrufkontext

Die konfigurierbare Call-out-Schnittstelle <LPDU_CalloutName> wird vom AUTOSAR-CAN-Modul optional bei jedem Empfang einer L-PDU aufgerufen (SWS_CANDriver §8.4.1 „Call-out function“). Die Deklaration der Funktion wird über die Header-Datei Can_Externals.h bereitgestellt ([SWS_Can_00443]). Der tatsächliche Name der Funktion wird projektspezifisch konfiguriert ([SWS_Can_00443]).

Als Eingangsparameter werden das Hardware-Receive-Handle Hrh, der Bezeichner CanId, die Datenlänge CanDataLegth sowie ein Zeiger auf die Nutzdaten CanSduPtr übergeben ([SWS_Can_00443]).

Filterung und Rückgabewert

Die Funktion liefert einen boolean-Wert zurück. Gibt der Call-out false zurück, darf die empfangene L-PDU nicht weiterverarbeitet werden ([SWS_Can_00444]). Interpretation: Liefert der Aufruf true, dürfte die reguläre Weiterleitung der L-PDU an die übergeordneten Schichten erfolgen. Frage Q-e96e75e93881c3af (offen)

Nebenläufigkeit und Einschränkungen

Die Funktion ist mit der Service-ID 0x20 versehen und als asynchron (Asynchronous) sowie nicht reentrant (Non Reentrant) spezifiziert ([SWS_Can_00443]). Da sie nicht reentrant ist, dürfen parallele Aufrufe im selben Kontext nicht stattfinden.

Die Funktion Can_MainFunction_Write führt das zyklische Polling von Sende-Bestätigungen (TX-Confirmation) durch, sofern der Parameter CAN_TX_PROCESSING auf POLLING konfiguriert ist [SWS_Can_00225], AUTOSAR SWS CAN Driver §7 „Scheduled functions“. Sie ist parameterlos (void Can_MainFunction_Write(void)), besitzt die Service-ID 0x01 und wird über die Header-Datei SchM_Can.h für den Scheduler bereitgestellt [SWS_Can_00225]. Über Konfigurationsschalter kann die Funktion zur Verarbeitung der PDU-Übertragung aktiviert oder deaktiviert werden AUTOSAR SWS CAN Driver §10 „CanMainFunctionWrite“.

Wird im System überhaupt kein Polling für Sendevorgänge genutzt, soll Can_MainFunction_Write laut Spezifikation als leeres Define implementiert werden AUTOSAR SWS CAN Driver §7 „Scheduled functions“. Dies dürfte unnötigen Scheduler-Overhead in rein interruptgesteuerten Systemen vermeiden. Frage Q-2152a35397130945 (offen)

Im Zusammenspiel mit Can_MainFunction_Read und Can_MainFunction_BusOff bildet die Routine die zyklische Schnittstelle des Treibers zur SchM AUTOSAR SWS CAN Driver §7 „Scheduled functions“. Die Bestätigungsverarbeitung findet abhängig vom Modus direkt an der Hardware-Ressource oder im Kontext von Can_MainFunction_Write statt AUTOSAR SWS CAN Driver §7 „Hardware Resources“. Der konkrete Aufruf und die Zuordnung richten sich nach den jeweils referenzierten Elementen AUTOSAR SWS CAN Driver §10 „CanMainFunctionWrite“, AUTOSAR SWS CAN Driver §10 „Call Context“, unterstützt durch eine controllerbezogene Tx-Verarbeitung [SWS_Can_00441].

Die Funktion Can_MainFunction_Read dient der zyklischen Abfrage (Polling) von CAN-Empfangsmeldungen ([SWS_Can_00226]). Sie besitzt die Signatur void Can_MainFunction_Read (void) mit der Service-ID 0x08 und wird über die Header-Datei SchM_Can.h für die Ablaufsteuerung bereitgestellt ([SWS_Can_00226]).

Verwendung und Konfiguration

Die Funktion führt das Polling von RX-Indikationen aus, wenn der Konfigurationsparameter CAN_RX_PROCESSING auf POLLING eingestellt ist ([SWS_Can_00226]). Im System kann diese Verarbeitung controllerweise konfiguriert werden ([SWS_Can_00441]). Wird im CAN-Treiber überhaupt kein Polling genutzt, kann Can_MainFunction_Read als leeres Makro definiert werden (AUTOSAR_SWS_CANDriver S. 77).

Nebenläufigkeit und Einschränkungen

Der Aufruf erfolgt periodisch im Scheduler-Kontext gemäß der parametrierten Trigger-Periode (AUTOSAR_SWS_CANDriver S. 22). Für die Ausführung gelten strenge Bedingungen:

• Die Funktion darf nicht durch sich selbst unterbrochen werden (AUTOSAR_SWS_CANDriver S. 47).
• Generell dürfen CAN-Hauptfunktionen wie Can_MainFunction_Read nicht unterbrochen werden (AUTOSAR_SWS_CANDriver S. 49), um den konsistenten Zugriff auf Treiber- und Hardwareressourcen im Polling-Modus zu sichern (AUTOSAR_SWS_CANDriver S. 46).

Interpretation: Das konfigurierte Aufrufintervall der Task dürfte so bemessen werden müssen, dass eine Bearbeitungsphase vor dem nächsten Zyklusstart stets beendet ist, da Reentranz unzulässig ist (AUTOSAR_SWS_CANDriver S. 47). Frage Q-1f2fa9db14970b12 (offen)

Die geplante Hauptfunktion Can_MainFunction_BusOff dient dem zyklischen Polling von Bus-Off-Ereignissen der CAN-Controller, sofern diese statisch als zu pollen konfiguriert sind [SWS_Can_00227], [SWS_Can_00109]. Sie besitzt die Signatur void Can_MainFunction_BusOff(void), nimmt keine Parameter entgegen, gibt keinen Wert zurück und wird über den Header SchM_Can.h für die Ablaufsteuerung bereitgestellt [SWS_Can_00227].

Verwendung und Zusammenspiel

Hardware-Ereignisse können im CAN-Treiber entweder per Interrupt oder durch Polling entsprechender Statusflags erfasst werden, wobei die Konfiguration der Abfrage hardwareabhängig ist [SWS_Can_00099]. Der Treiber kann auch so konfiguriert werden, dass vollständig auf Interrupts verzichtet wird [SWS_Can_00007]. Wird systemweit überhaupt kein Polling eingesetzt, darf das Can-Modul die Funktion als leeres Makro implementieren [SWS_Can_00183].

Wird in Can_MainFunction_BusOff ein Bus-Off-Ereignis über Statusbits erkannt, nimmt das Modul notwendige Registereinstellungen vor – etwa zur Vermeidung einer automatischen Hardware-Erholung SWS_CANDriver §7.3 „CAN Controller State Machine“, [SWS_Can_91010]. Anschließend benachrichtigt das Modul die übergeordnete Schicht CanIf über den zugehörigen Callback, in welchem die Software-Zustandsänderung des Controllers erfolgt SWS_CANDriver §7.3 „CAN Controller State Machine“.

Aufrufkontext und Einschränkungen

Bei gepolltem Betrieb ist der Aufrufkontext der Callback-Benachrichtigung nicht die ISR, sondern die ausführende Task der Can_MainFunction_BusOff; dennoch müssen alle Callback-Funktionen so realisiert sein, als ob sie aus dem ISR-Kontext aufgerufen würden SWS_CANDriver §7.9 „Notification concept“. Hinsichtlich der Reentranz enthält der Payload keine expliziten Angaben; vermutlich ist die Funktion nicht reentrant, da sie auf globale Controller-Register und Zustände zugreift. Frage Q-38fcd72c40ce3e66 (offen)

Die Hauptfunktion Can_MainFunction_Wakeup führt das zyklische Polling von Wake-up-Ereignissen durch, die statisch als zu pollend konfiguriert sind ([SWS_Can_00228]). Die Funktion besitzt die Signatur void Can_MainFunction_Wakeup(void), nimmt keine Parameter entgegen, liefert keinen Rückgabewert und wird über den Header SchM_Can.h für den Schedule Manager bereitgestellt (AUTOSAR_SWS_CANDriver S. 79). Die Ausführungsperiode der Funktion wird in Sekunden konfiguriert (AUTOSAR_SWS_CANDriver S. 92).

Im Rahmen der Zustandsmaschine des CAN-Controllers (SWS_CANDriver §7.3 „CAN Controller State Machine“) können externe Hardware-Wakeup-Ereignisse statt über Interrupts über ein Statusbit signalisiert werden, das in Can_MainFunction_Wakeup abgefragt wird ([SWS_Can_91010]). Zudem pollt die Funktion bei Zustandsübergängen ein entsprechendes Flag des CAN-Statusregisters, bis dieses die Wirksamkeit der Änderung signalisiert ([SWS_Can_00370]). Nach erfolgreichem Zustandswechsel meldet der CAN-Treiber den neuen Zustand mit der Callback-Funktion CanIf_ControllerModeIndication an das CAN-Interface, bezogen auf die abstrakte CanIf ControllerId ([SWS_Can_00370]).

Hinsichtlich Konfiguration und Ressourcennutzung lässt sich die API Can_MainFunction_Wakeup() für die Behandlung von Wakeup-Ereignissen aktivieren oder deaktivieren (AUTOSAR_SWS_CANDriver S. 97). Falls im Steuergerät überhaupt kein Polling für Wakeup-Ereignisse verwendet wird, kann Can_MainFunction_Wakeup als leeres Makro definiert werden (AUTOSAR_SWS_CANDriver S. 79).

Verwendung und Funktionsweise

Die geplante Hauptfunktion Can_MainFunction_Mode ([SWS_Can_00368]) führt das Polling von Zustandsübergängen der CAN-Controller durch. Sie besitzt weder Übergabeparameter noch einen Rückgabewert (void Can_MainFunction_Mode(void), Service-ID 0x0c) und wird über den Header SchM_Can.h deklariert SWS_CANDriver §8.5.1.5 „Can_MainFunction_Mode“.

Die Funktion wird fortlaufend zyklisch aufgerufen (AUTOSAR_SWS_CANInterface S. 143). Sie prüft die Hardware, ob sich der Modus eines CAN-Controllers geändert hat. Bei einer erkannten Änderung wird die CAN-Schnittstelle über den Aufruf von CanIf_ControllerModeIndication(Controller, ControllerMode) benachrichtigt.

Asynchrone Modusüberwachung

Wurde zuvor eine Modusänderung über Can_SetControllerMode() angefordert und kehrt dieser Aufruf erfolgreich zu CanIf zurück, erkennt Can_MainFunction_Mode den vollzogenen Zustandsübergang der Controller-Hardware. Sie informiert CanIf daraufhin asynchron mittels CanIf_ControllerModeIndication über den neuen Zustand wie etwa CAN_CS_STARTED AUTOSAR_SWS_CANInterface S. 144.

Aufrufkontext und Randbedingungen

Aufgrund der Bereitstellung über SchM_Can.h und der Definition als Scheduled Function dürfte der periodische Aufruf durch den BSW-Scheduler erfolgen. Frage Q-42edbc2aa591e8d7 (offen) Spezifische Fehlercodes oder Entwicklungsschritte werden im Payload für diese Funktion nicht definiert.

Der Enumerationstyp Can_ErrorStateType aus Can_GeneralTypes.h beschreibt die Fehler- und Betriebszustände eines CAN-Controllers [SWS_Can_91003]. Er bildet das Verhalten des Controllers auf dem CAN-Bus über drei Zustände ab SWS_CANDriver §8.2.7 „Can_ErrorStateType“:

• CAN_ERRORSTATE_ACTIVE: Der CAN-Controller nimmt vollumfänglich an der Bus-Kommunikation teil [SWS_Can_91003].
• CAN_ERRORSTATE_PASSIVE: Der CAN-Controller nimmt an der Kommunikation teil, sendet aber keine aktiven Fehler-Frames (Error Frames) mehr [SWS_Can_91003].
• CAN_ERRORSTATE_BUSOFF: Der CAN-Controller ist infolge schwerwiegender Übertragungsfehler vom Bus isoliert und nimmt nicht mehr an der Kommunikation teil [SWS_Can_91003].

Zur Laufzeit wird der Zustand über den synchronen Treiberdienst Can_GetControllerErrorState abgefragt [SWS_Can_91004]. Dessen Ausgabeparameter ErrorStatePtr nimmt den ermittelten Wert auf. Dieselbe Signatur nutzt auch die übergeordnete Funktion CanIf_GetControllerErrorState im CAN-Interface AUTOSAR_SWS_CANInterface S. 78 „CanIf_GetControllerErrorState“. Bezüglich der Nebenläufigkeit gilt, dass Can_GetControllerErrorState für dieselbe ControllerId als nicht reentrant spezifiziert ist [SWS_Can_91004].

Im Fehlerfall liefert Can_GetControllerErrorState den Rückgabewert E_NOT_OK, bei erfolgreicher Abfrage E_OK [SWS_Can_91004]. Bei aktivierter Entwicklungserkennung (DET) führt ein Aufruf vor der Treiberinitialisierung zum Fehler CAN_E_UNINIT [SWS_Can_91005]. Eine unzulässige ControllerId löst den Entwicklungsfehler CAN_E_PARAM_CONTROLLER aus [SWS_Can_91006], und die Übergabe eines Null-Zeigers für ErrorStatePtr wird mit einem Entwicklungsfehler abgewiesen [SWS_Can_91007].

Interpretation: Der Aufrufer dürfte den Speicherbereich für ErrorStatePtr eigenverantwortlich allozieren müssen, da die Schnittstelle den Zeiger als reinen Ausgabeparameter behandelt und Null-Zeiger per Entwicklungsfehler ausschließt. Frage Q-5c907c21bcb50893 (offen)

Der Enumerationstyp Can_ControllerStateType definiert die grundlegenden Betriebszustände eines CAN-Controllers: CAN_CS_UNINIT, CAN_CS_STARTED, CAN_CS_STOPPED und CAN_CS_SLEEP [SWS_Can_91013]. Der Typ wird modulübergreifend zur softwaregesteuerten Zustandsführung der CAN-Controller-Zustandsmaschine verwendet [SWS_Can_00017].

Die Werte werden in folgenden Kontexten eingesetzt:

• Zustandsanforderung: In Can_SetControllerMode dient der Typ als Übergangswert (Parameter Transition) zur asynchronen Anforderung eines neuen Betriebszustands [SWS_Can_00230]; korrespondierend dazu existiert CanIf_SetControllerMode AUTOSAR_SWS_CANInterface §- „CanIf_SetControllerMode“. Der Treiber reicht die Anforderung an die Controller-Hardware weiter, wobei die tatsächliche Zustandsänderung unmittelbar oder nach einigen Millisekunden wirksam wird AUTOSAR_SWS_CANInterface §- „Can_SetControllerMode“. Ein Übergang nach CAN_CS_STARTED löst zudem eine Reinitialisierung des Controllers aus [SWS_Can_00384].
• Statusabfrage: Über Can_GetControllerMode kann der aktuelle Zustand synchron über den Ausgabepointer ControllerModePtr abgefragt werden [SWS_Can_91014], [SWS_Can_91015] (analog in CanIf_GetControllerMode AUTOSAR_SWS_CANInterface §- „CanIf_GetControllerMode“).
• Zustandsindikation: Nach vollzogenem Wechsel benachrichtigen Callbacks wie CanSM_ControllerModeIndication [SWS_CanSM_00396], CanIf_ControllerModeIndication AUTOSAR_SWS_CANInterface §- „CanIf_ControllerModeIndication“ sowie Anwender-Callbacks AUTOSAR_SWS_CANInterface §- „User_ControllerModeIndication“ übergeordnete Schichten synchron über den neuen Controller-Modus.

Hinsichtlich Nebenläufigkeit und Fehlerbehandlung gilt: Die Treiberfunktionen Can_SetControllerMode und Can_GetControllerMode sind nicht reentrant [SWS_Can_00230], [SWS_Can_91014]. Bei Aufruf von Can_GetControllerMode vor der Treiberinitialisierung wird der Entwicklungsfehler CAN_E_UNINIT gemeldet und E_NOT_OK zurückgegeben [SWS_Can_91016]. Die Callback-Funktion CanSM_ControllerModeIndication ist für unterschiedliche Controller reentrant und meldet eine unkonfigurierte Controller-ID mit CANSM_E_PARAM_CONTROLLER an das DET [SWS_CanSM_00396], [SWS_CanSM_00397].

Der Enumerationstyp Can_ErrorType definiert eine standardisierte Obermenge von CAN-Fehlerursachen, die typische CAN-Hardware erfassen und an höhere Schichten melden kann [SWS_Can_91021]. Er wird über die Header-Datei Can_GeneralTypes.h bereitgestellt SWS_CANDriver §8.2.9 „Can_ErrorType“.

Da die Aufzählung als Superset konzipiert ist, unterstützt nicht jeder CAN-Controller zwingend sämtliche spezifizierten Werte [SWS_Can_91021]. Zu den definierten Fehlerzuständen gehören:

• Bitfehler bei der Busüberwachung (CAN_ERROR_BIT_MONITORING1, CAN_ERROR_BIT_MONITORING0 bzw. zusammenfassend CAN_ERROR_BIT),
• Quittierungsfehler (CAN_ERROR_CHECK_ACK_FAILED, CAN_ERROR_ACK_DELIMITER),
• Arbitrierungsverlust des Senders (CAN_ERROR_ARBITRATION_LOST),
• Überlastzustände durch volle Empfangspuffer (CAN_ERROR_OVERLOAD),
• Format- und Bit-Stuffing-Verletzungen (CAN_ERROR_CHECK_FORM_FAILED, CAN_ERROR_CHECK_STUFFING_FAILED),
• CRC-Fehler (CAN_ERROR_CHECK_CRC_FAILED) sowie
• eine dauerhafte Blockierung des Busses auf dominantem Pegel (CAN_ERROR_BUS_LOCK) SWS_CANDriver §8.2.9 „Can_ErrorType“.

Im Zusammenspiel der BSW-Module dient der Typ als Parameter der Callback-Funktion CanIf_ErrorNotification zur Weiterleitung von Controller-Fehlern an das CAN-Interface AUTOSAR_SWS_CANInterface §8.x „CanIf_ErrorNotification“. Der übergebene Wert dürfte dabei dem von der zugrundeliegenden Hardware festgestellten Fehlerzustand entsprechen AUTOSAR_SWS_CANDriver §7.x „Error Notification“. Frage Q-d23c45dd3b23ec71 (offen)