5. 필수 프로세스

이 섹션에서 설명하는 프로세스 요소들은 전체 프로세스의 기본 요소들이다. 이들은 섹션 4.1의 프로세스 태스크들과 여러 가지 상호 작용을 한다.

 

5.1. 안전성 평가

 

안전성 평가 프로세스는 회사가 인증 요구사항(예: 14CFR/CS Parts 23과 25, section 1309) 준수와 자체 내부 안전성 표준 충족을 보여주기 위해 사용된다. 이 프로세스에는 시스템 개발 중에 수행되고 업데이트된 특정 평가가 포함되며 다른 시스템 개발 프로세스와 상호 작용하는 방식이 포함된다. 주요 안전성 평가 프로세스는 ARP4761에 자세히 설명되어 있으며 아래와 같이 요약된다.

 

a. Functional Hazard Assessment(FHA): 항공기 및 시스템 기능을 검사하여 잠재적인 기능 고장을 식별하고 특정 고장 조건과 관련된 위험을 분류한다. FHA는 개발 프로세스 초기에 개발되며 새로운 기능이나 고장 조건이 식별되면 업데이트된다. 따라서 FHA는 설계 개발 사이클 내내 살아있는 문서이다.

b. Preliminary Aircraft Safety Assessment / Preliminary System Safety Assessment(PASA/PSSA): 항공기나 특정 시스템 혹은 아이템 안전성 요구사항을 수립하고 예상되는 항공기 혹은 시스템 아키텍처가 이러한 안전성 요구사항을 충족할 수 있다는 것을 예비적으로 보여준다. PASA와 PSSA는 시스템 개발 프로세스 전반에 걸쳐서 업데이트되어 궁극적으로 ASA(Aircraft Safety Assessments)와 SSA(System Safety Assessments)로 이어진다.

c. Aircraft Safety Assessment / System Safety Assessment(ASA/SSA): 구현된 항공기 및 시스템이 PASA 및 PSSA에서 설정한 안전성 요구사항을 충족하는지에 대한 검증을 수집, 분석 그리고 문서화한다.

d. Common Cause Analysis(CCA): 시스템과 아이템 간의 물리적 및 기능적 분리, 격리 및 독립성 요구사항을 설정 및 검증하고 이러한 요구사항이 충족되었는지 검증한다.

 

추가적으로, 안전성 평가 프로세스의 적절한 관리를 위해 안전성 프로그램 계획(Safety Program Plan)을 작성해야 한다. 또한 FHA에서 식별된 고장 조건은 개발 프로세스를 통해 추적되어 설계 구현이 안전성 기준을 충족하고 있다는 활성(active) 상태를 제공할 수 있다.

 

그림 7은 이러한 네 가지 특정 평가와 시스템 개발 프로세스 간의 기본적인 관계를 보여준다. 실제로는 이러한 관계들 내부와 그 사이에 많은 피드백 루프가 있지만, 명확성을 위해 그림에서 생략되었다.

그림7 안전성 평가 프로세스 모델

다양한 안전성 평가 활동에 필요한 상세화 수준은 항공기 레벨의 고장 조건 분류, 통합 정도 그리고 시스템 구현의 복잡도에 따라 달라진다. 모든 관련 고장 조건이 식별되었고 이러한 고장 조건을 유발할 수 있는 모든 중대한 고장 조합이 고려되었다는 필요한 보증을 제공하기 위해 안전성 평가 프로세스를 계획하고 관리해야 한다. 안전성 평가 프로세스는 항공기 및 시스템에 대한 적절한 안전성 목표를 설정하고 구현이 이러한 목표를 충족하는지 결정하는 것에 그 근본적인 중요성이 있다.

 

안전성 평가 활동은 이 문서의 이어지는 섹션에 요약된다.

 

5.1.1. Functional Hazard Assessments (FHA)

 

FHA(Functional Hazard Assessments)는 항공기와 시스템 레벨 모두에서 수행되어야 한다. 이를 통해 각 기능과 관련하여 다음과 같은 정보를 제공해야 한다(항공기 혹은 시스템 레벨에 따라서).

 

a. 관련된 고장 조건(들)의 식별

b. 고장 조건(들)의 영향 식별

c. 예를 들어 No Safety Effect(안전성 영향 없는)의 분류를 포함하도록 확장된 AC 25 1309-1A, AC 23 1309-1D와 AMC 25.1309에 정의된 것처럼 식별된 영향에 따른 각 고장 조건의 분류(즉, Catastrophic(대재앙의), Hazardous(위험한)/Severe-Major(엄중한), Major(중대한), Minor(경미한), 혹은 No Safety Effect(안전성 영향 없는))와 필요한 안전성 목표의 할당

d. 각 고장 조건을 평가할 때 고려된 사항과 가정한 사항을 요약하는 설명. (예: 불리한 운용 혹은 환경 조건 및 비행 단계)

 

이 단계를 수행하는 목적은 분류의 근거와 함께 각 고장 조건의 상황과 심각도를 명확하게 식별하는 것이다. 분리된 시스템에서 공통 아키텍처 혹은 복잡한 컴포넌트를 사용하는 것은 여러 기능을 포함하는 추가적인 항공기 레벨 고장 조건을 주입할 가능성이 있기 때문에 FHA는 이러한 새로운 고장 조건을 식별하고 분류해야 한다. 항공기 레벨 기능이 시스템 혹은 시스템 조합에 의해서 통합될 때 FHA는 여러 기능을 포함하는 고장 조건을 식별하고 분류하기 위해 재평가되어야 한다. FHA가 시스템 중심 섹션에서 구성되는 경우 항공기 레벨과 시스템 레벨 간의 위험 및 고장 조건에 대한 추적성이 필요하다.

 

개발 과정에서 구현의 선택은 여러 항공기 레벨 고장 조건 혹은 고장이 발생하는 시스템 간의 상호 작용에 대한 공통 원인을 주입할 수 있다. 이러한 공통 원인은 시스템 혹은 기능 경계를 넘어설 수 있다. 시스템 구현에 대한 검토를 수행하여 그러한 조건이 있는지, 그리고 이를 항공기 레벨 FHA에 추가해야 하는지를 결정해야 한다.

 

항공기 혹은 시스템 레벨 FHA 수행에 대한 자세한 내용은 ARP4761 부록 A를 참조한다.

 

5.1.2. Preliminary Aircraft / System Safety Assessment (PASA/PSSA)

 

PASA/PSSA(Preliminary Aircraft / System Safety Assessment)는 고장이 어떻게 FHA에 의해서 식별된 고장 조건을 야기할 수 있는지를 결정하기 위해 제안된 아키텍처(들)를 체계적으로 조사하는 것이다. PASA 및 PSSA의 목표는 항공기, 시스템 혹은 아이템의 안전성 요구사항을 완료하고 제안된 아키텍처가 안전성 요구사항을 충족할 것으로 합리적으로 예상할 수 있는지를 확인하는 것이다. PASA/PSSA는 대체 보호 전략(예: 파티셔닝, 빌트인 테스트, 모니터링, 독립성 그리고 안전성 유지보수 태스크 간격 등)의 필요성을 식별할 수 있다. PASA/PSSA 출력은 시스템 요구사항, 소프트웨어 요구사항 그리고 하드웨어 요구사항에 국한되지 않고 이들을 포함하여 ASA/SSA 및 기타 문서에 대한 입력으로 사용되어야 한다.

 

PASA/PSSA는 설계 정의와 관련된 반복 프로세스이다. PASA/PSSA는 항공기, 시스템 및 아이템 설계 정의를 포함한 시스템 개발의 여러 단계에서 수행된다. 가장 낮은 레벨에서 PSSA는 하드웨어 및 소프트웨어의 안전성 관련 설계 요구사항을 결정한다.

 

PASA/PSSA 수행에 대한 자세한 내용은 ARP4761 부록 B를 참조한다.

 

5.1.3. Aircraft / System Safety Assessment (ASA/SSA)

 

ASA/SSA(Aircraft/System Safety Assessment)는 관련된 안전성 요구사항이 충족되었음을 보여주기 위해, 구현된 항공기 및 시스템(들)에 대한 체계적이고 포괄적인 평가이다. PASA/PSSA와 ASA/SSA의 차이점은 PASA/PSSA는 제안된 아키텍처를 평가하고 시스템/아이템 안전성 요구사항을 도출하는 방법이라는 것이다. 반면에 ASA/SSA는 구현된 설계가 PASA 및 PSSA에 정의된 안전성 요구사항을 충족하는지 검증하는 방법이다.

 

ASA/SSA는 다양한 분석 결과를 통합하여 전체 항공기/시스템의 안전성을 확인하고 PASA/PSSA에서 식별된 모든 특정 안전성 고려사항을 다룬다. ASA/SSA 프로세스 데이터에는 관련된 분석 및 입증 결과가 포함된다. 여기에는 다음과 같은 정보가 포함될 수 있다.

 

a. 이전에 합의된 외부 이벤트 확률 목록,

b. 기능 및 인터페이스를 포함한 시스템 설명,

c. 고장 조건 목록 (FHA, PASA, PSSA),

d. 고장 조건 분류 (FHA, PASA, PSSA),

e. 고장 조건에 대한 정성적 분석 (예: FTA, FMES, Markov Analysis, Dependence Diagrams),

f. 고장 조건에 대한 정량적 분석 (예: FTA, FMES, Markov Analysis, Dependence Diagrams),

g. CCA(Common Cause Analyses)에서 얻은 결과,

h. 안전성 관련 태스크 및 간격 (FTA, FMES, Markov Analysis, Dependence Diagrams),

i. 항공기 기능 및 시스템에 대한 개발 보증 레벨(FDAL) (PASA, PSSA),

j. 전자 하드웨어 및 소프트웨어 아이템에 대한 개발 보증 레벨(IDAL) (PSSA),

k. PASA, PSSA의 안전성 요구사항이 설계 그리고/혹은 테스트 프로세스에 통합되는지를 검증,

l. 비분석적 검증 프로세스의 결과 (즉, 테스트, 시연 그리고 검사).

 

ASA는 개념 개발 초기부터 상세 설계 개발 완료까지 항공기 안전성 활동에 대한 요약을 제공해야 한다. 이는 항공기 레벨 요구사항 및 목표에 대한 준수를 보여주고 적절한 방법과 프로세스가 적용되었음을 보증하는 것을 목표로 한다. ASA는 다음을 검증한다.

 

• 모든 안전성 활동이 안전성 계획(Safety Plan)에 따라 수행된다,
• 항공기에 대한 안전성 요구사항이 충족되고 관련된 지원 자료를 사용할 수 있다,
• 안전성 확인/검증 프로세스가 완료되고 결과가 승인된다,
• 수행된 모든 활동은 항공기가 안전하다는 결론을 뒷받침하는 논리적 논거를 형성한다.

 

이 평가는 때때로 "안전성 케이스" 혹은 "안전성 통합"이라고 하는 것의 일부를 형성한다. 안전성 케이스 혹은 안전성 통합은 항공기와 시스템이 특정 상황에서 작동하기에 충분히 안전하다는 명확하고 이해 가능하며 방어 가능한 논거를 전달한다.

 

참고: FTA(Fault Tree Analysis)가 여기에 사용될 때, 상황에 적합한 분석인 경우 DD(Dependence Diagrams) 혹은 MA(Markov Analysis)와 같은 다른 분석 방법 또한 사용될 수 있음을 이해해야 한다.

 

ASA/SSA 수행에 대한 자세한 내용은 ARP4761 부록 C를 참조한다.

 

5.1.4. Common Cause Analysis (CCA)

 

안전성 혹은 규정 요구사항을 충족시키기 위해 기능, 시스템 혹은 아이템 간의 독립성이 필요할 수 있다. 따라서 그러한 독립성이 존재하는지 혹은 독립성의 결여가 수용될 수 있는지 확인할 필요가 있다. CCA(Common Cause Analysis)는 이러한 독립성을 검증하거나 특정 종속성을 식별하는 도구를 제공한다. Catastrophic(대재앙의) 고장 조건에 대해서는 공통 원인의 이벤트가 배제되어야 한다.

 

특히, CCA는 Catastrophic(대재앙의) 혹은 Hazardous(위험한)/Severe-Major(엄중한) 고장 조건으로 이어질 수 있는 개별 고장 모드 혹은 외부 이벤트를 식별한다. CCA는 평가를 돕기 위해 다음과 같은 연구 영역으로 세분화된다.

 

a. Particular Risks Analysis (PRA)

b. Common Mode Analysis (CMA)

c. Zonal Safety Analysis (ZSA)

 

이러한 분석은 설계 프로세스의 모든 단계에서 수행될 수 있다. 시스템 아키텍처 및 설치에 대한 잠재적인 영향을 고려하면 가장 비용 효율적인 시간은 설계 프로세스의 초기라는 점은 명확하다. 하지만, 구현이 완료될 때까지는 확인이 가능하지 않을 수 있다.

 

PRA(Particular Risks Analysis)는 관련 시스템 및 아이템 외부에 있지만 고장 독립성 주장을 위반할 수 있는 이벤트 혹은 영향으로 정의된 위험을 평가한다. 일부 특정 위험은 감항성 규정 때문에 분석이 필요한 반면, 다른 위험은 항공기 혹은 시스템에 대한 알려진 외부 위협에서 발생한다. 또한 이러한 특정 위험은 동시에 여러 구역에 영향을 줄 수 있는 반면에 ZSA(Zonal Safety Analysis)는 각각의 특정 구역으로 제한된다. PRA 수행에 대한 자세한 내용은 ARP4761 부록 J에서 확인할 수 있다.

 

ASA/SSA(FTA/DD 혹은 MA)에서 식별된 고장 이벤트가 실제 구현에서 독립적인지 검증하기 위해 CMA(Common Mode Analysis)가 수행된다. 개발, 제조, 설치, 유지보수 및 승무원 오류 그리고 독립성을 무너뜨리는 시스템 컴포넌트의 고장에 대한 영향을 분석해야 한다. 기능과 해당 모니터의 독립성을 고려해야 한다. 동일한 시스템 혹은 아이템은 여러 시스템 혹은 아이템에서 고장을 일으킬 수 있는 공통된 고장/결함에 취약할 수 있다. 예비 CMA의 결과는 개발 보증 레벨의 할당에 핵심이다. CMA 수행에 대한 자세한 내용은 ARP4761 부록 K에서 확인할 수 있다.

 

ZSA(Zonal Safety Analysis)는 항공기의 각 구역에서 수행되어야 한다. 분석의 목표는 설치가 기본 설치, 시스템 간 간섭 혹은 유지보수 오류와 관련된 안전성 요구사항을 충족하는지 확인하는 것이다. ZSA 수행에 대한 자세한 내용은 ARP4761 부록 l에서 확인할 수 있다.

 

5.1.5. 안전성 프로그램 계획 (Safety Program Plan)

 

안전성 프로그램 계획(Safety Program Plan)은 항공기 레벨에서 적용할 수 있는 안전성 활동의 범위와 내용을 정의해야 한다. 안전성 계획의 개념은 원하는 경우에는 시스템 레벨에서도 적용될 수 있다. 다음은 안전성 프로그램 계획에서 다루어질 수 있는 주제에 대한 개요이다.

 

• 안전성 설계 및 분석 책임이 있는 항공기 레벨에서 입력 요구사항을 식별,
• 적용 가능한 안전성 표준을 식별,
• 프로젝트 안전성 조직을 식별하고 이 조직 내의 책임과 안전 프로세스와 관련하여 파트너 그리고/혹은 공급업체와의 관계를 정의,
• 안전성 활동 및 결과물을 설명,
• 리포트가 필요한 주요 프로젝트 마일스톤을 정의,
• 관리 원칙, 안전성 요구사항의 확인 그리고 설계가 이러한 요구사항을 충족하는지에 대한 검증을 포함,
• 다른 적절한 계획(예: 인증 계획, 확인 및 검증 계획, 프로세스 보증 계획)과의 연결을 식별.

 

부록 B는 안전성 프로그램 계획에 대한 예시 내용을 제공한다.

 

5.1.6. 안전성 관련 비행 운항 혹은 유지보수 태스크

 

항공기 운항 및 유지보수 인력에 할당된 기능은 결과적으로 관련 안전성 요구사항을 가질 수 있는 태스크 및 절차를 낳게 된다. 식별된 고장 조건의 안전성 영향은 특정 태스크를 할당하거나 이러한 인력에 대한 특정 제한 사항을 식별하여 해결할 수 있다. 안전성 관련 태스크 혹은 제한이 인증 입증의 일부를 구성하는 경우, 인증 데이터에 식별 및 기록되어야 한다(5.8.4 참조). 인증 유지보수 요구사항에 대해서는 AC/AMC 25.19를 참조한다.

 

5.1.7. 서비스 중 안전성과의 관계

 

서비스 중 안전성 평가를 수행하기 위한 프로세스는 ARP5150 "Safety Assessment of Transport Airplanes in Commercial Service" 및 ARP5151 "Safety Assessment of General Aviation Airplanes and Rotorcraft In Commercial Service"에 설명되어 있다. 이들 문서에는 서비스 중인 항공기에 대한 안전성 우려의 감시를 설정 및 유지하고 이러한 문제를 해결하고 해결 방법을 문서화하는 데 사용되는 프로세스에 대한 심도있는 연구가 포함되어 있다.

 

전체적으로 보면, ARP4761 및 ARP5150(혹은 ARP5151)은 개념 설계에서 노후화에 이르기까지 민간 항공기와 해당 시스템 및 아이템의 전체 라이프 사이클에 대한 안전성 평가 프로세스를 포함한다.

 

안전성은 스스로 유지되는 것이 아니다. 항공기가 인도될 때 SSA 및 SAS에 의해 식별된 초기 안전성 레벨을 갖는다. 항공기가 운항됨에 따라 서비스 경험을 지속적으로 모니터링하고 안전성 관련 이슈 및 기회를 식별한 다음 적절한 제품 혹은 절차 변경을 통해 이러한 이슈를 해결하는 지속적인 프로세스를 통해 안전성 레벨을 유지한다.

 

진행중 안전성 평가 프로세스(Ongoing Safety Assessment Process)에는 다음과 같은 세 가지 목표가 포함된다.

 

a. 항공기의 감항성 (인증) 유지

b. 항공기의 안전성 유지

c. 항공기의 안전성 개선

 

서비스 중 안전성 평가 프로세스는 지속적이고 반복적이며 폐쇄형 루프가 될 것으로 예상된다. 이벤트가 식별되고 평가되며 조치가 구현되면 모니터링은 해당 조치의 효과를 계속 검증한다.

 

5.2. 개발 보증 레벨 할당

 

이 섹션을 잘 이해하기 위해 필요한 전제 조건은 기능, 고장 조건, 고장, 오류 및 독립성에 대한 정의이다.

 

고장 조건은 하나 이상의 고장 혹은 오류로 인해 발생할 수 있다.

 

고장 완화는 시스템 아키텍처에 영향을 미치는 AC/AMC 25.1309의 fail-safe 설계 개념을 포함하여 안전성에 대한 정성적 그리고/혹은 정량적 요구사항을 설정하여 수행된다. 이러한 측면은 이 문서의 섹션 5.1(안전성 평가)에 설명되어 있다.

 

오류는 개발 보증 프로세스의 구현으로 완화된다. 개발 보증 프로세스는 시스템 개발이 항공기 안전성에 영향을 줄 수 있는 개발 오류의 가능성을 제한할 만큼 충분히 훈련된 방식으로 수행되었다는 신뢰를 확고히 한다. 개발 보증 레벨은 항공기/시스템 기능 및 아이템의 개발 프로세스 과정에서 서비스 중 노출되는 경우 안전성에 부정적인 영향을 미치는 오류가 발생할 가능성을 안전성에 대해서 받아들일 수 있는 정도로 제한하기 위해 개발 프로세스에 적용되는 엄격성의 척도이다.

 

항공기/시스템 기능 혹은 아이템의 개발 보증 레벨은 이 항공기/시스템 기능 혹은 아이템의 개발 프로세스뿐만 아니라 검토되는 기능 혹은 아이템에 영향을 미칠 수 있는 범위까지 상호 관련된 다른 항공기/시스템 기능 혹은 아이템과의 인터페이스 개발에도 적용된다.

 

개발 보증 레벨은 개발 오류의 결과를 제한할 수 있는 개발 프로세스 간의 가능한 독립성을 고려하여 고장 조건의 심각도 분류에 따라 할당된다. 고장 조건 분류가 엄격할수록 고장 조건을 완화하는 데 필요한 개발 보증 레벨이 높아진다.

 

5.2.1. 일반 원칙 – 개발 보증 레벨 할당에 대한 소개

 

항공기 레벨 고장 조건 심각도 분류를 고려한 개발 보증 레벨 할당에 대한 일반 원칙은 다음 단락에 설명되어 있다.

 

Catastrophic(대재앙의) 고장 조건이 관련된 경우 할당 원칙은 다음과 같다.

 

• 만약 하나의 항공기/시스템 기능 혹은 아이템에서 개발 오류로 Catastrophic(대재앙의) 고장 조건이 발생할 가능성이 있는 경우 관련된 개발 보증 프로세스는 레벨 A가 할당된다.
• 만약 둘 이상의 독립적으로 개발된 항공기/시스템 기능 혹은 아이템 간에 개발 오류의 조합으로 Catastrophic(대재앙의) 고장 조건이 발생할 가능성이 있는 경우 하나의 개발 보증 프로세스에 레벨 A가 할당되거나 두 개의 개발 보증 프로세스에 최소한 레벨 B가 할당된다. 다른 독립적으로 개발된 항공기/시스템 기능 혹은 아이템은 개발 보증 레벨 C 이상으로 지정된다. 둘 이상의 독립적으로 개발된 항공기/시스템 기능 혹은 아이템이 실제로 독립적임을 확실히 하는 개발 보증 프로세스는 레벨 A를 유지해야 한다.

 

Hazardous(위험한) 고장 조건이 관련된 경우 할당 원칙은 다음과 같다.

 

• 만약 하나의 항공기/시스템 기능 혹은 아이템에서 개발 오류로 Hazardous(위험한)/Severe-Major(엄중한) 고장 조건이 발생할 가능성이 있는 경우 관련된 개발 보증 프로세스는 최소한 레벨 B가 할당된다.
• 만약 둘 이상의 독립적으로 개발된 항공기/시스템 기능 혹은 아이템 간에 개발 오류의 조합으로 Hazardous(위험한)/Severe-Major(엄중한) 고장 조건이 발생할 가능성이 있는 경우 하나의 개발 보증 프로세스에 최소한 레벨 B가 할당되거나 두 개의 개발 보증 프로세스에 최소한 레벨 C가 할당된다. 다른 독립적으로 개발된 항공기/시스템 기능 혹은 아이템은 개발 보증 레벨 D 이상으로 지정된다. 둘 이상의 독립적으로 개발된 항공기/시스템 기능 혹은 아이템이 실제로 독립적임을 확실히 하는 개발 보증 프로세스는 레벨 B를 유지해야 한다.

 

Major(중대한) 고장 조건이 관련된 경우 할당 원칙은 다음과 같다.

 

• 만약 하나의 항공기/시스템 기능 혹은 아이템에서 개발 오류로 Major(중대한) 고장 조건이 발생할 가능성이 있는 경우 관련된 개발 보증 프로세스는 최소한 레벨 C가 할당된다.

• 만약 둘 이상의 독립적으로 개발된 항공기/시스템 기능 혹은 아이템 간에 개발 오류의 조합으로 Major(중대한) 고장 조건이 발생할 가능성이 있는 경우 하나의 개발 보증 프로세스에 최소한 레벨 C가 할당되거나 두 개의 개발 보증 프로세스에 최소한 레벨 D가 할당된다. 다른 독립적으로 개발된 항공기/시스템 기능 혹은 아이템은 개발 보증 레벨 D 이상으로 지정된다. 둘 이상의 독립적으로 개발된 항공기/시스템 기능 혹은 아이템이 실제로 독립적임을 확실히 하는 개발 보증 프로세스는 레벨 C를 유지해야 한다.

 

Minor(경미한) 고장 조건이 관련된 경우 할당 원칙은 다음과 같다.

 

• 만약 하나의 항공기/시스템 기능 혹은 아이템에서 개발 오류로 Minor(경미한) 고장 조건이 발생할 가능성이 있는 경우 관련된 개발 보증 프로세스는 최소한 레벨 D가 할당된다.
• 만약 둘 이상의 독립적으로 개발된 항공기/시스템 기능 혹은 아이템 간에 개발 오류의 조합으로 Minor(경미한) 고장 조건이 발생할 가능성이 있는 경우 하나의 개발 보증 프로세스에 최소한 레벨 D가 할당된다.

 

5.2.2. FDAL과 IDAL

 

개발 단계에서 일반적인 원칙을 다루기 위해 두 가지 서로 다른 유형의 개발 프로세스로 두 단계가 식별될 수 있다. 기능 개발 단계와 아이템 개발 단계이다.

 

기능 개발 단계: 이 단계에서 기능에 대한 요구사항이 개발되고 아이템에 할당된다. 요구사항 개발 프로세스는 요구사항 집합의 확인(완전성 및 정확성 보장)을 포함한다. 기능 요구사항 개발을 위한 개발 프로세스의 엄격성 수준은 FDAL이라고 불리는 기능의 개발 보증 레벨에 의해 주어진다. 충족되어야 할 목표는 이 문서 내에 제시되어 있다. 부록 A는 각각의 FDAL에 대한 이러한 목표의 적용가능성을 제공한다.

 

아이템 개발 단계: 이 단계에서 아이템이 개발된다. 아이템을 위한 개발 프로세스의 엄격성 수준은 IDAL이라고 불리는 전자 하드웨어 혹은 소프트웨어 보증 레벨에 의해 주어진다. IDAL 할당의 맥락에서는 아키텍처를 사용해서 아이템 자체내의 잠재적인 개발 오류를 완화하는 부분은 포함되지 않는다. 전자 하드웨어 및 소프트웨어의 통합을 위해 충족되어야 할 목표는 이 문서에서 제공된다. 시스템과 아이템 간의 경계는 항공기 제조업체와 공급업체 간 혹은 공급업체와 하위 공급업체 간의 경계 혹은 물리적 패키징과 일치하지 않을 수 있다는 점에 유의한다.

 

5.2.3. 상세한 FDAL 및 IDAL 할당 지침

 

ARP4761의 안전성 평가 기법(예: 항공기 FHA, PASA, 시스템 FHA, PSSA, CMA)을 사용하여 시스템 개발 초기에 고장 조건을 체계적인 방법으로 식별할 수 있다. 기능 간의 관계, 관련된 고장 조건 분류, 시스템 및 아이템 요구사항 그리고 해당하는 개발 보증 레벨 할당이 그림 8에 요약되어 있다. 항공기 기능의 제안된 할당은 항공기 FHA 기법을 사용하여 잠재적인 고장 조건에 대해 평가함으로써 항공기 레벨 아키텍처를 확인하고 항공기 레벨 기능에 기여하는 다양한 시스템에 대한 안전성 요구사항을 도출한다.

그림 8 FDAL/IDAL 할당 프로세스

개발 보증 레벨은 개발 프로세스의 오류를 최소화하기 위한 적절한 확인 및 검증 프로세스를 호출하기 위해 항공기/시스템 기능 및 아이템에 할당된다. 할당된 개발 보증 레벨이 특정 하드웨어의 무작위 고장 확률을 의미하는 것은 아니다. 즉, 안전성 요구사항 준수를 입증하기 위해 필요한 경우 고장 조건의 확률 분석도 필요하다. 항공기/시스템 기능 혹은 아이템 개발 보증의 엄격성 수준은 기능에 대한 FDAL 혹은 아이템에 대한 IDAL인 개발 보증 레벨의 할당에 의해 설정된다는 것을 이해해야 한다.

 

항공기 기능을 구성하는 시스템 기능의 상호 작용은 항공기 기능의 FDAL에서 평가되어야 한다. 시스템 기능을 구성하는 아이템의 상호 작용은 항공기 및 시스템 기능의 여러 FDAL 중 더 높은 것에서 평가되어야 한다.

 

개발 보증 레벨 할당 프로세스는 항공기 그리고/혹은 시스템의 FHA 고장 조건(여기서는 최상위 레벨 고장 조건이라고 함)과 관련된 기능에 대한 FDAL 할당으로 시작한다.

 

FDAL은 가장 심각한 최상위 레벨 고장 조건 분류를 기반으로 최상위 레벨 기능에 할당된다. 이는 항공기 및 시스템 FHA에서의 각 기능에 대해 표 2에 따라서 수행된다. 이러한 할당은 이 ARP에 설명된 해당 개발 보증 프로세스에 대한 엄격성을 설정한다.

 

표2 최상위 레벨 기능 FDAL 할당

 

5.2.3.1 시스템 아키텍처를 고려하지 않은 FDAL 할당

 

표 2는 해당 기능 하에서의 모든 것에 대한 개발 보증 레벨을 직접 할당하는 데 사용될 수 있다(즉, 최상위 레벨 기능을 지원하는 모든 기능에 대해 FDAL을, 최상위 레벨 기능 FDAL과 동일한 레벨의 아키텍처에 포함된 모든 아이템에 대해 IDAL을 할당). 시스템적인 오류에 대한 완화 전략이 Catastrophic(대재앙의) 고장 조건에 대해 단일 FDAL A 개발 프로세스인 경우, 지원자는 해당 멤버에 대한 개발 프로세스가 재앙적인 영향을 가진 잠재적 개발 오류(들)가 제거되거나 완화되었다는 것을 보장하기에 충분한 독립적인 확인/검증 활동, 기술 그리고 완료 기준을 가지고 있다는 것을 입증해야 할 수 있다. 이 경우, 개발 보증 프로세스는 아키텍처 내의 독립성에 의존하기보다는 프로세스 내에서 개발 오류(들)가 감지되고 해결될 것이라는 확신을 제공할 필요가 있다.

 

5.2.3.2 시스템 아키텍처를 고려한 FDAL 할당

 

일단 최상위 레벨 고장 조건의 심각도 분류를 기반으로 FDAL이 최상위 레벨 기능에 할당되면 해당 최상위 레벨 기능과 관련된 시스템 기능의 아키텍처를 조사하여 해당하는 시스템 기능의 개발 보증 레벨을 결정한다. 이 섹션에서는 지원 시스템 기능에 대한 FDAL을 결정하는 프로세스를 설명한다.

 

둘 이상의 독립된 하위 기능에 최상위 레벨 기능을 할당하는 동안(즉, 하나의 하위 기능만으로는 최상위 레벨 위험을 초래할 수 없음), 하위 기능 중 적어도 하나에 대해서 최상위 레벨 기능의 FDAL보다 낮은 FDAL을 할당할 수 있다. 하지만 또한 하위 기능 중 적어도 하나의 FDAL 할당이 최고 위험 수준만큼 높을 수 있는 기능 할당이 있을 수 있다. 이어지는 단락에서 몇 가지 다른 FDAL 할당 케이스가 논의된다.

 

FDAL(그리고 IDAL) 할당을 잘 이해하기 위한 전제 조건은 FFS(Functional Failure Set), 멤버(Members) 그리고 독립성(Independence)의 정의이다.

 

시스템 아키텍처를 고려할 때 개발 보증 레벨을 할당하는 체계적인 접근 방식은 FFS(Functional Failure Set) 개념을 사용하는 것이다. 시스템 안전성 평가 기술은 각 최상위 레벨 고장 조건과 각 FFS의 멤버로 이어지는 모든 FFS를 식별하는 데 사용된다. 주어진 고장 조건에 대한 FFS는 Fault Tree Analysis(참조: ARP4761 부록 D) 혹은 Dependence Diagrams(참조: ARP4761 부록 E)와 같은 정성적 안전성 평가 기술을 사용하여 식별할 수 있다.

 

개념적으로 FDAL (그리고 이어지는 IDAL) 할당의 경우, FFS는 결함 트리 최소 컷 세트와 동일하며(ARP4761에 정의된 것처럼), 여기서 멤버는 고장이 아니라 잠재적인 개발 오류의 결과를 나타낸다. FFS는 각각의 고장 조건으로 이어질 수 있는 멤버의 조합을 식별하고 잠재적 오류를 완화하기 위해 적절한 엄격성을 할당하는 데 사용된다. 하나의 고장 조건은 단일 FFS 혹은 여러 FFS를 가질 수 있으며 각각의 FFS는 단일 혹은 다중 멤버를 포함할 수 있다.

 

5.2.3.2.1 독립성(Independence) 속성

 

항공기/시스템 기능 혹은 아이템 간의 독립성(Independence)은 잠재적인 공통 모드 오류로부터 보호할 수 있으며 개발 보증 레벨을 지정할 때 고려해야 할 기본적인 속성이다.

 

독립성 속성의 의도는 고장 조건 분류의 심각도에 상응하는 둘 이상의 멤버 사이에서 공통 모드 오류의 가능성이 최소화된다는 충분한 확신을 갖는 것이다.

 

FDAL 및 IDAL 할당을 위해 기능적 독립성(Functional Independence)과 아이템 개발 독립성(Item Development Independence)이라는 두 가지 유형의 독립성 속성이 고려된다.

 

5.2.3.2.1.1 기능적 독립성(Functional Independence)

 

기능적 독립성(Functional Independence)은 공통 요구사항 오류의 가능성을 최소화하기 위해 기능이 다른 속성이다. 예를 들어, 기능 요구사항의 두 가지 다른 집합을 할당하면 두 가지 모두에 동일한 오류가 있을 가능성을 최소화할 수 있다. 조사되는 고장 조건의 심각도에 상응하는 수준에서 요구사항이 충분히 철저한 검사를 거쳤으며 부정적인 공통점이 식별되지 않았음을 분석을 통해서 보여야 한다.

 

기능적 독립성은 다음과 관련된 공통 오류 소스의 가능성을 최소화한다.

 

• 공통 요구사항 에러
• 공통 요구사항 해석 에러

 

항공기 혹은 시스템 레벨 기능을 구현/달성하기 위해 서로 다른 요구사항이 채택되고 관련 최상위 레벨 고장 조건을 완화할 수 있는 기능적 독립성의 예는 다음과 같다.

 

• 지상에서의 감속 (휠브레이크, 엔진 역추력 장치 그리고 지상 스포일러)
• 지상에서의 방향 제어 (노즈 휠 스티어링, 차동 제동 그리고 고속 방향타)
• 공중에서의 항공기 제어 (비행조종면 그리고 추력 벡터 제어)
• 항공기의 상대 위치 제공 (통신 그리고 항법)
• 운항 (GPS 그리고 관성 참조 시스템)
• AOA 제공 (날개 그리고 대기 속도 및 관성 데이터에서 계산된 합성 AOA)
• 연료량 제공 (엔진 연료 유량 그리고 탱크 연료 프로브)

 

기능적 독립성을 강화/유지하는 데 필요한 요구사항은 개발 사이클 전반에 걸쳐 관리되어야 하며 아이템 개발에 제약으로 이어질 수 있다.

 

기능적 독립성은 여러 요구사항 집합 간의 공통 오류 소스가 최상위 레벨 고장 조건 심각도 분류에 상응하는 엄격성의 수준에서 최소화될 때 입증된다. 요구사항에 공통 오류 소스의 존재가 불확실한 경우 기능적 독립성을 주장할 수 없다. 이것은 추상화 혹은 요구사항 분해의 모든 레벨에서 입증되어야 한다.

 

5.2.3.2.1.2 아이템 개발 독립성(Item Development Independence)

 

아이템 개발 독립성(Item Development Independence)은 개별적으로 개발된 아이템 간의 공통 모드 오류가능성을 최소화하기 위해 아이템들이 서로 다르다는 속성이다.

 

아이템 개발 독립성을 통해서 완화될 수 있는 오류의 예는 다음과 같다.

 

• 소프트웨어 설계 오류 (소프트웨어 요구사항, 소프트웨어 아키텍처 등을 포함),
• 소프트웨어 개발 오류 (소프트웨어 개발 프로세스, 소프트웨어 형상 컨트롤 등을 포함),
• 하드웨어 설계 오류 (하드웨어 요구사항, 하드웨어 아키텍처 등을 포함),
• 하드웨어 개발 오류 (하드웨어 개발 프로세스, 하드웨어 형상 컨트롤 등을 포함),
• 전자 하드웨어 도구 오류 (VHDL 코더, 레이아웃 도구 등),
• 소프트웨어 개발 도구 오류 (컴파일러, 링커 등)

 

아이템 개발 독립성을 달성하기 위한 수단의 예는 다음과 같다.

 

• 유압 vs 전력 사용과 같은 서로 다른 기술,
• 서로 다른 운영 체제,
• 서로 다른 컴퓨터/소프트웨어 언어,
• 서로 다른 마이크로프로세서,
• 서로 다른 팀과 프로세스

 

아이템 개발 독립성은 여러 아이템 간의 공통 오류 소스가 최소화될 때 입증된다. 입증은 최첨단 기술 그리고 서비스 경험과 같은 고려사항과 함께 최상위 레벨 고장 조건 분류의 심각도에 상응하는 엄격성 수준을 적용하여 달성된다. 아이템 간의 독립성에 대한 요구사항은 필요에 따라 시스템에서 해당 아이템으로 흘러가야 한다. 아이템 간에 공통 오류 소스의 존재가 불확실하거나 입증할 수 없는 경우 아이템 개발 독립성을 주장할 수 없다.

 

5.2.3.2.1.3 기능적 그리고 아이템 개발 독립성의 요약

 

기능적 독립성은 기능 요구사항이 공통 오류를 겪지 않도록 보장하는 반면 아이템 개발 독립성은 기능이 구현되는 아이템 개발이 공통 모드 오류를 겪지 않도록 보장한다.

 

5.2.3.2.2 FDAL 그리고 IDAL 할당 프로세스

 

FDAL 및 IDAL 보증 레벨 할당은 FHA에서의 고장 조건 심각도 분류로 시작하여 PASA/PSSA에서 최상위 레벨 FDAL을 할당하는 하향식 프로세스이다. 최상위 레벨 기능을 하위 기능으로 분해한 후 하위 기능의 FDAL이 할당된다. 그런 다음 각 하위 기능이 아이템으로 분해 그리고/혹은 할당된 다음 아이템 IDAL이 할당된다. FDAL 및 IDAL 할당 프로세스는 새로운 기능 그리고 새로운 아이템을 개발할 때 적용되어야 한다. 그럼에도 불구하고 경험에 따르면 개발은 종종 과거에 활용을 위해 개발 및 인증된 항공기/시스템 기능 및 아이템을 사용한다. 이전에 개발된 항공기/시스템 기능과 아이템의 재사용을 고려할 때, FDAL과 IDAL은 섹션 5.2.1에 정의된 "일반 원칙"과 섹션 5.2.3.3 및 5.2.4의 특정 사례를 다루는 것을 보여야 한다.

 

일단 FDAL이 최상위 레벨 고장 조건 심각도 분류를 기반으로 최상위 레벨 항공기 기능에 할당되면 최상위 레벨 고장 조건과 관련된 시스템 기능의 아키텍처를 조사하여 해당 시스템 기능의 개발 보증 레벨을 설명한다.

 

항공기 혹은 시스템 아키텍처가 둘 이상의 독립적인 멤버들에 의한 개발 오류의 영향에 대해서 억제를 제공할 수 있는 경우 아키텍처에서 제공하는 그러한 억제를 고려하여 개발 보증 레벨이 할당될 수 있다. 시스템 안전성 평가 기법은 최상위 레벨 고장 조건으로 이어지는 FFS(Functional Failure Sets)내의 멤버들을 식별하는 데 사용된다. FFS의 식별은 독립성 속성이 고려되는 PSSA 및 CMA의 주제이다. 최상위 레벨 고장 조건에는 둘 이상의 FFS가 있을 수 있다.

 

FFS 멤버 간의 독립성을 입증하기 위한 엄격성 수준은 표 2에 따라 최상위 레벨 고장 조건에 할당된 것과 동일한 FDAL이다. 주어진 FFS 내의 멤버들은 기능적 독립성 속성이 충족되는 경우 최상위 레벨 고장 조건 심각도 분류보다 낮을 수 있는 자체 FDAL을 할당받을 수 있다. 항공기 기능을 구성하는 시스템의 상호 작용은 주장된 기능적 독립성의 입증을 포함하여 항공기 기능의 FDAL에서 평가될 필요가 있다.

 

표 3은 주어진 최상위 레벨 고장 조건의 심각도 분류와 관련하여 FFS 내의 멤버(들)에게 FDAL을 할당하기 위한 지침을 제공한다. 표 3을 활용하는 프로세스의 예가 부록 C에 나와 있다. 각각의 기능에 대한 모든 최상위 레벨 고장 조건에 대해 프로세스를 반복한 다음 모든 고장 조건에서의 역할을 고려하여 해당 기능에 가장 엄격한 FDAL을 할당한다. 옵션 1 혹은 옵션 2의 선택은 식별된 고장 조건을 완화하는 데 가장 적절한 것으로 간주되는 옵션에 따른 인증 지원자의 재량에 달려 있다. 반복적인 설계 프로세스 동안 표 3에 대해 여러 항목들이 해당될 것으로 예상된다. 하지만, 각각의 항목은 반드시 최상위 항공기 레벨 고장 조건(즉, 표 3의 동일 행)에 연결되어야 한다.

 

IDAL 할당은 항상 FDAL 프로세스를 따른다. 시스템 아키텍처가 아이템 레벨로 세분화되면 표 3을 사용하여 FFS 멤버에게 FDAL이 할당된다. 표 3에서 최상위 레벨 고장 조건에 적용한 것과 동일한 행을 활용하도록 주의해야 한다. 이러한 할당은 관련된 아이템의 IDAL이 된다. 이 IDAL은 DO-178B/ED-12B(소프트웨어 개발 보증) 혹은 DO-254/ED-80(전자 하드웨어 설계 보증)의 적용을 위한 입력으로 사용된다.

 

IDAL 할당의 경우 FFS에 아이템 개발 독립성이 있는 경우 지원자는 최상위 레벨 고장 조건 분류와 관련된 행의 옵션 1 혹은 옵션 2(즉, FDAL 할당과 같은 행)를 사용할 수 있다. 하지만 어떤 옵션을 선택하든 최종 FDAL 및 IDAL 조합은 섹션 5.2.1의 일반 원칙과 섹션 5.2.3.2.3 에 제시된 일반 케이스를 따라야 한다.

표 3 FFS(Functional Failure Set)의 멤버들에 대한 개발 보증 레벨 할당

참고 1: FFS에 단일 멤버가 있고 시스템 오류에 대한 완화 전략이 단독으로 FDAL A인 경우, 지원자는 해당 멤버에 대한 개발 프로세스가 Catastrophic(대재앙의) 영향을 미치는 잠재적인 개발 오류(들)가 제거되거나 완화되었음을 보장하기 위한 충분한 확인/검증 활동, 기술 그리고 완료 기준을 가지고 있다는 것을 증명해야 할 수 있다.

 

참고 2: 수행된 기능적 분해의 수와 관계없이 같은 행에 있어야 함(예를 들어 Catastrophic(대재앙의) 고장 조건의 경우 최상위 FDAL A FFS로부터의 어떤 분해이든 적어도 하나의 FDAL A 혹은 두 개의 FDAL B 멤버를 포함해야 한다)

 

참고 3: FFS(Functional Failure Set)에서 멤버들의 수치적 가용성에 큰 차이가 있는 경우 일반적으로 더 높은 가용성 멤버에게 더 높은 레벨의 FDAL이 할당되어야 한다.

 

참고 4: 14 CFR Part 23/CS-23 항공기의 일부 클래스는 표 3에 제시된 것보다 낮은 FDAL을 가지고 있다. 구체적인 지침은 현재 FAA AC23.1309 및 이에 상응하는 EASA 정책을 참조한다.

 

5.2.3.2.3 FDAL 그리고 IDAL 할당 케이스

 

5.2.3.2.3.1 케이스 1: 기능적 독립성도 아이템 개발 독립성도 없음

 

기능적 독립성이 없고 아이템 개발 독립성이 없는 경우 표 3의 2열을 사용하여 FDAL 및 IDAL을 할당한다. FDAL 및 IDAL은 동일하며 최상위 레벨 기능 FDAL과 동일하다.

 

5.2.3.2.3.2 케이스 2: 기능적 독립성 그리고 아이템 개발 독립성 모두 있음

 

기능적 그리고 아이템 개발 독립성이 모두 있는 경우 먼저 표 3을 사용하여 FDAL을 할당한 다음 표 3을 사용하여 IDAL을 할당한다(IDAL을 FDAL로 대체). IDAL 할당에는 최상위 레벨 고장 조건 분류와 관련된 행의 옵션 1 혹은 옵션 2(즉, FDAL 할당과 동일한 행)를 사용할 수 있다. 항공기/시스템 기능 및 아이템 모두의 오류 조합을 나타내는 FFS에 대한 리뷰를 수행하여 FDAL 및 IDAL 할당이 섹션 5.2.1의 일반 원칙을 준수하는지 확인해야 한다. 이를 리뷰하는 목적은 항공기/시스템 기능 및 아이템의 개발에서 발생할 수 있는 모든 오류 조합이 일반 원칙에 따라 FDAL 및 IDAL 할당에 의해 적절히 완화되는지 확인하는 것이다. 그림 9 및 표 4에 표시된 예는 Catastrophic(대재앙의) 고장 조건인 FC2에 대해 F1 및 F2에 대한 FDAL 할당에 B가 주어진 두 개의 유효하지 않은 IDAL 할당을 보여준다.

 

할당 프로세스가 끝날 때 해당 FDAL보다 높은 IDAL의 할당이 요구되는 경우 지원자는 FDAL이 IDAL 레벨에서 재할당될 필요가 없음을 정당화해야 한다. (그림 9 및 표 4는 케이스 2의 요점과 섹션 5.2.1의 일반 원칙을 설명하기 위해 가능한 모든 오류 조합을 포함하며 표현 방법론을 설명하기 위한 것이 아니다)

 

그림9 기능적 독립성 및 아이템 개발 독립성

FC2 고장 조건에 대한 FFS를 식별하는 최소 방정식 혹은 항은 다음과 같다.

 

• F1 오류 및 F2 오류, 혹은
• F1 오류 및 I3 오류, 혹은
• I1 오류 및 F2 오류, 혹은
• I1 오류 및 I3 오류.

 

표4 동일한 FC에서 여러 기능들의 설계 의존성에 대한 보증 할당 예시

참고: 표 4의 일부 FFS는 항공기/시스템 기능 및 아이템 모두에서 오류의 조합을 나타낸다.

 

 

5.2.3.2.3.3 케이스 3: 기능적 독립성은 있으나 아이템 개발 독립성은 없음

 

독립적인 기능이 비독립적인 아이템(혹은 독립적이지 않은 아이템의 일부)을 사용하여 구현되고 비독립적인 아이템의 개발 오류로 인해 일부 혹은 모든 기능 간에 공통 모드 오류가 발생할 수 있는 경우 "공통된" 비독립적인 아이템의 IDAL은 가장 높은 FDAL 레벨이 할당될 필요가 있다. 그림 10의 결함 트리는 아이템 I2가 F1 및 F2에 영향을 미치는 이러한 조건을 보여주며, 이는 FDAL A를 가지는 Catastrophic(대재앙의) 최상위 레벨 고장 조건으로 이어진다. 다시 말해서, 공통 모드 오류가 최상위 레벨 고장 조건으로 직접 이어질 수 있는 경우 공통 아이템의 IDAL은 최상위 레벨 고장 조건 분류를 기반으로 할당된 최상위 레벨 기능의 FDAL이다. 그림 10에 나와 있는 Catastrophic(대재앙의) 사례에서 단일 멤버 FFS는 아이템 I2로 구성되므로 IDAL A가 할당된다.

 

FDAL 할당을 위해 주장된 기능적 독립성을 확인하고 공통 설계를 통해 다른 기능에 영향을 미치는 하나의 기능 개발 프로세스에서의 오류를 피하기 위해 공통 설계에서 구현된 기능은 파티셔닝되어야 한다. 파티션 기능의 개발 보증 레벨은 개발 오류의 가장 심각한 영향에 상응하는 FDAL이 할당되어야 한다. 이는 구현된 기능의 가장 높은 FDAL보다 낮지 않다. Catastrophic(대재앙의) 고장 조건 사례의 제시에서, F1 및 F2에 대해 정의된 독립성 요구사항은 F1 및 F2의 기능적 독립성 주장이 유지되도록 보장하기 위해 FDAL A에서 개발되어야 하는 F1 및 F2 요구사항의 하위 집합의 예가 될 것이다.

 

파티셔닝이 사용되지 않거나 독립성이 입증될 수 없는 경우 공통 설계의 IDAL은 공통 설계의 IDAL 레벨에서 해당 설계에 구현된 기능의 FDAL을 재할당하도록 강제할 수 있다. 이것은 일반적으로 기능의 구현 계층 혹은 기능의 일부가 파티셔닝 메커니즘에 의해 보호될 수 없는 경우이다(예: 운영 체제 계층 혹은 마이크로프로그램 계층에서 실시간 시퀀싱 기능 구현). 이 경우 파티셔닝 메커니즘으로 보호할 수 없는 기능의 FDAL은 공통 아이템의 IDAL에서 재할당될 필요가 있거나 설계의 독립 및 공통 부분을 분리하기 위해 상위 레벨 기능이 아이템에 재할당될 수 있다.

 

독립적인 항공기/시스템 기능의 FDAL 할당을 반영하는 IDAL 할당은 해당 개발이 기능적 독립성 경계 전반에 걸쳐 공통 개발 오류의 근원을 최소화했다는 것을 입증해야 한다. 예를 들어 FDAL A 기능을 수행하는 두 기능(그림 10의 F1과 F2)이 서로 독립적으로 설정된 기능을 수행하고 FDAL B(표 3의 옵션 2)가 할당되는 경우, 기능 요구사항은 FDAL B로 개발되어야 하며, 이들 두 기능에 대한 기능적 개발 독립성을 입증할 필요가 있을 것이다. 또한 그 두 FDAL B 기능 간의 상호 작용과 IDAL B 아이템(그림 10의 아이템 I1 및 아이템 I3) 간의 상호 작용은 이들 독립적인 항공기/시스템 기능 및 아이템들이 개별적으로는 레벨 B임에도 불구하고 항공기 기능 하에서의 FDAL A에서 캡처되고 검증될 필요가 있다.

 

기능적으로 독립적인 FDAL B 기능을 구현하는 아이템 중에 아이템 개발 독립성에 대한 주장을 막는 공통 아이템이 있는 경우 그림 10의 아이템 I2와 같이 최소한 공통 부분에 대해 IDAL A 할당이 필요할 것이다. 아이템 경계는 독립성을 입증하는 데 사용될 수 있는 인터페이스를 따라 반복적으로 형성될 수 있지만 남아 있는 공통 부분은 IDAL A를 할당해야 할 것이다. 위에서 언급한 완전히 독립적인 IDAL B 아이템의 경우와 마찬가지로, 두 FDAL B 기능 간의 상호 작용 그리고 IDAL B 아이템과 그들의 공통 IDAL A 아이템 간의 상호 작용은 이 항공기 레벨 기능의 일부가 개별적으로는 레벨 B임에도 불구하고 완전한 항공기 레벨 기능 하에서의 FDAL A에서 검증될 필요가 있다.

 

항공기/시스템 기능 및 아이템 모두에서 오류 조합을 나타내는 FFS를 리뷰하여 FDAL 및 IDAL 할당이 섹션 5.2.1의 일반 원칙을 준수하는지 확인한다. 이를 리뷰하는 목적은 항공기/시스템 기능 및 아이템의 개발에서 발생할 수 있는 모든 오류 조합이 일반 원칙에 따라 FDAL 및 IDAL 할당에 의해 적절하게 완화되도록 하는 것이다. 그림 10 및 표 5에 보이는 예는 F1과 F2에 대한 FDAL B 할당이 주어진 두 개의 유효하지 않은 IDAL 할당을 보여준다. (그림 10과 표 5는 케이스 3의 요점과 섹션 5.2.1의 일반 원칙을 설명하기 위해 가능한 모든 오류 조합을 포함하며 표현 방법론을 설명하기 위한 것이 아니다)

 

동일한 설계를 기반으로 하는 공통 리소스를 사용하는 독립된 기능(예: 컴퓨터, 네트워크, 인터페이스 그리고 IMA)은 신중한 고려가 필요할 수 있으므로 ARP4761에서 논의한다.

그림10 동일한 FC에서 여러 기능들의 개발 의존성

 

 

FC2 고장 조건에 대한 FFS를 식별하는 최소 방정식 혹은 항은 다음과 같다.

 

• F1 오류 및 F2 오류, 혹은
• F1 오류 및 I3 오류, 혹은
• I1 오류 및 F2 오류, 혹은
• I1 오류 및 I3 오류, 혹은
• I2 오류

 

표5 동일한 FC에서 여러 기능들의 설계 의존성에 대한 보증 할당 예시

참고: 추가적인 케이스가 평가될 수 있지만 여기에는 제시되지 않는다. 공통 아이템 I2는 최상위 레벨 위험을 지원하기 위해 레벨 A가 되어야 한다.

 

5.2.3.2.3.4 케이스 4: 기능적 독립성은 없으나 아이템 개발 독립성은 있음

 

최상위 레벨 기능은 서로 독립적인 여러 아이템으로 분해되는 하나의 시스템 기능에서 생성된다. 시스템 기능 FDAL은 표 2에 따라 최상위 기능 FDAL이 할당된다. 아이템 IDAL은 표 3의 최상위 레벨 고장 조건 분류에 해당하는 행의 옵션 1 혹은 옵션 2를 사용하여 할당된다.

 

참고: 각각의 독립된 아이템의 고장만으로 최상위 고장 조건을 초래해서는 안 된다.

 

5.2.3.3 IDAL 할당에 대한 추가적인 고려사항

 

IDAL 프로세스를 주어진 항공기/시스템 아키텍처에 적용할 때 아키텍처는 다음 케이스의 맥락에서 검토되어야 한다.

 

• 요구사항 및 식별된 고장 조건과 관련하여 테스트 및 분석의 조합으로 완전히 보장될 수 있는 컴포넌트는 설계가 확인 및 검증된 경우 IDAL A와 동등한 수준의 신뢰도를 제공하는 것으로 간주될 수 있다. 이는 해당 시스템 내의 기능 및 아이템에 대해 FDAL 및 IDAL을 할당하기 위해 시스템의 다른 아이템 혹은 기능과 관련된 역할을 고려할 때 유용할 수 있다. 예로는 기계 부품, 전기 기계 장치, 전기 밸브 혹은 서보 밸브가 있다.
• Catastrophic(대재앙의) 혹은 Hazardous(위험한) 고장 조건을 해결하고 동일한 COTS 설계(예: 컴퓨터, 네트워크, 인터페이스)를 기반으로 공통 리소스를 사용하는 독립된 기능은 추가적인 고려사항(예: 설정 컨트롤, 타겟 프로세서에서의 소프트웨어 테스트)이 필요할 수 있다. 기능적 그리고 아이템 개발 독립성의 전통적인 케이스는 독립적인 기능이 서로 독립적인 설계에서 구현되는 것이다.

 

5.2.4. 외부 이벤트에 대한 신뢰를 가지는 FDAL 할당

 

항공기 설계에서 외부 이벤트(예를 들면 화물칸 화재)에 대한 보호를 제공하는 시스템의 경우, 관련 FDAL을 규정하는 기존 지침 자료가 없는 경우 다음의 지침을 적용할 수 있다. 보호 기능의 잘못된 작동 혹은 활성화와 관련된 고장 조건 외에도 고려해야 할 적어도 다음과 같은 두 가지의 고장 조건이 있다.

 

• 외부 이벤트와 결합된 보호 상실: FHA(섹션 5.1.1에 따른)는 분류를 고려할 필요가 있다. 외부 이벤트에 대한 보호 기능의 FDAL은 그림 11에 따라 할당할 수 있다. 외부 이벤트와 결합된 보호 기능의 상실이 Catastrophic(대재앙의) 혹은 Hazardous(위험한)/Severe-Major(엄중한)인 경우, 보호 기능 단독에 대한 FDAL은 최소한 레벨 C여야 한다.
• 보호만 상실: FHA(섹션 5.1.1에 따른)는 안전성 마진(없음, 경미한, 중대한 혹은 큰)의 감소와 승무원 작업량에 대한 영향을 반영하기 위한 분류를 고려해야 한다.

 

외부 이벤트에 대한 보호를 위해 단일 기능만 있는 경우에는 표 3을 적용하지 않는다. 해당 기능이 여러 아이템으로 구현된 경우 외부 이벤트와 결합된 보호 상실의 고장 조건에 해당하는 표 3의 행을 적용한다.

 

보호의 손실만으로는 임무를 안전하게 완수할 수 있는 항공기 혹은 승무원의 능력에 영향을 미치지 않을 때(종종 그것은 잠재적인 고장이다), 보호되는 외부 이벤트의 예상 확률을 고려하여 안전성 마진의 감소 수준을 평가할 수 있다. 외부 이벤트가 더 자주 발생할수록 보호가 손실될 때 안전성 마진이 더 많이 감소한다. 그림 11은 이러한 서로 다른 속성 간의 관계를 보여주며 보호 기능 상실(가용성 고장)을 고려할 때 FDAL 할당에 대한 지침을 제공한다.

 

일부 비행 단계는 가끔씩만 발생하며, 이러한 단계는 비행 조건을 구별하는 데 필요한 경우에만 FHA에서 발생할 수 있다. 조건부 비행 단계 자체가 기능 혹은 FDAL이 할당되는 시스템과 독립적인 경우, 적용 가능한 조건부 비행 단계의 상황 혹은 빈도는 FDAL을 결정할 때 완화 요소로 간주될 수 있다. 임박한 실속(스틱셰이커를 넘어선 비행), 오버스피드 혹은 비상 하강과 같은 비정상적인 비행 조건은 FDAL 할당에 영향을 미칠 수 있으며 FHA의 관련 고장 조건에도 반영된다. 의도적으로 수행되는 운항 및 운항 비행 단계(자동 착륙 혹은 ETOPS 세그먼트)는 FDAL 정당화에 이러한 고려사항을 포함할 수 없을 것이다. 이 경우, 지원자는 지원자가 제안한 개발 보증 프로세스가 허용 가능한 수준의 안전성을 충족한다는 것을 인증 당국에 입증해야 한다.

 

그림 11 외부 이벤트 확률에 따른 기능으로써의 보호 기능 FDAL 할당