4. 위험 레벨

 

안전성 평가를 수행하는 SAE Standard ARP4761은 위험레벨 A, B, C 혹은 D를 결정한다. 때로는 고객이 직접 레벨을 지정하기도 한다. 위험 레벨을 낮추는 것에 대해서 설득력 있고 친절하게 이야기하는 것이 고객의 결정에 영향을 줄 수 있을까? 아마 아닐 것이다.

 

위험 레벨은 문서에 정의된다. 비공식적으로 말하자면, 레벨 A는 어떤 실패가 발생하게 되면 일부 혹은 모든 승객의 목숨을 잃게 만드는 가장 엄중한 레벨이다. 그 다음으로 레벨 B는 일부 사람들이 목숨을 잃게 될 수도 있고 레벨 C는 아무도 목숨을 잃지는 않지만 큰 부상이 있을 수 있다. 레벨 D에서는 작은 부상이 있을 수 있고 레벨 E에서는 비행 안전에 아무런 영향이 없다.

 

만약 당신이 레벨 E를 받았다면 DO-178B를 따르지 않아도 된다. 레벨 E로 지정을 하고 항공전자 시스템에 대해서 DO-178 혹은 DO-254를 적용하지 않는 것이다. 화장실 조명이나 승객 엔터테인먼트 시스템 같은 간단한 항목들이 레벨 E가 될 수 있을까? 항상 그렇지는 않다. 예를 들어 화장실 조명이 독립적인 여러 전원에 연결되어서 꺼지는 일이 절대 없도록 할 수 있다. 만약 하나의 소스로부터 전원이 끊어지더라도 백업으로 배터리가 있는 것이다. 왜 이런 중복을 가지는 걸까? 지상에서 항공기 객실 내부에 연기가 가득 찬 상황을 가정해 보자. 승무원은 항공기를 빠져나갈 것을 승객들에게 요청할 것이다. 이때 캄캄한 화장실에서 문을 열기 위해 우왕좌왕하면서 갇혀 있는 것을 누구도 원하지 않을 것이다. 그래서 별 것 없어 보이는 화장실 조명조차도 레벨 D 인증을 받게 된다.

 

의자 뒤의 비디오 스크린과 같은 승객 엔터테인먼트 시스템은 어떨까? 생명 유지 시스템의 오작동으로 비행중에 항공기 전체로 연기가 퍼지기 전까지는 중요하게 여겨지지 않았다. 연기가 조종실까지 다다르면서 결국에는 치명적인 사고를 일으키고 말았다. 나중에 조사관은 그 엔터테인먼트 시스템이 중요한 조종 시스템으로 연결되는 주 전원 버스를 공용으로 사용하고 있다는 것을 발견했다. 그래서 위험레벨은 전혀 관계없어 보이는 시스템 사이에서 조차도 매우 중요할 수 있다.

역주) 위험레벨에 대해서 화장실 조명과 엔터테인먼트 시스템을 예로 들었는데 항공기에 탑재되는 소프트웨어나 하드웨어도 결국은 마찬가지이다. 복잡하게 얽혀 있는 시스템 간의 연동에 따라서는 레벨 A가 될 수도 있고 레벨 B가 될 수 있는 것이다. 심지어는 같은 소프트웨어도 다른 시스템과 어떻게 연동하느냐에 따라서는 레벨 D로도 결정될 수 있다. 물론 이 때 중요한 것은 시스템 안전성 분석과 함께 시스템 설계를 어떻게 하느냐가 될 것이다. (참고 포스팅: 29 DO-178과 System Safety (1))

 

위험 레벨 피라미드

 

레벨 A, 치명적인, 때때로 비행기와 승객을 모두 잃게 되는 결과를 낳을 수 있으며 단지 승무원에게 너무 많은 부하를 주는 것으로도 발생할 수 있다. 어떤 기능이 고장이 나서 갑작스레 조종사는 그 문제를 다루는 데 너무 정신이 없어지면서 치명적인 상황으로 빠져들 수 있다. 시스템 문제나 혹은 오류 지시기가 어떤 데이터를 놓치는 것에만 해당하는 것이 아니다. 단지 조종사가 항공기 조종을 유지할 수 없는 너무 많은 일이 생기는 것 만으로도 원인이 될 수 있다.

역주) 항공기 사고의 원인을 생각하면 일반적으로 엔진 고장과 같은 아주 심각한 항공기 결함을 생각하게 된다. 그런데 레벨 A에 대한 위의 설명을 보면 그런 것뿐만 아니라 특별한 고장이 아니더라도 승무원이나 조종사가 비행에 필요한 일을 하지 못할 정도로 다른 일이 발생하는 경우도 같은 레벨로 위험할 수 있다고 말하고 있다. 이처럼 항공기의 안전과 관계된 고려사항은 일반적으로 생각하는 범위를 훨씬 넘어서는 방대한 범위라는 것에 유의해야 한다. 그래서 항공기의 안전성 분석(평가)이 중요한 것이다.

 

레벨 B, 위험한/심각한, 모든 사람이 목숨을 잃을 수 있지만 그런 위험이 잠재적이라는 점에서 레벨 A와 다소 차이가 있다.

레벨 C, 주요한, 사람들이 부상을 입거나 항공기를 마음대로 컨트롤 할 수 없는 상황이 될 수 있다.

레벨 D, 사소한, 어떤 영향이 있을 수 있지만 항공기 자체가 극복할 수 있고 조종사가 컨트롤을 유지할 수 있다.

레벨 E, 영향이 없다. 시스템 안전성 평가 프로세스가 이러한 위험 레벨을 결정한다. 만약 레벨 E라면 그 레벨의 무언가 발생한다는 것이고 그것을 정당화할 필요가 있다. FAA에 가서 그저 “이것은 레벨 E입니다. 전 아무것도 하지 않아도 됩니다.”라고 말할 수는 없다. 당신의 고객이 그것을 정당화하지 않으면 당신이 그것을 해야 할 것이다.

 

일반적으로 제품을 설계하거나 TSO(기술표준품)를 획득하려고 할 때에는 정당성이 필요하다. DO-178B 부록 A는 각각의 레벨에 대해서 무엇이 필요한지가 기술되어 있는데 그것이 사람들이 우선적으로 학습해야 할 부분이다. 거기에서 혹시라도 지름길을 발견할 지 모른다. 하지만 장담하건데 그 프로세스를 따르는 것 보다는 그 지름길에 대하서 논쟁하고 정당화하느라 대부분의 시간을 소모하게 될 것이다. 지름길은 없다. 가이드라인에 있는 부분을 그대로 따르는 것이 비용이 덜 들고 더 빨리 할 수 있을 것이다.

 

위험 레벨 비교

DO-178B 특징	레벨 A	레벨 B	레벨 C	레벨 D
독립 레벨	High	Medium	Low	Very Low
하위레벨 요구사항의 필요성	Yes	Yes	Yes	No
Statement 구조적 커버리지	Yes	Yes	Yes	No
Decision/Condition 구조적 커버리지	Yes	Yes	No	No
MCDC 구조적 커버리지	Yes	No	No	No
형상관리	Tight	Tight	Medium	Low
소스와 바이너리 상관관계	Yes	No	No	No
타겟 프로세스와 관련된 요구사항	Yes	Yes	No	No
아키텍처 & 알고리즘 검증	Yes	Yes	Yes	No
코드 리뷰	Yes	Yes	Yes	No
SQA 전이 기준	Yes	Yes	Yes	No

 

Statement 구조적 커버리지. 레벨 A, B, 그리고 C에서 필요하다.

Decision condition 구조적 커버리지. 레벨 C에서는 필요하지 않으며 오직 레벨 A와 B에서 필요하다.

MCDC 구조적 커버리지는 오직 레벨 A에서만 필요하다. 이것은 측정기준 프로세스로써 DO-178B의 독특한 요구사항이다. 이것은 시험이 아니라 분석 프로세스이다. 많은 사람들이 구조적 커버리지를 달성하기 위해 반복해서 시험해야 한다고 생각한다. 하지만 그것은 단순한 커버리지가 아니며 시험으로 얻어야 하는 것도 아니다. 다른 준비된 대안이 없다면 분석으로 완전하게 할 수 있다.

역주) 저자의 말처럼 구조적 커버리지는 DO-178에서 요구하는 독특한 항목이다. 물론 기존 개발에서도 사용되어온 방법이긴 하지만 커버리지 100%를 만들기 위해서 형식적으로 진행된 부분이 많았다. 위의 설명은 DO-178에서는 시험으로 커버리지를 얻을 수 없는 부분은 분석이라는 방법을 사용해서도 가능하다는 것을 말하고 있다. 구체적인 내용은 다른 곳에서 설명한다. (참고 포스팅: 4. DO-178과 커버리지 분석(Coverage Analysis))

 

형상관리는 위험레벨이 높아지면 더 엄격해 진다. 대부분의 DER(그리고 FAA 사람들)은 기본적으로 “위험 레벨을 높였으니까 더 엄격하게 하기를 원합니다.”라고 말한다.

 

그러나 “엄격함”은 모호한 단어이다. DO-178B는 레벨 A, B, 그리고 C 사이에 형상관리의 주된 차이점을 지적하지 않지만 레벨 C에서부터 B로, A로 높아지면 더 엄격함이 필요해 진다. 다른 말로 하자면 문제점을 리포트하는 것이나 형상관리 그리고 형상 상태를 감사하는 프로세스가 더 정확해져야 한다는 것이다. 그것은 더 많은 산출물과 더 높은 레벨의 문서 작성, 변경 관리를 요구한다.

 

우리는 지금껏 이들 레벨에 대한 형상관리에 대해서 서로 다른 프로세스를 쓴 사람을 본적이 없다. 하지만 DER은 당신이 만약 레벨 A를 수행하고 있다면 그 프로세스에 대해서 더 나은 수행을 기대할 것이다. 반면에 레벨 C를 수행한다면 크게 신경쓰지 않는 경향이 있다.

 

소스와 바이너리 상호관계는 레벨 A에서 유일하게 수행한다. FAA에서는 항공기를 만드는 사람들에게 어떤 질문들에 대해서 답을 하기 위한 레포트를 발행하고 있다. 예를 들어 컴파일러가 사용될 때 많은 사람들은 호스트 기반의 컴퓨터를 사용해서 호스트 시스템 상에서 시험하기를 원하고 그래서 크로스 컴파일링이 사용된다. 또한 소프트웨어 개발자들은 사이즈를 줄이거나 실행 속도를 높임으로써 코드의 실행을 최적화하기를 원한다. 그것은 “최적화”라 불리는 컴파일 타임 옵션을 통해서 수행된다. 하지만 컴파일러를 시험하거나 인증을 받을 수 있을까? 안된다. 그 일은 단순하게는 이성적으로 시도하기에는 너무 거대하고 어떤 식으로든 컴파일러를 완전하게 시험할 수 있다고 생각한다면 그것은 농담을 하는 것과 마찬가지다. 더구나 컴파일러의 결과물은 시험이 되기 때문에 컴파일러는 암묵적으로 검증이 되는 것이다. 하지만 레벨 A 시스템에 대해서는 컴파일러를 정말로 신뢰할 수 있어야 한다. 그래서 레벨 A에 대해서는 엄격함이 더해져서 하나의 단계가 추가된다. 바로 “소스와 바이너리의 상호관계”이다. 컴파일러로부터 나온 바이너리가 의도된 소스코드와 연결되는 것을 명시적으로 검증해야 한다.

 

만약 호스트에서 최종 승인을 위한 시험이 진행된다면 그 시스템은 항공기에 실제로 탑재될 수 있을까? 안된다. 왜냐하면 최종 “신뢰를 위한” 시험은 최종 타겟용 바이너리를 사용해서 진행되어야 하기 때문이다. 시험에 대한 신뢰를 얻기 위해서 바이너리와 소스를 비교한 결과를 보여주어야 한다. 이를 위해서는 타겟상에서 언제나 같은 컴파일러를 사용하는 것이 최선이다. 레벨 A를 위해서 타겟상에서 시험함으로써 소스가 바이너리에 올바로 반영되는 것이다. 바꾸어 말하면 당신은 소스를 작성하지만 컴파일러는 바이너리로 데이터를 입력하는 것이다. 대응되는 바로 그 소스에 대해서 바이너리가 정확하다는 상호관계가 필요하다.

역주) 소스와 바이너리의 상호관계라는 것은 결국은 바이너리와 소스코드가 1:1로 매칭된다는 것을 말한다. 레벨 A에서는 그것에 대한 증거를 요구하는 것이다. 실제로 이는 상당히 어려운 작업이다. 그래서 도구의 도움이 없으면 거의 불가능하다고 할 수 있다. (참고 포스팅: 10. DO-178과 커버리지 분석 – Source Code to Object Code Traceability (1))

 

소스코드 생성툴은 DO-178B의 단계를 자동화하고 그래서 모든 프로그램 상에서 당신이 직접 수행할 필요가 없기 때문에 인증을 받을 필요가 있다. 일단 툴이 인증되면 코드가 어떻게 생성되고 컴파일 되며 오브젝트 코드가 어떻게 나오는지를 알기 때문에 생성된 소스코드를 그대로 사용하게 된다. 코드를 생성하고 그런 프로세스를 체크하는 네 개 혹은 다섯 개의 시스템이 있는데 그 시스템들은 소스와 바이너리를 비교하는 기능을 추가해 왔다.

 

FAA는 제품화된 툴을 인증하지는 않는다. 더 높은 레벨의 위험도로 갈수록 더 많은 증빙과 더 고난이도의 업무량이 필요하게 된다. 레벨 C와 그 이상에 대해서는 코드 리뷰가 필요하지만 레벨 D는 필요하지 않다.

 

SQA 전이 기준. 코드 및 아키텍처 요구사항에 대한 많은 표준적인 QA 리뷰는 레벨 C에서 시작한다. 레벨 C에서 B, A로 올라가는 동안의 대부분의 작업은 구조적 커버리지 분석이다.

 

소프트웨어와 하드웨어의 위험도 레벨을 결정하는 것은 최상위 레벨 프로세스를 기반으로 한다. 예를 들면 소프트웨어 인증계획(PSAC)과 하드웨어 인증계획(PHAC)에 레벨 A라고 언급하는 것이다. 만약 내가 레벨 B의 상태라고 한다면, 더 이상 스스로 그것을 증명할 필요는 없지만 그것을 결정한 프로세스를 가리킬 것이다. 고객이 그것을 할 수 있고 당신은 그저 레벨 B라는 말을 들었을 뿐이다. 그걸로 끝이다 왜냐하면 당신 고객의 안전성 분석이 그 레벨 B 지정의 근거가 되기 때문이다.

 

시작부터 마지막 순간까지 위험 레벨은 전체적이고 꼼꼼한 안전성 분석 프로세스에 따라서 결정된다는 것을 기억하라. 그것은 전체 시스템과 내부 구성품으로의 안전성 분배를 결정하고 위험 레벨의 결정과 기본적인 시스템 아키텍처를 결정하게 한다.

역주) 저자의 설명자체가 그런 부분도 있지만 System Safety Assessment라고 하는 안전성 분석에 대해서 제대로 알지 못하는 상태여서 솔직히 이 부분에서의 해석이 완벽하지 않은 부분이 많다. 개략적인 느낌은 알겠는데 문장 하나하나를 명확하게 설명하기가 어렵게 느껴진다. 그렇더라도 결국은 위험도 레벨의 결정은 최상위 레벨인 시스템 안전성 분석에서 출발해서 그 하위 레벨의 소프트웨어, 하드웨어로 분리되어 할당된다는 사실이 이곳 설명에서의 핵심이다. (참고 포스팅: 29 DO-178과 System Safety (1))