18. PSAC(Plan for Software Aspects of Certification) (Section 11.1)

DO-178에서는 PSAC이 가장 중요한 문서라고 한 것을 기억할 지 모르겠다. 인증당국과의 일종의 계약서 역할을 한다는 점도 설명한 바가 있다. DO-178 가이드라인에서는 이러한 PSAC이 어떤 역할을 하며 그 안에 어떤 내용이 담겨야 하는지를 설명하고 있다. 해당 절의 서두에는 다음과 같은 설명이 있다.

 

해석을 보자.

 

Plan for Software Aspects of Certification (PSAC)은 지원자가 개발되는 소프트웨어 레벨에 필요한 정도의 엄격함에 부합하는 소프트웨어 라이프 사이클을 제안하는지를 결정하기 위해 인증당국에 의해서 사용되는 주된 방법이다.

 

여기에서의 초점은 ‘인증당국에 의해서 사용된다’는 점이다. 지원자가 PSAC 문서를 작성하고 인증당국에서는 그 문서를 사용하는 것이다. 따라서 인증당국이 사용할 수 있는 내용과 형태로 작성되어야 한다.

 

그럼 구체적으로 어떤 식으로 작성되어야 하는 것일까? DO-178 가이드라인에서는 다음과 같은 항목들을 들고 있다. 참고로 아래에 제시된 항목들이 반드시 포함되어야 하는 것은 아니다. 즉, 강제조항은 아니라는 말이다. 하지만 굳이 그런 것을 고려하기 보다는 일단 DO-178 가이드라인에서 설명하는 내용은 디폴트로 포함한다고 생각하는 것이 좋다. 특히 DO-178에서 만들게 되는 문서들은 형식적으로 작성하는 것이 아니기 때문에 가이드라인에서 설명하는 것을 기준으로 실제 관련되는 내용을 그대로 작성하면 되는 것이고 만약 조율이 필요한 부분이 있다면 언제든 인증당국과 협의를 해서 조정할 수 있다.

 

지금부터 본격적으로 PSAC에 반드시 포함되어야 할 주요 항목과 각각의 설명을 DO-178 가이드라인에서 제시한 내용 그대로 하나하나 살펴보자.

 

a.      시스템 개요(System overview)

 

처음 DO-178을 접하는 분들은 DO-178이 소프트웨어 인증이라고 생각해서 그 상위레벨이라고 할 수 있는 시스템에 대해서는 관심을 가지지 않는 경우가 많다. 때로는 시스템과 소프트웨어의 구분없이 두 개념이 혼재되는 경우도 있다. 하지만 DO-178 가이드라인에서는 시스템에 대한 내용을 가장 먼저 작성하도록 아래와 같이 가이드하고 있다.

 

해석을 보자.

 

a. 시스템 개요: 이 섹션은 시스템 기능과 하드웨어 및 소프트웨어로의 할당, 아키텍처, 사용된 프로세서, 하드웨어/소프트웨어 인터페이스, 그리고 안전성 특성을 포함하는 시스템의 개요를 제공한다.

 

더 추가하거나 뺄것도 없이 위의 설명이 ‘시스템 개요’에 포함되어야 할 것들을 모두 포함하고 있다. 최소한 여기에 나오는 부분은 개요 수준으로 모두 포함되어야 한다. 다만 여기에서 개요라는 것이 과연 어느 정도의 수준이나 분량인지에 대해서는 명확한 기준을 제시하지는 않고 있다. 사실 그래서 그 부분은 작성자의 선택이라고 할 수 있지만 ‘개요’라는 단어의 의미상으로도 그렇고 굳이 여기에 상세한 내용을 하나하나 모두 작성할 필요는 없다. 필자의 경험상으로는 1 ~ 2페이지 정도의 분량 내에서 위의 내용이 포함되는 정도로 작성하는 것으로도 충분하다.

 

b.      소프트웨어 개요(Software overview)

 

앞서 시스템의 개요가 작성되었다면 이번에는 소프트웨어에 대한 개요를 작성해야 한다. 어떤 내용이 포함되어야 할까?

 

해석을 보자.

 

b. 소프트웨어 개요: 이 섹션은 제안된 안전성과 파티션 컨셉상에서 강조되는 소프트웨어 기능들을 간략하게 설명한다. 예시로는 리소스 공유, 중복, 고장 허용 범위, 단일 이벤트 혼선의 완화 그리고 타이밍 및 스케쥴링 전략을 포함한다.

 

예시로 제시된 항목들이 다소 어려운 내용이어서 직관적으로 와닿지 않을 것 같은데 결국은 소프트웨어의 주요 기능을 설명하는 것으로 이해하면 된다. 그런데 여기에는 단순히 소프트웨어가 수행해야 하는 기능 자체만이 아니라 안전성과 관련해서 시스템 차원에서 제시되는 기능들이 포함되어야 한다. 설명에 포함된 예시가 바로 그런 것들을 말하는 것이라고 할 수 있다. 당장은 쉽게 이해가 되지 않겠지만 실제 작성하는 시점이 되면 구체적인 내용을 접하면서 관련 내용을 이해할 기회를 얻을 수 있을 것이다.

 

c.      인증 고려사항(Certification considerations)

 

이 부분에 대해서는 먼저 DO-178 가이드라인을 보자.

 

해석을 보자.

 

c. 인증 고려사항: 이 섹션은 인증의 소프트웨어 특성과 관련해서 준수 방법을 포함한 인증 기준의 요약을 제공한다. 이 섹션은 또한 제안된 소프트웨어 레벨을 언급하고 실패 조건에 대한 잠재적인 소프트웨어 역할을 포함하는 시스템 안전성 평가 프로세스에 의해서 제공되는 정당성을 요약한다.

 

여기서 주목해야 할 부분은 ‘준수 방법(means of compliance)’과 ‘소프트웨어 레벨(software level)’이다. DO-178 인증은 소프트웨어 레벨에 따라서 대응하는 방법이나 자료를 준비하는 것이 달라지기 때문에 PSAC에서 소프트웨어 레벨을 정확하게 명시해 주어야 한다. 그리고 이러한 소프트웨어 레벨에 따른 구체적인 준수 방법을 제시하게 된다. 특히 일반적인 준수 방법이 아닌 특별한 방법이 사용되는 경우 그에 대한 내용을 미리 제시해서 인증당국의 검토를 요청하게 된다.

 

d.      소프트웨어 라이프 사이클(Software life cycle)

 

인증을 받게 될 소프트웨어가 수행하게 되는 소프트웨어 라이프 사이클 전체를 인증 관점에서 작성하는 부분이다.

 

해석을 보자.

 

d. 소프트웨어 라이프 사이클: 이 섹션은 사용되는 소프트웨어 라이프 사이클을 정의하고 상세한 정보가 각각의 소프트웨어 계획에 정의되는 소프트웨어 라이프 사이클 프로세스 각각의 요약을 포함한다. 그 요약은 각 소프트웨어 라이프 사이클 프로세스의 목표가 어떻게 만족할 지를 설명하고 관여되는 조직, 조직의 의무, 그리고 시스템 라이프 사이클 프로세스와 인증 교섭 프로세스의 책임을 구체화한다.

 

기본적으로 소프트웨어 라이프 사이클 각각에 대한 부분은 관련된 계획 문서로 작성된다. 예를 들면 소프트웨어 개발 프로세스(Software Development Process)는 소프트웨어 개발 계획(Software Development Plan)으로, 소프트웨어 검증 프로세스(Software Verification Process)는 소프트웨어 검증 계획(Software Verification Plan)으로 작성되는 식이다. 상세한 내용은 이어지는 절에서 계속해서 나오게 될 것이다. 지금 설명하는 PSAC은 그러한 계획 문서들을 취합하는 성격을 가지고 있다.

 

사실 소프트웨어 라이프 사이클에 대한 부분은 요약이라고 하더라도 작성할 내용이 상당히 많다. 그래서 내부에 작성되는 내용을 좀 더 세분해서 볼 필요가 있는데 여기에서 그런 것들을 하나하나 풀어서 설명하기는 어려울 것 같고 추후에 기회가 되면 아예 템플릿 형태로 샘플을 공유하는 것을 고려하고 있다.

 

e.      소프트웨어 라이프 사이클 데이터(Software life cycle data)

 

앞에서 나온 소프트웨어 라이프 사이클 과정에서 생성되는 데이터를 모두 나열하는 곳이다. 우선 가이드라인의 설명을 보자.

 

해석을 보자.

 

e. 소프트웨어 라이프 사이클 데이터: 이 섹션은 소프트웨어 라이프 사이클 프로세스에 의해서 생성되고 컨트롤될 소프트웨어 라이프 사이클 데이터를 구체화한다. 이 섹션은 또한 데이터 상호간 혹은 시스템을 정의하는 다른 데이터간의 관계, 인증당국에 제출되어야 할 소프트웨어 라이프 사이클 데이터, 데이터의 형태, 그리고 데이터가 인증당국에서 사용할 수 있도록 만들어 지는 방법을 설명한다.

 

복잡한 설명이 나오고 있지만 결국 인증에 필요한 데이터, 문서들을 이곳에 정리하게 된다. 그리고 특히 그 중에서 인증당국이 참고해야 할 부분이 있으면 그에 대한 설명이 추가되며 만약 특별히 그런 부분이 없다면 일반적으로 데이터 리스트가 제시되는 수준으로도 충분하다.

 

f.       일정(Schedule)

 

현실적으로 일정에 대한 내용은 미묘한 부분이 많다. 아래는 가이드라인의 설명이다.

 

해석을 보자.

 

f. 일정: 이 섹션은 지원자가 소프트웨어 라이프 사이클 프로세스의 활동들에 대해서 인증당국이 볼 수 있도록 제공해서 리뷰가 계획될 수 있도록 하기 위한 방법을 설명한다.

 

여기에서 말하는 일정은 기본적으로 소프트웨어 전체 개발과정을 담고 있는 일정이며 여기에 인증을 위한 활동들이 고려되어야 한다. 그러한 활동에는 주로 위의 설명에서처럼 인증당국의 리뷰에 대한 부분이 기준이 될 것이다. 여기에 그것을 준비하기 위한 기간을 고려한다면 단순히 소프트웨어 개발만을 고려한 일정과는 많이 달라지게 된다.

 

g.      추가 고려사항(Additional considerations)

 

DO-178 인증을 받기 위해서는 앞서 언급한 부분들 이외에도 추가적으로 고려해야 할 사항들이 있을 수 있다. 먼저 가이드라인의 설명을 보자.

 

해석을 보자.

 

g. 추가적인 고려사항: 이 섹션은 인증 프로세스에 영향을 줄 수 있는 특정한 고려사항을 설명한다. 예시로는 준수에 대한 대체 방법, 툴인증, 이전에 개발된 소프트웨어, 옵션 선택가능 소프트웨어, 사용자 수정가능 소프트웨어, 비활성화된 코드, COTS 소프트웨어, 현장 적재가능 소프트웨어, 파라미터 데이터 아이템, 다중 버전 비유사성 소프트웨어, 그리고 제품 서비스 히스토리를 포함한다.

 

우선 추가적인 고려사항으로 위의 설명에서 제시한 항목들을 다시 한 번 정리하면 다음과 같다.

 

-       준수에 대한 대체 방법(Alternative methods of compliance)

-       툴인증(Tool qualification)

-       이전에 개발된 소프트웨어(Previously developed software)

-       옵션 선택가능 소프트웨어(Option-selectable software)

-       사용자 수정가능 소프트웨어(User-modifiable software)

-       비활성화된 코드(Deactivated code)

-       COTS 소프트웨어(Commercial Off-the-Shelf Software)

-       현장 적재가능 소프트웨어(Field-loadable software)

-       파라미터 데이터 아이템(Parameter data items)

-       다중 버전 비유사성 소프트웨어(Multiple-version dissimilar software)

-       제품 서비스 히스토리(Service history)

 

그 외에 다른 항목들이 있을 수 있지만 우선 위의 항목들부터 제대로 작성해야 한다. 특히 툴인증, COTS 소프트웨어의 경우는 대부분의 소프트웨어에 해당하는 것으로써 경우에 따라서는 DO-178 인증 자체의 성패를 좌지우지할 수 있는 항목들이어서 절대 가볍게 처리할 수 없는 부분이다. 위의 항목들 하나하나를 여기서 설명하기에는 너무 내용이 방대해 지므로 별도의 절을 통해서 각각에 대해 설명하기로 한다.

 

h.      납품업체 감독(Supplier oversight)

 

경우에 따라서는 소프트웨어 일부를 하청해서 개발하게 될 경우가 있다. 만약 DO-178 인증에 하청해서 개발한 소프트웨어가 포함된다면 직접 개발하지 않은 부분에 대해서 어떻게 처리해야 하는지 의문이 들 수 있다. 가이드라인에서는 다음과 같이 간단하게 언급하고 있다.

 

해석을 보자.

 

h. 납품업체 감독: 이 섹션은 납품 프로세스와 결과물이 승인된 소프트웨어 계획과 표준을 따를 것을 보장하는 방법을 기술한다.

 

한마디로 납품업체도 동일한 인증 계획과 절차를 따르라는 것이다. 어차피 인증을 받는 소프트웨어라면 그것이 어디에서 만드는지가 중요한 것이 아니므로 어쩌면 이것은 당연한 지침이라고 할 수 있다. 하지만 같은 조직내에서 이루어 질 수 있는 부분이 아니다 보니 결국 해당 업체와 어떻게 진행할 지를 협의해야 하고 전체 과정을 챙겨야 하므로 상당히 번거롭고 진행하기 어려운 부분이라는 점은 부인할 수 없는 사실이다.

 

이상이 DO-178 인증을 위해서 작성해야 하는 PSAC에 포함되어야 할 내용들이다. 앞서 설명한 것처럼 가능하면 여기에 제시된 내용을 기본으로 작성하고 필요한 부분을 추가 혹은 경우에 따라서 일부 내용은 해당되지 않는다는 점을 분명히 명시하는 형태로 작성하는 것을 추천한다. 필자의 경우에는 PSAC의 인덱스를 아예 위의 순서로 정해서 문서의 포맷을 잡고 세부 내역을 채우는 형태로 작성하기도 한다.

 

지금까지 길게 설명을 했지만 막상 이것을 기준으로 실제로 작성하려고 하면 여전히 막막해 지는 것이 사실이다. 필자의 경우 한 두 번의 경험을 거친 이후에도 여전히 생소한 느낌을 지울 수 없었고 아직까지도 작성에 어려움을 겪고 있다. 그런 이유로 PSAC을 처음 작성하는 분들에게 여기에서의 설명을 해답으로 제시하려는 것은 아니다. 다만 이런 것이 있다는 것을 알고 접근하는 것과 그렇지 않은 것은 비록 당장의 결과에는 별 영향을 주지 못하더라도 향후 계속해서 DO-178 인증을 진행하는 경우에는 과정과 결과에서 많은 차이를 가져올 수 있다는 점을 말해주고 싶다.