module ara::diag — Diagnostics
ModulegidsAI-GEGENEREERD
Biedt gestandaardiseerde diagnosediensten, UDS- en SOVD-protocollen alsmede centraal foutgeheugenbeheer.
Biedt gestandaardiseerde diagnosediensten, UDS- en SOVD-protocollen alsmede centraal foutgeheugenbeheer.
Het functionele cluster Diagnostic Management biedt in het AUTOSAR Adaptive Platform de centrale infrastructuur voor de klassieke UDS- en moderne SOVD-voertuigdiagnose (AUTOSAR_AP_EXP_SWArchitecture p. 150). Als platformdaemon termineert het transportlagen zoals DoIP, stuurt protocolhandlers aan en stuurt diagnoseverzoeken via typeveilige callback-interfaces door naar Adaptive Applications ([SWS_DM_00311]). Tegelijkertijd neemt de module foutbewaking, tijd- en tellerontdendering en het beheer van het foutgeheugen voor zijn rekening. Applicaties schakelen servicefuncties vrij via een declaratief offer-model, waardoor applicatielogica en protocolafhandeling netjes van elkaar gescheiden blijven.
Het functionele cluster Diagnostic Management (ara::diag) biedt in het AUTOSAR Adaptive Platform de centrale, op een daemon gebaseerde infrastructuur voor de afhandeling van voertuigcompatibele diagnosecommunicatie (AUTOSAR_AP_EXP_SWArchitecture p. 150). Het ontkoppelt transportspecifieke protocolhandlers (zoals DoIP of CAN-TP) van de eigenlijke diagnosekern (UdsTransportProtocolMgr) en maakt zo een uniforme terminatie en doorzending van diagnoseverzoeken mogelijk (AUTOSAR_AP_EXP_SWArchitecture p. 164).
Contextdiagram: inbedding van de Diagnostic Management-daemon tussen transporthandlers, Adaptive Applications en externe testers. Bronnen: AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168
Voor de serviceafhandeling implementeert de module een declaratief beschikbaarstellingsmodel: de diagnosedaemon realiseert de port-interfaces, terwijl Adaptive Applications service-callbacks voor DataIdentifier, routines of blokgebaseerde overdrachten registreren en hun beschikbaarheid via Offer() resp. StopOffer() sturen ([SWS_DM_00557], AUTOSAR_AP_EXP_SWArchitecture p. 156). Binnenkomende berichten worden via tweetraps indicatie- en overdrachtsmechanismen (IndicateMessage en HandleMessage) fouttolerant verwerkt ([SWS_DM_00309], [SWS_DM_00311]).
Sequentiediagram: doorlopende control flow van een UDS-request van de transportlaag via de diagnosemanager tot de toepassende applicatie. Bronnen: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130
Naast klassieke UDS-functies beheert het cluster diagnostische monitors, voert geconfigureerde ontdenderingen uit en persisteert gekwalificeerde fouten in het primaire foutgeheugen (DTCInformation) ([SWS_DM_00664], SWS_Diagnostics p. 225). Uitgebreide standaarden zoals ISO 13400-2 (DoIP) en ASAM SOVD (Service-Oriented Vehicle Diagnostics) worden via gespecialiseerde interfaces voor activeringslijnen, authenticaties en hiërarchische JSON-payloads naadloos in het platform geïntegreerd ([SWS_DM_00834], [SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170).
Architecturale rol en systeemgrenzen van Diagnostic Management
Het functionele cluster Diagnostic Management (ara::diag) vormt in het AUTOSAR Adaptive Platform (release R25-11) het centrale knooppunt voor de voertuiginterne en externe voertuigdiagnose (AUTOSAR_AP_EXP_SWArchitecture p. 150). Architecturaal is de module ontworpen als een op een daemon gebaseerde achtergronddienst («aapFunctionalCluster» Diagnostic Management daemon-based). Het termineert zowel fysieke als logische diagnoseprotocollen, beheert de globale diagnosecontext en stelt de middleware-infrastructuur beschikbaar waarmee individuele Adaptive Applications diagnosegerelateerde gegevens en routines kunnen aanbieden (AUTOSAR_AP_EXP_SWArchitecture p. 156).
Het interfacelandschap is primair opgedeeld in twee categorieën: gemodelleerde port-interfaces, die via het AUTOSAR-manifest worden geconfigureerd en aan applicatieprocessen worden gebonden, en native C++-runtime-interfaces (AUTOSAR_AP_EXP_SWArchitecture p. 150). Tot de native interfaces behoort met name de klasse Conversation, waarmee applicaties actuele sessietoestanden kunnen opvragen ([SWS_DM_00696]), beveiligingsniveaus kunnen bepalen ([SWS_DM_00698]) of actieve diagnoseconversaties kunnen inspecteren ([SWS_DM_00783]). Interpretatie: de strikte scheiding tussen de centrale diagnosedaemon en de toepassende processen is vermoedelijk gekozen om deterministische responstijden richting externe testers te garanderen, ook bij herstarts van processen van individuele applicaties. Vraag Q-2e2ea8eb9d415fed (open)
Contextdiagram: inbedding van de Diagnostic Management-daemon tussen transporthandlers, Adaptive Applications en externe testers. Bronnen: AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168
Transportlaagaansluiting en levenscyclussturing van de protocolhandlers
Om onafhankelijk van specifieke netwerktechnologieën (zoals Ethernet/DoIP of CAN/ISO-TP) te opereren, ontkoppelt Diagnostic Management de protocolkern via gestandaardiseerde transportinterfaces (AUTOSAR_AP_EXP_SWArchitecture p. 164). De generieke kern implementeert de interface UdsTransportProtocolMgr, terwijl transportspecifieke adapters als UdsTransportProtocolHandler worden aangesloten (AUTOSAR_AP_EXP_SWArchitecture p. 165). Elke handler wordt geïdentificeerd via een unieke identifier, die via GetHandlerID() kan worden opgevraagd ([SWS_DM_00325]).
De levenscyclussturing van een transporthandler is onderverdeeld in deterministische operationele fasen (AUTOSAR_SWS_Diagnostics p. 128): tijdens het opstarten initialiseert Diagnostic Management de handler via Initialize() ([SWS_DM_00319]) en activeert vervolgens de berichtverwerking door middel van Start() ([SWS_DM_00322]). Bij een gecontroleerde beëindiging verzoekt de manager de handler via Stop() om open verbindingen te sluiten ([SWS_DM_00323]), waarna de handler de voltooiing via HandlerStopped() bevestigt ([SWS_DM_00314]).
Voor langlopende diagnosesessies specificeert AUTOSAR bovendien een herstelmechanisme over proceslevenscycli heen (AUTOSAR_SWS_Diagnostics p. 134). Kan een eerder gepersisteerd kanaal na een herstart van de diagnosemanager opnieuw worden opgezet, dan meldt de transporthandler dit via NotifyReestablishment() ([SWS_DM_00326]). De manager synchroniseert de toestand intern en bevestigt dit met het aanroepen van ChannelReestablished() ([SWS_DM_00313]).
Sequentiediagram: levenscyclussturing van een UDS-transporthandler door de generieke diagnosemanager. Bronnen: [SWS_DM_00314], [SWS_DM_00319], [SWS_DM_00322], [SWS_DM_00323], AUTOSAR_SWS_Diagnostics p. 128
UDS-serviceafhandeling en applicatiespecifieke request-handling
Binnenkomende UDS-berichten worden na de protocolvalidatie stapsgewijs verwerkt (AUTOSAR_SWS_Diagnostics p. 130). Eerst kondigt de transporthandler een beginnend bericht via IndicateMessage() aan bij de manager om resources en buffers te alloceren ([SWS_DM_00309]). Het bericht wordt ingekapseld als UdsMessage, die het bronadres ([SWS_DM_00297]), doeladres ([SWS_DM_00298]) en adresseringstype ([SWS_DM_00299]) verschaft. Na volledige ontvangst draagt de handler het gegevensobject via HandleMessage() over aan Diagnostic Management ([SWS_DM_00311]), waarbij kanaalspecifieke meta-informatie door middel van AddMetaInfo() wordt aangevuld ([SWS_DM_00302]).
In release R25-11 volgt de interactie tussen platformdaemon en applicatie een geïnverteerd service-beschikbaarstellingsmodel (AUTOSAR_AP_EXP_SWArchitecture p. 156): de platformdaemon realiseert de service-ports, terwijl Adaptive Applications callback-methoden implementeren en hun gereedheid voor doorzending expliciet via Offer() activeren ([SWS_DM_00557]) of via StopOffer() opschorten ([SWS_DM_00558]). Dit geldt evengoed voor generieke routines (GenericRoutine [SWS_DM_00552]), getypeerde routines (RoutineInterface [SWS_DM_00589] met Start [SWS_DM_00591]), data-identifiers (GenericDataIdentifier [SWS_DM_00634] met Read [SWS_DM_00636] en Write [SWS_DM_00637]) als generieke UDS-diensten (GenericUDSService [SWS_DM_00616] met HandleMessage [SWS_DM_00618]).
Langer durende diagnosetransacties (zoals blokoverdrachten via UploadService [SWS_DM_00797], DownloadService [SWS_DM_00787] of FileTransferService [SWS_DM_01325] conform AUTOSAR_AP_EXP_SWArchitecture p. 163) worden asynchroon via ara::core::Future afgehandeld. Om resourceblokkades te voorkomen, ontvangen applicatiespecifieke handlers een instantie van CancellationHandler (AUTOSAR_AP_EXP_SWArchitecture p. 152). Via IsCanceled() kan de applicatie een afbreking opvragen ([SWS_DM_00614]) of via SetNotifier() een notificatiefunctie registreren ([SWS_DM_00615]). Voor gecoördineerde herstarts wordt de interface EcuResetRequest aangeboden ([SWS_DM_01010]), die reset-aanvragen delegeert aan State Management (AUTOSAR_AP_EXP_SWArchitecture p. 162).
Sequentiediagram: doorlopende control flow van een UDS-request van de transportlaag via de diagnosemanager tot de toepassende applicatie. Bronnen: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130
Gebeurtenisbewaking, ontdendering en foutgeheugenbeheer
Voor het detecteren en kwalificeren van systeemfouten implementeert Diagnostic Management een hiërarchisch model van monitors en diagnose-events (SWS_Diagnostics p. 225). Een applicatie instantieert een Monitor-object ([SWS_DM_00548]) en meldt testresultaten continu via ReportMonitorAction() ([SWS_DM_00543]). De module ondersteunt daarbij zowel tellergebaseerde als tijdgebaseerde ontdenderingsalgoritmen ([SWS_DM_00549], [SWS_DM_00550]). Via de interface Event kunnen applicaties de actuele UDS-statusbytewaarde bepalen ([SWS_DM_00649]), de ontdenderingsstatus controleren ([SWS_DM_00654]) of callbacks voor statuswijzigingen registreren ([SWS_DM_00650]).
Om de port-footprint in complexe systemen gering te houden, stelt het platform gebundelde interfaces beschikbaar (AUTOSAR_AP_EXP_SWArchitecture p. 153): via MultipleMonitor ([SWS_DM_01695]), MultipleEvent ([SWS_DM_01705]) en MultipleCondition ([SWS_DM_01727]) kunnen meerdere bewakingskanalen via een gemeenschappelijke port-interface worden geadresseerd. Het vrijgavebeheer voor monitors verloopt via Condition-objecten ([SWS_DM_00712]), terwijl OperationCycle ([SWS_DM_00752]) en Indicator ([SWS_DM_00742], SWS_Diagnostics p. 633) bedrijfscycli sturen en waarschuwingslampverzoeken signaleren.
De geaggregeerde gebeurtenissen monden uit in het foutgeheugenbeheer, dat via DTCInformation wordt geëxponeerd ([SWS_DM_00664], AUTOSAR_AP_EXP_SWArchitecture p. 144). Deze interface maakt het uitlezen van opgeslagen vermeldingen ([SWS_DM_00669]), het selectief of globaal wissen van DTC's ([SWS_DM_00671]) en het activeren van de DTC-registratie ([SWS_DM_00674]) mogelijk. Treedt er een overschrijding van de capaciteit van het primaire geheugen op, dan wordt de applicatie via SetEventMemoryOverflowNotifier() op de hoogte gesteld ([SWS_DM_00918], [SWS_DM_00919]).
Toestands-/activiteitendiagram: verloop van monitoractie via ontdendering tot DTC-kwalificatie in het foutgeheugen. Bronnen: [SWS_DM_00543], [SWS_DM_00649], [SWS_DM_00664], SWS_Diagnostics p. 225
Uitgebreide diagnoseprotocollen: DoIP-integratie en SOVD-diensten
Voor Ethernet-gebaseerde voertuignetwerken integreert de module speciale DoIP-functies (Diagnostic communication over Internet Protocol conform ISO 13400-2) (AUTOSAR_AP_EXP_SWArchitecture p. 166, AUTOSAR_AP_EXP_SWArchitecture p. 167). Platformuitbreidingen melden de toestand van fysieke activeringslijnen via DoIPActivationLine::UpdateActivationLineState() ([SWS_DM_00834], AUTOSAR_AP_TPS_ManifestSpecification p. 338). Daarop voortbouwend kunnen voertuigaankondigingsberichten (Vehicle Announcement Messages) via DoIPTriggerVehicleAnnouncement worden getriggerd ([SWS_DM_00821], [SWS_DM_00822], AUTOSAR_AP_SWS_Diagnostics p. 108). De groeps- en entiteitsidentificatie wordt via DoIPGroupIdentification ([SWS_DM_00722]) en DoIPEntityIdentification ([SWS_DM_01364], [SWS_DM_01366]) dynamisch opgevraagd.
Sequentiediagram: interactie tussen applicatie, activeringslijn en het triggeren van DoIP-voertuigaankondigingen. Bronnen: [SWS_DM_00822], [SWS_DM_00834], AUTOSAR_AP_SWS_Diagnostics p. 108
Naast klassieke UDS-diensten introduceert release R25-11 native interfaces voor SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / ISO 13170) (AUTOSAR_AP_EXP_SWArchitecture p. 168). Gestructureerde diagnosegegevens worden gemodelleerd via DiagnosticSovdContentElementData ([SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170). Voor de manipulatie van complexe JSON-analoge payloads staan typeveilige STL-achtige klassen zoals DiagnosticSovdArrayContentElementDataView ([SWS_DM_02245], AUTOSAR_AP_EXP_SWArchitecture p. 172) en DiagnosticSovdRecordContentElementDataView ([SWS_DM_02289], AUTOSAR_AP_EXP_SWArchitecture p. 174) ter beschikking.
Voor uitgebreide SOVD-transacties en beveiligingen definieert de module gestandaardiseerde rollen: grote hoeveelheden gegevens (zoals traces of crashdumps) worden via SovdBulkData overgedragen ([SWS_DM_01847], [SWS_DM_01854], AUTOSAR_AP_TPS_ManifestSpecification p. 321). De toegangscontrole vindt plaats via token- en nabijheidscontroles via SovdAuthorization ([SWS_DM_01489]) en SovdProximityChallenge ([SWS_DM_01480], [SWS_DM_01493]), terwijl servicecontroles via SovdServiceValidation worden geautoriseerd ([SWS_DM_01823], [SWS_DM_01827]).
Gedrag in het foutgeval
Het foutbeheer van de module diag is gebaseerd op het AUTOSAR-standaardpatroon ara::core::Result<T, ErrorCode> en sluit stille fouttoestanden volledig uit. Fouten worden op basis van hun functionele oorzaken onderverdeeld in vijf gespecialiseerde foutdomeinen (ErrorDomain), die zowel foutcodes als corresponderende exception-klassen definiëren:
- Algemene diagnosefouten: de
DiagErrorDomain([SWS_DM_00520], [SWS_DM_00524]) en de bijbehorendeDiagException([SWS_DM_00516]) signaleren fundamentele platform- of configuratiefouten zoals ongeldige argumenten of niet-geïnitialiseerde instanties. - UDS Negative Response Codes (NRC): Specifieke protocollaire UDS-afwijzingen conform ISO 14229 worden via de
DiagUdsNrcErrorDomain([SWS_DM_00532], [SWS_DM_00536]) enDiagUdsNrcException([SWS_DM_00528]) afgebeeld. - Service-beschikbaarstellingsfouten: Mislukt de activering of deactivering van port-interfaces, dan grijpt de
DiagOfferErrorDomain([SWS_DM_00992], [SWS_DM_01003]) in met deDiagOfferException([SWS_DM_00986]). - Event- en monitor-meldingsfouten: Fouten tijdens de statusmelding van monitors worden door de
DiagReportingErrorDomain([SWS_DM_00999], [SWS_DM_01004]) enDiagReportingException([SWS_DM_00988]) aangegeven. - SOVD-protocolfouten: Fouten in REST-eindpunten, JSON-inhoud of de toegangscontrole worden via de
DiagSovdErrorDomain([SWS_DM_01812], [SWS_DM_01816]) enDiagSovdException([SWS_DM_01808]) gemeld.
Op transportlaagniveau worden overdrachtsafbrekingen, bufferoverstromingen of verbindingsverbrekingen door de callback NotifyMessageFailure() aan het Diagnostic Management gemeld ([SWS_DM_00310]). Dit stelt de module in staat om gealloceerde resources onmiddellijk vrij te geven en eventueel negatieve antwoordberichten aan de tester te initiëren.
Klassendiagram: foutdomeinarchitectuur en toewijzing van de gestandaardiseerde uitzonderings- en foutcodes in het Diagnostic Management. Bronnen: [SWS_DM_00520], [SWS_DM_00532], [SWS_DM_00992], [SWS_DM_00999], [SWS_DM_01812]
Verdere gedetailleerde bewijzen
De normatieve basis van de module diag steunt op drie centrale specificatiewerken van het AUTOSAR Adaptive Platform:
- Interface- en componentenarchitectuur: De systeeminterfaces, het daemonmodel en de scheiding van transport- en toepassingslaag zijn vastgelegd in
AUTOSAR_AP_EXP_SWArchitecture(AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168). - Specificatie van Diagnostic Management: De gedetailleerde API-signaturen, sequentieverlopen voor request-handling, levenscycli van transporthandlers en ontstoringsregels definieert
AUTOSAR_SWS_Diagnostics(AUTOSAR_SWS_Diagnostics p. 128, AUTOSAR_SWS_Diagnostics p. 130, SWS_Diagnostics p. 225). - Manifest- en metamodeldefinities: De declaratieve binding van port-interfaces, validatielogica en service-mappings aan softwarecomponenten wordt geregeld door
AUTOSAR_AP_TPS_ManifestSpecification(AUTOSAR_AP_TPS_ManifestSpecification p. 311, AUTOSAR_AP_TPS_ManifestSpecification p. 321, AUTOSAR_AP_TPS_ManifestSpecification p. 341).
Deze modulehandleiding is gegenereerd op basis van de AUTOSAR Adaptive-specificaties voor release R25-11. Alle normatieve voorschriften zijn afkomstig uit de gerefereerde SWS- en architectuurdocumenten.
function: 755 variable: 102 class: 79 type alias: 45 struct: 39 enumeration: 35
Themakaart
ara::diag
131Geen elementgegevens voor deze release
<DataElement-Namespace>
DiagnosticDataElementInterface class
<DataIdentifier-Namespace>
DiagnosticDataIdentifierInterface class
<ExtendedDataRecord-Namespace>
DiagnosticExtendedDataRecordInterface class
<RoutineInterface-Namespace>
DiagnosticRoutineInterface class
apext::diag::uds_transport
class represents an UDS message exchanged between DM generic core (UdsTransport ProtocolMgr) and a specific implementation of UdsTransportPr
Abstract Class, which a specific UDS Transport Protocol (plugin) shall subclass.
The UdsTransportProtocolMgr class manages the interaction between the Diagnostic Server instance(s) and various UDS Transport Protocols (e.g
UdsTransportProtocolPeriodicHandler class to support 0x2A service from ISO.
This is the type of ByteSpan.
using ByteSpan = ara::core::Span<ara::core::Byte>;This is the identification of channel on which to transmit.
using ChannelID = std::uint32_t;This is the unique_ptr for constant UdsMessages containing a custom deleter as provided by the generic/core DM part towards the UdsTransportLayer-Plugin.
using UdsMessageConstPtr = std::unique_ptr<const UdsMessage, std::function<void(const UdsMessage*)>>;This is the unique_ptr for UdsMessages containing a custom deleter as provided by the generic/ core DM part towards the UdsTransportLayer-Plugin.
using UdsMessagePtr = std::unique_ptr<UdsMessage, std::function<void(UdsMessage*)>>;UdsTransportProtocolHandler are flexible "plugins", which need an identification.
using UdsTransportProtocolHandlerID = std::uint8_t;ara::diag
Class to implement the Service Authentication interfaces to application.
CancellationHandler contains a shared state if the processing should be cancelled.
Interface for the application to inform the Diagnostic Server instance about the authentication states and the user roles that are currently
Definition of the ClientAuthenticationHandle which is returned to the application when an AuthenticationState is set by the application.
0x28 CommunicationControl interface
DiagnosticConditionInterface.
Conversation interface.
Represents the parameters for counter-based debouncing.
Specifies the Concurrency type of a DataIdentifier related port.
Handles data transfers initiated by RequestReadFile/-Directory with data pulled by AraDiag from the implementation.
Handles data transfers initiated by RequestReadFile/-Directory with data pushed by the implementation.
Encapsulates all data transfer reading variants.
Handles data transfers initiated by AddFile, ResumeFile or ReplaceFile ModeOfOperation handling per requested RequestWriteFile.
Encapsulates all data transfer writing variants.
Error domain for diagnostic errors.
erft van ara::core::ErrorDomain
Exception type thrown by Diag classes.
erft van ara::core::Exception
Definition of the DiagnosticServiceDynamicAccessList class, which is used by the application to build a DynamicAccessList.
Const iterator for a DiagnosticSovdArrayContentElementData.
Const view on a DiagnosticSovdContentElementData with Array type.
Iterator for a DiagnosticSovdArrayContentElementData.
View on a DiagnosticSovdContentElementData with Array type.
The DiagnosticSovdContentData declaration.
Diagnostic SOVD Abstract Content Data.
A DiagnosticSovdContentElementData with associated key.
Const iterator for a DiagnosticSovdRecordContentElementData.
Const view on a DiagnosticSovdContentElementData with Record type.
Iterator for a DiagnosticSovdRecordContentElementData.
View on a DiagnosticSovdContentElementData with Record type.
Error domain for diagnostic offer errors.
erft van ara::core::ErrorDomain
Exception type thrown by Diag classes.
erft van ara::core::Exception
Error domain for diagnostic reporting errors.
erft van ara::core::ErrorDomain
Exception type thrown by Diag classes.
erft van ara::core::Exception
Error domain for errors originating from SOVD.
erft van ara::core::ErrorDomain
Exception type for SOVD thrown by Diag classes.
erft van ara::core::Exception
Error domain for errors originating from several diagnostic classes.
erft van ara::core::ErrorDomain
Exception type thrown by Diag classes.
erft van ara::core::Exception
DiagnosticDoIPActivationLineInterface.
DoIPEntityIdentification class to obtain the EID if required.
DoIPGroupIdentificationInterface.
DiagnosticDoIPPowerModeInterface.
DiagnosticDoIPTriggerVehicleAnnouncement.
Download service interface.
Class to implement operations on DTC informations per configured DiagnosticMemory Destination.
Definition of the DynamicAccessListDiagServiceBuilder class, which is used by the application to build a DynamicAccessList.
Service EcuReset Request interface.
Class to implement operations on diagnostic Events.
Current event status byte, bit-encoded.
Definition of the ExternalAuthentication class, which is used by the application to receive an instance of the ClientAuthentication Class re
File Transfer service interface.
Generic DataIdentifier interface.
Generic Diagnostic SOVD Content interface.
Generic Diagnostic SOVD Operation interface .
Generic Routine interface.
Generic UDS interface.
Definition of HTTP-Redirect
DiagnosticIndicatorInterface provides functionality for handling indicators.
Metainfo interface.
Class to implement operations on diagnostic Monitor interface.
Class for multiple condition operations.
Class to implement operations on diagnostic Events with the multiple event interfaces.
Class to implement monitor operations on the multiple monitor interfaces.
DiagnosticOperationCycleInterface provides functionality for handling of operation cycles.
ReleaseHandler contains a shared state if the processing should be cancelled.
DiagnosticSecurityAccessInterface.
DiagnosticServiceValidationInterface.
Class to implement the SOVD Authorization interfaces in the application.
Generic SOVD Bulk Data interface.
Generic SOVD Configuration interface.
Specifies the Concurrency type of a SOVD Content related port.
Interface to handle the SOVD Operation Execution .
Class to implement the SOVD proximity_challenge interfaces in the application.
Holds the data returned by the SovdProximityChallenge::GetChallenge()
Class to implement manufacturer-/supplier-specific checks for SOVD in the application.
Class to implement the SovdSwUpdate interface.
Represents the parameters for time-based debouncing.
Class to implement the subfunction TransmitCertificate (29 04) of UDS service Authentication as interface to application
Upload service interface.
Obtain the reference to the single global DiagErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagDomain () noexcept;Obtain the reference to the single global DiagErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagOfferDomain () noexcept;Obtain the reference to the single global DiagReportingErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagReportingDomain () noexcept;Obtain the reference to the single global DiagSovdErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagSovdErrorDomain () noexcept;Obtain the reference to the single global DiagUdsNrcErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagUdsNrcDomain () noexcept;Create a new ErrorCode for DiagErrorDomain with the given support data type.
Overloads MakeErrorCode 5
constexpr ara::core::ErrorCode MakeErrorCode (DiagErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_00525constexpr ara::core::ErrorCode MakeErrorCode (DiagUdsNrcErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_00537constexpr ara::core::ErrorCode MakeErrorCode (DiagOfferErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_01005constexpr ara::core::ErrorCode MakeErrorCode (DiagReportingErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_01006constexpr ara::core::ErrorCode MakeErrorCode (DiagSovdErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_01817Type for current activity status.
enum class ActivityStatusType : std::uint8_t {...};Specifies the Concurrency types.
enum class ConcurrencyType : std::uint8_t {...};Type for Condition status.
enum class ConditionType : std::uint8_t {...};Represents the status of the service processing.
enum class ConfirmationStatusType : std::uint8_t {...};Type for ControlDTCStatus status as requested by UDS service 0x85 ControlDTCSetting.
enum class ControlDtcStatusType : std::uint8_t {...};Determines transfer exit signal type.
enum class DataTransferExitType : ara::core::Byte {...};Debounce status of event.
enum class DebouncingState : std::uint8_t {...};Specifies the types of internal errors that can occur upon calling Offer or ReportMonitorAction.
enum class DiagErrc : ara::core::ErrorDomain::CodeType {...};The type of the SOVD content data.
enum class DiagnosticSovdContentElementDataType : std::uint8_t {...};The primitive content element value types.
enum class DiagnosticSovdPrimitiveContentValueType : std::uint8_t {...};The DiagOfferErrc enumeration defines the error codes for the DiagOfferErrorDomain.
enum class DiagOfferErrc : ara::core::ErrorDomain::CodeType {...};The DiagReportingErrc enumeration defines the error codes for the DiagReportingErrorDomain.
enum class DiagReportingErrc : ara::core::ErrorDomain::CodeType {...};Specifies the types of errors that can occur in SOVD services.
enum class DiagSovdErrc : ara::core::ErrorDomain::CodeType {...};Specifies the types of internal errors that can occur upon calling Offer or ReportMonitorAction. The error codes described are defined in ISO 14229-1:2020 [1], Table A.1 "Negative Response Codes". In AUTOSAR, the three negative response code ranges, 0x00, 0x01-0x7F and 0x80-0xFF are respected, however, the value 0xFF is used to internally indicate, that there is no further processing and no response handling foreseen.
enum class DiagUdsNrcErrc : ara::core::ErrorDomain::CodeType {...};Represents the type of the DTC format according to ISO 14229-1 [30].
enum class DTCFormatType : std::uint8_t {...};Single event status bits.
enum class EventStatusBit : std::uint8_t {...};Represents the state of an indicator.
enum class IndicatorStatusType : std::uint8_t {...};Represents the status information reported to AAs why the monitor may be re-initalized.
enum class InitMonitorReason : std::uint32_t {...};Represents the status of the key compare.
enum class KeyCompareResultType : std::uint8_t {...};Represents the status information reported by AAs being relevant for error monitoring.
enum class MonitorAction : std::uint32_t {...};The standard operation execution capabilities .
enum class OperationExecutionCapability : std::uint8_t {...};The operation execution status .
enum class OperationExecutionStatus : std::uint8_t {...};PowerMode as defined in ISO 13400-2 [2].
enum class PowerModeType : std::uint8_t {...};This is the type of ProximityChallengeResultType.
enum class ProximityChallengeResultType : std::uint8_t {...};HTTP method used in the SOVD request.
enum class SovdRequestMethod : std::uint8_t {...};Phase type for a SOVD update.
enum class SovdUpdatePhase : std::uint8_t {...};Status type for a SOVD update .
enum class SovdUpdateStatus : std::uint8_t {...};The Terminate Operation reason .
enum class TerminateOperationExecutionReason : std::uint8_t {...};UDS DTC status bits according to ISO 14229-1.
enum class UdsDtcStatusBitType : std::uint8_t {...};Type to identify a condition.
using ConditionHandleType = std::uint8_t;Type to identify an event.
using EventHandleType = std::uint32_t;Register a notifier function which is called if a diagnostic event is changed.
using EventStatusByteNotifier = std::function<void(EventStatusByte)>;Notifier function which is called if the monitor needs to be re-initialized.
using InitMonitorNotifier = std::function<void(InitMonitorReason)>;Type to identify an monitor .
using MonitorHandleType = std::uint32_t;This is the type of ProximityChallengeValidationResultType.
using ProximityChallengeValidationResultType = ProximityChallenge ResultType;The type of the requested reset.
using ResetRequestType = std::uint8_t;Type for the active security level. .
using SecurityLevelType = std::uint8_t;Type for the active diagnostic session. .
using SessionControlType = std::uint8_t;kCustomReset
constexpr ResetRequestType kCustomReset = 3;Default session according to IS0 14229-1.
constexpr SessionControlType kDefaultSession = 0x01;Extended diagnostic session according to IS0 14229-1.
constexpr SessionControlType kExtendedDiagnosticSession = 0x03;HardReset.
constexpr ResetRequestType kHardReset = 1;KeyOffOnReset.
constexpr ResetRequestType kKeyOffOnReset = 2;Security level locked.
constexpr SecurityLevelType kLocked = 0x00;Programming session according to IS0 14229-1.
constexpr SessionControlType kProgrammingSession = 0x02;Safety system diagnostic session according to IS0 14229-1.
constexpr SessionControlType kSafetySystemDiagnosticSession = 0x04;SoftReset.
constexpr ResetRequestType kSoftReset = 0;Namespaces
- <DataElement-Namespace> 1 Klassen, 0 freie Funktionen
- <DataIdentifier-Namespace> 1 Klassen, 0 freie Funktionen
- <ExtendedDataRecord-Namespace> 1 Klassen, 0 freie Funktionen
- <RoutineInterface-Namespace> 1 Klassen, 0 freie Funktionen
- apext::diag::uds_transport 4 Klassen, 0 freie Funktionen
- ara::diag 78 Klassen, 10 freie Funktionen
UML-klassendiagram van de module
Abgerundete Rahmen = Namespaces; hohle Dreieckspfeile = Vererbung (zeigt zur Basisklasse); graue Boxen = modulfremde bzw. externe Basisklassen. Klicken öffnet die Klassenseite.
gemini-3.8-flash-low· 2026-10-13 · Duits origineel