CHAPTER 7. SECTION 33.28(e) – SYSTEM SAFETY ASSESSMENT.
7-1. Rule Text. Section 33.28(e) reads: “(e) System safety assessment. When complying with this section and 33.75, the applicant must complete a System Safety Assessment for the engine control system. This assessment must identify faults or failures that result in a change in thrust or power, transmission of erroneous data, or an effect on engine operability producing a surge or stall together with the predicted frequency of occurrence of these faults or failures.”
7-2 Guidance: System Safety Assessment . Refer to Appendix 3 “Guidance for System Safety Assessment for EECS Applied to Reciprocating Engines.”
a. Scope of the assessment. The methods presented in ARP4761 for conducting safety assessment are recognized for ECS assessments.
(1) The SSA required under § 33.28 (e) must address all operating modes.
(2) The LOTC/LOPC analysis described in § 33.28(d) is a subset of the SSA. The LOTC/LOPC analysis and SSA may be separate or combined as a single analysis. For clarity, the remainder of the discussion mentions only the SSA, but it is equally applicable to an LOTC/LOPC analysis or combined SSA/LOTC/LOPC analysis.
(3) The SSA must consider all faults, both detected and undetected, and their effects on the ECS and engine operation. The SSA must also include faults or malfunctions in aircraft signals, including electrical opens, shorts, data validation, signal input errors and any other malfunction defined by the installer. These malfunctions should include those in a multiengine aircraft installation that could affect more than one engine. These types of faults are addressed under § 33.28(h).
(4) The ECS SSA should identify the applicable assumptions and installation requirements. It should also establish any limitations relating to ECS operation. These assumptions, requirements, and limitations should be stated in the engine installation and operating instructions, as appropriate.
(5) As necessary, the airworthiness limitations section of the instructions for continued airworthiness should include the limitations related to the ECS operation. For example, the LOTC/LOPC analysis may classify faults into various categories that may require repair within an approved time frame. Refer to SAE ARP5107B for additional information.
(6) The SSA must address all failure effects identified under § 33.75, as appropriate.
The applicant may reference the § 33.75 analysis in this SSA when appropriate.
(7) The applicant must provide a summary listing the malfunctions or failures and their effects caused by the ECS, such as:
(a) Failures affecting power or thrust resulting in LOTC/LOPC events.
(b) Failures that result in the engine’s inability to meet the operability regulations.
If these failure cases are not considered LOTC/LOPC events according to the criteria of Chapter 6, then document the expected frequency of occurrence for these events.
(c) Transmission of erroneous parameters, for example; false high indication of the thrust or power setting that could lead to thrust or power changes greater than 3% of take-off power, or thrust, or both, (10% for reciprocating engines installations), or high exhaust gas temperature or turbine temperatures, or low-oil pressure that could lead to engine shutdown.
These levels have typically been considered unacceptable, however, applicants may propose different levels for a specific engine.
(d) Failures affecting aircraft functions included in the ECS, for example, propeller control, thrust reverser control, control of cooling air, or control of fuel recirculation.
(e) Failures resulting in major engine effects and hazardous engine effects. In addition, reciprocating engine applicants must address failures resulting in destructive events.
(8) The SSA should also consider all signals used by the ECS, particularly any crossengine control signals and air pressure signals as described in § 33.28(j).
(9) The SSA should include functions implemented in the ECS that involve aircraft level functions. The aircraft applicant needs to define the criticality of aircraft level functions.
b. Criteria. The SSA should demonstrate or provide the following:
(1) Compliance with §§ 33.75, as appropriate.
(2) For failures leading to LOTC/LOPC events, Chapter 6, paragraph 6-2.d., provides guidance on compliance with the agreed LOTC/LOPC rate for the intended installation.
(3) For failures affecting engine operability but not necessarily leading to LOTC/LOPC events, only the rate of occurrence of the faults that could lead to an operability limitation should be documented. Any aircraft flight deck indications deemed necessary to inform the flight crew of such a failure will be determined at aircraft certification.
(4) The applicant must identify the consequences of the transmission by the ECS of a faulty parameter that is not indicated or identified as failed or faulty. If the consequence can result in loss of the ability to set power, then that fault should be included in the LOTC/LOPC analysis. The engine operating instructions should include any information necessary to mitigate the consequences of a detected faulty parameter transmission. For example, the engine operating instructions may indicate that a display of zero oil pressure may be ignored in flight if the oil quantity and temperature displays appear normal. In this situation, failure to transmit oil pressure or transmitting a zero oil pressure signal should not lead to an engine shutdown or LOTC/LOPC event.
(5) Flight crew initiated shutdowns have occurred in-service as the result of failure conditions, such as the ECS transmitting a faulty parameter. If the engine operating instructions provide information to mitigate this failure condition, then control system faults or malfunctions leading to the failure condition would not have to be included in the LOTC/LOPC analysis. In the case of the ECS transmitting faulty parameters, the loss of multiple functions should be included in the LOTC/LOPC analysis. For example, if the display of zero oil pressure and zero oil quantity (or high oil temperature) would result in a crew-initiated shutdown, then the applicant should include those failures in the systems LOTC/LOPC analysis.
c. Malfunctions or faults affecting thrust or power.
(1) In multiengine aircraft, faults that result in thrust or power changes of less than approximately 10% of take-off power or thrust, may be undetectable by the flight crew. This level is based on pilot assessment and has been used for a number of years. Pilots have indicated that flight crews will note engine operating differences when the difference is greater than 10% in asymmetric thrust or power. A thrust change larger than 10% of take-off power or thrust, may be acceptable if authorized by the installer.
(2) Engine applicants and the installer should agree on the detectable difference level for engines for other installations. This is important as the installation can significantly affect the pilot’s ability to detect the operating difference between engines. If the pilot cannot detect this difference and take appropriate action, the result may be hazardous to the aircraft.
(3) When operating in the take-off envelope, uncovered faults in the ECS that result in a thrust or power change of less than 3% (10% for reciprocating engines installations) are generally considered acceptable. However, this does not diminish the applicant’s obligation to ensure that the full-up system is capable of providing the declared minimum rated thrust or power. In this regard, faults that could result in small thrust changes should be random in nature and detectable and correctable during routine inspections, overhauls, or power-checks.
(4) The SSA documentation should include the frequency of occurrence of uncovered faults that result in a thrust or power change greater than 3% of take-off power, or thrust, but less than the change defined as an LOTC/LOPC event. No specific regulations relating to this class of faults for engine certification exist. However, the rate of occurrence of these types of faults should be reasonably low. We recommend on the order of 10-5 events per engine flight hour or less. Documentation of these faults may be required in the aircraft certification analysis.
(5) Signals sent from one ECS to another, such as signals used for an ATTCS, APR or synchrophasing, are addressed under § 33.28(h). These cross-engine signals should be limited in authority by the receiving ECS, so that undetected faults do not result in an unacceptable change in thrust or power for the engine using those signals. The maximum thrust or power loss on the engine using a cross-engine signal should generally be limited to 3% absolute difference of the current operating condition. The ATTCS or APR, when activated, may command a thrust or power increase of 10% or more on the remaining engine(s). These thrust and power losses do not have to be considered LOTC/LOPC events. In addition, in a rotorcraft installation, signals sent 29
from one engine control to another, such as load sharing and OEI, can have a much greater impact on engine power when those signals fail. However, data on these failure modes should be in the SSA.
(6) When operating in the take-off envelope, detected faults in the ECS, that result in a thrust or power change of up to 10% (15% for reciprocating engines), may be acceptable if the total frequency of occurrence for these types of failures is relatively low. A thrust change larger than 10% (15% for reciprocating engines) of take-off power, or thrust, may be acceptable if authorized by the installer. The predicted frequency of occurrence for this category of faults should be in the SSA documentation. Requirements for the allowable frequency of occurrence for this category of faults and any need for a flight deck indication of these conditions are reviewed during aircraft certification. A total frequency of occurrence of less than of 10 –5 events per engine flight hour would normally be acceptable, as the occurrence of this on multiple engines would be an extremely remote event.
(7) Detected faults in signals exchanged between ECSs should be accommodated so as not to result in greater than a 3% thrust or power change on the engine using the cross-engine signals.
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.