ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 33. 툴인증(Tool Qualification) (Section 12.2)
    잡談/DO-178 기본 2019. 1. 7. 17:18

    DO-178 인증에서 툴인증(Tool Qualification)은 상당히 밀접한 관련이 있으면서도 한편으로는 완전히 분리된 대상이다. 모순된 이야기로 들릴 수도 있겠지만 이 말을 이해하기 위해서는 DO-178 인증과 툴인증과의 히스토리를 살펴볼 필요가 있다.

     

    먼저 DO-178의 히스토리, 그 중에서도 DO-178 가이드라인의 히스토리를 살펴보자. 인터넷으로 구글링을 해보면 아래와 같은 표를 볼 수 있다.

     

    출처: https://slideplayer.com/slide/3890726/

     

    지금은 DO-178 인증과 관련된 사업분야가 분리되긴 했지만 HighRely라는 회사에서 만든 DO-178 관련 발표자료에 포함된 내용이다. 참고로 DO-178 가이드라인의 업데이트에 대한 히스토리는 DO-178 가이드라인 부록(Appendix) A에 아래와 같이 설명되어 있다. (일부 발췌)


     


    앞서 본 표의 내용을 포함해서 좀 더 자세히 설명되어 있으므로 관심있는 분들은 참고하시기 바란다.

     

    다시 위의 표를 보면 DO-178 가이드라인은 최초 DO-178이라는 이름으로 뒤에 아무런 알파벳없이 만들어 졌다가 이후 A à B à C가 붙으면서 업데이트된 것을 확인할 수 있다. 특히 DO-178BDO-178C에 대한 ‘Themes’를 보면 붉은색으로 표시된 ‘tools’가 보일 것이다. 실제로 처음 나왔었던 DO-178과 그 다음 버전인 DO-178A에서는 툴에 대한 가이드라인이 없었다가 DO-178B에서 처음 툴에 대한 가이드가 추가되었다.

     

    그럼 여기서 DO-178BDO-178C‘tools’는 어떤 차이가 있는 것일까? 결론부터 말하자면 DO-178B에서는 툴인증(Tool qualification)DO-178 가이드라인 문서 내부에 포함되어 있었지만 시간이 흐를수록 툴인증의 중요성이 높아지고 적용 범위가 점점 더 넓어지면서 DO-178C에서는 아예 툴인증이 별도로 분리되어 ‘DO-330’이라는 독자적인 인증으로 만들어졌다. 아래가 DO-330 가이드라인의 표지이다. 2011년에 RTCA에서 만들었다는 것을 확인할 수 있다.

     

     

    위의 표에는 그 외에도 설명할 부분이 많이 있지만 여기서 중요한 것은 툴인증에 대한 부분이므로 다른 것들에 대해서는 추후 기회가 되면 별도로 설명하겠다.

     

    이처럼 툴인증은 DO-178과 상당히 밀접한 관계가 있으면서 동시에 그 범위가 확대됨으로써 이제는 별도의 인증으로 분리된 상태로 이전과 동일한 수준의 밀접한 관계를 유지하고 있다. 이를 반영하듯 DO-178 가이드라인에서는 아래와 같이 DO-330으로의 참조를 설명하고 있다.


     

    그런데 이렇게 DO-178과 밀접한 관계가 있다는 툴인증은 도대체 어떻게 적용하는 것일까? 필자가 현장에서 경험하기로는 DO-178에서 툴인증이 중요하다는 점은 점차 많은 사람들이 인지를 하고 있는 것 같은데 생각보다는 그 중요성에 비해서 툴인증에 대한 이해는 많이 떨어지는 것이 아닌가 싶다. 이것은 근본적으로 DO-178부터가 어렵기 때문에 미처 툴인증에 대한 이해까지 도달하지 못하는 것이 가장 큰 원인이 아닌가 싶다. 결국 여기에서 설명되는 툴인증을 이해하기 위해서는 지금까지 설명한 DO-178 가이드라인의 내용에 대해서 먼저 이해를 하고 있어야 한다. 만약 아직도 앞부분의 설명이 잘 이해가 안되는 분들은 이번에는 이 부분을 가볍게 읽어 보는 정도로 넘어가고 다음에 다시 학습하는 것도 방법이 될 것이다.

     

    DO-178 인증을 위한 과정에서 툴인증에 대한 의사결정은 기본적으로 다음과 같은 과정을 거치게 된다.

     

        툴인증이 필요한지를 결정

        툴인증 레벨을 결정

        툴인증 프로세스를 수행

     

    정리된 내용은 간단하기 그지 없지만 툴인증을 수행할지에 대한 판단은 물론이고 실제로 진행하는 과정은 결코 간단하지가 않다. 별도의 가이드라인으로 만들어 진 것에서도 짐작이 되겠지만 툴인증은 메인이라고 할 수 있는 DO-178 인증에 버금가는 비용과 리소스가 필요한 작업이라는 점을 염두에 두고 앞으로 나오는 내용들을 이해하도록 하자.

     

    (1)    툴인증이 필요한지를 결정 (Section 12.2.1)

     

    기본적으로 툴인증은 선택의 문제이다. , 지원자가 툴인증을 받을지 혹은 받지 않을지를 자신의 의지로 선택할 수 있다는 말이다. 간혹 DO-178 인증을 받으려고 하는 업체들 중에는 툴인증을 무조건 받아야 하는 것으로 알고 있는 경우가 있는데 이는 DO-178과 툴인증에 대해서 정확하게 이해하지 못하고 있다 보니 잘못된 정보를 그대로 받아들이면서 오해를 하게 된 경우라고 할 수 있다.

     

    일단 이에 대한 가이드라인의 설명은 다음과 같이 시작한다.


     

    해석을 보자.

     

    툴에 대한 인증은 출력에 대해서 Section 6에 기술된 것 같은 검증없이 소프트웨어 툴의 사용에 의해서 이 문서(참고: DO-178 가이드라인)의 프로세스가 제거되거나, 줄어들거나 혹은 자동화될 때 필요하다.

     

    우리가 툴을 사용하는 것은 단순하게 생각하면 편하기 위해서이다. 사람이 일일이 수작업으로 할 부분을 툴을 사용함으로써 빠른 시간에 쉽게 수행할 수 있다. 이렇게 편리한 툴을 사용하게 되면 결과적으로 개발 과정에서 사람이 수행할 부분 혹은 전체가 제거되거나, 줄어들거나 혹은 자동화된다. 이것이 바로 위에서 설명하는 내용이다.

     

    그런데 여기에서 DO-178은 다음과 같은 질문을 하게 된다.

     

    당신이 사용한 툴이 혹시 잘못된 결과를 만들어 낼 가능성은 없는가?’

    당신이 사용하는 툴이 완벽한가? 그것을 어떻게 보장할 수 있나?’

     

    말도 안되는 질문이라고 생각하는 사람들도 있을 것 같은데 DO-178에서는 바로 이 질문을 하고 그에 대한 답을 요구하게 된다. 그리고 그 답의 한 가지로 제시할 수 있는 것이 지금 이야기하고 있는 툴인증이라는 것이다.

     

    이에 대해서 DO-178 가이드라인에서는 아래와 같이 설명하고 있다.


     

    해석을 보자.

     

    툴인증 프로세스의 목적은 적어도 툴이 제거되거나 줄어들거나 혹은 자동화되는 프로세스의 그것과 동등한 확신을 제공한다는 것을 보장하는 것이다.

     

    결국 이러한 목적에 기반해서 보면 툴인증을 받을 것인지 받지 않을 것인지는 툴의 결과물을 그대로 믿고 사용할 것인지 아니면 믿지 못하고 결과물을 하나하나 검증할 지에 대한 결정에 달려있다. 그리고 그 선택에 따라서 다음과 같은 장단점을 예상할 수 있다.

     

    구분

    툴인증을 받음

    툴인증을 받지 않음

    장점

    결과물에 대한 검증을 생략할 수 있으며 결과물에 대한 확실한 안전성을 보장받을 수 있음 (결과물을 인증당국에 그대로 제출할 수 있음)

    툴인증에 소요되는 비용과 리소스를 절감할 수 있음

    단점

    툴인증을 받기 위한 많은 비용과 리소스, 시간이 필요

    결과물에 대해서 사람이 직접 확인해야 하므로 그 만큼의 리소스와 비용, 시간이 소요됨

     

    툴인증을 받지 않기로 결정했다면 이후의 내용은 굳이 지금은 보지 않아도 된다. 대신 툴에서 나온 결과물을 하나하나 직접 검사해서 문제가 없다는 것을 확인해야 한다. 하지만 툴인증을 받기로 결정했다면, , 툴인증의 필요성이 확인되었다면 이제 다음 단계로 넘어가 보자.

     

    (2)    툴인증 레벨을 결정 (Section 12.2.2)

     

    DO-178에는 레벨 A ~ E까지의 소프트웨어 레벨에 대한 구분이 있다. 툴인증에도 유사한 형태의 인증 레벨이 존재한다. 툴인증을 받기로 결정했다면 먼저 어느 레벨로 받을 것인지를 결정해야 한다. 여기서 말하는 레벨이 무엇인지를 DO-178 가이드라인에서는 다음과 같이 설명하고 있다.


     

    해석을 보자.

     

    만약 툴인증이 필요하다면 소프트웨어 라이프 사이클 프로세스에서의 툴사용의 영향은 TQL(Tool Qualification Level)을 결정하기 위해 평가되어야 한다.

     

    우선 툴인증에 대한 레벨은 TQL(Tool Qualification Level)이라는 용어를 사용한다. 그리고 여기에서 말하는 레벨은 툴을 사용함으로써 소프트웨어에 미치는 영향에 따른 구분을 말하는 것이다. 툴을 사용함으로써 소프트웨어에 영향을 미친다는 것은 무슨 뜻일까? DO-178 가이드라인에서는 이에 대한 설명을 위해서 아래와 같은 세 가지 기준으로 설명하고 있다.


     

    해석을 보자.

     

    a. Criteria 1: 툴의 출력이 항공기 소프트웨어의 일부이고 그래서 에러를 입력할 수 있는 툴

    b. Criteria 2: 검증 프로세스를 자동화하고 그래서 에러를 검출하는 데 실패할 수 있는 툴이며 그 출력이 다음의 제거 혹은 감소를 정당화하는데 사용되는 툴

    1. 툴에 의해서 자동화되는 검증 프로세스 이외, 혹은

    2. 항공기 소프트웨어에 영향을 줄 수 있는 개발 프로세스

    c. Criteria 3: 의도된 사용 범위내에서 에러를 검출하는데 실패할 수 있는 툴

     

    위의 설명을 좀 더 쉽게 이해하기 위해서 DO-178 가이드라인의 이전 버전(DO-178B)에서 정의한 부분을 살펴보는 것이 도움이 될 것 같다. 다음을 보자.


         출처: SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICATION (DO-178B) / RTCA

     

    위의 내용에 대한 해석은 생략하고 간단하게 정리하면 소프트웨어 개발툴소프트웨어 검증툴두 가지로 나눈 것이다. 앞서 나눈 세 가지 기준과는 확연히 다르다는 것을 알 수 잇다. 사실 우리가 보기에는 확실히 앞서 본 세 가지의 기준에 비해서 이전 버전의 두 가지 기준이 상대적으로 명확하고 구분하기도 쉽다. 하지만 이는 이론적인 구분으로 이후 툴인증이 진행되면서 실제 툴이 미치는 영향이 두 가지 구분만으로는 애매한 부분이 생기면서 DO-178C에서는 세 가지 기준으로 확장된 것이다. DO-330에도 아래와 같이 이전버전과 비교해서 설명하는 부분이 들어있다.

     

         출처: Software Qualification Considerations / RTCA

     

    사실 세 가지 기준의 설명도 기본적으로는 개발툴과 검증툴의 구분에 기반한 것이다. 그래서 Criteria 1의 경우는 명확하게 개발툴에 대한 것이고 Criteria 3은 검증툴에 대한 것이다. 문제는 Criteria 2인데 이에 대한 자세한 설명과 샘플을 DO-330에서 확인할 수 있다. 여기서 그 부분을 모두 설명하기는 어렵고 핵심만 정리하자면 다음과 같다.

     

    -       Criteria 3은 검증툴이 사용되는 목표(Objective)에만 국한해서 사용되고 영향을 미치게 됨

    -       Criteria 2는 검증툴이 사용되는 목표(Objective)뿐만 아니라 검증 프로세스 혹은 개발 프로세스의 다른 영역까지도 영향을 미치게 됨

     

    일단 툴을 구분하는 기준에 대해서는 이 정도로 정리하고 혹시 더 자세한 내용을 알고 싶은 분은 DO-330의 아래 부분을 살펴보기 바란다.


     

    이상의 내용을 바탕으로 TQL은 최종적으로 다음과 같이 구분된다.

     

     

    위의 표가 설명하는 것은 툴이 사용되는 소프트웨어 레벨이 무엇인지, 그리고 사용하는 툴이 앞서 설명한 Criteria 1, 2, 3 중 어디에 속하느냐에 따라서 TQL이 결정된다는 것이다. TQL-1 ~ TQL-55 단계 중 TQL-1이 가장 엄격한 레벨이고 TQL-5가 가장 덜 엄격한 레벨이다.

     

    툴인증에 대한 레벨이 결정되면 이제 툴인증을 본격적으로 수행하게 된다.

     

    (3)    툴인증 프로세스를 수행 (Section 12.2.3)

     

    DO-178 가이드라인에서는 더 이상 툴인증 프로세스를 수행하는 것에 대해서 지침을 제공하지 않으며 대신 아래와 같이 DO-330을 참조하라고 가이드하고 있다.


     

    해석을 보자.

     

    각각의 툴인증 레벨에 대해서 필요한 목표, 활동, 지침 그리고 소프트웨어 라이프 사이클 데이터는 DO-330 “Software Tool Qualification Considerations”에 기술되어 있다.

     

    DO-330은 이곳의 범위를 벗어나는 부분이므로 필자 역시 DO-330에 대한 설명은 생략한다.

     

    그런데 마지막으로 툴인증과 관련해서 알아야 할 부분이 있다. 바로 툴인증을 받는 두 가지 유형에 대한 것이다.

     

    (4)    툴인증을 받는다는 의미

     

    한 가지 질문을 해 보자. 툴인증은 누가 받을까? 앞서 지원자가 툴인증을 받을지 결정한다고 해놓고 무슨 말인가라고 생각하겠지만 여기에는 좀 더 고려해야 할 부분이 있다. 바로 툴을 사용하는 사람과 툴을 만든 사람이 다르다는 사실이다. 각각을 구분하면 다음과 같다.

     

    -       툴을 사용하는 사람: DO-178 인증을 받고자 하는 지원자

    -       툴을 만든 사람: 툴을 만든 제조사

     

    지금까지 우리는 툴을 사용하는 사람이 DO-178 인증을 받게 되므로 그 쪽을 중심으로 이야기를 해왔고 툴을 만든 사람에 대해서는 굳이 언급을 하지 않았다. 언급할 필요가 없는 것은 아니지만 아직은 언급할 시기가 아니었기 때문이다. 하지만 툴인증을 본격적으로 수행하는 시점에서는 툴을 사용하는 사람과 툴을 만든 사람에 대해서 명확하게 구분해야 할 필요가 생긴다. 그래야 제대로 툴인증을 수행할 수 있기 때문이다.

     

    사실 툴을 만든 사람역시 툴인증을 받아야 한다. 그런데 이렇게 말하면 툴을 사용하는 사람과 툴을 만든 사람이 동일한 툴인증을 받는 것처럼 생각하기 쉽지만 실제 받게 되는 각각의 툴인증은 전혀 다른 것이다. DO-178 가이드라인에서 그 부분을 명확하게 제시해 주었다면 좋았을 것 같은데 앞서 본 것처럼 DO-330을 참고하라는 말만 나와있고 다른 설명은 없는 상태이다.

     

    필자가 DO-330을 부분적으로 확인해 본 바로는 DO-330은 한 마디로 툴을 만든 사람을 위한 툴 인증이라고 할 수 있다. 물론 툴을 만든 사람툴을 사용하는 사람이 동일하다면 툴을 사용하는 사람에게도 해당된다고 할 수 있겠지만 근본적으로는 툴을 만든 사람DO-330 툴인증을 받는 것이다. 그렇다면 툴을 사용하는 사람이 받게 되는 툴인증은 무엇을 말하는 것일까?

     

    여기서 잠시 DO-178 인증에 사용되는 툴을 판매하는 한 외국 업체에서 광고하는 내용 중 일부를 한 번 보자.

     

    ※ 출처:

    https://www.rapitasystems.com/system/files/downloads/mc-pb-124_rapicover_tool_qualification_do-178bc_v4.pdf

     

    복잡한 표가 나오는데 이에 대한 설명이 다음과 같이 제시되고 있다. 참고로 위의 표와 아래의 설명은 Rapita Systems라는 외국의 업체가 RapiCover라고 하는 커버리지 분석 도구를 판매하면서 고객에게 제시하는 다양한 구매옵션에 대한 설명을 담고 있는 내용이다.


     

    해석을 보자.

     

    인증 옵션과 라이선스

     

    Table 2에서 보는 것처럼 당신이 RapiCover를 구매할 때 많은 인증 옵션을 가지고 있다.

     

    인증킷의 각각의 사용은 인증킷의 개별적인 라이선스가 필요하다. 하나의 사용은 하나의 타겟과 시험 환경에 특화된 툴설치로 정의되고 일반적으로 인증을 위한 단일 제출 혹은 적용을 나타낸다. 만약 당신이 동일한 시스템 혹은 프로젝트에 우리의 툴을 복수의 횟수로 사용하기를 원한다면 우리는 복수 라이선스 할인을 제공한다.

     

    위의 설명에 나오는 상세한 옵션에 대해서 이해하는 것은 일단 여기서는 넘어가기로 하자. 필자가 위의 사례를 통해서 보여주고 싶은 부분은 앞에서 언급했던 툴을 사용하는 사람툴을 만든 사람에 대한 구분이다. 업체의 광고 내용을 기준으로 정리하면 아래와 같다.

     

    -       툴을 사용하는 사람: RapiCover라는 툴을 구매하는 고객

    -       툴을 만든 사람: RapiCover를 판매하는 Rapita Systems라는 회사

     

    여기에서 툴을 사용하는 사람은 DO-178 인증을 받고자 하는 당사자이다. 그리고 DO-178 인증을 위해서 툴인증을 받기로 결정한 상태이다. 그런데 실제로 툴을 만든 사람은 Rapita Systems라는 전혀 다른 회사이다. 그렇다면 툴인증은 어떻게 받는 것일까? 바로 Table 2에 그 부분이 나온다.

     

     

    결론적으로 툴을 만든 사람, Rapita Systems에서는 툴만판매할 수도 있고 인증킷만 팔 수도 있다. 물론 둘 다 판매할 수도 있다. 핵심은 이것이다. ‘툴을 만든 사람이 툴도 팔고 인증킷도 판매를 하는 것이다. (여러가지 옵션은 구매 비용 조절을 위한 판매 옵션일 뿐이다.)

     

    정확한 이해를 돕고자 배경설명이 길었는데 이제 툴인증을 받는다는 의미를 정리해 보면 다음과 같다.

     

        DO-178 인증을 받는 지원자가 사용하는 툴에 대해서 툴판매(제작) 업체로부터 툴인증킷을 구매해서 제출하는 것

        그리고 툴제작 업체는 자신들이 제작하는 툴에 대해서 DO-178 인증에 적합하도록 툴인증을 받는 것

     

    두 가지 케이스 모두 결과적으로 툴인증을 받는 것이며 상황에 따라서 좀 더 상세한 구분을 하는 것이다.

     

    앞서 소개한 DO-330 가이드라인은 기본적으로는 에 대한 지침을 제공하는 것이다. 그리고 에 대한 것은 사실상 DO-330 가이드라인에 포함되는 것이라고 이해할 수 있다. 여기서 더 자세하게 설명하기는 어렵지만 (필자가 아직 완전히 이해하고 있지는 못한 상태) 어쨌든 툴인증에 대해서 혹시 잘못 이해하는 부분이 있다면 큰 그림으로는 이와 같이 생각하면 무리가 없을 것이다.

     

    실질적인 툴인증 프로세스를 설명하는 DO-330 DO-178과의 연계에 대해서는 필자가 좀 더 학습을 하고 가능하면 실무 경험까지 더해서 어느 정도라도 정리가 되면 공유하는 것으로 하겠다.

    댓글

Designed by Tistory.