35. 대체방법(Alternative Methods)의 종류 (Section 12.3)

앞 절의 마지막에 정리한 것처럼 DO-178 가이드라인에서 제시하는 대체 방법의 종류에는 아래와 같은 4가지가 나온다.

 

-       철저한 입력 시험(Exhaustive Input Testing) (Section 12.3.1)

-       다중 버전 비유사성 소프트웨어 검증에 대한 고려사항(Considerations for Multiple-Version Dissimilar Software Verification) (Section 12.3.2)

-       소프트웨어 신뢰도 모델(Software Reliability Models) (Section 12.3.3)

-       제품 서비스 히스토리(Product Service History)

 

물론 이외에도 여러가지 방법이 있을 수 있고 시간이 지나고 기술이 발전하면 할 수록 그 가지수는 더욱 더 많아질 것이다. 하지만 최소한 DO-178의 다음 버전이 나오기 전까지는 앞서 잠시 언급되었던 보조재(Supplement)나 여기서 설명하는 4가지 대체 방법을 통해서 DO-178 인증에 적용하는 것이 충분히 가능하리라고 생각된다. 그런 의미에서 여기에서 설명되는 내용들은 앞으로 나오게 될 다양한 대체 방법에 대해서 어떤 형태로 적용할 수 있는지를 이해하는 관점으로 보는 것이 더 도움이 되지 않을까 싶다.

 

(1)    철저한 입력 시험(Exhaustive Input Testing) (Section 12.3.1)

 

이 대체방법은 한 마디로 가능한 모든 시험을 수행해서 문제가 없다는 것을 확인하는 것이다. 소위 ‘단순 무식한’ 방법이라고 할 수 있는데 이것이 가능 하려면 시험하고자 하는 대상이 상대적으로 간단하고 시험 범위를 100% 한정할 수 있어야 한다. 이렇게 되면 시험 계획이나 절차, 결과 등의 관련된 문서들이 필요없이 직접 시험을 수행해서 보여주는 것으로(Demonstrate) 검증결과에 대한 증빙이 될 수 있다.

 

DO-178 가이드라인에서는 이 대체 방법에 대해서 다음과 같은 활동을 제시하고 있다.

 

a.      소프트웨어의 유효한 입력과 출력의 완전한 셋을 정의

b.     소프트웨어로의 입력에 대한 분리를 확정하는 분석을 수행

c.      철저한 입력 시험 케이스와 절차에 대한 타당성을 개발

d.     시험 케이스, 시험 절차 그리고 시험 결과를 개발

 

 

(2)    다중 버전 비유사성 소프트웨어 검증에 대한 고려사항(Considerations for Multiple-Version Dissimilar Software Verification) (Section 12.3.2)

 

솔직히 필자에게는 ‘다중 버전 비유사성 소프트웨어’라는 것이 당장 용어에서부터 여전히 낯설다. 정확히 무엇을 말하는 것이고 과연 어디에 사용하는지에 대해서 아직도 제대로 이해하지 못하고 있다. 그래서 구글링으로 자료를 찾던 중에 아래와 같은 그림을 발견했다.

 

※     출처: https://www.slideshare.net/shabnam0102/nversion-programming

 

참고로 그림에서 ‘N-Version Programing’은 ‘Multiple-Version Dissimilar Software’의 다른 표현이다. 위의 그림을 간단하게 설명하면 하나의 스펙(Specification)을 가지고 두 개의 조직이 서로 다른 소프트웨어(Version 1, Version 2)를 개발하는 것이다. 이때 동일한 스펙을 가지고 구현을 했으므로 이론적으로는 두 소프트웨어는 완벽하게 동일한 기능을 수행한다. 이렇게 구현된 소프트웨어는 서로 다른 하드웨어, 즉 서로 다른 프로세스(Processor 1, Processor 2)에서 구동하게 된다. 이것이 의미하는 바는 Version 1과 Version 2가 다른 언어로 개발되고, 다른 컴파일러로 컴파일되며 다른 빌더, 다른 로더를 사용해서 적재된다는 것을 말해준다. 최종적으로는 이렇게 수행되는 두 개의 기능 중 하나를 선택해서 마지막 구동 결과를 보여주는 것이다.

 

DO-178 가이드라인에는 다중 버전 비유사성 소프트웨어에 대한 설명이 별로 없지만 그래도 다음과 같이 그것이 어떤 기법으로 만들어지는지에 대한 설명이 나온다. 앞서 본 그림과 연계해서 보면 설명이 조금 더 쉽게 이해될 수 있을 것이다.

 

내용이 많긴 하지만 전체를 해석해 보자.

 

• 소스코드가 둘 혹은 그 이상의 서로 다른 프로그래밍 언어로 구현된다.   • 오브젝트 코드가 둘 혹은 그 이상의 서로 다른 컴파일러로 생성된다.   • 실행 가능 오브젝트 코드의 각각의 소프트웨어 버전은 분리된, 이종의 프로세스 혹은 소프트웨어 버전 사이에 파티션을 제공하기 위한 방법을 가진 하나의 프로세스상에서 동작한다.   • 소프트웨어 요구사항, 소프트웨어 설계, 그리고/혹은 소스코드가 상호 작용이 관리되는 둘 혹은 그 이상의 개발 팀에 의해서 개발된다.   • 소프트웨어 요구사항, 소프트웨어 설계, 그리고/혹은 소스코드가 둘 혹은 그 이상의 소프트웨어 개발 환경에서 개발된다. 그리고/혹은 각 버전은 분리된 시험 환경을 사용해서 검증된다.   • 실행가능 오브젝트 코드는 둘 혹은 그 이상의 서로 다른 링크 에디터 그리고 둘 혹은 그 이상의 서로 다른 로더를 사용해서 링크되고 로드된다.   • 소프트웨어 요구사항, 소프트웨어 설계, 그리고/혹은 소스코드는 둘 혹은 그 이상의 서로 다른 소프트웨어 요구사항 표준, 소프트웨어 설계 표준, 그리고/혹은 소프트웨어 코드 표준에 따라서 각각 개발된다.

 

위의 설명을 자세히 보면 결국 모두가 앞의 그림을 설명하고 있다는 것을 알 수 있다. 도대체 왜 이렇게 비싼 비용을 들여서 이렇게나 어렵게 중복된 소프트웨어를 만드는 것일까? 게다가 프로세서가 다르다는 것은 하드웨어에도 비용이 더 든다는 것을 의미한다.

 

결론적으로 이는 항공기의 안전을 위한 한 가지 방법이다. 이렇게라도 해서 가장 확실한 안전성을 확보하겠다는 것이다. 실제 그 효과와 가치에 대해서는 여기서는 논외로 하고 어쨌든 ‘다중 버전 비유사성 소프트웨어’가 ‘대체방법’으로써 선택될 수 있다는 것을 이해하자.

 

대체방법으로 다중 버전 비유사성 소프트웨어가 선택되는 경우 위에서 설명된 기법으로 소프트웨어가 제작되면서 이에 대한 검증이 이루어지게 된다. 여기에서 이루어 지는 검증을 생각해 보면 아래와 같이 두 가지 형태가 이루어 진다는 것을 예상할 수 있다.

 

-       각각의 분리된 개발 과정에서의 개별적인 검증

-       서로 다른 프로세서가 합쳐져 있는 하드웨어와 소프트웨어 구조 상에서 동작하는 것에 대한 통합 검증

 

이로 인한 추가적인 검증 프로세스의 목표를 DO-178에서는 다음과 같이 설명하고 있다.

 

해석을 보자.

 

a. 정상적인 그리고 비정상적인 동작과 상태 전이 동안의 호환성을 포함해서 버전 상호간의 호환성 요구사항이 충족된다. b. 동등한 에러 탐지를 얻는다.

 

이러한 목표를 만족하는지 확인하기 위해 DO-178 가이드라인에서는 다음의 5가지를 검증하는 활동을 수행하도록 하고 있다.

 

각각의 핵심을 정리하면 다음과 같다.

 

-       다중 버전 비유사성 소프트웨어에 대한 검증의 독립성

-       다중 프로세서에 관련된 검증

-       다중 버전 소스 코드에 대한 검증

-       다중 버전 비유사성 소프트웨어를 위한 툴인증

-       여러 개의 시뮬레이터와 검증

 

5가지 모두 기존의 ‘단일’ 소프트웨어에 사용하던 검증 방법이 ‘다중 버전’으로 달라지면서 기존 검증 방법과 일부 혹은 전체가 달라질 가능성을 가지게 된다. 물론 경우에 따라서는 기존 검증 방법의 변경없이 그대로 사용될 수도 있을 것이다. 이러한 판단에 도움을 주기 위해서 DO-178에서 각각에 대해서 좀 더 자세하게 설명하고 있다. 그 내용을 확인해 보자.

 

①     다중 버전 비유사성 소프트웨어에 대한 검증의 독립성

 

두 개의 버전으로 소프트웨어를 개발한다고 해 보자. 이 경우 각각의 버전으로 개발되는 과정은 지금까지 우리가 살펴본 DO-178 가이드라인에서 제시한 다양한 지침을 참고해서 독립적으로 개발된다. 이때 각각의 소프트웨어 버전에 대한 검증이 이루어 진다면 그 자체로 소프트웨어 개발 프로세스의 독립적인 검증활동이 되는 것이다. 결국은 이것이 다중 버전 비유사성 소프트웨어에 대한 검증의 독립성이다. 구체적으로는 다음과 같은 활동이 수행된다.

 

a.      지원자는 제한된 상호작용을 하는 서로 다른 팀이 각각의 소프트웨어 버전에 해당하는 소프트웨어 요구사항, 설계 그리고 소스코드를 개발한다는 것을 보여줌

b.     독립적인 시험 커버리지 분석(Test Coverage Analysis)은 여전히 하나의 버전으로 수행하는 것처럼 수행

 

위의 설명 중 b의 경우는 시험 자체는 독립적으로 진행되더라도 결국은 서로 다른 버전이 함께 돌아가는 하나의 시스템을 기준으로 커버리지를 달성해야 한다는 의미이다.

 

참고로 DO-178 가이드라인에는 독립성을 깨뜨릴 수 있는 상황에 대한 구체적인 예시는 없지만 위의 설명을 기준으로 한 필자의 판단으로는 만약 독립적으로 개발하고 있는 두 팀이 각자의 개발 과정에서 유사한 부분이 있다고 해서 한쪽에서 진행한 프로세스나 결과를 그대로 받아들이는 경우가 있다면 여기에서 설명하는 취지의 독립성을 저해할 수 있는 예가 아닐까 싶다.

 

②     다중 프로세서에 관련된 검증

 

단일 소프트웨어의 경우 하나의 프로세서에서 구동되지만 다중 버전 비유사성 소프트웨어의 경우에는 여러 개의(최소 두 개 이상) 프로세서에서 구동된다. 이 경우 프로세서와의 호환성을 어떻게 확인할 수 있을까? 이에 대해서 DO-178 가이드라인에서는 결과적으로 여러 개의 프로세서가 동작하고 있는 상태에서도 결과물에 대한 확인을 통해서 올바른 출력을 만들어 낸다는 것을 보장하는 방법을 제시하고 있다. 아래는 그에 대한 설명이다.

 

해석을 보자.

 

이 검증은 다중 버전의 출력이 요구사항 기반 시험 케이스에서 상호 비교되는 통합시험으로 구성된다.

 

즉 요구사항 기반의 통합시험을 수행하면서 다중 버전의 소프트웨어가 제대로 된 결과를 내는지를 상호 비교하면서 검증을 하는 것이다. 이를 통해서 여러 개의 프로세서가 존재하는 상태에서 구동하면서도 제대로 동작한다는 것을 보여주게 된다. 최종적으로는 다음과 같은 활동들이 완료되어야 한다.

 

a.      동등한 에러 탐지가 달성된다는 것을 보여주어야 함

b.     각각의 프로세서가 서로 다른 개발자에 의해서 설계되었다는 것을 보여주어야 함

c.      다중 버전의 출력이 동등하다는 것을 보여주어야 함

 

③     다중 버전 소스 코드에 대한 검증

 

DO-178 에서는 레벨에 따른 차이가 있긴 하지만 구조적 커버리지 분석을 반드시 수행해야 한다. 다중 버전 소스 코드 역시 이를 수행해야 하는데 각각에 대한 수행은 과정에 따라서 진행하면 되지만 문제는 혹시라도 다른 버전의 소스가 포함될 여지가 없는가를 확인해야 한다는 점이다. 컴파일이나 링크 혹은 다른 방법으로 기존 소스코드와는 다른 코드가 추가되는 경우가 그것인데 DO-178 가이드라인에서는 지원자가 아래의 활동을 완료한다면 구조적 커버리지 분석을 수행하지 않아도 된다고 설명하고 있다.

 

a.      각각의 소프트웨어가 서로 다른 프로그래밍 언어를 사용해서 코딩되었다는 것을 보여줌

b.     사용된 각각의 컴파일러가 서로 다른 개발자에 의해서 사용되었다는 것을 보여줌

 

소스코드와 관련해서 DO-178에서 중요한 것 중 하나는 컴파일을 수행하면 소스코드에 의도하지 않은 코드가 추가되거나 변경되지 않느냐에 대한 부분이다. 앞서 이에 대한 부분을 살펴본 바가 있는데 다중 버전 소스 코드의 경우에는 하나의 소스코드와 관련된 부분이 다른 소스코드에 영향을 주지 않는지를 확인하는 것이 중요하다. 위의 활동을 수행함으로써 그에 대한 가능성을 근본적으로 차단하는 것이라고 이해할 수 있다.

 

④     다중 버전 비유사성 소프트웨어를 위한 툴인증

 

만약 소프트웨어 개발 프로세스에서 사용되는 여러 개의 소프트웨어 툴들이 비유사성을 가지고 있다는 증거를 제시할 수 있다면 다중 버전 비유사성 소프트웨어를 위한 툴인증은 변경될 수 있다. 이는 비유사성 소프트웨어 툴을 사용하는 여러 개의 소프트웨어 버전의 개발에서 동등한 소프트웨어 검증 프로세스 활동을 보여줄 수 있느냐에 달려있다. 지원자는 다음과 같은 활동을 완료해야 한다.

 

a.      각각의 툴이 서로 다른 개발자로부터 입수되었다는 것을 보여줌

b.     각각의 툴이 상이한 설계를 가진다는 것을 보여줌

 

⑤     여러 개의 시뮬레이터와 검증

 

다중 버전 비유사성 소프트웨어에 대한 검증을 위해서는 여러 개의 시뮬레이터가 사용된다. 이 때 여러 개의 시뮬레이터가 사용되면서 동등한 소프트웨어 검증 프로세스 활동을 보여준다면 시뮬레이터에 대한 툴검증이 단일 소프트웨어에 사용되는 시뮬레이터에 대해서 수행하는 방법과 달라지게 된다. 지원자는 다음과 같은 활동을 완료해야 한다.

 

a.      각각의 시뮬레이터가 서로 다른 팀에 의해서 개발되었다는 증거를 제공

b.     각각의 시뮬레이터가 서로 다른 요구사항, 서로 다른 설계, 그리고 서로 다른 프로그래밍 언어를 가진다는 증거를 제공

c.      각각의 시뮬레이터가 서로 다른 프로세서상에서 수행되는 증거를 제공

 

(3)    소프트웨어 신뢰도 모델(Software Reliability Models) (Section 12.3.3)

 

소프트웨어 신뢰도 모델(Software Reliability Models)이라는 방법에 대해서 DO-178 가이드라인에서는 다음과 같은 예를 들고 있다.

 

해석을 보자.

 

개발 측정기준에 기반한 소프트웨어 신뢰도를 예측하는 많은 방법들이 발표되어 왔다. 예를 들면, 소프트웨어 구조, 결함 탐지율 등.

 

예를 들긴 했지만 필자는 위의 내용에 대해서 잘 알지 못한다. 하지만 여기서 중요한 것은 이 대체방법은 DO-178 가이드라인에서 가이드하는 부분이 없다는 점이다. 따라서 이를 대체 방법으로 선택하는 경우에는 다른 대체 방법도 마찬가지지만 반드시 인증당국과의 협의를 거쳐서 승인을 받은 후에 적용할 수 있다. 하지만 DO-178 가이드라인에서 제시하는 지침이 없기 때문에 협의를 위한 자료를 전적으로 지원자가 알아서 준비해야 한다는 점을 생각하면 현실적으로는 차라리 다른 대체 방법을 선택하는 것이 효과적일 것이다.

 

지금까지 대체방법에 대한 여러가지 내용을 살펴보았다. 다시 한 번 강조할 부분은 대체방법에 대해서는 필자가 아는 바가 많이 없다는 점이다. 그럼에도 이렇게 관련 내용을 소개하는 것은 우선 DO-178 가이드라인에서 공식적으로 제공하는 내용을 소개함으로써 혹시라도 이와 관련된 분들이 있다면 최소한 이런 게 있다더라 정도는 알 수 있도록 하기 위한 것이다. 그리고 상황이 된다면 DER을 통해서 이 부분에 대한 조언과 도움을 받을 것을 추천드린다. 추후 이 부분에 대해서 필자가 좀 더 알게 되면 전체적으로 다시 업데이트할 예정이다.