1. 소개

DO-178B는 항공전자 소프트웨어 개발자들과 정부 인증 부서들에 가이드라인을 제공하기 위해 상업용 항공전자 산업계와 RTCA(연방 자문 위원회)에 의해서 개발되었다. 첫번째 버전인 DO-178은 기본적인 항공전자 소프트웨어 라이프사이클을 커버했고 그 다음으로 DO-178A가 이어졌는데 위험 레벨이 더해졌고 품질을 얻기 위한 소프트웨어 컴포넌트 시험이 강조되었다. 현재의 버전은 완전히 재 작성된 DO-178B로써 계획을 더 추가하고, 문서만이 아닌 데이터 아이템을 생성하며 소프트웨어 개발 활동의 다양성을 허용하고 상용제품(COTS)과 상용툴을 허용하며 실제 조건하에서의 지속적인 품질 모니터링, 검증 및 시험을 허용함으로써 소프트웨어 품질의 개선을 가져왔다.

역주) 위에서 나오는 ‘현재의 버전’이라는 것은 원서 작성 시점 기준으로 DO-178B를 말하고 있다. 2018년 현재 기준으로 DO-178 인증의 기준은 DO-178C인데 이는 2012년에 릴리즈되었다. 이렇게 보면 이 책의 내용이 최신 버전과 상당히 다른 옛날 이야기를 하는 게 아닌가 싶지만 결론적으로 그런 걱정은 하지 않아도 된다. 여기서 나오는 내용은 거의 100% 현재 당신이 하고자 하는 DO-178 인증에 그대로 적용할 수 있다. 비록 아무런 권위가 없지만 그 점은 역자가 보증하겠다.

 

현실에서는 엄격한 요구사항인 것처럼 보이지만 DO-178B는 하나의 가이드라인이다. 단지 100페이지 정도의 길이로 모든 사람들에게 모든 것을 전달할 수 있어야 하는데 그것은 사실상 DO-178B를 대단히 광범위하게 받아들이도록 만든다. 그럼에도 불구하고 그 의도를 제대로 이해할 필요가 있다. DO-178B 가이드라인이 제대로 사용되기 위해서는 상당한 분량의 문서와 시스템 케이스에 대한 연구가 따라야 한다.

 

DO-254(유럽에서는 ED-80으로도 알려진)는 하드웨어를 다룬다. 항공전자 하드웨어의 설계 보증에 대한 공식적인 항공전자 표준이다. DO-254는 프로젝트 컨셉, 계획, 설계, 구현, 툴인증을 포함한 시험 그리고 확인을 통해서 정보를 제공한다.

 

DO-178B와 DO-254 두 문서는 상당히 비슷하다. 둘 다 공식적인 소프트웨어 프로세스 전문가들이 함께 모여서 작성되었다. 사실 최근까지만 해도 항공전자 하드웨어 인증은 소프트웨어만큼 엄격한 기준을 요구하지 않았었다. 그러나 항공전자 시스템은 하드웨어와 소프트웨어 둘 다로 구성되어 있고 각각은 항공기 안전성에 거의 동일한 영향을 미친다. 오늘날, 대부분의 항공전자 프로젝트는 전형적인 DO-178B에 대한 요구와 함께 DO-254 인증 혹은 그에 준하는 요구를 받고 있다.

 

DO-178B는 검증가능한 소프트웨어 품질, 높은 신뢰성, 지속성, 더 나은 재사용성, 더 낮은 라이프사이클 비용, 유지보수의 감소, 더 빠른 하드웨어 통합, 그리고 개발 프로세스 내에서 잘못된 부분을 잡아낼 가능성이 더 높아지는 것과 같이 인증에 더해서 그 이상의 많은 장점들을 제공한다.

 

우리는 인증 과정에서 나타나는 불필요한 위험 요인들을 감수하는 사람들을 몇 년 동안 보아왔다. 그들은 사실 ‘너무’ 많은 일을 하는 것일 수 있고, 어쩌면 평균적으로 40% 이상의 비용을 초과하게 만드는 핵심 산출물들 혹은 핵심 단계들을 등한시하고 있는지 모른다. 그리고 여전히 DO-178B의 진정한 의도를 만족하지 못한다. 이러한 각각의 함정들이 그것을 피하는 방법을 포함해서 이 책 전반에 걸쳐서 상세하게 논의된다. 그러나 우선, DO-178 인증 프로그램의 시작과 관련해서 사람들로부터 자주 듣게 되는 여러가지 질문들을 살펴보자.

 

“기존의 소프트웨어에 대한 리버스 엔지니어링(reverse engineering)으로 DO-178B를 적용할 수 있는가?”

그렇다. DO-178B는 신규로, 자체 개발되는 소프트웨어에 적용되지만 이전에 개발된 소프트웨어에 리버스 엔지니어링을 적용하고 이미 완료된 작업 대부분을 그대로 사용할 수 있도록 하는 조항이 있다.

역주) 최초 번역본에서 ‘리버스 엔지니어링’을 ‘역엔지니어링’으로 번역했었다. 어떤 식이든 의미가 통하긴 하지만 개발자들이 ‘리버스 엔지니어링’으로 영어발음 그대로 사용하는 경우가 많은 듯 해서 영어발음 그대로 옮겼다.

 

“DO-178B 툴인증이 무엇인가?”

소프트웨어 개발은 설계, 코드생성, 컴파일러/링커, 라이브러리, 시험 및 구조적 커버리지를 위한 많은 툴이 필요하다. DO-178B에서 툴인증은 개발툴과 시험툴 두 가지 종류로 구분된다 각각에 대해서 서로 다른 인증 기준이 적용되며 사실 대부분의 툴은 인증을 받을 필요가 없다. 툴인증이 필요한 경우에는 DO-178B의 서브셋을 사용하며 툴의 올바른 동작을 보증한다.

역주) DO-178C로 업데이트 되면서 툴인증에 대한 내용이 일부 변경되었다. 추후 자세히 설명하겠지만 어쨌든 기본적인 개념에서는 유사하므로 지금은 위의 내용으로 이해하고 넘어가도 무리는 없을 것이다. (참고 포스팅: 33. 툴인증(Tool Qualification) (Section 12.2))

 

“DO-178 갭분석(Gap Analysis)이란 무엇인가?”

이것은 당신의 현재 소프트웨어 엔지니어링 프로세스와 산출물들을 DO-178B에서 요구하는 것들과 비교해서 평가하는 것이다. DO-178B가 자체 개발한 항공전자 소프트웨어를 커버하는데 반해서 갭분석은 이미 개발된 소프트웨어가 DO-178B를 준수하는지 혹은 인증받을 수 있는지를 구분한다. 많은 경우에 있어서, 특히 군용 항공전자 소프트웨어의 경우 DO-178B 인증(Certification) 대신 DO-178B 준용(Compliance)이 사용된다. DO-178B 준용은 인증과 유사하지만 FAA가 관여하지 않는다.

역주) 인증(Certification)은 FAA의 공식적인 인증을 받는 것이고 준용(Compliance)은 FAA의 공식적인 인증을 받지는 않지만 DO-178 인증을 유사하게 따른다는 것을 말한다. 군용 항공전자 소프트웨어의 경우 FAA의 인증을 받지 않기 때문에 DO-178에 따라서 개발되었다고 하더라도 ‘인증(Certification)을 받았다’고 하지 않고 ‘준용(Compliance)한다’라고 표현한다. (참고 포스팅: 4. DO-178 인증과 준용)

 

갭분석은 일반적으로 훈련된 컨설턴트 혹은 DER(Designated Engineering Representatives)에 의해서 수행된다. 소프트웨어의 모든 프로세스들과 산출물들을 평가하게 되며 그 결과는 갭분석이다. 그것은 DO-178B 인증 혹은 준수를 위한 요구사항을 만족시키기 위한 갭을 채울 수 있는 상세한 내용을 제공한다.

역주) DER을 굳이 한글로 번역을 할 수도 있지만 실제 현장에서 DER(디이알)로 바로 부르고 있는 점을 고려해서 여기서도 달리 번역하지 않고 DER로 바로 표기한다. (참고 포스팅: 21. DO-178과 DER(Designated Engineering Representative) – Job Aid (7))

 

MCDC란 무엇인가?

Modified(혹은 Multiple) Condition Decision Coverage는 프로그램에서 모든 진입, 진출점이 적어도 한 번은 발생하고 하나의 결정문에서 모든 조건은 가능한 모든 결과를 적어도 한 번은 만들어 내며 각각의 조건은 그 결과에 독립적으로 영향을 미치는 것을 의미한다.

 

성공적인 MCDC 분석과 시험의 키는 잠재적인 MCDC 적용가능성에 대한 각각의 소스 코드를 분석하는 것이고 그런 다음 그 생성된 소스에서 각각의 조건을 보장하기 위한 충분한 시험 케이스들이 개발되어 MCDC 정의마다 독립적으로 검증되는 것이다. 오늘날 대부분의 MCDC 분석/시험은 DO-178B 인증을 받은 구조적 커버리지 툴의 도움을 받아서 수행된다.

역주) 위의 내용을 이해하려면 ‘코드 커버리지(Code Coverage)’에 대해서 알아야 한다. 참고로 DO-178에서 코드 커버리지는 상당히 중요한 개념이다. 여기서 다 풀어서 설명하기는 내용이 방대하므로 다른 곳에서 추가로 설명하기로 하고 궁금하신 분은 ‘코드 커버리지’로 구글링을 해서 Statement, Condition(Branch), 그리고 MCDC로 구분되는 내용을 살펴볼 것을 추천한다. (참고 포스팅: 4. DO-178과 커버리지 분석(Coverage Analysis))

 

Dead Code란 무엇인가?

이것은 해당 코드(소프트웨어)가 런타임 실행 중에 절대 수행되지 않는 것을 말한다. DO-178B는 일반적으로 Dead Code를 허용하지 않으며 반드시 제거되어야 한다. Dead Code는 어떤 소프트웨어 요구사항과도 연결되지 않으며 따라서 어떠한 요구 기능도 수행하지 않는다. 참조되지 않는 변수들 혹은 프로그램 어디에서도 호출되지 않는 함수들은 일반적으로 컴파일러 혹은 링커를 통해서 제거된다. 이 경우 실제 로드되는 바이너리 이미지에 존재하지 않기 때문에 DO-178B 관점에서는 Dead Code가 아니다.

역주) 최초 번역본에서 Dead Code를 ‘죽은 코드’로 번역했었다. 이 역시 어색한 것 같아서 그냥 영어를 그대로 사용한다.

 

비활성화 코드(Deactivated Code)란 무엇인가?

이것은 특별한 항공전자 장비내에서 특정한 소프트웨어 설정 혹은 버전의 런타임 실행 중에 수행되지 않을 코드(소프트웨어)이다. 그러나 그 코드는 유지보수 기간 동안이나 특별한 동작 중, 혹은 다른 설정이나 미래의 버전에서 수행될 수도 있다. Dead Code와 달리 비활성화 코드는 소스와 바이너리에 남아 있을 수 있다.

 

DO-178B 요구사항 추적성이란 무엇인가?

이것은 개별 요구사항을 각각의 요구사항에 대한 구현 및 검증과 연관된 설계, 코드 그리고 검증/시험과 연결하는 것이다. 요구사항 추적성은 다대일 및 일대다의 연결성을 가질 수 있다.

참고 포스팅: 3. DO-178과 추적성 매트릭스(Traceability Matrix)

  

항공전자 소프트웨어에 가장 적합한 언어는 무엇인가?

상위레벨의 언어들(복잡한 구문을 만들어 낼 수 있는 컴파일러가 필요한)이 더 안전하기 때문에 강력하게 선호되고 있다. 안전한 항공전자 소프트웨어란 무엇일까? DO-178B에서는 코드의 일관성, 가독성, 결정성, 방어코드, 강건성, 설계 추적성, 상세한 체크리스트에 기반한 소프트웨어 동료검토, 구조적 커버리지를 통한 전반적인 시험 그리고 실제 환경에서의 비동기 시험을 강조한다.

 

결과적으로 항공전자 소프트웨어는 Ada, C 그리고 C++로 작성되는 것이 최선이다. 그 모든 언어들과 함께 안전한 부분만 사용되어야 한다.  Ada는 사실상의 항공전자 언어의 표준이었고 Ada95는 객체지향 특성이 개선되었다. 그러나 그 흐름은 C와 C++로 넘어가게 되는데 언어 자체의 우수성이 뒤쳐져서가 아니라 실시간 임베디드 C와 C++을 개발할 수 있는 개발툴과 개발인력이 더 풍부했기 때문이다.

 

어떤 형상관리(CM)툴이 가장 좋은가?

DO-178B는 요구사항, 설계, 코드, 시험 그리고 문서를 포함해서 소프트웨어 라이프사이클 산출물들에 대한 형상관리를 요구한다. 그러나 DO-178B는 항공전자에 대한 형상관리도 그렇고 특별한 툴을 요구하지 않는다. 그래서 형상관리는 수동으로 진행될 수도 있으며 심지어 순수한 종이 기반의 시스템으로도 가능하다. 그러나 사실상 모든 항공전자와 DO-178B 소프트웨어 프로젝트는 형상관리툴을 사용해서 더 잘 관리된다. 간단한 툴(무료 혹은 낮은 비용: $0 ~ $200/년)은 기본적인 소프트웨어 버전 관리, 체크인/체크아웃 그리고 문서 관리를 제공한다. 더 비싼 툴은 더 복잡하고 자동화된 기능을 제공한다. 그러나 시중의 형상관리툴 중에서 DO-178B의 형상관리 단계별로 요구하는 모든 기능을 수행하는 툴은 현재까지 우리에게 알려진 바가 없다. 특별히 DO-178B의 형상관리 단계들에 해당하는 데이터 보안, 오프라인 백업, 각각의 변경에 대한 동료 검토 및 승인되지 않은 변경이 없도록 보장하는 것 등은 모두 일반적으로 항공전자 형상관리툴의 영역을 벗어나는 것들이지만 프로세스 개선을 통해서 달성될 수 있다.

 

DO-178B 체크리스트란 무엇인가?

체크리스트는 DO-178B 준용 여부를 추적할 수 있게 해준다. DO-178B 문서 뒷부분에 개략적인 체크리스트가 제공되긴 하지만 사실 그것은 적절한 체크리스트가 아니다. 왜냐하면 실질적인 체크리스트는 각 프로젝트에 대해서 케이스별로 개발되어야 하기 때문이다. 수 많은 써드파티 업체들이 계획, 개발, 정확성, 품질보증 그리고 DER 활동의 모든 단계를 커버하는 DO-178B 및 DO-254 체크리스트를 제공한다.

 

DO-178B 독립성이란 무엇인가?

이것은 서로 다른 DO-178B 라이프사이클 단계에 적용되는 개발과 리뷰에 대한 분리된 권한이다. 개발은 필요한 산출물(요구사항, 설계, 코드, 시험 등)을 생성한 사람과 관련된다. 리뷰 권한은 그 산출물이 정확한지, 그리고 DO-178B를 준수하는지를 리뷰하는 사람과 관련된다.

역주) 여기서 저자가 전달하고 싶은 부분은 바로 ‘제3자 리뷰’에 관한 것이다. 문서를 만든 사람과 리뷰하는 사람이 달라야 하고 소스를 작성한 사람과 그 소스를 리뷰하는 사람이 달라야 한다는 말이다. 쉬운 걸 너무 어렵게 설명한 게 아닌가 싶다.

 

위험레벨이란 무엇인가?

DO-178B에는 5개의 위험 레벨이 있는데 레벨 A가 가장 위험하고 레벨 E가 가장 덜 위험하다. 이것은 잠재적인 실패 조건을 소프트웨어에 할당하는 것에 기반한다. 각각의 항공전자 기능 혹은 시스템은 하나의 미리 정의된 위험 레벨(인증 담당자에 의해서 반드시 승인받아야 하는)을 가진다. 그러나 하나의 시스템 내에 서로 다른 컴포넌트들이 서로 다른 위험 레벨을 가질 수 있다. 위험 레벨이 더 높을수록 소프트웨어 개발에 더 많은 노력이 필요하게 된다.

 

DO-178B 레벨 A란 무엇인가?

이 레벨에서는 비정상적인 소프트웨어 동작이 모든 사람의 생명을 잃게 만드는 것과 같은 치명적인 실패를 만들어 낼 수도 있다. 항공전자 시스템의 약 20 ~ 30%, 그리고 소프트웨어 코드의 40% 정도가 DO-178B 레벨 A를 만족해야 한다.

 

레벨 B란 무엇인가?

이것은 비정상적인 소프트웨어 동작이 일부 사람들의 생명을 잃게 만드는 것과 같은 위험한/심각한 주요 실패를 만들어 낼 수도 있다. 항공전자 시스템의 약 20%, 그리고 소프트웨어 코드의 30% 정도가 DO-178B 레벨 B를 만족해야 한다.

 

레벨 C란 무엇인가?

이것은 비정상적인 소프트웨어 동작이 심각한 부상을 만드는 것과 같은 주요 실패를 만들어 낼 수도 있다. 항공전자 시스템의 약 25%, 그리고 소프트웨어 코드의 32% 정도가 DO-178B 레벨 C를 만족해야 한다.

 

레벨 D란 무엇인가?

이것은 비정상적인 소프트웨어 동작이 사소한 부상을 만드는 것과 같은 사소한 실패를 만들어 낼 수도 있다. 항공전자 시스템의 약 20%, 그리고 소프트웨어 코드의 10% 정도가 DO-178B 레벨 D를 만족해야 한다.

 

레벨 E란 무엇인가?

이것은 비정상적인 소프트웨어 동작이 항공기 운항이나 승무원의 업무에 아무런 영향을 미치지 않는 정도의 어떤 실패를 만들어 낼 수도 있다. 승객이나 항공기 안전에 아무런 영향이 없을 것이다. 항공전자 시스템의 약 10%, 그리고 소프트웨어 코드의 5% 정도가 DO-178B 레벨 E를 만족해야 한다.

 

승객 엔터테인먼트 및 인터넷 통신 시스템 사용으로 오늘날 레벨 E 소스코드의 양은 증가하고 있다. 다른 위험한 항공전자 시스템과의 통합으로 이들의 위험 레벨이 높아지는 경향이 있다.

 

DO-178B 툴인증이란 무엇인가?

이 프로세스는 공식적인 인증이 필요한지를 결정하기 위해 소프트웨어 개발 및 검증툴을 평가한다. 두 가지 타입이 있다. 바로 개발툴 인증과 검증툴 인증이다. DO-178B 개발툴은 내장형 구동 항공전자장비 소프트웨어에 실제로 존재하게 되는 결과물을 만들어 낸다. 그런 툴은 무결성을 보장하기 위해 반드시 DO-178B 소프트웨어 라이프사이클에 대한 부분을 제공해야 한다. 검증툴은 DO-178B 검증을 지원한다. 만약 툴이 이러한 범위를 만족하고 DO-178B에 의해서 언급되는 프로세스를 줄여주거나 자동화하거나 혹은 대신하는 경우에는 반드시 인증을 받아야 한다.

참고 포스팅: 33. 툴인증(Tool Qualification) (Section 12.2)

 

구조적 커버리지란 무엇인가?

이것은 공식적인 소프트웨어 검증 시험 케이스들이 소프트웨어 구조(조건 및 수행경로들)를 완전히 커버한다는 것을 증명하는 것과 관련되어 있다. 레벨 E와 레벨 D 소프트웨어에 대해서는 DO-178B의 구조적 커버리지가 필요하지 않다. 레벨 C, 레벨 B 그리고 레벨 A에 대해서는 더 엄격함이 요구된다.

역주) 앞서 MCDC를 설명하면서 언급했던 코드 커버리지에 대한 내용이다.

 

DO-178B 인증가능성(Certifiability)이란 무엇인가?

이것은 하나의 항공전자 컴포넌트가 DO-178B의 일부를 만족할 수 있고 나머지 인증에 대한 요구사항들은 다음 단계를 통해서 달성할 수 있다는 것을 말한다. DO-178B 인증은 개별 시스템에 속하는 것이고 따라서 하나의 시스템에 있는 모든 소프트웨어 컴포넌트들은 각각의 컴포넌트와 그 시스템이 DO-178B의 모든 요구사항을 완전하게 만족한 상태로 완성되어야 한다. 그러나 완전한 시스템의 부재로 개별 소프트웨어 컴포넌트(RTOS, 그래픽 라이브러리, 통신 프로토콜 등)는 그 컴포넌트를 모든 DO-178B 요구사항들에 종속시킴으로써 인증가능하다는 것으로 지정될 수 있다.

역주) 원문에 사용된 ‘certifiable’과 ‘certified’를 구분해서 정확하게 이해해야 하는 부분이다. 우리말로 번역하게 되면 두 단어의 미묘한 차이가 직관적으로 드러나지 않는다. ‘certified’는 완전하게 인증이 된 상태를 말하며 ‘certifiable’은 이에 비해서 아직 완전한 인증을 받지는 않았으나 인증받을 수 있는 자격(?)을 갖춘 상태를 말하는 것이라고 이해하면 좋을 것 같다. 특히 아직 시스템이 정해지지 않은 상태에서 소프트웨어가 개별적으로 DO-178 인증을 진행하고 성공적으로 완료된 경우 해당 소프트웨어는 아직 ‘certified’는 아니지만 ‘certifiable’하다고 말할 수 있다. 참고로 이 부분은 DO-178에 대한 전반적인 이해가 높아지고 실제 경험이 더해지면 좀 더 자연스럽게 이해가 될 것이다. (참고 포스팅: 4. DO-178 인증과 준용)