4. 항공기 및 시스템 개발 프로세스

이 섹션에서는 개념 정의에서 인증에 이르기까지 항공기 및 항공기 시스템 개발을 위한 일반적인 접근법에 대한 개요를 제공한다. 이 섹션에서는 입증 자료의 의도와 적용가능성을 이해하기 위해 개발 프로세스 및 상호 관계와 관련된 공통 용어 및 기대치를 설정한다.

 

개발 라이프 사이클은 시작과 끝이 있으며 항공기 혹은 시스템 변경을 해결하기 위해 다시 시작될 수 있다. 그림 3은 개발 라이프 사이클의 간단한 그림이다. 이 문서에 포함된 지침은 주로 “개발” 단계에 맞춰져 있다.

그림3 개발 라이프 사이클

 

개념 단계(즉, 연구 및 예비 개발 단계)는 페이로드 및 항속 거리, 항공기 크기, 엔진 수 및 위치, 에어포일, 설계 및 제조에서의 신기술 적용과 같은 전체 항공기 성능 및 구성을 결정한다. 생산/운용을 위한 구현을 준비하는 개발 단계가 개념 단계 다음에 이어진다. 개발 단계는 다음과 같은 시점에 완료된다.

 

• 구축/테스트 정보가 생산 시설(들)로 제공됨,
• 모든 규정 준수 데이터가 제출되고 승인됨,
• 설계가 모든 내부 준수 데이터를 충족함 (필요한 경우),
• 제약사항, 유지보수 및 기타 운용 정보가 항공기 운영자에게 제공됨.

 

4.1. 항공기/시스템 개념 개발 프로세스

 

이 섹션에서 설명하는 일반적인 항공기/시스템 개발 프로세스는 프로세스를 논의하기 위한 프레임워크를 확립한다. 이 섹션은 선호하는 방법이나 프로세스를 의미하지 않으며 특정 조직 구조를 의미하지도 않는다. 그림 4는 각 활동 상자안에 해당 활동이 추가로 설명되는 이 문서의 섹션 번호를 나타내는 숫자 항목을 포함한 시스템 개발 프로세스 모델의 그래픽 표현을 제공한다.

그림 4 항공기 혹은 시스템 개발 프로세스 모델

 

의도된 항공기 기능에 대한 지식으로부터의 특정 시스템 구현을 개발하기 위한 하향식 시퀀스는 시스템 개발 프로세스에 대한 편리한 개념 모델을 제공한다. 전형적인 시스템 개발은 하향식 및 상향식 전략을 모두 사용하여 반복적으로 동시에 진행된다. 이 문서에서는 항공기 안전과 시스템 개발 사이에 필요한 연결을 제공하기 때문에 하향식 측면에 중점을 두고 있다. 회사 조직은 기능/제품으로 분류되는 추가적인 하위 계층을 구성할 수 있는 것으로 인식된다. 그런 다음 이 문서에서 설명된 프로세스가 항공기에서 아이템 레벨에 이르기까지 이러한 계층에 적절한 적응을 통해 적용된다.

 

4.1.1. 개발 보증

 

현대 항공기 시스템의 고도로 복잡하고 통합된 특성으로 인해 규정 당국은 개발 오류가 항공기 고장 조건을 유발하거나 이에 기여할 가능성에 대한 우려를 강조해왔다. 이러한 우려를 해결하려면, 개발 에러를 완화하는 방법론이 필요하다. 다음 문장은 현재 인증 요구사항/규정에 표현된 그러한 우려를 보여주고 있다.

 

a. 특히 전자 기술 및 소프트웨어 기반 기술의 사용을 통해 복잡하고 상호 관련된 기능을 수행하는 고도로 통합된 시스템의 안전성 측면을 평가하는 데 사용되는 기술의 효율성과 커버리지에 대한 우려가 제기되었다. 그러한 우려는 전통적으로 결정론적 위험이나 복잡하지 않은 시스템에 적용되는 설계 및 분석 기법이 더 복잡한 시스템에 대해 적절한 안전성 커버리지를 제공하지 않을 수 있다는 것이다. 그래서, 프로세스 보증, 확인 및 검증 커버리지 기준 혹은 필요한 경우 항공기 레벨에서 적용되거나 적어도 통합 혹은 상호 작용 시스템에 걸쳐 적용된 구조화된 분석 혹은 평가 기법의 조합을 활용한 개발 보증과 같은 다른 보증 기법이 이러한 보다 복잡한 시스템에 적용되어 왔다. 그것들의 체계적인 사용은 요구사항이나 설계 그리고 통합 혹은 상호 작용 영향에서의 오류가 적절하게 식별되고 수정되어 왔다는 확신을 높이게 된다.

 

b. 위에서 언급한 개발과 함께 14CFR/CS 25.1309에 대한 개정을 고려하여, AMC25.1309가 안전성 요구사항을 결정하고 이러한 요구사항 준수를 확립하는 데 도움이 될 수 있는 새로운 접근법을 질적으로 그리고 양적으로 모두 포함하도록 수정되었으며 전체 항공기 및 시스템을 고려하여 규칙의 개정을 반영하도록 수정되었다. 또한 개발 및 안전성 평가 프로세스의 프레임에서 특정 분석 혹은 개발 보증 조치의 수행 시기 혹은 수행될 지 여부를 결정하는 지침을 제공한다. 시스템 고장의 영향이 정량적 분석 방법으로 조사되는 경우 사용되는 요구사항에 포함된 확률적 용어에 수치 값이 할당된다. 수치를 결정하는 데 사용되는 분석 도구는 엔지니어링 및 운영 판단에 기반한 정성적 방법에 추가로(대체가 아닌) 사용하기 위한 것이다. 따라서 식별된 고장 조건을 유발하거나 이에 기여할 수 있는 개발 오류가 적절한 수준의 엄격성으로 최소화되었다는 확신 수준을 설정하는 프로세스가 필요하다. 이제부터 이것을 개발 보증(Development Assurance) 프로세스라고 칭한다.

 

4.1.2. 개발 보증 프로세스에 대한 소개

 

소프트웨어 및 전자 하드웨어의 특정 아이템이 각각 의도된 설계 요구사항에 대해 수행하는 신뢰 수준을 확립하는데 있어서 DO-178B/ED-12B에 제시된 지침 자료는 산업계와 여러 규정 당국에 의해서 인정받아 왔다. 항공기 시스템 전체에 대한 신뢰 수준을 확립하기 위해 여기에 설명된 프로세스는 항공기 레벨, 시스템 레벨 그리고 아이템 레벨 요구사항을 개발하기 위한 지침을 제시한다. 이 프로세스는 필요한 형상 관리 및 프로세스 보증 활동과 함께 요구사항 확인과 요구사항이 충족하는지에 대한 검증을 포함한다. 개발 보증 레벨 할당은 고장 조건의 분류에 의존하기 때문에 개발에 필요한 엄격성 수준을 도출하기 위해 사용되는 고장 조건과 심각도 분류를 식별하기 위해 안전성 분석 프로세스가 여기에 정의된 개발 보증 프로세스와 함께 사용된다.

 

복잡한 시스템과 통합된 항공기 레벨 기능은 개발 오류(요구사항 결정 및 설계 오류)와 바람직하지 않은, 의도하지 않은 영향의 더 큰 위험을 나타낸다. 한편 남아 있는 개발 오류가 없음을 결정적으로 입증하는 고도로 통합되고 복잡한 시스템을 위한 한정된 테스트 스위트를 개발하는 것은 일반적으로 실용적이지 않다.(심지어 불가능할 수도 있다) 이러한 오류는 일반적으로 결정론적이지 않고 특징을 나타내는 수치적 방법을 적용할 수 없기 때문에 시스템이 안전성 목표를 충족할 수 있음을 확실히 하기 위해 다른 정성적인 수단을 사용해야 한다. 무엇보다도 FDAL(기능 개발 보증 레벨)과 수치적 확률 사이에는 직접적인 상관 관계가 없다. 고장 조건 분류와 관련된 안전성 목표는 지정된 기능 개발 보증 엄격성과 수치 분석 방법(필요한 경우) 모두에 의해 충족될 수 있다. 일반적으로 이 두 가지 개별적인 방법은 서로 관련이 없으며 상호 보완하지도 않는다.

 

이러한 맥락에서, 본 ARP4754A/ED-79A는 DO-178B/ED-12B와 DO-254/ED-80의 활동을 소프트웨어와 전자 하드웨어 아이템에 대한 개발 보증 엄격성을 구현하는 수단으로 간주한다. 이러한 소프트웨어 및 전자 하드웨어 관련 프로세스는 그림 5와 같은 항공기 레벨에서 아이템 레벨까지의 개발 보증 프로세스 없이는 항공기/시스템 오류를 완화하는 데 적절한 것으로 더 이상 간주되지 않는다.

그림5 안전성과 개발 프로세스 간의 상호 작용

섹션 5.2는 항공기 레벨에서 시작하여 아이템 레벨 요구사항에 이르기까지 FDAL 및 IDAL 할당에 대한 지침을 제공한다. 각각의 FDAL 달성을 위한 목표가 부록 A에 요약되어 있다. 각각의 IDAL 달성을 위한 목표는 소프트웨어와 전자 하드웨어 아이템에 대해 각각 DO-178B/ED-12B와 DO-254/ED-80을 따른다.

 

요약하자면, 개발 보증은 시스템 개발이 항공기 안전에 영향을 미칠 수 있는 개발 오류의 가능성을 제한할 만큼 충분히 훈련된 방식으로 완료되었다는 확신을 확고히 하는 프로세스 기반 접근법이다.

 

4.1.3. 안전성 분석에서 도출된 계층적 안전성 요구사항에 대한 소개

 

안전성 요구사항은 항공기, 시스템, 그리고 아이템 레벨에 존재한다. 안전성 요구사항의 유형에는 독립성, 정량적(확률적), 정성적, 가용성, 무결성, 모니터링, FDAL, 운용 및 유지보수 요구사항이 포함된다.

 

안전성 요구사항은 계층적 구조에서 항공기 레벨부터 아이템 레벨까지 기능적으로 분해된다. 항공기 레벨에서 안전성 요구사항은 방향 제어, 지상 감속 등과 같이 항공기 기능에 기반한 항공기 FHA로부터 생성된 요구사항이다. 시스템 레벨에서 안전성 요구사항은 항공기 레벨 안전성 요구사항의 분해인 시스템 FHA로부터 생성된 모든 시스템 레벨 요구사항이다. 그 다음 하위 레벨에서의 요구사항은 시스템 FHA 분류와 관련된 안전성 목표를 충족할 수 있도록 하는 시스템의 모든 측면이다. 그림 5는 다양한 요구사항 레벨을 보여준다. 또한 안전성 요구사항은 CCA(Common Cause Analyses)로부터 생성될 수 있다.

 

4.1.4. 항공기 레벨 기능, 기능 요구사항 및 기능 인터페이스의 식별

 

이 활동은 기본 항공기 레벨 성능 및 운용 요구사항을 확립한다. 이러한 기본 요구사항으로부터 항공기 레벨 기능과 해당 요구사항을 수립할 수 있으며 외부의 물리적 및 운영 환경과의 기능 인터페이스가 식별될 수 있다. 항공기 레벨 기능은 높은 레벨의 활동이며 단일한 물리적 시스템 구현과 연관되는 것은 아닐 수 있다.

 

이 활동의 출력은 항공기 레벨의 기능 목록과 이러한 기능들에 대한 관련 기능 요구사항 및 인터페이스이다.

 

4.1.5. 항공기 기능의 시스템 할당

 

이 레벨의 활동은 항공기 기능의 적절한 그룹화와 이러한 기능에 대한 요구사항을 시스템으로 할당하는 것을 명확하게 한다. 이 활동의 출력은 관련된 인터페이스를 포함한 각각의 항공기 시스템에 대한 요구사항 집합이다.

 

4.1.6. 시스템 아키텍처 개발

 

시스템 아키텍처는 이 프로세스 활동의 일부로 달성된다. 이 시스템 아키텍처는 확립된 모든 안전성 및 기술 성능 요구사항을 충족하기 위해 특정 아이템 설계가 구현되는 구조와 경계를 설정한다. 이 활동의 출력에는 아이템 레벨에 대한 시스템 아키텍처와 적절한 아이템에 대한 시스템 기능 및 안전성 요구사항의 할당이 포함된다.

 

4.1.7. 시스템 요구사항을 아이템으로 할당

 

실제로 시스템 아키텍처 개발과 요구사항 할당은 밀접하게 결합된 반복적인 프로세스이다. 각각의 반복 주기마다 요구사항에 대한 식별 및 이해가 증가하고 시스템 레벨 요구사항을 하드웨어 혹은 소프트웨어 아이템에 할당하는 것이 더 명확해진다. 이러한 할당 노력의 출력은 안전성 목표, 개발 보증 레벨 그리고 기능/성능 요구사항을 포함하여 하드웨어 및 소프트웨어에 할당된 요구사항이다.

 

4.1.8. 시스템 구현

 

프로세스 모델의 시스템 구현 단계는 이 문서에 설명된 시스템 프로세스 모델과 DO-178B/ED-12B 소프트웨어 및 DO-254/ED-80 전자 하드웨어 개발 프로세스 라이프 사이클 지침 문서를 연결한다.

 

또한 이 단계는 항공기 시스템이 개별적으로 그리고 집합적으로 올바르게 작동하도록 하는 작업을 제공한다.

 

이 단계의 출력은 하드웨어-소프트웨어 통합 절차, 시스템 통합 절차, 릴리즈된 하드웨어 도면, 관련된 문서와 함께 소프트웨어 소스 코드, 적용가능한 개발 보증 데이터, 해당되는 경우 브레드보드 혹은 프로토타입 하드웨어, 그리고 실험실/비행 테스트 품목을 포함한다.

 

4.2. 항공기 기능 개발

 

그림 4가 일반적인 시스템 개발 프로세스를 보여주는 반면에, 그림 6은 항공기 기능 구현 프로세스를 보여준다. 이 모델은 여러 개의 시스템 개발 프로세스를 포함한다. 각각의 시스템 개발 프로세스는 여러 개의 아이템 개발 프로세스로 구성될 수 있다. 각각의 개발 활동 과정에서 반복적으로 발생하는 특정 필수 프로세스들이 있다.

그림6 항공기 기능 구현 프로세스

 

대부분의 실제 시스템 개발 프로세스에는 많은 반복 사이클이 포함되므로 순차적이기 보다는 주기적인 경험을 더 하게 된다. 항공기 기능 구현을 위한 진입점은 사이클의 어느 지점에서나 발생할 수 있다. 새로운 항공기 레벨 기능의 경우, 프로세스는 기능의 최상위 레벨 정의로 시작된다. 항공기에 기능을 추가하는 경우, 진입점은 특정 아이템에 대한 변경의 맥락에서 발생할 수 있다. 하지만 진입점과 관계없이 새로운 혹은 수정된 기능이 다른 항공기 레벨 기능과 지원 요구사항에 미치는 영향에 대한 평가가 필요하다. 실제로 그림 6에 표시된 많은 개발 활동은 동시적이며 이전에 설정된 요구사항을 변경하는 상호 작용 의존성을 포함할 수 있다.

 

기능 요구사항 할당 프로세스의 일부로 관련 고장 조건 분류 정보가 분명하게 명시되어야 한다. 이것은 추가적인 아키텍처 파티셔닝의 이점을 입증하기 위한 추적성을 제공한다. 할당 프로세스의 이 부분에서 파생 요구사항이 다시 발생하게 되는데 이는 확인되어야 하며 안전성에 미치는 영향이 결정되어야 한다.

 

전형적인 항공기 기능은 다음이 포함될 수 있다.

 

a. 비행 제어 (Flight Control)

b. 지상 조향 (Ground Steering)

c. ATC의 항공기 측면 (Aircraft Aspects of ATC)

d. 자동 비행 제어 (Automatic Flight Control)

e. 화물 취급 (Cargo Handling)

f. 엔진 제어 (Engine Control)

g. 충돌 회피 (Collision Avoidance)

h. 지상 감속 (Ground Deceleration)

i. 환경 통제 (Environmental Control)

j. 승객 편의 (Passenger Comfort)

k. 통신 (Communication)

l. 안내 (Guidance)

m. 항법 (Navigation)

n. 승객 안전 (Passenger Safety)

 

이 문서가 엔진 개발에 적용되는 경우, 전형적인 엔진 기능에는 다음이 포함될 수 있다.

 

a. 추력 조절 (Modulate Thrust)

b. 역추력 제어 (Thrust Reverser Control)

c. 승객 안전 (Passenger Safety)

d. 항공기 통신 (Aircraft Communication)

e. 엔진 헬스 모니터링 (Engine Health Monitoring)

 

이 문서가 프로펠러 개발에 적용되는 경우, 전형적인 프로펠러 기능에는 다음이 포함될 수 있다.

 

a. 속도 조절 (Modulate Speed)

b. 승객 안전 (Passenger Safety)

c. 블레이드 피치 변조 (Modulate Pitch of Blade)

 

4.3. 항공기 기능의 시스템 할당

 

다음 활동 레벨은 항공기 기능의 적절한 그룹화와 관련 요구사항(항공기 레벨 FHA로부터의 요구사항을 포함해서)을 시스템에 할당하는 것으로 구성된다. 가능한 그룹화 범위에서 적절한 기능 그룹을 선택하는 프로세스는 종종 복잡하다. 이 문서에서는 그룹화 활동을 수행하기 위한 특정 권장 사항을 제공하지 않는다. 하지만 관련된 가정을 포함하여 선택 결정의 기초에 대한 세심한 주의는 후속 프로세스의 성공에 필수적이다. 기능적인 그룹화는 항공기 아키텍처와 상호 작용하며 시스템 아키텍처 개발의 기초가 된다. 필요한 기능적인 그룹화를 달성하기 위해 시스템이 구현되는 방법을 자세히 알 필요는 없지만 구현 제약, 고장 영향 및 라이프 사이클 지원은 모두 가장 적절한 그룹화를 선택하는 데 중요한 역할을 할 수 있다. 할당은 또한 입력, 수행되는 프로세스 및 출력을 정의하고 운용 및 지원 측면을 고려해야 한다. 이 프로세스의 과정에서 만들어지는 가정은 전체 시스템 요구사항 패키지의 중요한 부분이 되며 다른 요구사항과 동일한 확인 활동의 대상이 된다.

 

기능 할당 및 관련된 고장 결과로부터 안전성 목표를 달성하는 데 필요한 추가적인 특정 시스템 요구사항이 결정된다. 다양한 기능 조합, 시스템 및 사람에 대한 할당의 결과가 고려됨에 따라 파생 요구사항 및 추가적인 가정이 이 단계에서 나타날 것이다. 이는 항공기 레벨 기능 요구사항의 변경으로 이어질 수 있다.

 

이 활동의 출력은 관련된 인터페이스와 함께 각각의 항공기 시스템에 대한 요구사항 집합이다. 인터페이스는 소스를 가진 모든 입력과 사람 혹은 다른 시스템 중 하나의 대상이 있는 모든 출력으로 정의되어야 한다.

 

4.4. 시스템 아키텍처 개발

 

시스템 아키텍처는 설정된 요구사항을 충족하기 위해 특정 아이템 설계가 구현되는 구조와 경계를 설정한다. 구현을 위해 둘 이상의 시스템 아키텍처 후보가 고려될 수 있다. 이러한 후보 시스템 아키텍처는 기술 준비, 구현 일정, 생산가능성, 계약 의무, 경제성, 이전 경험 및 업계 우선 순위와 같은 요소를 사용하여 평가할 수 있다. 그런 다음 후보 아키텍처들은 시스템에 할당된 기능 및 최상위 레벨 안전성 요구사항을 충족하는 데 있어서의 타당성을 확립하기 위해 기능 및 성능 분석, PASA(Preliminary Aircraft Safety Assessments)/PSSA(Preliminary System Safety Assessments) 그리고 CCA(Common Cause Analysis)를 사용하여 반복적으로 평가받게 된다. PASA/PSSA 그리고 CCA 수행에 대한 지침은 각각 섹션 5.1.2와 5.1.4에 요약되어 있다.

 

기술, 아키텍처, 시스템 및 아이템 인터페이스, 혹은 구현 선택에서 기인하는 파생 요구사항은 아키텍처에 대한 작업이 진행됨에 따라 더욱 명확하게 드러난다. 파생 요구사항이 더 높은 레벨의 요구사항에 미치는 잠재적 영향이 평가되어야 한다.

 

이 활동의 출력은 아이템 레벨에 대한 시스템 아키텍처의 정의와 최상위 레벨 시스템 기능 및 관련된 하위 레벨 안전성 요구사항의 할당이다. 아이템 인터페이스, 시스템 제약 조건(물리적, 환경적, 등) 그리고 통합을 관장하는 요구사항이 포함되어야 한다.

 

4.5. 시스템 요구사항의 아이템 할당

 

실제로 시스템 아키텍처 개발과 아이템 요구사항에 대한 시스템 요구사항의 할당은 밀접하게 결합된 반복적인 프로세스이다. 각각의 사이클이 진행되면서 파생 요구사항의 식별과 이해가 증가하고 아이템 레벨에서 하드웨어 혹은 소프트웨어로 시스템 레벨 요구사항을 할당하는 근거가 더 명확해진다. 최종 아키텍처 내에서 모든 요구사항이 수용될 수 있을 때 해당 프로세스가 완료된다. 아이템에 대한 요구사항의 분해 및 할당은 또한 아이템이 할당된 요구사항을 완전히 구현하는 것을 보일 수 있음을 보장해야 한다.

 

할당에서 발생하는 파생 요구사항은 시스템과 관련되거나 소프트웨어-하드웨어와 관련될 수 있다. 유사하게, 할당된 요구사항에 대한 구현 검증은 시스템 레벨 혹은 아이템 레벨에서 수행될 수 있다.

 

이 할당 노력의 출력은 각각의 아이템에 대해서 적절한 안전성 목표 및 개발 보증 레벨을 가지는 하드웨어에 할당되는 요구사항과 개발 보증 레벨을 포함하는 소프트웨어에 할당되는 요구사항이다. 필요한 경우 하드웨어-소프트웨어 통합을 관장하는 요구사항이 포함되어야 한다. 이 활동의 결과는 PSSA(Preliminary System Safety Assessment)를 업데이트하는 데에도 사용된다.

 

4.6. 시스템 구현

 

시스템 구현에는 다음과 같은 네 개의 주요 포인트가 있다.

 

a. 시스템 프로세스에서 하드웨어 & 소프트웨어 프로세스로의 정보 흐름과 그 반대로의 정보 흐름,

b. 하드웨어/소프트웨어 설계 & 구축,

c. 하드웨어/소프트웨어 통합 그리고

d. 시스템 통합.

 

이들에 대해서는 이어지는 하부 단락에서 좀 더 논의된다.

 

4.6.1. 정보 흐름 – 시스템 프로세스 & 아이템 프로세스(들)

 

4.6.1.1 시스템 프로세스로부터 하드웨어/소프트웨어 프로세스로의 정보 흐름

 

시스템 요구사항은 시스템 아키텍처에 따라 결정된 대로 분해되고 하드웨어 그리고/혹은 소프트웨어에 할당된다. 하드웨어 그리고/혹은 소프트웨어로의 요구사항 분해 및 할당은 시스템 프로세스를 따른다. 시스템 프로세스와 하드웨어 및 소프트웨어 프로세스 간의 인터페이스는 다음 섹션에서 다룬다.

 

하드웨어 및 소프트웨어 아이템에 요구사항이 할당되는 지점은 또한 이 문서의 지침이 DO-178B/ED-12B(소프트웨어를 위한), DO-254/ED-80(전자 하드웨어를 위한), 그리고 기타 기존 산업 지침으로 전환되는 지점이기도 하다. 이 문서는 이중화 관리를 포함한 아키텍처, 개발 보증 레벨 그리고 기능 분해에 대한 지침을 제공한다. 이는 아키텍처, 이중화 관리 그리고 요구사항 분해가 완료되는 시점에 하드웨어 그리고/혹은 소프트웨어에 대한 요구사항 할당이 시작된다는 것을 의미한다.

 

다음 데이터가 요구사항 할당의 일부로 소프트웨어 및 하드웨어 프로세스에 전달된다.

 

a. 하드웨어로 할당된 요구사항

b. 소프트웨어로 할당된 요구사항

c. 아이템(들)에 대한 개발 보증 레벨(들)과 해당하는 경우 관련된 고장 조건(들)에 대한 설명

d. 하드웨어 고장에 대한 할당된 고장률과 노출 간격

e. 시스템 설명

f. 기능 격리, 분리, 기타 외부 인터페이스 요소의 데이터/모델 및 분할 요구사항 그리고 아이템 개발 독립성 요구사항을 포함한 설계 제약 조건

g. 해당되는 경우 소프트웨어 혹은 하드웨어 개발 레벨에서 수행할 시스템 검증 활동

h. 하드웨어 그리고/혹은 소프트웨어 프로세스에 의해서 시스템 프로세스로 제공된 데이터에 대해서 시스템 프로세스에 의한 활동 혹은 평가를 수행함으로써 그러한 시스템 프로세스에 의해서 얻게 되는 수용가능성의 증거. 그런 활동의 예는 SSA에 미치는 영향을 결정하기 위해 소프트웨어 프로세스에서 제공하는 파생 요구사항을 시스템 프로세스에서 평가하는 것이다.

 

4.6.1.2 하드웨어/소프트웨어 프로세스로부터 시스템 프로세스로의 정보 흐름

 

아래에 나열된 정보는 시스템 레벨 개발 활동과 필수 프로세스를 지원하기 위해 시스템 프로세스로 전달되는 데이터에 포함되어 있어야 한다.

 

a. 시스템 혹은 아이템 요구사항 그리고 안전성 평가에 대해서 평가되어야 할 파생 요구사항(하드웨어와 소프트웨어 모두),

b. 달성된 독립성 및 결함 억제 기능(예: 하드웨어 분리, 소프트웨어 파티셔닝)을 보여주기에 충분한 구현된 하드웨어 혹은 소프트웨어 아키텍처에 대한 설명,

c. 소프트웨어 혹은 하드웨어 개발 레벨에서 수행된 시스템/아이템 검증 활동의 증거(존재하는 경우),

d. SSA에 통합하기 위한 하드웨어 고장률, 결함 탐지 범위, 공통 원인 분석 및 대기 시간 간격,

e. 시스템 혹은 아이템 요구사항 혹은 안전성 평가에 대해서 평가되어야 하는, 시스템 혹은 아이템 요구사항 혹은 하드웨어/소프트웨어 파생 요구사항에 영향을 미칠 수 있는 문제점 혹은 변경의 문서화,

f. 사용 제한, 형상 식별/상태 제약, 성능/타이밍/정확도 특성,

g. 하드웨어/소프트웨어의 시스템 통합을 용이하게 하는 데이터(예: 설치 도면, 회로도, 부품 목록),

h. 시스템 레벨 검증 중에 수행할 제안된 하드웨어/소프트웨어 검증 활동의 세부 사항.

 

또한 도구를 통해서 달성한 모든 보증을 포함해서 할당된 아이템 개발 보증 레벨(들)과 일치하는 프로세스 활동이 수행되었다는 증거가 제공되어야 한다.

 

4.6.1.3 하드웨어 설계 라이프 사이클과 소프트웨어 라이프 사이클 프로세스 간의 정보 흐름

 

아래에 나열된 정보는 하드웨어와 소프트웨어 라이프 사이클 프로세스 간에 전달되어야 한다. 이 정보는 시스템 프로세스를 통해 전달되어야 한다. 이러한 데이터에는 다음이 포함된다.

 

a. 하드웨어와 소프트웨어 간의 인터페이스에 대한 프로토콜 정의, 타이밍 제약, 그리고 주소 체계와 같은 하드웨어/소프트웨어 통합에 필요한 파생 요구사항,

b. 하드웨어 및 소프트웨어 검증 활동에 조정이 필요한 부분,

c. 하드웨어와 소프트웨어 간에 식별된 비호환성, 이는 리포트 및 수정 조치 프로세스의 일부가 될 수 있다.

 

4.6.2. 하드웨어 및 소프트웨어 설계/구축

 

하드웨어 및 소프트웨어 설계/구축 프로세스는 하드웨어 및 소프트웨어에 할당된 요구사항에 대한 추적성을 제공해야 한다. 하드웨어 및 소프트웨어 구현이 요구사항 할당 및 아키텍처 정의 단계와 함께 진행되는 경우 파생 요구사항이 캡처되고 구현에서 모든 기능 요구사항이 달성되도록 보장하기 위해 충분한 훈련이 필요하다.

 

이 단계의 출력은 전자 하드웨어-소프트웨어 통합 절차, 릴리즈된 하드웨어 도면, 관련된 라이프 사이클 데이터와 함께 소프트웨어 소스 코드, 적용가능한 개발 보증 데이터, 해당하는 경우 브레드보드 혹은 프로토타입 하드웨어, 그리고 실험실/비행 테스트 품목을 포함한다. 섹션 2.1.4와 2.1.5에 참조된 RTCA/EUROCAE 문서는 전자 하드웨어 및 소프트웨어의 개발에 대한 지침을 제공한다.

 

4.6.3. 전자 하드웨어/소프트웨어 통합

 

사용된 시스템 및 개발 프로세스의 특성에 따라 초기 아이템 전자 하드웨어 및 소프트웨어 통합은 브레드보드, 프로토타입, 컴퓨터 에뮬레이션, 실험실 혹은 비행 관련 품목에서 발생할 수 있다. 이에 대한 출력은 개발 보증 데이터와 하드웨어 그리고/혹은 시스템 라이프 사이클 데이터와 함께 형상 컨트롤되고 있는 장비이다. 설계-구축 과정에서 개발된 세부 절차를 사용하여 모든 전자 하드웨어 및 소프트웨어 통합 요구사항이 충족되는지 확인해야 한다.

 

인터페이스 문서의 개발을 통해 전자 하드웨어/소프트웨어 통합 프로세스를 향상시키는 것이 도움이 될 수 있다. 이는 전자 하드웨어와 소프트웨어가 호환 가능한 기능(예: 전자 하드웨어가 올바르게 초기화되는 것, 메모리맵 등)을 제공하는 것을 보장할 것이다.

 

4.6.4. 항공기/시스템 통합

 

일반적으로 시스템 통합은 아이템별 통합으로 시작해서 완전한 시스템 통합으로 진행된다. 항공기 환경을 완전히 예측하거나 모델링하는 것이 어렵기 때문에 일부 통합 활동이 항공기에서 수행되어야 할 수 있다. 항공기에서 이루어지는 통합의 유효성은 일반적으로 높다고 가정되지만 종종 실험실 혹은 시뮬레이션 환경에서 더 의미 있고 비용 효율적인 결과를 얻을 수 있다. 시스템 통합을 위한 구체적인 절차는 업계 전반에 걸쳐 매우 다양하다.

 

통합 프로세스 중에 식별된 결함은 해결을 위해 적절한 개발 혹은 필수 활동(요구사항 캡처, 할당 혹은 확인, 구현, 검증, 등)에 다시 참조되어야 하며 프로세스가 반복되어야 한다. 모든 반복이 완료되면 이 활동의 출력은 시스템이 모든 기능 및 안전성 요구사항을 충족한다는 것을 보여주는 데이터와 함께 검증된 통합 시스템이다.

 

항공기/시스템 통합은 항공기에 설치된 모든 항공기 시스템이 개별적으로 그리고 함께 올바르게 작동하도록 하는 작업이다. 이는 그룹으로 취해진 시스템 간 요구사항이 충족되었음을 보여주는 수단을 제공한다. 또한 원하지 않는 의도되지 않은 기능을 발견하고 제거할 기회를 제공한다.