26. DO-178과 COTS의 사용 (3)

COTS Avionics Software Study.pdf

이전 절에서 이어지는 내용이다.

 

(1)   대체 방법(Alternate Methods)에 대한 고찰

 

앞절에서 소개된 COTS 선정을 위한 여러가지 기법들을 사용하더라도 그것 만으로는 충분하지 않을 수 있다. 이런 경우 제시될 수 있는 대체 방법이 몇 가지 있을 수 있는데 그것이 무엇인지, 그리고 그것을 적용하면서 고려해야 할 점에 대해서 설명하고 있다.

 

①     누락된 문서화에 대한 부분

 

일반적으로 COTS 제품에 대해서 제공받을 수 있는 문서는 상당히 제한적이다. 따라서 이것을 교체하느냐, 다시 작성하느냐 혹은 대체하느냐와 같은 논쟁이 있을 수 있다. 이때 기술적인 판단에 대해서는 조심할 필요가 있다. 즉, 기술적인 부분에 대해서는 아주 제한적으로, 엄격하게 다루어 져야 하며 그 판단의 근거는 반드시 문서화되어야 한다. 이 문서에서는 “기술적인 판단은 COTS 제품을 받아들일지에 대해서 일반적인 논거를 정당화할 수 없다”라고 잘라 말하고 있다.

 

②     리버스 엔지니어링 (Reverse Engineering)

 

누락된 데이터를 대체하는 방법으로 리버스 엔지니어링과 같은 방법을 사용해서 데이터를 다시 만들어 낼 수도 있다. 그런데 이 방법은 결과적으로 새로 개발하는 것과 같은 정도의 혹은 그 이상의 노력이 필요한 일이고 비록 그것이 완료되더라도 그 과정이 문제가 없다는 것을 보장할 수 없다는 문제가 있다. 다만 이 과정을 통해서 DO-178 인증을 위한 목표(Objective)를 만족하는지를 확인하고 분석할 수 있는 실질적인 데이터가 만들어 진다는 점은 다른 방식으로는 얻을 수 없는 명확한 장점이라고 할 수 있다.

 

③     서비스 히스토리

 

기본적으로 서비스 히스토리가 엄청나게 많다면 그 자체로 신뢰성을 높일 수 있는 배경을 제공한다. 많이 판매되었고 오랜 기간 실제 운영되었다는 사실을 통해서 사용 가능하다는 것을 보여주는 데이터를 얻을 수 있다면 동일한, 혹은 유사한 환경에서 그 제품이 사용될 수 있다는 가능성을 짐작할 수 있는 것이다. 하지만 결과적으로 이것은 그저 ‘짐작’일 뿐이다. 실질적으로 그것을 완벽하게 보장할 수 없기 때문이다. 이 문서에서는 그와 관련해서 다음과 같은 이슈들을 들고 있다.

 

-       실제 버전의 형상 데이터를 얻기가 어려움

-       문제가 발생한 상황, 발견된 상황, 기록된 상황 모두 모호함

-       제공된 정보로부터 문제를 재현하기가 어려움(불가능)

-       COTS 판매자가 굳이 부정적인 결과를 공포하려고 하지 않음 (특히 안전과 관련된 시스템에 의도되지 않은 제품인 경우)

-       시험만으로 문제가 없다는 것을 증명할 수 없음. 이를 서비스 히스토리 관점에서 보자면 엄청난 양의 운영 히스토리가 있다고 해도 그것 만으로 문제가 없다는 것을 증명할 수 없음

 

기본적으로 서비스 히스토리가 DO-178과 같은 보장 메커니즘에 적용되는 경우 그 목표는 서비스히스토리를 통해서 실제 운영에 대한 부분을 보장하는 것이다. 이를 위해서는 이론적인 면(통계적으로 유효한 접근)과 실질적인 면(주어진 정보에서 무엇이 실질적으로 유효하고 신뢰를 제공하는가) 모두에 대해서 좀 더 접근할 필요가 있다.

 

(2)   COTS 운영 체제에 활용된 실제 적용 사례

 

앞서 안전이 중요한 시스템에 사용되고 있는 대표적인 COTS로 운영 체제와 컴파일러 라이브러리를 든 바가 있다. 여기서는 그 중 COTS 운영 체제의 실제 사례를 설명한다. 특히 COTS 운영 체제는 생각보다 많은 수의 판매자들이 존재하고 이들이 실제로 항공분야에 적용하기 위해, 즉 “DO-178-ready” 운영 체제를 만들기 위해 적극적으로 활동하고 있기 때문에 그러한 과정에서 나오는 다양한 실전 사례를 확인할 수 있다.

 

한편 그러한 사례들 속에는 지금까지 설명된 내용들이 중간 중간 포함되어 있기 때문에 지금까지 COTS라는 주제를 가지고 세 번에 걸쳐서 설명한 많은 내용들을 총괄해서 정리하는 의미도 될 수 있을 것이다. 참고로 여기서 설명된 부분은 단지 COTS 운영 체제에만 국한되지 않고 다른 COTS 제품들에게도 충분히 적용될 수 있다.

 

①     OS 기반의 Software Hazard Analysis (SHA)

 

어떤 판매자는 만약 그들의 제품이 애초에 항공전자 시스템에 사용되기 위해서 개발되기 시작한다면 소프트웨어 위험 분석을 수행하고 그로부터 인식되는 위험을 감소시킬 요구사항을 개발함으로써 실제 항공기에 적용하는 부분에 대한 자신들의 이해도를 높일 것이라고 언급한 바가 있다.

 

사실 이는 COTS 제품을 항공기에 적용하기 위해 가장 먼저 수행되어야 할 부분이라는 점에서 판매자가 이를 먼저 고려할 수 있다면 COTS의 안전성을 획기적으로 높일 수 있게 된다. 특히 COTS를 적용해서 인증을 받으려는 지원자(Applicant)에게도 COTS 적용에 있어서 고려해야 할 부분을 정확하게 전달할 수 있다는 점도 아주 중요한 부분이다. (물론 그것이 지원자가 COTS를 포함하는 자신의 시스템에 대한 시스템 안전성 평가를 완화시키는 것은 아니라는 점은 유의하자)

 

②     OS PSAC(Plan for Software Aspects of Certification)

 

다들 알다시피 PSAC은 인증당국(FAA)에 DO-178 인증을 어떻게 수행할지를 알려주고 동의를 받는 문서이다. 여러 판매자들이 그들의 OS를 위한 별도의 PSAC을 제공하려는 계획을 가지고 있으며 어떤 판매자들은 OS를 고려한 PSAC 템플릿을 제공하는 방식을 고려하고 있기도 하다. 또한 어떤 판매자의 경우는 지원자가 DO-178 인증을 지원하는 COTS 패키지를 적용하는 데 있어서 보드 옵션을 설정하는 것에 대한 기술적인 지원까지도 고려하고 있기도 하다.

 

③     COTS OS에 고려된 대체 방법

 

1)     리버스 엔지니어링 (Reverse Engineering)

기본적으로는 COTS 개발과정을 통해서 데이터를 얻을 수 있지만 DO-178 인증을 위한 데이터에 대해서는 실질적으로 많은 COTS 판매자들이 리버스 엔지니어링에 상당부분 의지하고 있다. 이는 특히 DO-178 인증을 위해서 반드시 필요한 데이터의 누락된 부분을 커버하기 위함인데 그 중 가장 큰 것이 바로 추적성(Traceability)에 대한 부분이다. 한 판매자의 경우는 오브젝트 코드와 그로부터 생성된 소스 코드 그리고 원래 가지고 있던 헤더 정보를 통해서 추적성 매트릭스를 만들어 내기도 했다. 그 외에도 리버스 엔지니어링을 통해서 코드 구조에 대한 맵을 제공함으로써 이를 통해서 코드가 표준에 따라서 구현되었는지를 확인한 사례가 있다.

 

2)     파티셔닝 (Partitioning)

이 문서가 작성되는 시점에 적어도 2군데의 판매자가 여러 위험 레벨을 가진 파티션을 지원하는 OS를 제공할 계획을 가지고 있었고 한편 다른 곳에서는 시스템 안전성 평가에 따라서 파티션 무결성 체크를 하지 않기로 결정한 바가 있다. 참고로 현재 VxWorks 653이라는 OS의 경우 시간과 메모리에 대한 완벽한 파티션을 지원하는 DO-178 인증 제품으로 전세계적으로 가장 많이 사용되고 있기도 하다.

 

3)     기능의 제한

실시간 시스템의 안전성에 대한 문제로 한 판매자는 지원자로부터 오직 초기화 시점에만 메모리를 할당할 수 있도록 하고 그 외의 경우에는 메모리 할당을 허용하지 않도록 만들어 달라는 요청을 받기도 했다. 어떤 판매자의 경우는 OS와 항공전자 어플리케이션을 타겟에 올리기 위한 빌드 과정에서 사용자가 일부 특성을 비활성화 할 수 있는 환경을 제공하기도 한다.

 

④     표준에 대한 준수

 

어떤 판매자의 경우 표준 준수에 대해서 단지 안전성과 관련된 표준만을 고려한 케이스가 있다. 이를 위해 리버스 엔지니어링을 통해서 하나의 컴포넌트에 대한 필수 안전성 표준셋을 만들어 내고 이를 그 외의 다른 컴퍼넌트에 대한 리버스 엔지니어링에 사용하였다.

 

⑤     리뷰 – 요구사항, 설계, 그리고 코드

 

COTS는 대부분의 경우 DO-178 기반의 리뷰를 위한 원래의 데이터를 얻기가 거의 불가능하다. 그래서 많은 판매자들의 다양한 시도를 통해서 다음과 같은 접근 방법이 제시되었다.

 

-       요구사항 리뷰: 한 판매자의 경우 소프트웨어 구조에 대해서 “Software Hazard Analysis”라고 하는 안전성 분석을 수행함. 참고로 이런 접근에 대한 산업계의 표준은 없음

-       설계 리뷰: 한 판매자의 경우 재귀 유형의 함수가 있는지를 확인하거나 다른 비결정적인 코드가 있는지를 찾는 방식으로 안전성에 민감한 특성을 리뷰함

-       코드 리뷰: 한 판매자의 경우 시험을 할 수 없는 영역이 존재하는지를 결정하기 위한 리뷰를 수행함

 

⑥     COTS 통합

 

COTS를 항공전자 어플리케이션과 통합하는 것은 판매자들에게 가장 큰 관심사항이다. 무엇보다도 DO-178 인증을 받기 위해서는 지원자(Applicant)가 COTS를 선택해 주어야 한다. 그리고 대부분의 판매자들은 지원자가 그들의 항공전자 어플리케이션에서 OS와의 인터페이스와 타이밍 특성을 검증해 줄 것을 기대하는 것이 사실이다.

 

⑦     소프트웨어 품질보증 고려사항

 

소프트웨어 품질 보증을 위해서는 판매자로부터 이전의 품질보증 데이터를 얻는 것뿐만 아니라 컴포넌트의 통합과 시험에 대한 감독이 필요하다. 이는 독립적인 컨설턴트와 같은 외부 인사가 관여하더라도 그들 역시 해당되는 부분이다.

 

⑧     판매자 지원 업데이트

 

시스템에 대한 업데이트 문제는 다음과 같은 이슈들이 고려되어야 한다.

 

-       COTS 제품에 대한 형상 컨트롤과 입수가 필수이다.

-       새로운 버전이 전달되면 판매자는 DO-178 목표(Objective)를 어떻게 지원할 지에 대해서 고려해야 한다.

-       지원자(Applicant)는 다른 사이드 이펙트가 없는지를 명확하게 하기 위해 새로운 버전을 평가하고 재시험(Regression testing)을 수행해야 한다.

 

이러한 것들은 지원자의 PSAC에 작성되어야 한다.

이상으로 제시된 다양한 사례들은 실제로 COTS OS가 DO-178 인증을 받으면서 적용한 방법이라고 설명하고 있다. (설문조사로 확인됨) 하지만 구체적인 내용이 없다 보니 직접적으로 와 닿는 부분이 적은 것도 사실이다. 아쉬운 대로 이렇게 진행된 사례가 있다는 정도로 넘어가고 향후 실제 COTS 적용에 있어서 어려움이 생길 경우 참고자료로 활용하도록 하자.

 

(3)    DO-178 목표(Objective)와 COTS에 미치는 영향

 

기본적으로 COTS가 DO-178 인증을 받기 위해서는 DO-178 목표(Objective)를 준수해야 한다. 그런데 그 많은 목표를 준수하는 것이 결코 쉽지 않기 때문에 결과적으로 그러한 목표가 COTS를 사용하는 데 장애물이 된다. 여기에서는 그러한 장애가 되는 목표(Objective)를 각각의 레벨로 구분해서 설명하고 있다.

 

①     레벨 A

 

COTS 제품은 일반적으로 레벨 A의 소프트웨어에 대한 DO-178 목표(Objective)를 만족하지 못하는 것으로 알려져 있다. 워낙 요구사항이 까다롭고 증빙을 확보하기가 어렵기 때문이다. 특히 MCDC(Modified Condition Decision Coverage)가 그 중에서도 가장 만족하지 못하는 부분인데 이 문서에서는 심지어 조사에 참여했던 COTS 판매자들이 MCDC에 대해서 잘 알지도 못한다고 언급하고 있다. 여기에 DO-178에서 요구하는 독립성(Independence)에 대한 요구가 더해지면서 더욱 어렵게 만들고 있기도 하다.

 

②     레벨 B

 

레벨 A에 비해서 MCDC가 제외된다는 점에서 상대적으로 레벨 B는 DO-178 목표(Objective)를 만족하기가 용이하다는 장점을 가진다. 그럼에도 COTS 제품들이 레벨 B역시 레벨 A와 마찬가지로 일반적으로는 DO-178 목표를 만족하지 못하는 것으로 알려져 있다. 레벨 B에 해당하는 구조적 커버리지를 달성하는 것과 독립성에 대한 요구를 만족하는 것이 쉽지 않기 때문이다.

 

③     레벨 C

 

COTS에 대한 DO-178 인증에 있어서 그래도 가장 활발한 활동이 이루어 지고 있는 레벨이라고 할 수 있다. 레벨 A, B에 비해서 상대적으로 커버리지와 독립성에 대한 요구사항이 감소하기 때문이다. 그 외에도 여러가지 요구사항이 감소된다.

 

그럼에도 여전히 Statement와 Data / Control Coupling에 대한 커버리지 요구사항이 있기 때문에 이를 어떻게 달성하고 증빙을 제출하느냐가 관건이 된다. 이 문서에서는 그것에 대한 핵심을 추적성(Traceability)에 두고 제대로 된 추적성을 얻기 위한 여러가지 방법을 제시하고 있다. 그 중에는 특히 리버스 엔지니어링이 Statement와 Data / Control Coupling에 대한 구조적 커버리지를 달성하는 하나의 대안이 될 수 있다.

 

DO-178 목표(Objective)를 만족하는 지에 대한 증빙에는 개발 과정에서 만들어지는 문서들도 포함된다. 이상적으로는 COTS 판매자로부터 그러한 자료들을 얻는 것이 가장 좋을 것이다. 하지만 현실적으로 그것이 어려운 경우에 대체 방법을 사용하게 된다. 이는 앞서 우리가 살펴보았던 리버스 엔지니어링, 서비스 히스토리, 프로세스 인정과 같은 방법들이다.

 

④     레벨 D

 

일반적인 COTS 패키지의 많은 수가 레벨 D를 만족할 수 있다. 다음과 같은 주요 목표(Objective)를 만족할 수 있기 때문이다.

 

-       상위레벨 요구사항의 정의

-       하위레벨 요구사항의 정의

-       소스코드의 개발과 타겟 컴퓨터상에서의 운영

-       상위레벨 요구사항에 대한 검증

-       파티션에 대한 무결성

-       형상 관리

-       독립된 품질 보증 활동

 

위의 항목 중 유의해야 할 부분이 ‘파티션에 대한 무결성’이다. 이는 레벨 D 소프트웨어가 다른 상위레벨의 소프트웨어에 영향을 미치지 않는다는 것을 보장하는 것을 말한다.

 

(4)    툴 (Tools)

 

DO-178 인증에서 툴의 비중은 그 영향력이 잘 드러나지 않아서 그렇지 상당히 중요하며 큰 비중을 차지한다. 따라서 COTS에 대해서도 관련된 툴이 있다면 반드시 DO-178 인증의 관점에서 고려해야 할 부분이 생긴다. 여기에서 그런 부분들을 설명하고 있다. 비록 이 문서의 작성 시점까지만 확인되는 내용이어서 지금의 상황과는 다소 거리가 있겠지만 기본적인 원리로써 참고는 될 것이다.

 

①     자동 코드 생성기

 

여기에서는 코드를 자동으로 생성하는 툴로써 SCADE(Safety Critical Application Development Environment)라는 툴을 소개하고 있다. 비항공 분야의 한 인증 당국에서는 SCADE를 모듈 시험 영역에서 개발 리소스를 감소시켜주는 툴로써 인정하고 있다고 알려져 있다.

 

②     타겟 환경 마법사

 

소프트웨어와 관련해서 ‘마법사’ 기능이라고 하면 일반적으로 사용자의 직접적인 선택을 최소화하고 자동으로 필요한 것들을 만들어 주는 기능이라고 할 수 있다. 이 문서에서는 어플리케이션 혹은 시스템 개발에서 설계 과정에 컴포넌트를 선택할 수 있도록 하는 마법사 기능을 사용한 사례를 소개하고 있다.

 

③     요구사항 기반의 툴

 

요구사항에 대한 툴은 결국 추적성과 관련되는 기능을 활용하는 것이다. 요구사항과 설계, 코드 등의 추적성을 관리하고 개발 과정에서 활용하는 것이 일반적이다. 이는 인증 당국의 원활한 활동에도 영향을 주는 부분이기도 하다.

 

 

이상으로 총 3회에 걸쳐서 COTS와 DO-178 인증과의 관계, 관련된 이론과 실제, 그리고 업계를 통한 조사 내용 등을 확인해 보았다. 비록 당장은 본인의 상황에 바로 활용할 수 있는 부분이 없을 수도 있겠지만 이러한 배경 지식이 COTS의 선택과 적용에 있어서 전체적인 방향을 어떻게 설정할 것인지를 도와줄 수는 있을 것이다. 사실 방향을 어떻게 설정하느냐에 따라서 세부적으로 실행되는 활동들이 생각보다 많이 달라질 수 있기 때문에 이는 결국 본인이 진행하는 업무의 양과 질에도 영향을 미치게 된다는 점을 인식하는 것이 중요하다.

 

끝으로 이 문서에서 진행했던 설문 조사의 질문 내역을 소개하는 것으로 이 절을 마무리한다. 참고로 질문의 취지가 그대로 전달되도록 하기 위해서 해석은 생략한다.