Communication Stack Types (ComStack_Types)

De module comstack levert via ComStack_Types.h de gemeenschappelijke types waarmee alle lagen van de Classic-communicatiestack PDU's adresseren en uitwisselen: PduIdType als handle, PduLengthType als lengte en PduInfoType met payloadpointer, metadatapointer en lengte ([SWS_COMTYPE_00011]). Transportprotocollen kopiëren grote PDU's segmentsgewijs via StartOfReception, CopyRxData en CopyTxData. De buffertoestand melden ze met BufReq_ReturnType, terwijl RetryInfoType bevestiging en herhaling bestuurt ([SWS_COMTYPE_00012]). Belangrijkste randvoorwaarde: de breedte van PduIdType en PduLengthType hangt af van de EcuC-configuratie en wordt gegenereerd.

meer ›

De module comstack definieert de gemeenschappelijke typeset van de Classic-communicatiestack. Daartoe behoren PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, RetryInfoType evenals identifiers voor kanalen en deelnetwerken, alle beschikbaar via ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00038]). Bus-interfaces, transportprotocollen, PduR, diagnosemodules en de RTE gebruiken dezelfde types; de RTE importeert ze uitdrukkelijk (SWS RTE p. 833).

Contextdiagram: één typeset voor alle lagen, gedimensioneerd via de EcuC-configuratie. Bronnen: [SWS_COMTYPE_00005], SWS RTE p. 833

Handles en lengtes hangen af van de configuratie. PduIdType is uint8 of uint16, PduLengthType uint8, uint16 of uint32; beide worden gegenereerd uit de EcuC-configuratie ([SWS_COMTYPE_00005], [SWS_COMTYPE_00008]). Elke leverende module kiest zijn eigen handle-ID's. Deze hoeven alleen per API uniek te zijn; de PduR vertaalt ze langs het routeringspad (ECU Configuration p. 156).

PduInfoType bundelt payloadpointer, metadatapointer en lengte. Daarmee draagt de structuur zendopdrachten, ontvangstindicaties en Trigger Transmit. Grote PDU's worden stapsgewijs gekopieerd: het transportprotocol roept via de PduR herhaaldelijk CopyTxData van de bovenliggende laag op (SWS PduR p. 109). De ontvangst begint met StartOfReception en wordt voortgezet met CopyRxData.

Sequentiediagram: het transportprotocol haalt de te verzenden gegevens in een lus op uit de DCM; de bevestiging volgt aan het einde. Bronnen: SWS PduR p. 109

Fouten en knelpunten worden gemeld door BufReq_ReturnType ([SWS_COMTYPE_00012]):

• BUFREQ_E_BUSY: tijdelijk geen buffer of te weinig gegevens; de aanroep mag worden herhaald.
• BUFREQ_E_OVFL: geen buffer van de vereiste lengte.
• BUFREQ_E_NOT_OK: afbreken.

Bevestiging en herhaling bij het TP-verzenden worden bestuurd door RetryInfoType met TP_DATACONF, TP_CONFPENDING en TP_DATARETRY inclusief offset TxTpDataCnt ([SWS_COMTYPE_00027], [SWS_COMTYPE_00037]).

Verdere identifiertypes vullen de set aan. NetworkHandleType (uint8) duidt een communicatiekanaal aan. TPParameterType selecteert STmin, Block Size of bandbreedteregeling voor wijziging ([SWS_COMTYPE_00031]). PNCHandleType is in R20-11 afgeleid van uint8 ([SWS_COMTYPE_00036]); de versie van R23-11 vermeldt in afwijking daarvan uint16 (SWS ComStackTypes p. 17).

meer ›

Rol: gemeenschappelijke typeset van de communicatiestack

De module comstack stelt zelf geen services beschikbaar. Deze definieert de datatypes waarmee de modules van de Classic-communicatiestack met elkaar communiceren. Daartoe behoren PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, TpDataStateType, RetryInfoType, TPParameterType, NetworkHandleType en PNCHandleType. Ze zijn beschikbaar via ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00037], [SWS_COMTYPE_00038]). Interpretatie: de module heeft daardoor zelf geen runtime-gedrag. Vraag Q-766338989232e06a (open) Processen, toestanden en foutreacties ontstaan pas in de modules die deze types in hun interfaces gebruiken.

De systeemgrens loopt daarom dwars door de gehele stack. Dezelfde types worden gebruikt door:

• bus-interfaces zoals CanIf en transportprotocollen zoals CanTp (SWS CanIf p. 87),
• de PDU Router en diagnosemodules zoals DCM (SWS PduR p. 109),
• SecOC (SWS SecOC p. 110),
• de RTE, die BufReq_ReturnType, PduIdType, PduInfoType, PduLengthType en RetryInfoType uitdrukkelijk importeert uit ComStack_Types.h (SWS RTE p. 833).

Contextdiagram: alle lagen van de bus-interface tot de RTE baseren zich op dezelfde typeset uit ComStack_Types.h; de groottes daarvan worden gegenereerd uit de EcuC-configuratie. Bronnen: [SWS_COMTYPE_00005], SWS RTE p. 833, SWS PduR p. 33, SWS ComM p. 171

PDU-handles en -lengtes: identiteit en grootte van een PDU

PduIdType is een zero-based geheel getal in het bereik 0…<PduIdmax>. De breedte ervan (uint8 of uint16) hangt af van het maximale aantal PDU's dat een afzonderlijke softwaremodule beheert. De generatortool genereert deze op basis van de waarde in ComStack_Cfg.h die in de virtuele EcuC-laag is geconfigureerd ([SWS_COMTYPE_00005]). De bijbehorende parameter PduIdTypeEnum legt de regel vast: UINT8 volstaat zolang geen enkele module meer dan 256 PDU's verwerkt, anders is UINT16 vereist (ECU Configuration p. 153).

Analoog is PduLengthType configuratieafhankelijk vormgegeven als uint8, uint16 of uint32. Bepalend is de maximale lengte van de PDU's die een regeleenheid verzendt ([SWS_COMTYPE_00008]). Ook transportprotocollen leiden lengtes af uit de EcuC: CanTp bepaalt de maximale zendlengte van de N-PDU uit de EcuC-parameter PduLength (SWS CanTp p. 60).

De API's van de stack combineren twee zaken: een pointer naar de PDU-databuffer en een handle-ID die vastlegt bij welke PDU deze pointer hoort. De waarde van de handle-ID wordt vrij gekozen door de aanbiedende module. Zo kan dezelfde PDU vanuit Com met ID 5 naar de PduR gaan en vanuit de PduR met ID 19 naar CanIf. De ID hoeft alleen uniek te zijn binnen het geldigheidsgebied van de desbetreffende API (ECU Configuration p. 156). Om ervoor te zorgen dat twee modules naar dezelfde PDU kunnen verwijzen, bevat de virtuele moduleconfiguratie EcuC de module-onafhankelijke EcucPduCollection (ECU Configuration p. 154). De PduR identificeert een routeringspad via bron-ID en doel-ID's, converteert de ID's en geeft de PduInfoType-waarde ongewijzigd door (SWS PduR p. 33).

Collaboratiediagram: elke interface heeft eigen handle-ID's; de PduR vertaalt deze, terwijl naar de gemeenschappelijke PDU wordt verwezen via de EcucPduCollection. Bronnen: ECU Configuration p. 156, ECU Configuration p. 154, SWS PduR p. 33

PduInfoType: payload, metadata en lengte in één structuur

PduInfoType bundelt drie elementen ([SWS_COMTYPE_00011]):

• SduDataPtr wijst naar de payload.
• MetaDataPtr wijst naar metadata zoals CAN-ID, socket-ID of diagnoseadressen. De lengte en het type daarvan zijn per PDU statisch geconfigureerd; elementen met meer dan 8 bits staan in platform-bytevolgorde.
• SduLength van het type PduLengthType geeft de SDU-lengte in bytes aan.

Dezelfde structuur ondersteunt meerdere interactievormen:

• Verzendopdracht: <Mod>_Transmit(TxPduId, const PduInfoType*) geeft lengte, data-pointer en metadata-pointer door en retourneert E_OK of E_NOT_OK (SWS CanIf p. 87).
• Ontvangstindicatie: <Mod>_RxIndication(RxPduId, const PduInfoType*). Bij CanNm is de data-pointer alleen geldig tot aan de return van de indicatie (SWS CanNm p. 73).
• Trigger Transmit: PduInfoPtr fungeert als in- en uitvoer. Bij het aanroepen bevat SduLength de beschikbare buffergrootte, bij terugkeer de lengte van de gekopieerde data (SWS CanIf p. 107). In de voorafgaande verzendopdracht geeft de bovenste laag alleen de lengte door; SduDataPtr wijst dan naar NULL (SWS CanIf p. 158).
• TP-kopieerinterfaces: StartOfReception, CopyRxData en CopyTxData met returnwaarde BufReq_ReturnType (SWS PduR p. 93).

Transportprotocol-buffers: segmentsgewijs kopiëren in plaats van overdragen

Grote PDU's worden niet in hun geheel overgedragen. De zender haalt de data stapsgewijs op: DCM triggert CanTp_Transmit via de PduR. CanTp roept daarna herhaaldelijk PduR_CanTpCopyTxData aan, dat wordt doorgestuurd naar Dcm_CopyTxData. Aan het einde volgen PduR_CanTpTxConfirmation en Dcm_TpTxConfirmation (SWS PduR p. 109). Voor de parameters van CopyTxData geldt:

• info levert de doelbuffer en het aantal te kopiëren bytes.
• Een SduLength van 0 meldt alleen een statuswijziging in de parameter retry of vraagt de beschikbare datahoeveelheid op; SduDataPtr mag dan NULL_PTR zijn (SWS PduR p. 93).
• availableDataPtr meldt de resterende verzenddata. TP-modules met een dynamische payloadlengte, zoals FrIsoTp, stemmen hierop de volgende Consecutive Frames af (SWS LdCom p. 34).

Sequentiediagram: Bij TP-verzending haalt het transportprotocol de data in een lus via de PduR op uit de bovenste laag; de bevestiging volgt pas na het laatste segment. Bronnen: SWS PduR p. 109, SWS PduR p. 93, [SWS_COMTYPE_00012]

De ontvangst verloopt in drie stappen:

1. StartOfReception opent de verbinding. info bevat de data van het First of Single Frame inclusief metadata, of is NULL_PTR wanneer geen van beide aanwezig is. TpSduLength geeft de totale lengte aan. Via bufferSizePtr meldt de ontvanger zijn vrije buffer; het transportprotocol berekent daaruit de Block Size (SWS PduR p. 92).
2. Elke aanroep van CopyRxData levert het volgende deel van de I-PDU op en schrijft de resterende buffer terug (SWS PduR p. 91).
3. Een RxIndication sluit de ontvangst af.

Als een TP-PDU bovendien wordt gegatewayd, buffert de PduR deze zelf, omdat de DCM niets weet van het gatewayen (SWS PduR p. 112).

Sequentiediagram: De TP-ontvangst begint met een bufferonderhandeling, wordt segmentsgewijs voortgezet en eindigt met de indicatie. Bronnen: SWS PduR p. 112, SWS PduR p. 92, SWS PduR p. 91

Bevestiging en herhaling: RetryInfoType en TpDataStateType

RetryInfoType bevat twee velden ([SWS_COMTYPE_00037]):

• TpDataState beschrijft de toestand van de TP-buffer.
• TxTpDataCnt geeft de offset vanaf de huidige positie aan, die het aantal opnieuw te verzenden bytes bepaalt.

TpDataStateType kent drie waarden ([SWS_COMTYPE_00027]):

• TP_DATACONF: Alle tot nu toe gekopieerde data zijn bevestigd en mogen uit de TP-buffer worden verwijderd. De in deze aanroep gekopieerde data zijn hiervan uitgezonderd.
• TP_DATARETRY: Reeds gekopieerde data worden opnieuw gekopieerd om een fout te herstellen. TxTpDataCnt geeft de startoffset aan.
• TP_CONFPENDING: De tot nu toe gekopieerde data moeten voor foutafhandeling in de TP-buffer blijven.

Als retry zelf NULL_PTR is, mogen de data direct na het kopiëren worden vrijgegeven (SWS PduR p. 93).

Activiteitendiagram: Een CopyTxData-aanroep evalueert eerst de retry-parameter en beslist vervolgens over kopiëren of BUFREQ_E_BUSY. Bronnen: SWS PduR p. 93, [SWS_COMTYPE_00027], [SWS_COMTYPE_00012]

Het schema voor het J1939-transportprotocol toont het samenspel concreet:

• Per blok wordt het eerste pakket aangevraagd met TP_DATACONF, de daaropvolgende met TP_CONFPENDING.
• Gaat een TP.DT verloren, dan begint de overdracht weer bij het eerste pakket van het blok. Daartoe wordt TP_DATARETRY ingesteld en TxTpDataCnt bevat de offset naar het begin van het blok (SWS J1939Tp p. 55).

Niet elke gebruiker evalueert de parameter: bij LdCom wordt retry volgens de specificatie noch door LdCom noch door de bovenste laag ervan behandeld (SWS LdCom p. 34).

Sequentiediagram: Bloksugewijze overdracht met bevestigingstoestanden en terugsprong naar het begin van het blok bij een verloren datapakket. Bronnen: SWS J1939Tp p. 55, [SWS_COMTYPE_00027], [SWS_COMTYPE_00037]

Kanalen, deelnetwerken en TP-parameters

NetworkHandleType is een uint8 met het zero-based bereik 0..255. Het slaat de identificatie van een communicatiekanaal op ([SWS_COMTYPE_00038]). Voorbeelden uit latere releases:

• Bus Mirroring meldt een LIN-frame met het ComM-kanaal dat aan het LIN-kanaal is toegewezen (SWS Mirror p. 80).
• J1939Dcm geeft het kanaal door waarop een verzoek is binnengekomen (SWS J1939Dcm p. 67).

PNCHandleType slaat de identificatie van een Partial Network Cluster op en is in R20-11 afgeleid van uint8 ([SWS_COMTYPE_00036]). De passage uit R23-11 noemt daarentegen uint16 (SWS ComStackTypes p. 17). Voor R20-11 geldt de requirement. De toepassingscontext van de PNC-identificaties blijkt bijvoorbeeld uit het gesynchroniseerde uitschakelen van PNC's in de ComM (SWS ComM p. 171).

TPParameterType specificeert de transportprotocolparameter waarvan de waarde moet worden gewijzigd ([SWS_COMTYPE_00031]):

• TP_STMIN: Separation Time,
• TP_BS: Block Size,
• TP_BC: bandbreedteregeling van het FlexRay-transportprotocol.

Block Size en STmin verschijnen bijvoorbeeld in het Flow-Control-frame van het FlexRay-AR-transportprotocol (SWS FrArTp p. 47).

Gedrag in het foutgeval

De uitkomst van een bufferverzoek wordt beschreven door BufReq_ReturnType ([SWS_COMTYPE_00012]):

• BUFREQ_OK (0): succesvol.
• BUFREQ_E_NOT_OK (1): De buffer is niet toegankelijk.
• BUFREQ_E_BUSY (2): Tijdelijk is er geen buffer beschikbaar; de aanvrager moet het gedurende een bepaalde tijd opnieuw proberen.
• BUFREQ_E_OVFL (3): Er kan geen buffer van de vereiste lengte worden geleverd.

De interfaces wijzen deze waarden als volgt toe:

• CopyTxData: Als de verzenddata ontoereikend zijn, wordt er niets gekopieerd en wordt BUFREQ_E_BUSY geretourneerd; de onderste laag mag de aanroep herhalen (SWS PduR p. 93). In het paged-buffer-proces van de DCM treedt BUFREQ_E_BUSY afwisselend op met het voorbereiden van de volgende pagina (SWS DCM p. 481).
• StartOfReception: BUFREQ_E_NOT_OK wijst de verbinding af en breekt de ontvangst af; bufferSizePtr blijft ongewijzigd. BUFREQ_E_OVFL breekt af omdat er geen buffer van de vereiste lengte beschikbaar is. Bij BUFREQ_OK zonder buffer van de gevraagde grootte wordt een buffergrootte van 0 gemeld (SWS DCM p. 273).
• CopyRxData: BUFREQ_E_NOT_OK betekent dat er wegens een fout niets is gekopieerd (SWS PduR p. 91).
• Transmissiefout in het TP: Het herstel verloopt via TP_DATARETRY met de offset TxTpDataCnt ([SWS_COMTYPE_00027]).
• TriggerTransmit: E_NOT_OK houdt in dat er niets is gekopieerd. PduInfoPtr mag dan niet worden gebruikt, omdat deze NULL of ongeldig kan zijn (SWS CanIf p. 107).

Verdere controles worden door de gebruikende modules zelf gedefinieerd. Voorbeelden:

• DoIP_SoAdTpCopyRxData controleert bij ingeschakelde detectie van ontwikkelingsfouten of DoIP_Init vooraf is aangeroepen (SWS DoIP p. 77).
• FrIf_Transmit levert in de toestand FRIF_STATE_OFFLINE de waarde E_NOT_OK op (SWS FrIf p. 68).
• Veel van deze functies zijn alleen re-entrant voor verschillende PDU-ID's, niet voor dezelfde (SWS DoIP p. 75).

Verdere gedetailleerde bewijzen

Het volgende overzicht ordent de belangrijkste bewijsplaatsen ([SWS_COMTYPE_00005] tot [SWS_COMTYPE_00038]):

Referentie	Indeling
[SWS_COMTYPE_00005], [SWS_COMTYPE_00008]	Configuratieafhankelijke breedte van PduIdType en PduLengthType, gegenereerd vanuit EcuC
[SWS_COMTYPE_00011]	Opbouw van PduInfoType inclusief metadata
[SWS_COMTYPE_00012]	Resultaatcodes van alle TP-bufferverzoeken
[SWS_COMTYPE_00027], [SWS_COMTYPE_00037]	Bevestigings- en herhalingslogica bij TP-verzending
[SWS_COMTYPE_00031], [SWS_COMTYPE_00036], [SWS_COMTYPE_00038]	TP-parameterselectie, PNC- en kanaalidentificaties
ECU Configuration S. 156	Handle-ID-concept: waarden per module vrij te kiezen, uniek per API
SWS PduR S. 93, SWS PduR S. 92	Referentiesemantiek van de TP-kopieerinterfaces
SWS J1939Tp S. 55	Schema over de retry-afhandeling (ook aangemerkt voor R20-11)