네임스페이스 apext::diag::uds_transport

네임스페이스 apext::diag::uds_transport은 특정 UDS 전송 프로토콜로부터 일반 진단 관리를 분리하기 위한 C++ 전송 인터페이스를 제공합니다 AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”. 프로토콜 플러그인은 기본 클래스 UdsTransportProtocolHandler에서 파생되며 생성, 초기화, 시작 및 정돈된 중지로 구성된 엄격한 라이프사이클을 거칩니다 [SWS_DM_00329]. 수신 메시지는 IndicateMessage를 통해 보고되며, 여유 용량이 있는 경우 페이로드 인수를 위해 메모리 관리되는 UdsMessagePtr를 받습니다. 핵심 제약 조건은 중지 후 확인 메시지를 제외하고 진단 관리에 대한 추가 호출이 발생해서는 안 된다는 것입니다.

자세히 ›

컨텍스트

네임스페이스 apext::diag::uds_transport은 AUTOSAR Adaptive Platform의 진단 관리(DM)를 위한 표준화된 C++ 전송 인터페이스(Transport Protocol API)를 정의합니다 AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”. 이 아키텍처는 진단 관리의 일반 핵심을 구체적인 네트워크 및 전송 계층으로부터 기능적으로 분리합니다. 이를 통해 DoIP와 같은 표준화된 프로토콜뿐만 아니라 향후 또는 제조업체 특정 전송 프로토콜(예: CAN, CAN-FD 또는 FlexRay용)을 모듈식 플러그인으로 통합할 수 있습니다 AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”.

중앙 중개 인스턴스는 Diagnostic Server 인스턴스와 연결된 전송 프로토콜 간의 상호 작용을 조정하는 클래스 UdsTransportProtocolMgr입니다. 구체적인 프로토콜 플러그인은 추상 기본 클래스 UdsTransportProtocolHandler에서 파생됩니다 AUTOSAR_AP_SWS_Diagnostics §7.1.1 “Support of UDS Transport Layer” [SWS_DM_00315]. 개별 핸들러 인스턴스는 UdsTransportProtocolHandlerID를 통해 주소가 지정되는 반면 [SWS_DM_00336], 통신 채널은 타입 ChannelID을 통해 식별됩니다 [SWS_DM_00337]. ISO 서비스 0x2A에 따른 주기적 데이터 조회를 지원하기 위해 인터페이스에는 클래스 UdsTransportProtocolPeriodicHandler도 추가로 포함됩니다.

수명 주기

진단 관리는 정해진 순서에 따라 각 UdsTransportProtocolHandler 인스턴스의 라이프사이클을 제어합니다 [SWS_DM_00329]:

1. 생성: DM은 생성자 UdsTransportProtocolHandler::UdsTransportProtocolHandler을 통해 프로토콜 플러그인을 인스턴스화합니다 [SWS_DM_00329].
2. 초기화: DM은 UdsTransportProtocolHandler::Initialize을 호출합니다 [SWS_DM_00329]. GetPeriodicHandler 조회를 제외하고 DM은 kInitializeOk이 성공적으로 반환되기 전에 핸들러에서 다른 메서드를 호출해서는 안 됩니다 [SWS_DM_01746].
3. 시작 및 작동: 성공적으로 초기화된 후 핸들러는 UdsTransportProtocolHandler::Start으로 활성화됩니다. 이 호출 이후에야 DM은 UdsTransportProtocolMgr::ChannelReestablished을 통해 재활성화된 채널에 대한 메시지를 처리합니다 [SWS_DM_01744].
4. 종료: DM이 상태 ApplicationState.kTerminating으로 전환되면 모든 활성 플러그인에 대해 UdsTransportProtocolHandler::Stop을 호출합니다 [SWS_DM_00333]. 이 호출이 반환된 후 플러그인은 UdsTransportProtocolMgr::HandlerStopped만을 호출해야 합니다 [SWS_DM_01741]. DM은 이 확인을 적극적으로 대기합니다 [SWS_DM_00340].

상태 다이어그램: 전송 프로토콜 핸들러 구현의 라이프사이클 단계 및 전이 조건. 출처: [SWS_DM_00329], [SWS_DM_00333], [SWS_DM_00340], [SWS_DM_01741], [SWS_DM_01744], [SWS_DM_01745], [SWS_DM_01746]

사용 경로

작동 중 수신 진단 메시지의 전달은 핸들러와 매니저의 조율된 상호 작용을 통해 수행됩니다:

1. 메시지 표시: 핸들러가 채널(ChannelID [SWS_DM_00337])에서 데이터를 수신하면 UdsTransportProtocolMgr::IndicateMessage를 호출합니다. 이때 payloadInfo으로 사전 페이로드를 전달할 수 있으며, 기능적 요청을 조기에 감지하기 위해 최소 처음 2바이트를 전달하는 것이 권장됩니다 AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”.
2. 버퍼 할당: DM이 수신 준비가 된 경우 IndicateMessage은 IndicationResult::kIndicationOk의 std::pair 및 유효한 스마트 포인터 UdsMessagePtr [SWS_DM_00309] [SWS_DM_00385]로 응답합니다. 참조된 UdsMessage 객체는 최소 1바이트의 용량을 갖습니다 [SWS_DM_00385]. 버퍼는 DM 코어의 특정 삭제자를 사용하는 std::unique_ptr로 관리되며 스레드로부터 안전하지 않습니다 [SWS_DM_00303]. 읽기 액세스를 위해 상수 대응물인 UdsMessageConstPtr이 존재합니다 [SWS_DM_00304].
3. 데이터 전달: 핸들러는 수신된 진단 데이터를 제공된 버퍼에 기록하며, 이 버퍼의 바이트 시퀀스는 타입 ByteSpan(ara::core::Span<ara::core::Byte> [SWS_DM_00338]의 별칭)을 통해 형식화됩니다. GetPeriodicHandler를 통해 별도의 클래스 UdsTransportProtocolPeriodicHandler을 제공하는 것은 주기적 전송 서비스 0x2A를 일반 UDS 메시지 경로로부터 분리하기 위한 것으로 추정됩니다. 질문 Q-230ef0b7c384c594 (열림)

시퀀스 다이어그램: 핸들러, 매니저 및 DM 코어 간의 메시지 표시 및 버퍼 할당 흐름. 출처: AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”, [SWS_DM_00303], [SWS_DM_00309], [SWS_DM_00385], [SWS_DM_00386]

오류 시나리오

명세는 전송 연결을 위한 구체적인 오류 상태 및 전제 조건을 정의합니다:

• 초기화 실패: UdsTransportProtocolHandler::Initialize이 결과 kInitializeFailed을 반환하면 DM은 이 핸들러에 대한 초기화 프로세스를 즉시 중단하고 해당 핸들러에서 더 이상의 메서드를 호출하지 않습니다 [SWS_DM_01745].
• 진단 코어 사용 중 거부: 동일한 테스터 프레즌트 대화의 진행 중인 서비스 처리로 인해 DM이 차단되어 있고 payloadInfo 0x3E 0x80을 포함하는 기능적 테스터 프레즌트가 아닌 경우, IndicateMessage는 메시지 버퍼 대신 nullptr와 함께 결과 kIndicationOccupied을 반환합니다 [SWS_DM_00386].
• 종료 후 허용되지 않는 호출: 플러그인이 Stop 반환 후 HandlerStopped 이외의 UdsTransportProtocolMgr 메서드를 호출하면 이는 프로토콜 요구 사항을 위반하는 것입니다 [SWS_DM_01741]. 마찬가지로 DM은 Start의 성공적인 호출 전에 수신된 경우 ChannelReestablished와 같은 신호를 무시합니다 [SWS_DM_01744].