MOC VTOL.2510 Equipment, systems, and installations

1.      Purpose

This MOC describes an accepted means for showing compliance with the requirements VTOL.2510(a) and VTOL.2510(b). These means are intended to supplement the engineering and operational judgement that should form the basis of any compliance demonstration.

Whilst this MOC details “what” should be addressed for showing compliance with the requirement VTOL.2510(a), it does not provide detailed guidance on the implementation of development assurance and safety assessment processes. Detailed guidance and recommended practices may be found in the standards that are recognised through the list of reference documents in §3 below.

In general, the extent and structure of the analyses required to show compliance with VTOL.2510(a) and VTOL.2510(b) will be greater when the system is more complex and the effects of the Failure Conditions are more severe.

2.      Applicability

As specified in VTOL.2500(a), paragraph VTOL.2510 is intended as a general requirement that should be applied to any equipment or system as installed, in addition to specific systems requirements, considering the following:

(a)      General - If a specific SC VTOL requirement exists which predefines systems safety aspects (e.g., redundancy level or criticality) for a specific type of equipment, system, or installation, then the specific SC VTOL requirement will take precedence. This precedence does not preclude accomplishment of a system safety assessment. For example, requirement VTOL.2430 predefines a required level of redundancy in the energy storage and distribution systems.

(b)     Subpart B, C and D - While VTOL.2510 does not apply to the performance and flight characteristics of Subpart B and structural requirements of Subparts C and D, it does apply to any system on which compliance with any of those requirements is based. For example, it does not apply to an aircraft's inherent stall characteristics, but it does apply to a stall warning system used to enable compliance with VTOL.2150.

(c)      Subpart E - In certain VTOL configurations, the lift/thrust system is closely integrated with other systems, such as the flight control system, and will also affect “continued safe flight and landing” or the “controlled emergency landing”. Therefore the “lift/thrust control systems” and “lift/thrust system installation hazard assessment” will be addressed through the requirements VTOL.2500 and VTOL.2510 of Subpart F.

This MOC does not cover “Airworthiness Security” aspects. Interactions and interfaces between the system safety assessment process and the security assessment process exist however. Therefore, should a function be implemented or a system/equipment installed on the aircraft as a result of the airworthiness security assessment process, this function or system/equipment needs to undergo the system safety assessment process.

3.      Reference Documents

The following references are quoted in different sections of this MOC as a source of additional guidance:

(a)      EUROCAE ED-79A/ARP4754A, Guidelines for development of civil aircraft and systems

(b)     SAE ARP4761, Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment.

(c)      AMC 20-115( ), Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178.

(d)     AMC 20-152( ), Development Assurance in Airborne Electronic Hardware (AEH)

(e)     AMC 20-189( ), Management of Open Problem Reports.

(f)      AMC 25-19 Amdt. 24, Certification Maintenance Requirements

4.      Definitions

(a)      Complexity: An attribute of functions, systems or items which makes their operation, failure modes or failure effects difficult to comprehend without the aid of analytical methods. (Source: ED-79A/ARP4754A).

(b)     Continued Safe Flight and Landing: see MOC to VTOL.2000 Applicability and definitions.

(c)      Controlled emergency landing: see MOC to VTOL.2000 Applicability and definitions.

(d)     Commercial-Off-The-Shelf (COTS) software:  Commercially available applications that are sold by vendors through public catalogue listings. COTS software is not intended to be customised or enhanced. Contract-negotiated software developed for a specific application is not COTS software (Source: ED-12C/DO-178C).

(e)     Derived requirements: Additional requirements resulting from design or implementation decisions during the development process which are not directly traceable to higher-level requirements and/or specify behaviour beyond that specified by the higher level requirements (Source: adapted from  ED-79A/ARP4754A and ED-12C/DO-178C).

(f)      Development Assurance: All of those planned and systematic actions used to substantiate, at an adequate level of confidence, that errors in requirements, design and implementation have been identified and corrected such that the system satisfies the applicable certification basis. (Source: ED-79A/ARP4754A).

(g)      Development Assurance Level (DAL): the level of rigor of development assurance tasks necessary to demonstrate compliance with paragraphs VTOL.2500 and VTOL.2510 (Source: adapted from ED79A/ARP4754A). The DALs are determined by the system safety assessment process.

Two types of development assurance levels are identified in this document:

(1)     FDAL: Development Assurance Levels for aircraft functions, systems and equipment

(2)     IDAL: Development Assurance Levels for software and electronic hardware items

(h)     Error: An omission or incorrect action by a flight crew member or maintenance personnel, or a mistake in requirements, design, or implementation.

Note: Errors may cause failures, but are not considered to be failures (Source: adapted from AMC 25.1309 in Book 2 of CS-25 Amdt. 24).

(i)      Event: An occurrence which has its origin distinct from the aircraft, such as atmospheric conditions (e.g. gusts, temperature variations, icing and lightning strikes)    , runway conditions, conditions of communication, navigation, and surveillance services, bird-strike, payload fire. The term is not intended to cover sabotage. (Source: adapted from AMC 25.1309 in Book 2 of CS-25Amdt. 24)

(j)      Failure: An occurrence that affects the operation of a component, part, or element such that it can no longer function as intended (this includes both loss of function and malfunction). (Source: adapted from AMC 25.1309 in Book 2 of CS-25 Amdt. 24)

(k)      Failure Condition: A condition having an effect on the aircraft, its occupants and/or third parties, either direct or consequential, which is caused or contributed to by one or more failures or errors, considering flight phase and relevant adverse operational or environmental conditions, or external events. (Source: adapted from AMC 25.1309 in Book 2 of CS-25 Amdt. 24)

(l)      Latent failure: A failure is latent until it is made known to the flight crew or maintenance personnel. (Source: adapted from AMC 25.1309 in Book 2 of CS-25 Amdt. 24)

(m)    Malfunction: Failure of a system, subsystem, unit, or part to operate in the normal or usual manner. The occurrence of a condition whereby the operation is outside specified limits. (Source: AC 23.1309-1E)

(n)     Open-source software: describes software that comes with permission to use, copy and distribute, either as is or with modifications, and that may be offered either free or with a charge. The source code should be available. (Source: Gartner)

(o)     Significant latent failure: A significant latent failure is one, which would in combination with one or more specific failures, or events result in a Hazardous or Catastrophic Failure Condition. (Source: adapted from AMC 25.1309 in Book 2 of CS-25 Amdt. 24).

5.      Abbreviations

(a)      AEH – Airborne Electronic Hardware

(b)     COTS – Commercial Of The Shelf

(c)      CMA – Common Mode Analysis

(d)     (F)/(I)DAL – Function / Item Development Assurance Level

(e)     PRA – Particular Risk Analysis

6.      Principles of Fail-Safe design concept

The requirements of SC-VTOL incorporate the objectives and principles or techniques of the fail-safe design concept, which considers the effects of failures and combinations of failures in defining a safe design.

(a)      The following basic objectives pertaining to failures apply:

(1)     In any system or subsystem, the failure of any single element, component, or connection during any one flight should be assumed, regardless of its probability. Such single failures should not be catastrophic.

(2)     Subsequent failures of related systems during the same flight, whether detected or latent, and combinations thereof, should also be considered.

(b)     The fail-safe design concept uses the following design principles or techniques in order to ensure a safe design. The use of only one of these principles or techniques is seldom adequate. A combination of two or more is usually needed to provide a fail-safe design, i.e. to ensure that major failure conditions are remote, hazardous failure conditions are extremely remote, and catastrophic failure conditions are extremely improbable:

(1)     Designed Integrity and Quality, including Life Limits, to ensure intended function and prevent failures.

(2)     Redundancy or Backup Systems to enable continued function after any single (or other defined number of) failure(s); e.g. two or more engines, hydraulic systems, flight control systems, etc.

(3)     Isolation and/or Segregation of Systems, Components, and Elements so that the failure of one does not cause the failure of another.

(4)     Proven Reliability so that multiple, independent failures are unlikely to occur during the same flight.

(5)     Failure Warning or Indication to provide detection.

(6)     Flight Crew Procedures specifying corrective action for use after failure detection.

(7)     Checkability: the capability to check a component's condition.

(8)     Designed Failure Effect Limits, including the capability to sustain damage, to limit the safety impact or effects of a failure.

(9)     Designed Failure Path to control and direct the effects of a failure in a way that limits its safety impact.

(10)   Margins or Factors of Safety to allow for any undefined or unforeseeable adverse conditions.

(11)   Error-Tolerance that considers adverse effects of foreseeable errors during the VTOL capable aircraft’s design, test, manufacture, operation, and maintenance.

7.      Failure conditions classifications and probability terms

(a)      Failure Conditions Classifications.

Failure Conditions are classified according to the severity of their effects as follows:

(1)     No Safety Effect: Failure Conditions that would have no effect on safety; for example, Failure Conditions that would not affect the operational capability of the aircraft or increase crew workload.

(2)     Minor: Failure Conditions which would not significantly reduce aircraft safety, and which involve crew actions that are well within their capabilities. Minor Failure Conditions may include, for example, a slight reduction in safety margins or functional capabilities, a slight increase in crew workload, such as routine flight plan changes, or some physical discomfort to passengers.

(3)     Major: Failure Conditions which would reduce the capability of the aircraft or the ability of the crew to cope with adverse operating conditions to the extent that there would be, for example, a significant reduction in safety margins or functional capabilities, a significant increase in crew workload or in conditions impairing crew efficiency, physical distress to occupants, possibly including injuries, or physical discomfort to the flight crew.

(4)     Hazardous: Failure Conditions, which would reduce the capability of the aircraft or the ability of the crew to cope with adverse operating conditions to the extent that there would be:

(i)      a large reduction in safety margins or functional capabilities, or

(ii)     physical distress or excessive workload such that the flight crew’s ability is impaired to where they could not be relied on to perform their tasks accurately or completely, or

(iii)     for Category Enhanced, possible serious injury to an occupant other than the flight crew, but no fatality reasonably expected, or

(iv)     for Category Basic, serious or fatal injury to an occupant other than the flight crew.

(5)     Catastrophic:

(i)      For Category Enhanced, failure conditions, which are expected to result in one or more fatalities, or incapacitation of a flight crew member, usually with the loss of the aircraft. Failure conditions that would prevent continued safe flight and landing of the aircraft are also considered catastrophic.

(ii)     For Category Basic, failure conditions, which are expected to result in multiple fatalities, or incapacitation or fatal injury to a flight crew member, usually with the loss of the aircraft. Failure conditions that would prevent a controlled emergency landing of the aircraft are also considered catastrophic.

When referring to “fatalities”: passengers, flight crew and people on ground are considered.

(b)     Qualitative Probability Terms.

When using qualitative analyses to determine compliance with VTOL.2510(a), the following descriptions of the probability terms used in VTOL.2510 and this MOC have become commonly accepted as aids to engineering judgment:

(1)     Probable Failure Conditions are those that are anticipated to occur one or more times during the entire operational life of each aircraft.

(2)     Remote Failure Conditions are those that are unlikely to occur to each aircraft during its total life, but which may occur several times when considering the total operational life of a number of aircraft of the type.

(3)     Extremely Remote Failure Conditions are those that are not anticipated to occur to each aircraft during its total life but which may occur a few times when considering the total operational life of all aircraft of the type.

(4)     Extremely Improbable Failure Conditions are those so unlikely that they are not anticipated to occur during the entire operational life of all aircraft of one type.

8.      Safety Objectives

The objective of VTOL.2510(a) is to ensure an acceptable safety level for equipment and systems as installed on the aircraft. A logical and acceptable inverse relationship must exist between the average probability per flight hour and the severity of failure condition effects.

(a)      Safety Objectives per aircraft category and failure condition classification:

The safety objectives for each failure condition are:

Table 5: Safety Objectives

Note A: no considerations of the system architecture for a DAL reduction are acceptable, as the FDAL classification already constitute a proportionate approach. 

Note B: Alleviation in software development assurance for IDAL D as per section 10(c) is possible.

Note C: It is recognised that, for various reasons, component failure rate data may not be precise enough to enable accurate estimates of the probabilities of Failure Conditions. This results in some degree of uncertainty. When calculating the estimated probability of each Failure Condition, this uncertainty should be accounted for in a way that does not compromise safety.

Note D: The applicant is not expected to perform a quantitative analysis for minor failure conditions.

Note E: An average flight profile (including flight phases duration) and an average flight duration should be defined.

(b)     Single failure and common cause failure considerations:

According to VTOL.2510(a)(1), a catastrophic failure condition must not result from the failure of a single component, part, or element of a system. Failure containment should be provided by the system design to limit the propagation of the effects of any single failure to preclude catastrophic failure conditions. In addition, there must be no common-cause failure, which could affect both the single component, part, or element, and its failure containment provisions. A single failure includes any set of failures, which cannot be shown to be independent from each other. Common-cause failures (including common mode failures) and cascading failures should be evaluated as dependent failures from the point of the root cause or the initiator. Errors in development, manufacturing, installation, and maintenance can result in common-cause failures (including common mode failures) and cascading failures. They should, therefore, be assessed and mitigated in the frame of the common –cause and cascading failures consideration.

Protection from multiple failures should be provided when the first failure would not be detected during normal operations of the aircraft, which includes pre-flight checks.

Sources of common cause and cascading failures include development, manufacturing, installation, maintenance, shared resource, event outside the system(s) concerned, etc. The ARP4761 describes types of common cause analyses, which may be conducted, to ensure that independence is maintained (e.g. particular risk analyses, zonal safety analysis, common mode analyses), see also Section 9(b).

While single failures should normally be assumed to occur, experienced engineering judgment and relevant service history may show that a catastrophic failure condition by a single failure mode is not a practical possibility. The logic and rationale used in the assessment should be so straightforward and obvious that the failure mode simply would not occur unless it is associated with an unrelated failure condition that would, in itself, be catastrophic.

Analyses should always consider the application of the fail-safe design concept as described in section 6, and give special attention to ensuring the effective use of design techniques that would prevent single failures or other events from damaging or otherwise adversely affecting more than one redundant system channel or more than one system performing operationally similar functions

Early coordination with the Agency on these aspects is advised.

9.      Safety assessment process

(a)      Overview

The Safety Assessment process aims at demonstrating that systems and components are designed and installed in a way that occurrence probabilities of failure conditions are commensurate with their classification and that no catastrophic failure condition results from a single failure. It consists of several objectives, listed below in no particular order:

(1)     Examine aircraft and system functions to identify potential functional failures and classify the hazards associated with specific failure conditions.

(2)     Establish the safety requirements for the aircraft, its systems and items and validate these safety requirements.

(3)     Verify that system architecture and design meets the corresponding safety requirements and the safety objectives, including the single failure criterion.

(4)     Establish and verify physical and functional separation, isolation and independence requirements between systems and items, and verify that these requirements have been met.

Guidance on how to perform the Safety Assessment process can be found in ED-79A/ARP4754A and ARP4761. The applicant may propose other guidance for the Safety Assessment process, which should be agreed with the Agency in conjunction with the overall proposed Development Assurance process.

The depth and scope of the analyses are dependent on the system criticality and/or complexity.

The safety assessment process is an iterative process, requiring preliminary assessment steps to ensure that the proposed system architecture(s) can reasonably be expected to meet the safety objectives, as well as regular coordination with the Agency on the different process steps.

When identifying the aircraft and system functions and classifying the hazards associated with the Failure Conditions, the applicant will have to substantiate the effects of failure conditions with consideration to operational conditions and events. Guidance on the handling qualities assessment can be found in MOC VTOL.2135.

Any assumptions made during the safety assessment process need to be justified and validated.

(b)     Common mode considerations

Common mode analysis (CMA) is an analytical method to define independence principles and associated requirements, and verify that those independence requirements have been implemented sufficiently. The CMA serves also as a tool to identify any lack of independence and to develop mitigation means to reduce the likelihood or the effect of a common mode failure resulting from a lack of independence.

The CMA should be performed early in the safety assessment process, because it has an impact on the definition of the safety requirements as well as on the system architecture.

Sources of common mode failures include development, manufacturing, installation, maintenance, shared resource, event outside the system(s) concerned, etc. When identifying mitigation means for specific common modes, the means should be appropriate to the common mode failure/error.

It is important to note that even Items that are developed to IDAL A may be subject to development error. Such error may simultaneously affect several instances of the same item with potential functional or safety consequences. EASA has experienced cases, where a development error in IDAL A item has even resulted in simultaneous failures of all affected equipment. Therefore, it should not be assumed that IDAL A items are protected from such development errors and consequently they should be included in the scope of the common mode analysis irrespective of the FDAL/IDAL of the system/item.

The following structured approach is accepted to accomplish a common mode analysis:

(1)     Establish program-specific checklists (for common mode types, sources, and resulting failures/errors). ARP4761 paragraph K.3.1 can be followed for this purpose. These checklists should be used to detect elements that may defeat the redundancy or independence principles within the design.

The following Common Modes are examples of common mode types, sources, and resulting failures/errors to be considered:

(i)      Software development errors

(ii)     Hardware development errors

(iii)     Hardware failures

(iv)     Production/repair flaws

(v)     Stress related events (e.g., abnormal flight conditions, abnormal system configurations)

(vi)     Installation errors

(vii)    Requirement errors

(viii)   Environmental factors (e.g., temperature, vibration, humidity, etc.)

(ix)     Cascading faults

(x)     Common external source faults

(xi)     General Common Modes are further detailed in the ARP4761 table K1.

(2)     Identify the independence principles and requirements. ARP4761 paragraph K.3.2 can be followed for this purpose.

These Failure Conditions should cover both the availability (i.e. loss) and integrity of functions and protections.

(3)     Analyse the design to ensure it meets the principles and requirements identified in paragraph (2) above. ARP4761 paragraph K.3.3 can be followed for this purpose.

The analysis of the design:

(i)      should be conducted not just at system level but also at item level (Airborne Electronic Hardware items including architecture and Software items including architecture), and

(ii)     should address both the availability (i.e. loss) and integrity of functions and protections.

(4)     Document the results of the above steps of the CMA process. ARP4761 paragraph K.4 can be followed for this purpose.

Additional considerations may be appropriate for some specific systems and functions. In particular for Fly-by-wire Flight Control Functions, MOC 4 VTOL.2300 applies.

10.     Development Assurance process

Any analysis necessary to show compliance with VTOL.2510(a) should consider the possibility of development errors.

For simple systems, which are not highly integrated with other aircraft systems, errors made during the development of systems may still be detected and corrected by exhaustive tests conducted on the system and its components, by direct inspection, and by other direct verification methods capable of completely characterising the behaviour of the system. Such items may be considered as meeting the DAL A rigor when they are fully assured by a combination of testing and analysis, however requirements for these items should be validated with the rigor corresponding to the FDAL of the function. Systems which contain software and/or complex electronic hardware items, cannot be considered simple.

For more complex or highly integrated systems, exhaustive testing may either be impossible because all of the system states cannot be determined or impractical because of the number of tests which should be accomplished. For these types of systems, compliance may be shown by the use of development assurance. The level of development assurance should be commensurate with the severity of the failure conditions the system is contributing to.

(a)      Development Assurance Level (DAL) allocation

The development assurance level of a function or of an item is assigned depending on the classification of the failure conditions it contributes to.

Initial FDAL allocation is performed in accordance with Section 8(a) in this MOC.

Guidelines, which may be further used for the allocation of development assurance levels to aircraft and system functions (FDAL) and to items (IDAL), are described in the document ED-79A/ARP4754A, section 5.2.

In the absence of agreed guidelines on FDAL/IDAL allocation, the FDAL should be commensurate with those applicable to the category of aircraft as per Sectionn8(a) in this MOC and the IDAL of all components contributing to a given function should be equal to the FDAL of that function.

(b)     Aircraft/System development assurance

For the aircraft and for systems of FDAL A, B, C or D, this MOC recognises the ED-79A/ARP4754A as acceptable guideline for establishing a development assurance process from aircraft and systems levels down to the level where software/ Airborne Electronic Hardware (AEH) development assurance is applied.

The extent of application of ED-79A/ARP4754A to substantiate functional development assurance activities may vary depending on the complexity of the systems and on their level of interaction with other systems. Early concurrence with the Agency is essential.

(c)      Software development assurance

This MOC recognises AMC 20-115( ) as an accepted means of compliance with requirement VTOL.2510(a).

For Commercial-Off-The-Shelf (COTS) software items and open-source software, in addition to the provisions of AMC20-115(), this MOC recognises guidance from DO-278A/ED-109A section 12.4 as an alternative that could be generally applied beyond the limits of CNS/ATM systems.  In this case, the association between ED-12C/DO-178C software level and ED-109A/DO-278A AL (Assurance Level) can be found in DO-278A / ED-109A table 2-2 of section 2.3.3 ‘Assurance Level Definitions’.

Alleviation for software items of IDAL D contributing to Minor Failure Conditions:

(1)     For Category Basic 1 and Basic 2 (c.f. Table 1: Safety Objectives), it is possible to alleviate the software-level development assurance, relying on system-level development assurance processes, provided that:

(i)      the equipment is one piece of equipment; and

(ii)     the equipment is developed with an acceptable development assurance process.

(2)     For Category Basic 3 (see Table 1: Safety Objectives) and Enhanced, the software-level development assurance may be alleviated provided that:

(i)      the software high-level requirements are defined and are verified to be captured in the systems requirements as described in ED-79A/ARP4754A section 5.4; and

(ii)     if some are ‘derived requirements’, a mechanism is in place to properly identify, validate and verify those derived software high-level requirements as described in ED-79A/ARP4754A section 5.4.

Note: In both cases, the system-level processes are not considered to be software development assurance processes.

(d)     Airborne Electronic Hardware development assurance

This MOC recognises AMC 20-152( ) as accepted means of compliance for requirement VTOL.2510(a).

(e)     Open Problem Report management

This MOC recognises AMC 20-189( ) as accepted means of compliance for establishing an open problem report management process for the system, software and AEH domains.

(f)      Considerations on derived requirements

ED-79A/ARP4754A section 5.3.1.4 adequately addresses the concerns related to potential for errors introduced by derived requirements while designing and implementing the systems

However, if ED-79A/ARP4754A section 5.3.1.4 defines the derived requirements as those that “may not be uniquely related to a higher-level requirement “, the definition could create an ambiguity as it is limited to “Additional requirements resulting from design or implementation decisions during the development process which are not directly traceable to higher-level requirements”.

Requirements that trace to a higher-level requirement and add a behaviour that is not specified at a higher level should also be considered as derived.

As a consequence, the definition from ED-79A/ARP4754A is superseded by the definition provided in Section 4 of this document.

11.     Considerations for highly integrated systems

(a)      Generic guidance

(1)     When aircraft functions are provided by a combination of systems, the relevant requirements of those systems should be validated together, including the following activities:

(i)      Analysis of the potential interactions and interferences between systems,

(ii)     Planning of dedicated activities at system and aircraft levels to ensure validation of those requirements that are affected by interactions or interference.

(2)     When incorporating multiple functions into the same system or equipment, applicability of AMC 20-170 should be considered. For architectures with no partitioning, particular care should be taken in the analysis of interactions between functions.

(b)     Additional Considerations for the Lift/Thrust system

For most VTOL capable aircraft designs, the Flight Control System and the Lift/Thrust system are highly integrated, i.e. the propulsion system directly contributes to the controllability of the aircraft. Therefore the development of the Lift/Thrust system should take into consideration the safety objectives of Section 8 and should follow the provisions of VTOL.2510 and associated guidance.

12.     Latent failure considerations

The use of periodic maintenance or flight crew checks to detect significant latent failures when they occur is undesirable and should not be used in lieu of practical and reliable failure monitoring and indications. Significant latent failures are latent failures that would, in combination with one or more specific failure(s) or event(s), result in a Hazardous or Catastrophic failure condition and should be avoided in system design.

Within the frame of the no single failure criterion, dual failure combinations, with either one latent, that can lead to a Catastrophic Failure Condition should be avoided in system design. Any such combinations should be highlighted in the relevant SSA and discussed with the Agency as early as possible after identification.

Additional considerations may be appropriate for some specific systems and functions. In particular for Fly-by-wire Flight Control Functions, MOC 5 VTOL.2300 applies.

13.     Flight Crew and Maintenance considerations

(a)      Flight Crew actions

When assessing the ability of the flight crew to cope with a failure condition, the information that is provided to the flight crew and the complexity of the required action should be considered. If the evaluation indicates that a potential failure condition can be alleviated or overcome during the time available without jeopardizing other safety related flight crew tasks and without requiring exceptional pilot skill or strength, credit may be taken for correct and appropriate corrective action for both qualitative and quantitative assessments. Similarly, credit may be taken for correct flight crew performance if overall flight crew workload during the time available is not excessive and if the tasks do not require exceptional pilot skill or strength. Unless flight crew actions are accepted as normal airmanship, the appropriate procedures should be included in the Agency-approved AFM or in the AFM revision or supplement. The AFM should include procedures for operation of complex systems such as integrated flight guidance and control systems. These procedures should include proper pilot response to cockpit indications, diagnosis of system failures, discussion of possible pilot-induced flight control system problems, and use of the system in a safe manner.

(b)     Maintenance actions

Credit may be taken for the correct accomplishment of maintenance tasks in both qualitative and quantitative assessments if the tasks are evaluated and found to be reasonable. Required maintenance tasks, which mitigate hazards, should be provided for use in the Agency-approved ICA. Annunciated failures that will be corrected before the next flight or a maximum duration should be established before a maintenance action is required. If the latter is acceptable, the analysis should establish the maximum allowable interval before the maintenance action is required. A scheduled maintenance task may detect latent failures. If this approach is taken, and the failure condition is hazardous or catastrophic, then a maintenance task should be established.  The process for the identification and selection of these scheduled maintenance tasks requires early coordination and agreement with the Agency. Guidance may be found in AMC 25-19.

Credit could be given to tests performed due to mean time between failures (MTBF) to detect the presence of hidden failures, if it can be ascertained that the equipment is removed and inspected at a rate much more frequent than the safety analysis requires. This credit should be substantiated in the relevant SSA. The means of detection of the hidden failures should be clearly identified, either at the opportunity of the acceptance tests performed before the equipment enters service or leaves the manufacturer, or at the opportunity of test of system integrity when it is installed back on the aircraft. This substantiation should be recorded in the relevant SSA. In case of double failures, with either one or both hidden, that can lead to Catastrophic or Hazardous Failure Condition, no credit should be taken from MTBF for failure detection, and the maintenance task enabling detection of the hidden failure should be identified as a required maintenance task.