페이퍼요약 - DO-178B의 안전성 및 신뢰성 고려사항 by Zemskyy

제목: DO-178B의 안전성 및 신뢰성 고려사항(Safety and Reliability Considerations in DO-178B)

저자: Dima Zemskyy, Embry-Riddle Aeronautical University, 미국

문서유형: 페이퍼(총 8페이지), 2006년

 

항공 시스템 표준인 DO-178B의 프로세스 중 안전성과 신뢰성 보장을 위한 활동인 소프트웨어 검증에 중점을 두어 기술한 자료

---

DO-178B 표준

• 항공 시스템 및 장비 인증의 소프트웨어 고려사항(Software Considerations in Airborne Systems and Equipment Certification)
• 작은 애플리케이션의 경우도 완벽한 테스팅은 불가능하지만 소프트웨어 동작의 정확성을 납득할만한 수준의 확신을 가지고 가늠할 수 있는 가이드라인을 제공하는 것이 목표

DO-178B의 History

• 1970년대 후반과 1980년대 초반, PC 도입과 더불어 컴퓨터 시스템 가격이 내려가고 성능은 크게 증가함에 따라 항공전자 제조업자(avionics manufacturers)들이 기존 항공 장비(airborne equipment)를 소프트웨어 기능으로 대체하거나 보강
• 고위험 애플리케이션(safety critical applications)에 소프트웨어와 컴퓨터 시스템 사용이 증가하게 되자 1980년 미국의 항공 협회에서 DO-178 표준을 개발
• 1985년 원본의 수정을 거쳐 DO-178A로 릴리즈
• 1990년대 초 다시 검토를 거쳐 1992년에 DO-178B로 릴리즈
• 이후 지속적인 업데이트를 하고 2000년에 DO-248B로 확장하여 릴리즈(하지만 1990년대 초반 유행했던 소프트웨어 개발 방법과 패러다임을 여전히 기반으로 하고 있음)

항공 소프트웨어의 안전성 레벨과 인증 레벨

아래 그림과 같은 소프트웨어 안전성 레벨(Software Safety Levels)은 대상 시스템의 위험성(the criticality)을 명시하는데 사용된다.

• Level A 소프트웨어의 장애(failure)는 지속적인 안전 비행이나 착륙을 막는 재앙 상황(a Catastrophic condition)을 초래한다. 항공기에는 많은 백업 시스템과 기능이 설치되므로 Level A 시스템은 그다지 많지 않다. 엔진 컨트롤러 소프트웨어(an engine controller software)가 Level A 시스템의 예이다.
• Level B 소프트웨어의 장애는 항공기나 승무원의 원활한 기능 수행을 막고 탑승자들에게 심각하거나 치명적인 피해를 줄 수도 있는 위험 상황(a Hazardous condition)을 초래한다. Level B 시스템의 예로 항공 상태 표시 화면(Primary Flight Displays: PFDs)과 객실 여압 시스템 소프트웨어(cabin pressurization system software)가 있다.
• Level C 소프트웨어의 장애는 승무원의 작업량을 증가시키고 안전 버퍼(safety margins)를 감소시켜 탑승자들에게 불편이나 상해를 줄 수 있는 주요 장애 상황(a Major failure condition)을 초래한다. Level C 시스템의 예로 비행 관리 시스템(Flight Management System: FMS)과 자동 파일럿 및 자동 착륙 시스템(autopilot and auto landing systems)이 있다.
• Level D 소프트웨어의 장애는 항공기의 안전을 약간 감소시키고 탑승자의 불편을 줄 수도 있어 승무원의 대응을 요구하는(승무원의 능력으로 대응 가능) 사소한 장애 상황(a Minor failure condition)을 초래한다. Level D 시스템의 예로 트랜스폰더(transponders)와 통신 장비(communication equipment)가 있다.
• Level E 소프트웨어의 장애는 비행의 안전이나 항공기 탑승자들의 안전에 악영향을 미치지 않는다. Level E 시스템의 예로 기내 오락 기능(in-flight entertainment functions), 위성 전화(satellite phone), 인터넷 접속(internet access) 등이 있다.

특정 소프트웨어의 인증 레벨(The certification level)은 인증을 위해 요구되는 문서화 유형 및 양에 큰 영향을 미치므로 개발 초기에 결정되어야 한다(예를 들어 Level A 시스템은 66가지 인증 목표를 요구하지만 Level D 시스템은 28개 목표만을 요구). 적절한 인증 레벨은 시스템 안전성 레벨을 평가하여 결정한다. 

DO-178B의 소프트웨어 개발 프로세스(the software development processes)

DO-178B의 소프트웨어 개발 프로세스는 아래 그림처럼 3개의 주요 프로세스로 구성된다.

• 계획 프로세스: 대부분의 소프트웨어 개발 프로젝트에서 공통적으로 수행되는 활동들로 구성되며, 한 가지 특이한 점은 DO 178B의 인증 요구사항이나 기타 인증 기관의 인증 요구사항을 어떻게 충족시킬 것인지 계획하는 소프트웨어 인증 계획(Plan for Software Aspects of Certification) 활동이 포함되어 있다는 것이다.
• 개발 프로세스: 표준에서 특정 라이프사이클 모델을 한정하지는 않지만 1990년대 유행한 반복적 폭포수 모델(iterative waterfall) 또는 V 모델에 자연스럽게 매핑되는 활동들과 정보 흐름으로 구성
• 검증 프로세스: DO 178B은 소프트웨어 검증을 검토(reviews), 분석(analysis), 테스팅(testing)의 조합으로 정의. 대상 시스템의 인증 레벨(the software certification level)에 따라 요구되는 검증 활동도 달라진다.

DO-178B의 소프트웨어 검토 및 분석(Software Reviews and Analyses)

• 소프트웨어 개발물(software development artifacts)의 검토는 해당 결과물의 정확성(correctness)에 대한 정성적 평가를 제공하는 반면 분석은 정량적 평가를 제공한다.
• 검토는 대개 사전 정의된 체크리스트로 공식/비공식 인스펙션(inspections)을 수행하여 이루어지고, 분석은 조사 대상 컴포넌트가 모든 관련된 요구사항에 부합하는지 확인하기 위해 기능의 특정 측면을 상세하게 조사한다.

1) 요구사항 검토/분석

• 소프트웨어 요구사항 프로세스에서 발생된 에러나 불일치(discrepancies)를 찾기 위해 상위 레벨 요구사항(The High Level Requirements)과 하위 레벨 요구사항(Low Level Requirements)을 조사
• 각 요구사항이 명확하고 모호하지 않게 정의되었고, 상위 레벨 요구사항과 일관성을 가지며, 검증 가능하고(verifiable), 소프트웨어 요구사항 표준(the Software Requirements Standards)을 준수하는지 확인
• 시스템 소프트웨어 요구사항으로부터 상위 레벨 요구사항으로의 추적성(traceability)과 상위 레벨 요구사항으로부터 하위 레벨 요구사항으로의 추적성이 확립되었는지 확인
• 시스템에 적용하기 위해 제안된 모든 알고리즘도 인스펙션을 통해 정확성(accuracy) 및 확정성(deterministic behavior) 확인

2) 소프트웨어 아키텍쳐 검토/분석

• 에러나 불일치(discrepancies)가 존재하는 확인하기 위해 소프트웨어 아키텍쳐(The Software Architecture)를 검토하고 분석한다.
• 상위 레벨 요구사항(high level requirements)과 충돌하는 경우를 식별하고 해결해야 한다.
• 모든 아키텍쳐 컴포넌트에 대해 타겟 컴퓨터와의 일관성(consistency) 및 호환성(compatibility)을 확인해야 한다.

3) 소스 코드 검토/분석

• 소스 코드에 에러가 있는지 그리고 소프트웨어 코드 표준(the Software Code Standards)을 준수하는지를 검토하고 분석한다.
• 코드는 모든 하위 레벨 요구사항을 커버해야 하고 문서화되지 않은 기능을 포함해서는 안 된다.
• 코드의 데이터 플로우와 컨트롤 플로우는 소프트웨어 아키텍쳐에 정의된 것과 일치해야 한다.
• 코드 복잡도(Code complexity)도 반드시 조사하여 코드를 이해하는데 문제가 있는 경우 적절하게 손 봐야 한다.

4) 통합 결과물 검토/분석

• 통합 프로세스 결과물(the Integration Process artifacts)을 검증할 때는 데이터 링킹과 로딩 그리고 메모리 맵(the memory map)을 조사해야 한다. 
• 분석에서는 부정확한 하드웨어 주소(incorrect hardware addresses), 메모리 중복(memory overlaps), 빠진 소프트웨어 컴포넌트(missing software components)를 식별하는데 집중한다.

DO-178B의 소프트웨어 테스팅

테스팅은 소프트웨어가 요구사항을 만족하는지 확인하기 위해 그리고 특정 문제/장애(failure conditions)를 야기하는 원인이 제거 되었다는 것을 증명하기 위해 수행된다. DO-178B의 전반적인 테스팅 전략은 아래 그림과 같다.

• 정상적인 입력 값과 경계 값을 테스트 하기 위해 하위 레벨 소프트웨어 요구사항(the low level software requirements)으로부터 정상적 테스트 케이스(Normal range Test Cases) 개발해야 한다.
• 시간 관련 기능(time-related functions)에서는 테스트가 여러 차례 반복 수행되어야 한다.
• 정상적인 시스템 운영 동안 발생될 수 있는 모든 상태 변이(state transitions)가 테스트 케이스에 의해 커버되어야 한다.
• 견고성(예외적) 테스트 케이스(Robustness Test Cases)는 예외적인 입력 값이나 초기화 조건에서 소프트웨어의 반응을 테스트 해야 한다.
• 계산 관련 항목들에서는 산술적 오버플로우 조건(arithmetic overflow conditions)에 대하여 테스트 해야 한다.
• 테스트 커버리지 분석도 수행되어야 한다. 요구사항 기반 테스트 커버리지 분석(Requirements-based test coverage analysis)은 각 소프트웨어 요구사항에 대하여 적어도 하나 이상의 테스트 케이스가 존재하며, 또한 정상적 테스트 케이스와 예외적 테스트 케이스가 모두 존재하는지 확인한다. 구조적 커버리지 분석(Structural coverage analysis)은 모든 코드 문장(code statement)이 요구사항 기반 테스트 케이스에 의해서 적어도 한번 이상 실행되었는지 확인한다. 그렇지 않은 경우 이를 보완하는 추가 검증을 수행해야 한다.
• 의도적으로 비활성화된 코드(the deactivated code)가 어떤 경우에도 실행되지 않는 것을 검증해야 한다.

시스템 신뢰성 향상을 위한 DO-178B의 추가적 기법

DO-178B은 항공 시스템의 안전성과 신뢰성을 향상 시킬 수 있는 추가적인 기법과 아키텍쳐를 권고하는데, 아래는 이 중 세 가지를 간략히 기술하고 있다.

1) 분할 기법(Partitioning)

• 기능적으로 독립적인 시스템 컴포넌트들을 특정 컴포넌트에 문제가 생겼을 때 다른 컴포넌트로 영향이 미치지 않도록 분리
• 컴포넌트 간의 낮은 결합도(Low coupling) 또한 컴포넌트가 사용하는 데이터 간의 낮은 결함도가 성공적인 파티셔닝의 핵심
• 파티셔닝을 소프트웨어로 구현할지, 하드웨어로 구현할지, 아니면 하드웨어와 소프트웨어를 조합하여 구현할지 결정 필요

2) 다수 버전의 상이한 소프트웨어(Multiple-version Dissimilar Software)

• 종종 N-버전 프로그래밍이라고도 불림
• 동일한 기능을 제공하지만 다른 방식으로 구현된 중복된 컴포넌트를 개발
• 특정 컴포넌트에 내재한 구현 이슈가 시스템에 영향을 주지 않도록 하려는 전략(같은 기능을 제공하지만 다른 방식으로 구현된 컴포넌트가 존재하므로 가능)
• 컴포넌트의 입력 데이터 자체에 문제가 있는 경우는 이 기법으로 시스템 보호 불가능
• 동일 기능의 여러 컴포넌트 중 하나에 장애가 발생했을 때, 현재 어떤 컴포넌트에 문제가 있는 것인지 판단할 필요가 있음. 이를 위해 아래의 안전 모니터링(Safety Monitoring) 기법이 필요

3) 안전 모니터링(Safety Monitoring)

• 장애 징후를 찾기 위해 컴포넌트를 모니터하고 실제 장애 발생시 이를 빠르게 식별하여 시스템 다른 부분으로 퍼지는 것을 방지
• 이 기법은 컴포넌트의 동작을 평가하고 올바르지 않는 결과를 생성하는 경우를 판단할 수 있도록 설계되어야 한다.
• 이러한 기능은 소프트웨어로 구현하거나, 하드웨어로 구현하거나, 소프트웨어와 하드웨어를 조합하여 구현할 수도 있다.