ARP4754A Introduction – Avionics Systems
ARP4754A is officially titled “Guidelines for Development of Civil Aircraft And Systems”. Rarely can one judge a book by its cover or title; however, in this case, the title literally conveys a powerful message: if you are involved with development of aircraft or systems, you should be well versed in ARP4754A’s ‘guidelines’. Why? There are two key reasons which should be understood before first opening the pages of ARP4754A:
1. ARP4754A’s title states “guidelines”, but failure to understand and apply ARP4754A will greatly reduce safety and your ability to achieve certification.
2. Where its predecessor ARP4754 was largely similar, too many organizations treated it as “optional” befitting its name “Guideline”; but certification organizations worldwide have formally mandated adherence to this latest version, ARP4754A.
For experienced, proficient developers of aircraft and systems, ARP4754A reads like a book for maintaining good personal health: make a plan for health, understand healthy living, be safe, eat well, reduce stress, exercise, sleep, get regular check-ups, and repeat. For aircraft, an analogous synopsis of ARP4754A would state:
1. Plan your aircraft/system’s development lifecycle ecosystem;
2. Implement Safety activities per ARP4761/A;
3. Define and justify Assurance Level;
4. Define System architecture and requirements; Validate.
5. Perform Verification and Configuration Management
6. Implement Quality Assurance and prove Transition Criteria.
The original ARP4754 standard was first published in 1996 with the purpose of assisting avionics development organizations to think beyond mere hardware and software. Remember, DO-178 (and its European equivalent ED-12) was published over a decade prior to provide guidelines for avionics software. But by the early 90’s it was clear that safe software, and software certification itself, required both knowledge of the system and confirmation of system level safety aspects. ARP4754 was focused upon aircraft systems whose failure could potentially affect safety of aircraft or occupants. While there are certainly critical stand-alone components on aircraft which could affect safety, ARP4754 is focused not upon components, but rather systems which have complex interactions with other systems on or off the aircraft. These systems typically involve multiple knowledge domains and are likely to evolve over time. Thus they are developed by different persons via different disciplines often separated by space and time; the best means to ensure safe implementation is via codified development processes based upon deterministic safety: ARP4754.
ARP4754A versus ARP4754
With revision “A” of ARP4754, e.g. ARP4754A, several key improvements were made as shown below:
ARP4754A requires ARP4754A Planning, ARP4754A Processes, ARP4754A Reviews, and ARP4754A Process Assurance (quality assurance) Audits. Here is an all-too-brief summary of ARP4754A Plans, ARP4754A Procedures, ARP4754A Reviews, and ARP4754A Audits for avionics systems:
- ✓ ARP4754A “Plans” comply with safety requirements and summarize what you will do, while
- ✓ ARP4754A “Processes” state how you will implement the Plans, and
- ✓ ARP4754A “Reviews” (with Checklists advised) denote objective review criteria to determine if Processes were followed, then
- ✓ ARP4754A “Process Assurance Audits” assess conformance of engineering/manufacturing activities, including respective transitions to those Processes and Reviews.
The following page is reprinted from AFuzion’s 300-page proprietary ARP4754A Training manual (page 37 of 293 pages):
ARP4754A’s Eight Planning Topics
Figuratively and literally, systems development via ARP4754A is the centerpiece: it is preceded by, and must consider, the ARP4761A safety assessment which is used to help define system architecture and system safety requirements. (See AFuzion’s ARP476! Whitepaper for safety details; free download here: https://afuzion.com/rp-4761a-introduction-avionics-safety/ ) In turn, ARP4754A precedes software (DO-178C) and hardware (hardware) development yet aircraft and system considerations are continuously addressed during the entire software and hardware development. A refined view of the relevant guidelines showing ARP4754A’s importance is depicted here:
Why ARP4754A? Background.
Before delving into ARP4754A specifics, one should truly consider why it exists. When avionics systems were simpler decades ago, it was possible for smart designers to avoid a framework posed by ARP4754A and simply mentally conceive those systems and proceed immediately with implementation. Admittedly today, the need for ARP4754A is less justifiable for simple systems, but such simple systems are becoming fewer and fewer. But for modern aircraft, the number, variety, and complexity of systems continues to grow exponentially. Clearly, avionics systems can be much more complex than commercial brick and mortar buildings, but it would be inconceivable to begin building a commercial office building without a soil/earthquake analysis, foundation design, and a plan for inspections. Those inspections obviously continue throughout the building process including satisfactory electrical, plumbing, emergency exits, and proper reinforcement. While it is possible great builders could possibly build a safe building without detailed plans, blueprints, processes, and inspections, there would be no way to fully verify the building’s “greatness.” Why? “Greatness” must be associated with proof a building is great. Proof is based upon assessing implementation versus plans then correcting any deficiencies found. ARP4754A is aviation’s framework for proving reliable, safe, and reusable aircraft and systems. Clearly, without plans and processes for a building, there is no way to assess, or claim, a building’s design and construction are safe. Since developing avionics can be more complex than constructing a building,it is clear that avionics systems require big-picture planning, processes, requirements, safe development, verification/validation, and evidentiary proof of conformance. Welcome to ARP4754A, “Guidelines for Development of Civil Aircraft And Systems.”
With revision “A”, e.g. ARP4754A, several key improvements were made as shown below:
ARP4754 was “good”: it described a foundational process for developing safe, good-quality avionics systems and aircraft. However, due to the evolution of related guidelines and certification refinement, and a requirement to address increasing integration and complexity of systems, ARP4754 was considered by many to be incomplete; thus, ARP4754A was not applied as rigorously as needed.
By contrast, ARP4754A truly emphasizes the importance of an entire ecosystem for avionics system development, founded upon a formal Safety process (supported by ARP4761). ARP4754A provides specific guidance to complying with regulations, and instructions into a “how to” guide for aircraft and system development, emphasizing the need to integrate that Safety and Systems process continuously throughout development. (Note while ARP4754A can be perused in a day, understanding it requires formal training; AFuzion’s 2-Day private customized ARP4754A training has been provided to over 100 organizations and 3,000 engineers. Information on AFuzion’s ARP4754A Training Classes is here: https://afuzion.com/private-training/avionics-systems-arp-4754a-training-class/).
The ARP4754A aviation development ecosystem covers numerous ARP and DO documents as depicted in the following figure:
Figure: ARP4754A & ARP4761A Aviation Ecosystem
Figuratively and literally, systems development via ARP4754A is the centerpiece: it is preceded by, and must consider, the ARP4761A safety assessment which is used to help define aircraft/system architecture, and aircraft/system safety requirements. In turn, ARP4754A precedes software and hardware development, yet system considerations are continuously addressed during the entire software and hardware development associated with ARP4754A. For a free 1-hour ARP4754A training video, see here: https://www.youtube.com/watch?v=tng3rGW-BcQ&list=PL0es63yi1vbw9Tt1GWX8TtiFm4R2qRryu&index=6
ARP4754A versus ARP4754
With revision “A”, e.g. ARP4754A, several key improvements were made as shown below:
The scope of ARP4754A’s planning process is summarized in the following graphic:
At the aircraft level, ARP4754A requires an overall Safety Program Plan (SPP). It is common to have system-level SPP’s for each system. Like building a house, the scope of ARP4754A’s aircraft and avionics safety takes many different forms: foundation, architecture, problem detection, problem mitigation, susceptibility to particular hazards (lightning, etc.), and verifiability. So multiple ARP4754A / ARP4761A safety activities and analysis are required. Aviation development tools are often used to perform the ARP4754A activities and ARP4761A safety assessment; the following site describes a wide selection of aircraft and avionics development tools: http://certegic.com/aviation-development-information/adi-development-tools/ The following figure summarizes the primary safety activities necessary for ARP4754A compliance:
Primary Aircraft & Avionics Safety Activities per ARP4754A & ARP4761A
For a more complete description of the ARP4754A Aircraft and System Functional Hazard Assessment (FHA), PSSA, SSA and CCA, see the corresponding AFuzion ARP4761A Safety Assessment whitepaper.
The overall ARP4761A Safety process relationship within ARP4754A is depicted below:
Figure: ARP4754A V-Model Aircraft & Avionics Engineering Lifecycle
ARP4754A is a complex and varied field. For ARP4754A training and ARP4761A training, see here: https://afuzion.com/private-training/avionics-systems-arp-4754a-training-class/
Most aviation developers find their initial ARP4754A implementation cost increase to be 20-30% over conventional non-ARP4754A development. My adopting the following ten Best Practices for ARP4754A, new users are usually able to mitigate such costs.
System Safety Assessment (SSA) for ARP4754A & ARP4761A
The ARP4754A / ARP4761A SSA verifies that the implemented aircraft and system designs meet the requirements of the aircraft/system FHA and the Preliminary Aircraft Safety Assessment (PASA) and Preliminary System Safety Assessment (PSSA). The SSA documentation generated during the SSA includes:
- Updated aircraft FTAs, system FHAs, and system FTAs per ARP4754A / ARP4761A
- Documentation showing item installation requirements
- Any material used to validate the failure condition classifications
- If necessary, revised maintenance manuals detailing new maintenance tasks aimed at reducing component exposure times
- If necessary, revised flight crew operating manuals detailing procedures to be followed in the event of certain failure conditions
There are two types of DALs defined by ARP4754A:
- Functional DAL, called FDAL; and
- Item DAL, called IDAL.
Figure: ARP4754A V-Model Aircraft & Avionics Engineering Lifecycle
While not mandatory, it’s most common in ARP4754A / ARP4761A to determine the FDAL first, then followed with IDAL determination. Why? Functions are associated with requirements, and those requirements are allocated to items. Functions and their requirements thus describe “what” a system does while the actual requirement is implemented in hardware and/or software items. ; This is to allow a single function to be split between multiple items to potentially allow a lower Design Assurance Level of those individual items. The level of rigor for the functional requirement development is defined by the FDAL, with level A being the most rigorous. The required development objectives for each FDAL are provided in Appendix A of ARP4754A itself. The corresponding hardware/software item development likewise has a specific DAL assignment called an IDAL; the required hardware/software development objectives for each IDAL are provided in DO-178C (ED-12C for Europe) and DO-254 (ED-80 for Europe). Note that most aircraft and system developers build or buy ARP4754A planning document templates and checklists; AFuzion’s can be viewed here: https://afuzion.com/plans-checklists/ .
The DAL determination starts by considering the functions in the aircraft or system’s FHA failure conditions; therefore these are called “Top-Level Failure Conditions.” The FDAL is assigned based upon the most severe Top-Level Failure Condition. For example, if the most severe is DAL B, the FDAL is thus Level B. A synopsis of the ARP4754A FDAL’s is provided below:
|Top-Level Failure Condition Severity Classification:||Corresponding FDAL Assignment|
|No Safety Effect||E|
Table: ARP4754A / ARP4761A FDAL Assignment Allocations
ARP4754A describes specific processes for considering independence between systems and processes as they pertain to DAL. The goal is to ensure requisite levels of necessary safety and elimination of common mode failures. For example, if a single failure can affect multiple systems or components, then independence can be added to prevent that single failure from affecting more than one system or component.
Functional independence ensures that functions are not affected by common errors within the same function. For example, navigation is clearly an important function for aircraft safety; using two sources of navigation data (Global Positioning System (GPS) and Inertial Navigation System (INS)) provides for functional independence and elimination of many common mode error problems which could occur otherwise.
Item Development Independence likewise ensures that the items associated with the function do not experience common errors; for example using different operating systems within independent items provides for Item Development Independence which could occur if a single operating system had an unmitigated error.
The SSA should verify that all significant effects identified in the FMES are considered for inclusion as primary events in the FTA, and the SSA should also include applicable CCA results.
Common Cause Analysis (CCA)
The acceptance of adequate probability of failure conditions is often derived from the assessment of multiple systems based on the assumption that failures are independent. This independence might not exist in the practical sense, and specific studies are necessary to ensure that independence can either be assured or deemed acceptable. The CCA is concerned with events that could lead to a hazardous or catastrophic failure condition. The same software installed on multiple LRU’s is considered by many to be the most often overlooked area of common cause. For example, Dual Flight Management Systems (FMS) could fail under the exact same conditions if the same software is installed on both units.
You have the DALs are defined and it is time to define requirements. What? Requirements are not considered during the DAL assignment process? While it’s common to know, or at least initiate, the requirements in parallel with the DAL assignment process, the DAL is about safety and thus should be initiated without formally considering the requirements. Safety considerations need to precede functionality. Requirements are defined partly to satisfy safety, as determined via the DAL process. So DAL determination precedes requirement definition. How are requirements defined? By considering the various types of requirements and how each pertains to the aircraft or system being developed. The following figure depicts the primary types of requirements which must be defined, along with the common (but not mandated) order:
Graphic: Primary ARP4754A Aircraft/System Requirement Types
Which of the above ARP4754A requirement types are important? They all are. But really, which are most important? Well, consider: functional and operational performance are important – the aircraft and systems need to fulfill objectives and those objectives must be clearly defined; requirements provide that definition. Operational aspects and the interfaces which affect the ability to perform and necessary to define. However, per ARP4761A (and inherently ARP4754A) safety is key, so the safety requirements must be paramount. But safety requirements are usually the most difficult to define as there is more subjectivity involved: how safe is “safe”? Careful consideration must be given to the safety assessment artifacts to consider relevant failure conditions, modes, and effects; knowledge should focus upon prevention, but wisdom should prevail knowing one hundred percent prevention is impossible. So architectural aspects including redundancy, dissimilarity, partitioning, etc. must be added to support the requisite DAL, and those aspects must be defined via requirements. The approach to be used for ARP4754A requirements capture must be defined in advance, in the planning process. Why? Plans are independently assessed prior to following the activities described in those plans, so the planned requirements capture process can be evaluated prior to initiation. Some say the biggest mistake made during this phase is for the requirements writers to incorrectly muse “but the pilot would never do that … ” Particularly as flight decks become more and more automated, the Catch-22 of automation pervades: the more automation, the more the pilot depends upon automation, so the more automation …
Regarding ARP4754A safety and requirements, an often misunderstood aspect is the role of derived requirements. What are derived requirements? Be careful of linguistics. If English is not your native tongue, despair not: native English speakers are seemingly less able to understand the meaning of “derived requirements” because they are derived from an engineer’s desire to address an otherwise undocumented or overlooked capability. Derived requirements usually do not trace to a parent requirement or describe obvious functionality. Instead, derived requirements are additional aspects which the system or aircraft being developed must implement, typically to address safety, re-use, or verifiability. For example, sampling rates, use of partitioning, or adding redundancy with health monitoring and voting are all examples of functionality commonly addressed via derived requirements. Since derived requirements often relate directly to safety, ARP4754A requires developers to ensure the existence of a feedback loop to the safety process for all derived requirements. Any change to derived requirements must be fed back to the safety process to determine any direct or indirect impact upon safety and the developers are required to prove the mandatory use of this process for all derived requirements, as audited by QA.
Congratulations – the aircraft and system requirements are captured and it’s time to initiate design then implementation. But you’re … (Download remaining pages of this whitepaper to read the rest.)
For the remaining 13 pages of this AFuzion ARP4754A Technical Whitepaper, please download below.
Information Request Form
Please provide the following information to receive your full WhitePaper