25. DO-178과 COTS의 사용 (2)

COTS Avionics Software Study.pdf

이전 절에서 이어지는 내용이다. 앞에서는 주로 COTS에 대한 DO-178 인증과 관련해서 배경 설명의 성격이 강했다고 한다면 이번 절에서는 COTS의 적용과 인증을 위한 세부적인 내용이 본격적으로 설명된다.

 

(6)   COTS 통합 프로세스

 

여기에서는 COTS 제품을 시스템에 적용하는 경우에 진행할 수 있는 주요 프로세스들을 제시하고 있다.

 

-       시스템의 위험 요인(Risks와 Hazards)을 식별하고 그러한 위험 요인과 COTS 컴포넌트와의 관계를 결정

-       COTS 제품을 시스템에 맞추기 위한 평가

-       제품에 대한 COTS 판매자의 개발 프로세스를 평가

-       COTS 확보 계획, 라이선스, 대여, 향후 지원에 대한 동의 등을 개발

-       COTS 제품을 다루기 위한 형상 관리(CM) 계획과 소프트웨어 품질 보증(SQA) 계획을 개발

-       가능하다면 정적 그리고 동작 시험을 포함하는 COTS 시험 계획을 개발

-       컴포넌트에 대한 통합 계획을 개발 (사용자 선택에 대한 고려가 필요할 수도 있음)

-       문제점 리포트를 확보하는 것과 한편으로는 문제점 리포트를 제공하는 점에 대해서 판매자와 조율

-       문제점과 버그 리포트를 분석하고 알려진 이상 동작을 수용하기 위해 COTS 제품의 사용을 설계

 

위에서 제시된 프로세스들은 각자가 실제 진행하는 과정에서는 경우에 따라서 동일하게 수행할 수 없을 수도 있다. 이런 경우에는 자신들의 상황에 맞게 커스터마이징을 해야 한다. 따라서 위의 내용을 절대적인 기준으로 판단하면 안되며 다만 이후 설명의 근간이 되는 부분이므로 전체적인 흐름을 파악하는 정도로 이해하고 넘어가도록 하자.

 

(7)   COTS 통합의 결정에 사용되는 기법

 

소프트웨어를 개발하면서 COTS를 사용하는 것은 한편으로는 개발을 더 편하게 만들기도 하지만 다른 한편으로는 상당한 위험을 떠안게 되는 것이다. 그래서 그 위험을 최소화하기 위한 다양한 기법들이 제시되고 있다. 하지만 그러한 기법들이 DO-178 인증에 대한 커버를 보장하는 것은 아니다. 따라서 각각의 기법이 DO-178 인증의 의도를 커버하는지의 여부는 COTS를 적용하는 쪽에서 확인해야 할 부분이라는 점을 명심하자.

 

참고로 이 문서에서는 RTCA(DO-178 가이드라인을 발행한 곳)의 후원을 받는 특정 위원회(Special Committee 190)에서 다음의 기법들을 추천한다고 설명하고 있다.

 

-       프로세스 인정

-       이전 제품의 인증

-       COTS 기능의 제한

-       기타 DO-178B에 대한 준수를 시연(Demonstrate)하는 기법들

 

①     COTS 프로세스 인정

 

이는 COTS가 객관적으로 승인된 개발 프로세스로 개발되었음을 보장하는 것을 말한다. 한마디로 믿을 만한 개발 프로세스로 COTS가 만들어졌다는 말이다. COTS의 개발 과정을 하나하나 직접 확인하지 않고도 인정을 해줄 수 있다는 의미에서 상당히 유용한 방법으로 보인다.

 

하지만 이를 FAA의 관점에서 보게 되면 심각한 문제를 발견하게 된다. 과연 앞에서 나온 ‘승인된 개발 프로세스’에서 ‘승인’을 누가 할 수 있는가이다. 기본적으로 이에 대해서는 위임(Delegation)의 규정이 있기 때문에 임의로 위임을 할 수 없다는 근본적인 문제에 봉착하게 된다.

 

②     이전 제품의 인증

 

이는 개발된 COTS 컴포넌트가 이전에 인증된 시스템 항공전자 어플리케이션의 일부로써 승인된 경우를 말한다. 사실 이는 항공분야 뿐만 아니라 다양한 분야에 적용될 수 있는 기법이다. 하지만 여기에도 이전의 인증에 대한 유효성을 어떻게 평가할 것이냐의 문제가 남게 된다.

 

③     COTS 기능의 제한

 

이는 COTS가 가지고 있는 모든 기능 중에서 일부만 제한해서 사용하겠다는 것이다. 이를 구현하는 방법으로는 실행 시점에 체크, 설계를 통한 적용 혹은 빌드 시점의 제약과 같은 방법이 있을 수 있다. 하지만 여기에는 제약이 제대로 강제되는지에 대한 추가적인 검증이 필요하다는 문제가 있다.

 

④     하드웨어 아키텍처

 

먼저 COTS 소프트웨어에 대한 인증을 설명하면서 하드웨어 아키텍처를 언급하는 부분이 이상하게 받아들여 질지 모르겠다. 하지만 갈수록 복잡한 시스템이 만들어지고 있는 현실에서는 하드웨어와 소프트웨어를 완전히 분리해서 구현한다는 것이 이미 더 이상 고려할 가치가 없는 개념이 되었다는 점을 이해할 필요가 있다. 즉, 하나의 시스템을 만들기 위해서는 하드웨어와 소프트웨어를 적절하게 조합하고 고려해야 한다는 뜻이다. 그런 의미에서 하드웨어 아키텍처에 대한 기법은 분명히 COTS의 결정에 중요한 요인이 된다.

 

이 문서에서는 다음과 같은 하드웨어 아키텍처 기법을 소개하고 있다.

 

1)     시스템 파티셔닝 (System Partitioning)

시스템의 안전과 관련된 부분을 시스템의 나머지 부분과 완전히 분리하는 것이다.

 

2)     메모리 파티셔닝 (Memory Partitioning)

데이터 혹은 코드의 물리적인 메모리 주소를 완전히 분리하는 것이다.

 

3)     시간 파티셔닝 (Time Partitioning)

프로그램의 일부의 동작이 다른 부분의 동작 시간에 영향을 주지 않도록 분리하는 것이다.

 

4)     와치독 타이머

5)     중복 구성(N-Redundant Component)

시스템에서 문제가 발생하는 경우 하나의 컴포넌트에서 수용하지 못하더라도 기능적으로 중복된 여분의 다른 컴포넌트에서 수용하는 개념이다. 독립적인 설계 기법으로 구현될 수 있다.

 

6)     네트워크 분리

커뮤니케이션 방식을 완전히 다르게 가져가는 것이다. 예를 들면 컴포넌트간의 통신에서 공유 메모리를 사용하는 방식과 패킷으로 메시지를 전달하는 방식으로 구분하는 것을 들 수 있다.

 

7)     Safety Bag

적절한 번역이 어려워서 영어를 그대로 적었다. 이는 한마디로 ‘Safety Bag’이라는 외부 모니터를 별도의 독립된 컴퓨터로 두고 감시하는 기법이다. 결국 메인 컴퓨터의 시스템 동작은 아무런 변경없이 자체적으로 수행되면서 문제점에 대한 것은 외부 모니터를 통해서 처리되는 것이다. 앞서 보았던 ‘중복 구성(N-Redundant Component)’과 유사한 컨셉이라고도 볼 수 있다.

 

구체적인 예를 들긴 했지만 하나같이 실제 구현하기에는 상당히 난해한 기법들로 보인다.

 

⑤     소프트웨어 아키텍처

 

소프트웨어 아키텍처에 대한 내용을 확인해 볼 차례이지만 앞서 하드웨어 아키텍처에서 설명한 것처럼 COTS의 적용에 있어서 하드웨어와 소프트웨어를 함께 고려해야 한다는 점을 다시 한 번 상기하자.

 

1)     소프트웨어 중복을 포함한 오류 탐지 및 수용

오류 탐지에는 물리적(예. 온도, 전압 장치), 논리적(예. 에러 탐지 코드), 기능적(예. 경고), 혹은 외부적(예. 가용성 체크)인 방법을 들 수 있다. 이러한 오류를 탐지하고 수용하기 위해서 주로 백그라운드에서 실행되는 진단 프로그램이 활용된다. 진단 프로그램에서는 여러 번에 걸친 체크, 패리티 체크, CRC 체크와 같은 방법을 사용할 수 있다. 때로는 중요한 기능에 대해서 중복(Redundancy)을 적용하고 그러한 중복 구조에서 하나를 선택하게 되는 보팅(Voting) 기법을 설계에 반영하기도 한다.

 

2)     오류 복구의 재시도

재시도를 통한 오류 복구는 통신과 관련된 시스템에서 많이 사용하는 방식으로 빠른 처리가 필요한 실시간 시스템에서는 잘 사용되지 않는다.

 

3)     N-Version Programming

N-Version 프로그래밍에 대한 내용 자체에 대해서는 별도로 포스팅한 부분이 있다. 다만 COTS 적용에 있어서 이 기법을 사용하기 위해서는 이 기법이 가지는 한계에 대한 부분도 충분히 고려가 되어야 한다. 예를 들면 상위레벨의 정의 자체가 적절하지 못한 경우에는 그렇게 구현된 여러 버전의 소프트웨어라고 하더라도 여전히 동일한 에러를 발생할 가능성이 높다. 이 문서에서는 이 기법 자체에 대한 논쟁이 있다고도 설명하고 있다.

 

4)     Recovery Block Programming

용어가 낯설고 어려워 보이는 데 쉽게 설명하자면 독립된 별도의 모듈을 만들어서 그 모듈이 스스로 COTS를 체크하고 복구까지 할 수 있도록 하는 기법이다. 이렇게만 된다면 가장 이상적이겠지만 결국 별도로 만들어 지는 모듈의 신뢰도를 어떻게 보장할 것이냐가 이슈가 될 것이다.

 

5)     Model Following

‘Model Following’이라는 용어는 필자가 처음 들어보는 것이다. 구글링을 해 보아도 관련 자료들이 검색이 되지 않고 있다. 우리가 반드시 참고해야 할 항목은 아니라고 판단되어 설명은 생략한다. 혹시 궁금하신 분은 아래의 원문을 참고하자.

 

6)     Wrappers

Wrapper라는 용어로만 보자면 COTS를 둘러싸는 무언가를 만든다고 생각하면 될 것이다. 이 문서에서는 다음과 같은 3가지 Wrapper를 소개하고 있다.

•           Porthole wrapper: 작은 구멍(인터페이스)을 통해서 필요한 최소한의 정보만 주고받는 방식으로 가장 간단하게 구현될 수 있지만 COTS의 오동작으로부터 시스템을 보호하는 것에는 상대적으로 취약점을 가지는 구조라고 설명하고 있다.

•           Shell wrapper: 이것을 설명하면서 ‘immunization’이라는 단어를 사용하고 있다. 일종의 ‘예방’ 기능을 적용하는 것이라고 할 수 있는데 제대로 구현하기 위해서는 COTS가 시스템과 어떻게 교류하는 지에 대해서 상세하게 이해해야 하기 때문에 상당히 어려운 기법이라고 할 수 있다.

•           Worm wrapper: 데이터를 보호하기 위한 방법으로 통신이 이루어지기 전에 암호화를 했다가 전송이 된 후에 해독을 하는 방식을 예로 들고 있다.

 

7)     객체지향 아키텍처

사실 객체지향이 항공기에 적용되기 시작한 지는 이미 오래되었다고 할 수 있다. 객체지향의 동적 부분과 다형성(Polymorphism)과 같은 안전성에 영향을 주는 요인들을 커버할 수 있는 방법들이 많이 도입되었기 때문이다. 그에 대한 예시로 이 문서에서는 아래와 같은 아키텍처 혹은 패턴을 소개하고 있다.

•           Homogeneous Redundancy Pattern

•           Diverse Redundancy Pattern

•           Monitor-Actuator Pattern

•           Safety Executive Pattern

 

소프트웨어 아키텍처 역시 구체적인 예를 들긴 했지만 하드웨어 아키텍처에서와 마찬가지로 실제 구현하기에는 상당히 난해한 기법들임에는 틀림없다. 일단 이러한 방법들이 있다는 정도로만 이해하고 넘어가자.

 

⑥     검증 기법

 

COTS를 결정하는 데 있어서 검증기법도 하나의 선택지가 될 수 있다. 즉 검증을 통해서 COTS 사용에 대한 무결성을 확인하는 것이다. 하지만 이것 역시 결코 쉽지가 않다. 시험을 수행하는 자체도 중요하지만 그 시험이 DO-178의 의도와 일치해야 하기 때문이다. 여기에는 소프트웨어 레벨이 무엇이냐도 고려해야 하며 어느 시점에 어떤 시험을 수행하느냐도 결정되어야 한다.

 

결국 이 문서에서는 이 모든 것을 다음의 문장으로 설명하고 있다.

 

해석을 보자.

 

아래에 상세하게 기술된 검증 기법은 COTS 컴포넌트의 검증에 대한 후보군으로써 제공된다. 그들이 왜 선택되고 어떻게 사용되며 어디에 적용될지는 시스템 개발자에게 달려있다. 각각의 기법은 그 자신만의 특성을 가지며 일부는 항공전자 어플리케이션에 가장 잘 맞도록 수정될 수 있다. 각각의 기법은 또한 그 자신의 장점과 단점을 가지며 이들은 서로 다른 COTS 컴포넌트에 따라 다를 것이다.

 

이러한 배경을 이해하면서 아래에 설명되는 검증 기법들을 살펴보자.

 

1)      기능 컴포넌트 시험 (블랙박스)

 

COTS에 대한 기능을 시험하는 것으로 가장 일반적인 시험 기법이다. 블랙박스 시험이라는 의미도 무엇인지 다들 아실 것으로 믿는다. 이후 나오는 시험들 중 일부는 기능 시험의 조금 특별한 형태라고 할 수 있다.

 

2)      스트레스 시험 (블랙박스)

 

잘못된 부분과 실패 모드 등을 찾아내기 위해서 예외적으로 높은 작업 부하를 주는 방식이다. 하지만 내부적인 구조를 알지 못하는 상태에서는 스트레스 시험을 하는 것 자체로 모든 오류를 발견할 수 있는 것은 아니라는 한계도 명확한 시험이라고 할 수 있다.

 

3)      프로세스 시나리오 시험 (블랙박스)

 

예상되는 환경과 사용에 기반해서 시험 시나리오를 만들어 내는 것이다. 실제 운영 환경에서는 재현할 수 없는 상황을 만들어 낼 수 있다는 장점이 있다.

 

4)      동등클래스 시험 (블랙박스)

 

어떤 입력의 범위가 있을 경우 그 범위 내의 모든 케이스를 시험하는 것은 실용성이 떨어진다. 그래서 정의된 범위 내의 대표성을 가진 일부만 시험을 수행하면서도 전체를 시험한 것과 같은 효과를 얻는 기법이다. 하지만 대표성에 대한 판단이 잘못될 경우 오류가 검출되지 않고 남아있게 되는 결과가 될 수도 있다.

 

5)      경계값 시험 (블랙박스)

 

앞서 보았던 동등클래스 시험과 관련된 시험이라고 할 수 있다. 즉 동등 클래스의 경계와 그 이상 그리고 이하에서 시험을 선택하게 된다.

 

6)      랜덤 입력 시험 (블랙박스)

 

통계적인 시험이라고도 불리는 것으로 체계적인 방식과 랜덤 방식으로 구분될 수 있다. 컨트롤과 관련된 부분은 체계적인 방식으로, 특정한 시험 케이스에 대해서는 랜덤으로 수행한다. 하지만 랜덤 선정의 기준이 무엇인지, 그리고 시험 결과의 신뢰성을 어떻게 판단할 지에 대한 논쟁이 있기도 하다.

 

7)      성능 시험 (블랙박스)

 

특히 실시간 특성에 대해서 응답 시간을 검증하는 시험이다. 이 시험을 통해서 최적의 처리량을 조율할 수도 있다. 하지만 실시간 환경인 경우에 그러한 시험 자체가 어렵기도 하고 특히 최악의 값을 증명하는 것이 상당히 어렵다.

 

8)      Formal Methods

 

DO-178 가이드라인에서는 Formal Methods를 “시스템 동작의 수학적 모델을 만들고, 개발하고 그에 대해 정당화하기 위한 기술적인 표기법과 분석적인 방법”이라고 정의하고 있다. 일반적인 개발 방법은 아니기 때문에 그냥 수학적인 방법으로 개발하는 것이라는 정도로 가볍게 이해하고 넘어가자. 개발을 수학적인 방식으로 하는 만큼 시험 역시 그러한 수학적인 방식에 기반해서 수행하게 된다. 개발에 대한 부분을 수학적인 방식으로 제대로 표현할 수만 있다면 가장 정확한 결과를 얻을 수 있는 기법이라고 할 수 있다.

 

이상으로 COTS 선정을 위한 검증 기법이 여러 가지 소개되었는데 서두에서 보았던 “그들이 왜 선택되고 어떻게 사용되며 어디에 적용될지는 시스템 개발자에게 달려있다.”는 설명을 다시 한 번 인용하면서 마무리한다.

 

예상보다 분량이 많아서 이어지는 내용은 다음 절에서 설명한다.