6. 항공기 혹은 시스템에 대한 변경

이 섹션의 목표는 아이템, 시스템 혹은 항공기를 변경할 때 이 문서의 자료가 어떻게 적용될 수 있는지를 설명하는 것이다. 개발 및 안전성 평가 프로세스의 목표 중 하나는 원래 인증 기반에서 제공하는 기존의 안전성 레벨을 유지하거나 개선하는 것이다. 따라서 변경의 영향이 알려지고 완전히 확인되며 검증되는 방식으로 변경을 컨트롤해야 한다. 아이템, 시스템 혹은 항공기에 대한 변경은 새로운 기능 추가에서부터 필요한 수정 조치에 대한 대응에 이르기까지 다양한 이유로 시작될 수 있다. 변경 프로세스는 전체 안전성 관리 프로그램의 일부를 구성해야 한다.

 

항공기 및 시스템에 대한 변경을 보장하는 미국과 유럽의 접근 방식에는 차이가 있다. 필요하다고 판단되는 경우 이 섹션에서 그 차이점이 강조된다.

 

인증 기준은 적용가능한 요구사항, 규정, 특별 조건 그리고 기타 적절한 규정 자료를 정의한다. 항공기가 형식증명 기준 내에서 식별된 항공기에 적용가능한 요구사항 및 규정에 따라 항공기가 설계되었음을 지원자가 인증 당국에 입증했을 때 항공기는 형식증명(TC: Type Certificate) 을 받는다. 형식증명의 소지자는 형식 설계를 변경할 수 있다. 형식증명 소지자의 개별 항공 당국 규정에 따라 이는 TC 변경 혹은 ATC(Amended Type Certificate) 변경으로 수행될 수 있다. 아이템, 시스템 혹은 항공기 개조를 도입할 때 14 CFR/IR Part 21의 관련 단락에 정의된 대로 인증 기반에서의 잠재적 영향을 평가하고 "minor" 혹은 "major"로 분류해야 한다. 변경 분류의 승인은 관련 감항 당국으로부터 받아야 한다.

 

"major" 변경에 대한 지원자가 형식증명 소지자가 아닌 경우 일반적으로 부가형식증명(STC) 신청이 필요하다. TC 변경/ATC/STC는 지원자가 설계 변경을 통해 변경된 항공기가 해당 항공기에 적용되는 요구사항/규정을 계속 준수할 것임을 인증 당국에 입증할 때 발행된다.

 

장비의 승인을 위한 규정 프로세스도 있다. 이 프로세스는 (유럽)기술표준품 형식승인(TSO/ETSO)으로 알려져 있다. 이는 장비를 여러 항공기 유형에 통합할 수 있게 해준다. TSO/ETSO 승인은 장비에 대한 최소 성능 표준을 나타낸다. 항공기 시스템에 장비의 통합은 적절한 TC, ATC 혹은 STC 프로세스를 통해 수행된다. TSO/ETSO 아이템에 대한 변경 승인이 필요한 경우 위에서 설명한 바와 같이 "minor" 혹은 "major"로 평가 및 분류해야 한다. TSO/ETSO 소지자는 (예를 들면, IR Part 21 Subpart G POA와 같이 “대체” 설계 절차에 합의된 적절하게 승인된 생산 조직으로써) 당국의 추가 개입 없이 “minor” 변경을 승인할 수 있다. 하지만, 모든 "major" 변경 사항은 승인을 위해 관련 감항 당국에 제출되어야 한다.

 

6.1. 변경 프로세스 개요

 

지원자는 변경된 아이템, 시스템 혹은 항공기가 인증 기준을 충족함을 입증하는 방법을 정의하는 준수 방법 혹은 수단을 제안한다. 인증 기준이 원래의 형식증명에서 변경될 수 있으므로 합의된 인증 기준과의 호환성을 보장하기 위해 제안된 준수 증명 수단을 평가할 필요가 있을 것이다. 항공기 변경을 위한 이러한 방법 혹은 준수 수단은 이 문서의 이전 섹션에 제시된 대로 확립된 아이템 혹은 시스템 개발 프로세스에서 벗어나지 않는다. 변경 프로세스의 목표는 다음과 같다.

 

a. 변경 관리 프로세스를 개발하고 모든 이해 관계자와 조정,

b. 승인된 프로세스를 사용하여 변경 수행,

c. 초기 변경 영향 분석 수행 및 문서화,

d. 변경에 대한 분류를 결정(즉, “minor/major”),

e. 요구대로 아이템, 시스템, 그리고 항공기로 변경을 통합,

f. 변경 달성 요약/준수 입증 수행 및 문서화,

g. 변경과 관련된 데이터의 형상 컨트롤 관리, 섹션 5.6 참조

 

6.2. 변경 관리 프로세스

 

변경 관리 프로세스는 이해 관계자 간의 활동을 컨트롤하고 조정하는 구조화된 수단을 제공한다. 예를 들어, 지원자, 시스템 통합자 그리고 아이템 개발자는 각각 다른 이해 관계자의 변경 프로세스와 조정되는 정의된 변경 관리 프로세스가 필요하다. 이러한 프로세스 문서는 다음을 포함해야 한다.

 

a. 아이템, 시스템 혹은 항공기에 대한 제안된 변경의 설명(왜, 무엇을, 어떻게 그리고 일정),

b. 초기 변경 영향 분석의 결과,

c. 제안된 변경 구현 전략,

d. 합의된 구현 전략을 사용한 변경의 구현 및 통합,

e. 구현된 변경에 대한 검증 활동의 결과,

f. 최종 변경 달성 요약 활동의 결과,

g. 모든 변경된 아이템 혹은 시스템에 대한 항공기 형상 관리 업데이트, 섹션 5.6 참조

 

6.3. 변경 영향 분석

 

아이템, 시스템 혹은 항공기에 대한 변경이 제안되면 초기 영향 분석을 수행해야 하며 변경으로 인해 원래의 안전성 평가에 미칠 수 있는 영향에 대한 평가를 포함해야 한다. 예를 들어, 항공기 레벨의 변경이 제안되면, 사용된 아키텍처 형식, 개발 보증 레벨 할당 그리고 설치에 대해 만들어진 가정의 유효성을 검토해야 한다. 다음은 항공기 안전성 혹은 운영에 부정적인 영향을 미칠 수 있는 영역의 예이다.

 

• 안전성 관련 정보가 변경된다. 예를 들면,

- 고장 조건 분류(들) 변경 혹은 추가,

- 개발 보증 레벨,

- 안전성 마진이 감소된다,

- 아키텍처적인 가정,

- 환경 인증 테스트 결과의 유효성이 영향을 받는다,

- V&V 방법 혹은 절차가 변경된다.

 

• 운영 혹은 절차 특성이 변경된다. 예를 들면,

- 항공기 운영 혹은 감항성 특성,

- 비행 승무원 절차,

- 조종사에게 부하가 증가됨,

- 상황 인지, 경고, 주의 혹은 권고,

- 비행 결정을 내리기 위해 디스플레이되는 정보.

 

초기 영향 분석의 주요 결과는 제안된 변경에 의해 영향을 받는 고장 조건 분류(들) 및 시스템(들)이어야 한다. 또한 영향 분석은 변경 분류(즉, “major/minor” 변경)를 식별한다.

 

일단 검증 활동이 완료되면 변경 영향 분석을 확인하거나 업데이트해야 한다. 이러한 분석의 결과는 다음에 반영되어야 한다.

 

a. 적절한 인증 문서,

b. 변경 프로세스 과정에서 부정적인 영향이 발생하지 않음을 보장하기 위해 필요한 검증 활동,

c. 구현된 변경의 영향이 확인된 변경 요약.

 

수행되는 재분석 수준에 대한 근거는 운용 이력 그리고 변경되는 아이템, 시스템 혹은 항공기의 요구되는 보증 레벨과 같은 요소를 기반으로 제공되어야 한다. 변경의 결과로 안전성 평가 프로세스의 상당한 부분을 반복해야 할 수도 있다. 특히, 변경 중인 아이템 혹은 시스템이 다른 아이템 혹은 시스템과의 완전한 독립성을 입증하기 위해 Common Cause Analysis(CCA)에 포함되었다면, 초기 인증에 앞서 더 낮은 개발 보증 레벨 할당을 입증하기 위해 CCA는 그 결론이 유효한지 확인하기 위한 재조사를 요구할 것이다.

 

변경 영향 분석 그리고 변경의 수용가능한 구현을 위한 설계 활동을 포함해서 변경은 반복적인 프로세스이다. 초기 영향 분석은 최종 확증적 영향 분석이 생성되기 전에 여러 번 재검토되어야 할 수 있다.

 

6.4. 변경 분류 및 관리

 

항공 당국의 요구사항 및 규정은 항공기 변경을 "minor” 혹은 “major" 변경으로 분류한다. 이러한 변경은 위에서 식별한 프로세스를 통해 관리되어야 한다. 하지만 어떤 변경이든 다음을 보여줄 것이다.

 

a. 변경된 아이템, 시스템 혹은 항공기가 해당 인증 요구사항, 규정 및 규격 그리고 환경 요구사항을 충족한다.

b. 준수되지 않은 감항성 규정은 동등한 수준의 안전성을 제공하는 요소로 보상된다. 그리고,

c. 어떤 특성이나 특징도 인증이 요청된 용도에 대해 아이템, 시스템 혹은 항공기를 안전하지 않게 만들지 않는다.

 

6.5. 변경 수락에 대한 증거

 

이전에 인증된 아이템 혹은 인증된 시스템 "베이스라인"에서 수행된 개발 보증 활동에 대해 신뢰를 모색하는 경우 제안된 아이템 혹은 시스템 그리고 해당 인증 데이터를 해당 베이스라인까지 추적할 수 있어야 한다. 어떤 경우에는 그러한 증거가 충분하지 않을 수 있다. 이어지는 단락은 다음에 대한 지침을 제공한다.

 

a. 기존 아이템 혹은 시스템의 변경 혹은 이전에 인증된 아이템 혹은 시스템의 신규 설치 인증을 지원하기 위해 기존 인증 데이터를 보완,

b. 서로 다른 항공기 유형에서의 유사한 아이템 혹은 시스템 인증을 지원하기 위해 혹은 동일한 항공기 유형에서의 유사한 아이템 혹은 시스템 인증을 지원하기 위해 한 항공기 유형에서의 설치에서 얻은 서비스 이력을 사용.

 

기존 인증 데이터를 보완하기 위해, 지원자는 다음을 수행할 수 있다.

 

a. 이전 인증에서 사용할 수 있는 데이터를 평가하여 새로운 응용에 대해 어떤 인증 목표가 충족되고 어떤 목표가 추가 고려사항이 필요한 지를 결정한다. 이 활동은 변경 영향 분석의 일부를 구성한다,

b. 모든 가정이 검증될 수 있는 리버스 엔지니어링을 사용하여 새로운 응용에 대한 인증 목표를 충족하는 데 필요한 인증 데이터를 개발한다,

c. 인증 요구사항을 충족하기 위해 아래 지침에 따라 서비스 히스토리를 사용한다,

d. 인증 계획에 이 문서의 준수를 달성하기 위한 전략을 구체화한다.

 

6.5.1. 서비스 히스토리의 사용

 

분석을 통해서 적용가능한 히스토리가 확인되며 참조된 아이템 혹은 시스템 형상에 대한 변경이 적절하게 컨트롤되고 문서화된 경우 서비스 히스토리를 사용하여 신규/변경된 아이템 혹은 시스템의 인증을 지원할 수 있다. 이 방법을 사용하면 유사한 형태로 운영 중인 아이템 혹은 시스템의 요구사항과 비교하여 요구사항을 확인할 수 있다. 유사성에 대한 주장은 적용가능한 운영 경험 기간이 증가함에 따라 힘을 얻는다. 운영에서 경험한 중대한 문제가 이해되고 해결될 때까지는 유사성에 대한 주장을 사용해서는 안 된다.

 

서비스 히스토리 사용에 대한 고려사항은 다음을 포함한다.

 

• 지원자는 인증 계획에서 서비스 히스토리가 사용되는 방법을 제안해야 한다. (예를 들면, 사용가능한 서비스 경험의 양 그리고 서비스 데이터 분석 방법에 대한 설명)

• 지원자는 서비스 히스토리가 적용가능한 범위를 결정하기 위해 분석을 수행해야 한다. 그러한 분석은 다음을 보여주어야 한다.

a. 적용가능한 서비스 히스토리 기간 동안의 문제 보고 절차는 운영 중 문제의 적절한 단면을 제공하기에 충분함,

b. 서비스 히스토리 기간 동안 참조된 아이템 혹은 시스템에 대한 변경이 아이템 혹은 시스템의 안전성 혹은 성능을 실질적으로 변경하지 않음,

c. 서비스 히스토리 기간 동안 참조된 아이템 혹은 시스템의 실제 사용이 신규 혹은 변경된 아이템 혹은 시스템의 의도된 사용과 일치함. 기존 응용과 제안된 응용의 운영 환경이 다른 경우 차이점과 관련된 추가 확인 및 검증 활동을 수행해야 한다.

• 지원자는 보고된 모든 안전성 관련 문제를 원인 및 시정 조치와 함께 분석하고 제안된 아이템 혹은 시스템의 변경 혹은 응용과 관련이 있는지 여부를 확실히 해야 한다.

 

6.6. 변경에 대한 고려사항

 

기존 항공기, 시스템 혹은 아이템에 대한 변경은 아이템 혹은 시스템의 기능에 대한 추가, 삭제 혹은 변경을 포함하여 다양한 형태를 취할 수 있다. 변경의 예는 다음과 같다.

 

• 항공기 레벨의 새로운 기능을 도입,

• 기존 항공기에서 하나의 아이템 혹은 시스템을 다른 것으로 교체,

• 기존 아이템 혹은 시스템을 다른 항공기 유형에 적용,

• 기능 추가없이 아이템 혹은 시스템을 변경.

 

대부분의 시스템은 여러 기능을 구현하기 때문에 그런 시스템에 대한 특정 수정에는 이러한 형식 중 하나 이상이 포함될 가능성이 있다. 예로 든 변경은 섹션 6.1과 6.2에서 소개된 프로세스와 관련하여 아래에서 논의한다.

 

6.6.1. 항공기 레벨의 새로운 기능 도입하기

 

항공기 레벨의 새로운 기능 도입을 해결하기 위한 고려사항은 다음을 포함한다.

 

• 지원자는 이 문서에 제공된 지침에 따라 새로운 항공기 기능을 개발해야 한다. 변경 영향 분석에서 다음을 강조해야 한다.

- Functional Hazard Assessments(FHA)는 새로운 기능에 대한 고장 조건 및 관련 위험을 해결하고 변경할 아이템 혹은 시스템에 대한 안전성 목표를 식별해야 한다.

- FHA는 또한 새로운 항공기 기능의 도입으로 인해 다른 아이템, 시스템 그리고 기능이 영향을 받는 방식을 식별해야 한다. 이것은 기능적 상호 작용과 상호 의존성에 대한 분석을 수행하고 항공기 기능이 다른 항공기 기능과 통합되는 정도를 결정함으로써 달성될 수 있다.

 

이 분석은 제안된 변경의 분류에 대한 기초를 형성한다. 변경 구현 전략은 다른 아이템, 시스템 그리고 기능과의 상호 작용을 입증하기 위한 조치를 포함해야 한다.

 

• 이전에 인증된 "베이스라인" 항공기 혹은 시스템에서 수행된 개발 보증 활동에 대한 신뢰를 모색하는 경우에는 제안된 시스템 혹은 아이템 그리고 해당하는 인증 데이터를 해당 베이스라인까지 추적할 수 있어야 한다.

• 항공기 기능이 의존하는, 항공기의 수정되지 않은 영역에 대한 인증 데이터를 지원자가 이용할 수 없는 경우, 변경 영향 분석은 안전성 평가 프로세스의 결과를 지원하기 위해 해당 영역에 대해 만들어진 가정을 식별해야 한다. 변경 구현 전략은 가정을 입증하기 위한 조치를 포함해야 한다.

• 지원자는 필요한 경우 변경되지 않은 기능(들)과 관련된 안전성 평가 프로세스의 모든 요소를 반복할 수 있는 옵션이 있다.

 

새로운 기능이 항공기에 도입되면 항공기의 형상 변경으로 간주된다.

 

6.6.2. 기존 항공기에서 다른 것으로 아이템 혹은 시스템 교체하기

 

이전에 인증된 항공기 유형에 교체 아이템 혹은 시스템을 설치하면 항공기 레벨의 새로운 기능을 추가하지 않고도 항공기 기능의 구현을 변경할 수 있다. 교체 아이템 혹은 시스템은 다음을 포함한 여러 가지 이유로 설치될 수 있다.

 

• 노후된 장비의 교체,

• 신뢰성 혹은 무결성의 개선,

• 장비가 강화되거나 추가된 기능을 가지거나 규정 의무를 준수한다.

 

이전에 인증된 항공기 유형에 교체 아이템 혹은 시스템 설치를 위한 고려사항은 다음과 같다.

 

• 지원자는 이 문서에 제공된 지침에 따라 교체 아이템 혹은 시스템을 개발해야 한다. 변경 영향 분석에서, 다음을 강조해야 한다.

- Functional Hazard Assessments(FHA)는 교체 아이템 혹은 시스템에 대한 고장 조건 및 관련 위험을 해결하고 변경될 아이템 혹은 시스템에 대한 안전성 목표를 식별해야 한다.

- FHA는 또한 교체의 도입으로 인해 다른 아이템, 시스템 그리고 기능이 영향을 받는 방식을 식별해야 한다. 이것은 기능적 상호 작용과 상호 의존성에 대한 분석을 수행하고 교체에 의해서 수행되는 항공기 기능(들)이 다른 항공기 기능과 통합되는 정도를 결정함으로써 달성될 수 있다.

 

이 분석은 제안된 변경의 분류에 대한 기초를 형성한다. 구현 전략은 다른 기능 및 시스템과의 상호 작용을 입증하기 위한 조치를 포함해야 한다.

 

• 변경 영향 분석은 다음을 고려해야 한다.

- 교체 아이템 혹은 시스템의 설치 설계,

- 교체 아이템 혹은 시스템이 의존하는 영역,

- 교체 중인 아이템 혹은 시스템에 대한 인증 데이터의 가용성,

- 항공기에 대한 인증 기준.

 

교체 아이템 혹은 시스템에 대한 안전성 목표가 정확하고 완전함을 확인하며 항공기 레벨 안전성 목표가 충족되었음을 확인하기 위해 안전성 평가 데이터를 개발하는 것이 변경 구현 전략의 일부로 필요할 수 있다.

 

• 이전에 인증된 "베이스라인" 항공기에서 수행된 개발 보증 활동에 대한 신뢰를 모색하는 경우에는 제안된 아이템 혹은 시스템 그리고 해당하는 인증 데이터를 해당 베이스라인까지 추적할 수 있어야 한다.

• 변경되는 아이템 혹은 시스템이 개발 보증 레벨 감소를 증명하기 위해서 다른 아이템 혹은 시스템으로부터 기능적 그리고 아이템 독립성을 증명하기 위한, 베이스라인이 인증된 항공기의 Common Cause Analysis(CCA)에 포함되었다면, 해당하는 CCA는 그 결론이 여전히 유효하다는 것을 보장하기 위해 재조사가 필요할 것이다.

• 아이템 혹은 시스템이 의존하는 항공기의 변경되지 않은 영역에 대한 인증 데이터를 이용할 수 없는 경우, 변경 영향 분석은 안전성 평가 프로세스의 결과를 지원하기 위해 해당 영역에 대해 만들어졌던 가정을 식별해야 한다. 변경 구현 전략은 가정을 입증하기 위한 조치를 포함해야 한다. 하지만, 여기에 CCA의 적용을 받은 영역이 포함되는 경우 이 접근 방식은 베이스라인 CCA 결론이 유효한지 확인하기 위해 인증 당국과 함께 구체적인 분석 및 리뷰가 필요하다.

 

6.6.3. 다른 항공기 유형에 기존 아이템 혹은 시스템 적용하기

 

이전에 하나의 항공기 유형에서 운영하도록 승인된 아이템 혹은 시스템은 다른 항공기에서 사용하기 위해서는 재조사되어야 한다. 지원자가 이전 인증에서 신뢰를 모색하는 것을 선택한다면 인증 당국은 설계, 설치 그리고 응용이 유사하다는 증거를 요구할 것이다. 증거를 이용할 수 없다면, 설치할 아이템 혹은 시스템이 인증 요구사항/규정을 충족한다는 증거를 제공하기 위해 필요에 따라 섹션 4 그리고 5의 관련 부분이 적용된다. 다른 항공기에 설치하는 것에 대한 고려사항은 다음을 포함한다.

 

• 지원자는 다음을 고려하여 변경 영향 분석을 수행해야 한다.

- 기존 항공기와 제안된 항공기 모두에 대한 설치 및 운영의 유사성,

- 이전되는 아이템 혹은 시스템이 의존하는 기능의 유사성,

- 이전되는 아이템 혹은 시스템이 제안된 항공기의 다른 아이템 혹은 시스템에 미치는 영향,

- 기존 항공기 설치 인증 기준과 제안된 항공기 설치 인증 기준의 유사성,

- 이전 설치에서 사용할 수 있는 인증 데이터의 적절성.

 

이 분석은 제안된 변경의 분류에 대한 기초를 형성한다. 안전성 목표가 제안된 설치에 대해서 동일하고 적절한 수준의 항공기 유사성을 확립할 경우 추가적인 노력이 필요하지 않을 것이다.

 

변경 영향 분석은 새로운 설치와 관련된 기능에 의해 영향을 받는 원래의 응용과 관련된 기능을 식별해야 한다. 평가는 새로운 설치가 의존하는 변경되지 않는 기능을 다루어야 한다. 이는 새로운 아이템 혹은 시스템과 다른 항공기 아이템 혹은 시스템 간의 상호 작용 및 상호 의존성에 대한 분석을 수행하여 달성할 수 있다. 변경 구현 전략은 다른 아이템, 시스템 그리고 기능과의 상호 작용을 입증하기 위한 조치를 포함해야 한다.

 

• 이전에 인증된 "베이스라인" 항공기에서 수행된 개발 보증 활동에 대한 신뢰를 모색하는 경우에는 제안된 아이템 혹은 시스템 그리고 해당하는 인증 데이터를 해당 베이스라인까지 추적할 수 있어야 한다.

• 적용되는 아이템 혹은 시스템의 도입에 의해서 변경되는 아이템 혹은 시스템이 최상위 레벨 고장 조건 분류보다 낮은 개발 보증 레벨 할당을 입증하기 위해서, 다른 아이템 혹은 시스템으로부터의 기능적 그리고 아이템 개발 독립성을 증명하기 위한, 베이스라인이 인증된 항공기의 Common Cause Analysis(CCA)에 포함되었다면, 해당하는 CCA는 그 결론이 유효하다는 것을 보장하기 위해 재조사가 필요할 것이다.

• 적용되는 아이템 혹은 시스템이 의존하는 항공기의 변경되지 않는 기능에 대한 인증 데이터를 이용할 수 없는 경우, 변경 영향 분석은 안전성 평가 프로세스의 결과를 지원하기 위해 해당 기능에 대해 만들어졌던 가정을 식별해야 한다. 변경 구현 전략은 가정을 입증하기 위한 조치를 포함해야 한다. 하지만, 여기에 CCA의 적용을 받은 영역이 포함되는 경우 이 접근 방식은 베이스라인 CCA 결론이 유효한지 확인하기 위해 인증 당국과 함께 구체적인 분석 및 리뷰가 필요하다.

• 변경 구현 전략은 인증 요구사항/규정을 충족하기 위해 다음 조건에서 지원자가 기존 인증 데이터를 보완할 수 있도록 해야 한다.

a. 새로운 설치가 이전 설치의 인증 데이터를 제안된 설치의 안전성 목표를 충족한다는 것을 입증하는 데 사용할 수 없다.

b. 이전 설치의 인증 데이터가 영향을 받는 영역을 정의하고 입증하기에 부적절하다.

 

새로운 설치에 영향을 받는 모든 요구사항은 섹션 5.4 및 5.5에 제공되는 지침에 따라 확인되고 검증되어야 한다.

 

6.6.4. 기능 추가없이 아이템 혹은 시스템 변경하기

 

이전에 승인된 아이템 혹은 시스템에 대한 변경은 항공기 레벨의 새로운 기능을 추가하지 않고 항공기 기능의 구현을 변경할 수 있다. 변경은 요구사항 혹은 원하는 성능의 변경, 구현 오류의 수정, 장비 신뢰도의 향상 혹은 노후 장비의 교체로 인한 결과일 수 있다. 이전에 인증된 항공기의 아이템 혹은 시스템 변경을 처리하기 위한 고려사항은 다음을 포함한다.

 

• 변경 영향 분석은 다음에 미치는 변경의 영향을 고려해야 한다.

- 아이템 혹은 시스템이 의존하는 영역

- 항공기에 대한 인증 기준

- 기존 요구사항/규정(변경되지 않는 요구사항에 미치는 영향을 포함해서)

- 시스템 아키텍처

- 변경에 의해 영향을 받는 영역. 이는 변경된 아이템 혹은 시스템과 다른 항공기 아이템 혹은 시스템의 상호 작용에 대한 분석을 수행하여 달성할 수 있다. 변경 구현 전략은 식별된 상호 작용을 입증하기 위한 조치를 포함해야 한다.

 

이 분석은 제안된 변경의 분류에 대한 기초를 형성한다.

 

• 이전에 인증된 "베이스라인" 항공기 혹은 시스템에서 수행된 개발 보증 활동에 대한 신뢰를 모색하는 경우에는 제안된 아이템 혹은 시스템 변경 그리고 해당하는 인증 데이터를 해당 베이스라인까지 추적할 수 있어야 한다.

• 변경되는 아이템 혹은 시스템이 최상위 레벨 고장 조건 분류보다 낮은 개발 보증 레벨의 할당을 입증하기 위해서, 다른 아이템 혹은 시스템으로부터의 기능적 그리고 아이템 개발 독립성을 증명하기 위한, 베이스라인이 인증된 항공기의 Common Cause Analysis(CCA)에 포함되었다면 해당하는 CCA는 그 결론이 유효하다는 것을 보장하기 위해 재조사가 필요할 것이다.

• 아이템 혹은 시스템 변경이 의존하는 항공기의 변경되지 않는 영역에 대한 인증 데이터를 이용할 수 없는 경우, 변경 영향 분석은 안전성 평가의 결과를 지원하기 위해 해당 영역에 대해 만들어졌던 가정을 식별해야 한다. 변경 구현 전략은 가정을 입증하기 위한 조치를 포함해야 한다. 하지만, 여기에 CCA의 적용을 받은 영역이 포함되는 경우 이 접근 방식은 베이스라인 CCA 결론이 유효한지 확인하기 위해 인증 당국과 함께 구체적인 분석 및 리뷰가 필요하다.

• 변경 구현 전략은 다음 조건에서 지원자가 기존 인증 데이터를 보완할 수 있도록 해야 한다.

a. 변경된 아이템 혹은 시스템이 제안된 설치의 안전성 목표를 충족한다는 것을 입증하는 데 이전 설치의 인증 데이터를 사용할 수 없다.

b. 이전 개발의 인증 데이터가 아이템 혹은 시스템 변경의 영향을 받는 영역을 정의하고 입증하기에 부적절하다.

 

• 변경에 영향을 받는 요구사항은 섹션 5.4 및 5.5에 제공되는 지침에 따라 확인되고 검증되어야 한다.

 

6.6.5. STC 생산 소개

 

STC 변경(위의 섹션 참조)에 의해 하나의 항공기에서 작동하도록 이전에 자격을 얻고, 인증 및 승인된 아이템 혹은 시스템이 수정된 항공기 베이스라인의 일부로써 아이템 혹은 시스템을 제공하기 위해 항공기 생산 프로세스로 도입되는 경우가 있다. 그러한 프로세스는 인라인 형식증명(TC) 소지자 변경(in-line Type Certificate holder modification)이라고 하거나 STC로 생산 프로세스에 통합될 수 있다. TC 프로세스를 사용한 변경 도입은 위에 정의된 기준을 따라야 한다. 반면에 STC 접근 방식이 사용되는 경우 이미 제공된 것에 대한 추가 고려사항이 필요하다. STC 생산 도입을 위해 고려해야 할 주제는 다음과 같다.

 

• 프로젝트 조정. STC 소지자, TC 소지자/항공기 제조업체 그리고 인증 당국은 다양한 이해 관계자 간의 기대가 충족될 수 있도록 긴밀하게 협력해야 한다.

• 데이터 기대치 조정. STC에서 제공한 데이터가 항공기 및 변경 인증 기준과 TC 소지자/항공기 제조업체의 인증 기준에 적용되는 인증 요구사항/규정을 충족하도록 조정된 노력이 필요하다.

• 데이터 전송 조정. 일단 생산 도입을 위한 활동이 시작되면 TC 소지자, STC 소지자 그리고 인증 당국 간의 데이터 전송을 관리하는 프로세스가 필요하다. 인증 데이터에 이슈가 있는 경우 해당 데이터 이슈를 추적하고 해결하는 리포팅 시스템을 구현할 필요가 있다. 일반적으로 이것은 조정 각서(coordination memo)를 통해 수행된다.

• 변경되지 않은 남은 부분에 대해서 엔지니어링 데이터/설계 재사용에 대한 가정의 명확화:

- 이전 인증 노력에서 사용할 수 있는 데이터를 평가하여 새로운 응용에 대해 충족되는 목표 그리고 추가 고려사항이 필요한 목표를 결정.

- 리버스 엔지니어링을 사용하여 이 문서의 목표를 충족하는 데 필요한 인증 데이터를 개발.

- 이 문서의 목표를 충족하기 위해, 해당되는 경우 서비스 히스토리를 사용.

- 인증 계획에서 이 문서의 준수를 달성하기 위한 전략을 지정.

 

• 여러 STC의 호환성을 포함하여 인증 요구사항이 유효하다는 확신을 보장하기 위해 STC 구현의 포괄적 조정.

 

행정적 그리고 기술적 STC 프로세스 요구사항에 대해서는 FAA/EASA 14CFR/IR Part 21을 참조한다.

 

7. 참고

 

7.1 S-18 및 WG-63 위원회의 지도부는 이 문서를 개발하는 여러 해 동안 시간과 노력 그리고 비용을 들여서 기여해 온 위원회 멤버들과 그 후원사들의 활동에 감사를 표하고자 한다. 이들의 경험과 협조 그리고 헌신이 없었다면 이 문서의 개발은 불가능했을 것이다.

 

7.2 왼쪽 여백에 있는 변경 바(|)는 이 문서의 이전 호에 대한 편집상의 변경이 아닌 기술적인 개정이 이루어진 영역을 사용자가 쉽게 찾을 수 있도록 하기 위한 것이다. 문서 제목 왼쪽의 (R) 기호는 기술적인 개정을 포함하여 문서의 완전한 개정을 나타낸다. 변경 바와 (R)은 원본 출판물이나 편집상의 변경 사항만 포함된 문서에는 사용되지 않는다.

 

 

PREPARED BY SYSTEMS INTEGRATION SUBCOMMITTEE

(FAA SYSTEMS INTEGRATION REQUIREMENTS TG (SIRT)

OF COMMITTEE AS-1, AVIONICS/ARMAMENT INTEGRATION