모듈 ara::com — Communication Management

Functional Cluster Communication Management(ara::com)는 표준화된 프록시 및 스켈레톤 인터페이스를 통해 Adaptive 애플리케이션 간의 서비스 지향 상호작용을 가능하게 합니다(SWS_CommunicationManagement 55쪽, ARAComAPI 1쪽). 이는 OfferService() 및 FindService()을(를) 사용한 동적 서비스 발견을 제어하며([SWS_CM_00101], [SWS_CM_00122]), E2E 및 SecOC 보호가 통합된 동기 및 비동기 메서드, 이벤트, 필드를 제공합니다([SWS_CM_00141], [SWS_CM_90420]). 서비스가 일시적으로 유실된 경우 미들웨어는 연결 중단을 처리하고 재사용 가능해지면 기존 프록시 객체를 자동으로 업데이트합니다(ARAComAPI 32쪽).

자세히 ›

Functional Cluster Communication Management(ara::com)는 AUTOSAR Adaptive Platform에서 서비스 지향 아키텍처(SOA)의 중추를 형성하며 프록시-스켈레톤 패턴을 통해 애플리케이션 로직을 구체적인 전송 프로토콜로부터 분리합니다(SWS_CommunicationManagement 55쪽, ARAComAPI 1쪽). 정형 인터페이스 설명에서 생성된 소비자 측의 프록시 클래스와 제공자 측의 스켈레톤 클래스는 타입 안전한 C++ API를 통해 메서드, 이벤트, 필드를 제공합니다([SWS_CM_00130], [SWS_CM_00131]).

서비스 제공 및 동적 검색은 Service Discovery를 통해 처리됩니다(SWS_CommunicationManagement 67쪽). 제공자는 OfferService()을(를) 통해 서비스를 제공하고([SWS_CM_00101]), 소비자는 FindService()을(를) 통해 동기적으로 또는 StartFindService()을(를) 사용하여 비동기적으로 일치하는 인스턴스를 결정합니다([SWS_CM_00122], [SWS_CM_00123]). 이때 인스턴스는 ara::core::InstanceSpecifier을(를) 통해 모델 기반으로 주소 지정될 수 있으며 런타임에 구체적인 ara::com::InstanceIdentifier(으)로 해석될 수 있습니다([SWS_CM_00118], [SWS_CM_00622]).

시퀀스 다이어그램: 서비스 제공, 비동기 검색 및 프록시 생성 흐름. 출처: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces 16쪽

데이터 전송을 위해 ara::com은(는) ara::core::Future을(를) 통한 요청-응답 메서드([SWS_CM_00191], [SWS_CM_00196]) 및 이벤트와 필드를 위한 발행-구독 패턴을 지원합니다(AUTOSAR_EXP_ARAComAPI 68쪽). 구독자는 Subscribe()을(를) 통해 등록하고([SWS_CM_00141]) GetNewSamples()을(를) 통해 수신 데이터를 읽어옵니다([SWS_CM_00701]). 성능 향상을 위해 제공자는 Allocate()을(를) 통해 데이터를 제공하고 Send()을(를) 통해 제로 카피(Zero-Copy)로 소유권을 전달합니다([SWS_CM_90437], [SWS_CM_90438]).

전송 보안을 위해 플랫폼은 End-to-End 보호(E2E), Freshness Value Management(FVM)를 통한 암호화 인증(SecOC), 클래식 네트워크를 위한 Signal-to-Service-Translation을 통합합니다([SWS_CM_90420], [SWS_CM_11288], [SWS_CM_10174], SWS_CommunicationManagement 222쪽). 오류 상태는 ComErrorDomain 및 ComE2EErrorDomain과(와) 같은 타입 안전한 오류 도메인을 통해 표준화된 방식으로 시그널링됩니다([SWS_CM_10432], [SWS_CM_10474]). 서비스와의 연결이 끊어지면 프록시의 상태가 kSubscriptionPending(으)로 변경되며, 다시 사용 가능해지면 미들웨어가 내부 주소 지정을 투명하게 업데이트하여 프록시를 다시 인스턴스화하지 않고도 통신을 재개합니다(ARAComAPI 32쪽).

자세히 ›

서비스 지향 통신의 역할 및 시스템 아키텍처

Functional Cluster Communication Management(ara::com)는 AUTOSAR Adaptive Platform의 정보 기술 중추를 형성하며 격리된 애플리케이션 프로세스 간 및 ECU 경계를 넘어 서비스 지향 통신(Service-Oriented Architecture, SOA)을 구현합니다(SWS_CommunicationManagement 55쪽). 핵심 원칙은 엄격한 프록시-스켈레톤 디자인 패턴입니다(ARAComAPI 1쪽): 모델 기반 코드 생성기는 정형 소프트웨어 인터페이스 설명(Service Interfaces)으로부터 서비스 소비자를 위한 형식화된 프록시 클래스와 서비스 제공자를 위한 스켈레톤 클래스를 생성합니다([SWS_CM_00130], [SWS_CM_00131]). 애플리케이션 로직은 이러한 추상화와만 상호작용하며, SOME/IP, IPC 또는 DDS와 같은 프로토콜별 바인딩 및 그 직렬화는 통합 및 배포 시점에 비로소 연결됩니다(AUTOSAR_AP_EXP_ARAComAPI 124쪽).

플랫폼 요구사항을 충족하기 위해 ara::com은(는) 다른 기능 클러스터들과 긴밀히 협력합니다(SWS_CommunicationManagement 34쪽). 런타임 시 Execution Management는 프로세스 수명 주기를 모니터링하며, Identity and Access Management(IAM)는 정책 기반 접근 검사(Policy Decision Point)를 통해 Method, Event 및 Field 레벨의 무단 상호작용을 차단합니다(SWS_CommunicationManagement 215쪽). 또한 보안 이벤트는 침입 탐지 시스템 매니저(IdSM)의 EventReporter로 직접 보고됩니다(SWS_CommunicationManagement 34쪽).

컨텍스트 다이어그램: ara::com의 임베딩 및 바인딩을 통한 애플리케이션 계층 분리. 출처: SWS_CommunicationManagement 55쪽, ARAComAPI 1쪽

프록시 및 스켈레톤을 통한 서비스 검색 및 인스턴스화

동적 서비스 검색(Service Discovery)은 로컬 및 분산 통신 관계의 형성을 제어합니다(SWS_CommunicationManagement 67쪽). 서비스 프로바이더는 스켈레톤에서 OfferService()을(를) 호출하여 가용성을 알립니다([SWS_CM_00101]). 서비스가 종료되거나 제공이 철회되면 StopOfferService()이(가) 오퍼를 철회합니다([SWS_CM_00111]). 컨슈머는 FindService()을(를) 통해 동기식으로 또는 StartFindService()을(를) 통해 비동기식으로 적합한 서비스 인스턴스를 찾습니다([SWS_CM_00122], [SWS_CM_00123], ARAComAPI 103쪽). 후자는 FindServiceHandler을(를) 등록하여 StopFindService()을(를) 통해 검색이 명시적으로 종료될 때까지 인스턴스 구성이 변경될 때마다 알림을 받습니다([SWS_CM_00125], [SWS_CM_00383]).

소스 코드를 고정된 네트워크 및 인스턴스 ID로부터 분리하기 위해, 인터페이스는 ara::core::InstanceSpecifier을(를) 사용한 추상 모델 경로 기반 주소 지정을 허용합니다([SWS_CM_00622], [SWS_CM_00623], AUTOSAR_AP_EXP_ARAComAPI 124쪽). 미들웨어는 구성된 Service Instance Manifest를 통해 이러한 지정자를 구체적인 ara::com::InstanceIdentifier(으)로 해석합니다([SWS_CM_00118], [SWS_CM_11520], ARAComAPI 1쪽). 검색된 서비스는 ServiceHandleContainer 내에서 타입이 지정된 설명자(HandleType)(으)로 제공됩니다([SWS_CM_10383], AUTOSAR_EXP_SensorInterfaces 16쪽). 정적 팩토리 메서드 Proxy::Create() 또는 생성자를 통해 컨슈머는 추가적인 기능 사용을 위한 바인딩된 프록시 인스턴스를 생성합니다([SWS_CM_10438], [SWS_CM_00131]).

시퀀스 다이어그램: 서비스 제공, 비동기 검색 및 프록시 생성 흐름. 출처: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces 16쪽

상호작용 패턴: 메서드 호출 및 비동기 처리

메서드 호출은 동기 및 비동기 요청-응답 패러다임을 나타냅니다. 클라이언트는 프록시에서 함수 호출 연산자 operator()을(를) 통해 메서드를 트리거합니다([SWS_CM_00196]). 기본 반환 타입으로는 결과 또는 오류 상태를 캡슐화하는 ara::core::Future이(가) 사용됩니다([SWS_CM_00191], ARAComAPI 1쪽). 컨슈머는 동기화 방식을 유연하게 결정할 수 있습니다: get()을(를) 통한 블로킹 조회, wait_for() 또는 wait_until()을(를) 통한 타임아웃 감시 대기, 혹은 then()을(를) 통한 이벤트 기반 콜백 루틴 등록을 활용합니다(ARAComAPI 1쪽). 피드백이 없는 순수 단방향 알림을 위해 void를 반환하는 파이어 앤 포겟(Fire-and-Forget) 메서드도 존재합니다([SWS_CM_90434], [SWS_CM_90435]).

프로바이더 측에서는 MethodCallProcessingMode이(가) 수신 호출에 대한 실행 전략을 정의합니다([SWS_CM_00301], [SWS_CM_00130]). 이벤트 구동 모드(kEvent 또는 kEventSingleThread)에서는 미들웨어가 관리하는 워커 스레드 내에서 메서드 호출이 즉시 실행됩니다(AUTOSAR_SWS_CommunicationManagement 60쪽). 폴링 모드(kPoll)에서는 애플리케이션이 주기적으로 ProcessNextMethodCall()을(를) 호출하여 처리 시점을 결정론적으로 자체 제어합니다([SWS_CM_00199], EXP_SWArchitecture 68쪽). 메서드 구현은 내부적으로 ara::core::Promise을(를) 통해 결과를 생성하고 연계된 Future를 반환합니다(ARAComAPI 1쪽).

시퀀스 다이어그램: kPoll 및 kEvent 디스패칭 하에서의 프록시와 스켈레톤 간 메서드 호출. 출처: [SWS_CM_00196], [SWS_CM_00199], AUTOSAR_SWS_CommunicationManagement 60쪽

발행-구독 패턴에서의 이벤트 및 필드 통신

연속적인 데이터 스트림 및 상태 변경의 배포는 발행-구독 패턴의 이벤트 및 필드를 통해 이루어집니다(SWS_CommunicationManagement 67쪽). 활성 구독자는 유지할 최대 샘플 수(maxSampleCount)를 지정하여 Subscribe()을(를) 통해 수신 의사를 등록합니다([SWS_CM_00141], [SWS_CM_12002]). 구독 상태는 GetSubscriptionState()을(를) 통해 조회하거나 SetSubscriptionStateChangeHandler()을(를) 통한 콜백으로 비동기 모니터링됩니다([SWS_CM_00310], [SWS_CM_00316], [SWS_CM_01110]). 구독 해제는 Unsubscribe()을(를) 통해 수행됩니다([SWS_CM_00151]).

데이터 수신은 SetReceiveHandler()을(를) 통한 이벤트 구동 방식 또는 수신 버퍼의 주기적 판독을 통해 이루어질 수 있습니다([SWS_CM_00181], [SWS_CM_11356]). 컨슈머는 GetNewSamples()을(를) 사용하여 도착한 각 샘플에 대해 타입이 지정된 SamplePtr(으)로 호출되는 함수 객체(람다)를 전달합니다([SWS_CM_00701], [SWS_CM_11610]). 복사 오버헤드를 방지(Zero-Copy)하기 위해 스켈레톤은 Allocate()을(를) 통해 메모리를 할당하고 전송 계층으로 Send()을(를) 통해 완전한 소유권 이전과 함께 타입이 지정된 포인터 SampleAllocateePtr을(를) 전송합니다([SWS_CM_90438], [SWS_CM_90437], [SWS_CM_00308], AUTOSAR_EXP_ARAComAPI 63쪽, ARAComAPI 1쪽).

필드는 이벤트 개념을 Getter 및 Setter 시맨틱으로 확장합니다(AUTOSAR_EXP_ARAComAPI 68쪽). 컨슈머는 Get()을(를) 통해 필드를 읽거나 Set()을(를) 통해 필드를 씁니다([SWS_CM_00112], [SWS_CM_00113]). 서버 측에서는 이러한 요청을 RegisterGetHandler() 및 RegisterSetHandler()(으)로 각각 처리합니다([SWS_CM_00114], [SWS_CM_00116]). 서버가 Update()을(를) 통해 상태를 업데이트하면, 필드는 자동으로 알림자(Notifier) 역할을 수행하여 등록된 모든 구독자에게 변경 사항을 배포합니다([SWS_CM_00119], ARAComAPI 1쪽).

시퀀스 다이어그램: 제로 카피 할당, 이벤트 발행, 구독 및 GetNewSamples 소비. 출처: [SWS_CM_00141], [SWS_CM_00701], [SWS_CM_90437], AUTOSAR_EXP_ARAComAPI 63쪽

보안, 서비스 변환 및 플랫폼 통합

안전 관련 및 결정론적 데이터 흐름을 위해 ara::com은(는) AUTOSAR 표준에 따른 종단 간 보호(E2E) 및 인증을 통합합니다(AUTOSAR_AP_TR_SystemTests 132쪽). 컨슈머는 GetProfileCheckStatus() 및 GetE2EStateMachineState()을(를) 통해 수신된 데이터의 무결성 및 유효성 검사 상태를 확인할 수 있습니다([SWS_CM_90420], [SWS_CM_90421], [SWS_CM_11554]). 서버 측에서 애플리케이션은 SetTransportFaultConditionHandler()을(를) 통해 오류 처리 루틴을 등록하여 메서드 수준의 E2E 및 전송 결함에 표준화된 방식으로 대응합니다([SWS_CM_00093], [SWS_CM_00094], [SWS_CM_00100], EXP_SWArchitecture 68쪽).

외부 메시지의 암호화 무결성 및 신뢰성은 Secure Onboard Communication(SecOC)을 통해 보장됩니다(SWS_CommunicationManagement 222쪽). 이를 위해 미들웨어는 교체 가능한 Freshness Value Management 라이브러리(FVM)를 통합하며, 이는 GetRxFreshness(), GetTxFreshness() 및 Initialize()을(를) 통해 신선도 값을 관리합니다([SWS_CM_11288], [SWS_CM_11289], [SWS_CM_11290], SWS_CommunicationManagement 226쪽). 진단 및 보안 기능은 SetVerificationStatus()과(와) 같은 특정 인터페이스를 통해 검증을 모니터링하거나 제어합니다([SWS_CM_19999], AUTOSAR_AP_EXP_SWArchitecture 70쪽).

AUTOSAR Classic Platform과의 상호운용성을 위해 ara::com은(는) 신호 기반 통신(Signal-to-Service Translation)을 지원합니다(SWS_CommunicationManagement 146쪽, TPS_ManifestSpecification 476쪽). [SWS_CM_10174] 및 [SWS_CM_80001]에 따라 클래식 신호 I-PDU와 SOME/IP 메시지는 동일한 소켓을 통해 전송될 수 있습니다. 신호 기반 SecOC 구성이 존재하는 경우, 미들웨어는 매니페스트의 PDU 트리거링에서 직접 보안 파라미터를 읽어옵니다([SWS_CM_11346], SWS_CommunicationManagement 228쪽).

액티비티 다이어그램: 수신 메시지의 E2E 및 SecOC 보호 파이프라인. 출처: [SWS_CM_90420], [SWS_CM_11288], SWS_CommunicationManagement 222쪽

오류가 발생한 경우의 동작

ara::com의 오류 관리는 AUTOSAR 코어 프레임워크의 타입 안전한 오류 도메인 및 반환 코드를 기반으로 합니다([SWS_CM_11334], [SWS_CM_11335]). 일반 통신 계층의 오류는 ComErrorDomain에 그룹화되며 열거자 ComErrc을(를) 통해 인코딩됩니다([SWS_CM_10432]). E2E 검증 오류 시 ComE2EErrorDomain은(는) 열거형 값 ComE2EErrc을(를) 통해 체크섬 불일치 또는 유효하지 않은 카운터와 같은 특정 검사 오류를 알립니다([SWS_CM_10474], [SWS_CM_12510], [SWS_CM_12511]). SecOC 신선도 오류의 경우에도 유사하게 ComSecOcFvmErrc을(를) 포함하는 ComSecOcFvmErrorDomain이(가) 존재합니다([SWS_CM_12521], [SWS_CM_12522]).

런타임 중 연결 끊김이 발생하면 프록시의 구독 상태가 kSubscribed에서 kSubscriptionPending(으)로 전환됩니다([SWS_CM_00310], [SWS_CM_00316], ARAComAPI 32쪽). 이 단계에서 메서드 호출은 오류와 함께 실패합니다. 이후 서비스 프로바이더가 Service Discovery를 통해 복귀하면, 미들웨어는 컨슈머가 프록시 객체를 다시 인스턴스화할 필요 없이 프록시의 내부 주소 지정을 투명하게 업데이트하며, 성공적인 재동기화 후 상태는 자동으로 kSubscribed(으)로 복귀합니다(ARAComAPI 32쪽). 시간 제한 및 마감 시간 모니터링(Deadline Monitoring)은 시스템 명세에 따라 애플리케이션 소프트웨어가 직접 담당합니다(TPS_ManifestSpecification 504쪽).

상태 다이어그램: 프로바이더 가용성 변경 시 프록시 인스턴스의 수명 주기 및 연결 상태. 출처: [SWS_CM_00310], [SWS_CM_00316], ARAComAPI 32쪽

더 자세한 증거

주요 요구사항 및 시스템 인터페이스는 AUTOSAR 사양에 다음과 같이 분류됩니다:

• 서비스 수명 주기 및 Discovery: 서비스 제공 및 검색 메커니즘은 [SWS_CM_00101], [SWS_CM_00111], [SWS_CM_00122] 및 [SWS_CM_00123]을(를) 기반으로 하며, 소프트웨어 아키텍처 가이드(ARAComAPI 103쪽)에 상세히 설명되어 있습니다.
• 상호작용 패러다임: 메서드 및 비동기 미래 값은 [SWS_CM_00191] 및 [SWS_CM_00196]에 표준화되어 있으며, 이벤트 구독 및 샘플 전송은 [SWS_CM_00141], [SWS_CM_00701] 및 [SWS_CM_90437]을(를) 따릅니다(SWS_CommunicationManagement 67쪽).
• 보안 및 직렬화: E2E([SWS_CM_90420]), SecOC([SWS_CM_90108], [SWS_CM_11288]) 및 Signal-to-Service-Translation([SWS_CM_10174])을 위한 보안 개념이 시스템 전반의 데이터 교환을 제어합니다(SWS_CommunicationManagement 146쪽, SWS_CommunicationManagement 222쪽).
• 매니페스트 및 타입 정의: 구조화된 데이터 타입, 선택적 필드 및 인스턴스 지정자의 매핑은 매니페스트 사양에 명시되어 있습니다(TPS_ManifestSpecification 161쪽, TPS_ManifestSpecification 458쪽).