모듈 ara::nm — Network Management

기능 클러스터 Network Management는 State Management가 논리적 네트워크 핸들, 부분 네트워크 및 물리적 통신 채널을 조정하여 요청하고 해당 상태를 조회할 수 있도록 인터페이스를 제공합니다([SWS_ANM_01000], EXP_SWArchitecture 77쪽). 클래스 NetworkHandle를 통해 kNoCom과 kFullCom 사이의 목표 상태 및 실제 상태가 제어되며 비동기 노티파이어가 등록됩니다([SWS_ANM_01009], [SWS_ANM_01010], [SWS_ANM_01358]). 인터페이스 사용은 State Management에 독점적으로 제한되며, 오류는 NmErrorDomain을 통해 일관되게 보고됩니다([SWS_ANM_01101], [SWS_ANM_01111]).

자세히 ›

기능 클러스터 Network Management(NM)는 통신 네트워크 및 부분 네트워크의 요청과 상태 모니터링을 위한 메커니즘을 AUTOSAR Adaptive Platform에 제공합니다. 프로그래밍 인터페이스는 기능 클러스터 State Management 전용으로 제공되며, State Management는 클래스 NetworkHandle의 논리적 인스턴스를 통해 네트워크 리소스를 제어하고 Ethernet 또는 CAN과 같은 물리적 버스 구조로부터 디커플링됩니다([SWS_ANM_01000], EXP_SWArchitecture 77쪽, EXP_PlatformDesign 60쪽).

컨텍스트 다이어그램: State Management와 물리적 네트워크 계층 간의 Functional Cluster Network Management 시스템 통합. 출처: SWS_NetworkManagement 13쪽, EXP_PlatformDesign 60쪽, [SWS_ANM_01000]

NetworkHandle은 ara::core::InstanceSpecifier을 통해 초기화되고 이동 연산을 지원하지만 복사 생성자와 복사 대입은 삭제되어 있습니다([SWS_ANM_01001], [SWS_ANM_01003], [SWS_ANM_01005]). 모듈은 설정된 요청 상태(SetNetworkRequestedState, GetNetworkRequestedState)와 실제 활성 네트워크 상태(GetNetworkState)를 구분하며, 각각은 상태 kNoCom 및 kFullCom을 갖는 NetworkStateType로 표현됩니다([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01358]).

시퀀스 다이어그램: 노티파이어 등록, 상태 요청 및 상태 조회 시의 상호작용 흐름. 출처: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement 38쪽

상태 변경의 비동기 시그널링을 위해 – 선택적으로 자체 실행자를 포함하여 – RegisterNetworkStateChangeNotifier 또는 RegisterNetworkRequestedStateChangeNotifier을 통해 콜백을 등록할 수 있습니다([SWS_ANM_01010], [SWS_ANM_01014], [SWS_ANM_01020]). 오류는 NmErrorDomain 및 NmErrc을 통해 보고되며, kServiceNotAvailable 및 kInvalidHandler과 같은 표준화된 코드는 장애 및 잘못된 구성의 결정론적 처리를 보장합니다([SWS_ANM_01101], [SWS_ANM_01111]).

자세히 ›

시스템적 역할 및 기능적 아키텍처 범위 분리

기능 클러스터 Network Management(NM)는 AUTOSAR Adaptive Platform 내에서 통신 네트워크 및 부분 네트워크(Partial Networks, PN)의 통합 관리를 제공합니다. 모듈의 프로그래밍 인터페이스는 임의의 Adaptive Applications를 대상으로 하지 않고, 필요에 따라 통신 기능을 요청하거나 해제할 수 있도록 기능 클러스터 State Management(SM)를 위해 특별히 제공됩니다([SWS_ANM_01000], EXP_SWArchitecture 77쪽). State Management는 머신의 중앙 시스템 오케스트레이터 역할을 수행하며 기능 그룹과 플랫폼 상태를 제어하는 반면, Network Management는 실제 버스 모니터링, 부분 네트워크 로직 및 버스 Keep-Alive 상태를 캡슐화합니다(SWS_NetworkManagement 13쪽, EXP_PlatformDesign 60쪽).

아키텍처 관점에서 Network Management는 논리적 네트워크 핸들(NetworkHandle)을 통해 상위 상태 제어를 Ethernet 또는 CAN 네트워크와 같은 물리적 네트워크 토폴로지로부터 디커플링합니다(EXP_PlatformDesign 60쪽). State Management의 네트워크 요구는 내부적으로 채널별 상태 머신 및 Partial Network State Machines(PNSM)에 매핑되어 물리적 채널에서의 통신이 동기화되고 필요에 따라 활성화되거나 중단됩니다(SWS_NetworkManagement 18쪽, SWS_StateManagement 17쪽).

컨텍스트 다이어그램: State Management와 물리적 네트워크 계층 간의 Functional Cluster Network Management 시스템 통합. 출처: SWS_NetworkManagement 13쪽, EXP_PlatformDesign 60쪽, [SWS_ANM_01000]

NetworkHandle을 통한 인스턴스화 및 리소스 관리

특정 부분 네트워크 또는 물리적 통신 채널에 대한 기능적 접근은 클래스 NetworkHandle의 인스턴스를 통해 이루어집니다([SWS_ANM_01000]). NetworkHandle는 NetworkManagementPortInterface의 할당된 포트 프로토타입을 고유하게 참조하는 ara::core::InstanceSpecifier을 전달하여 명시적으로 생성됩니다([SWS_ANM_01001]). 이 생성자를 통한 초기화는 스레드 안전한 것으로 명세되어 있습니다([SWS_ANM_01001]).

NetworkHandle의 인터페이스 설계는 엄격한 라이프사이클 및 소유권 규칙을 따릅니다: 복사 생성자와 복사 대입 연산자는 명시적으로 삭제되어(= delete), 핸들 인스턴스의 무분별한 복제가 방지됩니다([SWS_ANM_01005], [SWS_ANM_01006]). 반면 리소스를 제어된 방식으로 이전할 수 있도록 이동 생성자와 이동 대입이 제공됩니다([SWS_ANM_01003], [SWS_ANM_01004]). 해석: 복사가 금지되고 이동 연산만 허용되므로, 동일한 객체에 대한 경합적 노티파이어 등록을 배제하기 위해 아키텍처가 핸들 인스턴스당 배타적 소유권 의미론을 강제하는 것으로 보입니다. 질문 Q-912cb5d1ddff2896 (열림) 소멸자와 이동 대입은 명시적으로 스레드 안전하지 않은 것으로 정의되어 있으므로 State Management에서 핸들의 수명 주기 관리는 동기화되어 수행되어야 합니다([SWS_ANM_01002], [SWS_ANM_01004]).

통신 상태의 제어 및 조회

모듈은 네트워크 핸들의 요청된 목표 상태(Requested State)와 실제 활성 상태(Network State)를 엄격하게 구분합니다([SWS_ANM_01007], [SWS_ANM_01008]). 두 상태는 값 0을 갖는 kNoCom 및 값 1을 갖는 kFullCom의 열거형 NetworkStateType로 표현됩니다([SWS_ANM_01358]). 전체 상태는 핸들에 할당된 모든 부분 네트워크 또는 전체 네트워크가 예외 없이 통신 상태 FULL_COM에 있는 경우에만 정의상 kFullCom이며, 그렇지 않으면 상태는 kNoCom입니다([SWS_ANM_01358]).

메서드 SetNetworkRequestedState을 통해 State Management는 연관된 PNC, VLAN 또는 물리적 네트워크의 활성화(kFullCom) 또는 해제(kNoCom)를 요청합니다([SWS_ANM_01009], EXP_SWArchitecture 77쪽). GetNetworkRequestedState를 사용하면 마지막으로 설정된 요청 값을 동기적으로 조회할 수 있습니다([SWS_ANM_01008]). 반면 실제 버스 관련 작동 상태는 GetNetworkState을 통해 읽어오며, 두 조회 메서드는 모두 스레드 안전한 것으로 선언되어 있고 결과를 ara::core::Result에 캡슐화합니다([SWS_ANM_01007], [SWS_ANM_01008]).

상태 다이어그램: 기본 네트워크 상태 NetworkStateType의 상태 전이. 출처: [SWS_ANM_01358], [SWS_ANM_01007], [SWS_ANM_01009]

이벤트 기반 상태 모니터링 및 알림 메커니즘

외부 버스 노드, 메시지 타임아웃 또는 비동기 구동 시간으로 인해 네트워크 레벨의 상태 변화가 지연되어 도달하므로, NetworkHandle은 NetworkStateChangeNotifier 유형의 콜백 함수(std::function<void(const NetworkStateType&)>)를 통한 비동기 알림 메커니즘을 제공합니다([SWS_ANM_01020]). 실제 네트워크 상태의 변경에는 RegisterNetworkStateChangeNotifier가 사용되며([SWS_ANM_01010]), 요청된 상태의 변경은 RegisterNetworkRequestedStateChangeNotifier을 통해 모니터링됩니다([SWS_ANM_01012]).

핸들 및 모니터링 유형당 최대 하나의 노티파이어만 등록할 수 있으며, 이후의 각 등록 호출은 이전에 등록된 콜백을 덮어씁니다(EXP_SWArchitecture 77쪽). UnregisterNetworkStateChangeNotifier 및 UnregisterNetworkRequestedStateChangeNotifier를 사용하여 기존 등록을 명시적으로 다시 해제할 수 있습니다([SWS_ANM_01011], [SWS_ANM_01013]). 확장된 흐름 제어를 위해, 알림을 특정 실행 컨텍스트 또는 스레드에서 처리할 수 있도록 사용자 정의 실행자(ExecutorT&& executor)를 수신하는 템플릿 기반 등록 메서드를 사용할 수 있습니다([SWS_ANM_01014], [SWS_ANM_01015]).

시퀀스 다이어그램: 노티파이어 등록, 상태 요청 및 상태 조회 시의 상호작용 흐름. 출처: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement 38쪽

매니페스트 모델링 및 매핑 구성

Adaptive Application으로의 Network Management 통합은 매니페스트의 표준화된 메타모델 요소를 통해 이루어집니다. 인터페이스 NetworkManagementPortInterface은 기본 메타클래스 PortInterface을 특수화하여 클러스터와의 상호작용을 위한 정형화된 포트 프로토타입(PPortPrototype, RPortPrototype)을 정의합니다(TPS_ManifestSpecification 263쪽).

배포 매니페스트에서 애플리케이션 인스턴스와 논리적 네트워크 관리 간의 바인딩은 매핑 요소 NetworkHandlePortMapping을 통해 선언됩니다(TPS_ManifestSpecification 620쪽). 이는 프로세스 내의 포트 프로토타입(Process)을 논리적 NmNetworkHandle과 연결합니다(TPS_ManifestSpecification 620쪽). 또한 메타모델 요소 NmInteractsWithSmMapping를 통해 클러스터 State Management(StateManagementStateRequest을 통해)와 네트워크 핸들(NmNetworkHandle) 간의 조정 결합이 구속력 있게 구성됩니다(TPS_ManifestSpecification 875쪽).

메타모델 다이어그램: 포트, 프로세스, 핸들 및 State Management 간의 ARXML 구성 및 매핑 관계. 출처: TPS_ManifestSpecification 263쪽, TPS_ManifestSpecification 620쪽, TPS_ManifestSpecification 875쪽

오류가 발생한 경우의 동작

통일된 오류 처리를 위해 모듈은 AUTOSAR Adaptive 오류 아키텍처에 따른 고유한 오류 도메인을 구현합니다. 클래스 NmErrorDomain은 ara::core::ErrorDomain에서 상속되며 정적 도메인 쿼리 GetNmDomain와 식별 메서드 Name 및 Message를 통해 네트워크 관리의 오류를 식별합니다([SWS_ANM_01101], [SWS_ANM_01105], [SWS_ANM_01106], [SWS_ANM_01107], [SWS_ANM_01109]).

특정 오류 원인은 열거형 NmErrc에 정의되어 있습니다([SWS_ANM_01111]). 오류 코드 NmErrc::kServiceNotAvailable(코드 1)는 기본 플랫폼 서비스 또는 데몬에 도달할 수 없음을 나타내며, 메서드 GetNetworkState, GetNetworkRequestedState 및 SetNetworkRequestedState에서 발생할 수 있습니다([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01111]). 오류 코드 NmErrc::kInvalidHandler(코드 2)은 등록 메서드 중 하나에 유효하지 않은 노티파이어 핸들러가 전달되었을 때 보고됩니다([SWS_ANM_01010], [SWS_ANM_01012], [SWS_ANM_01014], [SWS_ANM_01015], [SWS_ANM_01111]).

오류 코드는 MakeErrorCode을 통해 일반 ara::core::ErrorCode 객체로 변환됩니다([SWS_ANM_01110]). 실행 환경에서 C++ 예외가 허용되고 구성된 경우 이러한 오류는 ThrowAsException을 통해 NmException 유형의 예외로 발생할 수 있습니다([SWS_ANM_01100], [SWS_ANM_01102], [SWS_ANM_01108]). 편의를 위해 유형 별칭 Errc 및 Exception가 제공됩니다([SWS_ANM_01103], [SWS_ANM_01104]).

더 자세한 증거

모듈의 필수 요구사항은 사양의 규범적 규정과 수반되는 아키텍처 모델을 기반으로 합니다:

• 클래스 및 인터페이스 사양: 네트워크 요청 및 상태 조회를 위한 핵심 클래스로서의 NetworkHandle([SWS_ANM_01000]~[SWS_ANM_01015]).
• 상태 정의: 네트워크 상태를 표현하기 위한 kNoCom 및 kFullCom를 포함하는 NetworkStateType([SWS_ANM_01358]).
• 오류 도메인 및 오류 코드: NmErrorDomain, NmException 및 NmErrc([SWS_ANM_01100]~[SWS_ANM_01111]).
• 아키텍처 및 매니페스트 근거: EXP_SWArchitecture 77쪽, SWS_NetworkManagement 13쪽, EXP_PlatformDesign 60쪽의 인터페이스 및 포트 정의와 TPS_ManifestSpecification 263쪽, TPS_ManifestSpecification 620쪽 및 TPS_ManifestSpecification 875쪽의 메타모델 매핑.