9. 안전성 평가

 

시스템 안전성 평가는 Functional Hazard Assessments, Failure Modes and Effects Analysis, Reliability Assessments, preliminary Safety Analysis 그리고 Zonal Considerations를 포함하는 활동들이다. 이런 활동들을 통해서 안전성을 고려한 위험레벨을 얻고 아키텍처를 조정하기 위한 전반적인 시스템 안전성 평가를 만들어낸다. 프로그램이 소프트웨어와 하드웨어 라이프사이클로 들어가고 시스템 레벨 시험과 통합 시스템 레벨 검증 및 시험을 포함해서 가장 높은 레벨이 검증된다. 시스템 개발을 정의하는 프로세스들이 소프트웨어와 하드웨어를 위한 계획과 라이프사이클 프로세스들을 제공한다. 이들 계획의 상당수가 약간의 수정과 변경으로 재사용될 수 있다.

안전성, 시스템, 소프트웨어 & 하드웨어

 

역주) 시스템 안전성 평가(System Safety Assessment)는 DO-178을 시작하기 전에 항공기를 만드는 체계업체(우리나라는 KAI가 대표적)에서 먼저 진행해야 하는 부분이다. 위에서 간단하게 위험레벨과 아키텍처를 정한다고 되어 있지만 사실 거대한 항공기의 안전성을 분석하는 작업이므로 상상을 초월하는 어려운 작업이다. 여기서 그런 부분을 하나하나 자세히 설명하기는 어려우므로 더 알고 싶으신 분들은 구글링을 해보시기 바란다.   어쨌든 자세한 설명이 이어지겠지만 먼저 간단하게 정리해 보면 위의 그림에서 핵심은 시스템 개발이라는 박스다. 좌측의 안전성 평가로부터 위험레벨과 아키텍처에 대한 입력이 들어오는 것을 볼 수 있다. 실제로 이를 근거로 시스템 개발을 위한 설계가 이루어 진다. 그리고 이렇게 시스템 개발이 진행되면서 시스템을 구성하는 하위의 하드웨어와 소프트웨어로 각각의 요구사항이 전달되는 것을 볼 수 있다. 물론 여기에는 각각의 위험레벨도 포함된다. 시스템이 요구하는 대로 소프트웨어와 하드웨어가 개발되고 나면 다시 화살표가 위로 향하게 되는데 이는 소프트웨어와 하드웨어가 시스템에서 시험된다는 것을 의미한다. (물론 자체 시험도 하겠지만 결과적으로 시스템에서 시험하는 것이 기본이라는 의미이다.) 이 과정 중에서 소프트웨어의 개발에 대한 가이드라인을 제시하는 DO-178을 이 책에서 저자가 하나하나 설명하고 있는 것이다. DO-178을 파악하는 과정이 오래 걸리고 어렵겠지만 최소한 위의 그림을 참고해서 DO-178이 어느 위치인지를 인지하고 있어야 한다. (참고 포스팅: 29 DO-178과 System Safety (1))

 

앞선 다이어그램은 시스템 요구사항을 정의하기 전에 하나의 프로세스 단계로써 안전성 평가 프로세스가 어떻게 사용되는지를 보여주고 있다. 이상적으로는 안전성 평가는 어떠한 시스템 개발 이전에 완료되어야 한다. 그러나 현실에서 그리고 실제 시스템에서 이것은 때때로 반복해서 진행된다. 하지만 최종 제품은 안전성 분석의 고려사항이 반영될 필요가 있다.

 

안전성 평가 프로세스는 시스템 내부의 컴포넌트들과 서브컴포넌트들에 대해서 초점을 맞추는 작은 분석들의 연속이다. 아래의 다이어그램은 시스템 내부의 각각의 시스템과 컴포넌트들에 적용되는 안전성 분석 단계들의 집합을 통해서 계층적인 추상을 묘사한다.

 

 

역주) 시스템 안전성에 대해서는 필자가 별도로 포스팅한 자료가 있다. 중요한 것은 DO-178 인증을 받기 위해서는 소프트웨어에 대한 위험 레벨이 결정되어야 하는데 바로 이런 복잡한 과정을 통해서 최종적으로 위험레벨이 결정된다는 것을 이해하는 것이다. 이 글을 보시는 분들 중에 좀 더 자세한 내용이 궁금한 분들은 해당 자료를 참고해도 되고 아니면 구글링을 통해서 관련된 자료들을 찾아보는 것도 추천하는 방법이다.

 

만약 파생 요구사항이 추가되면 안전성 평가 프로세스로의 영향에 대해서 분석이 진행되어야 한다. 파생 기능의 실패 요인이 분석되고 위험 레벨과 아키텍처로의 영향이 결정되어야 한다.

역주) 사실 DO-178 관점에서 안전성 평가와 관련된 핵심은 바로 이것이다. 개발을 하다 보면 요구사항이 추가되거나 변경되는 경우가 많다. 이 때 그냥 요구사항 문서만 수정하는 것이 다가 아니다. 혹시 요구사항 수정으로 소스가 변경되면 이전에는 없던 버그가 발생할 수도 있는 것이고 자칫 그 버그 하나가 항공기를 추락시킬지도 모를 일이다. 이 문장은 이런 위험에 대해서 분석해야 한다는 것을 말하고 있다. 결국 위험분석을 다시 해야 한다는 것이고 이는 이전에 결정했던 위험레벨과 아키텍처가 변경될 수도 있다는 의미이다. 물론 보통은 소프트웨어의 요구사항 하나 변경한다고 해서 이 정도의 파장이 생기지는 않겠지만 이론적으로는 이런 부분까지 염두에 두고 있다는 점을 알고 있어야 한다.

 

항공전자 시스템에는 많은 기능들이 있는데 거기에서 두 개의 기능은 치명적인 오류를 가져올 수 있고 여섯 개의 기능은 위험한 항공기 오류를 일으킬 수 있다고 가정하자. 나머지 기능들은 항공기의 안전성에 사소한 영향을 미친다. 그들은 동일한 CPU상에서 언제나 서로 다른 기능과 프로세스를 수행하고 있다. 우리가 하고 싶은 것은 이들 기능들의 경계를 구분하는 것이다. 이것은 두 개의 기능은 레벨 A로 여섯 개의 기능은 레벨 B 그리고 나머지는 레벨 D로 구분해서 각각의 사이에 가상의 단단한 벽을 두는 것이다. 시간과 공간 파티션으로 분리함으로써 거기에서는 낮은 위험 레벨의 기능이 CPU 리소스를 모두 소모함으로써 더 높은 위험 레벨의 기능이 구동하지 못하도록 하거나 혼란스럽게 만드는 경우를 막을 수 있다. 그렇게 하기 위해서는 메모리 관리 유닛(MMU)을 가진 CPU가 가장 적절하다. PowerPC 계열과 같은 특정 프로세서는 그것을 가지고 있지 않으므로 제대로 골라야 한다.

역주) 여기서 이야기하는 파티셔닝을 이해하려면 ‘VxWorks653’ 에 대해서 알아보는 것이 가장 적합할 것이다. 전 세계에서 유일하게 DO-178 인증을 받은 파티션을 지원하는 OS이기 때문이다. 구글링을 해보면 영어이긴 하지만 그림이 포함된 여러 가지 설명을 쉽게 확인할 수 있다.

 

벽 혹은 파티션을 만들 수 있고 침범을 탐지/완화시킬 수 있는 메모리 관리 기능을 가진 실시간 운영체제(RTOS) 또한 필요하다. 서로 다른 위험으로 구분된 관리를 위한 파티션 구조는 복잡도와 개발 비용을 추가하지만 당신의 프로그램이 동일한 CPU 안에 위치하고 서로 다른 위험 레벨을 사용하기를 원한다면 파티션 시스템을 사용할 수 있다. 왜 이와 같은 추가작업과 비용이 발생하는 것일까? 세 가지 이유가 있는데 모두 다 오늘날 시스템에서는 그 중요성이 증가하고 있다. 바로 중량 감소, 전력 소비 감소 그리고 크기 감소이다. 오늘날, 모든 항공기 제조사와 개량 업체들은 그런 고려사항들에 대한 요구가 증가하고 있고 만약 당신이 그것을 따르지 않으면 당신의 경쟁업체가 그 기회를 가져가게 될 것이다.

역주) 구형 항공기에도 수많은 시스템들이 포함되어 있지만 그들은 각각 물리적으로 분리되어 있는 경우가 많았다. 안전이라는 관점에서는 최소한 물리적으로는 완벽하게 분리되어 있는 것이다. 대신 모든 것을 따로 만들려면 그 만큼 비용이 많이 들었다. 하지만 기술의 발전으로 그 동안 분리되었던 시스템들을 합칠 수 있게 되면서 획기적으로 비용을 줄일 수 있게 되었다. 하지만 여러 시스템이 하나로 합쳐지면서 안전성에 대해서는 더 위험해지는 결과가 되고 만 것이다. 이런 이유로 파티션이 지원되는 OS가 필요하게 되었다.

 

물리적인 핀을 선택해서 경계를 설정하는 파티션 시스템 또한 사용할 수 있다. 이를 테면 외부 핀이 연결되지 않으면 소프트웨어가 플래시 혹은 램으로 아예 로딩조차 되지 않는 것이다. 물론 핀이 연결되는 것은 항공기가 지상에 있을 때이다. 조심스럽게 골라야 한다. 파티션 시스템은 매우 중요하다.

 

우리가 보아 온 바로는 소프트웨어 위험성은 레벨 A에서부터 E(치명적인, 위험한, 주요한, 사소한 그리고 영향이 없는)까지 다섯 가지로 나누어 진다. 반면에 하드웨어는 일반적으로 ‘심각한, 필수적인, 필수적이 아닌’의 세 가지 레벨로 구분된다. 그러나 위험한 시스템이 모두 레벨 A 소프트웨어만 가지는 것은 아니다. 예를 들면 단지 하드웨어의 문제점을 기록만 하는 소프트웨어를 가진 위험한 항공 시스템을 고려해보자. 그것은 아무것도 컨트롤하지 않는다. 이제 당신은 그 소프트웨어가 레벨 D로 구동한다는 것을 보여줄 수 있을 것이다. 시스템 아키텍처를 살펴보고 그것이 단일 경로의 오류를 제거하기 위해 위험 레벨과 아키텍처 정의를 확인하는 반복된 프로세스인지를 확인하라.

역주) 실제 현장에서는 DO-178 수행을 위한 위험 레벨을 고객이 아니라 소프트웨어 개발 업체에서 알아서(?) 정해야 하는 경우가 많다. 아무리 알아서 하라고 하더라도 최소한 설명을 할 수 있어야 하므로 위에서 말한 것과 비슷한 검토를 해 볼 수 있다. 즉, 개발하는 소프트웨어가 항공기 내에서 실제 사용된다고 가정하면 과연 어느 정도 중요한 기능인지를 검토해 보는 것이다. 일반적으로 예상할 수 있는 범위에서 개발하는 소프트웨어의 레벨을 짐작할 수는 있다. 물론 당연히 공식적인 근거는 될 수 없다.

 

안전성 평가 개념   시스템 위험 레벨 수립 치명적인, 위험한, 주요한, 사소한 설계 보증 레벨(A, B, C, D, 혹은 E)을 결정 아키텍처 정의를 제공하기 위한 프로세스 반복 설계 보증 레벨을 낮추기 위한 아키텍처 정의를 사용 안전성은 제공된 기능으로부터 나옴 기능의 고장, 잠재적 고장은 계층 추상화의 모든 레벨에서 평가됨

 

세 가지 핵심 안전성 평가 프로세스   Functional Hazard Assessment(FHA) Preliminary System Safety Assessment(PSSA) System Safety Assessment(SSA)

 

아키텍처와 파티션과 관련된 또 다른 예를 살펴보자. 우리는 SAE ARP4754 기반의 파티션 설계를 가지고 있다. 하나의 기능은 ‘위험한’ 것이고 다른 하나는 ‘주요한’ 것이다. 따라서 하나는 레벨 B이고 다른 하나는 레벨 C이다. 그것들은 각각 기능 A와 기능 B로 구현된 독립적인 기능들이고 두 개의 서로 다른 시스템으로 파티션되어 있다. Functional Hazard Analysis는 기능 A만 따로 조사하고 다음으로 기능 B를 따로 조사한다. 둘 다 실패하면 가장 높은 위험 레벨로 가게 된다. 그들을 개별적으로 바라보자. 하나의 기능에서의 실패는 다른 것에 영향을 줄 수 없다. 왜냐하면 하드웨어가 다르고 분리된 채널과 분리된 전원을 가진 분리된 보드상에 있기 때문이다. 그것은 적절하게 파티션된 설계를 나타낸다. 기억하라. 기능 A는 레벨 B였고 기능 B는 레벨 C였다.

 

개발/설계 보증 결정   Example 1a: 파티션된 설계   (SAE ARP4754, section 5.4.1.1과 RTCA DO-178B section 2.3.1 참조)   Fa와 Fb는 시스템 Sa와 시스템 Sb로 각각 구현된 독립된 기능임. Sa와 Sb는 파티션되어 있음.

 

개발/설계 보증 결정   Example 1a: 파티션된 설계(계속)   SAE ARP4754 파티션을 포함한 전체적인 시스템에 대해서 레벨 B   Sa는 ‘위험한’ 영향과 관련된 레벨 B이다.   Sb는 ‘주요한’ 영향에 일치하는 레벨 C이다. RTCA DO-178B 만약 기능 Fa와 Fb가 소프트웨어에 구현된다면:   Sa의 소프트웨어는 레벨 B이다. Sb의 소프트웨어는 레벨 C이다.   만약 파티션 보호가 소프트웨어에 포함된다면: 파티셔닝 소프트웨어는 레벨 B이다.

 

채널 1과 채널 2, 시스템 A와 시스템 B, 기능 A와 기능 B가 있다고 가정하자. 어떤 기능을 위해서 둘 다 구동되어야 한다. 만약 하나가 실패하면 그 기능은 실패이고 따라서 여기에는 어떤 상관관계를 가지고 있다. 이런 이유로 그들 간의 통신을 위한 최상위 위험 레벨을 설계하는 것에 조심해야 한다.

 

개발/설계 보증 결정   Example 1b:   파티션된 설계(SAE ARP4754, section 5.4.1.1과 RTCA DO-178B section 2.2.3과 2.3.1 참조)

 

위의 그림은 설계 보증 레벨과 발견되지 않는 실패의 가능성을 정의한다. 소프트웨어에 있어서 그 숫자는 측정될 수 없다. 아니, 사실은 소프트웨어 실패의 가능성은 소프트웨어가 실패할 수 있다는 것을 의미하는 1이다. 그것은 시스템 안전성 분석 프로세스와 시스템 자체에 중요한 실패가 발생한다는 것이다. 일반적으로 항공전자 시스템은 소프트웨어 바이너리의 무결성을 빨리 체크하기 위해서 전원이 인가될 때 자체 시험을 수행하며 이러한 자체 시험은 구동 중에도 때때로 백그라운드에서 계속해서 수행된다. 체크섬이 주된 기술로 사용되지만 최근에는 CRC 즉 순환중복검사가 사용된다. CRC는 바이너리에 적용되는 수학적인 알고리즘으로 정확한 바이너리 이미지와 관련된 유일한 정수값을 만들어 낸다. CRC값은 타겟 바이너리내에 저장되며 구동 시험 동안에 다시 CRC 시험이 이어서 계산된다. CRC값은 일치해야 하며 만약 그렇지 않다면 바이너리에 문제가 생긴 것이다. 이 알고리즘에서는 하나 혹은 그 이상의 비트가 변경되면 전체 CRC값이 변경되고 그것은 실패를 나타낸다.

 

각각의 DO-178B 위험레벨은 실패의 가능성과 관련되어 있다. 위험레벨이 증가하면 대응하는 실패의 가능성은 줄어들어야 한다. 안전성 평가 프로세스는 이 모든 것과 그 이상을 고려한다. 이 책은 DO-178B와 DO-254를 주로 기술하므로 안전성 평가 프로세스는 더 이상 기술하지 않지만 이 프로세스는 항공전자 소프트웨어와 하드웨어 개발에 치명적인 시작점이며 완전하게 고려되고 적용되어야 한다.

역주) 이상의 설명과 그림은 안전성 평가 방법의 극히 일부를 보여주고 있다. 여기서 핵심은 내가 개발하는 소프트웨어가 고장났을 때 항공기에 어떤 영향을 주느냐이다. 다른 소프트웨어가 동작하지 못하게 할 수도 있고 아무런 영향 없이 자신만 죽어(?) 버릴 수 있다. 소프트웨어를 더 안전하게 만드는 방법은 단순히 해당 소프트웨어의 위험레벨을 높게 정해서 더 엄격한 기준으로 만드는 것 이외에도 다른 직간접적인 방법을 사용할 수 있다. 위에서 나오는 체크섬이나 CRC도 그런 다양한 방법 중의 하나이다. 안전성을 위해서 소프트웨어 자체를 수정해서 해결하는 것이 아니라 특정 기술을 추가적으로 적용하는 것이다. 혹시 기회가 된다면 함께하는 DER에게 System Safety Assessment가 어떻게 수행되어서 DO-178로 이어지는 지 물어볼 것을 추천드린다.