Ethernet Driver (Eth)

Die Funktion Eth_Init dient der Initialisierung des Ethernet-Treibers [SWS_Eth_00027]. Sie wird über die Header-Datei Eth.h deklariert, besitzt die Service-ID 0x01 und besitzt keinen Rückgabewert (void) [SWS_Eth_00027]. Als Eingabeparameter erwartet sie CfgPtr, der auf eine implementierungsspezifische Konfigurationsstruktur vom Typ Eth_ConfigType zeigt [SWS_Eth_00027]. Der Aufruf erfolgt synchron und ist als nicht reentrant (Non Reentrant) definiert [SWS_Eth_00027].

Im Betriebsablauf bildet Eth_Init die fundamentale Vorbedingung für die Arbeit mit dem Modul. Sämtliche weiteren Funktionen setzen eine vorangehende Controller-Initialisierung durch Eth_Init zwingend voraus [SWS_Eth_00070], [SWS_Eth_00167], [SWS_Eth_00185]. Diese Abhängigkeit ist für diverse Controller-Dienste des Treibers verbindlich vorgeschrieben [SWS_Eth_00189], [SWS_Eth_00194], [SWS_Eth_00199], [SWS_Eth_00232].

Für den Fall eines uninitialisierten Zugriffs ist eine gezielte Fehlerbehandlung vorgesehen: Bei aktivierter Entwicklungsausnahme- bzw. Fehlererkennung (Development Error Detection, DET) prüfen die Treiberfunktionen, ob der Service Eth_Init zuvor ordnungsgemäß aufgerufen wurde [SWS_Eth_00066]. Ist diese Prüfung nicht erfolgreich, lösen sie den Entwicklungsfehler ETH_E_UNINIT aus [SWS_Eth_00164], [SWS_Eth_00182], [SWS_Eth_00187], [SWS_Eth_00196]. Ist DET hingegen deaktiviert, verweigern betroffene Funktionen die Ausführung und signalisieren den unzulässigen Zustand durch Rückgabe des Status E_NOT_OK [SWS_Eth_00228], [SWS_Eth_00235], [SWS_Eth_00248], [SWS_Eth_00252].

Die Funktion Eth_SetControllerMode dient dem Aktivieren (ETH_MODE_ACTIVE) oder Deaktivieren (ETH_MODE_DOWN) des über den Parameter CtrlIdx adressierten Ethernet-Controllers [SWS_Eth_00041]. In AUTOSAR Classic R20-11 ist dieser Dienst als veraltet (obsolete) eingestuft [SWS_Eth_00041].

Die Ausführung des Dienstes ist asynchron und nicht reentrant (Non Reentrant) [SWS_Eth_00041]. Als Rückgabewert liefert die Funktion E_OK bei erfolgreicher Initiierung oder E_NOT_OK, falls der Betriebsmodus nicht gewechselt werden konnte [SWS_Eth_00041]. Interpretation: Da der Aufruf als asynchron spezifiziert ist, aber im Payload kein Callback definiert wird, dürfte die tatsächliche Zustandsübernahme hardwarenah im Treiberhintergrund nach Rückkehr der Funktion abgeschlossen werden. Frage Q-d7ec04578e921eb9 (offen)

Wird der Controller beziehungsweise dessen Sende- und Empfangskommunikation über Eth_SetControllerMode deaktiviert, gelten verbindliche Pufferbereinigungen:

• Sämtliche gesperrten Sendepuffer (locked transmit buffers) müssen freigegeben werden [SWS_Eth_00137] [SWS_Eth_00280].
• Alle ausstehenden Sendepuffer (pending transmit buffers) müssen ebenfalls freigegeben werden [SWS_Eth_00138] [SWS_Eth_00281].

Aufgrund der Eigenschaft Non Reentrant darf die Funktion für dieselbe oder weitere Controller-Instanzen nicht nebenläufig ausgeführt werden [SWS_Eth_00041]. Spezifische DET- oder DEM-Fehlermeldungen sind nicht aufgeführt; Fehlerzustände werden dem Aufrufer über den Rückgabewert E_NOT_OK mitgeteilt [SWS_Eth_00041].

Die Funktion Eth_SetControllerMode (Service-ID 0x03, bereitgestellt über Eth.h) dient dem Aktivieren und Deaktivieren der Empfangs- und Sende-Kommunikation (Rx/Tx) eines spezifischen Ethernet-Controllers [SWS_Eth_91009].

Verwendung und Aufrufbedingungen

Die Ausführung der Funktion erfolgt asynchron und ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Eth_91009]. Beim Aufruf werden zwei Parameter übergeben:

• CtrlIdx: Index des betreffenden Controllers im Kontext des Ethernet-Treibers [SWS_Eth_91009].
• CtrlMode: Zielmodus für den Controller, entweder ETH_MODE_ACTIVE zur Aktivierung der Rx/Tx-Kommunikation oder ETH_MODE_DOWN zu deren Deaktivierung [SWS_Eth_91009].

Als Rückgabewert liefert die Funktion den Status Std_ReturnType: E_OK signalisiert eine erfolgreiche Durchführung, während E_NOT_OK anzeigt, dass der Modus des Controllers nicht gewechselt werden konnte [SWS_Eth_91009].

Zusammenspiel und Pufferverwaltung

Wird die Rx/Tx-Kommunikation des indizierten Controllers über Eth_SetControllerMode deaktiviert (Modus ETH_MODE_DOWN), sind zwingend Bereinigungsaktionen für die Sendepuffer durchzuführen:

• Alle gesperrten Sendepuffer (locked transmit buffers) müssen freigegeben werden [SWS_Eth_00280].
• Alle ausstehenden Sendepuffer (pending transmit buffers) müssen ebenfalls freigegeben werden [SWS_Eth_00281].

Die aktuellen Bestimmungen zur Freigabe gesperrter und ausstehender Puffer sowie die Funktionsdefinition selbst besitzen den Status „draft“ [SWS_Eth_91009], [SWS_Eth_00280], [SWS_Eth_00281]. Sie ersetzen die historisch vorangegangenen Anforderungen [SWS_Eth_00137] und [SWS_Eth_00138], welche als obsolet eingestuft sind.

Die synchrone Schnittstelle Eth_UpdatePhysAddrFilter wird über die Header-Datei Eth.h bereitgestellt und besitzt die Service-ID 0x12 [SWS_Eth_00152]. Die Funktion dient dazu, eine physikalische Adresse zu dem Filter eines indizierten Ethernet-Controllers hinzuzufügen oder aus diesem zu entfernen [SWS_Eth_00152].

Die Parameter der Funktion umfassen drei Eingangswerte [SWS_Eth_00152]:

• CtrlIdx: Bestimmt den Index des betreffenden Ethernet-Controllers innerhalb des Treiberkontexts [SWS_Eth_00152].
• PhysAddrPtr: Zeiger auf den Speicherbereich mit der physikalischen Zieladresse (MAC-Adresse) in Netzwerk-Byte-Reihenfolge; dies ist die Multicast-Zieladresse des Layer-2-Ethernet-Pakets [SWS_Eth_00152].
• Action: Gibt über den Aufzählungstyp Eth_FilterActionType vor, ob die angegebene Adresse zum Filter des Controllers hinzugefügt oder daraus gelöscht wird [SWS_Eth_00152].

Die Funktion gibt einen Status vom Typ Std_ReturnType zurück: E_OK bestätigt die erfolgreiche Änderung des Filters, während E_NOT_OK meldet, dass der Filter nicht geändert werden konnte [SWS_Eth_00152]. Ist der Ethernet-Controller hardwareseitig nicht in der Lage, die Filterung eigenständig vorzunehmen, muss die Filteraufgabe durch die Software realisiert werden [SWS_Eth_00152].

Für die Ausführung gilt eine strikte Reentranz-Einschränkung: Die Funktion ist für denselben Controller-Index (CtrlIdx) nicht reentrant, darf jedoch für voneinander abweichende Controller-Indizes nebenläufig und reentrant aufgerufen werden [SWS_Eth_00152].

Die Funktion Eth_WriteMii dient dazu, ein Register eines Ethernet-Transceivers über das MII-Interface zu konfigurieren oder eine vom Transceiver bereitgestellte Funktion auszulösen [SWS_Eth_00058]. Die Deklaration ist über den Header Eth.h verfügbar [SWS_Eth_00058].

Verwendung und Parameter

Der Aufruf erfolgt mit der Service-ID 0x05 und verarbeitet vier Eingangsparameter [SWS_Eth_00058]:

• CtrlIdx: Index des Ethernet-Controllers im Kontext des Ethernet-Treibers [SWS_Eth_00058].
• TrcvIdx: Index des Transceivers auf der MII-Schnittstelle [SWS_Eth_00058].
• RegIdx: Index des zu beschreibenden Transceiver-Registers auf der MII [SWS_Eth_00058].
• RegVal: Der 16-Bit-Wert, der in das adressierte Register geschrieben werden soll [SWS_Eth_00058].

Die Ausführung des Dienstes ist asynchron spezifiziert [SWS_Eth_00058]. Dies bedeutet, dass der eigentliche Schreibvorgang über die Hardwareschnittstelle typischerweise im Hintergrund abgewickelt werden dürfte, während die Funktion nach Annahme der Anforderung unmittelbar zurückkehrt. Frage Q-0f9a9e682985d796 (offen)

Rückgabewerte und Einschränkungen

Als Rückgabewert liefert die Funktion den Typ Std_ReturnType [SWS_Eth_00058]:

• E_OK: Der Schreibauftrag wurde erfolgreich angenommen [SWS_Eth_00058].
• E_NOT_OK: Der Dienst wurde abgelehnt [SWS_Eth_00058].

Hinsichtlich der Nebenläufigkeit ist Eth_WriteMii als nicht reentrant (Non Reentrant) spezifiziert [SWS_Eth_00058]. Aufrufe dürfen daher nicht nebenläufig ohne entsprechende Synchronisation durch den Aufrufer ausgeführt werden.

Verwendung und Parameter

Die Funktion Eth_ReadMii (Service-ID 0x06) dient dem Auslesen eines Transceiver-Registers über die MII-Schnittstelle und wird über die Header-Datei Eth.h bereitgestellt [SWS_Eth_00064]. Beim Aufruf identifiziert CtrlIdx den jeweiligen Ethernet-Controller im Treiberkontext, TrcvIdx den angesprochenen Transceiver auf dem MII und RegIdx das konkrete Transceiver-Register [SWS_Eth_00064]. Der ermittelte Registerwert wird in den Speicherbereich geschrieben, auf den der Zeiger RegValPtr verweist [SWS_Eth_00064].

Ausführung und Nebenläufigkeit

Die Ausführung erfolgt asynchron (Asynchronous) [SWS_Eth_00064]. Ein Rückgabewert von E_OK bestätigt dabei lediglich, dass der Service bzw. der Leseauftrag erfolgreich angenommen wurde (Service accepted), während E_NOT_OK eine Ablehnung des Auftrags signalisiert (Service denied) [SWS_Eth_00064]. Wegen des asynchronen Charakters dürfte der für RegValPtr übergebene Speicherbereich bis zum endgültigen Abschluss des Lesevorgangs gültig bleiben müssen. Frage Q-04a94624b96bf51f (offen) Da die Funktion zudem als nicht reentrant (Non Reentrant) eingestuft ist [SWS_Eth_00064], dürfen Aufrufer gleichzeitige Zugriffe über verschiedene Tasks oder Interrupt-Kontexte nicht ohne externe Synchronisation durchführen.

Fehlerbehandlung

Kann der Treiber den Lesewunsch nicht annehmen, wird der Aufruf direkt mit E_NOT_OK quittiert [SWS_Eth_00064]. Spezifische Fehlercodes, DET-Laufzeitprüfungen oder DEM-Diagnoseereignisse sind für diese Funktion in den elementbezogenen Spezifikationsdaten nicht ausgewiesen.

Die synchrone Funktion Eth_EnableEgressTimeStamp aktiviert die Erfassung von Sende-Zeitstempeln (Egress Time Stamping) für ein dediziertes Nachrichtenobjekt des Ethernet-Treibers [SWS_Eth_00186]. Der Aufruf erfolgt über den Header Eth.h mit der Service-ID 0x17 und liefert keinen Rückgabewert [SWS_Eth_00186].

Beim Aufruf sind folgende Eingangsparameter zu übergeben [SWS_Eth_00186]:

• CtrlIdx: Index des adressierten Ethernet-Controllers [SWS_Eth_00186].
• BufIdx: Index des Nachrichtenpuffers, für den die übergeordnete Applikation die Erzeugung eines Egress-Zeitstempels erwartet [SWS_Eth_00186].

Hinsichtlich der Nebenläufigkeit ist die Funktion als nicht reentrant (Non Reentrant) spezifiziert [SWS_Eth_00186]. Ein paralleler Aufruf für denselben oder weitere Puffer muss daher aufrufseitig synchronisiert bzw. vermieden werden.

Das Verhalten der Hardware variiert je nach Controller-Implementierung: Manche Hardware speichert die Markierung für den Sende-Zeitstempel dauerhaft, während andere Controller die Aktivierung vor jeder Übertragung zwingend anfordern [SWS_Eth_00186]. Interpretation: Für eine hardwareunabhängige Ansteuerung dürfte es daher ratsam sein, die Funktion vor jedem Sendevorgang des gewünschten Puffers aufzurufen. Frage Q-c2b8d2db03e9d13b (offen) Eine Deaktivierungsschnittstelle existiert nicht, da der Nachrichtentyp gemäß dem Netzwerkdesign stets zeitgestempelt übertragen wird [SWS_Eth_00186].

Verwendung

Die synchrone Funktion Eth_ProvideTxBuffer gewährt Zugriff auf einen Ethernet-Sendepuffer des FIFOs, der der übergebenen Priorität zugeordnet ist [SWS_Eth_00077]. Sie wird über den Header Eth.h bereitgestellt und ist als reentrant spezifiziert [SWS_Eth_00077]. Über die Eingangsparameter werden der Controller-Index CtrlIdx sowie die Rahmenpriorität Priority zur FIFO-Auswahl übergeben [SWS_Eth_00077]. Der In-Out-Parameter LenBytePtr übergibt die gewünschte Puffergröße und liefert nach dem Aufruf die tatsächlich gewährte Bytegröße zurück [SWS_Eth_00077]. Die Ausgabeparameter BufIdxPtr (Ressourcenindex für spätere Anfragen) und BufPtr (Zeiger auf den Puffer) stellen die Referenzen auf den Speicherbereich bereit [SWS_Eth_00077].

Fehlerbehandlung und Rückgabewerte

Die Funktion signalisiert das Ergebnis über Rückgabewerte des Typs BufReq_ReturnType [SWS_Eth_00077]:

• BUFREQ_OK: Der Sendepuffer wurde erfolgreich bereitgestellt [SWS_Eth_00077].
• BUFREQ_E_BUSY: Alle Pufferressourcen sind derzeit belegt [SWS_Eth_00077].
• BUFREQ_E_OVFL: Der angeforderte Puffer ist zu groß [SWS_Eth_00077].
• BUFREQ_E_NOT_OK: Ein Entwicklungsfehler wurde erkannt [SWS_Eth_00077].

Zusammenspiel

Wenn EthCtrlConfigSwBufferHandling auf TRUE konfiguriert ist, wird intern ein Tupel aus dem an BufIdxPtr übergebenen Pufferindex des Software-Pufferpools und der angegebenen Priorität Priority gespeichert [SWS_Eth_00267].

Wird anschließend Eth_Transmit() aufgerufen, wird der gegebene Pufferindex demjenigen Software-FIFO zugewiesen, dessen Konfiguration EthCtrlConfigEgressFifoPriorityAssignment mit der zuvor in Eth_ProvideTxBuffer() übergebenen Priorität übereinstimmt [SWS_Eth_00268].

Verwendung und Aufrufkontext

Die synchrone Schnittstelle Eth_Transmit stößt den Sendevorgang für einen zuvor bereitgestellten und befüllten Ethernet-Sendepuffer an [SWS_Eth_00087]. Sie nimmt folgende Parameter entgegen:

• CtrlIdx: Index des Ethernet-Controllers im Kontext des Treibers [SWS_Eth_00087].
• BufIdx: Index der zu übertragenden Pufferressource [SWS_Eth_00087].
• FrameType: Spezifischer Ethernet-Frame-Typ [SWS_Eth_00087].
• TxConfirmation: Schalter zur Aktivierung der Sende-Bestätigung [SWS_Eth_00087].
• LenByte: Datenlänge der Nutzlast in Byte [SWS_Eth_00087].
• PhysAddrPtr: Zeiger auf die physikalische Zieladresse (MAC-Adresse) in Netzwerk-Byte-Reihenfolge [SWS_Eth_00087].

Der Rückgabewert vom Typ Std_ReturnType signalisiert mit E_OK die erfolgreiche Einleitung der Übertragung und mit E_NOT_OK ein Fehlschlagen [SWS_Eth_00087].

Zusammenspiel und Pufferabwicklung

Im Rahmen des Sendeablaufs weist Eth_Transmit den Pufferzeiger BufIdx dem Software-FIFO zu, dessen Konfigurationselement EthCtrlConfigEgressFifoPriorityAssignment mit der zuvor bei Eth_ProvideTxBuffer() festgelegten Priorität übereinstimmt [SWS_Eth_00268]. Mit dem Aufruf werden die entsprechenden Nachrichten aus den Software-FIFOs in das Hardware-FIFO überführt [SWS_Eth_00269].

Nebenläufigkeit

Die Funktion ist reentrant für Aufrufe mit unterschiedlichen Puffer-Indizes (BufIdx) sowie unterschiedlichen Controller-Indizes (CtrlIdx) [SWS_Eth_00087].

Die synchrone Funktion Eth_Receive dient dem Empfang eines Ethernet-Frames aus einem spezifischen FIFO-Puffer eines Ethernet-Controllers [SWS_Eth_00095]. Sie besitzt keinen Rückgabewert, liefert das Ergebnis der Abfrage jedoch über den Zeiger RxStatusPtr vom Typ Eth_RxStatusType an den Aufrufer zurück [SWS_Eth_00095]. Dieser Ausgabeparameter zeigt an, ob ein Rahmen erfolgreich empfangen wurde und ob für den betreffenden FIFO-Puffer noch weitere Rahmen zur Abholung bereitstehen [SWS_Eth_00095].

Parameter und Aufrufkontext

Als Eingangsparameter verlangt die Funktion den Controller-Index CtrlIdx innerhalb des Ethernet-Treibers sowie den Index FifoIdx des auszulesenden FIFOs [SWS_Eth_00095]. Die Funktion ist in der Header-Datei Eth.h deklariert [SWS_Eth_00095]. Der Aufruf dürfte typischerweise periodisch im Rahmen eines Polling-Mechanismus durch übergeordnete Treiber- oder Schnittstellenschichten erfolgen. Frage Q-f5ec0693a5887bcf (offen)

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Nebenläufigkeit ist Eth_Receive reentrant für unterschiedliche FIFOs implementiert, jedoch nicht reentrant für denselben FIFO [SWS_Eth_00095]. Gleichzeitige Aufrufe, die denselben FIFO desselben Controllers abfragen, sind unzulässig und müssen durch die aufrufende Software ausgeschlossen werden.

Zusammenspiel mit dem Ethernet-Interface

Im Polling-Modus ist der Ethernet-Treiber verpflichtet, bei einem erfolgreichen Empfangsvorgang unmittelbar aus der Routine Eth_Receive heraus die Funktion EthIf_RxIndication aufzurufen, um den empfangenen Rahmen der oberen Schicht zur Weiterverarbeitung zu melden [SWS_Eth_00244].

Verwendung und Aufrufkontext

Die über den Header Eth.h verfügbare Funktion Eth_TxConfirmation dient dem gezielten Auslösen der Übertragungsbestätigung für gesendete Ethernet-Frames [SWS_Eth_00100]. Sie besitzt die Service-ID 0x0C und wird synchron ausgeführt [SWS_Eth_00100]. Als einzigen Übergabeparameter erwartet die Funktion CtrlIdx, welcher den logischen Index des anzusprechenden Controllers innerhalb der Instanz des Ethernet-Treibers bestimmt [SWS_Eth_00100]. Ein Rückgabewert existiert nicht (void), und es werden keine Ausgabeparameter übergeben [SWS_Eth_00100].

Zusammenspiel im Sendeablauf

Im Zusammenspiel der Schichten übernimmt Eth_TxConfirmation die Weitergabe des Sendestatus an die übergeordnete Ethernet-Schnittstelle. Sofern die entsprechende Benachrichtigung aktiviert wurde, ist der Ethernet-Treiber dazu verpflichtet, EthIf_TxConfirmation mit dem Ergebniswert E_OK aufzurufen, um eine erfolgreiche Übertragung zu signalisieren [SWS_Eth_00243]. Im Polling-Modus erfolgt dieser Aufruf explizit aus dem Kontext der Routine Eth_TxConfirmation heraus, während er im unterbrechungsgesteuerten Modus alternativ direkt aus der Interrupt-Routine abgesetzt wird [SWS_Eth_00243].

Nebenläufigkeit und Ausführungsbedingungen

Für die Ausführung gilt die Einschränkung, dass Eth_TxConfirmation als nicht reentrant (Non Reentrant) definiert ist [SWS_Eth_00100]. Zeitgleiche Aufrufe für denselben Controller müssen daher durch den Aufrufer verhindert werden. Der Aufruf dürfte im Polling-Betrieb typischerweise zyklisch durch eine übergeordnete Ablaufsteuerung erfolgen. Frage Q-c19295838459b689 (offen) Spezifische Fehlercodes sowie Vorgaben zu DET- oder DEM-Meldungen sind in der Funktionsspezifikation nicht angegeben, weshalb eine gesonderte Fehlerbehandlung entfällt.

Verwendung und Aufrufkontext

Die Funktion Eth_MainFunction besitzt die Signatur void Eth_MainFunction(void) und wird über die Header-Datei SchM_Eth.h bereitgestellt [SWS_Eth_00171]. Daraus lässt sich interpretieren: Der Aufruf dürfte zyklisch durch den Schedule Manager (SchM) in einem taskbasierten Kontext erfolgen, da keine Übergabeparameter oder Rückgabewerte definiert sind. Frage Q-690a2dc372d49c6a (offen)

Funktionsumfang und Polling

Die Hauptaufgabe der Funktion besteht im Polling von Zustandsänderungen sowie der Überprüfung auf Controller-Fehler und verloren gegangene Ethernet-Frames [SWS_Eth_00171]. Stellt die Funktion fest, dass sich der Modus des Ethernet-Controllers geändert hat, ruft sie die Funktion EthIf_CtrlModeIndication auf, um die übergeordnete Schicht über den Zustandswechsel zu informieren [SWS_Eth_00171].

Abarbeitungsreihenfolge im Sendepfad

Im Kontext von Eth_MainFunction() ist eine feste Reihenfolge für die Verarbeitung von Software-FIFOs vorgegeben [SWS_Eth_00270]:

• Zunächst werden alle SW-FIFOs iteriert und deren Guthabenkonten (Credits Account) aktualisiert [SWS_Eth_00270].
• Anschließend werden alle SW-FIFOs erneut iteriert und auf sendefertige Nachrichten geprüft [SWS_Eth_00270].
• Für jedes iterierte SW-FIFO wird daraufhin die Übertragung unternommen [SWS_Eth_00270].

Der generische Enumerationstyp Eth_ModeType dient in den Schichten des Ethernet-Kommunikationsstacks (wie EthIf, Eth, EthSwt und EthTrcv) dazu, den Ethernet-Kommunikationskanal zu aktivieren oder zu deaktivieren sowie die zugehörige Hardware (wie Ethernet-Controller, Ethernet-Switch-Port oder Ethernet-Transceiver) in einen stromsparenden Schlafzustand bzw. Aktivmodus zu versetzen [SWS_Eth_00158].

Der Typ ist über die Header-Datei Eth_GeneralTypes.h verfügbar und definiert die folgenden Wertebereiche [SWS_Eth_00158]:

• ETH_MODE_DOWN (0x00): Deaktiviert den Ethernet-Kommunikationskanal und versetzt die zugehörige Hardware in einen stromsparenden Schlafmodus (Low-Power Sleep Mode) [SWS_Eth_00158].
• ETH_MODE_ACTIVE (0x01): Aktiviert den Ethernet-Kommunikationskanal und versetzt die Hardware in den Betriebsmodus (Power-On Mode) [SWS_Eth_00158].

Hinsichtlich des Lebenszyklus und der Verwendung ist zu beachten, dass Eth_ModeType im Release R20-11 mit dem Status obsolete gekennzeichnet ist [SWS_Eth_00158]. In Neuentwicklungen sollte die Verwendung dieses Typs daher vermieden werden, da veraltete Schnittstellentypen in künftigen Standards typischerweise durch modernere Kontrollstrukturen ersetzt werden.

Der Enumerationstyp Eth_ModeType wird über Eth_GeneralTypes.h deklariert und dient als schichtenübergreifender Modus-Typ im AUTOSAR-Ethernet-Kommunikationsstack ([SWS_Eth_91008]). Er wird in Modulen wie EthIf, Eth, EthSwt und EthTrcv verwendet, um Kommunikationskanäle gezielt zu aktivieren bzw. zu deaktivieren und die zugehörige Hardwarekomponente (Ethernet-Controller, Switch-Ports oder Transceiver) zwischen einem energiesparenden Schlafmodus und dem aktiven Betriebsmodus umzuschalten ([SWS_Eth_91008]).

Der Typ umfasst drei Zustände zur Modussteuerung ([SWS_Eth_91008]):

• ETH_MODE_DOWN (0x00): Deaktiviert die Rx- und Tx-Kommunikation und versetzt die zugehörige Hardware in einen Low-Power-Sleep-Modus. Sofern die Hardware dies unterstützt, wird zugleich ein Schlafprozess eingeleitet (beispielsweise das Anfordern von Sleep auf der Datenleitung gemäß OPEN Alliance TC10).
• ETH_MODE_ACTIVE (0x01): Aktiviert die Rx- und Tx-Kommunikation und schaltet die zugehörige Hardware in den regulären Betriebsmodus (Power-on).
• ETH_MODE_ACTIVE_WITH_WAKEUP_REQUEST (0x02): Aktiviert die Rx- und Tx-Kommunikation, versetzt die Hardware in den Betriebsmodus und löst zusätzlich eine Weckanforderung auf dem Netzwerk aus, sofern die Hardware über Weckfähigkeiten verfügt (wie Wake-up auf der Datenleitung nach OPEN Alliance TC10).

Im Stack-Zusammenspiel unterstützt Eth_ModeType insbesondere die Weiterreichung von Weckanforderungen aus der Serviceschicht (ComM) über die Zwischenschichten bis hinab zu den Kommunikationstreibern (EthTrcv), wodurch Hardware mit Wake-up- und Sleep-Funktionalität auf der Datenleitung bedarfsgerecht gesteuert wird ([SWS_Eth_91008]).

Der Aufzählungstyp Eth_StateType wird über den Header Eth_GeneralTypes.h bereitgestellt und dient gemäß [SWS_Eth_00159] der Zustandsüberwachung des Ethernet-Treibers. Sein Zweck besteht in der Unterstützung der Erkennung von Entwicklungsfehlern (Development Error Detection), wobei der aktuelle Zustand laut Spezifikation für Debugging-Zwecke verfügbar sein muss ([SWS_Eth_00159]).

Für die Zustandsverwaltung definiert Eth_StateType zwei diskrete Enumerationswerte ([SWS_Eth_00159]):

• ETH_STATE_UNINIT (Wert 0x00): Kennzeichnet, dass der Ethernet-Treiber noch nicht konfiguriert ist ([SWS_Eth_00159]).
• ETH_STATE_INIT (Wert 0x01): Kennzeichnet, dass der Ethernet-Treiber erfolgreich konfiguriert ist ([SWS_Eth_00159]).

Hinsichtlich der Fehlerbehandlung und des Zusammenspiels bildet dieser Zustandstyp die Grundlage für die interne Fehlererkennung. Es dürfte davon auszugehen sein, dass Treiber-APIs diesen Zustand abfragen und Aufrufe abweisen, solange sich der Treiber im uninitialisierten Zustand ETH_STATE_UNINIT befindet ([SWS_Eth_00159]). Frage Q-35a17e3267274d70 (offen) Erst wenn der Treiber in den Zustand ETH_STATE_INIT übergegangen ist, gilt er als konfiguriert und betriebsbereit ([SWS_Eth_00159]). Da die Typdefinition in Eth_GeneralTypes.h liegt, steht sie treiberübergreifend zur Verfügung ([SWS_Eth_00159]).

Verwendung und Wertebereich

Der Aufzählungstyp Eth_RxStatusType wird gemäß [SWS_Eth_00162] in der Header-Datei Eth_GeneralTypes.h definiert. Er dient als Ausgangsparameter (out parameter) in der Funktion Eth_Receive(), über den der Ethernet-Treiber mitteilt, ob ein Ethernet-Frame empfangen wurde und ob nachfolgend weitere Frames im Puffer vorliegen oder Daten verloren gegangen sind [SWS_Eth_00162].

Die Spezifikation definiert für diesen Typ drei diskrete Enumerationswerte [SWS_Eth_00162]:

• ETH_RECEIVED (0x00): Ein Ethernet-Frame wurde empfangen; im Controller stehen keine weiteren Frames mehr zur Verfügung.
• ETH_NOT_RECEIVED (0x01): Es wurde kein Ethernet-Frame empfangen; es liegen keine weiteren Frames vor.
• ETH_RECEIVED_MORE_DATA_AVAILABLE (0x02): Ein Ethernet-Frame wurde empfangen, und es stehen zusätzliche Frames zur Abholung bereit.

Zusammenspiel bei der Frame-Verarbeitung

Beim Aufruf von Eth_Receive() übergibt die aufrufende Schicht einen Zeiger auf eine Variable des Typs Eth_RxStatusType. Die Auswertung dieses Ausgabeparameters steuert den weiteren Ablauf des Empfangszyklus: Der Rückgabewert ETH_RECEIVED_MORE_DATA_AVAILABLE dürfte dem Aufrufer als Kriterium dienen, Eth_Receive() unmittelbar erneut aufzurufen, um verbleibende Frames zügig aus dem Empfangspuffer abzuarbeiten [SWS_Eth_00162]. Frage Q-4ed309522aa004f8 (offen) Die Zustände ETH_RECEIVED und ETH_NOT_RECEIVED signalisieren demgegenüber, dass der Puffer erschöpft ist und keine weiteren Daten zur Verarbeitung anstehen. Die Bereitstellung über Eth_GeneralTypes.h gewährleistet dabei eine einheitliche Typverwendung über die Module hinweg [SWS_Eth_00162].

Verwendung und Zweck

Der Datentyp Eth_TxErrorCounterValuesType ist gemäß [SWS_Eth_91004] als Struktur für statistische Zähler zu Diagnosezwecken im Ethernet-Treiber spezifiziert. Die Definition steht über die Header-Datei Eth_GeneralTypes.h bereit. Die Struktur bündelt mehrere 32-Bit-Zähler (uint32), welche spezifische Übertragungszustände und Sendehemmnisse auf Schnittstellenebene abbilden.

Strukturkomponenten und Semantik

Die einzelnen Zähler orientieren sich gemäß [SWS_Eth_91004] an standardisierten Netzwerk-MIB-Definitionen:

• Tx Dropped No Error Pkts: Anzahl der ausgehenden Pakete, die trotz fehlerfreiem Zustand verworfen wurden, beispielsweise um Pufferspeicher freizugeben (RFC1213 ifOutDiscards).
• Tx Dropped Error Pkts: Anzahl der Pakete, die aufgrund aufgetretener Fehler nicht übertragen werden konnten (RFC1213 ifOutErrors).
• Tx Deferred Trans: Anzahl der Frames, deren erster Sendeversuch verzögert wurde, weil das Übertragungsmedium belegt war (RFC1643 dot3StatsDeferredTransmissions).
• Tx Single Collision und Tx Multiple Collision: Erfolgreich übertragene Frames, deren Aussendung durch genau eine beziehungsweise durch mehrere Kollisionen verzögert wurde (RFC1643).
• Tx Late Collision: Kollisionen, die später als 512 Bit-Zeiten nach Beginn der Paketübertragung erkannt wurden (RFC1643 dot3StatsLateCollisions).
• Tx Excessive Collison: Anzahl der Übertragungen, die infolge zu vieler Kollisionen endgültig fehlgeschlagen sind (RFC1643 dot3StatsExcessiveCollisions).

Aufrufkontext und Einschränkungen

Interpretation: Da der Spezifikationsauszug keine zugehörige API-Funktion aufführt, dürfte dieser Diagnosetyp vermutlich als Ausgabeparameter per Zeiger an entsprechende Treiberfunktionen zur Zählerabfrage übergeben werden. Frage Q-2bfbe59d1fb81938 (offen) Spezifische Anforderungen an Fehlerbehandlung, DET-Meldungen oder Nebenläufigkeit sind für diese reine Datenstruktur in den Quellen nicht definiert.