CHAPTER 16. OTHER CONSIDERATIONS: ENGINE, PROPELLER, AND AIRCRAFT
SYSTEMS INTEGRATION AND RELATIONSHIPS BETWEEN ENGINE,
PROPELLER, AND AIRCRAFT CERTIFICATION ACTIVITIES
16-1. Systems Integration.
a. Two forms of systems integration are discussed. First, aircraft or propeller functions integrated into EECS hardware and software, and second, integrating engine functions into aircraft systems. One version of systems integration involves the integration of aircraft or propeller functions (i.e. those that have traditionally not been considered engine control functions) into the EECS hardware and software. The other version involves aircraft systems performing functions traditionally considered part of the ECS. These are addressed in paragraphs
(2)(a) and (2)(b), respectively, below.
b. We encourage applicants with highly integrated systems to develop an EEC System Integration Certification Plan (SICP). A SICP should identify the tasks unique to integration.
You should include in it’s SICP a clear definition of the respective certification tasks of the engine, propeller, and aircraft manufacturers. The applicant should also develop it’s plan during close coordination with the associated engine, propeller, and aircraft certification authorities. The SICP may provide valuable information to the installer and should be provided to the installer for their use. It may address the following types of integration:
(1) Aircraft or propeller functions integrated into the ECS or EECS.
(a) Examples of aircraft or propeller functions integrated into the ECS include thrust reverser control systems, propeller speed governors, ATTCS, and APR System. When integrating aircraft or propeller functions into the ECS, the EECS failure cases related to the integration need to be included in the Aircraft Level SSA by the installer. Although aircraft functions incorporated into the ECS may be reviewed at engine certification, the acceptability of the safety analysis involving these functions will be determined at aircraft certification.
(b) The EECS may be configured to contain parts or all of the aircraft system’s functionality. Thrust reverser control systems are an example of including only part of the functionality in the EECS. In those control systems, the aircraft is configured with separate switches and logic (i.e., independent from the EECS) as part of the thrust reverser control system. This separation of reverser control system elements and logic provides an architectural means to limit the criticality of the functions provided by the EECS.
(c) One example of configuring the ECS to contain all functionality of an aircraft system: an ECS designed to fully govern propeller speed in turboprop aircraft. Here, the engine applicant may need to configure the ECS logic to feather a propeller when an engine fails.
Failure of the prop to feather may result in catastrophic aircraft failure as the result of excessive drag. Another example is an ATTCS or APR in turbofan aircraft. If an engine fails during takeoff, the engine applicant may need to configure the logic to increase the thrust of the remaining engine(s). Both examples indicate that criticality is not limited, since ECS failure 55
could result in loss of aircraft. Both examples also involve aircraft functionality that would receive significant review during aircraft certification.
(d) When functions like these are integrated into the ECS so that they render an ECS critical, the applicant should ensure that no single failure (including common cause/mode) could cause the critical failure condition. For example, exposing the EECS to overheat should not cause both an engine shutdown and failure of the propeller to feather.
(2) Integration of engine control functions into aircraft systems.
(a) Applicants may use aircraft systems to implement a significant number of ECS functions. For example, integrated flight and ECSs, such as those integrated into avionics, may be used to govern engine speed, and in helicopters, rotor speed, rotor pitch angle, and rotor tilt angle. A special case of this type of implementation is via an Integrated Modular Avionics system as defined in RTCA/DO-297. Implementation of a FADEC in an Integrated Modular Avionics system will require special considerations. The engine applicant needs to coordinate this with the Engine and Propeller Directorate. In these examples, we may require aircraft systems be used during engine certification. If so, then the engine applicant should specify the EECS requirements in the engine installation instructions and show that those EECS requirements are adequate to protect the engine from any hazardous engine effects.
(b) An example of limited integration is an engine control that receives a torque output demand signal from the aircraft and responds by changing the engine’s fuel flow and other variables to meet that demand. Then the EECS, which is part of the type design, provides all the functionality required to safely operate the engine as required by part 33 or other applicable specifications.
16-2. Certification Activities.
a. Engine certification. All hardware and software that reside on the engine, including those that provide aircraft or propeller functions, must meet the requirements of §§ 33.28(b), (f),
(g) and (m). This should include environmental testing of all components and software, and quality assurance of the software that performs both the engine and aircraft functions. The EECS SSA and other analyses (aircraft power, fault accommodation, etc.) that the engine applicant submits for engine certification, should address only engine functions performed by the EECS.
The aircraft and propeller functions do not need to be evaluated in the EECS SSA unless the functions affect engine operation or reliability.
b. Aircraft or propeller certification.
(1) The aircraft or propeller certification program should include all hardware and software substantiation requirements for the hardware and software that reside on the aircraft or propeller, including those that perform engine control functions. The applicant should also include environmental testing of all components and software, and quality assurance of the software that performs both engine and airplane functions.
(2) To satisfy aircraft requirements, such as §§ XX.901, XX.903 and XX.1309, the applicant should analyze the consequences to the aircraft of ECS failures. Together with the aircraft applicant, the engine applicant should ensure that the ECS software and AEH levels and safety and reliability objectives are consistent with aircraft certification requirements.
c. Interface Definition and System Responsibilities.
(1) The applicant should identify in the appropriate documents, e.g., EEC SICP or an Interface Control Document (ICD), the system responsibilities as well as interface definitions for the functions, the hardware and the software. These interfaces are typically between the engine, propeller, and aircraft systems.
(2) The engine, propeller, and aircraft documents should include:
(a) Requirements and categorization of the severity of the effects of a failure condition (that may be based on engine, propeller, and aircraft considerations),
(b) Fault accommodation strategies,
(c) Maintenance strategies,
(d) The software and airborne electronic hardware levels (per function if necessary), and
(e) The reliability objectives for:
1 LOTC/LOPC and MPL events, and 2 Transmission of faulty parameters.
(f) The environmental requirements including the degree of protection against lightning or other electromagnetic effects (for example, level of induced voltages that can be supported at the interfaces),
(g) Engine, propeller, and aircraft interface data and characteristics, and
(h) Aircraft power supply requirements and characteristics (if relevant).
d. Distribution of compliance tasks. Engine, propeller, and aircraft applicants often share aircraft propulsion system certification tasks. This is particularly true for aircraft propulsion systems equipped with electronic controls. Therefore, applicants sharing aircraft propulsion system certification tasks should identify how these tasks are distributed between themselves.
They should also include this distribution in their compliance plan(s). For example, the EEC SICP should list each task related to the EECS certification, identifying what each applicant should accomplish. The plan should likewise, address all analyses and tests required for EECS certification, also identifying what each applicant should accomplish. The appropriate engine, 57
propeller, and aircraft authorities will reach an agreement with the manufacturers on this distribution. This will ensure that all certification responsibilities are fully understood by each applicant, thereby avoiding certification delays.
(1) An EECS controlling the engine and propeller is a good example.
(a) The engine certification would address all general requirements such as software quality assurance procedures, EMI, HIRF and lightning protection levels; and effects of loss of aircraft-supplied power. The engine certification would also address the safety aspects for the engine functions (for example, safety analysis, rate for LOTC/LOPC events, and effect of loss of aircraft-supplied data). The fault accommodation logic affecting the control of the engine will be reviewed at that time.
(b) Similarly, propeller certification would address the propeller functions. The functions and characteristics that the propeller applicant defines that are to be provided by the ECS would normally need to be refined by flight test. The propeller applicant would ensure that these functions and characteristics, provided for use during the engine certification program, define an airworthy propeller configuration, even if they have not yet been refined.
(2) An aircraft computer performing the functions for the control of the engine is also a good example.
(a) The aircraft certification would address all general requirements, such as software quality assurance procedures, EMI, HIRF, and lightning protection levels, and functional aspects for the aircraft functions.
(b) The engine certification would address the functional aspects for the engine functions (for example, safety analysis, rate for LOTC/LOPC events, and effect of loss of aircraft-supplied data). The fault accommodation logic affecting the control of the engine would also be reviewed at that time.
e. Design change control. The EEC SICP should describe the design change control system the applicant established to support post-certification activity. This design change system should ensure that changes to any control element integrated into the EECS are evaluated by all design approval holders of that integrated system.
APPENDIX 1. REFERENCES TO INSTALLATION (AND/OR OPERATING)
INSTRUCTIONS
The following is a list of all paragraph references in this AC to information that must be documented, if applicable, in the installation or operating instructions required by § 33.5. This list is provided as an aide to applicants.
Table A1-1. Paragraph References.
AC Chapter/Paragraph number Brief Description 1-2a. Functions that are added to the EECS that are not required for compliance with part 33, but are required for installation compliance.
1-4 Installation and operational assumptions for the target application and any installation limitations or operational issues must be noted.
4-1 Rule: Environmental limits to which the system has been qualified must be documented.
4-2d.(1) HIRF and lightning test levels must be declared for engine type certification and documented in the engine installation instructions.
4-2d.(1)(b) Wire shields, connectors, etc. required for HIRF and lightning protection when the engine is installed on the aircraft.
4-2d.(1)(e) Same requirements for Reciprocating engines when using alternate levels. These are listed in the subsequent paragraphs.
5-1 Rule: If the crew is required to initiate, respond to, or be aware of the control mode change, the means to alert the crew must be described.
5-2a.(2) Show that all declared dispatchable control modes are capable of performing their intended functions in the environmental conditions 5-2a.(5) Any limitations on operations in alternate modes must be clearly stated.
5-2a.(6) Descriptions of the functioning of the ECS operating in its primary and any alternate modes must be provided.
5-2a.(9)(b) The loss of capability in some non-dispatchable modes such as operability in rain, hail, or bird ingestion should be documented or demonstrated.
5-2b. Training modes must be described.
5-2d.(4)(f) The power or thrust change associated with mode transition should be declared.
5-2d.(5) Any observable time delays associated with control mode, channel or system transitions, or in re-establishing the pilot’s ability to modulate engine thrust or power must be identified.
5-2d.(6)(b) The intent and purpose of the cockpit annunciation must be clearly stated.
6-2e.(4) The assumed reliability and interface requirements for non-engine type design elements must be documented.
6-2g.(4)(b) If cooling provisions are required in the design of the EECS, the applicant must specify these provisions.
6-2i.(7) The maximum safe design operating temperature for the components must be declared.
6-2i.(11)(b) Where aircraft interface wiring is involved, applicant must inform the installer of the potential effects of shorts in the interface wiring.
7-2a.(4) Identify the applicable assumptions and installation requirements and establish any limitations relating to ECS operation.
A1-1
AC Chapter/Paragraph number Brief Description 10-2c.(1)(b) The installation and/or the operating instructions should identify data transfers and exchanges between engines, and between the airplane and engines, that could produce common mode faults.
10-2c.(4) If the ECS relies entirely on aircraft air data to complete any of its critical control functions, then the engine applicant must require:
that the aircraft air data system is unaffected by a complete loss of aircraft generated power, and that there be no common mode faults where multiple incorrect, but valid, signals are transmitted to the engine control.
10-2f.(3) If an alternate mode, independent of aircraft-supplied data, has been provided, the applicant should document the characteristics of operation in this mode.
10-2g. The engine applicant must document data or issues to allow the installer to ensure engine compliance as installed. These are listed in the subsequent paragraphs.
11-1 Rule: Identify all characteristics for any required aircraft power.
11-2a.(1) Engine installation instructions should identify battery health, status, and maintenance requirements.
11-2a.(2)(b) If aircraft power is a back-up power source, then applicants should provide detailed electrical system interface requirements in the engine installation instructions.
11-2c.(2) As a part of the consideration regarding an aircraft single bus failure, The installation instructions may reference a wiring diagram.
11-2c.(3) The maximum allowable failure event rate values should be declared 11-2c(4)(c) Back up power used as a primary power source has specific requirements to assure that the EECS SSA assumptions are not violated 11-2d.(1) Any aircraft-supplied power reliability values used in system analyses, whether supplied by the aircraft manufacturer or assumed must be included.
11-2d(4)(b)1 Design review and safety analysis requirements if aircraft power without a dedicated power source is to be used 11-2e.(1) The ECS’s electrical power supply quality requirements.
11-2f.(1)(a) When aircraft power recovers from a low-voltage condition to a condition within which the ECS is expected to operate normally, the ECS must resume normal operation and the time interval associated with this recovery must be documented.
11-2f.(1)(c) The applicant should consider the effects of any aircraft electrical bus-switching transients or power transients in the engine installation or operating instructions.
11-2f.(2) The power requirements necessary for in-flight engine restarts are defined.
14-2. If the installer is to supply the fuel SOV, the applicant must state that a pilot initiated means for rapid shutdown of the engine must be provided by the installer.
In some instances these items may be documented in an Interface Control Document (ICD), also referenced in Section 16-2 c.(1). If an applicant wants to use the ICD as the means to document these facts, that may be possible. However, if that is the chosen method then the installation or operating instructions must reference the ICD and the ICD will need to be available to the Airworthiness Authorities and the installer.
A3-2
APPENDIX 2. CERTIFICATION AIDS The following are some document subjects commonly submitted with certification packages. Engine control system certification programs may vary. Not all documents in this list will apply to all programs, and this list is by no means, all inclusive.
Table A2-1.
Certification Aids.
Submitted Document Major Sections AC Chapter Reference Part 33 Section Number Installation and/or Operating Instructions Requirements Procedures Limitations Assumptions Also refer to Appendix 1 1 33.28 Declared Component/System Environmental Limits Electrical Physical 4 33.28(b)(2) Component/System Environmental Test Plans and Test Reports (Electrical) HIRF Lightning EMI TLD Environmental Tests 4 33.53
33.91
33.28(b)(2) ICA’s (as specified in AC 33.4
3) Maintenance Actions 4 33.28(b)(2) Component/System Environmental Test Plans and Test Reports (Physical) Thermal Vib Shock etc 4 33.53
33.91
33.28(b)(2) Control Modes Documentation Tests Analysis Backup availability 5 33.28(c) Reliability Assessment Plan 6 33.28(d) LOTC/LOPC Analysis (May be a sub-set of the SSA) 6 33.28(d) Commercial or Industrial Grade Electronic Parts Assessment 6 33.28(d) Single Fault Accommodation Analysis 6 33.28(d) Local Events Analysis 6 33.28(d) System Safety Analysis Full-up System Degraded System Protective Functions/Systems 7 33.28(e) A2-1
Submitted Document Major Sections AC Chapter Reference Part 33 Section Number Plan for Software Aspects of Certification (ref. RTCA/DO-178C) NOTE: Applicants should prepare all remaining Software 9 33.28(g) Software Configuration Index (ref. RTCA/DO-178C) Design Assurance documents as specified in RTCA/DO 9 33.28(g) Software Accomplishment Summary (ref. RTCA/DO-178C) 178B and have them on file and available for FAA audit.
9 33.28(g) Aircraft-Supplied Data Analysis Design Assessment Validation 10 33.28(h) Aircraft-Supplied Power Analysis Design Architecture Analysis Validation 11 33.28(i) Air Pressure Signals Analysis Design Analysis 12 33.28(j) Plan for Hardware Aspects of Certification (ref. RTCA/DO-254) NOTE: Applicants should prepare all remaining 15 33.28(m) Hardware Configuration Management Records (ref.
RTCA/DO-254) Hardware Design Assurance documents as specified in RTCA/DO-254 and have them 15 33.28(m) Hardware Accomplishment Summary (ref. RTCA/DO-254) on file and available for FAA audit.
15 33.28(m) EEC System Integration Certification Plan (SICP) (if applicable) Distribution of Compliance Tasks Interface Definition & Other Data Design Change Control 16 33.28 A2-2
APPENDIX 3. RECIPROCATING ENGINE EECS SSAs A reliability and safety analysis can show that the applicant’s system design meets its intended purpose. Two key terms that are used when evaluating system safety are “single-fault tolerant” and “unsafe condition.” Refer to chapter 11 of this AC for a discussion of ECS failures and, in particular, the subject of single-fault tolerance.
a. Unsafe condition. Engine power loss events are not typically considered unsafe conditions when evaluating airplane safety. However, if the frequency of these events is excessive relative to the safety objectives of the intended application, then they may be considered unsafe conditions. Consequently, engine power losses and shutdowns are included in the following failure conditions and categories that are considered unsafe conditions for reciprocating engines:
(1) Destructive events (DE).
(2) Excessive number of LOPC events.
(3) Excessive number of MPL events.
b. Continued operations
(1) Section 33.28 does not specifically address continued operations when faults are present in the EECS. However, service experience indicates that to be economically feasible, EECS-equipped engines must be permitted to operate for limited time periods with faults present in the system (that is, permitted to operate in a degraded state). In addition, a thorough system safety analysis includes all the components of the control system, including the mechanical components.
(2) To address these issues as well as meet the intent of the rule, the FAA has developed a method for demonstrating compliance for reciprocating engines that allows for operation with certain faults (that is, in a degraded state). This method consists of an ECS safety analysis with both quantitative and qualitative elements. The quantitative element compares the predicted number of failure events of the electrical or electronic components, with established criteria that represents unsafe conditions. Both full-up and degraded configurations are evaluated, but those degraded system configurations that are found acceptable are limited to 20 hours of operation. Mechanical component reliability is evaluated through the test and analyses required by §§ 33.19, 33.49, and 33.53. The qualitative elements provide an evaluation of the entire ECS.
(3) Instead of addressing all forms and levels of safety analyses, the FAA has developed a method for demonstrating compliance that meets the intent of § 33.28(e) and ensures an acceptable level of safety. The applicant may use a different method of showing A3-4
compliance. Alternative methods should be presented to the FAA for review and approval as early in the project as possible.
(4) The applicant may submit an EECS SSA to comply with § 33.28. The method of showing compliance described in this appendix allows for FAA approval of time-limited flight operations with certain reciprocating engine EECS faults. We derived a time limit of 20 hours from the unsafe condition criteria established for a degraded EECS. This 20 hour limit ensures that the engine maintains an acceptable reliability level during this type of operation.
c. EECS SSA: General. The EECS SSA includes a quantitative element that is intended to evaluate the predicted reliability of the components of the EECS, and to compare it to the system safety criteria included in this AC. The EECS SSA also includes a qualitative element that provides an evaluation of certain aspects of the EECS.
(1) The EECS SSA quantitative analysis will determine the instantaneous failure event rates in both the full-up system and degraded system. These event rates are then compared to the unsafe condition criteria for both full-up and degraded systems. The quantitative analysis may consist of the following analyses:
(a) Numerical FTA,
(b) FMEA, and
(c) Markov or similar type of analysis to evaluate the EEC system in a degraded condition.
(2) The EECS SSA qualitative analysis consists of design appraisals of certain aspects of the EECS. The qualitative analyses may include the following reports:
(a) Alternate control mode(s) characteristics,
(b) Control mode transition (refer to Chapter 5 of this AC),
(c) EECS output data content,
(d) Existing subsystems,
(e) Local events test or analysis (refer to Chapter 6 of this AC), and
(f) Commercial, automotive, or industrial grade electronic parts analysis (refer to Chapter 6 of this AC).
d. EECS SSA assumptions. The applicant should include in the EECS SSA, an explanation of any assumptions it made regarding airplane installation and operating conditions.
The applicant’s assumptions should be consistent with it’s data in the ICAs and the engine installation or operating instructions. The applicant’s assumptions may include the following:
A3-2
(1) Maintenance actions and associated intervals,
(2) Airplane systems or equipment response,
(3) Powerplant installation design and environment, and
(4) Latent failure exposure period.
e. EECS SSA quantitative analysis. The quantitative analysis is intended to supplement, but not replace, qualitative methods based on engineering and operational judgment and experience. In general, the depth and scope of an acceptable safety analysis depend on the complexity and criticality of the functions performed by the system, and can vary considerably for different types of systems. Because this analysis is limited to reciprocating engine electronic control systems, the criteria provided in this appendix are more specific. The quantitative analysis should encompass all elements of the control system: electrical or electronic, and mechanical.
(1) EECS SSA safety criteria. This appendix provides safety criteria, expressed in terms of events per million hours, for full-up and degraded configurations. The applicant may propose different criteria. However, if the applicant does so, the applicant should show that it’s different criteria provide an equally effective method of meeting the safety criteria.
(a) The safety criteria is provided for each of the two typical reciprocating engine control subsystems (fuel and ignition), and also for any other subsystem. This accommodates varying degrees of system functionality by increasing the allowable failure event rates as subsystems or functions are added to the total system definition. Once the total number of subsystems is defined and the associated maximum failure event rates are calculated, the applicant’s failure rates should be allocated across the total system and not to the individual subsystems. The failure event rates of tables A3-1 and A3-2 are consistent with FAA safety objectives for reciprocating engines.
(2) Full-up system analysis methods. The applicant may use this analysis to confirm that the full-up system meets the system safety criteria specified in table A3-1. We recommend that the applicant performs a numerical FTA and an FMEA, and that the applicant includes all engine parts in each.
(a) Each of the system elements in table A3-1 is additive. “Other” applies to each subsystem. For example, an EECS comprised of fuel, ignition, and wastegate control functions should meet a total system reliability of 15+15+15= 45 LOPC events per million hours (and 450 MPL events per million hours). This criteria is then applied to the entire system and not allocated to each of the subsystems.
(b) The applicant should limit the maximums to 45 LOPC and 450 MPL events per million hours, regardless of the number of subsystems. For example, if the EECS includes more than three subsystems, the sum of the LOPC rates for the total system should not exceed 45 A3-3
LOPC or 450 MPL events per million hours for all of the electrical and electronic elements.
Finally, the applicant should apply the event rates in table A3-1 to the highest appropriate system or subsystem level and not to individual components of the same system.
(3) Degraded system analysis methods and criteria. The applicant may use this analysis to confirm that the degraded system meets the system safety criteria of table A3-2 with existing fault(s), or with time limited operations. If the existing fault(s) does not affect engine operability and the criteria of table A3-2 are met, then Time-Limited Operations (TLO) may be approved for these fault conditions. The analysis determines the instantaneous failure rate with one or more failures in the system. A Markov analysis, or channel failure analysis for simple systems, may be used.
f. Time-limited operations (TLO) implementation requirements. The EEC SSA should include the following:
(1) The applicant should group all EECS faults into one of the following three operating limitations categories:
(a) No take-off (NTO). Faults in this category preclude departure. These faults are total system faults that result in calculated event rates that exceed the degraded system limits, or when the total system has insufficient resources to properly operate the engine. These system faults are defined as NTO faults.
(b) TLO. TLO faults permit operations up to 20 hours, and preclude them thereafter. These faults are also system faults that result in calculated event rates that exceed the full-up system limits but which are less than the degraded system limits. Also, the system LOPC and MPL rates are not generally greater than 450 and 4500 events per million flight hours, respectively. These system faults are defined as TLO faults.
(c) Unlimited operation (ULO). ULO faults are system faults where the calculated event rates are less than the full-up system limits (this may also apply to degraded system with certain minor faults).
(2) The applicant should ensure that its EECS design provides separate cockpit indications for TLO faults and NTO faults, such as:
(a) Indicator lights, codes, etc., and
(b) Confirmation of indicator function during the pre-flight check.
A3-4