5. DO-254와 시스템의 관계 (Section 2.0)
DO-254 가이드라인에서는 시스템과 관련된 설명을 위해서 아래와 같은 그림을 제시하고 있다.
위의 그림은 시스템 개발 프로세스와 관련된 핵심 항목들을 보여주고 있다. 하드웨어와 소프트웨어는 당연히 포함되는 것일텐데 시스템 안전성 평가가 그에 못지 않은 비중을 가지고 있다는 것을 확인할 수 있다. 이것은 안전성 평가가 그 만큼 중요하다는 것을 말해주는 부분이다.
사실 우리나라에서 DO-254나 DO-178을 진행하는 경우는 대부분 개별적인 하드웨어 혹은 소프트웨어 개발 업체 수준에서 단독으로 진행하는 경우가 대부분이다. 그리고 항공기용 제품을 개발한다고 하지만 대부분의 경우는 실제 탑재될 항공기가 결정되어 있지 않은 경우가 많다. 이것은 결국 위의 그림에서 보자면 하드웨어 혹은 소프트웨어 외부의 시스템에 대한 부분을 거의 정의할 수 없다는 것이고 또 다른 핵심 항목인 안전성 평가 역시 정의할 수 없다는 것을 의미하는 것이다. 물론 중첩된 부분도 제대로 커버할 수 없다.
이번 절에서 설명하는 부분이 바로 이와 같이 현실적으로 커버하지 못하고 넘어가게 될 여지가 많은 시스템과 그와 연계된 안전성 평가에 대한 부분이다. DO-254 가이드라인이 문서에 대한 소개와 함께 가장 먼저 시스템과 관련된 설명을 하는 것은 DO-254의 시작에서 시스템에 대한 부분이 그 만큼 중요하다는 것을 보여주는 것이기도 하므로 DO-254를 제대로 진행하기 위해서는 이번 절의 내용부터 확실하게 이해할 수 있어야 한다.
5.1. 시스템 안전성 평가 프로세스
DO-254와 관련된 시스템 안전성 평가 프로세스에 대해서 가이드라인의 내용을 보기 전에 필자가 포스팅한 자료 중에 포함되었던 아래 그림을 먼저 보고 가자.
※ 출처) 항공기 인증을 위한 시스템 안전성 평가 / 유승우, 진영권 / 항공우주연구원
위의 그림에 대한 설명을 여기서 다시 하지는 않겠다. 시스템 개발 단계에서의 안전성 평가가 위와 같이 복잡하고 상당히 밀접하게 연계되어 있다는 점만 기억하고 일단 다음 내용으로 넘어가 보자.
DO-254 가이드라인에서는 시스템 안전성 평가와 하드웨어 설계 라이프 스타일의 관계에 대해서 다음과 같이 설명하고 있다.
 |
해석을 보자.
|
초기에, 각각의 하드웨어 기능에 대한 하드웨어 설계 보증 레벨은 잠재적인 위험을 식별하기 위해 FHA를 사용하는 SSA 프로세스에 의해서 결정되며 그런 다음 PSSA 프로세서는 하드웨어에서 구현되는 기능에 안전성 요구사항과 관련된 실패 조건들을 할당한다. |
FHA, SSA, PSSA등의 어려운 약자가 나오고 설명도 어려워서 처음 접하는 분들이라면 쉽게 이해가 되지는 않을 것이다. 우선 이런 용어들이 무엇인지를 이해해야 하는데 가만히 보면 앞에서의 그림에 이것들이 표시되어 있는 것을 확인할 수 있다. FHA(Functional Hazard Assessment), PSSA(Preliminary System Safety Assessment) 그리고 SSA라는 것인데 결국 이들이 핵심이라는 것을 보여주는 것이다.
앞의 그림에 대한 설명을 포함해서 시스템 안전성 평가에 대한 보다 자세한 내용은 필자가 포스팅한 아래 링크를 참고하기 바란다. 비록 시스템 안전성 평가에 대한 완벽한 설명이 있는 것은 아니지만 적어도 DO-254를 이해하기 위한 수준의 시스템 안전성 평가에 대한 내용은 확인할 수 있을 것이다.
DO-254를 진행하는 입장에서 중요한 점은 이와 같은 시스템 안전성 평가를 고려해야 한다는 점이다. 하지만 계속 언급하는 것이지만 필자가 경험하기로는 대부분의 경우 시스템 안전성 평가에 대한 부분은 DAL(Design Assurance Level)이 A, B 혹은 C라는 정도만을 확인받는 것으로 넘어가는 경우가 많다. 물론 그것이 현실적인 한계이겠지만 적어도 이러한 부분을 이해는 하고 있어야 한다. 참고로 원칙적으로는 DO-254 인증에 필요한 DAL을 포함해서 안전성 목표를 달성하기 위한 안전성 요구사항, 기능 요구사항, 성능 요구사항 등을 바로 이 시스템 안전성 평가를 통해서 얻게 된다.
시스템 안전성 평가에 대한 더 자세한 내용은 필자의 다른 포스팅을 참고하는 것으로 하고 이에 대해서는 이정도로 마무리한다.
5.2. 하드웨어 안전성 평가
필자가 포스팅한 자료 중에 아래와 같은 그림이 있다.
※ 출처) https://kr.mathworks.com/solutions/aerospace-defense/standards/arp-4754.html
ARP4754와 ARP4761 그리고 DO-178과의 관계를 설명하기 위한 그림인데 DO-254도 포함된 것을 확인할 수 있다. 특히 가운데 붉은색 점선 박스로 된 부분을 보면 ‘ARP 4761 Safety Assessment’라는 문구가 보일 것이다. 그리고 연결된 화살표가 시스템, 소프트웨어, 하드웨어 모두와 연결되어 있는 것을 확인할 수 있는데 이는 앞서 맨 처음 본 그림과 같은 개념이라고 할 수 있다. DO-254 가이드라인에서 설명하는 하드웨어 안전성 평가는 바로 위의 연결된 부분과 관련된 내용이다.
DO-254 가이드라인에서는 하드웨어 안전성 평가의 역할에 대해서 다음과 같이 설명하고 있다.
 |
해석을 보자.
|
시스템 프로세스에 의해서 안전, 기능 그리고 성능 요구사항이 할당되면 하드웨어 안전성 평가는 각 기능에 대한 하드웨어 설계 보증 레벨을 결정하고 사용될 적절한 설계 보증 전략을 결정하는데 기여한다. |
DO-254 가이드라인에서는 위의 내용과 관련해서 여러가지 복잡하고 어려운 안전성 평가와 관련된 설명을 하고 있는데 사실 상당히 복잡하기도 하고 그것들을 하나하나 이해하는 것이 쉽지 않은 일이다. 여기서는 그 중 ‘설계 보증 전략’의 결정 과정을 보여주는 아래의 흐름도를 먼저 살펴보자.
위의 그림은 제목에도 나와 있듯이 하드웨어 설계 보증 전략을 선정하기 위한 결정 과정을 보여주는 그림이다. 최종적으로는 결정된 전략에 따라서 실제 하드웨어 구현이 이루어 지게 되는데(8번) 그림에 표시된 각각의 번호가 의미하는 바를 살펴보자.
① 평가 프로세스 시작
적절한 설계 보증 전략을 결정하기 위한 평가의 시작단계이다.
② FFP 설계 보증 레벨 결정
하드웨어 아이템별로 FFP(Functional Failure Paths), 즉 실패 경로를 확인한다. 어떤 회로에서 문제가 발생하는지를 구분하는 것이다. 이를 통해서 해당하는 회로 혹은 아이템이 Level A, B, C, D 중 어디에 해당하는지를 구분하게 된다.
③ FFP의 하드웨어 구현이 Simple인가 혹은 Complex인가?
앞에서 Level이 구분되는데 만약 A 혹은 B라면 이것을 구현할 하드웨어가 Simple 하드웨어인지 Complex 하드웨어인지를 결정한다.
|
참고) 여기서 Simple 하드웨어와 Complex 하드웨어의 구분은 DO-254 가이드라인 Section 1.6에 설명되어 있는데 간단하게 말하자면 해당하는 하드웨어에 대한 모든 시험을 수동으로 명시하고 직접 시험해서 확인이 가능하면 Simple이라고 말하고 그 외에는 모두 Complex라고 하는 것이다. 사실상 부품단위가 아니라면 칩을 포함해서 대부분의 하드웨어는 Complex 하드웨어라고 말할 수 있다. HDL로 개발하는 하드웨어가 모두 대상이라고도 말할 수 있을 것이다. |
④ Level A 혹은 Level B Complex에 대해서 설계 보증 전략을 개발
앞에서 Level A 혹은 B라는 것이 정해졌고 더구나 Complex 하드웨어라면 상당히 중요하고 복잡한 하드웨어라는 것이 판별이 되었으므로 그에 준하는 설계가 구상되어야 할 것이다. 여기에는 해당 하드웨어 자체의 안전성을 높이는 방법도 있을 것이고 혹은 에러 모니터링 등과 같은 간접적인 방법이 있을 수도 있다. 고급 분석, 경험 등의 다양한 기법이 필요한 부분이다.
⑤ 전략이 적절한가?
하드웨어는 소프트웨어와 달리 설계가 결정되면 제품이 만들어 진 후 수정하는 것이 상당히 어려워진다. 따라서 앞서의 전략이 적절한지에 대한 철저한 검증과 확인은 필수라고 할 것이다.
⑥ 적용가능한 Fail-Safe 특성을 문서화
Fail-Safe 특성을 반영한 설계 아키텍처를 결정하고 이를 문서화하게 된다. Fail-Safe 특성은 안전성과 관련된 특정한 요구사항의 하나인데 이에 대한 적절한 방법과 그에 대한 여러가지 분석 방법이 문서화되어야 한다.
⑦ 설계 보증 접근과 전략을 문서화
지금까지의 결과를 시스템 인증 계획 혹은 PHAC에 작성해서 인증당국의 승인을 받아야 한다.
⑧ 결정된 접근을 구현
실제 구현은 승인된 계획에 따라서 진행되며 그 과정에서의 증빙이 문서화된다.
|
참고) 여기서 잠시 본인의 상황을 생각해 보자. 과연 여러분은 위의 8단계를 거쳐서, 혹은 그와 유사한 형태로 하드웨어 개발을 진행하는가? 아마 대부분은 그렇지 않을 것이다. 역시 여기에서도 중요한 점은 DO-254 인증을 받기 위해서는 하드웨어 레벨에서도 안전성에 대한 엄격한 평가 과정이 필요하다는 점을 인식하는 것이다. |
하드웨어 안전성 평가와 관련해서는 위의 내용과 더불어 상당히 많은 설명이 나온다. 추가적인 내용은 가이드라인을 직접 참고하고 다만 그 중에 하드웨어 아키텍처와 기능적인 안전성 특성으로써 예시를 든 것들이 있는데 하드웨어의 안전성과 관련해서 적용할 수 있는 다양한 방법들을 확인할 수 있는 부분이어서 마지막으로 소개하면서 이 절을 마무리한다. (해석은 생략한다)
 |