28. DO-178과 System Safety (2)

 

(1)   System Safety와 ARP4761

※ 출처) Guidelines for Development of Civil Aircraft and Systems – Introduction to ARP4754A, Esterline

 

앞서 위의 그림을 통해서 시스템에 대한 중요성이 인식된 것이 소프트웨어 지침인 DO-178이 나온 이후라고 설명한 바가 있다. 그 결과가 ARP4754이고 ARP4761은 ARP4754와 거의 비슷한 시기에 발행된 것을 알 수 있다. 참고로 ARP4754가 ARP4754A로 업그레이드가 된 것처럼 ARP4761 역시 업그레이드가 진행 중으로 알려져 있는데 아직은 공식적으로 릴리즈되지 않은 상태이다. (2019년 3월 기준)

 

이제 본격적으로 ARP4761에 대해서 알아보자.

 

①     ARP4761에 대한 이해

 

먼저 SAE International에서 구할 수 있는 ARP4761 문서의 모습이다.

 

참고) 참고로 필자가 본 자료를 정리하는 시점(2019년 3월)을 기준으로 일부 자료에서는 ARP4761A가 발행된 것으로 나오는데 SAE International 사이트에서 확인한 바로는 아래와 같이 아직 공식 릴리즈는 되지 않은 상태였다. 착오 없으시기 바란다.

 

문서의 타이틀을 보자.

 

“GUIDELINES AND METHODS FOR CONDUCTING THE SAFETY ASSESSMENT PROCESS ON CIVIL AIRBORNE SYSTEMS AND EQUIPMENT”

 

문서명치고는 상당히 길기는 하지만 결과적으로 이 문서의 성격을 정확하게 보여주고 있다. 해석을 보자.

 

“민간 항공 시스템과 장비상의 안전성 평가 프로세스를 수행하기 위한 지침과 방법들”

 

문서명만 보더라도 이 문서가 어떤 용도이고 어떤 내용을 담고 있는지 정도는 짐작할 수 있을 것이다. 결론적으로 앞서 설명한 ARP4754A가 개발프로세스와 관련된 전반적인 내용을 담고 있고 그 안에서 각각의 프로세스와 관련된 안전성 평가 활동이 소개되는 수준이라면 ARP4761은 그러한 안전성 평가 활동의 구체적인 내용을 담고 있다고 할 수 있다.

 

따라서 ARP4754A를 이해하기 위해서는 ARP4761을 함께 알아야 한다. 참고로 두 지침서의 관계를 항공기 시스템 개발 라이프사이클 전체로 보자면 아래와 같이 나타낼 수 있다.

 

※ 출처) https://www.curtisswrightds.com/news/blog/system-safety-certification-using-safety-certifiable-cots.html

 

위의 그림을 보면 소프트웨어 개발 및 하드웨어 개발 이전에 상위 단계에서 체계 개발과 연계된 시스템 안전성 평가가 먼저 수행되어야 한다는 것을 확인할 수 있다.

 

이번에는 ARP4761 문서의 목차를 보자.

 

3.     SAFETY ASSESSMENT PROCESS 3.1                Safety Assessment Overview 3.2                Functional Hazard Assessment (FHA) 3.3                Preliminary System Safety Assessment (PSSA) 3.4                System Safety Assessment (SSA) 3.5                Validation Means Used for Aircraft Certification 4.     SAFETY ASSESSMENT ANALYSIS METHODS 4.1                Fault Tree Analysis/Dependence Diagram/Markov Analysis (FTA/DD/MA) 4.2                Failure Modes and Effects Analysis (FMEA) 4.3                Failure Modes and Effects Summary (FMES) 4.4                Common Cause Analysis (CCA)

 

앞서 보았던 ARP4754A와는 사뭇 다른 구성을 확인할 수 있다. 비슷비슷하면서도 어려운 약어들이 넘쳐나서 3장과 4장이 잘 구분이 안될 수도 있을 것 같은데 단순하게 보자면 3장은 시스템 안전성 평가의 핵심 프로세스(Process) 세 가지를 설명하고 있고 4장은 안전성 평가에 사용되는 기법(Methods)들을 세부적으로 구분해서 설명하고 있다.

 

이제 앞서 보았던 APR4754A의 위치를 보여주었던 그림을 다시 한 번 보자.

 

그림 27 시스템 개발프로세스에서 ARP4754A의 위치

※ 출처) https://kr.mathworks.com/solutions/aerospace-defense/standards/arp-4754.html

 

실질적인 개발 프로세스는 ARP4754A, DO-178C, DO-254를 통해서 진행되며 그 과정에서 ARP4761이 안전성 평가로 관여한다는 것을 확인할 수 있다. 혹시 ARP4761에 대해서 구글링을 해보면 아래와 같은 형태의 그림을 더 많이 찾을 수 있을 것이다. 결론적으로 같은 맥락을 보여주는 그림이라고 할 수 있다.

 

※ 출처) https://www.semanticscholar.org/paper/A-Comparison-of-STPA-and-the-ARP-4761-Safety-1-Wilkinson-Fleming/0eb2ce8003b6e62500bcfecc268718872a49254f/figure/0

 

 

참고) 사실 위에서 비교한 두 그림이 어떤 분들에게는 전혀 다르게 보일수도 있을 것 같다. 특히 ARP4761에 대해서 하나는 DO-178, DO-254와 직접 연결되어 있는데 다른 그림에서는 단순히 ARP4754로만 연결되어 있고 그것도 상위에 위치하고 있다.   여기서 한 가지 예를 들어 보자. 만약 항공기에 탑재되는 소프트웨어가 변경되는 경우 과연 그 변경은 단순히 소프트웨어에만 한정되는 것일까? 그렇지 않다. 소프트웨어의 변경은 반드시 시스템 차원에서 다시 검토가 되어야 한다. 즉, 소프트웨어를 변경해도 되는지를 시스템에서 먼저 확인해서 결정해야 하는 것이다. 이 과정에서 ARP4761에서 설명하고 있는 안전성 평가에 대한 다양한 방법들이 사용된다. 그리고 최종적으로 판단을 내려서 소프트웨어 수정에 대한 Confirm이 떨어지는 것이다.   이런 관점에서 보자면 ARP4761은 비록 시스템 레벨에서 수행되는 활동이라고 하더라도 DO-178과 직접 관련된다고 할 수 있는 것이다. 따라서 위의 두 가지 그림은 같은 의미를 담고 있다고 할 수 있다.   굳이 이렇게 부연 설명까지 넣으면서 다른 그림을 예시로 든 것은 해석의 다양성을 여러분들이 확인하도록 해주고 싶었기 때문이다. 그리고 그런 과정을 통해서 보다 확실한 이해를 돕고자 하는 의도이다.

 

여기에서 앞서 보았던 V모델을 다시 한 번 보자.

 

그림 28 ARP4754A에서 설명하는 항공전자시스템 개발에 대한 V모델

※ 출처) https://www.researchgate.net/figure/Avionics-V-Model-extract-from-the-ARP4754A-12_fig1_310776068

 

복잡하기 그지없어 보이는 위의 그림이 결론적으로는 ARP4754A를 통해 제시되는 시스템 개발 프로세스와 그 과정에서 ARP4761에서 제시하는 안전성 평가 방법들이 어떤 부분에 적용되고 있는지를 보여주고 있는 것이다. 가장 하위 단계에서 소프트웨어와 하드웨어 개발이 진행되는 것도 확인할 수 있다. 복잡하게 보여서 어렵기는 하겠지만 부분적인 면으로만 매몰되지 말고 수시로 큰 그림을 보도록 애써 보자.

 

②     ARP4761의 이해를 위한 배경 설명

 

ARP4761에 대한 구체적인 설명에 들어가기에 앞서 앞으로 설명될 ARP4761에 대한 내용을 이해하기 위해서 기본적으로 가지고 있어야 할 개념들을 먼저 살펴보도록 하자.

 

n  안전성(Safety)과 신뢰성(Reliability)

 

첫 번째는 바로 ‘안전성(Safety)’과 ‘신뢰성(Reliability)’에 대한 개념이다. 단어 자체로만 보자면 대충 무엇을 말하는지 알 수 있겠지만 앞으로의 설명에서 이들이 어떤 의미를 담고 있는지를 보다 분명히 할 필요가 있어 보인다. 전문적인 용어 설명을 할 수도 있지만 좀 더 직관적인 형태로 간략하게 정리하자면 다음과 같다.

 

-       신뢰성(Reliability): 원하는 기능을 제대로 수행할 수 있음을 보장하는 것

-       안전성(Safety): 원하는 기능을 수행하는 것과 관련된 모든 것들이 안전하다는 것을 보장하는 것

 

단순히 어떤 기능을 수행하는 것을 넘어서서 그 과정에서 안전에 대한 담보도 필요하다는 것을 말하고 있다.

 

n  시스템 안전성 평가를 고려해야 하는 범위

 

다음은 ARP4761에서 설명하는 시스템 안전성 평가를 어느 정도의 범위까지 고려해야 하는가에 대한 부분이다. 지금까지는 주로 항공기 시스템의 관점을 중심으로 모든 설명을 해왔다. 하지만 앞서 ‘안전성’과 ‘신뢰성’에 대한 설명에서 ‘관련된 모든 것들’이라고 설명한 부분이 무엇을 말하는 것인지를 인식할 필요가 있다. 그것을 보여주는 하나의 예시가 바로 아래의 그림이다.

 

그림 29 안전성 목표 할당의 개념

※ 출처) 안전성 평가기법(SAM) 고찰 / 김서원 / 한국항공우주연구원

 

위의 그림은 시스템(항공기) 기능을 정의하는 과정에서 안전성 묙표가 정해지고 그것이 우리가 지금까지 이야기했던 장비(시스템)를 통해서 그 하위 단계의 하드웨어와 소프트웨어로까지 할당된다는 것을 보여주고 있다. 그런데 중간에 있는 박스들을 보면 장비만이 아니라 심지어 ‘사람’ 그리고 ‘운영절차’로까지 할당되고 있는 것을 볼 수 있다.

 

여기서 ‘사람’이라는 것은 항공기 조종사, 승무원, 그리고 극단적으로는 승객까지도 해당될 수 있으며 ‘운영절차’는 대표적으로는 항공기 조종이나 운영에 대한 ‘매뉴얼’ 뿐만 아니라 비행을 하지 않는 동안에 사용되는 정비 ‘매뉴얼’도 해당된다. 그 외에 항공교통관제 시스템이나 공항 시설과 같은 항공기와 직접적으로 관련되지 않는 시스템도 해당될 수 있으며 심지어는 한 나라의 법이나 제도까지도 그 대상이 될 수 있다. 결국 우리가 앞으로 언급하게 될 안전성에 대한 고려는 우리가 상상하는 이상으로 훨씬 다양한 범위로까지 확장될 수 있다는 점을 기억하자.

 

n  시스템 안전성 평가를 설명하기 위한 그림

 

마지막으로 앞서 보았던 그림들과 유사하면서도 앞으로 나올 내용들을 좀 더 직관적으로 설명할 수 있는 한글로 표기된 그림을 추가로 소개한다. 이전에 제시된 그림 자체가 복잡하기도 하고 아무래도 한글로 된 그림을 보는 것이 그나마 받아들이기가 용이하지 않을까 싶다. 물론 동일한 내용을 다른 형태로 표현하는 예시를 본다는 의미도 있다. 앞으로 나오게 되는 설명에서는 아래에 소개되는 그림들도 활용해서 설명하게 될 것이다.

 

먼저 항공기 시스템 개발 프로세스와 위에서 설명한 ‘안전성’과 ‘신뢰성’이 어떻게 연결되는지를 보여주는 그림이다.

 

※ 출처) 항공기 인증을 위한 시스템 안전성 평가 / 유승우, 진영권 / 항공우주연구원

 

가운데에 개발 프로세스를 중심으로 좌우에 ‘안전성(Safety)’과 ‘신뢰성(Reliability)’이 함께 진행되는 흐름을 보여준다. 구체적인 설명은 추후 하기로 하고 이어지는 그림을 보자.

 

※ 출처) 항공기 인증을 위한 시스템 안전성 평가 / 유승우, 진영권 / 항공우주연구원

 

이 그림에서도 시스템 개발단계와 연결된 안전성 평가 단계가 보이고 그 내부적으로 수행되는 활동들이 한글로 표기되어 있는 것을 확인할 수 있다. 결론적으로 위의 그림들은 모두 앞서 보았던 영문으로 표기된 그림과 같은 내용을 보여주는 것이다. 단지 한글로 표기되어 있고 표현 방식이 조금 다르다는 차이가 있을 뿐이다.

 

n  항공기의 안전에 대한 가장 상위레벨의 안전성 요구사항

 

아무리 크고 복잡한 항공기라고 하더라도 일단 항공기 제작을 위한 시작점이라고 할 수 있는 가장 상위수준에서 제시하는 요구사항이 있을 것이다. 안전성에 대한 부분 역시 그 시작점이 있다. 아래는 바로 그 예시이다.

 

항목 번호	세부 내용	적용 대상 (감항분류)
§23.1309	(a) 각 장비품, 각 계통 및 그 장착은 다음을 만족하여야 한다.  (2) 단발비행기는, 발생 가능한 기능결함 또는 오작동이 일어났을 때 비행기에 미치는 위험을 최소화하도록 설계하여야 한다.  (3) 다발비행기는, 발생 가능한 기능결함 또는 오작동이 일어났을 때 비행기에 미치는 위험이 없도록 설계하여야 한다.	보통(N), 실용(U), 곡기(A), 커뮤터©류 비행기

※ 출처) 항공기 인증을 위한 시스템 안전성 평가 / 유승우, 진영권 / 항공우주연구원

 

위의 표는 가장 우측’의 (적용 대상(감항분류))’에 항공기의 유형이 표기되어 있고 이들 유형의 항공기가 감항인증을 받기 위해서는 ‘세부 내용’과 같은 안전에 대한 기준을 만족해야 한다는 것을 설명하고 있다. ‘세부 내용’에서 설명하는 ‘기능결함 또는 오작동이 일어났을 때 비행기에 미치는 위험을 최소화하도록 설계해야 한다’라거나 ‘위험이 없도록 설계하여야 한다’와 같은 말이 무엇을 의미하는 지는 짐작이 될 것이다.

 

이번에는 다른 예시를 보자.

 

항목 번호	세부 내용	적용 대상 (감항분류)
§33.75	발생 가능한 어떤 기능장애나 단순 또는 복합 결함 또는 부적절한 발동기 작동이 발동기에 다음과 같은 일들을 초래하지 않음을 분석에 의해 보여야 한다. (a) 발화 (b) 폭발(위험 파편이 발동기 케이스를 관통함) (c) 33.23(a)에 명시된 극한하중보다 큰 하중의 발생 또는 (d) 작동 중지 능력의 상실	항공기 엔진

※ 출처) 항공기 인증을 위한 시스템 안전성 평가 / 유승우, 진영권 / 항공우주연구원

 

앞서 보았던 항공기의 유형이 아니라 ‘항공기 엔진’에 대한 안전 요구사항이 제시되고 있다. 특히 ‘세부 내용’의 내용을 보면 문제가 생겼을 때 ‘발화’나 ‘폭발’이 발생하지 않아야 한다는 좀 더 구체적인 기준을 제시하고 있다는 것도 확인할 수 있다.

 

이처럼 가장 상위단계에서부터 항공기의 안전에 대한 기준(요구사항)이 제시된다. 따라서 이렇게 제시된 기준을 충족하기 위해서 그 하위 단계에서 보다 구체적인 내용이 정리되고 그에 따른 실제 활동이 이루어지게 된다.

 

결국 이렇게 주어지는 안전성에 대한 요구사항을 만족하기 위해서 참조하게 되는 지침서가 바로 ARP4754A와 ARP4761이라고 할 수 있다. 참고로 두 문서는 가장 중심이 되는 기준이라고 할 수 있으며 그 외에도 상당히 많은 수의 각종 지침서, 안내서, 표준서, 규격서들이 활용될 수 있다.

 

n  항공기의 안전을 평가하기위한 분석(Analysis)

 

항공기의 안전성에 대한 평가에는 시험이나 분석, 검사 등의 다양한 방법이 사용된다. 그 중 DO-178과 관련해서 여기서 설명하고자 하는 방법은 바로 분석(Analysis)이다. 분석은 다시 정성적인 분석과 정량적인 분석으로 나누어지는 데 그 중 주목해야 할 부분이 바로 정량적 분석이다.

 

사실 수많은 부품과 시스템들로 구성된 항공기를 분석하는 것이 어느 한 가지 방법만으로 정해질 수는 없다. 수 많은 복합적인 요인들이 함께 고려되어야 하고 결국 정량적 분석과 정성적 분석이 함께 적용될 수밖에 없다. 그 중에서도 정량적 분석의 결과는 우선적으로 확보되어야 할 데이터라고 할 수 있다. 그 중 가장 핵심이 되는 내용을 소개한다.

 

필자가 포스팅한 자료 중에 아래와 같은 그림을 소개한 적이 있다.

 

그림 30 소프트웨어 위험레벨의 구분

※ 출처) Avionics Certification: A Complete Guide to DO-178 (software), DO-254 (hardware) / Vance Hilderman, Tony Baghi

 

해당 포스팅에서 소프트웨어 레벨 선정은 시스템 안전성 평가(System Safety Assessment)를 통해서 결정된다고 설명한 바가 있다. 정확하게 말하자면 시스템 안전성 평가를 통해서 결정되는 것은 보다 상위레벨의 Development Assurance Level(DAL)이라는 것이고 그것이 하위레벨로 할당되고 분리되는 과정에서 결과적으로 위와 같은 소프트웨어에 대한 위험 레벨(Criticality Level)이 결정되는 것이다. 바로 이 과정에서 사용되는 다음과 같은 자료가 있다. (주석에도 있는 것처럼 ARP4761에 나오는 내용이다)

 

※ 출처) AIRCRAFT SYSTEM SAFETY ASSESSMENT – whitepaper from Consunova

 

위의 표를 설명하는 여러가지 복잡한 내용이 있지만 그런 내용들은 모두 생략하고 결론적으로만 보자면 우리가 관심을 가져야 할 부분은 바로 붉은색으로 표시된 부분이다. 특히 ‘Probability Requirement’에 표시된 숫자들을 주목하자. 우리말로는 ‘발생가능성에 대한 요구사항’ 정도로 해석할 수 있는데 소프트웨어 위험 레벨 선정의 근간이 되는 시스템 안전성 평가에서 정량적 평가를 위한 핵심 데이터라고 할 수 있다.

 

위의 표를 좀 더 쉽게 풀어서 설명하면 다음과 같다.

 

레벨	구분	목표확률	상태	해설
A	극히 불가능 (Extremely Improbable)	비행시간당 1x10-9	일정 형식의 모든 비행기의 전체 운용 수명동안 일어날 것으로 예상되지 않는 고장 상태	100대의 항공기가 1년에 각각 3,000시간씩 비행한다고 할 때, 3,000년에 1번 일어날 것으로 예상되는 고장
B	극히 희박 (Extremely Remote)	비행시간당 1x10-7	동일 형식의 모든 비행기의 전체 운용 수명에서 일어나지 않을 것 같지 않지만, 그럼에도 불구하고 가능성이 있는 것으로 보아야 하는 상태	100대의 항공기가 1년에 각각 3,000시간씩 비행한다고 할 때 30년에 1번 일어나는 사건과 동등
C	희박 (Remote)	비행시간당 1x10-5	동일 형식의 많은 비행기의 전체 운용 수명을 고려할 때 전체 수명동안 각 비행기에서 일어나지 않을 것 같지만 수차례 일어날 수도 있는 상태	100,000시간당 1번 일어나는 사건과 동등하며 항공기의 일반적인 설계 수명의 약 2배에 해당
D	가능	비행시간당 1x10-5 이하	안전 여유의 작은 감소, 승무원 업무량의 작은 증가, 작업자의 불편 발생	고장 발생으로 인한 영향이 경미

※ 출처) 항공기 인증을 위한 시스템 안전성 평가 / 유승우, 진영권 / 항공우주연구원

 

앞서 영문으로 작성된 표를 보는 것 보다는 그래도 좀 더 쉽게 받아들일 수 있을 것이다. 붉은색으로 표시된 부분이 앞서 본 표에서 핵심이라고 이야기한 부분이다. 숫자만으로 잘 와 닿지가 않는 분은 우측의 ‘해설’부분을 읽어보면 그래도 좀 더 현실적인 느낌이 있지 않을까 싶다.

 

참고로 위의 내용은 정량적 분석을 위한 기준으로 제시될 수 있는 하나의 예시일 뿐이며 실제로는 각 항공기마다, 혹은 시스템마다 관련된 많은 데이터를 기초로 감항당국과의 협의를 통해서 별도의 기준이 결정된다. (물론 일반적으로는 위의 기준을 그대로 사용할 수도 있을 것이다)

 

이처럼 항공기 최상위레벨에서의 정량적 분석에 대한 수치화된 기준이 주어지기 때문에 항공기를 제작하는 과정, 그리고 그 내부에 포함되는 하드웨어와 소프트웨어를 개발하는 과정에서 이러한 상위레벨에서 제시된 기준을 바탕으로 각각에 대한 정량적 분석이 추가로 이루어지게 되고 이를 통해서 하위레벨에서의 기준이 다시 정해지게 된다. 그리고 최종적으로는 하위레벨에서 결정된 정량적 기준에 따라서 실제 구현과정이 진행되는 것이다. 당연한 말이지만 실제로 구현되고 나면 제대로 만들어 졌는지에 대해서 앞서 정했던 정량적 기준에 따라 평가(확인)가 이루어 진다.

 

정량적 분석과 관련해서 언급되는 사례들을 좀 더 소개하면 다음과 같은 것들이 있다.

 

-       자동 착륙 시스템(Automatic Landing System)에 대해서 1,000만회의 착륙에 대해서 1건 이하의 고장 발생을 목표로 함

-       일반 시스템의 경우 각 시스템별로 1,000만 운용시간당 1건 이하의 고장 발생을 목표로 함

-       1980년부터 1996년 사이의 통계에 의하면 유럽감항당국의 관리 하에 있는 항공사는 백만 비행시간당 치명적 사고 0.35건의 사고율을 보이고 있음

※ 출처) 항공기 인증을 위한 시스템 안전성 평가 / 유승우, 진영권 / 항공우주연구원

 

지금까지 ARP4761을 이해하기 위한 여러 가지 배경을 설명하였다. 이어지는 내용은 다음 절에서 설명한다.