잡談/DO-178 기본

15. DO-178과 인증 교섭 프로세스 (Section 9.0)

sudam 2019. 1. 6. 17:30

여러분은 혹시 ‘liaison’이라는 단어를 들어본 적이 있는가? 필자에게는 사실 ‘DO-178’이라는 용어 자체도 항공분야 일을 하게 되면서 처음 들어본 것이지만 ‘liaison’이라는 단어는 그야말로 듣도 보도 못한 단어였다. 지금도 사실 단어나 뜻에 대해서 명쾌하게 이해한 것은 아니다. 그저 개념적으로 사전에서 알려주는 의미로만 이해를 하고 있으며 적당한 해석이 없어서 그나마 어울린다고 생각되는 교섭이라는 단어를 선택해서 사용하고 있다. 혹시라도 다른 분들은 이 단어가 아닌 다른 번역을 할 수도 있을 텐데 틀린 것이 아니므로 오해 없으시기 바란다.

 

참고를 위해서 인터넷으로 ‘liaison’을 검색해 보니 발음을 제대로 보여주는 것이 있어서 아래와 같이 가져와 봤다.



출처) http://aha-dic.com/View.asp?Word=liaison

 

사설이 길었는데 ‘liaison’이라는 단어의 특이함처럼 소프트웨어 인증교섭(Certification Liaison) 프로세스는 전적으로 DO-178에 특화된 프로세스이다. , 다른 인증이나 개발방법론에서는 사용하지 않는 개념이다. 따라서 이에 대해서는 전적으로 DO-178 가이드라인을 통해서 그 내용을 파악하고 이해해야 한다. 먼저 DO-178 가이드라인에 정의된 인증 교섭 프로세스의 의미는 다음과 같다.


 

해석을 보자.

 

인증 교섭 프로세스 지원자와 인증당국간의 소통, 이해 그리고 동의를 형성하는 프로세스

 

이 프로세스는 결국 DO-178 인증을 신청한 업체와 인증당국인 FAA간에 이루어지는 프로세스이다. DO-178FAA의 공식적인 인증을 받는다는 것을 생각하면 이런 프로세스가 공식적으로 필요하다는 것이 그렇게 이상한 부분은 아닐 것이다. 다만 다른 곳에서는 보지 못하던 것이어서 생소한 것은 사실이기에 어떻게 해야 하는지 막막한 부분이 생길 수밖에 없다.

 

여기서 잠시 지금까지 중간중간 언급되었던 인증당국(Certification Authority)에 대해서 조금 더 살펴보자. 우리가 실제로 DO-178 인증을 진행하기 위해서는 인증의 주체라고 할 수 있는 인증당국이 누구인지가 결정되어야 한다. 앞서 인증당국을 FAA로 통칭하기는 했지만 사실 이는 소프트웨어를 포함하는 항공기 전체의 관점에서 본 인증당국을 말하는 것이고 그 내부의 소프트웨어로 범위를 좁히게 되면 인증당국의 정의가 좀 더 세분화될 필요가 있다.

 

개념적으로는 인증당국을 FAA로 인식하면 되지만 실제로 소프트웨어에 대한 인증을 위해서 자료를 제출하고 감사를 받고 최종 승인을 받는 등의 구체적인 행위의 관점에서는 우리가 진행하는 DO-178 인증 혹은 준용에 대한 인증당국이 누구인지가 분명하게 먼저 구분되어야 하는 것이다. 이를 위해서 우선 DO-178에서는 인증당국을 어떻게 정의하고 있는지 확인해 보자.


 

내용이 조금 많긴 하지만 정확한 이해를 위해서 하나하나 해석해 보자.

 

인증당국 요구사항에 따른 제품의 인증 혹은 승인과 관련된 주, 지역 혹은 다른 관련 주체내의 책임이 있는 조직 혹은 사람

 

유의사항1: 항공기, 엔진, 프로펠러 혹은 지역에 따라서 보조 전원 유닛의 형식인증과 관련된 혹은 장비 승인과 관련된 문제는 보통 인증당국에 의해서 설명된다. 지속적인 감항과 관련된 문제는 감항당국으로 표현되는 것으로 설명된다.

 

유의사항2: 인증당국은 준수의 실질적인 결정이 승인된 설계 조직 혹은 위임받은 개인에 의해서 만들어 질 수 있는 시스템을 사용할 수 있다.

 

사실 용어 자체가 어렵고 복잡한 개념을 담고 있어서 위의 설명만으로 금방 이해가 되지는 않을 것이다. 여기서 우리나라의 인증당국이라고 할 수 있는 국토해양부에서 발행한 항공용 소프트웨어 승인 지침서에 관련 내용이 있는데 그 부분을 한 번 보자.



출처: 항공용 소프트웨어 승인 지침서 / 국토교통부

 

사실 가이드라인의 설명이 좀 더 정확하기는 하겠지만 DO-178 인증을 받기 위한 수준에서는 굳이 복잡한 내용으로 이해할 필요없이 국토해양부에서 제시한 정의만으로도 충분하다고 할 수 있다. 결국은 소프트웨어를 승인해주는 곳이 인증당국인 것이다.

 

그런데 위의 설명으로 보면 국내에서 수행하는 소프트웨어 승인은 국토해양부 항공기술과의 감항엔지니어 및 국토해양부 장관이 지정한 항공기등의 인증에 관한 전문검사기관의 엔지니어가 수행하는 것으로 되어 있다. 그렇다면 국내에서 수행하는 DO-178 인증 혹은 준용은 모두 이 기준을 따라야 하는 것일까?

 

결론적으로 내가 만들고 인증을 받고자 하는 소프트웨어에 대한 인증당국은 케이스마다 달라질 수 있다. 위의 정의에 나온 대로 인증당국이 정해질 수도 있고 전혀 다른 조직 혹은 개인이 담당하게 될 수도 있는 것이다. 그야말로 케이스 바이 케이스로 결정되어야 하는 부분이다.

 

이에 대해서 자세히 설명하기에는 너무 내용이 복잡하고 많기 때문에 여기서는 인증당국이 어떤 역할을 한다는 정도의 개념만 이해를 하고 넘어가도록 하자. 추후 자세한 설명을 할 기회가 있을 것이다.

 

이제 본격적으로 DO-178 가이드라인에서 설명하는 소프트웨어 인증 교섭 프로세스에 대해서 알아보자.

 

(1)    소프트웨어 인증 교섭 프로세스 목표(Objectives)

 

인증 교섭 프로세스도 다른 프로세스와 마찬가지로 목표(Objective)가 제시되고 있다. 아래와 같이 부속물(Annex) ATable A-10을 통해서 목표(Objective), 활동(Activity), 결과(Output)를 확인할 수 있다.

 

 

 

DO-178 가이드라인에서 인증 교섭 프로세스에 대해서 제시하는 목표는 다음과 같다.

 

a.      인증 프로세스를 지원하기 위해 소프트웨어 라이프 사이클 전반에 걸쳐서 지원자와 인증당국간에 소통과 이해를 형성

b.     PSAC(Plan for Software Aspects of Certification)의 승인을 통해서 준수 방법(Means of Compliance)에 대한 동의를 얻음

c.      준수에 대한 입증을 제시

 

앞서 보았던 프로세스들은 관련된 계획문서가 있었던 것을 기억할 것이다. 인증 교섭 프로세스 역시 계획 문서가 존재하는데 해당 문서의 이름은 PSAC(Plan for Software Aspects of Certification)이다.

 

추후 자세하게 설명되겠지만 이 문서는 DO-178 인증에서 가장 중요한 문서라고 할 수 있다. 특히 여기에서 언급되는 것처럼 인증 교섭에 대한 계획이 모두 작성되는 문서이기 때문에 필자는 종종 PSACDO-178 인증을 위한 일종의 계약서와 같은 것이라고 말하고 있다. 실제로도 지원자와 인증당국이 상호간에 인증과정을 어떻게 진행할 지를 이 문서를 통해서 공유하고 합의를 하게 된다.

 

(2)    소프트웨어 인증 교섭 프로세스 활동(Activities)

 

DO-178 가이드라인에서 설명하는 인증 교섭 프로세스에 대한 주요 활동을 간략하게 정리하면 다음과 같다.

 

-       DO-178 인증 기준을 어떻게 준수할 것인지를 PSAC(Plan for Software Aspects of Certification)이라는 계획문서에 작성하고 인증당국과 협의를 거친 후 최종 합의함

-       인증당국이 인증 기준을 만족했는지를 리뷰할 수 있도록 계획을 만족하는 증거를 제공

 

결과적으로 인증 교섭과 관련된 계획 문서를 작성하고 그에 따라서 진행한 결과를 인증당국이 확인하는 것이다. 그 안에 수반되는 여러가지 세부 활동들이 있다.

 

     준수 방법과 계획 (Section 9.1)

 

앞서 잠시 설명한 것처럼 인증 교섭 프로세스에서 가장 중요한 것은 PSAC 문서를 작성하는 것이다. 거기에는 인증 기준을 어떻게 만족할 지에 대한 준수 방법(Means of Compliance)이 담기게 된다. 세부적으로는 아래의 활동들이 포함된다.

 

a.      인증당국의 리뷰를 위해 PSAC과 다른 요구되는 데이터를 제출

b.     계획과 관련해서 인증당국에서 제기하는 이슈를 해결

c.      PSAC에 대해서 인증당국의 동의를 얻음

 

참고로 PSACDO-178 인증을 시작하게 되면 가장 먼저 작성하는 문서이다. 그리고 PSAC은 인증당국의 승인을 받아야 한다. 앞서 설명한 소프트웨어 계획 프로세스를 통해서 계획 문서가 완벽하게 작성되고 이후의 활동이 아무리 완벽하다고 하더라도 그것이 인증당국의 동의를 받은 PSAC을 기반으로 한 것이 아니라면 아무 소용이 없게 된다. 따라서 반드시 인증당국을 통해서 PSAC에 대한 승인을 받고 난 이후에 앞에서 보았던 다른 여러 프로세스들이 진행되어야 한다.

 

     준수 입증 (Section 9.2)

 

DO-178에서는 인증 교섭 프로세스에 대한 계획을 PSAC으로, 계획대로 제대로 수행되었는지에 대한 결과를 SAS(Software Accomplishment Summary)로 작성하도록 하고 있다. 그리고 그 과정에서 수행된 결과를 소프트웨어 라이프 사이클 데이터의 형태로 인증당국에 증빙(Evidence)으로 제출하게 된다. 인증당국에서는 그렇게 제출된 증빙을 리뷰하게 되는데 리뷰를 수행하는 장소는 지원자의 회사가 될 수도 있고 인증당국의 사무실이 될 수도 있다. 참고로 이런 부분을 포함해서 준수 입증을 위한 모든 것들은 협의에 의해서 조율될 수 있다. 따라서 중요한 것은 준수에 대한 입증을 위한 활동을 이해하는 것이다. 세부 활동을 정리하면 아래와 같다.

 

1.      리뷰의 결과로써 인증당국에 의해서 제기된 이슈를 해결

2.      인증당국에 SAS(Software Accomplishment Summary)SCI(Software Configuration Index)를 제출

3.      인증당국에 의해서 요구되는 증빙과 데이터를 제출

 

SASSCI에 대해서는 별도의 절을 통해서 자세히 설명할 예정이다.

 

     공식 제출 자료

 

DO-178 가이드라인에는 인증당국에 공식적으로 제출해야 하는 자료들이 자세하게 설명되어 있다. 사실 인증을 수행하면서 작성하게 되는 문서들은 상당히 많다. 특히 DO-178 가이드라인에서 공식적으로 제시하는 문서(데이터)들만 해도 아래와 같이 22건에 이른다. 사실 그 외에 공식, 비공식으로 추가되는 문서들까지 포함하면 실제 문서(데이터)의 양은 아래의 22건을 훨씬 넘어선다고 봐야 한다.


 

이 중에서 인증당국에 제출해야 할 최소한의 자료를 다음과 같이 지정하고 있다.

 

-       PSAC(Plan for Software Aspects of Certification)

-       SCI(Software Configuration Index)

-       SAS(Software Accomplishment Summary)

 

앞에서 설명된 문서들이다. 어떻게 보면 인증을 받기 위해서 위의 3가지 문서만 제출되면 된다는 의미이기도 하다. 이렇게 보면 인증을 받는 것이 생각보다 쉬운 것 아니냐고 할 지 모르겠지만 위의 문서들이 제대로 만들어 지기 위해서는 그 전에 앞에서 말했던 다른 20여건의 문서들이 모두 작성되어야 하기 때문에 여기서의 최소한이라는 것은 형식적인 면에서 설명하는 참고사항 정도로만 이해하자.

 

또 하나 가이드라인에서 설명하는 것은 바로 형식 설계(Type Design)와 관련된 부분이다. 여기서 말하는 형식 설계는 항공기에 대한 형식 인증(Type Certificate)과 관련된 것이다. 구체적으로는 DO-178 가이드라인에서 아래와 같이 정의하고 있다.


 

해석을 보자.

 

형식 설계 이 문서의 목적을 위해, 형식 설계는 다음으로 구성된다: (1) 그 제품에 대한 요구사항을 따르는 것을 보여주는 인증된 제품의 형상과 설계 특성을 정의하기 위해 필요한 도면과 명세, 그리고 그러한 도면과 명세의 목록; (2) 비교에 의해서 동일한 형식의 향후 제품의 감항성에 대한 결정을 허용하기 위해 필요한 다른 데이터

 

참고: 이 정의에서 제품이라는 용어의 사용은 인증당국에 의해서 승인되는 형식 인증에 대한 어떤 아이템을 말한다. 예를 들면 항공기, 엔진, 프로펠러, 그리고 지역에 따라서는 보조 전원 유닛이 있다.

 

위의 내용을 이해하기 위해서는 항공기에 대한 감항 인증에 대해서 알아야 한다. 여기서 그 부분까지 설명하기는 어렵고 위의 정의를 기준으로 형식 설계를 위해 인증당국에 제출되어야 할 문서에 대해서 간단하게 정리하면 다음과 같다.

 

-       요구사항 데이터(Software Requirements Data)

-       설계자료(Design Description)

-       소스코드(Source Code)

-       실행가능 오브젝트 코드와 파라미터 데이터 아이템 파일(존재하는 경우)

-       SCI(Software Configuration Index)

-       SAS(Software Accomplishment Summary)

 

DO-178 인증은 소프트웨어에 대한 인증이긴 하지만 사실 소프트웨어 자체만으로는 아무런 의미가 없다. 소프트웨어는 결국 항공기에 탑재되어야 의미를 가지게 되는 것이고 DO-178 인증 역시 그 상태에서 의미를 가지게 된다. 이때 탑재되는 항공기는 비행을 위한 여러 가지 인증을 받게 되는 데 그 중 하나가 항공기의 설계(Design)와 관련된 형식 인증(Type Certificate)’이다. DO-178 인증을 받는 소프트웨어는 이러한 형식 인증에 포함되어야 하는데 그 때 포함되는 형태가형식 설계(Type Design)’가 되는 것이다. 따라서 형식 설계의 일부로써 소프트웨어의 인증과 관련된 위의 문서들이 인증당국에 제출되어야 한다. 이 내용 역시 참고사항 정도로만 이해하고 넘어가자.