módulo ara::diag — Diagnostics
Guía del móduloGENERADO POR IA
Proporciona servicios de diagnóstico estandarizados, protocolos UDS y SOVD, así como una gestión central de la memoria de averías.
Proporciona servicios de diagnóstico estandarizados, protocolos UDS y SOVD, así como una gestión central de la memoria de averías.
El clúster funcional Diagnostic Management proporciona en AUTOSAR Adaptive Platform la infraestructura central para el diagnóstico de vehículos clásico mediante UDS y moderno mediante SOVD (AUTOSAR_AP_EXP_SWArchitecture p. 150). Como demonio de plataforma, termina capas de transporte como DoIP, controla manejadores de protocolo y reenvía solicitudes de diagnóstico a las Adaptive Applications a través de interfaces de retrollamada con seguridad de tipos ([SWS_DM_00311]). Al mismo tiempo, el módulo asume la supervisión de fallos, el filtrado antirrebote por tiempo y por contador, así como la gestión de la memoria de averías. Las aplicaciones habilitan las funciones de servicio mediante un modelo de oferta declarativo, con lo que la lógica de aplicación y el procesamiento de protocolos se mantienen netamente separados.
El clúster funcional Diagnostic Management (ara::diag) proporciona en AUTOSAR Adaptive Platform la infraestructura central basada en demonio para el procesamiento de la comunicación de diagnóstico adecuada para vehículos (AUTOSAR_AP_EXP_SWArchitecture p. 150). Desacopla los manejadores de protocolo específicos del transporte (como DoIP o CAN-TP) del núcleo de diagnóstico propiamente dicho (UdsTransportProtocolMgr) y permite así una terminación y reenvío uniformes de las solicitudes de diagnóstico (AUTOSAR_AP_EXP_SWArchitecture p. 164).
Diagrama de contexto: Integración del demonio de Diagnostic Management entre manejadores de transporte, Adaptive Applications y equipos de prueba externos. Fuentes: AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168
Para el procesamiento de servicios, el módulo implementa un modelo de provisión declarativo: el demonio de diagnóstico realiza las interfaces de puerto, mientras que las Adaptive Applications registran retrollamadas de servicio para DataIdentifier, rutinas o transferencias basadas en bloques, y controlan su disponibilidad mediante Offer() o StopOffer() ([SWS_DM_00557], AUTOSAR_AP_EXP_SWArchitecture p. 156). Los mensajes entrantes se procesan a prueba de fallos mediante mecanismos de indicación y transferencia en dos etapas (IndicateMessage y HandleMessage) ([SWS_DM_00309], [SWS_DM_00311]).
Diagrama de secuencia: Flujo de control de extremo a extremo de una solicitud UDS desde la capa de transporte a través del gestor de diagnóstico hasta la aplicación consumidora. Fuentes: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130
Además de las funciones UDS clásicas, el clúster gestiona monitores de diagnóstico, ejecuta los filtrados antirrebote configurados y persiste los fallos cualificados en la memoria de averías primaria (DTCInformation) ([SWS_DM_00664], SWS_Diagnostics p. 225). Estándares avanzados como ISO 13400-2 (DoIP) y ASAM SOVD (Service-Oriented Vehicle Diagnostics) se integran a la perfección en la plataforma mediante interfaces especializadas para líneas de activación, autenticaciones y datos útiles jerárquicos en JSON ([SWS_DM_00834], [SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170).
Rol arquitectónico y límites del sistema de Diagnostic Management
El clúster funcional Diagnostic Management (ara::diag) constituye en AUTOSAR Adaptive Platform (versión R25-11) el punto neurálgico central para el diagnóstico de vehículos tanto interno como externo (AUTOSAR_AP_EXP_SWArchitecture p. 150). Desde el punto de vista arquitectónico, el módulo está diseñado como un servicio en segundo plano basado en demonio («aapFunctionalCluster» Diagnostic Management daemon-based). Termina protocolos de diagnóstico tanto físicos como lógicos, gestiona el contexto global de diagnóstico y proporciona la infraestructura de middleware a través de la cual las Adaptive Applications individuales pueden suministrar datos y rutinas relacionados con el diagnóstico (AUTOSAR_AP_EXP_SWArchitecture p. 156).
El panorama de interfaces se divide principalmente en dos categorías: interfaces de puerto modeladas, que se configuran mediante el manifiesto de AUTOSAR y se vinculan a procesos de aplicación, así como interfaces nativas de tiempo de ejecución de C++ (AUTOSAR_AP_EXP_SWArchitecture p. 150). Entre las interfaces nativas se cuenta en particular la clase Conversation, a través de la cual las aplicaciones pueden consultar estados de sesión actuales ([SWS_DM_00696]), determinar niveles de seguridad ([SWS_DM_00698]) o inspeccionar conversaciones de diagnóstico activas ([SWS_DM_00783]). Interpretación: la separación estricta entre el demonio de diagnóstico central y los procesos de aplicación probablemente se eligió para garantizar tiempos de respuesta deterministas frente a testers externos, incluso ante reinicios de procesos de aplicaciones individuales. Pregunta Q-2e2ea8eb9d415fed (abierta)
Diagrama de contexto: Integración del demonio de Diagnostic Management entre manejadores de transporte, Adaptive Applications y equipos de prueba externos. Fuentes: AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168
Conexión de la capa de transporte y control del ciclo de vida de los manejadores de protocolo
Para operar con independencia de tecnologías de red específicas (como Ethernet/DoIP o CAN/ISO-TP), el Diagnostic Management desacopla el núcleo de protocolo mediante interfaces de transporte estandarizadas (AUTOSAR_AP_EXP_SWArchitecture p. 164). El núcleo genérico implementa la interfaz UdsTransportProtocolMgr, mientras que los adaptadores específicos de transporte se conectan como UdsTransportProtocolHandler (AUTOSAR_AP_EXP_SWArchitecture p. 165). Cada manejador se identifica mediante un identificador unívoco que puede consultarse a través de GetHandlerID() ([SWS_DM_00325]).
El control del ciclo de vida de un manejador de transporte se divide en fases operativas deterministas (AUTOSAR_SWS_Diagnostics p. 128): durante el arranque, el Diagnostic Management inicializa el manejador a través de Initialize() ([SWS_DM_00319]) y activa a continuación el procesamiento de mensajes mediante Start() ([SWS_DM_00322]). En la finalización controlada, el administrador solicita al manejador a través de Stop() cerrar las conexiones abiertas ([SWS_DM_00323]), tras lo cual el manejador confirma la finalización mediante HandlerStopped() ([SWS_DM_00314]).
Para sesiones de diagnóstico de larga duración, AUTOSAR especifica además un mecanismo de recuperación a través de ciclos de vida de procesos (AUTOSAR_SWS_Diagnostics p. 134). Si un canal previamente persistido puede restablecerse tras un reinicio del Diagnostic Manager, el manejador de transporte lo notifica mediante NotifyReestablishment() ([SWS_DM_00326]). El administrador sincroniza el estado internamente y lo confirma invocando ChannelReestablished() ([SWS_DM_00313]).
Diagrama de secuencia: control del ciclo de vida de un manejador de transporte UDS por parte del Diagnostic Manager genérico. Fuentes: [SWS_DM_00314], [SWS_DM_00319], [SWS_DM_00322], [SWS_DM_00323], AUTOSAR_SWS_Diagnostics p. 128
Procesamiento de servicios UDS y gestión de solicitudes específica de la aplicación
Los mensajes UDS entrantes se procesan paso a paso tras la validación de protocolo (AUTOSAR_SWS_Diagnostics p. 130). En primer lugar, el manejador de transporte anuncia un mensaje entrante mediante IndicateMessage() al administrador para asignar recursos y búferes ([SWS_DM_00309]). El mensaje se encapsula como UdsMessage, que proporciona la dirección de origen ([SWS_DM_00297]), la dirección de destino ([SWS_DM_00298]) y el tipo de direccionamiento ([SWS_DM_00299]). Tras la recepción completa, el manejador transfiere el objeto de datos mediante HandleMessage() al Diagnostic Management ([SWS_DM_00311]), complementándose metainformación específica del canal mediante AddMetaInfo() ([SWS_DM_00302]).
En el Release R25-11, la interacción entre el demonio de plataforma y la aplicación sigue un modelo invertido de provisión de servicios (AUTOSAR_AP_EXP_SWArchitecture p. 156): el demonio de plataforma implementa los puertos de servicio, mientras que las Adaptive Applications implementan métodos de callback y activan explícitamente su disponibilidad para el reenvío mediante Offer() ([SWS_DM_00557]) o la suspenden mediante StopOffer() ([SWS_DM_00558]). Esto aplica por igual a rutinas genéricas (GenericRoutine [SWS_DM_00552]), rutinas tipadas (RoutineInterface [SWS_DM_00589] con Start [SWS_DM_00591]), identificadores de datos (GenericDataIdentifier [SWS_DM_00634] con Read [SWS_DM_00636] y Write [SWS_DM_00637]), así como servicios UDS genéricos (GenericUDSService [SWS_DM_00616] con HandleMessage [SWS_DM_00618]).
Las transacciones de diagnóstico de mayor duración (como transferencias de bloques mediante UploadService [SWS_DM_00797], DownloadService [SWS_DM_00787] o FileTransferService [SWS_DM_01325] según AUTOSAR_AP_EXP_SWArchitecture p. 163) se gestionan de forma asíncrona mediante ara::core::Future. Para evitar bloqueos de recursos, los manejadores específicos de la aplicación reciben una instancia de CancellationHandler (AUTOSAR_AP_EXP_SWArchitecture p. 152). A través de IsCanceled(), la aplicación puede consultar una cancelación ([SWS_DM_00614]) o registrar una función de notificación mediante SetNotifier() ([SWS_DM_00615]). Para reinicios coordinados se proporciona la interfaz EcuResetRequest ([SWS_DM_01010]), que delega las solicitudes de reinicio al State Management (AUTOSAR_AP_EXP_SWArchitecture p. 162).
Diagrama de secuencia: Flujo de control de extremo a extremo de una solicitud UDS desde la capa de transporte a través del gestor de diagnóstico hasta la aplicación consumidora. Fuentes: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130
Supervisión de eventos, desparasitado y gestión de la memoria de averías
Para el registro y la cualificación de fallos del sistema, el Diagnostic Management implementa un modelo jerárquico de monitores y eventos de diagnóstico (SWS_Diagnostics p. 225). Una aplicación instancia un objeto Monitor ([SWS_DM_00548]) y notifica resultados de pruebas continuamente a través de ReportMonitorAction() ([SWS_DM_00543]). El módulo admite tanto algoritmos de desparasitado basados en contador como basados en tiempo ([SWS_DM_00549], [SWS_DM_00550]). A través de la interfaz Event, las aplicaciones pueden consultar el valor actual del byte de estado UDS ([SWS_DM_00649]), verificar el estado de desparasitado ([SWS_DM_00654]) o registrar callbacks de cambio de estado ([SWS_DM_00650]).
Para mantener reducida la huella de puertos en sistemas complejos, la plataforma proporciona interfaces agrupadas (AUTOSAR_AP_EXP_SWArchitecture p. 153): a través de MultipleMonitor ([SWS_DM_01695]), MultipleEvent ([SWS_DM_01705]) y MultipleCondition ([SWS_DM_01727]) se pueden direccionar múltiples canales de supervisión mediante una interfaz de puerto común. La gestión de habilitación para monitores se realiza mediante objetos Condition ([SWS_DM_00712]), mientras que OperationCycle ([SWS_DM_00752]) y Indicator ([SWS_DM_00742], SWS_Diagnostics p. 633) controlan los ciclos de operación y señalizan solicitudes de lámparas de advertencia.
Los eventos agregados confluyen en la gestión de la memoria de averías, expuesta a través de DTCInformation ([SWS_DM_00664], AUTOSAR_AP_EXP_SWArchitecture p. 144). Esta interfaz permite la lectura de entradas almacenadas ([SWS_DM_00669]), el borrado selectivo o global de DTC ([SWS_DM_00671]) y la activación del registro de DTC ([SWS_DM_00674]). Si se produce un exceso de capacidad de la memoria primaria, se notifica a la aplicación mediante SetEventMemoryOverflowNotifier() ([SWS_DM_00918], [SWS_DM_00919]).
Diagrama de estados/actividades: flujo desde la acción del monitor a través del desparasitado hasta la cualificación del DTC en la memoria de averías. Fuentes: [SWS_DM_00543], [SWS_DM_00649], [SWS_DM_00664], SWS_Diagnostics p. 225
Protocolos de diagnóstico avanzados: integración de DoIP y servicios SOVD
Para redes vehiculares basadas en Ethernet, el módulo integra funciones DoIP dedicadas (Diagnostic communication over Internet Protocol según ISO 13400-2) (AUTOSAR_AP_EXP_SWArchitecture p. 166, AUTOSAR_AP_EXP_SWArchitecture p. 167). Las extensiones de plataforma notifican el estado de las líneas físicas de activación mediante DoIPActivationLine::UpdateActivationLineState() ([SWS_DM_00834], AUTOSAR_AP_TPS_ManifestSpecification p. 338). Sobre esta base, pueden desencadenarse mensajes de anuncio de vehículo (Vehicle Announcement Messages) mediante DoIPTriggerVehicleAnnouncement ([SWS_DM_00821], [SWS_DM_00822], AUTOSAR_AP_SWS_Diagnostics p. 108). La identificación de grupos y entidades se consulta dinámicamente mediante DoIPGroupIdentification ([SWS_DM_00722]) y DoIPEntityIdentification ([SWS_DM_01364], [SWS_DM_01366]).
Diagrama de secuencia: interacción entre la aplicación, la línea de activación y el disparo de anuncios de vehículo DoIP. Fuentes: [SWS_DM_00822], [SWS_DM_00834], AUTOSAR_AP_SWS_Diagnostics p. 108
Además de los servicios UDS clásicos, el Release R25-11 establece interfaces nativas para SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / ISO 13170) (AUTOSAR_AP_EXP_SWArchitecture p. 168). Los datos de diagnóstico estructurados se modelan mediante DiagnosticSovdContentElementData ([SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170). Para la manipulación de cargas útiles complejas análogas a JSON, se dispone de clases de tipo seguro similares a STL como DiagnosticSovdArrayContentElementDataView ([SWS_DM_02245], AUTOSAR_AP_EXP_SWArchitecture p. 172) y DiagnosticSovdRecordContentElementDataView ([SWS_DM_02289], AUTOSAR_AP_EXP_SWArchitecture p. 174).
Para transacciones SOVD avanzadas y mecanismos de protección, el módulo define roles estandarizados: grandes volúmenes de datos (como trazas o volcados de fallos) se transfieren mediante SovdBulkData ([SWS_DM_01847], [SWS_DM_01854], AUTOSAR_AP_TPS_ManifestSpecification p. 321). El control de acceso se realiza mediante comprobaciones de token y proximidad a través de SovdAuthorization ([SWS_DM_01489]) y SovdProximityChallenge ([SWS_DM_01480], [SWS_DM_01493]), mientras que las comprobaciones de servicio se autorizan mediante SovdServiceValidation ([SWS_DM_01823], [SWS_DM_01827]).
Comportamiento en caso de error
La gestión de errores del módulo diag se basa en el patrón estándar de AUTOSAR ara::core::Result<T, ErrorCode> y excluye por completo los estados de error silenciosos. Los errores se subdividen según sus causas funcionales en cinco dominios de error especializados (ErrorDomain), que definen tanto códigos de error como clases de excepción correspondientes:
- Errores generales de diagnóstico: la
DiagErrorDomain([SWS_DM_00520], [SWS_DM_00524]) y la correspondienteDiagException([SWS_DM_00516]) señalizan errores fundamentales de plataforma o de configuración, tales como argumentos no válidos o instancias no inicializadas. - UDS Negative Response Codes (NRC): los rechazos de protocolo específicos de UDS según ISO 14229 se representan mediante la
DiagUdsNrcErrorDomain([SWS_DM_00532], [SWS_DM_00536]) yDiagUdsNrcException([SWS_DM_00528]). - Errores de provisión de servicios: si falla la activación o desactivación de interfaces de puerto, interviene la
DiagOfferErrorDomain([SWS_DM_00992], [SWS_DM_01003]) con laDiagOfferException([SWS_DM_00986]). - Errores de notificación de eventos y monitores: los errores durante la notificación de estado de los monitores se indican mediante la
DiagReportingErrorDomain([SWS_DM_00999], [SWS_DM_01004]) yDiagReportingException([SWS_DM_00988]). - Errores de protocolo SOVD: los errores en terminales REST, contenidos JSON o en el control de acceso se notifican mediante la
DiagSovdErrorDomain([SWS_DM_01812], [SWS_DM_01816]) yDiagSovdException([SWS_DM_01808]).
A nivel de la capa de transporte, las cancelaciones de transmisión, los desbordamientos de búfer o las caídas de conexión se notifican al Diagnostic Management mediante el callback NotifyMessageFailure() ([SWS_DM_00310]). Esto permite al módulo liberar de inmediato los recursos asignados y, en caso necesario, ordenar mensajes de respuesta negativa al tester.
Diagrama de clases: arquitectura de dominios de error y asignación de códigos de error y excepción estandarizados en el Diagnostic Management. Fuentes: [SWS_DM_00520], [SWS_DM_00532], [SWS_DM_00992], [SWS_DM_00999], [SWS_DM_01812]
Más evidencia detallada
La base normativa del módulo diag se apoya en tres obras de especificación centrales de la AUTOSAR Adaptive Platform:
- Arquitectura de interfaces y componentes: las interfaces del sistema, el modelo de demonio y la separación entre la capa de transporte y la de aplicación están definidos en
AUTOSAR_AP_EXP_SWArchitecture(AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168). - Especificación del Diagnostic Management: las firmas detalladas de API, los flujos de secuencia para la gestión de solicitudes, los ciclos de vida de manejadores de transporte y las reglas de desparasitado se definen en
AUTOSAR_SWS_Diagnostics(AUTOSAR_SWS_Diagnostics p. 128, AUTOSAR_SWS_Diagnostics p. 130, SWS_Diagnostics p. 225). - Definiciones de manifiesto y metamodelo: la vinculación declarativa de interfaces de puerto, lógicas de validación y mapeos de servicio a componentes de software está regulada en
AUTOSAR_AP_TPS_ManifestSpecification(AUTOSAR_AP_TPS_ManifestSpecification p. 311, AUTOSAR_AP_TPS_ManifestSpecification p. 321, AUTOSAR_AP_TPS_ManifestSpecification p. 341).
Esta guía del módulo fue generada a partir de las especificaciones de AUTOSAR Adaptive para el Release R25-11. Todos los requisitos normativos proceden de los documentos de SWS y arquitectura referenciados.
function: 755 variable: 102 class: 79 type alias: 45 struct: 39 enumeration: 35
Mapa de temas
ara::diag
131No hay datos de elementos para esta versión
<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.
hereda de ara::core::ErrorDomain
Exception type thrown by Diag classes.
hereda de 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.
hereda de ara::core::ErrorDomain
Exception type thrown by Diag classes.
hereda de ara::core::Exception
Error domain for diagnostic reporting errors.
hereda de ara::core::ErrorDomain
Exception type thrown by Diag classes.
hereda de ara::core::Exception
Error domain for errors originating from SOVD.
hereda de ara::core::ErrorDomain
Exception type for SOVD thrown by Diag classes.
hereda de ara::core::Exception
Error domain for errors originating from several diagnostic classes.
hereda de ara::core::ErrorDomain
Exception type thrown by Diag classes.
hereda de 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.
Sobrecargas 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
Diagrama de clases UML del módulo
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 · Original en alemán