ARP4754A Intro, Compliance: Free Tools/ Papers / Resources

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:

1. ARP4754A “Plans” comply with safety requirements and summarize what you will do
2. ARP4754A “Processes” state how you will implement the Plans
3. ARP4754A “Reviews” (with Checklists advised) denote objective review criteria to determine if Processes were followed
4. 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

More on ARP4754A VS 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:

1. Functional DAL, called FDAL; and
2. 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
Catastrophic	A
Hazardous/Severe-Major	B
Major	C
Minor	D
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.   

Defining Requirements

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.  

The scope of ARP4754A Planning topics is shown in the following figure:

Figure:  Scope of ARP47654A Planning Topics

ARP4754A, with ARP4761A, call for a formal Safety Program Plan (SPP) which includes the following key safety processes depicted in the figure below:

Functional Hazard Assessment

The objective of the FHA is to identify functions, failure conditions of functions (loss of function, malfunction, etc.), and their classification (catastrophic, hazardous, etc.) so that aircraft and system designs may be proposed and achieved which decrease the probability of the occurrence of the failure conditions to acceptably lesser levels. It should be noted that in some cases, total loss of a function is not as impactful as partial or misleading loss of functionality; a pilot may be more likely to mitigate total loss of one system’s functionality by switching to a different system.

Preliminary System Safety Assessment (PSSA)

The PSSA is a set of analyses normally performed during the system requirements and item requirements phases of the aircraft life cycle.  The PSSA is where the proposed aircraft and system architectures are evaluated and defined; this provides the ability to derive system and item safety requirements. The input documents to the PSSA are the aircraft FHA, preliminary aircraft Fault Tree Analysis FTA (and allocation of failure budget against the top level failure requirement), and the system FHAs. The documents produced during the PSSA are the updated aircraft and system FHAs, updated aircraft and systems FTAs, and the preliminary system Common Cause Analyses (CCAs).The PSSA is a continuous and iterative process. The objective of the PSSA is to determine how the aircraft and system failures can lead to the hazards identified in the FHAs and to determine how the FHA requirements can be met. The PSSA is often associated with the Preliminary Aircraft Safety Assessment (PASA).

An important note:  Appendix 1 of AC23.1309-E has some useful guidance to assist with assessing the severity of failure conditions of aircraft functions and systems at this stage of the project.

Requirement Validation

Congratulations – the aircraft and system requirements are captured and it’s time to initiate design then implementation.   But you’re smart and you know you will verify those requirements later to ensure implementation satisfies the requirements.  Wait: how do you know you have the “right” requirements? Exactly. That is the role of requirements validation and it must precede design/implementation.  Why?  Requirements are the foundation to aircraft and systems. Like building a house, changing the foundation after starting construction is undesirable for many reasons, most important of which is safety.

Truly, you need to determine if you have conflicting, incomplete, or incorrect requirements long before you initiate development.  ARP4754A requires a formal validation process whereby requirements are evaluated for correctness and completeness before they are used in design/implementation.  However, requirements validation is performed throughout the development process because changes are inevitable and all changes to requirements or anything affecting a requirement must be assessed through validation.

The approach to requirements validation must be defined in advance via plans; typically a separate validation plan is utilized, however it is common to combine validation planning documentation within the verification plan since validation and verification are related.  For ARP4754A and ARP4754B success, most practitioners find ARP4754A training to be helpful. A brief free ARP4754A training video, one hour, is here: https://www.youtube.com/watch?v=tng3rGW-BcQ

For more detailed Public ARP4754A training, Private ARP4754A training, and Remote Online ARP4754A training, see the training schedule here: https://afuzion.com/public-training-webinars-2/.

Requirements validation is a formal process, and within aviation, most formal processes require checklists.  Even a 5,000 hour pilot with vast experience is formally required to follow a checklist for many key activities including takeoff and landing. And because safety is so important, commercial aircraft utilize a co-pilot for added independent verification.  Fortunately, ARP4754A provides high-level requirement validation criteria in section 5.4.3 which should be used to form the basis of the validation checklist.  For brevity, these are not repeated herein as there is little unique about requirements validation in aviation versus other safety-critical industries (however the term “validation” itself is used differently – see the corresponding Aviation Requirements chapter in this book).  The usual evaluation criteria apply:  correctness, non-ambiguity, avoidance of conflicting logic, identifiability, traceability, impact upon safety, etc.

Implementation Verification

The plans have been followed perfectly, requirements seem to be perfectly validated, and QA has audited the activities throughout the engineering process including all transitions through implementation.  Ready to begin flight test?  Not so fast.  Remember, in aviation, the probability of software error is assumed to be “1”, e.g. errors happen – can they be detected and mitigated?

During engineering, the same philosophy applies. While great plans, processes, and engineering produce measurably better systems with fewer errors, verification is still required. The common belief is that verification improves quality by finding errors. While not incorrect, verification is really performed to assess the adequacy of prior activities in conjunction with a feedback loop to improve those activities and the implementation.  Therefore aviation verification is more important, and more encompassing, than mere bug detection.

It is commonly believed that verification is performed purely to identify errors so that they can be fixed.  While partially true, verification at the aircraft and avionics systems level per ARP4754A is more encompassing, as it is also used  to assess the completeness and quality of preceding development activities including Safety, Requirements, and Design; not just Implementation.  Remember the overly simplistic verification equation cited earlier, “Verification = Reviews + Tests + Analysis”

Both the required, and the potential, verification activities are more diverse; keep in mind the degree of verification rigor increases with the DAL rigor, e.g. DAL A is the most intensive.  The following figure depicts the common types of verification applied under ARP4754A:
ARP4754A’s Top 5 Verification Techniques

ARP4754A requires planning documents and system lifecycle documents for certification, safety, requirements, design, CM, PA, and V&V. Using AFuzion’s ARP4754A templates for these documents greatly eases their preparation and approval. ARP4754A Plans, Standards, and checklist templates are available here: https://afuzion.com/plans-checklists/#ARP4754A-plan-templates

ARP4754A also requires reviews, audits and proof thereof. The best “proof” is detailed and complete checklists covering the primary system lifecycle activities and artifacts.  Using AFuzion’s ARP4754A provided checklists ensures that you have an appropriate framework for successfully developing and certifying your system.

ARP4754A Planning Background

Once acquired and customized on the first project, your ARP4754A team will retain the expertise to create, customize and re-use as appropriate on future ARP4754A projects. Note that the ARP4754A Planning documents can be purchased in either Template form or “Initial Draft” form. The Template form option provides the basic templates which you then modify to create an initial draft. The Initial Draft option provides for AFuzion to first create initial drafts of all planning documents using the same template, but adding the customer’s basic product information to create an initial draft; the customer then must finalize this initial draft to create the first versions of these five planning documents.

AFuzion’s ARP4754A Plans and Checklist Templates cover all phases of the aircraft/system project lifecycle, and are developed with ARP4754A in mind.  The users of these templates would need to have some basic understanding of ARP4754A, such as attendance at AFuzion ARP4754A training available here: https://afuzion.com/public-training-webinars-2/

These ARP4754A templates and checklists also help in getting organizations to the goal of higher SEI CMM/CMMI ratings (preferably Level 3 – 4+). Usage of AFuzion process templates and checklists are intended to maximize the probability of project success and quality. The regulatory agencies require that most airborne commercial systems operating within commercial airspace to comply with ARP4754A (details can be found in the regulatory website).

The planning and processes for the systems lifecycle are required for any ARP4754A project and those processes must be defined before initiating that phase and followed during that phase. Although Checklists are not formally mandated by ARP4754A, your regulatory agencies will require that you prove conformance to ARP4754A according to your approved processes; this conformance is very difficult to achieve and prove without checklists. In fact, nearly all ARP4754A projects use checklists for reviews and proof of such.

AFuzion Planning Templates are meant to provide the proper framework for customization to meet the system planning requirements of ARP4754A.  Although there is no perfect process for all programs, there are unique areas of each individual project.  Each project will vary somewhat in how it chooses to define, implement, or augment the AFuzion Planning Templates. Factors to consider include project Design Assurance Levels, complexity, and expertise of staff, development methodology, tools/environment, and technology. 

The AFuzion Planning Templates provide the basic elements of an aircraft or avionics project compliant with ARP4754A.  Further, AFuzion can customize and tailor these processes by the appropriate amount as an outflow of an AFuzion gap analysis process, upon request as part of the optional first draft delivery.

If there are items in the checklists that are not applicable to your program they could simply be answered with “N/A”. It is also recommended that the checklists be placed under your project’s configuration management (CM) system to ensure checklist integrity.

Independent reviews are always preferable to reviews done by the developer. It should be noted that the checklists should be widely distributed to all personnel developing any avionics lifecycle item, prior to that person beginning such initiation. Thus, the checklist serves as a “report card” whereby the originator’s success is measured. When the originator understands what the independent verification reviewer will be evaluating the related hardware artifact for, the originator will more productively attain checklist compliance during development of that artifact.  This applies to requirements, design, implementation, test, etc. 

The level of “independence for verification” required by ARP4754A varies according to Design Assurance level (Level A through E).

ARP4754A Plan & Checklist Templates Provided by AFuzion

AFuzion ARP4754A Plan/Standard Templates

(email info@afuzion.com for a free sample copy)

• ARP4754A PASA Preliminary Aircraft Safety Assessment Template
• ARP4754A PSSA Preliminary System Safety Assessment Template
• ARP4754A Project Specific Certification Plan Template
• ARP4754A Safety Program Plan Template
• ARP4754A System Process Assurance Plan Template
• ARP4754A System Development Plan Template
• ARP4754A System Requirements Management Plan Template
• ARP4754A System Configuration Management Plan Template
• ARP4754A System Validation & Verification Plan Template
• ARP4754A System Requirements Standard Template
• ARP4754A System Design Standards Template
• ARP4754A System Validation & Verification Standards Template

AFuzion ARP4754A Checklist Templates

• ARP4754A Project Specific Certification Plan Checklist
• ARP4754A System Process Assurance Plan Checklist
• ARP4754A System Development Plan Checklist
• ARP4754A System Configuration Management Plan Checklist
• ARP4754A Validation & Verification Plan Checklist
• ARP4754A System Requirements Standards Checklist
• ARP4754A System Design Standards Checklist
• ARP4754A FMEA/FMES Review Checklist
• ARP4754A System Requirements Data Review Checklist
• ARP4754A System Design Review Checklist
• ARP4754A System Validation & Verification Standards Checklist
• ARP4754A System Configuration Index Checklist
• ARP4754A Objectives Checklist

ARP4754B

ARP4754A has evolved to ARP4754B (ED-79A in Europe which is now released and increasingly mandatory; the ARP4754A to ARP4754B transition is depicted in the following Figure extracted from AFuzion’s ARP4754A which is provided via SAE, the group that created and publishes ARP4754A and which has chosen AFuzion to deliver its training (contact SAE to procure ARP4754A training or visit the training schedule here: https://afuzion.com/public-training-webinars-2/

The relationship of ARP4754A’s and ARP4754B’s safety assessment process is depicted in the following ARP4754A Safety Assessment Phase Transition Diagram:

In the above figure, note the ARP4754A sequencing from Concept Development à Prelim Design à Detailed Design à Design Validation and Verification.  Furthermore, note that ARP4754A’s common cause analysis is subdivided into Particular Risk Analysis, Common Mode Analysis, and Zonal Safety Analysis.  (Download the full ARP4754 Introduction paper via the link below for the full details).

Are you ready to fly as a passenger in a fully autonomous aircraft? Are existing aviation safety regulations such as SAE Aerospace Recommended Practice ARP4761A sufficient to ensure safety? Keep reading … While autonomy is gradually being introduced to aviation via ground-based flight planning an onboard monitoring, true Artificial Intelligence (AI) is still not fully deployed on major aircraft as a means for sole control. Not yet. Aviation requires new aircraft adhere to rigid standards such as ARP4761A for Safety and ARP4754B for Aircraft/Systems development. While these standards are only recently released in 2023, they were under development for many years prior; that means ARP4761A and ARP4754B did not address artificial intelligence or machine learning directly. However, ARP4761A requires a mandatory Safety Program Plan (SPP) for each aircraft and system; ARP4761A is intended to ensure all aircraft systems are safely developed and integrated. How does ARP5761A help ensure aviation safety? First, each new aircraft must develop an Aircraft-level Functional Hazard Assessment (FHA) which assesses the potential risks based upon aircraft type, size, complexity, engines, and other factors. Next, a Preliminary Aircraft Safety Assessment (PASA) is developed for that aircraft. Then, that aircraft and systems are assessed with System-level FHAs to assess each systems’ contribution to safety for each phase of flight. Next, system-level Preliminary System Safety Assessments (PSSA’s) are developed for each system and continuously integrated with the PASA. Now, Artificial Intelligence and Machine Learning introduce potential non-determinism which must be analyzed and ensured to actually be deterministic while deployed on the aircraft for safety-related activities. That is done following strict formal language (compliant to RTCA DO-333) and Model-Based System Engineering (MBSE) per ARP4754B. So, will autonomous aircraft be in our children’s future? Yes, certainly. Will they use AI to help fly the aircraft? Yes, certainly. Will autonomous aircraft solely fly passenger aircraft in the next decade in the USA or Europe?

ARP4754A requires eight planning topics (often implemented via eight separate plans however Verification and Validation are often combined into a single ARP4754A V&V plan) plus project-specific standards and checklists.  (over 3,000 engineers at 70+ companies use AFuzion’s ARP4754A Templates for Planning, Standards, and Checklists which include ARP4761 Templates; details are here: https://afuzion.com/plans-checklists/#ARP4754A-plan-templates)

For a 45-minute technical video on ARP4754B extracted from AFuzion’s 16-hour ARP4754B training, please click below:

ARP4754B Video Training Extract

For the remaining 13 pages of this AFuzion ARP4754A Technical Whitepaper, please download below.

← Back To All Whitepapers