модуль ara::diag — Diagnostics
Руководство по модулюСОЗДАНО ИИ
Предоставляет стандартизированные диагностические службы, протоколы UDS и SOVD, а также централизованное управление памятью ошибок.
Предоставляет стандартизированные диагностические службы, протоколы UDS и SOVD, а также централизованное управление памятью ошибок.
Функциональный кластер Diagnostic Management в AUTOSAR Adaptive Platform предоставляет центральную инфраструктуру для классической бортовой диагностики UDS и современной SOVD (AUTOSAR_AP_EXP_SWArchitecture с. 150). В качестве демона платформы он терминирует транспортные уровни, такие как DoIP, управляет обработчиками протоколов и передает диагностические запросы в Adaptive Applications через типобезопасные интерфейсы обратного вызова ([SWS_DM_00311]). Одновременно модуль берет на себя мониторинг ошибок, фильтрацию дребезга по времени и счетчикам, а также управление памятью неисправностей. Приложения активируют сервисные функции через декларативную модель предложения (Offer), благодаря чему логика приложений и обработка протокола остаются четко разделенными.
Функциональный кластер Diagnostic Management (ara::diag) в AUTOSAR Adaptive Platform предоставляет центральную, основанную на демоне инфраструктуру для выполнения диагностической коммуникации транспортного средства (AUTOSAR_AP_EXP_SWArchitecture с. 150). Он отделяет зависимые от транспорта обработчики протоколов (такие как DoIP или CAN-TP) от фактического ядра диагностики (UdsTransportProtocolMgr), обеспечивая тем самым единообразное терминирование и маршрутизацию диагностических запросов (AUTOSAR_AP_EXP_SWArchitecture с. 164).
Контекстная диаграмма: встраивание демона Diagnostic Management между обработчиками транспорта, Adaptive Applications и внешними тестерами. Источники: AUTOSAR_AP_EXP_SWArchitecture с. 150, AUTOSAR_AP_EXP_SWArchitecture с. 164, AUTOSAR_AP_EXP_SWArchitecture с. 168
Для обработки служб модуль реализует декларативную модель предоставления: демон диагностики реализует интерфейсы портов, в то время как Adaptive Applications регистрируют сервисные функции обратного вызова для DataIdentifier, рутин или блочных передач и управляют их доступностью через Offer() и StopOffer() соответственно ([SWS_DM_00557], AUTOSAR_AP_EXP_SWArchitecture с. 156). Входящие сообщения безотказно обрабатываются через двухэтапные механизмы индикации и передачи (IndicateMessage и HandleMessage) ([SWS_DM_00309], [SWS_DM_00311]).
Диаграмма последовательности: сквозной поток управления запроса UDS от транспортного уровня через менеджер диагностики до обслуживающего приложения. Источники: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics с. 130
Наряду с классическими функциями UDS кластер управляет диагностическими мониторами, выполняет сконфигурированную фильтрацию дребезга и сохраняет квалифицированные ошибки в первичной памяти неисправностей (DTCInformation) ([SWS_DM_00664], SWS_Diagnostics с. 225). Расширенные стандарты, такие как ISO 13400-2 (DoIP) и ASAM SOVD (Service-Oriented Vehicle Diagnostics), бесшовно интегрируются в платформу через специализированные интерфейсы для линий активации, аутентификации и иерархических полезных данных JSON ([SWS_DM_00834], [SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture с. 170).
Архитектурная роль и границы системы Diagnostic Management
Функциональный кластер Diagnostic Management (ara::diag) в AUTOSAR Adaptive Platform (релиз R25-11) формирует центральный узел для внутриавтомобильной и внешней диагностики автомобиля (AUTOSAR_AP_EXP_SWArchitecture с. 150). Архитектурно модуль спроектирован как фоновая служба на базе демона («aapFunctionalCluster» Diagnostic Management daemon-based). Он терминирует физические и логические диагностические протоколы, управляет глобальным диагностическим контекстом и предоставляет инфраструктуру промежуточного слоя (middleware), с помощью которой отдельные Adaptive Applications могут предоставлять диагностические данные и рутины (AUTOSAR_AP_EXP_SWArchitecture с. 156).
Ландшафт интерфейсов делится преимущественно на две категории: моделированные интерфейсы портов, конфигурируемые через манифест AUTOSAR и привязываемые к процессам приложений, а также нативные интерфейсы времени выполнения C++ (AUTOSAR_AP_EXP_SWArchitecture с. 150). К нативным интерфейсам относится, в частности, класс Conversation, с помощью которого приложения могут опрашивать текущие состояния сессий ([SWS_DM_00696]), определять уровни безопасности ([SWS_DM_00698]) или инспектировать активные диагностические сеансы связи ([SWS_DM_00783]). Интерпретация: строгое разделение между центральным демоном диагностики и процессами приложений, по всей видимости, было выбрано для того, чтобы гарантировать детерминированное время отклика по отношению к внешним тестерам даже при перезапусках процессов отдельных приложений. Вопрос Q-2e2ea8eb9d415fed (открытый)
Контекстная диаграмма: встраивание демона Diagnostic Management между обработчиками транспорта, Adaptive Applications и внешними тестерами. Источники: AUTOSAR_AP_EXP_SWArchitecture с. 150, AUTOSAR_AP_EXP_SWArchitecture с. 164, AUTOSAR_AP_EXP_SWArchitecture с. 168
Подключение транспортного уровня и управление жизненным циклом обработчиков протоколов
Чтобы действовать независимо от конкретных сетевых технологий (таких как Ethernet/DoIP или CAN/ISO-TP), Diagnostic Management отделяет ядро протокола с помощью стандартизированных транспортных интерфейсов (AUTOSAR_AP_EXP_SWArchitecture с. 164). Универсальное ядро реализует интерфейс UdsTransportProtocolMgr, в то время как транспортно-специфичные адаптеры подключаются как UdsTransportProtocolHandler (AUTOSAR_AP_EXP_SWArchitecture с. 165). Каждый обработчик идентифицируется однозначным идентификатором, который может быть запрошен через GetHandlerID() ([SWS_DM_00325]).
Управление жизненным циклом транспортного обработчика подразделяется на детерминированные рабочие фазы (AUTOSAR_SWS_Diagnostics с. 128): во время запуска Diagnostic Management инициализирует обработчик с помощью Initialize() ([SWS_DM_00319]), а затем активирует обработку сообщений посредством Start() ([SWS_DM_00322]). При контролируемом завершении работы менеджер запрашивает у обработчика закрытие открытых соединений через Stop() ([SWS_DM_00323]), после чего обработчик подтверждает завершение через HandlerStopped() ([SWS_DM_00314]).
Для долгоживущих диагностических сессий AUTOSAR дополнительно определяет механизм восстановления между жизненными циклами процессов (AUTOSAR_SWS_Diagnostics с. 134). Если ранее сохраненный канал может быть повторно установлен после перезапуска менеджера диагностики, транспортный обработчик сообщает об этом через NotifyReestablishment() ([SWS_DM_00326]). Менеджер внутренне синхронизирует состояние и подтверждает это вызовом ChannelReestablished() ([SWS_DM_00313]).
Диаграмма последовательности: управление жизненным циклом транспортного обработчика UDS со стороны универсального менеджера диагностики. Источники: [SWS_DM_00314], [SWS_DM_00319], [SWS_DM_00322], [SWS_DM_00323], AUTOSAR_SWS_Diagnostics с. 128
Обработка UDS-сервисов и специфичная для приложения обработка запросов
Входящие UDS-сообщения обрабатываются пошагово после валидации протокола (AUTOSAR_SWS_Diagnostics с. 130). Сначала транспортный обработчик объявляет менеджеру о начинающемся сообщении через IndicateMessage() для выделения ресурсов и буферов ([SWS_DM_00309]). Сообщение инкапсулируется как UdsMessage, предоставляющий адрес источника ([SWS_DM_00297]), адрес назначения ([SWS_DM_00298]) и тип адресации ([SWS_DM_00299]). После полного приема обработчик передает объект данных через HandleMessage() в Diagnostic Management ([SWS_DM_00311]), при этом специфичная для канала метаинформация дополняется с помощью AddMetaInfo() ([SWS_DM_00302]).
В релизе R25-11 взаимодействие между демоном платформы и приложением следует инвертированной модели предоставления сервисов (AUTOSAR_AP_EXP_SWArchitecture с. 156): демон платформы реализует порты сервисов, в то время как Adaptive Applications реализуют методы обратного вызова и явно активируют свою готовность к пересылке через Offer() ([SWS_DM_00557]) или приостанавливают ее через StopOffer() ([SWS_DM_00558]). Это в равной степени относится к универсальным подпрограммам (GenericRoutine [SWS_DM_00552]), типизированным подпрограммам (RoutineInterface [SWS_DM_00589] с Start [SWS_DM_00591]), идентификаторам данных (GenericDataIdentifier [SWS_DM_00634] с Read [SWS_DM_00636] и Write [SWS_DM_00637]), а также универсальным сервисам UDS (GenericUDSService [SWS_DM_00616] с HandleMessage [SWS_DM_00618]).
Длительные диагностические транзакции (такие как блочные передачи через UploadService [SWS_DM_00797], DownloadService [SWS_DM_00787] или FileTransferService [SWS_DM_01325] согласно AUTOSAR_AP_EXP_SWArchitecture с. 163) обрабатываются асинхронно через ara::core::Future. Во избежание блокировки ресурсов специализированные обработчики приложений получают экземпляр CancellationHandler (AUTOSAR_AP_EXP_SWArchitecture с. 152). Через IsCanceled() приложение может запросить отмену ([SWS_DM_00614]) или через SetNotifier() зарегистрировать функцию уведомления ([SWS_DM_00615]). Для скоординированных перезапусков предоставляется интерфейс EcuResetRequest ([SWS_DM_01010]), который делегирует запросы сброса в State Management (AUTOSAR_AP_EXP_SWArchitecture с. 162).
Диаграмма последовательности: сквозной поток управления запроса UDS от транспортного уровня через менеджер диагностики до обслуживающего приложения. Источники: [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics с. 130
Мониторинг событий, устранение дребезга и управление памятью ошибок
Для регистрации и квалификации системных ошибок Diagnostic Management реализует иерархическую модель, состоящую из мониторов и диагностических событий (SWS_Diagnostics с. 225). Приложение создает экземпляр объекта Monitor ([SWS_DM_00548]) и непрерывно сообщает результаты проверок через ReportMonitorAction() ([SWS_DM_00543]). При этом модуль поддерживает как основанные на счетчиках, так и основанные на времени алгоритмы устранения дребезга ([SWS_DM_00549], [SWS_DM_00550]). Через интерфейс Event приложения могут получать текущее значение байта состояния UDS ([SWS_DM_00649]), проверять статус устранения дребезга ([SWS_DM_00654]) или регистрировать функции обратного вызова при изменении состояния ([SWS_DM_00650]).
Чтобы свести к минимуму занимаемый портами объем в сложных системах, платформа предоставляет объединенные интерфейсы (AUTOSAR_AP_EXP_SWArchitecture с. 153): через MultipleMonitor ([SWS_DM_01695]), MultipleEvent ([SWS_DM_01705]) и MultipleCondition ([SWS_DM_01727]) несколько каналов мониторинга могут адресоваться через общий интерфейс порта. Управление разрешением для мониторов осуществляется через объекты Condition ([SWS_DM_00712]), в то время как OperationCycle ([SWS_DM_00752]) и Indicator ([SWS_DM_00742], SWS_Diagnostics с. 633) управляют рабочими циклами и сигнализируют о запросах контрольных ламп.
Агрегированные события поступают в систему управления памятью ошибок, которая предоставляется через DTCInformation ([SWS_DM_00664], AUTOSAR_AP_EXP_SWArchitecture с. 144). Этот интерфейс позволяет считывать сохраненные записи ([SWS_DM_00669]), выборочно или глобально удалять DTC ([SWS_DM_00671]) и активировать запись DTC ([SWS_DM_00674]). При превышении емкости первичной памяти приложение уведомляется через SetEventMemoryOverflowNotifier() ([SWS_DM_00918], [SWS_DM_00919]).
Диаграмма состояний/деятельности: последовательность от действия монитора через устранение дребезга до квалификации DTC в памяти ошибок. Источники: [SWS_DM_00543], [SWS_DM_00649], [SWS_DM_00664], SWS_Diagnostics с. 225
Расширенные протоколы диагностики: интеграция DoIP и сервисы SOVD
Для автомобильных сетей на базе Ethernet модуль интегрирует специализированные функции DoIP (Diagnostic communication over Internet Protocol согласно ISO 13400-2) (AUTOSAR_AP_EXP_SWArchitecture с. 166, AUTOSAR_AP_EXP_SWArchitecture с. 167). Расширения платформы сообщают о состоянии физических линий активации через DoIPActivationLine::UpdateActivationLineState() ([SWS_DM_00834], AUTOSAR_AP_TPS_ManifestSpecification с. 338). На этой основе сообщения объявления транспортного средства (Vehicle Announcement Messages) могут инициироваться через DoIPTriggerVehicleAnnouncement ([SWS_DM_00821], [SWS_DM_00822], AUTOSAR_AP_SWS_Diagnostics с. 108). Идентификация группы и сущности запрашивается динамически через DoIPGroupIdentification ([SWS_DM_00722]) и DoIPEntityIdentification ([SWS_DM_01364], [SWS_DM_01366]).
Диаграмма последовательности: взаимодействие между приложением, линией активации и инициированием сообщений объявления транспортного средства DoIP. Источники: [SWS_DM_00822], [SWS_DM_00834], AUTOSAR_AP_SWS_Diagnostics с. 108
В дополнение к классическим службам UDS релиз R25-11 вводит нативные интерфейсы для SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / ISO 13170) (AUTOSAR_AP_EXP_SWArchitecture с. 168). Структурированные диагностические данные моделируются через DiagnosticSovdContentElementData ([SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture с. 170). Для обработки сложных полезных нагрузок, аналогичных JSON, предусмотрены типобезопасные STL-подобные классы, такие как DiagnosticSovdArrayContentElementDataView ([SWS_DM_02245], AUTOSAR_AP_EXP_SWArchitecture с. 172) и DiagnosticSovdRecordContentElementDataView ([SWS_DM_02289], AUTOSAR_AP_EXP_SWArchitecture с. 174).
Для расширенных транзакций и защиты SOVD модуль определяет стандартизированные роли: большие объемы данных (такие как трассировки или дампы сбоев) передаются через SovdBulkData ([SWS_DM_01847], [SWS_DM_01854], AUTOSAR_AP_TPS_ManifestSpecification с. 321). Управление доступом осуществляется с помощью проверок токенов и близости через SovdAuthorization ([SWS_DM_01489]) и SovdProximityChallenge ([SWS_DM_01480], [SWS_DM_01493]), тогда как проверки сервисов авторизуются через SovdServiceValidation ([SWS_DM_01823], [SWS_DM_01827]).
Поведение при ошибке
Управление ошибками модуля diag основано на стандартном шаблоне AUTOSAR ara::core::Result<T, ErrorCode> и полностью исключает скрытые состояния ошибок. По своим функциональным причинам ошибки подразделяются на пять специализированных доменов ошибок (ErrorDomain), которые определяют как коды ошибок, так и соответствующие классы исключений:
- Общие ошибки диагностики:
DiagErrorDomain([SWS_DM_00520], [SWS_DM_00524]) и соответствующийDiagException([SWS_DM_00516]) сигнализируют о фундаментальных ошибках платформы или конфигурации, таких как недопустимые аргументы или неинициализированные экземпляры. - UDS Negative Response Codes (NRC): специфические протокольные отклонения UDS согласно ISO 14229 отображаются через
DiagUdsNrcErrorDomain([SWS_DM_00532], [SWS_DM_00536]) иDiagUdsNrcException([SWS_DM_00528]). - Ошибки предоставления сервисов: если активация или деактивация интерфейсов портов завершается сбоем, вступает в действие
DiagOfferErrorDomain([SWS_DM_00992], [SWS_DM_01003]) сDiagOfferException([SWS_DM_00986]). - Ошибки сообщений о событиях и мониторах: ошибки во время сообщения состояния мониторов отображаются с помощью
DiagReportingErrorDomain([SWS_DM_00999], [SWS_DM_01004]) иDiagReportingException([SWS_DM_00988]). - Ошибки протокола SOVD: ошибки в конечных точках REST, содержимом JSON или управлении доступом сообщаются через
DiagSovdErrorDomain([SWS_DM_01812], [SWS_DM_01816]) иDiagSovdException([SWS_DM_01808]).
На уровне транспортного уровня прерывания передачи, переполнения буфера или разрывы соединения передаются в Diagnostic Management через функцию обратного вызова NotifyMessageFailure() ([SWS_DM_00310]). Это позволяет модулю незамедлительно освобождать выделенные ресурсы и при необходимости инициировать отправку сообщений с отрицательным ответом тестеру.
Диаграмма классов: архитектура доменов ошибок и сопоставление стандартизированных кодов исключений и ошибок в Diagnostic Management. Источники: [SWS_DM_00520], [SWS_DM_00532], [SWS_DM_00992], [SWS_DM_00999], [SWS_DM_01812]
Дальнейшие подробные доказательства
Нормативная база модуля diag опирается на три основных документа спецификаций AUTOSAR Adaptive Platform:
- Архитектура интерфейсов и компонентов: системные интерфейсы, модель демона, а также разделение транспортного и прикладного уровней изложены в
AUTOSAR_AP_EXP_SWArchitecture(AUTOSAR_AP_EXP_SWArchitecture с. 150, AUTOSAR_AP_EXP_SWArchitecture с. 164, AUTOSAR_AP_EXP_SWArchitecture с. 168). - Спецификация Diagnostic Management: детальные сигнатуры API, последовательности для обработки запросов, жизненные циклы транспортных обработчиков и правила устранения дребезга определяет
AUTOSAR_SWS_Diagnostics(AUTOSAR_SWS_Diagnostics с. 128, AUTOSAR_SWS_Diagnostics с. 130, SWS_Diagnostics с. 225). - Определения манифеста и метамодели: декларативное связывание интерфейсов портов, логики валидации и сопоставлений сервисов с программными компонентами регламентирует
AUTOSAR_AP_TPS_ManifestSpecification(AUTOSAR_AP_TPS_ManifestSpecification с. 311, AUTOSAR_AP_TPS_ManifestSpecification с. 321, AUTOSAR_AP_TPS_ManifestSpecification с. 341).
Настоящее руководство по модулю было сгенерировано на основе спецификаций AUTOSAR Adaptive для релиза R25-11. Все нормативные требования взяты из указанных документов SWS и архитектуры.
function: 755 variable: 102 class: 79 type alias: 45 struct: 39 enumeration: 35
Карта тем
ara::diag
131Для этого релиза нет данных об элементах
<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.
наследует от ara::core::ErrorDomain
Exception type thrown by Diag classes.
наследует от 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.
наследует от ara::core::ErrorDomain
Exception type thrown by Diag classes.
наследует от ara::core::Exception
Error domain for diagnostic reporting errors.
наследует от ara::core::ErrorDomain
Exception type thrown by Diag classes.
наследует от ara::core::Exception
Error domain for errors originating from SOVD.
наследует от ara::core::ErrorDomain
Exception type for SOVD thrown by Diag classes.
наследует от ara::core::Exception
Error domain for errors originating from several diagnostic classes.
наследует от ara::core::ErrorDomain
Exception type thrown by Diag classes.
наследует от 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.
Перегрузки 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;Пространства имён
- <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-диаграмма классов модуля
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 · Немецкий оригинал