ARINC 653

ARINC 653(Avionics Application Software Standard Interface)는 안전 필수 항공전자 실시간 운영체제(RTOS)의 시간 및 공간 분할을 위한 소프트웨어 규격이다. 이는 통합 모듈형 항공전자(IMA) 구조의 맥락에서 동일한 하드웨어 상에 서로 다른 소프트웨어 레벨을 가진 여러 애플리케이션을 탑재할 수 있도록 한다.

이 표준은 디지털 항공기 및 비행 시뮬레이터를 위한 ARINC 600 시리즈 표준의 일부이다.

개요

실시간 운영체제 플랫폼을 애플리케이션 소프트웨어와 분리하기 위해, ARINC 653은 APEX(APplication EXecutive)라고 불리는 API를 정의한다.

각 애플리케이션 소프트웨어는 파티션(partition)이라고 불리며 고유한 메모리 공간을 가진다. 또한 APEX API에 의해 할당된 전용 시간 슬롯을 갖는다. 각 파티션 내에서는 멀티태스킹이 허용된다. APEX API는 파티션, 프로세스 및 타이밍 관리 서비스뿐만 아니라 파티션/프로세스 간 통신 및 오류 처리 서비스를 제공한다. 분할 환경은 파티션을 가상 머신에 매핑하기 위해 하이퍼바이저를 사용하여 구현될 수 있으나, 이것이 필수 사항은 아니다.

이 표준은 에어버스와 보잉의 대표단이 공동 의장을 맡고 있는 AEEC APEX 소위원회에서 감독한다. 고든 푸치(Gordon Putsche)는 2002년부터 2023년까지 보잉 측 의장을 맡았다. 스티븐 H. 반더리스트(Steven H. VanderLeest)가 현재 보잉 측 의장이며, 피에르 가브릴로(Pierre Gabrilot)가 현재 에어버스 측 의장이다.

역사

초기 버전

ARINC 653의 초기 버전은 1996년 10월 10일에 발표되었다.

ARINC 653-1

보충판(Supplement) 1은 1997년 1월에 발표되었으며 APEX와 시간 및 공간 분할의 개념을 도입했다.

ARINC 653-2

보충판 2는 2006년 3월에서 2007년 1월 사이에 3개 부분으로 나뉘어 발표되었다.

  • 파트 1 (필수 서비스): ARINC 653 파티션 관리, 콜드 스타트 및 웜 스타트 정의, 애플리케이션 소프트웨어 오류 처리, ARINC 653 준수, 에이다 및 C 언어 바인딩.
  • 파트 2 (선택 서비스): 파일 시스템 접근, 데이터 로깅, 서비스 접근점(SAP) 등.
  • 파트 3 (적합성 테스트 규격).

표준의 현재 구성

  • 파트 0 - ARINC 653 소개 (현재 개정판 3, 2021년 11월 출시)
  • 파트 1 - 필수 서비스 (현재 보충판 6, 2024년 12월 출시)
  • 파트 2 - 확장 서비스 (현재 보충판 5, 2024년 12월 출시)
  • 파트 3A - 필수 서비스에 대한 적합성 테스트 규격 (현재 개정판 2, 2021년 11월 출시)
  • 파트 3B - 확장 서비스에 대한 적합성 테스트 규격 (현재 개정판 c1, 2019년 7월 출시)
  • 파트 4 - 서브셋 서비스 (현재 개정판 0, 2012년 6월 출시)
  • 파트 5 - 핵심 소프트웨어 권장 기능 (현재 개정판 1, 2019년 8월 출시)

파티셔닝의 기본 원칙

ARINC 653 플랫폼

ARINC 653 플랫폼은 다음을 포함한다:

  • 실시간 컴퓨팅 결정론적 서비스를 허용하는 하드웨어 플랫폼.
  • 플랫폼(메모리, CPU, 입출력)의 시간 및 공간 분할 제약 조건을 관리하는 추상화 계층.
  • ARINC 653 서비스의 구현체 (APEX API).
  • 플랫폼 및 사용 영역을 구성할 수 있는 인터페이스.
  • 다양한 계측 도구.

초기화

ARINC 653 파티션의 초기화는 파티션에서 사용하는 자원을 생성한다. 자원 생성(PROCESS, EVENT, SEMAPHORE 등)은 CREATE_xxxx라는 이름의 API 서비스를 호출하여 수행된다.

오류 처리

프로세스 오류 처리기(error handler)는 파티션 예외를 처리하기 위해 전용으로 할당된 가장 높은 우선순위의 선점형 프로세스이다. 이는 파티션 초기화 중에 CREATE_ERROR_HANDLER 서비스에 의해 생성된다.

API는 오류 처리기가 결함이 있는 프로세스를 중지할 수 있도록 허용한다(STOP_SELF). 이 경우, RTOS 스케줄러는 다음으로 높은 우선순위를 가진 프로세스를 선택한다.

ARINC 653은 오류 처리기가 결함 프로세스를 중지하지 않을 경우 스케줄러가 어떻게 동작해야 하는지 명시하지 않는다. 일부 (이론적인) 사례에서 이는 결함 프로세스와 오류 처리기 사이의 무한 루프로 이어질 수 있다.

오류 처리기는 예외의 원인과 문맥에 대한 정보를 얻을 수 있다.

모드 관리

각 파티션은 여러 활성화 모드에 있을 수 있다:

  • COLD_START 및 WARM_START: 초기화 프로세스만 실행된다.
  • NORMAL: 초기화 프로세스가 중지되고, 다른 파티션 프로세스들이 우선순위에 따라 RTOS 스케줄러에 의해 호출된다.
  • IDLE: 어떤 프로세스도 실행되지 않는다. 그러나 구현 상 이론적으로는 무한 루프를 시작하기 위해 가장 낮은 우선순위의 숨겨진 프로세스를 실행할 수도 있다.

SET_PARTITION_MODE 서비스는 이러한 상태들을 관리할 수 있게 해준다. 이 서비스는 파티션 내의 어떤 프로세스에 의해서도 호출될 수 있다. IDLE 상태로 진입하는 것은 파티션 입장에서 가역적이지 않다. 파티션이 이 상태에 있을 때는 외부 이벤트(플랫폼 재시작 등)만이 상태를 다른 모드로 변경할 수 있다.

파티션 및 프로세스 스케줄링

이 표준은 2단계 계층적 스케줄을 정의한다. 첫 번째 단계는 파티션을 스케줄링한다. 이는 주요 시간 프레임(Major Time Frame)을 반복하는 라운드 로빈 방식의 고정된 스케줄이다. 주요 시간 프레임은 주요 시간 프레임의 시작점으로부터 고정된 파티션 시간 윈도 오프셋(Partition Time Window Offset)을 가진 고정된 기간의 파티션 시간 윈도(Minor Time Frame이라고도 함)에 각 파티션을 할당한다.

ARINC 653 파티션 스케줄

파티션 시간 윈도 동안, 두 번째 단계의 스케줄링인 프로세스 스케줄링이 사용된다. 각 파티션은 적어도 하나의 프로세스를 갖는다. 파티션 시간 윈도 내에서의 프로세스 스케줄링은 선점형이다. 스케줄러는 타이머 또는 API 서비스에 의해 호출된다.

멀티코어

ARINC 653 P1-5는 멀티코어 프로세서 아키텍처를 다루기 위해 업데이트되었다. 섹션 4.2.1 "O/S 멀티코어 구현 준수"에서는 멀티코어 처리를 위해 설계된 OS가 다음 두 가지 경우를 지원해야 한다고 명시한다:

  • 단일 파티션에 의한 여러 코어 사용 (프로세스가 여러 코어에 걸쳐 실행됨)
  • 여러 파티션에 의한 여러 코어 사용

포지션 페이퍼 CAST-32A는 FAA가 민간 항공에서 멀티코어 프로세서를 인증하고 사용하기 위해 충족해야 하는 일련의 요구 사항과 지침을 정의하며, 이는 자문 회람(Advisory Circular) AC 20-193으로 대체될 예정이다. 유럽 연합 항공 안전국인 EASA는 2022년 1월에 AMC 20-193을 발표했다.

API 서비스

ARINC 653 APEX 서비스는 여섯 가지 범주에 속하는 API 호출이다:

파티션의 메모리 관리를 위한 ARINC 653 서비스는 제공되지 않는다. 각 파티션은 (ARINC 653에 의해 강제되는 메모리 분할 제약 하에서) 자체 메모리를 관리해야 한다.

각 서비스는 호출 성공 여부를 나타내는 RETURN_CODE 값을 반환한다:

POSIX 및 ASAAC와의 연결

ARINC 653이 다루는 분야는 ASAAC Def Stan 00-74와 유사하다. 그러나 두 표준 사이에는 차이점이 존재한다.

일부 ARINC 653 (APEX) 호출은 POSIX에 해당하는 기능이 있지만, POSIX에서 정의된 방식과는 다르다.

예를 들어, ASAAC에 정의된 다음 호출은:

 receiveBuffer

ARINC 653에서는 다음과 같이 변환되며:

 RECEIVE_BUFFER()

POSIX에서는 다음과 같이 변환된다:

 recv()

대한민국

한국에서는 최초로 한국전자통신연구원(ETRI)의 차세대OS연구팀에서 개발한 Qplus-653이 있으며, 항공 SW 인증 기준인 DO-178B Level A을 만족하고 있다. 현재는 알티스트라는 국내 회사가 ARINC 653 규격을 만족하는 실시간 운영체제(RTWORKS)를 자체 개발 및 판매하고 있다.

제작업체

같이 보기

각주

  1. ↑ “ARINC 653 - An Avionics Standard for Safe, Partitioned Systems” (PDF). 윈드 리버 시스템스 / IEEE Seminar. August 2008. 2009년 10월 7일에 원본 문서 (PDF)에서 보존된 문서. 2009년 5월 30일에 확인함.
  2. ↑ VanderLeest, S. H. (2010년 10월 1일). 〈ARINC 653 hypervisor〉. 《29th Digital Avionics Systems Conference》. 5.E.2–1–5.E.2–20쪽. doi:10.1109/DASC.2010.5655298. ISBN 978-1-4244-6616-0. S2CID 5784484.
  3. ↑ “Product Focus: ARINC 653 and RTOS”. aviationtoday.com. 2004년 7월 1일. 2009년 12월 3일에 원본 문서에서 보존된 문서. 2009년 5월 30일에 확인함.
  4. ↑ “Avionics Application Software Standard Interface: ARINC Specification 653 Part 0”. Aeronautical Radio, Inc. 2019년 12월 23일. 2022년 2월 3일에 원본 문서에서 보존된 문서.
  5. ↑ “Avionics Application Software Standard Interface: ARINC Specification 653P1-6, Required Services”. SAE ITC. 2024년 12월 16일. 2025년 11월 19일에 확인함.
  6. ↑ “Avionics Application Software Standard Interface: ARINC Specification 653P2-5, Part 2, Extended Services”. SAE ITC. 2024년 12월 16일. 2025년 11월 19일에 확인함.
  7. ↑ “653P3A-2 Avionics Application Software Standard Interface, Part 3A, Conformity Test Specifications for ARINC 653 Required Services”. 《SAE ITC》. 2021년 11월 17일. 2022년 2월 4일에 확인함.
  8. ↑ “653P3Bc1 Avionics Application Software Standard Interface, Part 3B, Conformity Test Specifications for ARINC 653 Extended Services”. 《SAE ITC》. 2019년 7월 18일. 2022년 2월 4일에 확인함.
  9. ↑ “Avionics Application Software Standard Interface: ARINC Specification 653 Part 4, Subset Services”. Aeronautical Radio, Inc. 2012년 6월 1일. 2012년 8월 25일에 원본 문서에서 보존된 문서. 2013년 10월 20일에 확인함.
  10. ↑ “653P5-1 Avionics Application Software Standard Interface, Part 5, Core Software Recommended Capabilities”. 《SAE ITC》. 2019년 8월 7일. 2022년 2월 4일에 확인함.
  11. ↑ “"AMC-20 Amendment 23"”. EASA. 2022년 12월 26일. 2022년 12월 22일에 확인함.
  12. 1 2 “Flexibility and Manageability of IMS Projects” (PDF). University of York. 2008년 7월 27일에 확인함.