Communication Stack Types (ComStack_Types)

Das Modul comstack liefert über ComStack_Types.h die gemeinsamen Typen, mit denen alle Schichten des Classic-Kommunikationsstapels PDUs adressieren und austauschen: PduIdType als Handle, PduLengthType als Länge und PduInfoType mit Nutzdatenzeiger, Metadatenzeiger und Länge ([SWS_COMTYPE_00011]). Transportprotokolle kopieren große PDUs segmentweise über StartOfReception, CopyRxData und CopyTxData. Den Pufferzustand melden sie mit BufReq_ReturnType, während RetryInfoType Bestätigung und Wiederholung steuert ([SWS_COMTYPE_00012]). Wichtigste Randbedingung: Die Breite von PduIdType und PduLengthType hängt von der EcuC-Konfiguration ab und wird generiert.

mehr ›

Das Modul comstack definiert den gemeinsamen Typvorrat des Classic-Kommunikationsstapels. Dazu gehören PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, RetryInfoType sowie Kennungen für Kanäle und Teilnetze, alle verfügbar über ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00038]). Bus-Interfaces, Transportprotokolle, PduR, Diagnosemodule und die RTE nutzen dieselben Typen; die RTE importiert sie ausdrücklich (SWS RTE S. 833).

Kontextdiagramm: Ein Typvorrat für alle Schichten, dimensioniert über die EcuC-Konfiguration. Quellen: [SWS_COMTYPE_00005], SWS RTE S. 833

Handles und Längen hängen von der Konfiguration ab. PduIdType ist uint8 oder uint16, PduLengthType uint8, uint16 oder uint32; beide werden aus der EcuC-Konfiguration generiert ([SWS_COMTYPE_00005], [SWS_COMTYPE_00008]). Jedes bereitstellende Modul wählt seine Handle-IDs selbst. Eindeutig müssen sie nur je API sein; der PduR übersetzt sie entlang des Routing-Pfads (ECU Configuration S. 156).

PduInfoType bündelt Nutzdatenzeiger, Metadatenzeiger und Länge. Damit trägt die Struktur Sendeaufträge, Empfangsindikationen und Trigger Transmit. Große PDUs werden stückweise kopiert: Das Transportprotokoll ruft über den PduR wiederholt CopyTxData der oberen Schicht auf (SWS PduR S. 109). Der Empfang beginnt mit StartOfReception und setzt sich mit CopyRxData fort.

Sequenzdiagramm: Das Transportprotokoll zieht die Sendedaten in einer Schleife aus dem DCM; die Bestätigung folgt am Ende. Quellen: SWS PduR S. 109

Fehler und Engpässe meldet BufReq_ReturnType ([SWS_COMTYPE_00012]):

• BUFREQ_E_BUSY: vorübergehend kein Puffer oder zu wenig Daten; der Aufruf darf wiederholt werden.
• BUFREQ_E_OVFL: kein Puffer der benötigten Länge.
• BUFREQ_E_NOT_OK: Abbruch.

Bestätigung und Wiederholung beim TP-Senden steuert RetryInfoType mit TP_DATACONF, TP_CONFPENDING und TP_DATARETRY samt Offset TxTpDataCnt ([SWS_COMTYPE_00027], [SWS_COMTYPE_00037]).

Weitere Kennungstypen ergänzen den Vorrat. NetworkHandleType (uint8) bezeichnet einen Kommunikationskanal. TPParameterType wählt STmin, Block Size oder Bandbreitensteuerung zur Änderung aus ([SWS_COMTYPE_00031]). PNCHandleType ist in R20-11 von uint8 abgeleitet ([SWS_COMTYPE_00036]); die R23-11-Fassung nennt abweichend uint16 (SWS ComStackTypes S. 17).

mehr ›

Rolle: gemeinsamer Typvorrat des Kommunikationsstapels

Das Modul comstack stellt keine eigenen Dienste bereit. Es definiert die Datentypen, über die die Module des Classic-Kommunikationsstapels miteinander kommunizieren. Dazu gehören PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, TpDataStateType, RetryInfoType, TPParameterType, NetworkHandleType und PNCHandleType. Sie sind über ComStack_Types.h verfügbar ([SWS_COMTYPE_00011], [SWS_COMTYPE_00037], [SWS_COMTYPE_00038]). Interpretation: Das Modul hat damit selbst kein Laufzeitverhalten. Frage Q-766338989232e06a (offen) Abläufe, Zustände und Fehlerreaktionen entstehen erst in den Modulen, die diese Typen in ihren Schnittstellen verwenden.

Die Systemgrenze verläuft deshalb quer durch den ganzen Stapel. Dieselben Typen nutzen:

• Bus-Interfaces wie CanIf und Transportprotokolle wie CanTp (SWS CanIf S. 87),
• der PDU Router und Diagnosemodule wie DCM (SWS PduR S. 109),
• SecOC (SWS SecOC S. 110),
• die RTE, die BufReq_ReturnType, PduIdType, PduInfoType, PduLengthType und RetryInfoType ausdrücklich aus ComStack_Types.h importiert (SWS RTE S. 833).

Kontextdiagramm: Alle Schichten vom Bus-Interface bis zur RTE stützen sich auf denselben Typvorrat aus ComStack_Types.h; dessen Größen werden aus der EcuC-Konfiguration erzeugt. Quellen: [SWS_COMTYPE_00005], SWS RTE S. 833, SWS PduR S. 33, SWS ComM S. 171

PDU-Handles und Längen: Identität und Größe einer PDU

PduIdType ist eine nullbasierte Ganzzahl im Bereich 0…<PduIdmax>. Ihre Breite (uint8 oder uint16) hängt von der maximalen Zahl an PDUs ab, die ein einzelnes Softwaremodul verwaltet. Das Generatorwerkzeug erzeugt sie aus dem in der virtuellen EcuC-Schicht konfigurierten Wert in ComStack_Cfg.h ([SWS_COMTYPE_00005]). Der zugehörige Parameter PduIdTypeEnum legt die Regel fest: UINT8 genügt, solange kein Modul mehr als 256 PDUs behandelt, sonst ist UINT16 nötig (ECU Configuration S. 153).

Analog ist PduLengthType konfigurationsabhängig als uint8, uint16 oder uint32 ausgeprägt. Maßgeblich ist die maximale Länge der PDUs, die ein Steuergerät sendet ([SWS_COMTYPE_00008]). Auch Transportprotokolle leiten Längen aus der EcuC ab: CanTp bestimmt die maximale Sendelänge der N-PDU aus dem EcuC-Parameter PduLength (SWS CanTp S. 60).

Die APIs des Stapels kombinieren zwei Dinge: einen Zeiger auf den PDU-Datenpuffer und eine Handle-ID, die festlegt, zu welcher PDU dieser Zeiger gehört. Den Wert der Handle-ID wählt das bereitstellende Modul frei. So kann dieselbe PDU von Com mit ID 5 an den PduR gehen und vom PduR mit ID 19 an CanIf. Eindeutig muss die ID nur im Geltungsbereich der jeweiligen API sein (ECU Configuration S. 156). Damit zwei Module dieselbe PDU referenzieren können, gibt es in der virtuellen Modulkonfiguration EcuC die modulunabhängige EcucPduCollection (ECU Configuration S. 154). Der PduR identifiziert einen Routing-Pfad über Quell-ID und Ziel-IDs, setzt die IDs um und reicht den PduInfoType-Wert unverändert weiter (SWS PduR S. 33).

Kollaborationsdiagramm: Jede Schnittstelle hat eigene Handle-IDs; der PduR übersetzt sie, während die gemeinsame PDU über die EcucPduCollection referenziert wird. Quellen: ECU Configuration S. 156, ECU Configuration S. 154, SWS PduR S. 33

PduInfoType: Nutzdaten, Metadaten und Länge in einer Struktur

PduInfoType bündelt drei Elemente ([SWS_COMTYPE_00011]):

• SduDataPtr zeigt auf die Nutzdaten.
• MetaDataPtr zeigt auf Metadaten wie CAN-ID, Socket-ID oder Diagnoseadressen. Deren Länge und Typ sind je PDU statisch konfiguriert; Elemente mit mehr als 8 Bit stehen in Plattform-Byte-Reihenfolge.
• SduLength vom Typ PduLengthType gibt die SDU-Länge in Bytes an.

Dieselbe Struktur trägt mehrere Interaktionsformen:

• Sendeauftrag: <Mod>_Transmit(TxPduId, const PduInfoType*) übergibt Länge, Datenzeiger und Metadatenzeiger und liefert E_OK oder E_NOT_OK (SWS CanIf S. 87).
• Empfangsindikation: <Mod>_RxIndication(RxPduId, const PduInfoType*). Bei CanNm ist der Datenzeiger nur bis zur Rückkehr der Indikation gültig (SWS CanNm S. 73).
• Trigger Transmit: PduInfoPtr ist Ein- und Ausgabe. Beim Aufruf enthält SduLength die verfügbare Puffergröße, bei der Rückkehr die Länge der kopierten Daten (SWS CanIf S. 107). Im vorangehenden Sendeauftrag übergibt die obere Schicht nur die Länge; SduDataPtr zeigt dann auf NULL (SWS CanIf S. 158).
• TP-Kopierschnittstellen: StartOfReception, CopyRxData und CopyTxData mit Rückgabe BufReq_ReturnType (SWS PduR S. 93).

Transportprotokoll-Puffer: segmentweises Kopieren statt Übergabe

Große PDUs werden nicht als Ganzes übergeben. Der Sender holt die Daten stückweise ab: DCM stößt über den PduR CanTp_Transmit an. CanTp ruft danach wiederholt PduR_CanTpCopyTxData auf, das an Dcm_CopyTxData weitergeleitet wird. Am Ende stehen PduR_CanTpTxConfirmation und Dcm_TpTxConfirmation (SWS PduR S. 109). Für die Parameter von CopyTxData gilt:

• info liefert Zielpuffer und Anzahl der zu kopierenden Bytes.
• Ein SduLength von 0 meldet nur einen Zustandswechsel im retry-Parameter oder fragt die verfügbare Datenmenge ab; SduDataPtr darf dann NULL_PTR sein (SWS PduR S. 93).
• availableDataPtr meldet die verbleibenden Sendedaten. TP-Module mit dynamischer Nutzlastlänge, etwa FrIsoTp, bemessen daran die folgenden Consecutive Frames (SWS LdCom S. 34).

Sequenzdiagramm: Beim TP-Senden zieht das Transportprotokoll die Daten in einer Schleife über den PduR aus der oberen Schicht; die Bestätigung folgt erst nach dem letzten Segment. Quellen: SWS PduR S. 109, SWS PduR S. 93, [SWS_COMTYPE_00012]

Der Empfang verläuft in drei Schritten:

1. StartOfReception eröffnet die Verbindung. info trägt die Daten des First oder Single Frame samt Metadaten, oder es ist NULL_PTR, wenn keines von beiden vorliegt. TpSduLength nennt die Gesamtlänge. Über bufferSizePtr meldet der Empfänger seinen freien Puffer; das Transportprotokoll berechnet daraus die Block Size (SWS PduR S. 92).
2. Jeder CopyRxData-Aufruf liefert das nächste Stück der I-PDU und schreibt den verbleibenden Puffer zurück (SWS PduR S. 91).
3. Eine RxIndication schließt den Empfang ab.

Wird eine TP-PDU zusätzlich gegatewayt, puffert der PduR sie selbst, weil der DCM vom Gatewaying nichts weiß (SWS PduR S. 112).

Sequenzdiagramm: Der TP-Empfang beginnt mit einer Pufferaushandlung, setzt sich segmentweise fort und endet mit der Indikation. Quellen: SWS PduR S. 112, SWS PduR S. 92, SWS PduR S. 91

Bestätigung und Wiederholung: RetryInfoType und TpDataStateType

RetryInfoType enthält zwei Felder ([SWS_COMTYPE_00037]):

• TpDataState beschreibt den Zustand des TP-Puffers.
• TxTpDataCnt gibt den Offset ab der aktuellen Position an, der die Zahl der erneut zu sendenden Bytes bestimmt.

TpDataStateType kennt drei Werte ([SWS_COMTYPE_00027]):

• TP_DATACONF: Alle bisher kopierten Daten sind bestätigt und dürfen aus dem TP-Puffer entfernt werden. Die in diesem Aufruf kopierten Daten sind davon ausgenommen.
• TP_DATARETRY: Bereits kopierte Daten werden erneut kopiert, um einen Fehler zu beheben. TxTpDataCnt gibt den Startoffset an.
• TP_CONFPENDING: Die bisher kopierten Daten müssen für die Fehlerbehebung im TP-Puffer bleiben.

Ist retry selbst NULL_PTR, dürfen die Daten sofort nach dem Kopieren freigegeben werden (SWS PduR S. 93).

Aktivitätsdiagramm: Ein CopyTxData-Aufruf wertet zuerst den retry-Parameter aus und entscheidet dann über Kopieren oder BUFREQ_E_BUSY. Quellen: SWS PduR S. 93, [SWS_COMTYPE_00027], [SWS_COMTYPE_00012]

Das Schaubild zum J1939-Transportprotokoll zeigt das Zusammenspiel konkret:

• Je Block wird das erste Paket mit TP_DATACONF angefordert, die folgenden mit TP_CONFPENDING.
• Geht ein TP.DT verloren, beginnt die Übertragung wieder beim ersten Paket des Blocks. Dazu wird TP_DATARETRY gesetzt, und TxTpDataCnt enthält den Offset zum Blockanfang (SWS J1939Tp S. 55).

Nicht jeder Nutzer wertet den Parameter aus: Bei LdCom wird retry laut Spezifikation weder von LdCom noch von seiner oberen Schicht behandelt (SWS LdCom S. 34).

Sequenzdiagramm: Blockweise Übertragung mit Bestätigungszuständen und Rücksprung an den Blockanfang bei verlorenem Datenpaket. Quellen: SWS J1939Tp S. 55, [SWS_COMTYPE_00027], [SWS_COMTYPE_00037]

Kanäle, Teilnetze und TP-Parameter

NetworkHandleType ist ein uint8 mit dem nullbasierten Bereich 0..255. Er speichert die Kennung eines Kommunikationskanals ([SWS_COMTYPE_00038]). Beispiele aus späteren Releases:

• Bus Mirroring meldet einen LIN-Frame mit dem ComM-Kanal, der dem LIN-Kanal zugeordnet ist (SWS Mirror S. 80).
• J1939Dcm übergibt den Kanal, auf dem eine Anfrage einging (SWS J1939Dcm S. 67).

PNCHandleType speichert die Kennung eines Partial Network Cluster und ist in R20-11 von uint8 abgeleitet ([SWS_COMTYPE_00036]). Die Dokumentstelle aus R23-11 nennt dagegen uint16 (SWS ComStackTypes S. 17). Für R20-11 gilt das Requirement. Den Einsatzkontext der PNC-Kennungen zeigt etwa das synchronisierte PNC-Abschalten im ComM (SWS ComM S. 171).

TPParameterType benennt den Transportprotokoll-Parameter, dessen Wert geändert werden soll ([SWS_COMTYPE_00031]):

• TP_STMIN: Separation Time,
• TP_BS: Block Size,
• TP_BC: Bandbreitensteuerung des FlexRay-Transportprotokolls.

Block Size und STmin erscheinen etwa im Flow-Control-Frame des FlexRay-AR-Transportprotokolls (SWS FrArTp S. 47).

Verhalten im Fehlerfall

Den Ausgang einer Pufferanforderung beschreibt BufReq_ReturnType ([SWS_COMTYPE_00012]):

• BUFREQ_OK (0): erfolgreich.
• BUFREQ_E_NOT_OK (1): Der Puffer ist nicht zugänglich.
• BUFREQ_E_BUSY (2): Vorübergehend ist kein Puffer verfügbar; der Anforderer soll es für eine gewisse Zeit erneut versuchen.
• BUFREQ_E_OVFL (3): Kein Puffer der benötigten Länge bereitstellbar.

Die Schnittstellen ordnen diese Werte so zu:

• CopyTxData: Reichen die Sendedaten nicht aus, wird nichts kopiert und BUFREQ_E_BUSY geliefert; die untere Schicht darf den Aufruf wiederholen (SWS PduR S. 93). Im Paged-Buffer-Ablauf des DCM tritt BUFREQ_E_BUSY im Wechsel mit dem Aufbereiten der nächsten Seite auf (SWS DCM S. 481).
• StartOfReception: BUFREQ_E_NOT_OK lehnt die Verbindung ab und bricht den Empfang ab; bufferSizePtr bleibt unverändert. BUFREQ_E_OVFL bricht ab, weil kein Puffer der benötigten Länge bereitsteht. Bei BUFREQ_OK ohne Puffer der angeforderten Größe wird eine Puffergröße von 0 gemeldet (SWS DCM S. 273).
• CopyRxData: BUFREQ_E_NOT_OK bedeutet, dass wegen eines Fehlers nichts kopiert wurde (SWS PduR S. 91).
• Übertragungsfehler im TP: Die Behebung läuft über TP_DATARETRY mit dem Offset TxTpDataCnt ([SWS_COMTYPE_00027]).
• TriggerTransmit: E_NOT_OK heißt, dass nichts kopiert wurde. PduInfoPtr darf dann nicht verwendet werden, weil er NULL oder ungültig sein kann (SWS CanIf S. 107).

Weitere Prüfungen legen die nutzenden Module selbst fest. Beispiele:

• DoIP_SoAdTpCopyRxData prüft bei aktivierter Entwicklungsfehlererkennung, ob DoIP_Init zuvor aufgerufen wurde (SWS DoIP S. 77).
• FrIf_Transmit liefert im Zustand FRIF_STATE_OFFLINE den Wert E_NOT_OK (SWS FrIf S. 68).
• Viele dieser Funktionen sind nur für verschiedene PDU-IDs reentrant, nicht für dieselbe (SWS DoIP S. 75).

Weiterführende Detailbelege

Die folgende Übersicht ordnet die wichtigsten Belege ein ([SWS_COMTYPE_00005] bis [SWS_COMTYPE_00038]):

Beleg	Einordnung
[SWS_COMTYPE_00005], [SWS_COMTYPE_00008]	Konfigurationsabhängige Breite von PduIdType und PduLengthType, generiert aus EcuC
[SWS_COMTYPE_00011]	Aufbau von PduInfoType einschließlich Metadaten
[SWS_COMTYPE_00012]	Ergebniscodes aller TP-Pufferanforderungen
[SWS_COMTYPE_00027], [SWS_COMTYPE_00037]	Bestätigungs- und Wiederholungslogik beim TP-Senden
[SWS_COMTYPE_00031], [SWS_COMTYPE_00036], [SWS_COMTYPE_00038]	TP-Parameterauswahl, PNC- und Kanalkennungen
ECU Configuration S. 156	Handle-ID-Konzept: Werte je Modul frei wählbar, eindeutig je API
SWS PduR S. 93, SWS PduR S. 92	Referenzsemantik der TP-Kopierschnittstellen
SWS J1939Tp S. 55	Schaubild zum Retry-Handling (auch für R20-11 ausgewiesen)