36. 제품 서비스 히스토리(Product Service History) (Section 12.3.4)

DO-178 가이드라인의 본문 중 가장 마지막 항목이자 대체 방법으로 가장 마지막으로 제시되는 것은 제품 서비스 히스토리(Product Service History)이다. 먼저 DO-178에서 말하는 제품 서비스 히스토리의 정의는 다음과 같다.

 

해석을 보자.

 

제품 서비스 히스토리 – 소프트웨어가 알려진 환경안에서 운영되는 동안의, 그리고 연속적인 실패가 기록되는 동안의 시간의 연속적인 기간

 

설명이 좀 어려운데 쉽게 말하자면 제품이 실제 현장에서 운영된 이력을 말하는 것이다. 거기에는 운영된 시간뿐만 아니라 고장에 대한 부분도 포함되며 뒤에서 자세히 설명되겠지만 그 외에도 관련된 내용이 상당히 많다. 혹시나 해서 언급하자면 개발과정에서 소요된 시간은 당연히 제품 서비스 히스토리에는 포함되지 않는다.

 

DO-178을 처음 접했던 초기에 필자는 제품 서비스 히스토리에 대해서 별 생각없이 운영기록같은 단순한 것이 아닌가라고 쉽게 생각한 적이 있다. 그저 다른 비행기에 사용된 이력이 있다는 것을 보여줄 수 있으면 되는 것이 아닌가라고 판단한 것이다. 물론 그 말이 완전히 틀린 것은 아니지만 실제로 그와 관련해서 DO-178에서 요구하는 형태의 증빙을 제출하기 위해서는 많은 부분이 고려되고 준비되어야 한다는 점을 간과한 것이었다.

 

실제로 DO-178 가이드라인에서는 제품 서비스 히스토리가 대체 방법으로 사용되기 위해서는 다음과 같은 것들이 필요하다고 설명하고 있다.

 

-       소프트웨어의 형상 관리

-       문제점 리포트 활동의 유효성

-       소프트웨어의 안정성과 성숙도

-       제품 서비스 히스토리 환경의 적절성

-       제품 서비스 히스토리의 기간

-       제품 서비스 히스토리에서 실질적인 에러 비율

-       수정의 영향

 

위의 항목들 중 하나라도 준비되지 못하는 경우에는 제품 서비스 히스토리를 대체 방법으로 인정하지 않는다는 것이다. 이에 대해서 DO-178 가이드라인에서는 아래와 같이 정리하고 있다.

 

해석을 보자.

 

인증 신뢰를 위한 서비스 히스토리 데이터의 사용은 서비스 히스토리 기간동안 발생하는 문제들의 충분함, 적절성 그리고 유형에 근거한다. 사용, 사용의 조건, 그리고 소프트웨어 서비스 히스토리의 결과가 정의되어야 하며, 시스템 안전성 평가 프로세스를 포함해서 시스템 프로세스에 의해서 평가되어야 하며 적절한 인증당국에 제출되어야 한다.

 

필자가 처음 생각했던 ‘다른 비행기에 사용된 이력’만으로는 위의 지침을 절대 만족할 수 없다는 것을 이제는 이해할 수 있다. 특히 단순한 사용 히스토리가 아니라 운영 중에 실전에서 발견되는 문제점에 대한 부분을 상당히 강조하고 있다는 것을 확인할 수 있다. 이와 관련해서 가이드라인에서는 많은 부분들을 이야기하고 있다. 이제 구체적인 내역들을 하나씩 확인해 보자.

 

(1)    서비스 히스토리의 적절성 (Section 12.3.4.1)

 

여기서 설명하는 것은 결국 서비스 히스토리를 인증당국에서 공식적으로 인정하기 위해서 무엇이 필요한지에 대한 내용이다. 다음과 같은 항목들이 제시되고 있다.

 

a.      서비스 히스토리 유형

b.     알려진 형상

c.      운영 시간 수집 프로세스

d.     소프트웨어에 대한 변경

e.      사용과 환경

f.       비활성화된 코드

 

여기서 잠시 서비스 히스토리에 대해서 생각해 볼 부분이 있다. 항공기는 안전이 대단히 중요한 요인이다. 따라서 항공기에 사용되는 하드웨어와 소프트웨어는 충분한 안전성이 확보되어야 한다. 이때 만약 어떤 하드웨어가 다른 항공기에 이미 사용된 이력이 있다면 적어도 그 하드웨어에 대해서는 최소한 심정적으로는 상당한 신뢰를 느끼게 된다. 실제 항공기에 탑재될 수 있을 만큼 안전성을 가지고 있다는 것을 간접적으로 보여준다고 생각하기 때문이다. 소프트웨어 역시 마찬가지일 것이다. 그런데 과연 그런 믿음(?)만으로 그 하드웨어나 소프트웨어를 지금 새로 만들고 있는 항공기에 그대로 사용할 수 있을까? 당연히 그렇지는 않을 것이다. 결과적으로는 그저 그 하드웨어 혹은 소프트웨어에 대해서 좋은 인상을 가지고 새로 만들고 있는 항공기에 탑재할 수 있을지를 긍정적으로(?) 살펴보게 될 것이다.

 

앞에서 정리한 6가지 항목들은 바로 그런 배경에서 막연한 믿음이 아닌 객관적인 믿음을 얻기 위해서 체크하게 되는 것들이다. 어쩌면 당연한 내용이지만 DO-178 가이드라인에서 지침을 제공함으로써 최소한 확인해야 할 부분, 갖추어야 할 부분을 명확하게 제시하는 것이다. 그 만큼 중요한 내용이므로 각각에 대한 설명을 좀 더 살펴보자.

 

①     서비스 히스토리 유형

 

이것은 서비스 히스토리 데이터를 무엇으로 할 것인지에 대한 것이다. DO-178 가이드라인에서는 다음과 같은 두 가지 예를 들고 있다.

 

-       비행시간: 비행동안에 계속해서 사용되는 소프트웨어인 경우, 예를 들면 비행 조종 소프트웨어

-       명령수행횟수: 명령에 따라서 수행되는 소프트웨어인 경우, 예를 들면 착륙 기어 소프트웨어

 

위의 두 가지가 가지고 있는 중요한 공통점은 ‘측정할 수 있다’는 것이다. 서비스 히스토리로 정의되고 인증당국의 동의를 받기 위해서는 이처럼 시스템의 동작과 관련된 측정이 가능해야 하며 그 결과가 제시될 수 있어야 한다.

 

②     알려진 형상

 

형상관리라는 것은 개발과정에서만 유지되고 활용되는 것이 아니다. 제품으로 출시된 이후 시장에서 문제가 발생하는 경우와 같은 변경사항이 생기면 형상관리는 그대로 이어져서 유지되어야 한다. 결과적으로 그것이 서비스 히스토리로 형상 관리되는 것이다. 여기서 중요한 점은 소프트웨어 자체가 형상관리되어야 하는 것은 물론이고 시스템 안전성 목표와 관련된 부분이 있다면 그에 대한 부분도 함께 형상관리되어야 한다는 점이다.

 

③     운영 시간 수집 프로세스

 

앞서 살펴본 ①이 서비스 히스토리를 측정하는 대상(Target)에 대한 내용이라면 여기서 말하는 것은 그 대상을 측정하는 방법에 대한 내용이다. 즉, 비행시간이나 명령수행횟수를 어떤 방법으로 측정할 것인지를 정확하게 제시할 수 있어야 한다는 말이다. 그런데 이때 측정에 영향을 줄 수 있는 요인이 있을 수 있다. DO-178 가이드라인에서는 다음과 같은 항목들을 제시한다.

 

1.      소프트웨어와 시스템 형상

2.      동작 모드 혹은 상태

3.      운영 환경

 

만약 위의 항목 중 측정에 영향을 줄 수 있는 요인이 있는 경우에는 측정시에 반드시 그에 대한 고려가 되어야 정확한 결과를 얻을 수 있다.

 

④     소프트웨어에 대한 변경

 

항공기에 탑재되는 소프트웨어가 변경되는 경우에는 그것으로 인해서 일어날 수 있는 여러 가지 상황을 고려해야 한다. 특히 시장에 출시되어 이미 항공기에 탑재되어 운영되고 있는 소프트웨어라면 그 부분은 더욱 중요해진다. 제품 서비스 히스토리가 운영되고 있는 과정에서 소프트웨어가 변경되는 경우 혹시 이전에 수집된 서비스 히스토리 데이터에 미치는 영향이 없는지 확인하는 부분 역시 놓쳐서는 안되는 부분이다.

 

⑤     사용과 환경

 

소프트웨어가 의도된 대로 사용될 수 있는지를 보여주기 위해서 제품 서비스 히스토리의 적절성을 위한 다음의 내용들이 분석되어야 한다.

 

1.      사용될 소프트웨어 기능이 모든 동작 모드에서 수행된다는 것을 보장해야 함

2.      입력 데이터의 적절한 변경이 수행된다는 것을 보장하는 분석이 수행되어야 함

3.      서비스 히스토리 데이터를 모으기 위해 사용된 운영 환경이 적용하고자 하는 현재의 운영환경과 일치하는지 확인해야 함. 만약 다른 경우에는 타겟 환경에서의 시스템 안전성 목표를 준수하는지를 확인하는 추가적인 검증이 필요함

4.      하드웨어 환경에 대한 부분도 고려해야 하는데 서비스 히스토리 기간 중에 하드웨어가 변경된 경우에는 그로 인한 영향이 평가되어야 함

 

⑥     비활성화된 코드

 

서비스 히스토리 기간 동안에 비활성화된 코드가 새로운 환경에서 활성화되지 않는다는 것을 보여주는 분석이 수행되어야 한다. 만약 활성화되는 부분이 발견되면 당연히 그에 대한 추가적인 검증이 수행되어야 한다.

 

(2)    축적된 서비스 히스토리의 충족 (Section 12.3.4.2)

 

그렇다면 이러한 서비스 히스토리가 어느 정도 확보되어야 유효하다고 인정할 수 있을까? DO-178 가이드라인에서는 이에 대한 절대적인 기준은 제시하지 않는다. 대신 다음과 같은 기준에 따라서 결정될 수 있다고 설명하고 있다.

 

a.      소프트웨어의 시스템 안전성 목표와 소프트웨어 레벨

b.      서비스 히스토리 환경과 시스템 운영 환경에서의 차이점

c.      서비스 히스토리에 의해서 언급되고 있는 section 4 에서 9까지의 목표

d.      서비스 히스토리에 더해서 그러한 목표를 언급하는 증거

 

하나같이 간단한 기준이 아니다. 결국 이는 지원자가 인증당국과의 협의를 통해서 결정할 수 밖에 없다.

 

(3)    서비스 히스토리 과정에서 발견된 문제점의 수집, 리포트 그리고 분석 (Section 12.3.4.3)

 

앞서 소프트웨어의 변경과 관련된 형상관리 등에 대해서 설명한 부분이 있는데 여기서는 특히 소프트웨어 변경과 관련된 문제점 리포트에 대해서 좀 더 상세하게 설명하고 있다. 크게 다음과 같은 점을 중심으로 이야기하고 있다.

 

-       문제점 리포트 프로세스에 대한 부분

-       프로세스 자체의 문제점과 관련된 부분

-       안전성과 관련된 문제점에 대한 부분

 

①     문제점 리포트 프로세스에 대한 부분

 

제품 서비스 히스토리 과정에서 발생하는 문제점은 당연히 리포트 되어야 한다. 또한 그 데이터는 기록되어야 하고 언제 어디서든 필요한 시점에 다시 얻을 수 있어야 한다. 이 과정에서 고려되어야 할 부분에 대해 DO-178 가이드라인에서는 다음과 같은 내용들을 제시하고 있다.

 

n  수집되어야 할 특정 데이터는 인증당국의 동의를 받아야 하며 각각의 기록되는 문제점에 대해서 DO-178 가이드라인 Section 11.17에서 설명된 항목들을 포함해서 다음과 같은 정보들이 포함되어야 함

 

      i.        문제가 발생한 시점에 영향을 주었던 하드웨어/소프트웨어 형상

     ii.        문제가 발생한 범위내에서의 운영 환경

    iii.        문제가 발생한 범위내에서의 운영 모드 혹은 상태

    iv.        문제점 평가를 위해 필요한 운영 특정 정보

     v.        엄격함, 안전성 중요도 그리고 그 문제가 서비스 히스토리 데이터 수집이 시작된 이후 소프트웨어 형상에서의 변경의 결과였는지에 대한 구분

    vi.        문제가 재현가능한지, 복구가능한지, 공통 원인과 같은 이전에 보고된 문제점과 관련되는지에 대한 평가

 

 

n  문제점 리포트의 연대기적인 경향이 평가되어야 하고 증가되는 경향이 있다면 설명되어야 함

n  소프트웨어 에러 히스토리의 완전성이 기술되어야 함. 여기에는 다음과 같은 것이 포함됨

      i.        문제점을 탐지하고 문제점 로그를 유지하는 능력

     ii.        운영자가 문제를 리포트하기위한 방법

    iii.        문제점 리포트 기록의 완전성

    iv.        문제점이 안전성과 관련되는지 그렇지 않은지에 대해서 지원자가 그것을 결정할 수 있는 방법

     v.        지원자가 특정 문제의 발생 횟수를 결정할 수 있는 방법

 

이미 서비스가 된 상태에서 발생하는 문제점이기 때문에 하나의 문제점에 대해서도 정말 많은 것들이 걸려있고 정말 많은 것들이 고려되어야 한다는 점을 다시 한 번 실감할 수 있는 설명이다.

 

②     프로세스 자체의 문제점과 관련된 부분

 

만약 설계나 코드상의 에러와 같은 부적절한 프로세스를 나타내는 문제점인 경우에는 하드웨어나 시스템 요구사항 에러와 같은 그 원인이 DO-178 가이드라인을 벗어나는 그런 것들과는 분리되어 표시되어야 한다. 물론 이런 경우라면 문제가 상당히 심각할 가능성이 높아지는 것이기 때문에 정확한 판단을 하기 위해서는 복잡하고 정확한 분석이 필요할 것이다.

 

③     안전성 관련 문제점에 대한 부분

 

운영 중에 발생하는 모든 문제는 안전성과 관련되는지, 그리고 안전성과 관련된 모든 문제점이 수정이 되었는지가 반드시 확인되어야 한다.

 

(4)    PSAC에 포함되어야 하는 서비스 히스토리 정보 (Section 12.3.4.4)

 

DO-178 인증을 위해서 서비스 히스토리가 사용될 경우 당연히 PSAC(Plans for Software Aspects of Certification)에 관련된 내용이 포함되어야 한다. 그리고 그렇게 포함된 것들은 당연히 인증당국의 승인을 받아야 한다. DO-178 가이드라인에서는 그러한 정보로써 다음과 같은 항목들을 제시하고 있다.

 

a.      서비스 히스토리의 적절성을 주장하는 이유, Section 12.3.4.1과 관련됨

b.     이유와 함께 필요한 서비스 히스토리의 양, Section 12.3.4.2와 관련됨

c.      전체 연관 서비스 히스토리 기간을 계산하는 것에 대한 이유, 여기에는 동작 모드, 설치와 서비스 내에서 독립적으로 동작하는 복사본의 수, 그리고 “정상 구동”과 “정상 구동 시간”의 정의와 같은 것을 포함

d.     에러로 카운트되는 것에 대한 정의와 그 정의에 대한 이유, Section 12.3.4.3a와 관련됨

e.      받아들여질 수 있을 정도로 제안된 에러율과 그와 관련된 제품 서비스 히스토리 기간에 대한 이유, Section 12.3.4.3b와 12.3.4.3c와 관련됨

f.       Section 12.3.4.3 혹은 다른 이유로 서비스 히스토리를 무효화할 수 있는 문제점에 대한 기준의 정의

g.     수정될 에러에 대한 기준, 그것이 수정되고 검증되는 방법, 아무 행위없이 그냥 그대로 진행하는 결함이 있을 경우 그에 대한 이유

h.     서비스 히스토리의 사용을 통해서 기술되어야 하는 Section 4에서 9에서의 목표

 

DO-178 가이드라인의 특성 상 제시된 모든 지침을 반드시 따라야 하는 것은 아니다. 하지만 실제로 진행하는 과정에서는 결과적으로 이처럼 하나하나 꼼꼼히 체크하고 따질 수밖에 없는 것도 현실이다. 무엇보다도 PSAC의 특성이 DO-178 인증 과정에서 가장 먼저 작성되고 인증당국과의 협의를 거친다는 점에서 서비스 히스토리에 대한 내용 역시 궁극적으로는 인증당국과 협의를 통해서 최종 결정된다는 것을 기억하자.