module ara::diag — Diagnostics

In the AUTOSAR Adaptive Platform, the functional cluster Diagnostic Management provides the central infrastructure for classic UDS and modern SOVD vehicle diagnostics (AUTOSAR_AP_EXP_SWArchitecture p. 150). As a platform daemon, it terminates transport layers such as DoIP, controls protocol handlers, and forwards diagnostic requests via type-safe callback interfaces to Adaptive Applications ([SWS_DM_00311]). At the same time, the module handles error monitoring, time- and counter-based debouncing, and fault memory management. Applications enable service functions via a declarative offer model, keeping application logic and protocol handling cleanly separated.

more ›

The functional cluster Diagnostic Management (ara::diag) in the AUTOSAR Adaptive Platform provides the central, daemon-based infrastructure for handling vehicle-compatible diagnostic communication (AUTOSAR_AP_EXP_SWArchitecture p. 150). It decouples transport-specific protocol handlers (such as DoIP or CAN-TP) from the actual diagnostic core (UdsTransportProtocolMgr), thereby enabling uniform termination and forwarding of diagnostic requests (AUTOSAR_AP_EXP_SWArchitecture p. 164).

Context diagram: Embedding of the Diagnostic Management daemon between transport handlers, Adaptive Applications, and external testers. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168

For service processing, the module implements a declarative deployment model: the diagnostic daemon implements the port interfaces, while Adaptive Applications register service callbacks for DataIdentifiers, routines, or block-based transfers and control their availability via Offer() and StopOffer(), respectively ([SWS_DM_00557], AUTOSAR_AP_EXP_SWArchitecture p. 156). Incoming messages are processed in a fail-safe manner via two-stage indication and handover mechanisms (IndicateMessage and HandleMessage) ([SWS_DM_00309], [SWS_DM_00311]).

Sequence diagram: End-to-end control flow of a UDS request from the transport layer via the Diagnostic Manager to the applying application. Sources: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130

In addition to classic UDS functions, the cluster manages diagnostic monitors, performs configured debouncings, and persists qualified faults in the primary fault memory (DTCInformation) ([SWS_DM_00664], SWS_Diagnostics p. 225). Extended standards such as ISO 13400-2 (DoIP) and ASAM SOVD (Service-Oriented Vehicle Diagnostics) are seamlessly integrated into the platform via specialized interfaces for activation lines, authentications, and hierarchical JSON payloads ([SWS_DM_00834], [SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170).

more ›

Architectural Role and System Boundaries of Diagnostic Management

The functional cluster Diagnostic Management (ara::diag) forms the central control center for in-vehicle and external vehicle diagnostics in the AUTOSAR Adaptive Platform (Release R25-11) (AUTOSAR_AP_EXP_SWArchitecture p. 150). Architecturally, the module is designed as a daemon-based background service («aapFunctionalCluster» Diagnostic Management daemon-based). It terminates physical as well as logical diagnostic protocols, manages the global diagnostic context, and provides the middleware infrastructure through which individual Adaptive Applications can provide diagnostic-related data and routines (AUTOSAR_AP_EXP_SWArchitecture p. 156).

The interface landscape is primarily divided into two categories: modeled port interfaces, which are configured via the AUTOSAR manifest and bound to application processes, and native C++ runtime interfaces (AUTOSAR_AP_EXP_SWArchitecture p. 150). The native interfaces specifically include the class Conversation, through which applications can query current session states ([SWS_DM_00696]), determine security levels ([SWS_DM_00698]), or inspect active diagnostic conversations ([SWS_DM_00783]). Interpretation: The strict separation between the central diagnostic daemon and the consuming processes was presumably chosen to guarantee deterministic response times towards external testers even during process restarts of individual applications. Question Q-2e2ea8eb9d415fed (open)

Context diagram: Embedding of the Diagnostic Management daemon between transport handlers, Adaptive Applications, and external testers. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168

Transport Layer Connection and Lifecycle Control of Protocol Handlers

To operate independently of specific network technologies (such as Ethernet/DoIP or CAN/ISO-TP), Diagnostic Management decouples the protocol core via standardized transport interfaces (AUTOSAR_AP_EXP_SWArchitecture p. 164). The generic core implements the interface UdsTransportProtocolMgr, while transport-specific adapters are connected as UdsTransportProtocolHandler (AUTOSAR_AP_EXP_SWArchitecture p. 165). Each handler is identified via a unique identifier that can be queried via GetHandlerID() ([SWS_DM_00325]).

The lifecycle control of a transport handler is structured into deterministic operating phases (AUTOSAR_SWS_Diagnostics p. 128): During startup, Diagnostic Management initializes the handler via Initialize() ([SWS_DM_00319]) and subsequently activates message processing via Start() ([SWS_DM_00322]). During controlled shutdown, the manager requests the handler via Stop() to close open connections ([SWS_DM_00323]), whereupon the handler acknowledges completion via HandlerStopped() ([SWS_DM_00314]).

For long-lived diagnostic sessions, AUTOSAR also specifies a recovery mechanism across process lifecycles (AUTOSAR_SWS_Diagnostics p. 134). If a previously persisted channel can be re-established after a restart of the diagnostic manager, the transport handler reports this via NotifyReestablishment() ([SWS_DM_00326]). The manager synchronizes the state internally and confirms this by calling ChannelReestablished() ([SWS_DM_00313]).

Sequence diagram: Lifecycle control of a UDS transport handler by the generic diagnostic manager. Sources: [SWS_DM_00314], [SWS_DM_00319], [SWS_DM_00322], [SWS_DM_00323], AUTOSAR_SWS_Diagnostics p. 128

UDS Service Processing and Application-Specific Request Handling

Incoming UDS messages are processed step-by-step after protocol validation (AUTOSAR_SWS_Diagnostics p. 130). First, the transport handler announces an incoming message to the manager via IndicateMessage() in order to allocate resources and buffers ([SWS_DM_00309]). The message is encapsulated as UdsMessage, which provides the source address ([SWS_DM_00297]), target address ([SWS_DM_00298]), and addressing type ([SWS_DM_00299]). After complete reception, the handler hands over the data object via HandleMessage() to Diagnostic Management ([SWS_DM_00311]), where channel-specific meta-information is supplemented via AddMetaInfo() ([SWS_DM_00302]).

In Release R25-11, the interaction between the platform daemon and the application follows an inverted service provision model (AUTOSAR_AP_EXP_SWArchitecture p. 156): The platform daemon implements the service ports, while Adaptive Applications implement callback methods and explicitly activate their readiness for forwarding via Offer() ([SWS_DM_00557]) or suspend it via StopOffer() ([SWS_DM_00558]). This applies equally to generic routines (GenericRoutine [SWS_DM_00552]), typed routines (RoutineInterface [SWS_DM_00589] with Start [SWS_DM_00591]), data identifiers (GenericDataIdentifier [SWS_DM_00634] with Read [SWS_DM_00636] and Write [SWS_DM_00637]), and generic UDS services (GenericUDSService [SWS_DM_00616] with HandleMessage [SWS_DM_00618]).

Longer-running diagnostic transactions (such as block transfers via UploadService [SWS_DM_00797], DownloadService [SWS_DM_00787], or FileTransferService [SWS_DM_01325] according to AUTOSAR_AP_EXP_SWArchitecture p. 163) are processed asynchronously via ara::core::Future. To avoid resource blockages, application-specific handlers receive an instance of CancellationHandler (AUTOSAR_AP_EXP_SWArchitecture p. 152). Via IsCanceled(), the application can query for a cancellation ([SWS_DM_00614]) or register a notification function via SetNotifier() ([SWS_DM_00615]). For coordinated restarts, the interface EcuResetRequest is provided ([SWS_DM_01010]), which delegates reset requests to State Management (AUTOSAR_AP_EXP_SWArchitecture p. 162).

Sequence diagram: End-to-end control flow of a UDS request from the transport layer via the Diagnostic Manager to the applying application. Sources: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130

Event Monitoring, Debouncing, and Fault Memory Management

For detecting and qualifying system faults, Diagnostic Management implements a hierarchical model of monitors and diagnostic events (SWS_Diagnostics p. 225). An application instantiates an Monitor object ([SWS_DM_00548]) and continuously reports test results via ReportMonitorAction() ([SWS_DM_00543]). The module supports both counter-based and time-based debouncing algorithms ([SWS_DM_00549], [SWS_DM_00550]). Via the interface Event, applications can determine the current UDS status byte value ([SWS_DM_00649]), check the debouncing status ([SWS_DM_00654]), or register status change callbacks ([SWS_DM_00650]).

To keep the port footprint low in complex systems, the platform provides bundled interfaces (AUTOSAR_AP_EXP_SWArchitecture p. 153): Via MultipleMonitor ([SWS_DM_01695]), MultipleEvent ([SWS_DM_01705]), and MultipleCondition ([SWS_DM_01727]), multiple monitoring channels can be addressed via a shared port interface. Enable management for monitors is performed via Condition objects ([SWS_DM_00712]), while OperationCycle ([SWS_DM_00752]) and Indicator ([SWS_DM_00742], SWS_Diagnostics p. 633) control operation cycles and signal indicator lamp requests.

The aggregated events lead into the fault memory management, which is exposed via DTCInformation ([SWS_DM_00664], AUTOSAR_AP_EXP_SWArchitecture p. 144). This interface allows reading out stored entries ([SWS_DM_00669]), selective or global clearing of DTCs ([SWS_DM_00671]), and activating DTC recording ([SWS_DM_00674]). If a capacity overflow of the primary memory occurs, the application is notified via SetEventMemoryOverflowNotifier() ([SWS_DM_00918], [SWS_DM_00919]).

State/activity diagram: Sequence from monitor action through debouncing to DTC qualification in fault memory. Sources: [SWS_DM_00543], [SWS_DM_00649], [SWS_DM_00664], SWS_Diagnostics p. 225

Extended Diagnostic Protocols: DoIP Integration and SOVD Services

For Ethernet-based vehicle networks, the module integrates dedicated DoIP functions (Diagnostic communication over Internet Protocol according to ISO 13400-2) (AUTOSAR_AP_EXP_SWArchitecture p. 166, AUTOSAR_AP_EXP_SWArchitecture p. 167). Platform extensions report the state of physical activation lines via DoIPActivationLine::UpdateActivationLineState() ([SWS_DM_00834], AUTOSAR_AP_TPS_ManifestSpecification p. 338). Based on this, vehicle announcement messages (Vehicle Announcement Messages) can be triggered via DoIPTriggerVehicleAnnouncement ([SWS_DM_00821], [SWS_DM_00822], AUTOSAR_AP_SWS_Diagnostics p. 108). Group and entity identification is queried dynamically via DoIPGroupIdentification ([SWS_DM_00722]) and DoIPEntityIdentification ([SWS_DM_01364], [SWS_DM_01366]).

Sequence diagram: Interaction between application, activation line, and triggering of DoIP vehicle announcements. Sources: [SWS_DM_00822], [SWS_DM_00834], AUTOSAR_AP_SWS_Diagnostics p. 108

In addition to classic UDS services, Release R25-11 establishes native interfaces for SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / ISO 13170) (AUTOSAR_AP_EXP_SWArchitecture p. 168). Structured diagnostic data is modeled via DiagnosticSovdContentElementData ([SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170). For manipulating complex JSON-analogous payloads, type-safe STL-like classes such as DiagnosticSovdArrayContentElementDataView ([SWS_DM_02245], AUTOSAR_AP_EXP_SWArchitecture p. 172) and DiagnosticSovdRecordContentElementDataView ([SWS_DM_02289], AUTOSAR_AP_EXP_SWArchitecture p. 174) are available.

For extended SOVD transactions and security measures, the module defines standardized roles: large volumes of data (such as traces or crash dumps) are transferred via SovdBulkData ([SWS_DM_01847], [SWS_DM_01854], AUTOSAR_AP_TPS_ManifestSpecification p. 321). Access control is performed via token and proximity checks via SovdAuthorization ([SWS_DM_01489]) and SovdProximityChallenge ([SWS_DM_01480], [SWS_DM_01493]), while service checks are authorized via SovdServiceValidation ([SWS_DM_01823], [SWS_DM_01827]).

Behavior in the event of an error

The error management of module diag is based on the AUTOSAR standard pattern ara::core::Result<T, ErrorCode> and completely excludes silent failure states. Errors are categorized according to their functional causes into five specialized error domains (ErrorDomain), which define both error codes and corresponding exception classes:

• General diagnostic errors: The DiagErrorDomain ([SWS_DM_00520], [SWS_DM_00524]) and the associated DiagException ([SWS_DM_00516]) signal fundamental platform or configuration errors such as invalid arguments or uninitialized instances.
• UDS Negative Response Codes (NRC): Specific protocol-related UDS rejections according to ISO 14229 are mapped via the DiagUdsNrcErrorDomain ([SWS_DM_00532], [SWS_DM_00536]) and DiagUdsNrcException ([SWS_DM_00528]).
• Service provision errors: If the activation or deactivation of port interfaces fails, the DiagOfferErrorDomain ([SWS_DM_00992], [SWS_DM_01003]) takes effect with the DiagOfferException ([SWS_DM_00986]).
• Event and monitor reporting errors: Errors during status reporting by monitors are indicated by the DiagReportingErrorDomain ([SWS_DM_00999], [SWS_DM_01004]) and DiagReportingException ([SWS_DM_00988]).
• SOVD protocol errors: Errors in REST endpoints, JSON contents, or access control are reported via the DiagSovdErrorDomain ([SWS_DM_01812], [SWS_DM_01816]) and DiagSovdException ([SWS_DM_01808]).

At transport layer level, transmission aborts, buffer overflows, or connection drops are reported to Diagnostic Management by the callback NotifyMessageFailure() ([SWS_DM_00310]). This enables the module to immediately release allocated resources and, if necessary, initiate negative response messages to the tester.

Class diagram: Error domain architecture and mapping of standardized exception and error codes in Diagnostic Management. Sources: [SWS_DM_00520], [SWS_DM_00532], [SWS_DM_00992], [SWS_DM_00999], [SWS_DM_01812]

Further detailed evidence

The normative basis of the module diag relies on three central specifications of the AUTOSAR Adaptive Platform:

• Interface and component architecture: The system interfaces, the daemon model, and the separation of transport and application layers are specified in AUTOSAR_AP_EXP_SWArchitecture (AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168).
• Specification of Diagnostic Management: The detailed API signatures, sequence flows for request handling, transport handler lifecycles, and debouncing rules are defined by AUTOSAR_SWS_Diagnostics (AUTOSAR_SWS_Diagnostics p. 128, AUTOSAR_SWS_Diagnostics p. 130, SWS_Diagnostics p. 225).
• Manifest and metamodel definitions: The declarative binding of port interfaces, validation logics, and service mappings to software components is governed by AUTOSAR_AP_TPS_ManifestSpecification (AUTOSAR_AP_TPS_ManifestSpecification p. 311, AUTOSAR_AP_TPS_ManifestSpecification p. 321, AUTOSAR_AP_TPS_ManifestSpecification p. 341).