정의
소프트웨어 컴포넌트는 자동차 기능의 전부 또는 일부를 캡슐화하는 단위이며, 구현과 그에 딸린 형식적 컴포넌트 기술로 이뤄진다. 컴포넌트끼리는 오직 포트를 통해서만 상호작용한다.[1]
Classic 플랫폼의 응용 계층은 하나의 덩어리가 아니라 상호연결된 컴포넌트들의 조합으로 모델링된다. 이 모델이 겨냥하는 것은 재배치 가능성이다 — 컴포넌트의 구현이 상대와 어떤 통신 수단으로 이어지는지에 거의 매이지 않게 해 두면, 같은 컴포넌트를 다른 ECU에 옮겨 놓아도 코드가 흔들리지 않는다.[1]
불투명한 구현 단위를 정해진 규칙 아래 조립한다는 발상 자체는 컴포넌트 기반 아키텍처의 일반 원리다. 이 페이지는 AUTOSAR가 그 원리를 어떤 구조물로 못박았는지를 다룬다. 컴포넌트를 실제 ECU 위에서 이어 주는 층은 런타임 환경이 맡는다.
포트와 포트 인터페이스
포트는 컴포넌트가 바깥과 만나는 유일한 지점이고, 하나의 포트는 정확히 하나의 컴포넌트에 속한다. 포트의 성격은 두 축으로 정해진다.[1]
첫째 축은 방향이다. PPort는 포트 인터페이스가 정의한 요소들을 제공하고, RPort는 그것들을 요구하며, PRPort는 둘을 겸한다. 어떤 포트가 셋 중 무엇인지는 구성 시점에 확정된다.
둘째 축은 계약이다. 포트마다 포트 인터페이스가 하나씩 붙어 그 포트가 지켜야 할 계약을 규정하고, 하나의 포트 인터페이스가 여러 포트를 타입 지정할 수 있다. 한 포트가 담을 수 있는 통신 패턴이 하나로 제한되는 것도 이 규칙 때문이다 — 그래야 어떤 포트끼리 이어도 되는지가 결정되고 데이터 흐름을 모델링할 수 있다. 표준이 정의하는 포트 인터페이스는 클라이언트-서버와 sender-receiver 외에도 파라미터 인터페이스, 비휘발성 데이터 인터페이스, 트리거 인터페이스, 모드 전환 인터페이스가 있다.
커넥터
통신이 필요한 포트들은 조립 커넥터(assembly connector)로 잇는다. 하나의 커넥터는 정확히 하나의 PPort 또는 PRPort를, 정확히 하나의 RPort 또는 PRPort에 연결한다. 커넥터로 이어지지 않은 포트 사이에는 통신이 성립하지 않으며, 구성 시점에 가상 기능 버스(virtual functional bus) 위 컴포넌트 사이의 모든 통신 가능성은 커넥터의 존재로 모델링된다.[1]
다중도는 패러다임에 따라 다르다. 두 패러다임 모두 하나의 PPort를 여러 RPort에 이을 수 있어, 각각 멀티캐스트 송신과 한 서버에 붙는 여러 클라이언트가 된다. 반대 방향인 여러 PPort를 하나의 RPort에 잇는 것은 sender-receiver에서만 허용되며, 여러 송신자가 만든 정보를 한 수신자가 모으는 경우를 위한 것이다.
포트가 이어지지 않은 채 남는 것이 반드시 설계 실수인 것은 아니다. 데이터를 제공할 응용이 아직 없고 초기값만으로도 동작할 수 있거나, 가변성 때문에 한쪽 끝이 시스템에서 빠진 경우가 있다. 이어지지 않은 sender-receiver RPort는 초기값을 내주면서 미연결 상태를 보고해야 하고, 이어지지 않은 클라이언트-서버 PPort의 서버는 어떤 요청도 받지 못한다.
두 통신 패러다임
sender-receiver 인터페이스는 가상 기능 버스 위에서 오가는 데이터 요소들의 집합을 정의한다. 송신자는 수신자의 정체도 수도 모르고, 수신자가 있든 없든 거동이 달라지지 않는다 — 송신자는 정보를 내놓기만 하고 그것을 언제 어떻게 쓸지는 수신자가 자율적으로 정하며, 배포는 통신 인프라의 책임이다. 데이터 요소는 구성 시점에 두 의미론 중 하나로 정해진다. last-is-best 요소는 항상 현재 값을 하나 갖고 새 값이 이전 값을 덮어쓰며, queued 요소는 송신자가 내놓은 연속된 값들이 정해진 길이의 큐에 쌓인다.[1]
클라이언트-서버 인터페이스는 서버가 구현하고 클라이언트가 호출하는 오퍼레이션들의 집합을 정의한다. AUTOSAR가 정의하는 것은 아주 단순한 정적 n대 1 메커니즘이다 — 서버 하나에 클라이언트가 0개 이상 붙으며, 브로커에 서비스를 등록하고 동적으로 구독하는 식의 구조는 들어 있지 않다. 클라이언트는 호출마다 정확히 하나의 응답을 받고, 그 응답은 유효한 서버 응답이거나 응용 오류이거나 인프라 오류다. 클라이언트가 동기 방식을 고르면 오퍼레이션을 호출한 실행 조각은 응답이 오거나 인프라 오류가 나거나 설정된 최대 블로킹 시간이 지날 때까지 블록된다.
오류가 두 갈래로 나뉘는 것은 두 패러다임에 공통이다. 인프라 오류는 송수신 또는 클라이언트-서버 사이의 인프라가 실패했을 때 반환되며 종류가 표준화되어 있고, 타임아웃이 전형적인 예다. 응용 오류는 응용마다 다르므로 해당 포트 인터페이스 안에 정의해 두어야 한다.
컴포지션과 원자 컴포넌트
컴포넌트와 커넥터로 이뤄진 하위 시스템은 컴포지션(composition)으로 묶인다. 컴포지션 자체가 하나의 컴포넌트 타입이어서 자기 포트를 가질 수 있고, 그래서 계층을 임의의 깊이로 쌓을 수 있다. 컴포지션 안에서 어떤 컴포넌트 타입이 쓰인 것을 프로토타입(prototype)이라 부르며, 한 컴포넌트 타입은 가상 기능 버스 위에서 여러 번 인스턴스화될 수 있다 — 좌우 좌석의 열선을 각각 제어하는 두 인스턴스가 코드는 공유하면서 내부 상태는 따로 갖는 식이다.[1]
컴포지션과 대비되는 것이 원자(atomic) 컴포넌트다. 원자라는 말은 더 작은 컴포넌트로 쪼갤 수 없다는 뜻이고, 그래서 반드시 하나의 ECU에 통째로 매핑된다. 원자 컴포넌트는 다시 여러 종류로 갈리는데, 응용의 일부를 구현하며 모든 통신 수단과 서비스를 쓸 수 있는 응용 컴포넌트, 센서·액추에이터 하드웨어를 다루는 센서-액추에이터 컴포넌트, 표준 서비스를 제공하는 서비스 컴포넌트, ECU 하드웨어 접근을 제공하는 ECU 추상화 컴포넌트, 그것을 일반화한 복합 드라이버 컴포넌트 등이 있다.
runnable
컴포넌트의 실제 구현은 runnable 엔티티(runnable entity)의 집합이다. runnable은 컴포넌트가 제공하는 명령열이며 런타임 환경이 시작시킨다.[1] 규격은 runnable을 원자 컴포넌트가 제공하는 가장 작은 코드 조각으로 정의한다.[2] 컴포넌트 하나가 runnable 하나만 가질 수도 있고 아주 많이 가질 수도 있으며, 어떤 runnable이 있는지는 구성 시점에 알려져 있어야 한다.
runnable을 언제 부를지는 컴포넌트가 요구 사항으로 적어 둔다. 주기적으로 돌아야 하는 runnable은 타이밍 이벤트에 걸리고, 그 이벤트에는 초 단위 주기와 첫 활성화의 오프셋이 붙는다. 통신과 관련된 사건 — 예컨대 다른 컴포넌트가 자기 PPort의 오퍼레이션을 호출하는 것 — 이나 물리적 사건에 반응해 도는 runnable도 있다.
여기서 설계 관점의 개념이 구현 관점으로 내려앉는다. runnable은 태스크의 컨텍스트에서 실행되며, 태스크가 스택 같은 공용 자원을 runnable에 제공한다. 어느 시점에 어떤 태스크가 CPU를 쓸지 정하는 것은 운영체제 스케줄러이고, 스케줄러가 쓰는 전략에는 우선순위 기반 선점이나 시간 구동 등 여러 표준적인 선택지가 있다. 컴포넌트가 요구한 주기가 태스크의 주기와 우선순위로 바뀌는 과정은 runnable 태스크 매핑에서, 태스크 객체 자체는 OSEK 태스크에서 다룬다.