26. 툴인증

 

역주) 앞서 툴인증에 대해서 여러 번 언급한 부분이 있다. 이 책에서 저자가 설명하는 부분은 DO-178B를 기준으로 설명하고 있으며 DO-178C에서는 개념이 조금 달라졌다는 점도 언급했었다. 기본적인 개념은 거의 유사하므로 여기서의 내용을 그대로 이해하고 있어도 실전 진행에 큰 무리는 없을 것이다.

 

툴인증이라는 주제는 비록 DO-178과 DO-254가 상당부분 동일하다고 하더라도 종종 잘못 인식되고 있다. DO-178과 DO-254 사이의 주요 차이점은 툴인증에 대해서 설명하는 플로우차트에 있는데 그것은 별도로 설명될 것이다. 인증이 필요한 툴의 두 가지 종류가 있다. 개발툴과 검증툴이다. 검증툴은 인증하기기 더 간단한데 그들은 당신의 제품에 에러를 넣을 수 없기 때문이다. 그들은 단지 에러를 탐지하는데 실패할 수 있다. 개발툴은 만약 제대로 개발되거나 사용되지 않으면 실제로 에러를 주입하게 될 수도 있다.

 

인증의 목적으로 툴은 DO-178B와 DO-254에 언급된 수동으로 진행하던 활동들을 자동화하고 대신하거나 강화하는 보조수단이다. 일반적인 검증툴은 프로세스를 정확하게 수행하는데 사용되며 시험 케이스 생성툴, 시험 실행 환경, 시험 통과/실패 결정툴, 시뮬레이션/스티뮬레이션(Stimulation)툴, 버스 인터페이스/캡처툴 등을 포함한다. 일반적인 개발툴은 코드생성기, 모델링툴, 컴파일러 등이 있다. 당신이 정말로 물어볼 필요가 있는 오직 2가지 최초 질문은 다음과 같다. (1) 그것이 검증툴인가 아니면 개발툴인가? 그리고 (2) 그 툴은 검증을 받을 필요가 있는가?

 

따라서 먼저 DO-178B와 DO-254에 언급된 수동으로 진행하던 활동들을 자동화하고 대신하거나 강화하는지를 결정한다. 위에서 언급한 모든 항목들은 “툴”의 정의를 만족하며 그에 따라서 언급되어야 한다. 하지만 진정한 질문은 당신이 그것을 인증 받을 필요가 있는가이다. 우리가 마주치는 가장 흔한 실수들 중 하나는 이러한 간단한 질문들에 기반한다. 우리는 인증 받아야만 하는 툴을 인증하는데 실패하는 것과 인증 받을 필요가 없는 툴을 인증 받으려고 하는 것을 계속해서 보고 있다.

 

어떤 툴이 인증 받을 필요가 있는지를 결정하는 데에는 세 가지 이어지는 질문들이 있다. 세 개의 노드가 있고 “AND” 함수이다. 모두 “Yes”인 경우에 인증을 받을 필요가 있다는 것에 대한 최종적인 “Yes”를 얻게 된다. 그런 다음에 당신은 그 툴을 개발 혹은 검증 계획하에서 인증을 하게 된다. 만약 그 중 어떤 질문이라도 “No”라는 답이 있다면 당신은 그것을 인증 받을 필요가 없다.

 

첫 번째 질문은 “툴이 제품 내부로 오류를 주입할 수 있는가 혹은 오류를 구분해 내는데 실패하는가?” 이다. 만약 답이 “Yes”라면 일반적으로는 “No”를 받게 되는 두 번째 질문으로 이어진다. 이 두 번째 질문은 때때로 컴파일러를 포함해서 많은 툴의 툴인증에 대한 필요성을 제거하게 된다.

소프트웨어 툴인증 두 가지 유형의 툴이 있음:   검증툴: 에러를 주입할 수는 없지만 그것들을 검출하는 데 실패할 수도 있는 툴 개발툴: 출력이 항공 소프트웨어의 일부이고 그래서 에러를 주입할 수 있는 툴   당신은 툴을 인증 받을 필요가 있는가? 아래의 질문들을 제기하자.   1.     툴이 소프트웨어 오류를 주입할 가능성이 있는지 혹은 그런 오류가 검출되지 않을 가능성이 있는가? 2.     DO-178B Section 6에서 언급한 것처럼 툴의 출력에 대한 검증을 생략하려고 하는가? 3.     DO-178B 프로세스가 제거되거나 감소하거나 혹은 자동화되는가?   만약 모든 답이 “Yes”라면 당신의 툴은 시험 혹은 개발툴로써 인증을 받아야 한다.

 

컴파일러를 사용해서 DO-178B Section 6에 정의된 것처럼 확인해 보자. 컴파일러가 코드로 에러를 주입할 수 있는가? 분명히 그렇다. 잘못된 컴파일러는 코드 내부로 에러를 넣을 수 있고 그래서 첫 번째 질문에 대한 답은 “Yes”이다. 하지만 두 번째 질문을 보자. 내가 목적 코드를 검증하지 않으려고 하는가? 나는 목적 코드에 대해서 시험을 수행하고 따라서 그 답은 “No”이다. 나는 이 단계에서의 검증을 생략할 의도가 없으며 따라서 이 질문에 대한 답은 “No”이고 나는 컴파일러를 인증받을 필요가 없다.

역주) 위의 컴파일러에 대한 예시가 이 섹션의 모든 것을 대변하고 있다. 검증툴이냐 개발툴이냐가 중요한 기준이지만 결국 중요한 것은 어떤 툴을 사용하든 그 결과물을 내가 검증하지 않는 경우이다. 툴에서 나온 결과물을 검증하지 않는다는 것은 내가 그 툴을 신뢰한다는 것이다. 그리고 그 신뢰하는 툴에서 나온 결과물도 신뢰한다는 것이다. 그런데 그 신뢰를 누가 보증할 수 있을까? 툴을 만든 회사에게 물어 보면 당연히 자신들의 툴이 완벽하다고 하겠지만 그것을 근거로 해서 FAA 혹은 DER에게 이 툴을 신뢰할 수 있다고 말한다면 FAA 혹은 DER은 그것을 받아들이지 않는다. 그것은 객관적인 증거가 아니기 때문이다. 여기서 필요한 객관적인 증거가 바로 툴인증이다.   사실 툴인증을 받는 것은 상당히 어렵다. 돈도 많이 들고 시간도 엄청나게 많이 든다. 무엇보다도 어떻게 받아야 하는지 아는 사람이 잘 없다. 그렇다면 다른 방법은 툴에서 나온 결과를 하나하나 검증하는 수 밖에 없다. 그렇게 하겠다고 한다면 당신은 더 이상 툴인증에 대해서 신경 쓸 필요가 없다. 툴인증에 대해서는 이런 개념을 이해하는 것이 핵심이다.

 

이제 형상관리(CM)툴을 보자. 그것은 우리가 리비전 컨트롤을 유지하도록 하는데 어떤 것을 형상관리로 등록할 때 무슨 일이 발생하는가? 툴에서의 오류가 소스코드내의 오류에 영향을 줄 수 있는가? 그렇다. 하지만 DO-178B에 따라서 누군가는 그 코드를 리뷰할 필요가 있고 살펴보게 되는 첫 번째 항목 중 하나는 버전 번호, 변경 이력 그리고 변경된 부분과 같은 것들이다. 그것은 형상관리를 확인하게 된다. 따라서 컴파일러의 경우에서처럼 형상관리툴 또한 인증 받을 필요가 없다.

 

우리가 일반적으로 검증하는 주요 툴은 검증툴, 특히 구조적 커버리지 분석툴로 한정할 수 있다. 코드를 변경하게 되는 입력 신호 생성기와 구조적 커버리지 분석툴과 같은 시험툴이 있다. 하나는 시험코드를 입력하고 다른 것은 커버된 포트를 기반으로 결과를 분석한다. 시험코드 입력기는 검증툴의 일부이다. 따라서 당신은 시험코드를 입력하고 커버리지를 위해서 코드의 구조를 분석하기 위해 구입한 툴을 인증한다. 코드에 무언가를 입력하긴 하지만 결국 그것은 검증툴이다. 그것은 최종 제품에 에러를 주입하지 않는다. 왜냐하면 시험코드는 실제 비행하는 코드에는 포함되지 않기 때문이다. 따라서 그 이유로 그것은 개발툴이 아니다.

역주) 원서의 ‘instrument’ 라는 단어를 ‘시험코드 입력’이라고 번역했다. 어색하다는 것을 잘 알고 있지만 아직까지도 마땅한 단어를 못 찾은 상태다. 중요한 것은 커버리지 분석툴의 동작 개념을 이해하는 것이다. 그래야 저자의 설명, 역자의 어설픈 설명이 제대로 이해될 수 있다. 참고로 DO-178 인증을 받기 위해서는 커버리지 분석툴에 대한 교육과 실제 사용을 해 보는 것이 필수이다.

 

산출물: 개발툴 혹은 검증툴을 위한?   개발툴   System PSAC Tool Qualification Plan Tool Operational Requirments Tool Accomplishment Summary System Software Accomplishment Summary(SAS)   검증툴   System PSAC Tool Operational Requirements System Software Accomplishment Summary(SAS)

 

툴인증을 위한 지원의 일부로써 무엇이 제공되어야 하는가? 당신은 이미 시스템과 소프트웨어를 위한 PSAC을 가지고 있다. 이제 당신은 그 개발툴을 위한 또 다른 인증 계획을 개발하게 된다. 코드생성기를 예로 들면 당신이 인증 받은 코드생성기를 사용하고 있기 때문에 그 모델에 대해서는 리뷰를 하지 않거나 혹은 DO-178B Section 6에서처럼 동일한 엄격함으로 코드를 검증하지 않는다고 적게 된다. 그런 다음 당신은 툴 자체에 대한 운영 요구사항을 가지는 검증 계획이 필요할 것이다. 이것은 항공기에 탑재되어 운항되는 제품에 대해서와 마찬가지로 요구사항, 설계 그리고 사용에 대한 동일한 레벨의 엄격함을 가진다.

 

툴 자체에 대한 Accomplishment Summary. Tool Operational Requirements 내에 당신은 또한 툴을 개발하기 위해 사용하는 프로세스들을 포함한다. 당신은 툴을 위한 적절한 형상관리 활동을 가지고 있고 따라왔는가? 품질보증 담당자가 관여했는가? 당신은 자체 개발 소스코드에 대해서 그런 것처럼 동일한 위험 레벨에 따라서 툴의 기능을 검증했는가? 코드 파일에 대해서 시스템과 동일한 위험레벨로 툴코드 자체에 대한 구조적 커버리지 분석을 수행했는가? 당신은 이미 PSAC을 개발하고 있고 따라서 거기에 툴에 대한 정보를 포함하고 있다. Tool Operational Requirement는 내용면에서 훨씬 더 가볍고 Accomplishment Summary에서 당신은 그것이 어떻게 개발되었는지에 대한 요약을 포함한다.

 

개발툴에 대한 Tool Operational Requirement는 두 개의 개발프로세스를 가진다. 툴검증과 툴 자체의 구조적 커버리지 분석이다. 에러 조건 응답이 반드시 포함되어야 한다. 다른 말로 하자면, 그것이 어떻게 반응하는지를 보기위해 툴로 에러를 주입하는 것이다. 그 툴은 많은 다른 기능을 수행하겠지만 당신은 단지 그 일부만 사용하기를 원하고 있다. 그것만이 인증받을 부분이다. 그것이 비정상이 아닌 정상적으로 동작하는 것을 보이고 시험하라.

역주) 툴인증에 대한 부분은 너무 깊게 들어갈 필요는 없다. 사실 DO-178 인증을 받을 기회도 갖기 어려운데 툴인증을 받을 경우는 사실상 없을 것이기 때문이다. 혹시 본인의 회사가 툴을 개발하는 회사이고 툴인증을 받는 것에 대해서 관심이 있다면 이 책의 설명은 그야말로 그냥 이런 게 있구나 정도로만 이해하고 DO-330 가이드라인을 구해서 정독하기를 권장한다. 다만 유의해야 할 점은 DO-178에 대한 지식을 기본으로 가지고 있어야 한다는 것이다. DO-330이 독자적으로 작성되었다고는 하지만 툴인증의 성격상 DO-178 혹은 DO-254에 대한 지식이 필수라고 할 수 있다.

 

툴운영 요구사항(Tool Operational Requirements)   개발툴   툴 기능과 운영 환경 운영과 설치 정보 툴 개발 프로세스 툴 검증 & 구조적 커버리지 분석 에러 조건 반응 검증툴   사용되는 컴포넌트에 대한 툴 기능과 운영 환경 운영과 설치 정보 사용되는 툴 컴포넌트의 기능 시험

 

DO-254에서의 툴인증에 대한 전체 프로세스는 DO-178B와는 약간 다르다. DO-254에서는 만약 레벨 A, B 혹은 C 설계툴 혹은 레벨 A 그리고 B 검증툴이라면 당신은 특정한 인증 활동이 필요하다고 말한다. DO-254는 서비스 이력이 있을 경우 융통성을 제공한다. DO-178B는 그렇지 않다. 따라서 그 테이블은 당신이 툴인증이 필요한지를 묻는다. 만약 아니라면 당신은 그걸로 다 한 것이다. 툴이 이전에 이런 환경에서 사용되었는가? 만약 그렇다면 당신은 많은 일을 할 필요없이 이미 존재하는 데이터를 참조해라. 그런 다음 만약 그것이 레벨 A 혹은 B의 설계툴이라면 검증툴과 설계툴 인증을 위한 기본적인 툴인증을 수행하라. DO-254에는 사용되는 툴셋에 기반한 ASIC과 PLD의 개발이 자주 일어나기 때문에 많은 설계툴이 사용된다.

 

툴인증을 결정하는 프로세스에 대한 다이어그램이 아래에 제공되고 있다. DER과 모든 툴인증의 특성에 대해서 논의하고 당신의 툴에 대해서 인증을 실패하거나 과하게 인증을 받지 않도록 논의하는 것을 기억하자.

역주) 툴인증에 대해서 지금 당장은 잘 몰라도 좋다. 사실 그 부분은 DER에게 어떻게 하면 되는지 물어보는 것이 가장 좋다. 극단적으로는 DER이 시키는 대로 하면 된다. 보통은 툴인증을 받지 않을 수 있는 쪽으로 가이드를 해 줄 것이다. 하지만 혹시라도 툴인증을 받으라고 한다면 그때는 정말로 제대로 알고 진행해야 한다. 역자의 예상으로는 그런 경우는 거의 없을 것이다.

 

DO-254에 대한 설계 및 검증툴 평가 및 인증