정의
런타임 환경(run-time environment, RTE)은 개별 컴포넌트 사이, 그리고 컴포넌트와 기본 소프트웨어 사이의 구체적인 인터페이스이며, 한 ECU 위에서 가상 기능 버스를 실현한 것이다.[1]
가상 기능 버스(virtual functional bus, VFB)는 소프트웨어 컴포넌트들이 상호작용할 수 있게 해 주는 추상 통신 메커니즘으로, 어떤 ECU와 네트워크를 쓰는지에 전혀 매이지 않은 수준에서 정의된다.[2] 이 추상 덕분에 응용과 인프라를 엄격히 갈라 놓을 수 있고, 응용을 구현하는 컴포넌트는 상대와 어떤 통신 수단으로 이어지는지에서 대체로 자유로워진다.
이 페이지는 그 추상이 실제 ECU 위에서 무엇으로 바뀌는지를 다룬다. 컴포넌트와 포트 개념 자체는 소프트웨어 컴포넌트 쪽에, 이 층 아래에 놓이는 계층 구조는 Classic 플랫폼에 있다.
ECU 안과 밖
컴포넌트들을 ECU 네트워크에 배치하면 모든 원자 컴포넌트가 어느 한 ECU에 매핑되고, 컴포넌트를 잇던 커넥터는 ECU 내부 통신 수단이나 ECU 사이 통신 수단으로 구현된다. 같은 ECU에 놓인 두 컴포넌트 사이의 연결은 그 ECU의 런타임 환경이 직접 구현하고, 원격 컴포넌트를 오가는 정보는 런타임 환경이 아래쪽 기본 소프트웨어의 통신 스택으로 라우팅한다. 로컬 비휘발성 메모리나 ECU 상태 같은 표준 서비스에 컴포넌트를 붙여 주는 것도 같은 층의 몫이다.[1]
컴포넌트에게 이 차이는 보이지 않지만 시스템에게는 보인다. 규격은 통신이 벌어지는 자리를 넷으로 갈라 놓는다 — 같은 태스크에 매핑된 runnable 사이, 같은 파티션 안의 다른 태스크 사이, 같은 ECU의 다른 파티션 사이, 그리고 다른 ECU 사이다. 뒤로 갈수록 대가가 커진다. 태스크가 달라지면 컨텍스트 전환이 끼어들고, 파티션이 달라지면 메모리 보호와 타이밍 보호의 경계를 넘어야 하며, ECU가 달라지면 본질적으로 동시적이고 신뢰성이 보장되지 않을 수 있는 통신을 지나야 한다.[3] ECU 사이 구간에서 실제로 무엇이 오가는지는 CAN 프레임처럼 해당 버스의 프레임 층위에서 다룬다.
생성 워크플로
이 층은 공급사가 손으로 짜는 코드가 아니라 도구가 뽑아내는 코드다. 출발점은 ECU와 네트워크에 무관한 VFB 뷰이고, 여기에 ECU와 네트워크의 토폴로지를 정의하고 컴포넌트를 ECU에 배치하면서 시스템으로 정제된다. 분산된 기능을 잇는 데 필요한 통신 매트릭스도 이 단계에서 도출된다. 시스템 설계가 끝나면 ECU마다 관련된 부분만 뽑아낸 ECU Extract가 만들어지고, 이것이 ECU 구성의 기반이 된다 — ECU Extract는 완전히 분해된 상태여서 원자 컴포넌트만 담는다.[2]
생성 작업 자체는 주어진 ECU 범위의 입력 XML 기술들을 읽어 산출물을 뽑는 일이다. 입력에는 ECU Extract, ECU 구성 값, 그 ECU에 올라가는 컴포넌트들의 구현 기술과 내부 거동, 기본 소프트웨어 모듈 묶음, 서비스 컴포넌트 기술이 들어간다. 산출물은 런타임 환경 소스 코드와 기본 소프트웨어 스케줄러 코드, 런타임 환경 구현 기술, 계측·캘리브레이션 지원 데이터다. 선택적인 모드에서는 운영체제 구성을 비롯한 ECU 구성에 값을 되써 넣어 통합 담당자의 반복 작업을 돕고, 최종 빌드 직전에 쓰는 엄격 모드에서는 ECU 구성이 완결된 것으로 보고 건드리지 않는다.
생성은 두 국면으로 나뉜다.[3] 계약 국면(contract phase)에서는 컴포넌트에 대한 제한된 정보 — 주로 인터페이스 정의 — 만으로 컴포넌트 타입별 응용 헤더 파일을 만든다. 이 헤더가 컴포넌트와 런타임 환경 사이의 계약이다. 생성 국면(generation phase)에서는 컴포넌트와 그 ECU 배치, 통신 연결에 관한 모든 정보를 써서 런타임 환경 자체를 만들며, 시스템의 ECU 하나마다 하나의 런타임 환경이 생성된다. 두 국면으로 나눈 덕분에 소스 코드로 납품되는 컴포넌트든 오브젝트 코드로 납품되는 컴포넌트든 같은 정의를 쓸 수 있다.
생성되는 인터페이스
생성된 함수의 이름에는 포트 이름과 그 포트를 타입 지정한 인터페이스 안의 요소 이름이 그대로 박힌다. 배포 방식과 요청·응답 방식에 각각 대응하는 함수가 나온다.[3]
| 함수 이름 | 하는 일 |
|---|---|
Rte_Write_<p>_<o> | sender-receiver 포트 <p>의 데이터 요소 <o>를 명시적으로 송신한다 |
Rte_Read_<p>_<o> | sender-receiver 포트 <p>의 데이터 요소 <o>를 명시적으로 읽는다 |
Rte_Call_<p>_<o> | 클라이언트-서버 포트 <p>의 오퍼레이션 <o>를 호출한다 |
Rte_Result_<p>_<o> | 비동기 오퍼레이션 호출의 결과를 가져온다 |
이름 규칙이 이런 모양인 데는 이유가 있다. 컴포넌트 구현은 자기 포트 이름만 알면 되고, 그 포트 반대편이 같은 ECU 안의 다른 컴포넌트인지 버스 건너편 ECU인지는 코드에 드러나지 않는다. 배치가 바뀌어도 함수 이름은 그대로 남고, 바뀌는 것은 생성된 함수의 속뿐이다.
기본 소프트웨어와의 경계
컴포넌트는 기본 소프트웨어 모듈에 직접 접근할 수 없다. 모든 통신은 AUTOSAR 인터페이스를 통해야 하고 따라서 런타임 환경의 통제 아래 놓이며, 이 제약은 운영체제와 통신 서비스를 포함한 모든 기본 소프트웨어 모듈에 적용된다.[3] 반대 방향으로, 기본 소프트웨어 모듈 자신은 ECU 추상화 계층과 다른 모듈에 직접 접근할 수 있어 ECU와 위치에 매인다 — 그래서 다른 ECU로 재배치할 수 있는 것은 컴포넌트뿐이다.
지원되는 통신은 정적 통신뿐이다. 모든 통신 연결의 출발점과 도착점이 런타임 환경을 생성하는 시점에 알려져 있어야 한다는 뜻이며, 가변성이 걸린 연결도 가능한 커넥터의 상위 집합에서 골라 쓰는 방식이라 이 제약을 벗어나지 않는다.