CHAPTER 8. SECTION 33.28(f) – PROTECTION SYSTEMS.
8-1 Rule Text . Section 33.28(f) reads: “Protection Systems.
“(f) Protection Systems. (1) The design and functioning of engine control devices and systems, together with engine instruments and operating and maintenance instructions, must provide reasonable assurance that those engine operating limitations that affect turbine, compressor, fan, and turbosupercharger rotor structural integrity will not be exceeded in service.
(2) When electronic overspeed protection systems are provided, the design must include a means for testing, at least once per engine start/stop cycle, to establish the availability of the protection function. The means must be such that a complete test of the system can be achieved in the minimum number of cycles. If the test is not fully automatic, the requirement for a manual test must be contained in the engine instructions for operation.
(3) When overspeed protection is provided through hydromechanical or mechanical means, the applicant must demonstrate by test or other acceptable means that the overspeed function remains available between inspection and maintenance periods.”
8-2. Guidance: Protection Systems.
a. Rotor overspeed protection.
(1) In engines of recent design, the applicant usually provides overspeed protection, or circuits, or both, utilizing the engine control devices, systems and instruments referred to in §
33.28(f). Although they may be independent devices, the overspeed protection and circuits are generally part of the EECS
(2) Rotor overspeed protection is usually achieved by providing an independent overspeed protection system that requires two independent faults or malfunctions (as described below) to result in an uncontrolled overspeed. Examples of engine provided, as opposed to ECS provided, overspeed protection include blade shedding, rotor interference, or fuel cutoff methods through rotor axial movement. Engine-provided overspeed protection methods are addressed by § 33.27.
(3) The following guidance applies if the rotor overspeed protection is provided solely by an ECS protective function.
(a) In all dispatchable configurations, the combined engine control and overspeed protection system should be at least two independent faults removed from an uncontrolled overspeed event. Hence, a potential rotor burst due to overspeed should only be possible as a result of an independent fault preventing the overspeed protection system from operating properly in combination with a control system fault causing an overspeed.
(b) The SSA should show that the probability per engine flight hour of an uncontrolled overspeed condition from any cause in combination with a failure of the overspeed 31
protection system to function is less than one event per hundred million hours (a failure rate of 10 –8 events per engine flight hour). The SSA should consider all the failure cases associated with the protection systems. Do not overlook the following cases:
When the fuel metering valve and the fuel shut-off valve (SOV) have a common failure mode.
When the metering valve is proposed to be used as the shut-off valve. These single valve systems have been problematic at installation.
(c) The overspeed protection system should have a failure rate of less than 10 –4 failures per engine flight hour to ensure the integrity of the protected function.
(d) A self-test of the over-speed protection system to ensure its functionality prior to each subsequent flight is acceptable. Verifying the functionality of the overspeed protection system at engine shutdown and/or start-up is also acceptable to show compliance with this regulation’s once-per start-stop cycle requirement. Some engines may routinely not be shut down between landings. If the engine is not shutdown between two flights, test of the over-speed protection system is not required but should be accounted for in the SSA.
(e) Because some overspeed protection systems provide multiple protection paths, uncertainty that all paths are functional at any given time always exists. Where multiple paths can trigger the overspeed protection system, the applicant should perform a test of a different path for each engine start/stop cycle. Doing so will achieve a complete test of the overspeed system, including electro-mechanical parts, in the minimum number of engine cycles. We recommend that the number of cycles it takes to verify the overspeed protection system be consistent with the system achieving a 10-4 failure rate—or the probability of failure (per hour) over the length of time that it takes to complete the number of cycles. If the system meets a 10-4 failure rate, it will generally be found compliant.
(f) If an applicant chooses to implement overspeed protection with a mechanical or hydro-mechanical system, the regulation does not require that the system be tested at each start/stop cycle. However, the regulation does require that the overspeed protection system’s mechanical parts (not including the electro-mechanical parts) can operate without failure between inspection and maintenance periods. Therefore, we recommend that where a mechanical or hydro mechanical system is used, that applicants provide a rational maintenance interval/inspection plan to ensure that mechanical elements still perform their intended function and protect from a destructive overspeed.
b. Other protective functions.
(1) The ECS may perform other protective functions, only some of which may be engine functions (others may be aircraft or propeller functions). The integrity of other protective functions provided by the ECS should be consistent with a safety analysis associated with those functions. If those functions are not engine functions, they might not be part of engine certification.
(2) As ECSs become increasingly integrated into aircraft and propeller systems, they are implementing within the ECS, protective functions previously provided by the aircraft or propeller systems. Examples include:
Reducing the engine to idle thrust if a thrust reverser deploys; and Providing the auto-feather function for the propeller when an engine fails.
(3) The reliability and availability of these other protective functions should be consistent with the top-level hazard assessment of conditions involving these other protective functions. This assessment is usually completed during aircraft certification. For example, if an engine failure with loss of the auto-feather function is catastrophic at the aircraft level—and auto-feather is incorporated into the ECS—the applicant should show for part 23 or 25 installations, that an engine failure with loss of the auto-feather function cannot result from a single control system failure. Also, aircraft regulations may require that combinations of control system failures, or engine and control system failures, that lead to a significant engine loss of thrust or power with an associated loss of the auto-feather function have an extremely improbable event rate (10-9 events per engine flight hour).
(4) Although these other protective functions can be evaluated as a part of the aircraft level SSA, we recommend that applicants evaluate them during the engine certification process and present that as a part of engine certification. If the aircraft level hazard assessment involving these functions is available during engine certification, then coordination between the engine and aircraft certification teams will be smoother. If this coordination does not occur, then although the engine may be certified, it may not be installable at the aircraft level.
(5) The ECS safety assessment should include all failure modes of all functions incorporated in the system, including those functions that are added to support aircraft certification. Information on those failure modes will therefore, be properly addressed and passed on to the installer for inclusion in the airframe SSA. Information concerning the frequencies of occurrence of those failure modes is also needed.
CHAPTER 9. SECTION 33.28(g) - SOFTWARE.
9-1. Rule Text. Section 33.28(g) reads:
“(g) Software. The applicant must design, implement, and verify all associated software to minimize the existence of errors by using a method, approved by the FAA, consistent with the criticality of the performed functions.”
9-2. Guidance: Software.
a. Objective.
(1) Applicants should design their software to prevent logic errors that would result in an unacceptable effect on power or thrust or in other unsafe conditions. Because of the nature and complexity of systems containing digital logic, the applicant should develop software using a structured development approach, commensurate with the hazard associated with failure or malfunction of the system in which the digital logic is contained.
(2) Applicants may not be able to establish with certainty that their software design is without error. However, if applicants use the software design appropriate for the criticality of the performed functions, and an approved development method, the software satisfies the requirement to minimize errors. In some installations, the possibility of digital logic errors common to more than one ECS may determine the software level appropriate for the software design. However, we have not required channel-to-channel dissimilar designs when the software is designed as specified in Level A (DO-178B or C).
b. Approved methods. The primary FAA guidance on software methods is found in AC 20-115C. In addition, the FAA must also follow FAA order 8110.49. Acceptable methods for developing software comply with the guidelines of RTCA/DO-178C/EUROCAE ED-12C, hereafter referred to as DO-178B. The applicant may also propose alternative methods for developing software. However, any such alternate method is subject to approval by the Administrator. Reference AC 20-171 regarding alternative methods.
c. Use of supplements. DO-331, DO-332 and DO-333 are supplements that address certain software development techniques. Supplements add, delete, or modify objectives, activities, and life cycle data in DO-178C. You should apply the guidance within a particular supplement when you use the addressed technique. Your Plan for Software Aspects of Certification (PSAC) should identify which supplements apply and describe how you intend to use each applicable supplement. You cannot use supplements as stand-alone documents. Refer to AC20-115C paragraph 8 when using the supplements in conjunction with DO-178C.
d. Software levels.
(1) The level of software required for certification depends on the criticality of the functions it performs. For example, failures resulting in significant thrust or power increases or 34
oscillations may be more severe than an engine shutdown. Therefore, consider these failures when selecting a given software level.
(a) Design, implementation, and verification of software as specified in Level A (DO-178C) is normally needed for turbine engines.
(b) For a reciprocating engine EECS, software implemented as specified in Level C is the minimum acceptable requirement.
(c) The applicant may choose to evaluate the failure condition criticality of EECS functions to determine if Level B or C software would be adequate. The applicant must coordinate this evaluation with the aircraft designer and the cognizant aircraft ACO during the EECS development program.
(2) Applicants may protect or partition noncritical software from critical software and design and implement the noncritical software to a lower level. The applicant must demonstrate the adequacy of the partitioning method as well as the protection and isolation features needed to prevent corruption between the two levels of software. This demonstration should consider whether the protected/partitioned lower software levels are appropriate for any anticipated installations.
e. Legacy software. Software developed using DO-178, DO-178A, or DO-178B is referred to as legacy software. Refer to AC20-115C paragraph 9 when modifying and re-using software approved using DO-178, DO-178A, or DO-178B.
f. Onboard or field-loadable software and part number marking.
(1) When Field-Loadable Software (FLS) is used in EECS, and the applicant wants to use electronic part marking for the FLS, the FLS must meet the part marking requirements of § 45.15 (c). The information required, like that for a hardware part number, must be verifiable in the aircraft at any geographic location on the ground. Use the following guidelines and, for additional information, refer to FAA order 8110.49, Chapter 5, “Approval of Field-Loadable Software (FTS),” when onboard or field loading of EEC software and associated Electronic Part Marking is implemented. While the order is directed at the FAA certification engineer, the applicant is advised to much of the following material in 9-2 e. and its subparagraphs based on the Order’s requirements.
(2) For software changes, document the software to be loaded through an approved design change and a released service bulletin or other appropriate documentation.
(3) For an EECS unit with separate part numbers for hardware and software, the software part numbers need not be displayed on the unit as long as they are embedded in the loaded software, and can be verified by electronic means. When new software is loaded into the unit, the verification by electronic means requirement applies and the proper software part number must be verified before the unit is returned to service.
(4) For an EECS unit with only one part number, the one part number represents a combination of a software and hardware build. Applicants should change or update the unit part number on the nameplate when the new software is loaded. As a portion of this process the software build or version number should be verified before returning the unit to service.
(5) For an EECS that will be onboard or field loaded, you cannot use the configuration control system and electronic part marking unless it was approved at the time of engine certification. The drawing system must provide a compatibility table that tabulates the combinations of hardware part numbers and software versions that have been approved by the Administrator. The top-level compatibility table must be under configuration control, and the applicant must update it for each change that affects the hardware and software combination. The applicable service bulletin must define the hardware configurations with which the new software version is compatible.
(6) The loading system must be in compliance with the guidelines of DO-178C, Section 2.5.5. If the applicant proposes more than one source for loading, (such as disk, CD or mass storage), all sources must comply with these guidelines.
(7) The service bulletin must require verification that the correct software version has been loaded after installation on the aircraft.
g. Software Change Category. The processes and methods used to change software must not affect the design assurance level of that software.
(1) The determination of a major versus minor type-design change is established in § 21.93. A change to the software in an ECS may affect the reliability, operational characteristics, or other characteristics affecting the airworthiness of the product. Therefore, a change to the software is normally classified as major.
(2) The failure effect of EEC software is always assumed to be at least a major effect because an error could result in the total loss of thrust or power to all engines on an aircraft.
(3) Refer to FAA order 8110.49, particularly Chapter 11, “Oversight of Software Change Impact Analysis Used to Classify Software Changes as Major or Minor” for additional information.
h. Software Changes by Others than the Type Certificate (TC) Holder.
(1) Software changes by someone other than the original TC holder are generally not feasible. The applicant must address the approval process with the certification authority to determine feasibility.
(2) Two types of software changes that are feasible and can be implemented by someone other than the original TC holder are:
Changes to option-selectable software, or 36
Changes to user-modifiable software (UMS).
(a) Option-selectable software changes are implemented via precertified logic that uses a method of selection shown not to cause a control malfunction.
(b) User-modifiable software is software intended for modification by the aircraft operator without review by the certifying authority, the aircraft applicant, the engine manufacturer, or the equipment vendor. For ECSs, UMS has generally not been applicable.
However, if approval of UMS is required, it will be reviewed on a case-by-case basis.
1 The necessary guidance for UMS is contained in DO-178C, paragraph
2.5.2. The guidance allows non-TC holders to modify the software within the constraints defined by the TC holder if the system has been certified with the provision for software user modifications. Refer to FAA order 8110.49, particularly Chapter 7, “Approval of Airborne Systems and Equipment Containing User-Modifiable Software (UMS)” for additional information.
2 To certify an EECS with the provision for software modification by a non- TC holder, the TC holder must (1) provide the necessary information for approval of the design and implementation of a software change, and (2) demonstrate that the necessary precautions have been taken to prevent the user modification, regardless of whether it is implemented correctly, from affecting engine airworthiness.
3 When software is changed in a manner not allowed by the TC holder as “user modifiable,” the non-TC holder applicant must comply with all applicable requirements of part 33, particularly § 33.28, as well as the requirements in part 21, subpart E. Refer to FAA order 8110.49, particularly Chapter 7, “Approval of Airborne Systems and Equipment Containing User-Modifiable Software (UMS)” for additional information.
CHAPTER 10. SECTION 33.28(h) – AIRCRAFT-SUPPLIED DATA.
10-1. Rule Text. Section 33.28(h) reads:
“(h) Aircraft-supplied data. Single failures leading to loss, interruption or corruption of aircraftsupplied data (other than thrust or power command signals from the aircraft), or data shared between engines must:
(1) Not result in a hazardous engine effect for any engine, and
(2) Be detected and accommodated. The accommodation strategy must not result in an unacceptable change in thrust or power or an unacceptable change in engine operating and starting characteristics. The applicant must evaluate and document in the engine installation instructions the effects of these failures on engine power or thrust, engine operability, and starting characteristics throughout the flight envelope.”
10-2. Guidance: Aircraft-Supplied Data.
a. Objective. The EECS should be self-sufficient and isolated from other aircraft systems, or provide redundancy that enables it to accommodate aircraft data system failures. In the case of loss, interruption, or corruption of aircraft-supplied data, the engine must continue to function in a safe and acceptable manner, without unacceptable effects on thrust or power, hazardous engine effects, or loss of ability to comply with the operating regulations of §§ 33.65 and 33.89, as appropriate. The single failure requirement applies to all dispatchable configurations of the engine control and aircraft air data systems.
b. Background.
(1) Reciprocating engines with EECS are not considered “conventional reciprocating engines.” For conventional reciprocating engines, magneto ignition and mechanical fuel systems can accommodate single failures leading to loss, interruption or corruption of aircraft-supplied data or data shared between engines. Therefore, further guidance is not necessary concerning conventional reciprocating engines.
(2) For reciprocating engines with EECS, any LOPC event is an unacceptable change in power. Therefore, as required by § 33.28 (h)(2), the applicant should show that the failure of aircraft-supplied data does not cause a LOPC.
(3) Aircraft-supplied data failures that result in engine effects less severe than a LOPC, such as a minor power loss, are typically considered to be acceptable changes in power. The analyses and the engine installation and operating instructions should identify these types of events along with their effects on engine operation if the effect of the event can be observed by the flight crew. This data can also be used in the powerplant installation safety analysis required during airplane certification to evaluate the impact of these failures on airplane operations.
(4) Previous regulatory practice preserved the independence of the engine from the aircraft. Hence, even with very reliable architectures, such as triplex air data computer (ADC) systems, the ECS provided an independent control that crews could use to safely fly the aircraft should all the ADC signals be lost. With the increased engine-aircraft integration currently occurring in the aviation industry, and with the improvement in reliability and implementation of aircraft-supplied data, the new requirement is that the ECS provide fault accommodation against single failures of aircraft-supplied data for which such accommodation is possible.
c. Design Assessment.
(1) As part of their compliance plan, applicants should provide an analysis, based on component, system, or engine testing, that shows they adequately evaluated the impact of a failure of aircraft data on the engine’s performance and operability throughout the aircraft flight envelope. This failure analysis should address all allowable engine control and aircraft dispatch configurations in which failure of aircraft data in that dispatch configuration would impact ECS response. “Failure of aircraft data,” includes airplane system failure events that either prevent data from being transmitted or result in the transmission of incorrect data. This analysis should include:
(a) Their evaluation of the engine control responses to aircraft data inputs, including an evaluation of the effect on the EECS of faulty and corrupted aircraft-supplied data.
(b) An evaluation of the potential for common mode faults affecting operation of more than one engine in EEC systems intended for installation on multiengine airplanes. 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.
Examples of potential common mode faults that the analysis should address include:
1 A single erroneous data source transmitted from the aircraft to multiple engines and their associated EEC systems (for example, air data sources or auto throttle systems), 2 Control system operating faults spread through data links between engines (for example, maintenance recording, common bus, cross-talk, or automatic power reserve system), and 3 Loss or interruption of aircraft data used by the engine control when that loss or interruption is caused by the failure of another engine.
(c) An evaluation of the EECS fault accommodation logic for coverage of aircraftsupplied data failures. Applicants should conduct testing or analysis on the fault accommodated control mode to establish that the engine operating characteristics comply with all operability requirements of part 33. The applicant may incorporate precautions for addressing common effects in the aircraft system architecture or in the EECS itself.
(2) When the particular aircraft air data failure mode(s) are unknown, the engine applicant should assume typical failure modes for loss of data and erroneous data. The engine applicant should assume that erroneous data is being transmitted to the EECS and identify for the installer the impact of this data on engine operation.
(3) The applicant may use any number of tools and techniques to assess and to shape the design of the ECS and its interface with the aircraft data systems. One example is the use of a Fault Accommodation chart and Markov Modeling, wherein applicants define the fault accommodation architecture for the aircraft-supplied data.
(4) If the ECS relies entirely on aircraft air data to complete any of its critical control functions, then the aircraft air data system becomes an element of the ECS. To maintain compliance to § 33.28, the applicant must require via the installation, or the operating instructions, or both that:
(a) The aircraft air data system is unaffected by a complete loss of aircraft generated power (for example, the air data system is backed up by battery power).
(b) No common mode faults exist where multiple incorrect, but valid, signals are transmitted to the EECS (for example, dedicated sensor(s) and pneumatic lines for each air data computer).
(5) The ECS’s LOTC/LOPC analysis should also analyze the effects of air data system failures in all allowable ECS and air data system dispatch configurations.
(6) Elements of the ECS, such as a throttle position transducer, may be mounted in the aircraft and not part of the engine type design but dedicated to the ECS and powered by it. Such elements are an integral component of the EECS, and are not considered aircraft data. The applicant should include failures in the throttle position sensing system and thrust command system in their engine LOTC/LOPC analysis.
(7) When aircraft-supplied data can affect ECS operation, the applicant should address the effects of faulty and corrupted aircraft-supplied data on the EECS, as applicable, in the SSA or other appropriate documents.
d. Accommodation. Even with a redundant, multipath aircraft air data system, the EECS should incorporate appropriate accommodation features. These features should retain a thrust or power modulation capability for complete loss of all aircraft environmental (i.e., speed, altitude, temperature data) information. The following are examples of possible means of accommodation:
(1) Implementation of an alternate mode that is independent of aircraft-supplied data.
(2) Dual sources of aircraft-supplied sensor data with local engine sensors providing data as alternate sources. This local engine sensor can be used to aid in the selection of the 40
correct aircraft-supplied data. The local engine sensor used in this selection is often called a voter.
(3) Use of synthesized engine parameters to control or act as voters. When synthesized parameters are used for control or voting purposes, the SSA should consider the impact of temperature and other environmental effects on sensors whose data are used in the synthesis. Also, applicants should assess any data tolerances necessary to correlate the data from the sensors used in the synthesis and the parameters being synthesized.
(4) Triple redundant ADC systems that provide the required data.
e. Effects on the engine. Applicants should ensure that their ECS system is capable of ensuring that the engine provides the declared minimum rated thrust or power throughout the engine operating envelope. The effects of failures in aircraft-supplied data must be documented in the SSA as described in Chapter 7 of this AC.
f. Validation.
(1) Applicants should demonstrate by test, analysis, or a combination thereof, that their ECS fault accommodation logic continues to successfully manage engine performance when the aircraft air data system is not functional.
(2) Applicants should also show that for all dispatchable control modes that involve aircraft data, the next single fault in the EECS does not lead to a hazardous engine effect.
(3) When the alternate mode is intended to be a dispatchable mode, applicants should demonstrate that the ECS continues to successfully meet the engine and aircraft certification basis when operating in this alternate mode, and the aircraft air data system is not functional. The objective here is to assure that a dispatchable alternate mode does not lead to a hazardous engine effect when there is a subsequent loss of aircraft air data. The instructions for installation should include characteristics of operation in this alternate mode, even if it is a nondispatchable mode.
g. Installation requirements. As a result of increasing levels of integration between aircraft systems and ECSs, engine applicants should show that their installation instructions provide guidance with certain aspects of the data interface during the integration of the engine.
“Certain aspects” includes ensuring that the engine continues to meet its certification basis when installed. This means that the engine applicant should state in the engine installation instructions that the installer is responsible for ensuring that:
(1) The software in the data path to the EECS is at a level consistent with how the aircraft data is used by the EECS, as described and analyzed in the EECS’s SSA, and
(2) The impact of the engine responses are included in the aircraft’s SSA as the data path may include other aircraft equipment, such as aircraft thrust management computers, or other avionics equipment, and 41
(3) The effects of faulty or corrupted aircraft-supplied data on the EECS are addressed in the aircraft SSA, and
(4) Those sensors and equipment involved in delivering information to the EECS continue to operate properly when exposed to EMI, HIRF and lightning, and
(5) The reliability level for the aircraft-supplied data is no worse than that used as part of the EEC’s SSA and LOTC/LOPC analysis, and
(6) Any assumptions made during the ECS design assessment regarding the reliability or configuration of the aircraft systems are appropriate, and thus the results of the evaluation of erroneous aircraft data as documented in the SSA are also appropriate.
h. Thrust and power command signals.
(1) Thrust and power command signals sent from the aircraft are unique and are not subject to the regulations of § 33.28(h).
(2) Some aircraft thrust or power command systems are configured to move the engine thrust or power levers or transmit an electronic signal to command a thrust or power change.
When so configured, the ECS merely responds to the command and changes engine thrust or power as appropriate. In these cases, other than input range or data validity checks, the ECS should not attempt to differentiate between correct or erroneous throttle or power lever commands. For EEC systems in which the throttle or power lever command system is not included in the EEC system design, do not include thrust and power command signals sent from the aircraft in the evaluation required by § 33.28(h)(2).
(3) For EEC systems in which the power lever command is included in the EEC system design to be certificated under part 33, we recommend including the thrust and power command signals in the analysis.
(4) In both moving and non-moving throttle (or power lever) configurations, the installer should ensure that a proper functional hazard analysis is performed on the aircraft system involved in generating engine thrust or power commands. The installer should also ensure that the system meets the appropriate aircraft functional hazard assessment safety related regulations. This should be shown at aircraft certification. However, failures in the throttle position sensing system and thrust command system must be included in the LOTC/LOPC analysis of the engine as defined in the LOTC/LOPC analysis system description.