AMC1 29.1309 Equipment, systems, and installations

• ED Decision 2023/001/R found in: CS-29 Amdt 11 - Large Rotercraft (Feb 2023)

AMC1 29.1309 Equipment, systems, and installations ED Decision 2023/001/R As defined in AMC 29.1, the AMC to CS-29 consists of FAA AC 29-2C Change 7, dated 4 February 2016. AMC 29.1309 provides further guidance and acceptable means of compliance to supplement FAA AC 29-2C Change 7 § AC 29.1309. As such, it should be used in conjunction with FAA AC 29-2C Change 7, but should take precedence over it, where stipulated, in the demonstration of compliance. **Single failure and common-cause considerations** According to [CS 29.1309](#_DxCrossRefBm1178332097)(b)(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. Sources of common-cause and cascading failures include development, manufacturing, installation, maintenance, shared resource, event outside the system(s) concerned, etc. SAE ARP4761 describes types of common-cause analyses, which may be conducted, to ensure that independence is maintained (e.g. particular risk analyses, zonal safety analyses, common-mode analyses). While single failures should normally be assumed to occur, experienced engineering judgement 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 straightforward and obvious that the failure mode simply would not occur unless it is associated with an unrelated failure condition that would, in itself, result in a catastrophic failure condition. By detecting the presence of, and thereby limiting the exposure time to significant latent failures that would, in combination with one or more other specific failures or events identified by safety analysis, result in a hazardous or catastrophic failure condition, periodic maintenance or flight crew checks may be used to help demonstrate compliance with [CS 29.1309](#_DxCrossRefBm1178332097)(b). **Development assurance process** Any analysis necessary to show compliance with [CS 29.1309](#_DxCrossRefBm1178332097) (a) and (b) should consider the possibility of development errors and should focus on minimising the likelihood of those errors. Errors made during the development of systems have traditionally been 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 performance of the system. These tests and direct verification methods may be appropriate for systems containing non-complex items (i.e. items that are fully assured by a combination of testing and analysis) that perform a limited number of functions and that are not highly integrated with other rotorcraft systems. For more complex or integrated systems, exhaustive testing may either be impossible because not all system states can be determined or impractical because of the number of tests that must be accomplished. For these types of systems, compliance may be demonstrated using development assurance. (a) System development assurance The applicability of system development assurance should also be considered for modifications to previously certificated aircraft. ED-79A/ARP4754A is recognised as providing acceptable guidelines 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 development assurance activities depends on the complexity of the systems and on their level of interaction with other systems. (b) Software development assurance This AMC recognises AMC 20-115 as an accepted means of compliance with [CS 29.1309](#_DxCrossRefBm1178332097) (a), (b) and (c). (c) AEH development assurance This AMC recognises AMC 20-152 as an acceptable means of compliance with the requirements in [CS 29.1309](#_DxCrossRefBm1178332097) (a), (b) and (c). (d) Open problem report management This AMC recognises AMC 20-189 as an acceptable means of compliance for establishing an open problem report management process for the system, software and AEH domains. **Integrated Modular Avionics (IMA)** This AMC recognises AMC 20-170 as an acceptable means of compliance for development and integration of IMA. [Amdt No: 29/11] ##### AMC1 29.1309 Equipment, systems, and installations *ED Decision 2023/001/R* As defined in AMC 29.1, the AMC to CS-29 consists of FAA AC 29-2C Change 7, dated 4 February 2016. AMC 29.1309 provides further guidance and acceptable means of compliance to supplement FAA AC 29-2C Change 7 § AC 29.1309. As such, it should be used in conjunction with FAA AC 29-2C Change 7, but should take precedence over it, where stipulated, in the demonstration of compliance. **Single failure and common-cause considerations** According to [CS 29.1309](#_DxCrossRefBm1685772562)(b)(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. Sources of common-cause and cascading failures include development, manufacturing, installation, maintenance, shared resource, event outside the system(s) concerned, etc. SAE ARP4761 describes types of common-cause analyses, which may be conducted, to ensure that independence is maintained (e.g. particular risk analyses, zonal safety analyses, common-mode analyses). While single failures should normally be assumed to occur, experienced engineering judgement 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 straightforward and obvious that the failure mode simply would not occur unless it is associated with an unrelated failure condition that would, in itself, result in a catastrophic failure condition. By detecting the presence of, and thereby limiting the exposure time to significant latent failures that would, in combination with one or more other specific failures or events identified by safety analysis, result in a hazardous or catastrophic failure condition, periodic maintenance or flight crew checks may be used to help demonstrate compliance with [CS 29.1309](#_DxCrossRefBm1685772562)(b). **Development assurance process** Any analysis necessary to show compliance with [CS 29.1309](#_DxCrossRefBm1685772562) (a) and (b) should consider the possibility of development errors and should focus on minimising the likelihood of those errors. Errors made during the development of systems have traditionally been 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 performance of the system. These tests and direct verification methods may be appropriate for systems containing non-complex items (i.e. items that are fully assured by a combination of testing and analysis) that perform a limited number of functions and that are not highly integrated with other rotorcraft systems. For more complex or integrated systems, exhaustive testing may either be impossible because not all system states can be determined or impractical because of the number of tests that must be accomplished. For these types of systems, compliance may be demonstrated using development assurance. (a) System development assurance The applicability of system development assurance should also be considered for modifications to previously certificated aircraft. ED-79A/ARP4754A is recognised as providing acceptable guidelines 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 development assurance activities depends on the complexity of the systems and on their level of interaction with other systems. (b) Software development assurance This AMC recognises AMC 20-115 as an accepted means of compliance with [CS 29.1309](#_DxCrossRefBm1685772562) (a), (b) and (c). (c) AEH development assurance This AMC recognises AMC 20-152 as an acceptable means of compliance with the requirements in [CS 29.1309](#_DxCrossRefBm1685772562) (a), (b) and (c). (d) Open problem report management This AMC recognises AMC 20-189 as an acceptable means of compliance for establishing an open problem report management process for the system, software and AEH domains. **Integrated Modular Avionics (IMA)** This AMC recognises AMC 20-170 as an acceptable means of compliance for development and integration of IMA. [Amdt No: 29/11]