klasse apext::diag::uds_transport::UdsMessage

De klasse apext::diag::uds_transport::UdsMessage vormt het gestandaardiseerde opslag- en transferobject voor diagnoseberichten die worden uitgewisseld tussen de generieke diagnosekern en transportspecifieke handlers. Instanties worden uitsluitend gecreëerd door de generieke kern met geoptimaliseerde geheugenallocatie en beschikbaar gesteld via UdsMessagePtr [SWS_DM_09012]. In het ontvangstpad vult de handler de beschikbaar gestelde databuffer beginnend bij het service-ID en stuurt het bericht door na het toevoegen van eventuele kanaalmetadata [SWS_DM_00388]. Kan de kern een bericht wegens bestaande belasting niet verwerken, dan wordt de toewijzing geweigerd en een nullpointer geretourneerd [SWS_DM_00386].

meer ›

Context

De klasse apext::diag::uds_transport::UdsMessage vormt het centrale data- en opslagobject voor UDS-berichten die worden uitgewisseld tussen de generieke kern van het Diagnostic Management (DM Generic Core respectievelijk UdsTransportProtocolMgr) en een specifieke implementatie van UdsTransportProtocolHandler. Deze dient als inkapseling en opslag (storage) voor inkomende UDS-requests en uitgaande UDS-responses.

Naast de nuttige data transporteert UdsMessage de adresseringsparameters van de diagnosecommunicatie: het bronadres Address [SWS_DM_00293] via GetSa() [SWS_DM_00297], het doeladres via GetTa() [SWS_DM_00298] en het adrestype TargetAddressType (fysiek met kPhysical of functioneel met kFunctional) [SWS_DM_00296] via GetTaType() [SWS_DM_00299]. Bovendien kunnen via AddMetaInfo() kanaalspecifieke meta-informatie zoals verbindingsparameters voor DoIP worden toegevoegd [SWS_DM_00294], [SWS_DM_00302].

Contextdiagram: Samenspel tussen DM-kern, transporthandler en UdsMessage. Bronnen: [SWS_DM_09012], [SWS_DM_00385], [SWS_DM_00345]

Levenscyclus

Instanties van UdsMessage worden met geoptimaliseerde resource-allocatie uitsluitend door de generieke kern van het Diagnostic Management gecreëerd. Om een ongecontroleerde instantiëring door protocolhandlers te verhinderen, is de standaardconstructor beschermd (protected) gedeclareerd [SWS_DM_09012]. Handlers krijgen uitsluitend toegang tot berichtobjecten via eigenaarpointers van het type apext::diag::uds_transport::UdsMessagePtr [SWS_DM_00303] of voor puur leestoegangen via apext::diag::uds_transport::UdsMessageConstPtr [SWS_DM_00304], AUTOSAR_AP_SWS_Diagnostics p. 98.

De vernietiging van het object vindt plaats via de virtuele destructor ~UdsMessage() [SWS_DM_09010]. Wat betreft gelijktijdigheid zijn de opvraagmethoden voor adresinformatie (GetSa, GetTa, GetTaType) herintredend (reentrant) en uitzonderingsveilig (noexcept) [SWS_DM_00297], [SWS_DM_00298], [SWS_DM_00299]. De toegang tot de databuffer via GetPayload() en het toevoegen van metadata via AddMetaInfo() zijn daarentegen geclassificeerd als niet-thread-safe, omdat de implementatie in het kader van deze aanroepen buffer- en resource-allocaties mag uitvoeren [SWS_DM_00300], [SWS_DM_00301], [SWS_DM_00302].

Gebruikspad

In het reguliere verloop van het ontvangstpad meldt de UdsTransportProtocolHandler een inkomend UDS-verzoek via UdsTransportProtocolMgr::IndicateMessage() aan bij het DM [SWS_DM_00385]. Voor zover het DM gereed is voor opname, bevestigt het dit met de status kIndicationOk en overhandigt een UdsMessagePtr met een minimale grootte van één byte en de door het DM gewenste buffercapaciteit [SWS_DM_00385].

Vervolgens roept de protocolhandler de niet-constante methode GetPayload() aan om een schrijfbare referentie naar het onderliggende geheugengebied (uds_transport::ByteSpan&) te verkrijgen [SWS_DM_00301]. Deze vult deze buffer beginnend bij de service-identificatie (SID) tot aan de maximale capaciteit van het UdsMessage-object of de volledige berichtlengte [SWS_DM_00388]. Na het optioneel toevoegen van kanaalspecifieke metadata via AddMetaInfo() [SWS_DM_00302] stuurt de handler het gevulde object via UdsTransportProtocolMgr::HandleMessage() door naar de diagnosekern [SWS_DM_00345]. (Interpretatie: In het transmissiepad voor diagnoseresponses zal de beschikbaarstelling van UdsMessage vermoedelijk analoog door de generieke kern plaatsvinden.) Vraag Q-4f568a0e527bdfbc (open)

Sequentiediagram: Interactievolgorde bij de ontvangst van een UDS-bericht. Bronnen: [SWS_DM_00385], [SWS_DM_00386], [SWS_DM_00388], [SWS_DM_00301], [SWS_DM_00302], [SWS_DM_00345]

Foutscenario's

Kan het DM het via IndicateMessage() aangemelde bericht niet verwerken omdat het bezet is door de actieve afhandeling van een dienst van dezelfde Tester-Present-sessie, dan retourneert het de status kIndicationOccupied en een UdsMessagePtr gelijk aan nullptr [SWS_DM_00386]. In dit geval wordt geen UdsMessage beschikbaar gesteld en wordt de ontvangst afgebroken. Evenzo leidt een onbekend doeladres tot het resultaat kIndicationUnknownTargetAddress met een nullpointer als berichtreferentie AUTOSAR_AP_SWS_Diagnostics p. 100.

Bij het vullen van de buffer moet de protocolhandler de voorgeschreven buffercapaciteit in acht nemen: Binnenkomende verzoeken die de beschikbaar gestelde capaciteit van de UdsMessage overschrijden, worden begrensd op de volledige buffergrootte [SWS_DM_00388]. Bovendien leiden gelijktijdige, onbeschermde toegangen tot GetPayload() of AddMetaInfo() vanuit meerdere threads tot ongedefinieerd gedrag, aangezien deze interfaces expliciet als thread-onveilig (unsafe) gespecificeerd zijn [SWS_DM_00300], [SWS_DM_00301], [SWS_DM_00302].