CHAPTER 7. SECTION 33.28(e)
7-1. Rule Text. Section 33.28(e) provides that each EEC system must: “Have all associated software designed and implemented to prevent errors that would result in an unacceptable loss of power or thrust, or other unsafe condition, and have the method used to design and implement the software approved by the Administrator.”
7-2. Intent of Rule. Section 33.28(e) requires that EEC system software undergo a sufficient level of design assurance testing to ensure, with a high level of confidence, that errors in the software are prevented, and requires that the FAA approve the method used to design and implement the software.
7-3. Guidance. The following guidance provides a method, but not the only method, for demonstrating compliance with §33.28(e). Compliance with §33.28(e) should be demonstrated by software design and implementation in accordance with an approved method, such as RTCA Document DO-178B, in combination with system validation testing.
a. Compliance Elements.
(1) Software Design and Implementation Process. RTCA Document DO-178B, “Software Considerations in Airborne Systems and Equipment Certification,” provides guidelines for the software design and implementation process. This process includes the following activities:
(a) Life cycle definition;
(b) Planning;
(c) Development;
(d) Software verification;
1. Requirements-based coverage analysis should be conducted to demonstrate that the system requirements allocated to the software have been properly implemented.
2. The software should be verified by open or closed loop bench testing on a system that provides an electrical simulation of the engine system.
(e) Configuration management; and
(f) Quality assurance.
(2) System Validation Testing. Validation testing should be conducted to substantiate successful integration of the EEC system software and the engine control system. Validation testing should be performed on a complete engine, or on a test rig that provides a physical simulation of the engine control system.
Par 7-1 Page 39
b. Software Level Requirement. The level of confidence regarding error prevention in the software is directly related to the scope of the design assurance activity. These design assurance scopes have been defined in terms of software levels. These levels have been correlated to EEC system functional criticality. The FAA has accepted EEC system software verification to software levels defined in RTCA Document DO-178B as substantiation for the error prevention requirement. The following information is provided for determining the software level:
(1) RTCA Document DO-178B software level C has been determined to be the minimum requirement for the reciprocating engine EEC systems to which this AC applies. Level C would be acceptable for single-engine or twin-engine airplanes under 6000 pounds maximum take-off weight (MTOW) approved under part 23 normal, utility or acrobatic categories, or similar CAR 3 approval.
(2) The guidance provided in this AC does not apply to reciprocating EEC systems installed in airplanes approved under part 23 commuter or part 25 transport categories.
Therefore, the minimum software level for those EEC systems should be determined by performing an airplane system-level safety analysis.
(3) For reciprocating EEC systems installed in any other aircraft, the applicant should evaluate the failure condition criticality of EEC system functions to determine if Level C software would be adequate. This would require coordination with the aircraft designer and the cognizant aircraft ACO during the EEC system development program.
c. Software Partitioning. Non-critical software may be partitioned from the critical software, allowing the non-critical software to be designed and implemented at a lower level than that established for the critical software.
(1) The applicant should substantiate the adequacy of the partitioning method.
(2) The partition should be developed to the highest level of the components being partitioned.
(3) The applicant should consider if the lower levels of the partitioned software are appropriate for the anticipated installations. If the criticality level requirement were higher in subsequent applications, it would be difficult to raise the software level without repeating the software life cycle processes for the new level.
d. Software Integrity. RTCA Document DO-178B provides guidance for assurance of software used at specified hazard levels. As with all guidance to which this document refers, DO-178B may be modified or updated due to events or advancements in technology.
Page 40 Par 7-3
CHAPTER 8. INTEGRATION OF ENGINE, PROPELLER,
AND AIRCRAFT SYSTEMS
8-1. EEC System Integration Certification Plan (SICP). There must be a clear definition of the respective certification tasks of the various applicants: engine, propeller, and aircraft manufacturers, with the associated engine, propeller, and aircraft certification authorities. This should be documented in an EEC SICP, submitted by the applicant for engine certification. The plan should be included as an appendix to the instructions for installation and should include the following:
a. Distribution of Compliance Tasks. The tasks for the certification of the aircraft propulsion system equipped with electronic controls may be shared between the engine, propeller, and aircraft manufacturers. The distribution of these tasks between the manufacturers should be identified and agreed on by the appropriate engine, propeller, and aircraft authorities. The EEC SICP should summarize the engine applicant’s responsibilities for these certification tasks. The plan should list each task related to the EEC system certification and define those for which the engine applicant is responsible and those for which the aircraft or propeller applicant is responsible. The plan should address all analyses and tests required for EEC system certification.
b. Interface Definition and Other Data. The EEC SICP should include interface definitions and other data for the functional, hardware, and software aspects that have been integrated between the engine, propeller, and aircraft systems. The plan should describe integration aspects or provide cross-references to the instructions for installation for the following items:
(1) Functional requirements;
(2) Fault accommodation strategies;
(3) Maintenance strategies;
(4) Software quality level (per function if necessary);
(5) The reliability objectives for:
(a) LOPC and MPL events; and
(b) Transmission of faulty parameters.
(6) The environmental requirements, including the degree of protection against lightning or other electromagnetic effects (for example, the level of induced voltages that can be supported at the interfaces);
(7) Engine, propeller, and aircraft interface data and characteristics; and
(8) Aircraft electrical power supply requirements and characteristics (if relevant).
Par 8-1 Page 41
c. Design Change Control. The EEC SICP should describe the design change control system established to support post-certification activity. This system should ensure that changes to any control element that is integrated into the EEC system are evaluated by all design approval holders of that integrated system.
8-2. Aircraft Functions Integrated into the Engine Control System.
a. Integration Activities. These activities involve the integration of aircraft and propeller control functions (that is, those that have traditionally not been considered engine control functions) into the EEC system’s hardware and software. Examples include: propeller speed governors, which govern speed by varying pitch, cowl flap controls, and automatic throttle systems.
(1) The EEC system may be configured to contain only part of the aircraft system’s functions, or it may contain all of it. Turbine engine thrust reverser control systems are an example in which only part of the functions are included in the EEC system. In such cases, the aircraft is configured to have separate switches and logic (that is, independent from the EEC system) 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 EEC system.
(2) However, in some cases the EEC system may be configured to incorporate virtually all of a critical aircraft function. Examples of this are EEC systems that contain full authority to govern propeller speed and automatic throttle systems in turbofan-powered aircraft. The first of these is considered critical because if an engine fails, the logic in the engine control must be configured to feather the propeller on that engine. Failure to rapidly feather the propeller following an engine failure results in excessive drag on the aircraft; such a condition can be critical to the aircraft. Automatic throttle systems are considered critical because the system is required to react to an engine failure during take-off by increasing the thrust of the remaining functioning engine(s); the increased thrust on the functioning engines is necessary to achieve the required aircraft performance.
b. Certification Considerations.
(1) Engine Certification. The engine certification program should include all hardware and software substantiation requirements for the hardware and software that resides on the engine, including those that provide aircraft or propeller functions. This includes environmental testing of all components and software quality assurance of the software that performs both the engine and aircraft functions.
(a) The EECSA and other analyses (aircraft power, fault accommodation, etc.) that the engine applicant should submit for engine certification should address only engine functions performed by the EEC system. The aircraft and propeller functions do not need to be evaluated in the EECSA unless they affect engine operation or reliability.
Page 42 Par 8-1
(b) The engine applicant should include in the instructions for installation the architecture, failure event rate data, and any other requirements for the aircraft or propeller functions that reside in the EEC system components. This data is then considered part of the engine type design to which the associated aircraft or propeller certification program must adhere.
(2) Aircraft or Propeller Certification.
(a) The aircraft or propeller certification programs should use the data in the engine instructions for installation for input into the aircraft or propeller safety analysis for evaluation of the safety and functional aspects of those systems.
(b) The aircraft or propeller functions performed by the EEC system should be substantiated by test and analysis during the airplane or propeller certification program.
8-3. Integration of Engine Control Functions into Aircraft Systems.
a. Integration Activities. The trend toward systems integration may lead to aircraft systems performing functions that are traditionally considered part of the engine control.
(1) Limited authority functions that are not required by the EEC system for engine control may be incorporated into the aircraft or propeller systems. This type of function would augment the basic engine control with inputs based on certain aircraft flight conditions. In these cases, the EEC system would provide all the functions required to safely operate the engine in accordance with part 33. An example of such a limited authority function 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.
(2) Other designs may use aircraft systems to implement a significant number of the engine control system functions. Examples of this are the complex integrated flight and engine control systems for tiltrotor aircraft. These systems are integrated into aircraft avionics units and govern engine speed, rotor speed, rotor pitch angle, and rotor tilt angle.
b. Certification Considerations.
(1) Engine Certification.
(a) The EECSA and other analyses (loss of aircraft power, fault accommodation, etc.)
submitted for engine certification should include the engine control functions performed by the aircraft or propeller system. The engine applicant should substantiate the adequacy of the event failure rates, function architectures, and any other requirements used in these analyses by test and analysis. The analyses may be based on actual or assumed aircraft or propeller systems design characteristics.
Par 8-2 Page 43
(b) The engine applicant should include in the instructions for installation the architecture, failure event rate data, and any other requirements for the engine functions that reside in the aircraft or propeller system components. This data is then considered part of the engine type design to which the associated aircraft or propeller certification program must adhere.
(2) Aircraft or Propeller Certification.
(a) The data submitted for the aircraft or propeller certification program should substantiate that the associated aircraft or propeller system meets these engine installation requirements.
(b) The aircraft or propeller certification program should include all hardware and software substantiation requirements for the hardware and software that resides on the aircraft or propeller, including those that perform engine control functions. This includes environmental testing of all components and software quality assurance of the software that performs both the engine and airplane functions.
Page 44 Par 8-3
Appendix 1 APPENDIX 1. CERTIFICATION COMPLIANCE DOCUMENTS
The following is a representative summary of documents that an applicant may submit to show compliance to §33.28. Specific reciprocating engine EEC system certification programs may vary; not all documents in this list will apply to all programs.
Submitted Document Major Sections AC Chapter Reference 14 CFR § Instruction Manual • Description
• Installation
• Operation 3 33.28(a) Certification Data Interface Manual (CDID)
• Failure of Aircraft Power Analysis
• Failure of Aircraft Data Analysis
• EECSA Assumptions
• EECSA Results
• Environmental Testing
• Software Validation and Verification 3 33.28(a) Aircraft-Supplied Power Analysis 4 33.28(b) Aircraft-Supplied Data Analysis 4 33.28(b) EECSA Assumptions 5 33.28(c) EECSA Quantitative Analysis • Full-up System
• Degraded System 5 33.28(c) EECSA Qualitative Analysis • Alternate Control Mode Analysis
• Control Mode Transition
• EEC System Output Data Analysis
• Existing Subsystems Analysis
• Local Events Analysis
• Commercial or Industrial Grade Electronic Parts Analysis
• Programmed Logic Devices Analysis 5 33.28(c) Declared Component/System Environmental Limits
• Electrical
• Physical 6 33.28(d) Component/System Environmental Test Plans and Test Reports (Electrical)
• HIRF
• Lightning
• EMI 6 33.53
33.28(d)
Appendix 1
Submitted Document Major Sections AC Chapter Reference 14 CFR § Component/System Environmental Test Plans and Test Reports (Physical)
• High/Low/Room Temperature Demonstrations
• Contaminated Fluids Vibration
• Impact
• Sustained Acceleration
• Sand and Dust
• Fluid Susceptibility
• Salt Spray
• Induction Icing
• Fungus
• Temperature and Altitude
• Thermal Cycle
• Explosion Proofness
• Humidity
• Waterproofness
• Power Input 6 33.53
33.28(d) Plan for Software Aspects of Certification (ref. RTCA DO-178B)
7 33.28(e) Software Configuration Index (ref. RTCA DO-178B) 7 33.28(e) Software Accomplishment Summary (ref. RTCA DO-178B) 7 33.28(e) NOTE: Applicants should prepare all remaining Software Design Assurance documents in accordance with RTCA DO-178B and have them on file and available for FAA audit.
EEC System Integration Certification Plan (SICP) (if applicable)
• Distribution of Compliance Tasks
• Interface Definition & Other Data
• Design Change Control 8 33.28