ara::com 기초 (프록시/스켈레톤 구조)

클래식 오토사의 RTE와 유사하게 아답티브 오토사에서는 인터페이스를 추상화 및 정형화하는 개념으로 ara::com 이 정의되어 있다. 아답티브 오토사에서 각 프로세스 간 (아답티브 애플리케이션 및 오토사 컴포넌트를 포함하는)의 통신은 기본적으로 프록시/스켈레톤 구조를 따르는데, 이 구조는 이미 COBRA 같은 미들웨어에 적용된 설계 패턴으로 하위 전송 계층을 추상화한 정형화된 서비스 인터페이스를 사용자인 클라이언트와 제공자인 서버에 제공함으로써 간결한 서비스 구현을 가능하게 한다.

프록시는 서비스를 사용하는 클라이언트 개체 클래스이며, 스켈레톤은 서비스를 제공하는 서버 개체 클래스이다.

개체간 통신 서비스 구현 절차를 요약하면,

• 통신 개체간 서비스 인터페이스 정의 -> 프록시/스켈레톤 코드 생성 -> 생성 코드를 이용한 통신 개체 구현

ara:com 구현 개요, 정의된 서비스 명세에 따라 생성된 인터페이스를 사용함으로써 두 개체간 통신 방식의 일관성을 유지

서비스 인터페이스는 사전 설계된 서비스 인터페이스 명세 (예, service_interfaces.arxml)에 따라 ara::com에서 정의한 인터페이스 형태로 생성되며, 클라이언트나 서버개체 내에서 클래스 형태로 사용된다. 이때, 생성된 인터페이스는 특정 아답티브 플랫폼 스택에 의존적인지 않은 표준화된(ara:com에서 정의한) 형태로 생성되므로 오토사 SWC (Software Component) 설계 및 구현시 스택 의존성을 회피할 수 있다.

기능 관점에서의 ara::com 구조, 실제 구현시에는 각 프로세스(클라이언트, 서버)들 과 ara::com 컴포넌트 (SD, SOME/IP) 간 IPC가 존재할 수 있다.

사용되는 서비스는 하위 전송 계층의 바인딩에 따라 SOME/IP (Scalable service-Oriented MiddlewarE over IP) 나 IPC (InterProcess Communicaiton)에 연결되며, 서비스 관리를 위해 SD (Service Discovery)가 우선적으로 연결 상태를 관리하게 된다.

클라이언트와 서버가 하나의 아답티브 머신에 존재하는 경우는 아래와 같이 IPC로 서비스 통신이 이루어지고,

한 머신상에 두 개체가 존재하는 경우 IPC를 통해 통신 경로가 구축된다.

각 개체가 다른 머신상에 존재하는 경우 SOME/IP로 서비스 통신이 이루어진다.

원격지에 각 객체가 존재하는 경우, SOME/IP - SD 를 통해 통신 경로가 구축된다.

통신을 위해서는 기본적으로 아래와 같은 ara::com 통신 방식이 지원된다.

• 이벤트 (Events)
  • Publish - Subscribe 기반으로, 서버가 가용한 서비스를 공개하면 클라이언트가 해당 서비스를 가입하여 정보를 받는 방식
• 메서드 (Methods)
  • Remove procedure Call 기반으로, 필요시 클라이언트가 해당 서비스를 요청하고 서버에게 응답을 요청하는 방식
• 필드 (Fields)
  • 메서드와 유사하지만,  get/set 메서드를 통해 원격지상의 필드 데이터만을 접근하는 방식