Modul ara::diag — Diagnostics
Modul-GuideKI-GENERIERT
Stellt standardisierte Diagnosedienste, UDS- und SOVD-Protokolle sowie zentrale Fehlerspeicherverwaltung bereit.
Stellt standardisierte Diagnosedienste, UDS- und SOVD-Protokolle sowie zentrale Fehlerspeicherverwaltung bereit.
Das funktionale Cluster Diagnostic Management stellt in der AUTOSAR Adaptive Platform die zentrale Infrastruktur für die klassische UDS- und moderne SOVD-Fahrzeugdiagnose bereit (AUTOSAR_AP_EXP_SWArchitecture S. 150). Als Plattform-Daemon terminiert es Transportschichten wie DoIP, steuert Protokoll-Handler und leitet Diagnoseanforderungen über typsichere Callback-Schnittstellen an Adaptive Applications weiter ([SWS_DM_00311]). Zugleich übernimmt das Modul die Fehlerüberwachung, Zeit- und Zählerentprellung sowie die Verwaltung des Fehlerspeichers. Applikationen schalten Service-Funktionen über ein deklaratives Offer-Modell frei, wodurch Anwendungslogik und Protokollabwicklung sauber voneinander getrennt bleiben.
Das funktionale Cluster Diagnostic Management (ara::diag) stellt in der AUTOSAR Adaptive Platform die zentrale, daemon-basierte Infrastruktur für die Abwicklung fahrzeuggerechter Diagnosekommunikation bereit (AUTOSAR_AP_EXP_SWArchitecture S. 150). Es entkoppelt transportspezifische Protokoll-Handler (wie DoIP oder CAN-TP) vom eigentlichen Diagnosekern (UdsTransportProtocolMgr) und ermöglicht so eine einheitliche Terminierung und Weiterleitung von Diagnoseanforderungen (AUTOSAR_AP_EXP_SWArchitecture S. 164).
Kontextdiagramm: Einbettung des Diagnostic-Management-Daemons zwischen Transport-Handlern, Adaptive Applications und externen Testern. Quellen: AUTOSAR_AP_EXP_SWArchitecture S. 150, AUTOSAR_AP_EXP_SWArchitecture S. 164, AUTOSAR_AP_EXP_SWArchitecture S. 168
Zur Service-Abwicklung implementiert das Modul ein deklaratives Bereitstellungsmodell: Der Diagnose-Daemon realisiert die Port-Interfaces, während Adaptive Applications Service-Callbacks für DataIdentifier, Routinen oder blockbasierte Transfers registrieren und ihre Verfügbarkeit über Offer() bzw. StopOffer() steuern ([SWS_DM_00557], AUTOSAR_AP_EXP_SWArchitecture S. 156). Eingehende Nachrichten werden über zweistufige Indikations- und Übergabemechanismen (IndicateMessage und HandleMessage) fehlersicher verarbeitet ([SWS_DM_00309], [SWS_DM_00311]).
Sequenzdiagramm: Durchgängiger Kontrollfluss eines UDS-Requests von der Transportschicht über den Diagnose-Manager bis zur anwendenden Applikation. Quellen: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics S. 130
Neben klassischen UDS-Funktionen verwaltet das Cluster diagnostische Monitore, führt konfigurierte Entprellungen durch und persistiert qualifizierte Fehler im primären Fehlerspeicher (DTCInformation) ([SWS_DM_00664], SWS_Diagnostics S. 225). Erweiterte Standards wie ISO 13400-2 (DoIP) und ASAM SOVD (Service-Oriented Vehicle Diagnostics) werden über spezialisierte Schnittstellen für Aktivierungsleitungen, Authentifizierungen und hierarchische JSON-Nutzdaten nahtlos in die Plattform integriert ([SWS_DM_00834], [SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture S. 170).
Architektonische Rolle und Systemgrenzen des Diagnostic Managements
Das funktionale Cluster Diagnostic Management (ara::diag) bildet in der AUTOSAR Adaptive Platform (Release R25-11) die zentrale Schaltstelle für die fahrzeuginterne und externe Fahrzeugdiagnose (AUTOSAR_AP_EXP_SWArchitecture S. 150). Architektonisch ist das Modul als daemon-basierter Hintergrunddienst («aapFunctionalCluster» Diagnostic Management daemon-based) ausgelegt. Es terminiert physische sowie logische Diagnoseprotokolle, verwaltet den globalen Diagnosekontext und stellt die Middleware-Infrastruktur bereit, über die einzelne Adaptive Applications diagnosebezogene Daten und Routinen bereitstellen können (AUTOSAR_AP_EXP_SWArchitecture S. 156).
Die Schnittstellenlandschaft teilt sich primär in zwei Kategorien: modellierte Port-Interfaces, die über das AUTOSAR-Manifest konfiguriert und an Anwendungsprozesse gebunden werden, sowie native C++-Laufzeitschnittstellen (AUTOSAR_AP_EXP_SWArchitecture S. 150). Zu den nativen Schnittstellen zählt insbesondere die Klasse Conversation, über die Applikationen aktuelle Sitzungszustände abfragen ([SWS_DM_00696]), Sicherheitsstufen ermitteln ([SWS_DM_00698]) oder aktive Diagnosekonversationen inspizieren können ([SWS_DM_00783]). Interpretation: Die strikte Trennung zwischen dem zentralen Diagnose-Daemon und den anwendenden Prozessen dürfte gewählt worden sein, um deterministische Antwortzeiten gegenüber externen Testern auch bei Prozessneustarts einzelner Applikationen zu garantieren. Frage Q-2e2ea8eb9d415fed (offen)
Kontextdiagramm: Einbettung des Diagnostic-Management-Daemons zwischen Transport-Handlern, Adaptive Applications und externen Testern. Quellen: AUTOSAR_AP_EXP_SWArchitecture S. 150, AUTOSAR_AP_EXP_SWArchitecture S. 164, AUTOSAR_AP_EXP_SWArchitecture S. 168
Transportschichtanbindung und Lebenszyklussteuerung der Protokoll-Handler
Um unabhängig von spezifischen Netzwerktechnologien (wie Ethernet/DoIP oder CAN/ISO-TP) zu agieren, entkoppelt das Diagnostic Management den Protokollkern über standardisierte Transportschnittstellen (AUTOSAR_AP_EXP_SWArchitecture S. 164). Der generische Kern implementiert das Interface UdsTransportProtocolMgr, während transportspezifische Adapter als UdsTransportProtocolHandler angebunden werden (AUTOSAR_AP_EXP_SWArchitecture S. 165). Jeder Handler wird über eine eindeutige Kennung identifiziert, die über GetHandlerID() abgefragt werden kann ([SWS_DM_00325]).
Die Lebenszyklussteuerung eines Transport-Handlers gliedert sich in deterministische Betriebsphasen (AUTOSAR_SWS_Diagnostics S. 128): Während des Hochlaufs initialisiert das Diagnostic Management den Handler über Initialize() ([SWS_DM_00319]) und aktiviert anschließend die Nachrichtenverarbeitung mittels Start() ([SWS_DM_00322]). Bei der kontrollierten Beendigung fordert der Manager den Handler über Stop() auf, offene Verbindungen zu schließen ([SWS_DM_00323]), woraufhin der Handler den Abschluss über HandlerStopped() quittiert ([SWS_DM_00314]).
Für langlebige Diagnosesitzungen spezifiziert AUTOSAR zudem einen Wiederherstellungsmechanismus über Prozesslebenszyklen hinweg (AUTOSAR_SWS_Diagnostics S. 134). Kann ein zuvor persistierter Kanal nach einem Neustart des Diagnostic-Managers reetabliert werden, meldet der Transport-Handler dies via NotifyReestablishment() ([SWS_DM_00326]). Der Manager synchronisiert den Zustand intern und bestätigt dies mit dem Aufruf von ChannelReestablished() ([SWS_DM_00313]).
Sequenzdiagramm: Lebenszyklussteuerung eines UDS-Transport-Handlers durch den generischen Diagnose-Manager. Quellen: [SWS_DM_00314], [SWS_DM_00319], [SWS_DM_00322], [SWS_DM_00323], AUTOSAR_SWS_Diagnostics S. 128
UDS-Serviceabwicklung und anwendungsspezifisches Request-Handling
Eingehende UDS-Nachrichten werden nach der Protokollvalidierung schrittweise verarbeitet (AUTOSAR_SWS_Diagnostics S. 130). Zunächst kündigt der Transport-Handler eine beginnende Nachricht über IndicateMessage() beim Manager an, um Ressourcen und Puffer zu allokieren ([SWS_DM_00309]). Die Nachricht wird als UdsMessage gekapselt, welche Quelladresse ([SWS_DM_00297]), Zieladresse ([SWS_DM_00298]) und Adressierungstyp ([SWS_DM_00299]) bereitstellt. Nach vollständigem Empfang übergibt der Handler das Datenobjekt via HandleMessage() an das Diagnostic Management ([SWS_DM_00311]), wobei kanalspezifische Metainformationen mittels AddMetaInfo() ergänzt werden ([SWS_DM_00302]).
In Release R25-11 folgt die Interaktion zwischen Plattform-Daemon und Applikation einem invertierten Service-Bereitstellungsmodell (AUTOSAR_AP_EXP_SWArchitecture S. 156): Der Plattform-Daemon realisiert die Service-Ports, während Adaptive Applications Callback-Methoden implementieren und ihre Bereitschaft zur Weiterleitung explizit über Offer() aktivieren ([SWS_DM_00557]) oder über StopOffer() suspendieren ([SWS_DM_00558]). Dies gilt gleichermaßen für generische Routinen (GenericRoutine [SWS_DM_00552]), typisierte Routinen (RoutineInterface [SWS_DM_00589] mit Start [SWS_DM_00591]), Datenbezeichner (GenericDataIdentifier [SWS_DM_00634] mit Read [SWS_DM_00636] und Write [SWS_DM_00637]) sowie generische UDS-Dienste (GenericUDSService [SWS_DM_00616] mit HandleMessage [SWS_DM_00618]).
Länger andauernde Diagnosetransaktionen (wie Blocktransfers via UploadService [SWS_DM_00797], DownloadService [SWS_DM_00787] oder FileTransferService [SWS_DM_01325] gemäß AUTOSAR_AP_EXP_SWArchitecture S. 163) werden asynchron über ara::core::Future abgewickelt. Zur Vermeidung von Ressourcenblockaden erhalten anwendungsspezifische Handler eine Instanz von CancellationHandler (AUTOSAR_AP_EXP_SWArchitecture S. 152). Über IsCanceled() kann die Anwendung einen Abbruch abfragen ([SWS_DM_00614]) oder über SetNotifier() eine Benachrichtigungsfunktion registrieren ([SWS_DM_00615]). Für koordinierte Neustarts wird das Interface EcuResetRequest bereitgestellt ([SWS_DM_01010]), welches Reset-Anfragen an das State Management delegiert (AUTOSAR_AP_EXP_SWArchitecture S. 162).
Sequenzdiagramm: Durchgängiger Kontrollfluss eines UDS-Requests von der Transportschicht über den Diagnose-Manager bis zur anwendenden Applikation. Quellen: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics S. 130
Ereignisüberwachung, Entprellung und Fehlerspeicherverwaltung
Zur Erfassung und Qualifizierung von Systemfehlern implementiert das Diagnostic Management ein hierarchisches Modell aus Monitoren und Diagnose-Events (SWS_Diagnostics S. 225). Eine Anwendung instanziiert ein Monitor-Objekt ([SWS_DM_00548]) und meldet Testergebnisse kontinuierlich über ReportMonitorAction() ([SWS_DM_00543]). Das Modul unterstützt dabei sowohl zählerbasierte als auch zeitbasierte Entprellalgorithmen ([SWS_DM_00549], [SWS_DM_00550]). Über die Schnittstelle Event können Anwendungen den aktuellen UDS-Statusbyte-Wert ermitteln ([SWS_DM_00649]), den Entprellungsstatus prüfen ([SWS_DM_00654]) oder Statusänderungs-Callbacks registrieren ([SWS_DM_00650]).
Um den Port-Footprint in komplexen Systemen gering zu halten, stellt die Plattform gebündelte Schnittstellen bereit (AUTOSAR_AP_EXP_SWArchitecture S. 153): Über MultipleMonitor ([SWS_DM_01695]), MultipleEvent ([SWS_DM_01705]) und MultipleCondition ([SWS_DM_01727]) können mehrere Überwachungskanäle über ein gemeinsames Port-Interface adressiert werden. Das Freigabemanagement für Monitore erfolgt über Condition-Objekte ([SWS_DM_00712]), während OperationCycle ([SWS_DM_00752]) und Indicator ([SWS_DM_00742], SWS_Diagnostics S. 633) Betriebszyklen steuern und Warnlampenanforderungen signalisieren.
Die aggregierten Ereignisse münden in die Fehlerspeicherverwaltung, die über DTCInformation exponiert wird ([SWS_DM_00664], AUTOSAR_AP_EXP_SWArchitecture S. 144). Diese Schnittstelle gestattet das Auslesen gespeicherter Einträge ([SWS_DM_00669]), das selektive oder globale Löschen von DTCs ([SWS_DM_00671]) und das Aktivieren der DTC-Aufzeichnung ([SWS_DM_00674]). Tritt eine Kapazitätsüberschreitung des primären Speichers auf, wird die Applikation über SetEventMemoryOverflowNotifier() benachrichtigt ([SWS_DM_00918], [SWS_DM_00919]).
Zustands-/Aktivitätsdiagramm: Ablauf von der Monitor-Aktion über die Entprellung bis zur DTC-Qualifizierung im Fehlerspeicher. Quellen: [SWS_DM_00543], [SWS_DM_00649], [SWS_DM_00664], SWS_Diagnostics S. 225
Erweiterte Diagnoseprotokolle: DoIP-Integration und SOVD-Dienste
Für Ethernet-basierte Fahrzeugnetzwerke integriert das Modul dedizierte DoIP-Funktionen (Diagnostic communication over Internet Protocol gemäß ISO 13400-2) (AUTOSAR_AP_EXP_SWArchitecture S. 166, AUTOSAR_AP_EXP_SWArchitecture S. 167). Plattform-Erweiterungen melden den Zustand physikalischer Aktivierungsleitungen über DoIPActivationLine::UpdateActivationLineState() ([SWS_DM_00834], AUTOSAR_AP_TPS_ManifestSpecification S. 338). Darauf aufbauend können Fahrzeugankündigungsnachrichten (Vehicle Announcement Messages) über DoIPTriggerVehicleAnnouncement ausgelöst werden ([SWS_DM_00821], [SWS_DM_00822], AUTOSAR_AP_SWS_Diagnostics S. 108). Die Gruppen- und Entitätsidentifikation wird über DoIPGroupIdentification ([SWS_DM_00722]) und DoIPEntityIdentification ([SWS_DM_01364], [SWS_DM_01366]) dynamisch abgefragt.
Sequenzdiagramm: Interaktion zwischen Applikation, Aktivierungsleitung und Auslösen von DoIP-Fahrzeugankündigungen. Quellen: [SWS_DM_00822], [SWS_DM_00834], AUTOSAR_AP_SWS_Diagnostics S. 108
Zusätzlich zu klassischen UDS-Diensten etabliert Release R25-11 native Schnittstellen für SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / ISO 13170) (AUTOSAR_AP_EXP_SWArchitecture S. 168). Strukturierte Diagnosedaten werden über DiagnosticSovdContentElementData modelliert ([SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture S. 170). Zur Manipulation komplexer JSON-analoger Payloads stehen typsichere STL-ähnliche Klassen wie DiagnosticSovdArrayContentElementDataView ([SWS_DM_02245], AUTOSAR_AP_EXP_SWArchitecture S. 172) und DiagnosticSovdRecordContentElementDataView ([SWS_DM_02289], AUTOSAR_AP_EXP_SWArchitecture S. 174) bereit.
Für erweiterte SOVD-Transaktionen und Absicherungen definiert das Modul standardisierte Rollen: Große Datenmengen (wie Traces oder Crash-Dumps) werden über SovdBulkData transferiert ([SWS_DM_01847], [SWS_DM_01854], AUTOSAR_AP_TPS_ManifestSpecification S. 321). Die Zugriffssteuerung erfolgt über Token- und Näherungsprüfungen via SovdAuthorization ([SWS_DM_01489]) und SovdProximityChallenge ([SWS_DM_01480], [SWS_DM_01493]), während Service-Prüfungen über SovdServiceValidation autorisiert werden ([SWS_DM_01823], [SWS_DM_01827]).
Verhalten im Fehlerfall
Das Fehlermanagement des Moduls diag basiert auf dem AUTOSAR-Standardmuster ara::core::Result<T, ErrorCode> und schließt stille Fehlerzustände vollständig aus. Fehler werden nach ihren funktionalen Ursachen in fünf spezialisierte Fehlerdomänen (ErrorDomain) unterteilt, welche sowohl Fehlercodes als auch korrespondierende Exception-Klassen definieren:
- Allgemeine Diagnosefehler: Die
DiagErrorDomain([SWS_DM_00520], [SWS_DM_00524]) und die zugehörigeDiagException([SWS_DM_00516]) signalisieren fundamentale Plattform- oder Konfigurationsfehler wie ungültige Argumente oder uninitialisierte Instanzen. - UDS Negative Response Codes (NRC): Spezifische protokollarische UDS-Rückweisungen gemäß ISO 14229 werden über die
DiagUdsNrcErrorDomain([SWS_DM_00532], [SWS_DM_00536]) undDiagUdsNrcException([SWS_DM_00528]) abgebildet. - Service-Bereitstellungsfehler: Scheitert die Aktivierung oder Deaktivierung von Port-Schnittstellen, greift die
DiagOfferErrorDomain([SWS_DM_00992], [SWS_DM_01003]) mit derDiagOfferException([SWS_DM_00986]). - Event- und Monitor-Meldefehler: Fehler während der Statusmeldung von Monitoren werden durch die
DiagReportingErrorDomain([SWS_DM_00999], [SWS_DM_01004]) undDiagReportingException([SWS_DM_00988]) angezeigt. - SOVD-Protokollfehler: Fehler in REST-Endpunkten, JSON-Inhalten oder der Zugriffskontrolle werden über die
DiagSovdErrorDomain([SWS_DM_01812], [SWS_DM_01816]) undDiagSovdException([SWS_DM_01808]) gemeldet.
Auf Transportschichtebene werden Übertragungsabbrüche, Pufferüberläufe oder Verbindungsabbrüche durch den Callback NotifyMessageFailure() an das Diagnostic Management gemeldet ([SWS_DM_00310]). Dies ermöglicht es dem Modul, allokierte Ressourcen unverzüglich freizugeben und gegebenenfalls negative Antwortnachrichten an den Tester zu veranlassen.
Klassendiagramm: Fehlerdomänen-Architektur und Zuordnung der standardisierten Ausnahme- und Fehlercodes im Diagnostic Management. Quellen: [SWS_DM_00520], [SWS_DM_00532], [SWS_DM_00992], [SWS_DM_00999], [SWS_DM_01812]
Weiterführende Detailbelege
Die normative Basis des Moduls diag stützt sich auf drei zentrale Spezifikationswerke der AUTOSAR Adaptive Platform:
- Schnittstellen- und Komponentenarchitektur: Die Systemschnittstellen, das Daemon-Modell sowie die Trennung von Transport- und Anwendungsschicht sind in
AUTOSAR_AP_EXP_SWArchitectureniedergelegt (AUTOSAR_AP_EXP_SWArchitecture S. 150, AUTOSAR_AP_EXP_SWArchitecture S. 164, AUTOSAR_AP_EXP_SWArchitecture S. 168). - Spezifikation des Diagnostic Managements: Die detaillierten API-Signaturen, Sequenzabläufe für Request-Handling, Transporthandler-Lebenszyklen und Entprellungsregeln definiert
AUTOSAR_SWS_Diagnostics(AUTOSAR_SWS_Diagnostics S. 128, AUTOSAR_SWS_Diagnostics S. 130, SWS_Diagnostics S. 225). - Manifest- und Metamodell-Definitionen: Die deklarative Bindung von Port-Interfaces, Validierungslogiken und Service-Mappings an Software-Komponenten regelt
AUTOSAR_AP_TPS_ManifestSpecification(AUTOSAR_AP_TPS_ManifestSpecification S. 311, AUTOSAR_AP_TPS_ManifestSpecification S. 321, AUTOSAR_AP_TPS_ManifestSpecification S. 341).
Dieser Modul-Leitfaden wurde auf Basis der AUTOSAR-Adaptive-Spezifikationen für Release R25-11 generiert. Alle normativen Vorgaben entstammen den referenzierten SWS- und Architektur-Dokumenten.
function: 755 variable: 102 class: 79 type alias: 45 struct: 39 enumeration: 35
Themenkarte
ara::diag
131Für dieses Release liegen keine Elementdaten vor
<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.
erbt von ara::core::ErrorDomain
Exception type thrown by Diag classes.
erbt von 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.
erbt von ara::core::ErrorDomain
Exception type thrown by Diag classes.
erbt von ara::core::Exception
Error domain for diagnostic reporting errors.
erbt von ara::core::ErrorDomain
Exception type thrown by Diag classes.
erbt von ara::core::Exception
Error domain for errors originating from SOVD.
erbt von ara::core::ErrorDomain
Exception type for SOVD thrown by Diag classes.
erbt von ara::core::Exception
Error domain for errors originating from several diagnostic classes.
erbt von ara::core::ErrorDomain
Exception type thrown by Diag classes.
erbt von 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.
Überladungen 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-Klassendiagramm des Moduls
Abgerundete Rahmen = Namespaces; hohle Dreieckspfeile = Vererbung (zeigt zur Basisklasse); graue Boxen = modulfremde bzw. externe Basisklassen. Klicken öffnet die Klassenseite.
gemini-3.8-flash-medium· 2026-10-13