페이퍼요약 - ARINC 653 기반 실시간 소프트웨어 엔지니어링 by Samolej

제목: ARINC 653 기반 실시간 소프트웨어 엔지니어링(ARINC Specification 653 Based Real-Time Software Engineering)

저자: Sławomir Samolej, 폴란드

문서유형: 페이퍼(총 12페이지), 2009년

 

항공 산업의 실시간 시스템 개발 표준인 ARINC 653을 피치 각도 콘트롤 시스템 개발에 적용한 경험을 기술한 자료

---

실시간 애플리케이션 특징

• 단순한 단일태스크 임베디드 프로그램에서 대규모의 멀티태스크 분산 시스템으로 점차 진화됨
• 오늘날의 대규모 실시간 애플리케이션은 대개 실시간 운영체제(예, VxWorks, PikeOS, LynksOS, WindowsCE, Linux RTAI)를 기반으로 하며, 실시간 언어(예, Ada 2005, Spakr)로 작성된다.
• 실시간 태스크에는 예측가능한 정책(예, Rate Monotonic, Deadline Monotonic)에 따른 우선순위가 주어진다.
• 인터태스크 통신 프로토콜(Inter-task communication protocols)은 시스템이 실행 동안에 데드락(deadlocks)이나 예측불가능한 지연(unpredictable delays)에 빠지는 것을 방지한다.
• 분산 애플리케이션 간의 데이터 교환은 예측가능(predictable) 해야 한다. 

실시간 애플리케이션 개발 표준

• 실시간 시스템 개발을 덜 번거롭게 만들기 위해 여러 전문가 그룹이 현업에서 적용가능한 실시간 설계 패턴(real-time design patterns)을 제안함. 예, POSIX 표준, HOOD와 HRT-HOOD 방법론, Ada Ravenscar 프로파일
• 이 표준들은 바람직한 실시간 시스템 프로그래밍 기법을 정의하며, 부분적으로 자동 코드 생성기(automatic real-time software code generators)의 지원을 받음
• 이 실시간 설계 패턴들은 실시간 소프트웨어를 그래픽하게 설계하는 것을 허용하는 전용 소프트웨어 툴킷(예, Matlab-Simulink, SCADE SUITE, IBM Rational Rose RealTime)에도 통합됨. 특히 SCADE SUITE 툴킷은 국제 안전성 표준인 DO-178B(군사/항공우주), IEC 61508(중장비/에너지) EN 50128(철도수송), IEC 60880(원자력)에 부합하는 하드 리얼타임 시스템 소스 코드를 개발하는 것을 가능하게 함
• ARINC(AERONAUTICAL RADIO, INC) 653과 SAE(Society of Automotive Engineers) AS5506는 국제표준화기구(ISO)가 비교적 최근에 발표한 실시간 시스템 개발 표준임. 이 표준들은 완전한 대규모 분산 실시간 시스템을 생성을 가능하게 하는 새로운 추상화 계층(a new abstraction layer)을 실시간 소프트웨어 설계 프로세스에 제공함

ARINC 653 표준

• 통합 모듈식 항공전자(Integrated Modular Avionics: IMA)와 전통적인 ARINC 700-시리즈 항공전자 분야에서 사용되는 애플리케이션 소프트웨어를 위한 바탕 환경(baseline environment)을 제공하기 위해 항공 전문가들에 의해 개발됨
• ARINC 653의 일차적인 목표는 항공전자 컴퓨터 운영체제와 애플리케이션 소프트웨어 간의 범용 APEX(APplication/EXecutive) 인터페이스를 정의하는 것. ARINC 653 명세는 애플리케이션 소프트웨어와 운영체제 간의 인터페이스 요구사항을 포함하며, 또한 애플리케이션 소프트웨어가 내부 프로세싱 요소의 스케쥴링, 통신, 상태를 통제하는 것을 허용하는 서비스 목록(list of services)을 포함한다.
• ARINC 653의 근간이 되는 IMA 개념은 유럽 자본의 연구 프로젝트인 PAMELA, NEVADA, VICTORIA에서 도입되었으며, 이 프로젝트들의 결과가 IMA 1세대(IMA1G)로 알려짐
• ARINC 653 기반 소프트웨어가 A380, A400M, B787 여객기(airliners)에 구현되었으며, 최소 3개 상용 실시간 운영체제(WxWorks 653, PikeOS, LynksOS-178 RTOS)가 APEX를 제공하기 위해 업데이트 됨

ARINC 653 주요 개념

• IMA 개념에 따르면 현대식 온보드 항공전자 서브시스템(소프트웨어 애플리케이션)은 제한된 수의 표준 마이크로프로세서 장치들로 그룹되며, 이 장치들과 다른 전자 기기들은 표준 네트워크 인터페이스인 AFDX(Avionics Full Duplex Switched Ethernet)를 통해 통신한다. 지금까지는 별도의 마이크로프로세서 장치에서 실행되고 ARINC 429 기반 기기들을 통해 통신하던 애플리케이션 그룹이 이제는 하나의 하드웨어 모듈 상에서 실행되는 실시간 프로세스 집합이 된다.
• IMA는 시간에 민감하고 안전에 민감한 실시간 애플리케이션 집합(항공전자 장치들)이 하나의 마이크로프로세서 모듈 상에서 실행될 수도 있음을 가정하여 이런 수준의 위험성(criticality)을 감당하기 위한 새로운 실시간 운영체제 아키텍쳐를 제안한다(아래 그림 참조)
• ARINC 653의 주요 개념인 파티션(Partitions)은 애플리케이션을 위한 일종의 콘테이너(container)를 생성하여 애플리케이션의 실행이 공간적으로(spatially) 그리고 시간적으로(temporally) 분리되도록 보장한다. 파티션은 애플리케이션 파티션과 시스템 파티션의 2개 카테고리로 나뉨. 애플리케이션 파티션은 항공전자 애플리케이션(avionics applications)을 실행하고 APEX(APplication/EXecutive)라는 특정 인터페이스를 통해 환경과 데이터를 교환한다. 시스템 파티션은 선택적이며(optional), APEX에서 가용하지 않은 서비스(예, 디바이스 드라이버, 결함 관리)를 제공하는 것이 주 역할이다.
• APEX 인터페이스는 ARINC 653 요구사항을 충족시키고 플랫폼 독립적인 소프트웨어를 어떻게 생성하는지를 명세함. 이 인터페이스의 주요 컴포넌트로 파티션 관리, 프로세스 관리, 시간 관리, 메모리 관리, 인터파티션 통신(interpartition communication), 인트라파티션 통신(intrapartition communication), 건전성 모니터링(health monitoring)이 있다.

[ARINC 653에 따라 생성된 실시간 운영체제 구조]

ARINC 653 기반 Pitch Control 애플리케이션 개발

유럽 SCARLETT 프로젝트는 ARINC 653을 기반으로 하여 전형적인 여객기의 피치각(pitch angle)을 통제하는 분산 하드 리얼타임 애플리케이션을 생성하는 것을 목표로 함. 이 애플리케이션은 PCA(Pitch Control Application)라고 불리며, 아래와 같은 개발 단계(development steps)를 거쳐 완성되었다.

단계1 - 콘트롤 시스템 정의(Control System Definition)

• 시스템이 Load(엘리베이터)에 연결된 2개의 구동기(무브러시모터)를 통제함. 각 구동기는 아래 그림처럼 일련의 컨트롤러에 의해 통제됨. 단일 구동기 콘트롤 시스템은 내부 기류 콘트롤 루프, 속도 콘트롤 루프(PID2, PID4), 위치 콘트롤 루프(PID1, PID3)를 포함한다.
• FCA(Flight Control Algorithm): 양 구동기 통제 서브시스템을 위한 위치 요구 신호를 생성하는 감독 모듈. 조종사, 항공기, 구동기로부터 신호를 수집함. FCA 모듈은 실제 항공기 피치 각도를 사용하여 참조 신호(조종사가 이동시킨 콘트롤사이드스틱)를 수정함
• Error Estimator: 콘트롤 신호를 수집하고 런타임 동안의 콘트롤 시스템의 품질을 추정함. 또한 시스템 오퍼레이터를 위한 별도의 출력을 생성함

[Pitch control 시스템 아키텍쳐]

단계2 - 콘트롤 절차를 하드웨어 장치로 배분(Distribution of Control Procedures)

• PCA는 시스템 통합자(system integrator)가 정의한 제약조건(restrictions)에 따라 개발되었는데, 그 중 하나는 “선정된 콘트롤 절차가 여러 다른 하드웨어 모듈 상으로 할당되어야 한다”는 것임. 아래 그림에서 하드웨어 모듈 1(HM1)은 FCA, Error Estimator, 위치 콘트롤러(PID1과 PID3)를 포함하고, HM2와 HM3은 속도 콘트롤러(PID2와 PID4)를 각각 포함한다.
• 시스템 통합자가 부여한 또 다른 제약조건은 “현 컨트롤러가 반드시 모터 드라이브 하드웨어에 포함되어야 하는 반면 FCA, Error Estimator, 그리고 모든 PID 컨트롤러는 소프트웨어 모듈이어야 한다”는 것임
• 하드웨어 모듈들은 AFDX 네트워크를 통해 연결되며, 이 네트워크 구조도 시스템 통합자에 의해 부여됨
• 요구사항에 따르면 하드웨어-소프트웨어 환경이 IMA 개념을 준수해야 하므로 FCA와 Error Estimator 콘트롤 블록이 하나의 ARINC 653 애플리케이션 파티션에 속하게 된다(즉, 각각이 별도의 실시간 태스크가 됨). 모든 PID 콘트롤러도 각각 별도의 실시간 태스크가 되어 별개의 애플리케이션 파티션에 속하게 된다.

[하드웨어 장치로 할당된 Pitch 콘트롤 절차]

단계3 - 타이밍 요구사항 평가(Timing Requirements Assessment)

• PCA는 아래 그림과 표에 보여진 ARINC 653 실시간 패러미터를 충족시키도록 개발됨. 구동기 동력(actuator dynamics)과 하드웨어 장치의 컴퓨팅 파워, 이 두 가지를 모두 고려하여 데드라인(time capacity)과 태스크 주기(task periods)를 선정함
• FCA와 Error Estimator의 주기적 실시간 태스크를 포함하는 파티션은 6[ms] 타임 슬롯과 20[ms] 데드라인을 가지며, 2개의 3-millisecond 타임 프레임에서 실행된다. PID1와 PID3 콘트롤 절차를 포함한 파티션들은 매 5[ms]마다 활성화되고 1[ms] 타임 프레임 내에서 실행된다. PID2와 PID4 실시간 태스크도 매 5[ms] 마다 활성화되지만 HM2와 HM3이 HM1보다 더 낮은 컴퓨팅 파워를 제공하기 때문에 데드라인은 2[ms]로 확장된다.
• 아래 그림에서 Major 타임 프레임에 일부 “System” 슬롯들이 포함되어 있는데, 이 슬롯들은 하드웨어상에 로드된 다른 소프트웨어 모듈에 의해 사용될 수도 있다.
• 실시간 태스크 각각에는 ‘HARD’ 애트리뷰트가 부착되어 태스크가 데드라인을 놓치면 이를 운영체제에 알리고 적절한 액션을 취하도록 만든다.
• AFDX 네트워크에서 최대 통신 지연(maximum communication delay)이 7[ms]를 초과해서는 안 되는 것으로 가정함
• PCA에 적용된 알고리즘들은 컨트롤러이거나 미분방정식을 푸는 단순 수치 절차(numerical procedures)임. 개발 동안에 이 알고리즘 각각의 최고 컴퓨팅 시간(the worst case computing time)을 평가하고, 실험 체크(Experimental checks)를 통해 알고리즘이 타이밍 제약(timing constraints)을 충족시킬 수 있음을 증명함

[PCA 타이밍 요구사항]

[PCA 실시간 태스크 패러미터]

단계4 - 애플리케이션 구조 설계(Application Structure Design)

• PCA 구조를 표현한 아래 그림에서 파티션, 인트라파티션 통신, 그리고 인터파티션 통신의 구조를 볼 수 있음
• HM1에 로드된 P1 파티션에는 FCA와 Error Estimator의 2개 실시간 태스크가 포함됨. FCA 태스크는 조종사, 항공기, 구동기 모듈로부터 신호를 수집하여 위치 콘트롤러(PID1, PID3)를 위한 바람직한 피치 각도 신호를 생성함. Error Estimator는 런타임 동안의 통신 채널과 콘트롤 품질을 모니터 함. P2 파티션은 첫 위치 컨트롤 알고리즘인 PID1을 포함하고, P3 파티션은 두 번째 위치 콘트롤 알고리즘인 PID3를 포함한다. 네 번째에 있는 ‘System 파티션’은 하드웨어 모듈간에 교환되는 모든 신호를 수집하고 이를 AFDX 네트워크로 전달한다.
• 동일한 하드웨어-소프트웨어 구조를 가지는 HM2와 HM3은 하나의 시스템 파티션과 하나의 애플리케이션 파티션을 포함한다. 애플리케이션 파티션(즉, P4와 P5)은 속도 콘트롤 PID 알고리즘의 단일 실시간 태스크이며, 시스템 파티션은 하드웨어간 모듈 통신(inter-hardware module communication)을 제공한다.
• 인트라파티션 통신을 위해 ARINC 653 블랙보드(blackboards)가 적용되는 반면 인터파티션 통신은 ARINC 653 샘플링 포트와 채널을 기반으로 한다. 

[PCA 구조]

단계5 - 시스템 프로그래밍(System Programming)

• PCA가 VxWorks 653과 PikeOS 운영체제를 위한 C 언어로 구현된다(PCA 구조 생성을 위해 적용된 APEX 인터페이스가 구현됨).
• 프로그래머의 관점에서 애플리케이션 개발 동안에 정의된 각 파티션은 별도의 프로그램이며, 이 프로그램은 실시간 태스크의 집합으로 구성된다.
• 태스크는 APEX 블랙보드를 통해 데이터를 교환하고 샘플링 포트를 통해 데이터를 송신하고 수신한다. 태스크에는 타이밍 제약(Timing constraints)이 부착된다.
• 각 태스크는 메인 기능(main function)을 가지는데, 입력 통신 오브젝트(블랙보드 또는 샘플링 포트)로부터 데이터를 수집하고, 적절한 콘트롤 블록 알고리즘을 호출하고, 계산된 데이터를 출력 오브젝트로 전송하고, 최종적으로 실행을 정지(suspend)시키는 일을 한다. 이 기능은 코어 운영체제에 의해 주기적으로 활성화(activated)된다. 

단계6 – 테스팅(Testing)

• 분산된 실시간 통제 애플리케이션인 PCA의 구현 테스트에서 아래와 같은 세 개의 주요 영역이 고려됨:
  - 통신(communication)
  - 타이밍 제약(timing constraints)
  - 콘트롤 알고리즘(control algorithms)
• 먼저 애플리케이션의 통신 구조가 평가되었고 모든 채널과 데이터 구조가 체크됨
• 두 번째로 각 실시간 태스크의 최고실행시간(Worst Case Execution Time: WCET)이 측정되었고, 프로세스 레벨과 파티션 레벨 양쪽 모두에서 타이밍 제약이 충족되는지 여부가 평가됨(측정된 시간은 개발 초반에 정의된 파티션 타임 슬롯과 비교됨)
• 세 번째로 애플리케이션에 적용된 콘트롤 절차(control procedures)가 별개의 기능 블록으로서도 테스트되고 또한 협업하는 소프트웨어 모듈의 완전한 집합체로서도 테스트됨