모듈 ara::diag — Diagnostics
모듈 가이드AI 생성
표준화된 진단 서비스, 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쪽).
컨텍스트 다이어그램: 전송 핸들러, Adaptive Applications 및 외부 테스터 사이의 Diagnostic Management 데몬 임베딩. 출처: 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쪽). 들어오는 메시지는 2단계 표시 및 인계 메커니즘(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)로 설계되었습니다. 물리적 및 논리적 진단 프로토콜을 종단하고, 글로벌 진단 컨텍스트를 관리하며, 개별 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 (열림)
컨텍스트 다이어그램: 전송 핸들러, Adaptive Applications 및 외부 테스터 사이의 Diagnostic Management 데몬 임베딩. 출처: 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]). 메시지는 소스 주소([SWS_DM_00297]), 대상 주소([SWS_DM_00298]) 및 주소 지정 유형([SWS_DM_00299])을 제공하는 UdsMessage로 캡슐화됩니다. 수신이 완료된 후 핸들러는 데이터 객체를 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]), 타입화된 루틴(Start [SWS_DM_00591]을 갖춘 RoutineInterface [SWS_DM_00589]), 데이터 식별자(Read [SWS_DM_00636] 및 Write [SWS_DM_00637]을 갖춘 GenericDataIdentifier [SWS_DM_00634]), 그리고 제네릭 UDS 서비스(HandleMessage [SWS_DM_00618]을 갖춘 GenericUDSService [SWS_DM_00616])에 모두 동일하게 적용됩니다.
장시간 실행되는 진단 트랜잭션(예: AUTOSAR_AP_EXP_SWArchitecture 163쪽에 따른 UploadService [SWS_DM_00797], DownloadService [SWS_DM_00787] 또는 FileTransferService [SWS_DM_01325]를 통한 블록 전송)은 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 기능(ISO 13400-2에 따른 Diagnostic communication over Internet Protocol)을 통합합니다 (AUTOSAR_AP_EXP_SWArchitecture 166쪽, AUTOSAR_AP_EXP_SWArchitecture 167쪽). 플랫폼 확장은 DoIPActivationLine::UpdateActivationLineState()를 통해 물리적 활성화 라인의 상태를 보고합니다 ([SWS_DM_00834], AUTOSAR_AP_TPS_ManifestSpecification 338쪽). 이를 기반으로 DoIPTriggerVehicleAnnouncement를 통해 차량 알림 메시지(Vehicle Announcement Messages)를 트리거할 수 있습니다 ([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 유사 페이로드를 조작하기 위해 DiagnosticSovdArrayContentElementDataView ([SWS_DM_02245], AUTOSAR_AP_EXP_SWArchitecture 172쪽) 및 DiagnosticSovdRecordContentElementDataView ([SWS_DM_02289], AUTOSAR_AP_EXP_SWArchitecture 174쪽)과 같은 타입 안전한 STL 유사 클래스가 제공됩니다.
확장된 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>을 기반으로 하며, 조용한 오류 상태를 완전히 배제합니다. 오류는 기능적 원인에 따라 오류 코드와 해당하는 예외 클래스를 모두 정의하는 5개의 특화된 오류 도메인(ErrorDomain)으로 세분화됩니다:
- 일반 진단 오류:
DiagErrorDomain([SWS_DM_00520], [SWS_DM_00524]) 및 관련DiagException([SWS_DM_00516])은 잘못된 인수 또는 초기화되지 않은 인스턴스와 같은 기본적인 플랫폼 또는 구성 오류를 알립니다. - UDS Negative Response Codes (NRC): ISO 14229에 따른 특정 프로토콜 UDS 거부는
DiagUdsNrcErrorDomain([SWS_DM_00532], [SWS_DM_00536]) 및DiagUdsNrcException([SWS_DM_00528])을 통해 매핑됩니다. - 서비스 제공 오류: 포트 인터페이스의 활성화 또는 비활성화가 실패하면
DiagOfferException([SWS_DM_00986])과 함께DiagOfferErrorDomain([SWS_DM_00992], [SWS_DM_01003])이 적용됩니다. - 이벤트 및 모니터 보고 오류: 모니터의 상태 보고 중 발생하는 오류는
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])을 통해 보고됩니다.
전송 계층 수준에서 전송 중단, 버퍼 오버플로 또는 연결 끊김은 콜백 NotifyMessageFailure()을 통해 Diagnostic Management에 보고됩니다([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쪽).
이 모듈 가이드는 릴리스 R25-11용 AUTOSAR Adaptive 명세를 기반으로 생성되었습니다. 모든 규범적 요구사항은 참조된 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 · 독일어 원문