20. DO-254(하드웨어)

 

역주) DO-254에 들어가기 전에 먼저 언급할 부분이 있다. 솔직히 역자가 DO-254와 관련된 하드웨어 분야에 대해서는 잘 알지 못한다. 그럼에도 이렇게 번역을 하는 것은 DO-254가 DO-178과 유사한 부분이 많기 때문이다. 실제로 DO-254 가이드라인은 DO-178을 기반으로 만들어졌다. 또한 DO-254에서 말하는 하드웨어라는 것은 사실 소프트웨어의 성격을 많이 가지고 있는 FPGA와 같은 것을 말한다.(일반적으로 생각하는 딱딱한 부품, 장비와 같은 그런 하드웨어가 아니다.) 무엇보다도 현재 저자가 설명하고 있는 부분은 하드웨어의 기술적인 부분보다는 인증을 받기 위한 프로세스를 중심으로 설명하는 수준이어서 비록 일부 부족한 부분이 있겠지만 DO-254에 대한 이해를 하는 데에는 도움을 드릴 수 있을 것이라는 판단이다.

 

만약 당신이 DO-178 소프트웨어 세계에서 일할 것이라면 하드웨어 사람들도 역시 표준을 따르도록 요청받는다는 것을 알아야 한다. 그것은 주로 VHDL 혹은 어떤 종류의 HDL 소프트웨어를 통해서(이전에는 “펌웨어”로 알려진) 실리콘 기반의 로직을 프로그램하는 사람들에게 강요하게 된다. 그것은 또한 스키매틱(schematic) 설계를 하는 사람들에게도 필요하다. ASIC, FPGA, PLD, CPLD로 들어가는 혹은 실리콘을 사용하는 어떤 것이든 표준을 만족해야 한다. 최근에 COTS 마이크로프로세스와 컨트롤러는 DO-254를 따르는 것에 좀 더 관용적인 방법이 허용되었다.

 

DO-254는 2000년도에 릴리즈되었고 2005년이 시작되면서 FAA에 의해서 일반적으로 요구되기 시작했다. 유럽은 이러한 가이드라인을 공인하기 위한 그들만의 위원회인 EUROCAE를 가지고 있는데 여기서는 ED-80이라고 부르며 그들의 DO-178B 버전으로는 동일한 내용으로 ED-12B를 가지고 있다.

 

DO-254 요약   RTCA DO-254/EUROCAE ED-80, “Design Assurance Guidance for Airborne Electronic Hardware”   2000년에 릴리즈됨   2005년부터 FAA에 의해서 공식적으로 요청됨   항공기 시스템과 장비안에 있는 복합 전자 하드웨어(Complex Electronic Hardware, CEH)의 설계 보증을 위한 가이드라인을 제공   잘 만들어진 소프트웨어 표준인 RTCA DO-178B/EUROCAE ED-12B에 대응

 

역주) 기본적으로 미국의 DO-178/DO-254와 유럽의 ED-12/ED-80은 내부에 포함된 내용이 동일하다고 생각하면 된다. 따라서 DO-178/DO-254만 잘 이해해도 유럽의 인증까지 커버할 수 있다고 보아도 무방하다. 물론 인증 조직, 규정, 방식은 다른 부분이 많은 것도 사실이지만 최소한 항공장비에 탑재되는 소프트웨어, 하드웨어의 인증 기준은 동일하다고 보면 된다.

 

비록 2000년도에 DO-254가 존재하고 있었지만 FAA는 하드웨어(특히 복합 하드웨어)를 사용하는 지원자들이 그것을 사용하도록 교육하기 위해 2005년도에 Advisory Circular를 발행했다. 2000년과 2005년 사이에 무슨 일이 발생했을까? 당시에 DO-254를 어떻게 적용해야 하는지에 대해서 뜨거운 토론이 있었다. 그 문서는 복합 전자 하드웨어, 항공기 시스템 그리고 장비의 설계 보증에 대한 가이드라인을 제공한다. 다시 말하지만 그것은 지상 시스템이 아닌 항공기에 관련된 것이다.

 

CEH – 복합 전자 하드웨어 – 는 재미있는 약어이다. 무엇이 복합이고 무엇이 단순인지에 대한 많은 논쟁이 있었다. 오늘날에는 실리콘 기반의 로직을 포함한 모든 것이 복합 전자 하드웨어로 간주되기 때문에 상관하지 않는다. 만약 당신이 그 하드웨어가 단순하다고 결정한다면, 예를 들어 실리콘 기반의 로직을 가지고 있지 않거나 혹은 당신이 그것을 철저하게 시험할 수 있다면, 더 이상 DO-254를 적용할 필요가 없다. 하지만 그 문서는 단순 하드웨어가 아니면 복합 하드웨어라고 말하기 때문에 도움이 되지 않는다.  – 확실히 정확한 요구사항은 아니다.

 

단순 하드웨어라는 것은 모든 가능한 입력 조건에 대해서 철저한 시험이 일어날 수 있다는 것을 증명할 수 있느냐에 의해서 결정된다. 그러면 간단하다. 예를 들어 레지스터를 시험한다고 하자. 철저한 시험이 어려울 수 있지만 전압과 현재 전류의 범위에 대한 동치 클래스는 당신이 철저한 시험을 수행했다고 말하는 것을 허용한다.

 

4비트의 컨트롤러와 그에 대한 두 개의 출력, 두 개의 입력을 가진 discrete IO를 고려해 보자. 이것은 철저하게 시험될 수 있고 단순 하드웨어라고 부를 수 있다. 8개의 입력과 8개의 출력을 가진 16핀의 칩으로 가보자. 당신은 가능성 있는 모든 입력을 철저하게 시험하고 잠재적인 출력을 보여줄 수 있으며 그것을 단순 하드웨어로 부를 수 있다. 그것은 discrete 로직이다. 다음으로 400개의 핀을 가진 수 천개의 게이트 혹은 수 백만개의 게이트를 가진 FPGA를 보자. 당신은 그것을 철저하게 시험할 수 없다. ASIC이 사용될 때에는 그 작업이 단순하지 않을 것이다. DO-254를 살펴보면 그것은 DO-178B처럼 정확한 영역안에 있다. 거기에는 시스템 요구사항, 자문자료, 개발 가이드, 검증 가이드 그리고 안전성 평가 가이드가 있다. 그 문서에는 볼륨 제약, 시스템 특성, 하드웨어 설계 라이프사이클, 계획 프로세스, 추가적인 고려사항, 설계 보증, 레벨 A, B, C, D 그리고 Appendix B가 보인다. 파생 요구사항에 관해서 이야기한다. DO-178B는 절대 파생요구사항에 대해서 실질적으로 이야기하지 않지만 DO-254에서는 그것을 기술하도록 결정되었다.

역주) 저항을 본 적이 있는가? 정말 단순한 부품이다. 이 저항이 가질 수 있는 입력과 출력은 몇개가 될까? 다들 아는 것처럼 입력 하나에 출력 하나이다. 그리고 이 입력과 출력을 기준으로 시험하는 것은 누구나 할 수 있는 단순한 작업이다. 그럼 이제는 컴퓨터에 들어가는 CPU를 생각해 보자. 그 안에는 FPGA가 포함되어 있다. 내부까지 들어가지 않더라도 당장 누가 봐도 CPU를 단순하다고 생각하지 않는다. 이 CPU(의 FPGA)가 가질 수 있는 입력과 출력이 몇 개나 될까? 전세계에서 가장 뛰어난 CPU 전문가라고 해도 그것을 직접 하나하나 나열할 수는 없을 것이다. DO-254는 CPU를 복합 전자 하드웨어라고 한다.   여기서 기억해야 할 점은 바로 복합 전자 하드웨어의 시험이 단순하지 않기 때문에 DO-254를 적용한다는 점이다. 만약 당신이 DO-254가 아닌 다른 방식으로 모든 입출력에 대해서 시험할 수 있다면 굳이 DO-254를 적용하지 않아도 된다. DO-254를 인증받지 않고도 항공기에 탑재할 수 있다는 말이다. 참고로 이런 개념 자체는 DO-178도 동일하다.   추가로 위의 설명 마지막에 DO-178B는 파생요구사항을 이야기하지 않는다고 했는데 이는 잘못된 설명으로 보인다. DO-178B에서는 아래와 같이 DO-254만큼은 아닐지 몰라도 파생요구사항(Derived Requirement)을 언급하고 있다.

 

DO-254 범위   복합 하드웨어에 적용 만약 “단순”하다면 DO-254를 더 이상 적용하지 않음   하지만 언제 하드웨어가 단순 vs. 복잡하다라고 하는가?

 

DO-254는 지원 프로세스, V&V, 검증, 형상관리, 품질보증(“프로세스 보증”으로 불리는) 그리고 인증교섭과 같은 DO-178B와 동일한 설계 프로세스를 가지고 있다. DO-178B를 작성한 사람들 중 다수가 그것을 작성했기 때문에 많은 부분에서 DO-178B와 유사하다. 사실 그 위원회가 시작된 이유는 소프트웨어 관련자들이 “기능을 펌웨어로 구현하는 것으로 바꾸자. 우리가 그것을 하드웨어 혹은 펌웨어라고 부르면 DO-178B를 따를 필요가 없을 거야.”라는 말을 했기 때문이었다. FAA는 그것에 제동을 걸었고 새로운 위원회가 시작된 것이다. VHDL, HDL 그리고 실리콘 기반의 로직을 넣게 되는 어떤 것이든 컨트롤하기 위해 프로세스를 DO-178B와 유사하게 구성했다.

 

위원회의 몇몇 멤버들은 “잠시만요. 이것은 하드웨어 지침입니다. LRU, 마이크로프로세스, 케이블 그리고 discrete 장비, 이들 회로의 조합, CCA 그리고 회로카드 조립품같은 모든 전기회로를 여기에 넣읍시다.”라고 말했다. 2000년과 2005년 사이에 위원회는 하드웨어, 펌웨어 혹은 소프트웨어에 그 문서를 적용할지에 대해서 논쟁했다.

 

2005년에 FAA는 “DO-254가 하드웨어의(복합) 소프트웨어에 집중해야한다”고 결정했다. 이것은 2002년도에 누군가가 대형 운송기상의 CPU에 DO-254를 적용했는데 CPU를 하드웨어에 대한 가이드라인에 충족하지 못하는 것 때문에 많은 우려를 낳게 되었기 때문이었다. 그것은 2년간의 아주 비싼 비용을 들인 전투였는데 결국은 CPU는 COTS 실리콘이고 오랜 기간동안 존재해왔고 알려진 대로 상당양이 실제 사용되어 왔기 때문에 면제되는 것으로 최종 결정되었다.(DO-254의 지원을 위해서 판매처로부터 제조 데이터를 확보하는 것이 일반적으로 불가능했다는 점은 말할 것도 없다!)

 

역주) CPU와 같은 복잡한 장비(device)에 대한 인증은 상당히 어려운 부분이다. CPU 하나라고 하더라도 그 자체의 복잡함과 장비의 중요성으로 인해 결코 간단하게 처리할 수 있는 부분이 아니다. 여기서 저자가 소개한 부분은 그야말로 수 많은 사례 중 아주 운이 좋게 정리된 단 하나의 사례일 뿐이다. 혹시 관련된 부분을 좀 더 알아보고 싶은 분들이라면 CPU는 아니지만 비슷한 종류의 GPU에 대해서 설명하고 있는 아래 문서를 참고하기 바란다.   -       CAST-29 Use of COTS Graphical Processors (CGP) in Airborne Display Systems

 

DO-254 개요 – 1

 

DO-254는 FFP(Functional Failure Path)와 당신이 실리콘과 구조적 컴포넌트를 통해서 발견할 수행경로를 추적하는 하드웨어 레벨에서의 안전성 평가 프로세스 그리고 파티션 크리티컬 컴포넌트들에 관해서 이야기한다. 이러한 컴포넌트들이 Functional Failure Path Analysis 혹은 오히려 FTA, 즉 Fault Tree Analysis에 의해서 파티션될 수 있을까?

 

당신은 시스템 FFP와 장비에 대한 FFP를 얻고 따라서 LRU는 FFP를 얻을 것이다. 최종적으로 카드 레벨로까지 위험성에 대해서 분해한다. 마침내 당신은 컴포넌트레벨에 이르고 그런 다음에는 그 내부로 들어간다. 그것이 많은 블록을 가진 하나의 ASIC이라고 하고 FFP가 구분하는 위험 요인은 하나의 블록이라고 말한다. 하나의 요인에 대해서 레벨 A이고 또 다른 것에 대해서는 레벨 B이다. 또 다른 것은 레벨 C인데 그것은 위험한 조건에 영향을 미치지 않는다. 따라서 기본적으로 이것이 하드웨어를 통해서 Fault Tree Analysis를 하는 것이다.

 

DO-254 개요 - 2   기능은 소프트웨어 혹은 하드웨어로 할당되고 DO-254 혹은 DO-178B 각각의 지침에 의해서 제공되는 프로세스의 적용에 의해서 관리될 것이다   더 이상의 “펌웨어”는 없음   DO-254는 군용 시스템과 장비 제조사들에 의해서 인식되고 있는 비 FAA 프로젝트에서 하나의 표준으로써 사용된다   규범적이거나 선호되는 라이프사이클 모델이 아니며 조직에 대한 구조를 암시하는 것도 아니다   하드웨어 계획 프로세스, 설계 프로세스 그리고 지원 프로세스가 필요하다.

 

당신은 하드웨어에서 FFP를 할 필요는 없다. DO-254는 FFP를 요구하지 않으며 그것은 하나의 방법론이다. 그것은 DO-254 가이드라인 문서의 부록 B안에 있다. 하드웨어의 한 부분이 레벨 A 혹은 레벨 B로 결정된다면 당신은 부록 B와 DO-254 내부의 다른 모든 것을 수행해야 할 것이다. 소프트웨어 레벨에서 안전성 평가와 거의 유사하게 어떤 것을 파티션하기 위해 FFP가 요구된다. 하드웨어에서 FFP가 유일하게 필요한 경우는 만약 당신의 FPGA와 여러 개의 컴포넌트들을 하나의 컴포넌트는 낮은 레벨로, 다른 것은 높은 레벨로 나누어야 할 때이다. 그럼 당신은 FFP를 수행한다. 일반적으로 대부분의 사람들은 그것을 하지 않지만 만약 그것이 이 PLD에 있다면 그것은 모두 하나의 레벨이다. 그것은 또한 모든 것이 레벨을 가진다는 것을 발견하기 위해서만 FFP를 수행하면서 많은 시간을 보낼 수 있기 때문에 가장 쉬운 것이다.

 

DO-254 가이드라인 문서의 지침은 Line Replaceable Units, Circuit Cards, Custom Micro-coated Components, 통합 하이브리드, 멀티칩 그리고 Commercial-off-the-shelf(COTS) 장비를 기술한다. DO-178B는 COTS에 대해서 그렇게 잘 언급하지 않는데, Section 12에서 제한적인 참조를 제공할 뿐이다. DO-254 가이드라인 문서는 COTS 제품을 어떻게 인증하고 어떻게 당위성을 세우는지를 말한다. 2005년도에 FAA 지침과 함께 Advisory Circular 20-152가 발간되었는데 하드웨어에서 다른 것은 모두 잊으라고 말하고 있다. ASICs, PLDs, FPGAs 혹은 실리콘 상의 어떤 것과 같은 단지 복합 전자 하드웨어만 해당한다는 것이다. DO-254에 대해서 다른 것에 대해서는 수행하지 말아라. 단지 ASIC과 PLD에 집중하라. 그것은 소프트웨어-펌웨어 프로세스 컨트롤이다.

 

DO-254 개요 – 3   지침은 다음에 대한 설계 보증을 제공한다:   Line Replaceable Units(LRUs) Circuit Card/Board Assemblies(CCAs) Custom Micro-coded Components (예를 들면 ASIC, PLD, FPGA, CPLD) 통합 하이브리드 및 멀티칩 컴포넌트들 Commercial-Off-The-Shelf(COTS) 장비들 AC 20-152는 ASIC과 PLD와 같은 Custom Micro-coded Components 같은 것들만 관여한다

 

DO-254는 요구사항의 할당에 대해서 DO-178B보다 더 분명하게 시스템을 정의한다. 그것은 특별히 요구사항을 소프트웨어 혹은 하드웨어 어디로든 할당하며, 소프트웨어 관련자들이 그들이 만든 것을 하드웨어로 두고 그것을 펌웨어라고 말하면서 설계 보증 프로세스를 피하는 것을 제거하는 컨셉을 이야기한다.

 

DO-254는 비 FAA 프로젝트에서는 하나의 표준이기도 하다. 그것은 많은 ASIC과 PLD를 사용하는 군에 의해서 신중하게 인식되고 있다. 그들은 설계 보증 프로세스를 가지고 있지 않았었다.

 

당신이 CPU상에서 동작하는 FPGA를 가진다고 가정해 보자. 당신이 그것을 설계했는가? 아니면 IP 코어로써 구매했는가? 만약 당신이 설계 데이터를 가지고 있다면 당신은 DO-254를 적용한다. 만약 그것이 IP 코어라면 당신은 여전히 DO-254를 적용한다. 문제는 아마도 당신이 데이터를 가지고 있지 않을 것이라는 점이다. 만약 당신이 Xilinx FPGA를 가지고 있고 CPU를 샀다면 당신은 CPU 소프트코어를 얻을 수 있고 제출할 수 있다. 당신은 DO-178B에서 그런 것처럼 설계 정보, 추적성 그리고 모든 항목들에 대한 시험과 같은 많은 것을 하면서 DO-254를 적용한다. 당신은 단지 FPGA가 DSP와 함께 동작하고 있기 때문에 그 FPGA는 반드시 정상동작한다고 말할 수는 없다.

역주) 일단 기본적으로 DO-254는 FPGA에 대해서 적용된다. CPU에도 당연히 FPGA가 포함되어 있고 항공기에 탑재하기 위해서는 그 부분에 대해서 DO-254 인증을 받아야 하는 것이다. 하지만 CPU를 구매해서 사용하는 입장에서는 그 부분에 대한 DO-254 인증을 자체적으로 진행하는 것은 불가능하다. 직접 개발한 것이 아니기 때문이다. 그렇다면 결국 그것을 만든 제조사로부터 해당 자료를 구매를 하는 수밖에 없다. 개념적으로는 DO-178에서의 COTS 사용과 같은 것으로 보면 된다. 다만 현실적으로 그것이 어느 수준까지 가능한지에 대해서는 아직 역자가 파악하고 있지는 못한 상태이다.

 

당신이 해온 것은 Element Analysis이고, 따라서 당신은 실제로 당신의 시험에 대한 분석을 한다. FPGA상의 모든 컴포넌트들을 통해서 시험을 추적하라. 그리고 만약 당신이 FPGA상의 컴포넌트들뿐만 아니라 모든 입력과 출력이 동작했다는 것을 보여줄 수 있다면 당신은 요구되는 Element Analysis를 모두 다 수행한 것이 된다. 당신은 여전히 모든 데이터를 가지고 있어야 한다. Element Analysis를 강화하기 위해서 소프트웨어 시험이 사용될 수 있다.

 

세 가지 프로세스   계획 프로세스 우선, 계획이 완료되기 전까지는 개발 없음   개발 프로세스는 계획 프로세스가 완료된 이후에 수행됨   정확성 프로세스(지원 프로세스)는 프로젝트 시작부터 완료까지 지속적으로 수행됨   DO-178B와 같다는 것은 놀라운 일이 아니다!

 

DO-178B처럼, DO-254는 규격화되어 있지 않다. 선호되는 라이프사이클이 없다. 그것은 하나의 모델이다. 암시되는 구조나 조직이 없다. DO-254 가이드라인 문서는 DO-178B에서처럼 개발된다. 세 가지 핵심 프로세스가 있다. 정확성 프로세스, 계획 프로세스 그리고 하드웨어 개발 프로세스이다. 계획 프로세스가 먼저 와야한다. 개발은 계획을 따르며 정확성 프로세스는 지속적으로 수행된다.

 

DO-178B에서 제시된 폭포수 라이프사이클과 유사한 기본적인 라이프사이클이 있다. 하드웨어 사람들은 비록 용어로는 다소 다르긴 하지만 동일한 폭포수 혹은 순차적 유형의 라이프사이클을 가지고 있다. 모든 지원 프로세스와 계획 프로세스를 수행하며 실제 라이프사이클에서는 요구사항 선정을 수행한다. 그것은 DO-178B에서의 요구사항 정의와 동일하다. 요구사항, 설계 그리고 추적성은 그러한 요구사항을 구분하는가? 당신은 개념 설계를 수행한다. 그것은 설계가 아키텍처상에서 어떻게 보여지는지를 보여주기 위한 상위레벨, 블록레벨 다이어그램이다. 당신은 그것을 상위레벨 설계 혹은 상위레벨 요구사항으로 부를 수 있다.

 

상세 설계는 각각의 회로 혹은 컴포넌트 블록이 어떻게 동작하고, 블록들이 어떻게 상호 동작하는지, 하나의 블록에서 다른 블록으로의 추적성은 어떻게 되는지, 어떤 데이터가 통과하게 되는지 그리고 입력과 출력이 무엇인지를 결정하는 것이다.

 

다음으로는 구현이 있다. 그것은 먼저 코드가 구현되고 그 다음에 실리콘내부에 내장되는 소프트웨어 세계에서와 동일하다. 하드웨어에 대해서 코딩이 있고 실제 배치 과정이 이어지는 통합이 있다. DO-254에는 DO-178에는 없는 생산라인을 통해서 하드웨어를 얻게 되는 생산 전이 프로세스가 있다. 따라서 설계된 것이 실제로 생산라인으로 나오는지에 대해서 당신이 얼마나 확신하는지를 묻는 프로세스가 있다. 그 프로세스는 어떻게 확인되는가?

 

ASIC/PLD 라이프사이클

 

DO-254 데이터 항목은 소프트웨어 데이터 항목과 상당히 유사하다. PHAC은 PSAC과 동일하며 생산 보증은 품질 보증과 유사하다. 설계 계획, 확인 및 검증 계획 또한 유사하다. 확인 계획은 독특하다. 하드웨어 설계에는 더 많은 파생 요구사항이 있다. 칩셋의 선택에서 예를 들면 타이밍, 인터페이스 그리고 메모리 제약과 같은 많은 하드웨어 요구사항이 강요된다. 특별히 파생 요구사항에 대해서 선정된 하드웨어를 기반으로 확인 계획을 가지도록 요구된다. 파생 요구사항을 개발하고 각각이 시스템에 적절한지를 확인하라. RS232 시스템을 이야기할 때 RS232 통신 포트를 가지고 있지 않은 칩셋을 선택하는 것은 거의 쓸모가 없다. 그런 요구사항을 확인하라.

 

DO-254 데이터 아이템   *Plan for Hardware Aspects of Certification(PHAC)   Hardware Design Plan   Hardware Validation Plan   *Hardware Verification Plan(HVP)   Hardware Configuration Management Plan   Hardware Process Assurance Plan   Hardware Design Standards   Requirements Standards   Validation and Verification Standards   Hardware Archive Standards   Hardware Requirements   Conceptual Design Data   Detailed Design Data   *Top-Level Drawing   Assembly Drawings Installation Control Drawings   Hardware/Software Interface Data   Hardware Traceability Data   Hardware Review and Analysis Procedures   Hardware Review and Analysis Results   Hardware Test Procedures   Hardware Test Results   Hardware Acceptance Test Criteria   Problem Reports   Hardware Configuration Management Records   Hardware Process Assurance Records   *Hardware Accomplishment Summary(HAS)   (Total: 27)   * FAA에 제출되어야 함

 

DO-178B에서의 특정 문서들의 숫자와 DO-254에서의 특정 문서들의 숫자를 비교해보자. 우리의 계산으로는 DO-178B에는 22개의 독자 문서들이 있다. 위의 표에서 27개의 DO-254 데이터 아이템 중 4개(밑줄 그어진)가 FAA에 제출되어야 하는 것에 유의하라. PHAC(PSAC과 같은), HAS, Hardware Accomplishments Summary(Software Accomplishments Summary와 같은), 상위레벨 도면(Top-level Drawing), 그리고 하드웨어 검증 계획(Hardware Verification Plan)이 그것이다.

 

하드웨어 검증 계획은 특이하다. FAA는 그것을 보기를 원한다. 그 이유는 DO-178B와 다르게 시스템이 어떻게 시험되는지에 대한 측정기준을 결정할 간단한 방법이 없기 때문이다. FAA는 당신이 하고자 하는 분석의 종류, 어떻게 분석에 적용되는지, 어떻게 달성되는지, 그리고 만약 하드웨어가 요구사항에 대한 기능을 한다면 어떤 시험으로 하게 되는지 보기를 원한다. 그들은 또한 이 문서 목록에서 무엇이 누락되는지를 알고 싶어한다. 그것은 소프트웨어로부터 요구되는 것 중에 하나로 하드웨어 목록에서는 아니다.

 

모든 것이 하드웨어에서 다루어 진다면 이해가 된다. 예전 방법에서는 하드웨어를 커버하는 상위레벨 도면을 가졌을 것이다. 최종적으로 당신이 PLD의 이쪽 저쪽을 말하는 서브어셈블리 리스트에 도달하고 그것은 PLD상에 프로그램될 것이다. 그렇지만 우리가 여기에 넣는 것은 무엇인가? 우리는 기본적으로 PLD상에 소프트웨어를 넣는다. 우리는 소프트웨어의 그러한 부분들과 그들의 버전을 알기를 원한다. 그 모든 형상정보는 무엇인가?

 

비록 DO-254는 요구하지 않지만 이것은 ASIC과 PLD를 위해서 만족해야 하며 따라서 당신은 결국 소프트웨어 형상 인덱스를 작성하게 될 것이다. ASIC에 대한 형상인덱스를 최상위레벨 도면으로 대체하되 여전히 최상위레벨 도면을 제공하라. 당신은 거기에 들어있는 ASIC, CCA 혹은 카드를 발견할 수 있어야 한다. DO-254는 ASIC 혹은 PLD를 어떻게 다루어야 하는지 정확하게 말하지 않기 때문에 이것이 어려울 수 있다. 당신은 계획, 안전성 평가, 요구사항 획득 그리고 개념 설계를 해야 하며 그런 다음 구현을 위한 상세 설계를 한다. 이들이 진행되는 동안 당신은 확인 검증, 형상관리 그리고 마지막에는 생산전이를 수행한다.

 

VHDL과 HDL 혹은 어떤 종류의 실리콘 프로그래밍을 다루는 대부분의 엔지니어들은 기본적으로 DO-178B 방법론을 따르는데 그것은 거기에 없는 것을 제외하면 DO-254와 동일하다. 당신은 실리콘상에서는 커버리지 분석을 수행할 수 없다. 실리콘에 시험용 코드를 입력할 수 있는 방법은 없다. 당신은 당신이 정의한 작은 컴포넌트 안으로 들어갈 수 없고 모든 수행경로를 커버했는지를 볼 수 없다. 지원하는 툴도 없다. 하지만 개선된 분석 기법을 커버하는 Appendix B가 있다. 만약 당신이 레벨 A 혹은 B라면 Element Analysis라고 불리는, 구조적 커버리지 분석과 동등한 어떤 것이 있다. 그것은 하나의 컴포넌트에 대한 모든 입력과 출력을 분석하고 FPGA 혹은 PLD 내부 회로를 통해서 추적하는 프로세스이다. Discrete 로직을 사용하면 모든 추적에 대해서 진리표를 사용할 수 있기 때문에 간단하다. 만약 거기에 아날로그 및 버스 데이터도 있다면 그것은 좀 더 어려워지는데, 당신은 Element Analysis를 해야 한다. 좋은 소식은 그러한 컴포넌트들에 대해서 얼마나 하위단계를 선정할지는 당신에게 달려있다는 점이다.

 

당신은 더 이상 LRU 혹은 회로어셈블리를 고려할 필요가 없다. 만약 위험성이 레벨 D보다 적으면 DO-254를 적용하지 않으며 따라서 예전 방법론을 사용한다. Advisory Circular에 따르면 상용 마이크로프로세서는 DO-254 관점을 고려하지 않는다고 말한다. 그들에게는 오로지 역사적인 관점이 중요하다. “이력”을 가지고 있는가? 항공시스템에서 엄격한 이력을 가지고 있지 않은 CPU는 사용하려고 하지 말아라.

DO-254 개요

 

위의 그림에서 원형으로 이어진 섹션이 있다는 점에 유의하자. 당신은 계획, 구조적 요구사항, 예비 설계, 상세 설계, 구현, 확인, 검증 그리고 형상 관리를 수행한다.

 

DO-254는 레벨 A에서 D까지 동일한 네 가지 위험 레벨을 설명한다. Advisory Circular에 따르면 레벨 D에 대해서는 이전에 수행된 표준 방법을 사용한다. 거기에는 최상위 레벨 다이어그램과 시험 기준이 있다. 부분들이 정확한지 확인하기 위해 추적이 이루어진다. 따라서 레벨 D는 DO-254의 범위를 벗어나며 레벨 A와 B는 동일하다. 비록 A와 B의 위험레벨이 있지만 설계 보증 노력은 동일하며 같은 방식으로 수행된다. 그것이 당신이 레벨 D를 선택하더라도 네 가지 모두에 대해서 계획과 설계가 같은 이유이다.

 

구현은 다소 다르다. A와 B에 대해서는 더 높은 작업량이 있는 반면에 C와 D에서는 다소 차이가 있다. 작업량이 더 많은 것은 Element Analysis이고, 그보다 더 많은 것은 리뷰이며, 그보다 훨씬 더 많은 것은 A와 B에 대한 분석이다. 따라서 DO-254에서 하나의 목표는 만약 당신이 가능하다면 레벨 C를 얻는 것이다.

 

하드웨어 계획에 대해서 프로세스 objective는 소프트웨어 계획 objective와 상당히 동일하다. 모든 하드웨어 라이프사이클 프로세스가 정의되고 표준이 선택되며 정의된다. 거기에는 여분의 표준 문서를 추가하는 네 개의 표준이 있다. AC 20-152에는 설계 표준, 요구사항 표준, V&V 표준 그리고 아카이브 표준이 있다. DO-254에서 개발된 4번째 표준이 아카이브 표준이다.