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.
CHAPTER 11. SECTION 33.28(i) – AIRCRAFT-SUPPLIED ELECTRICAL POWER
11-1. Rule Text. Section 33.28(i) reads: “(i) Aircraft-supplied electrical power. (1) The applicant must design the engine control system so that the loss, malfunction, or interruption of electrical power supplied from the aircraft to the engine control system will not result in any of the following:
(i) A hazardous engine effect, or
(ii) The unacceptable transmission of erroneous data.
(2) When an engine dedicated power source is required for compliance with paragraph (i)(1) of this section, its capacity should provide sufficient margin to account for engine operation below idle where the engine control system is designed and expected to recover engine operation automatically.
(3) The applicant must identify and declare the need for, and the characteristics of, any electrical power supplied from the aircraft to the engine control system for starting and operating the engine, including transient and steady state voltage limits, in the engine installation instructions.
(4) Low voltage transients outside the power supply voltage limitations declared in paragraph (i)(3) of this section must meet the requirements of paragraph (i)(1) of this section.
The engine control system must be capable of resuming normal operation when aircraft-supplied power returns to within the declared limits.”
11-2. Guidance: Aircraft-Supplied EECS Electrical Power.
a. The most common means of providing electrical power to an EECS has been an enginemounted alternator. An EECS dedicated engine-mounted alternator is not subject to the typical interruptions and power transients present in the aircraft power systems. In addition, this configuration is typically single-electric fault tolerant including common cause/mode electric fault tolerant. However, other options do exist, and are discussed below.
(1) Batteries. Batteries are not generally an acceptable aircraft-supplied power source, particularly for turbine engine aircraft, as they are unable to satisfy the reliability needs for the EECS. For reciprocating engines, however, an ECS dedicated battery may be acceptable. If an applicant proposes a battery as an EECS dedicated power source, the applicant should in the engine installation instructions, identify battery health, status, and maintenance requirements.
(2) Self-contained electrical power systems. This type of system is an integral part of the engine design. The self-contained reference may be only applicable to the critical functions of the ECS. It is both functionally and physically isolated from the aircraft electrical power system. This is acknowledging that there are means other than an alternator that may be used.
However, an engine driven alternator based system does fit into this type of system.