페이퍼요약 - 임베디드 항공 시스템의 소프트웨어 테스팅 by ISPRAS

제목: 임베디드 항공 시스템의 소프트웨어 테스팅(Software Testing for Embedded Avionics Systems)

저자: ISPRAS(Institute for System Programming of the Russian Academy of Sciences), 러시아

문서유형: 페이퍼(총 4페이지)

 

항공 시스템과 유관한 3개 표준에 대하여 해당 표준의 요구사항을 준수하는지 확인하는 적합성 테스팅(conformance testing)의 테스트 케이스 개발을 설명한 자료

---

ARINC-653 표준 적합성 테스팅(Conformance testing)

1) ARINC-653 표준

• 1997년 ARINC(Aeronautical Radio, Inc.)가 개발한 항공 애플리케이션 소프트웨어 표준 인터페이스(Avionics Application Software Standard Interface)
• 항공 컴퓨터의 운영 체제와 애플리케이션 소프트웨어 사이의 애플리케이션 프로그램 인터페이스 APEX(Application/Executive)를 정의함
• 임베디드 항공 시스템의 실시간 운영 체제(RTOS) 구현의 주요 표준으로 선정됨

2) ARINC-653 표준의 Part 3 - Conformity Test Specification

• 요구사항 기반 적합성 테스팅(the requirements-based conformance testing)을 지원하고 상용 소프트웨어의 인증 프로세스를 용이하게 하기 위해 ARINC-653 표준의 Part 3인 적합성 테스트 명세(Conformity Test Specification)가 정의됨
• Part 3은 RTOS 애플리케이션 프로그램 인터페이스(API) 기능이 ARINC-653의 Part 1(Required Services) 요구사항을 준수하는지 확인하기 위한 테스트 케이스를 명세하고 있다. 즉, ARINC-653 표준을 준수하는 RTOS가 반드시 구현해야 하는 56개 기능을 커버하는 약 250개 테스트 케이스를 기술하고 있으며, 이들을 모두 통과해야만 해당 OS가 ARINC-653 Part 1을 준수하는 것으로 인정된다.
• ARINC-653 표준의 Part 2(Extended Services) 준수 여부를 확인하는 테스트 케이스 집합도 ARINC-653 표준화 위원회에서 개발 중

3) ISPRAS의 ARINC-653 Part 3 테스트 케이스 개발

• 러시아 과학 아카데미 시스템 프로그래밍 연구소(The Institute for System Programming of the Russian Academy of Sciences: ISPRAS)에서 ARINC-653 Part 3에 기술된 테스트 케이스를 개발하던 중 많은 에러 발견. ARINC-652 Part 1 요구사항에 부합하지 않는 경우들이 있었는데, 이는 API 기능 요구 명세의 개정(변경)이 있었음에도 해당 테스트 명세를 업데이트 하지 않아서 발생. 즉, 테스트 명세가 노후 되어 RTOS API 명세와 내용이 달라지거나 일부 커버되지 않는 요구사항도 존재 했음
• 문제 해결을 위해 기존 테스트 케이스 집합(the test suite)을 확장하였고 결과적으로 370개 이상의 테스트 케이스가 C 언어로 구현됨. 이 테스트 케이스 집합의 구조는 서비스 매크로(service macros), 개별 테스트(individual tests), 테스트 절차(test sequence)의 세 개 계층(layers)으로 나누어짐.
• 개발된 테스트 케이스 집합은 OS2000 RTOS 테스팅 프로젝트에 사용되었으며, ARINC-653 Part 3에 기술된 기존 테스트 케이스 집합으로는 발견하지 못하는 여러 에러들을 발견함

POSIX 표준 적합성 테스팅

1) POSIX(Portable Operating System interface for unIX) 표준

• 임베디드 항공 시스템 RTOS에서 널리 사용되는 또 다른 표준임
• 운영 체제의 이식가능한(portable) API 소스를 정의
• IEEE 1003.1에 주요 명세가 이루어졌고, ISO/IEC 9945-1:1990로 국제 표준이 됨
• 임베디드 항공 시스템 RTOS와 가장 관련된 POSIX 표준으로 1003.1a(OS 정의), 1003.1b(실시간 확장), 1003.1c(쓰레드) 세 가지를 들 수 있다.

2) ISPRAS의 POSIX 테스트 케이스 개발

• POSIX 요구사항에 대한 RTOS의 적합성 테스팅을 수행하기 위한 테스트 케이스 집합(the test suite)을 ISPRAS에서 개발
• POSIX 표준의 요구사항을 계약명세(contract specifications)로 표현하여 정형화하고, 이 정형화된 명세에서 자동으로 테스트 시나리오를 생성하는 방식. 이러한 방식은 표준이 변경될 때 마다 수행되어야 하는 테스트 케이스의 업데이트를 용이하게 함
• POSIX 요구사항 카달로그에는 표준의 텍스트로부터 도출된 10,000개 이상의 요구사항이 있는데 이들은 916개의 POSIX 기능(functions)에 대한 요구사항임. 이 요구사항들이 총 60,000 라인 규모의 계약명세(contact specifications)로 정형화 되며, 이를 테스트하기 위해 172개의 테스트 시나리오를 포함하는 test suite을 개발
• ISPRAS가 개발한 POSIX 테스트 케이스 집합은 OLVER(Open Linux VERification) 프로젝트에서 사용되고 승인됨(개발된 POSIX 테스트 케이스들로 여러 OS Linux 배포 버전을 테스트함)

DO-178B 표준 적합성 테스팅

1) DO-178B 표준

• RTCA(Radio Technical Commission for Aeronautics)가 개발한 항공 시스템 및 장비 인증에서 소프트웨어 고려사항(Software Consideration in Airborne Systems and Equipment Certification)이라는 이름의 DO-178B은 내장형 항공 시스템의 소프트웨어 개발과 인증 프로세스에 대한 요구사항을 정의
• 유럽은 DO-178B 대신 이와 유사한 ED-12B를 표준으로 채택. ED-12B는 EUROCAE(The European organisation for civil aviation equipment)에서 지원함
• 2003년 러시아는 DO-178B와 유사한 GOSTR 51904-2002 표준을 채택. 임베디드 시스템 소프트웨어의 개발 및 문서화에 대한 일반 요구사항을 정의한 표준으로, 항공 분야의 고안전(safety-critical) 컴퓨터 시스템은 해당 표준의 모든 요구사항을 만족시켜야만 함

2) DO-178B의 품질 인증

DO-178B 표준에 정의된 인증 방법(Certification methodology)은 소프트웨어 벤더가 개발한 소프트웨어 솔루션의 품질을 입증할 것을 요구하며, 이를 위해 아래 특징을 갖는 요구사항 기반 테스트 케이스 집합(a requirements-based test suite)을 벤더가 개발할 것을 권고한다.

• 테스트 케이스 집합은 각 소프트웨어 요구사항에 대한 테스트 케이스들을 포함한다.
• 테스트 케이스를 요구사항으로 추적(매핑) 가능하고 또한 요구사항을 테스트 케이스로 추적 할 수 있다.
• 테스트 케이스가 일반 테스팅(normal testing) 기준과 견고성 테스팅(robustness testing) 기준을 만족한다.

3) ISPRAS의 DO-178B 테스트 케이스 개발

• DO-178B에서 요구하는 소프트웨어 테스팅(테스트 케이스 집합 개발)을 지원하기 위해 ISPRAS가 UniTESK 도구와 FOREST(FOrmal REquirements Specification and Testing) 프로세스를 개발. UniTESK와 FOREST는 DO-178B 표준에 대한 소프트웨어 적합성 테스팅 및 인증을 용이하게 하는 프레임워크를 제공한다.
• 테스트 케이스 집합 개발 프로세스는 아래와 같은 4 단계로 구성된다.
  - Stage 1: 표준의 원본 문서(예, ARINC-653 Part 1과 Part 2, POSIX 등)에서 요구사항 추출하고 분류하여 요구사항 카달로그(the requirements catalogue)를 만든다.
  - Stage 2: 요구사항 카달로그를 기반으로 요구사항의 개념 모델(Conceptual models)을 생성하여 요구사항을 분석한다. 개념 모델을 개발하고 분석하는데 있어 애플리케이션 도메인 지식을 재구성하고 다양한 모델 속성(예, adequacy, completeness 등)을 확인한다.
  - Stage 3: 계약명세(contract specifications)의 수학적 형식(표현 체계)을 활용하여 카달로그의 요구사항을 정형적으로 표현한다. 이전 단계에서 수행한 애플리케이션 도메인 지식의 재구성 및 분석이 텍스트 형식의 요구사항을 정형적 명세(formal representation)로 전환하는데 도움을 준다.
  - Stage 4: 계약명세(the contract specifications) 형태로 정형화된 카달로그의 모든 요구사항을 확인하여 테스트 시나리오 개발. 테스트 시나리오는 정형적 명세 언어(the specification language)로 쓰여지고 UniTESK 도구에 의해 실행된다. 테스트 실행의 결과는 주어진 테스트 커버리지 기준의 만족 정도를 나타낸 테스트 보고서로 요약된다.
• 이렇게 개발된 테스트 케이스는 표준에 정의된 요구사항으로 쉽게 추적 가능하며, 표준의 특정 요구사항에 변경이 있을 때 그에 따라 재설계가 필요한 테스트 케이스를 쉽게 식별 및 수정 할 수 있게 해준다.