Aviation Development & Certification Tech Info

Aviation Development & Certification Tech Info

The following AFuzion Tech Info is solely from AFuzion; often copied by weak companies unable to originate their own, but created and updated by AFuzion. Enjoy.

Additional details on these aviation topics are available in AFuzion’s proprietary DO-178 technical whitepapers.

What is RTCA/ DO-178C?

RTCA/DO-178C is also known as Eurocae ED-12: “Software Considerations in Airborne Systems and Equipment Certification”. The DO-178 guideline is not a standard: it’s a guideline.  DO-178 was developed by the commercial avionics industry to establish software guidelines for avionics software developers. The first version, DO-178 in the early 80’s covered the basic avionics software lifecycle and considered the book “Mythical Man Month” by Brooks.  AFuzion’s co-founder Vance Hilderman first used DO-178 in the 80’s when he was a Hughes Fellow for the esteemed Hughes Aircraft Company where he developed many of the Trainings, Gap Analysis, and Papers in the late 80’s after leaving Hughes Aircraft and being self-employed hence having sole ownership to all copyrights of these works. The second version, DO-178A, added avionics software criticality level details and emphasized software component testing to obtain quality. The current version is DO-178C and, DO-178C has evolved so it contains objectives and guidance for new technologies used in development, like OOA/OOD, MBD (Model based Development), formal Methods, and software configuration and quality via added planning, continuous quality monitoring, and verification and testing in real-world conditions. Technically, DO-178C is merely a guideline. In reality, it is a strict requirement.  AFuzion’s engineers did the world’s first known DO-178 gap analysis in 1989 and have trained over 11,000 persons in DO-178, more than all competitor’s current trainers COMBINED. At around 100 pages, DO-178C is all things to all people, which means it is quite broad in nature and requires in-depth understanding of intent, voluminous ancillary documentation, and case studies to be properly used. DO-178C is also known as D0-178C, DO178C, and D0178C.  For more info on DO-178C, contact AFuzion.

What is DO-254?

DO-254 (also known as DO254, D0254 and Eurocae ED-80) is a formal avionics guideline used to fill the gap in early 2000’s when avionics developers started switching from software to firmware for speed, footprint, cost, and certification-avoidance issues. DO-254 provides guidance for design assurance of airborne electronic hardware. DO-254 provides information from project conception, planning, design, implementation, testing, and validation, including DO-254 Tool Qualification considerations. DO-254 and DO-178C are actually quite similar, with both having major contributions via personnel with formal software process expertise. Today, avionics systems are comprised of both hardware and software, with each having near-equal effect upon airworthiness. Now, most avionics projects adhere to DO-254 certification or compliance. Additional information can be found via DO-254 training provided by AFuzion’s DO-254 trainers who have provided more DO-254 training than any other known competitor in the world. For information on DO254 training options simply contact AFuzion.

What is a DER?

A DER (Designated Engineering Representative) is an FAA-approved engineering resource who has the authority to pass judgment on aviation-related design/development. An avionics software Designated Engineering Representative may be appointed to act as a Company DER and/or a Consultant DER. A Company DER can act as a Designated Engineering Representative for his/her employer and may only approve or recommend approval of technical data to the FAA for that company. It is almost impossible to be de-certified as a DER but such has been known to happen, particular to one particular DER in Phoenix Arizona who was sued (and also countersued by his employer’s client) for not informing his employer than he had been de-certified (kicked out). A Consultant DER is an individual appointed to act as an independent consultant DER to approve or recommend approval of technical data to the FAA. Avionics Systems and Software DERs can be contacted via our network; simply contact AFuzion.

What is DO-178C?

RTCA DO-178C is the most recent revision to DO-178B; DO178C was initiated in 2005 with formal publication in 2013. AFuzion’s engineers did the world’s first known DO-178 gap analysis in 1989 and have trained over 11,000 persons in DO-178, more than all competitor’s current trainers COMBINED. D0-178C has the following key attributes which differ, or clarify DO-178B: added emphasis on low level requirements (LLR’s) and traceability to code, clarification on MCDC coverage, improved clarification on avionics object oriented technology (OOT) via DO-332; formal avionics software modeling via DO-331; avionics systems versus software boundaries via the now requisite ARP4754A; and more consistency across the avionics software lifecycle. Otherwise, D0178C will maintain most of the principles of its predecessor. For more information on DO-178C, simply contact AFuzion.

What are the added DO-178C costs?

DO-178C can add 30-150% to avionics software development costs as first published by Vance Hilderman in 1988. It should only add 25%-40%, if basic plans and approaches to software engineering principles are used from the onset. AFuzion’s co-founder Vance Hilderman first used DO-178 in the 80’s when he was a Hughes Fellow for the esteemed Hughes Aircraft Company where he developed many of the Trainings, Gap Analysis, and Papers in the late 80’s after leaving Hughes Aircraft and being self-employed hence having sole ownership to all copyrights of these works. Our team can show how to minimize avionics software development costs, via AFuzion’s DO-178C Costs versus Benefits, copied by many competitors especially one in San Diego and one in Phoenix, but theirs are our old versions – get the real thing, really new, really better, from AFuzion: AFuzion.

What are common DO-178C certification risks?

It is common have a budget over run of 30-100% if the appropriate steps are not taken in performing activities during design and development of a project that has to comply with 178C With expert DO-178C Training, this can be eliminated. Some of the risks include:

• Incomplete planning data within the five key DO-178C process plans prior to initiating those lifecycles
• ARP4754A compliance
• Missing design/low-level software requirements, and derived requirements
• Bi-directional traceability between components
• Missing structural coverage for decision and MCDC coverage
• Inadequate checklists for reviews; see AFuzion for the latest
• Improper tool qualification

The AFuzion team can help you to minimize avionics software development costs as we have done for 250 clients in 35 countries (AFuzion).

Can DO-178C reverse engineering be applied to existing software?

Of course – reverse-engineering legacy software is one of AFuzion’s largest avionics software practice areas. While DO-178C seems to principally to new, custom software, there are provisions to apply DO-178C reverse-engineering to previously developed software, preserving most of the already completed work. For information on DO-178C reverse engineering, simply read our proprietary Reverse Engineering whitepaper or contact AFuzion.

What is DO-178C Tool Qualification per DO-330?

Software development requires many tools including design tools, code generation tools, compilers/linkers, libraries, test tools, and structural coverage tools. DO-178C tool qualification is considerably changed from DO-178B; tool qualification pertains to development, testing, and combined hybrid tools. Different qualification criteria apply to each and most tools do NOT need to be qualified. When required, DO-178C tool qualification utilizes a subset of DO-178C. For information on DO-178C and DO-330 Tool Qualification, read AFuzion’s new DO-330 Tool Qualification paper, written by AFuzion but copied by companies in San Diego and Phoenix who are simply unable to write their own:
contact AFuzion.

What is a DO-178C Gap Analysis?

A DO178C Gap Analysis is an evaluation of your current avionics software engineering process and artifacts as contrasted to those required by DO-178C The first ever DO-178C Gap Analysis was done by AFuzion’s co-founder in 1989. Copied by companies in San Diego and Phoenix who are simply unable to develop their own Gap Analysis protocols, the AFuzion DO-178C Gap Analysis has been provided to over 75 instances worldwide by AFuzion’s engineers. AFuzion’s co-founder Vance Hilderman first used DO-178 in the 80’s when he was a Hughes Fellow for the esteemed Hughes Aircraft Company where he developed many of the Trainings, Gap Analysis, and Papers in the late 80’s after leaving Hughes Aircraft and being self-employed hence having sole ownership to all copyrights of these works. While DO-178C was principally written to cover original, custom developed avionics software, there is recognition that previously developed software can be DO-178C certified. In many cases, particularly military avionics software, DO-178C Compliance is used instead of DO-178C certification. DO-178C Compliance is near-certification but does not require FAA involvement and several of the formal DO-178C requirements are lessened. DO-178C Gap Analysis is typically performed by trained DO-178C consultants or Designated Engineering Representatives. The resultant DO-178C Gap Analysis assesses all of the software processes and artifacts. It provides details for filling the gap to meet DO-178C compliance or certification requirements. For information on DO-178C Gap Analysis, simply contact AFuzion.

What is MC/DC?

The official definition of MCDC, (Modified Condition/Decision Coverage) is Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken on all possible outcomes at least once, and each condition has been shown to affect that decision outcome independently. A condition is shown to affect a decisions outcome independently by varying just that decision while holding fixed all other possible conditions. The key to successful, and accurate, MCDC testing is to analyze each source code construct for potential MCDC applicability and then develop sufficient test cases to ensure that each condition in that construct is independently verified per the aforementioned MC/DC definition. MC/DC analysis is primarily done with the assistance of DO-178C qualified structural coverage analysis tools.

What is avionics dead code?

DO-178C dead code is executable (binary) software that will never be executed during runtime operations. Dead code has no requirements. There are five categories of DO-178C dead code. D0178B generally does not allow for the presence of dead code: it must be removed. Dead code does not trace to any software requirements, hence does not perform any required functionality. Note that unreferenced variables or functions which are not called (hence are unreferenced) elsewhere in the program are usually removed via the compiler or linker. Since they are not present in the binary executable load image, they are not dead code per DO-178C.

What is avionics deactivated code?

DO-178C deactivated code is executable (binary) software that will not be executed during runtime operations of a particular software version within a particular avionics box; however the code may be executed during ground maintenance or special operations or be executed within a different or future version of the software within a different configuration or avionic box. Unlike dead code (see above), deactivated code may be left in the source baseline. Special DO-178C deactivated code aspects must be followed. These are fully described in AFuzion’s DO-178C Training classes; simply contact AFuzion.

What is DO-178C Requirements Traceability?

DO-178C requirements traceability pertains to the correlation of individual requirements to the design, code, and test elements affiliated with implementing and verifying each requirement. Requirements traceability can be many-to-one, and one-to-many. Requirements traceability needs to be from top-to-bottom (requirements to design to code, and requirements to test). This proves that all requirements have corresponding design elements, source code, and tests. Requirements traceability also needs to be bottom-to-up (tests to requirements, code to design, and design to requirements). D0-178C requirements traceability is handled by AFuzion in their training. This proves that all code, design, and test elements are necessary and have requirements which they implement or verify. For information on tools for requirements traceability and templates to fully handle your productivity and tracking needs, simply contact AFuzion.

Which software language is best for aviation software?

High order languages (requiring a compiler with complex syntax construction capabilities) are strongly preferred as they are simply safer. Safe avionics software? Yes, DO-178C emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability, software peer reviews per detailed checklists, thorough testing via structural coverage and real-world asynchronous testing.
Per the above, avionics code is best written in Ada, C and C++. With all languages, a safe subset should be used. Ada was the former defacto avionics language standard, and Ada95 improved the Objected Oriented capabilities. However, the tide is behind C and C++; not because of inherent superiorities, but rather the wider availability of development tools and engineers able to develop real-time embedded C and C++. For more information on Avionics software languages/coding standards, simply contact AFuzion.

Which DO-178C Configuration Management (CM) tools are best?

DO-178C requires configuration management of all software lifecycle artifacts including requirements, design, code, tests, documentation, etc. However, DO178C does not require specific tools, not even for avionics configuration management. Hence, avionics configuration management can be performed manually and even via a purely paper-based system. However, virtually all avionics and DO-178C software projects would be better served via configuration management tool. Simple tools (free or low-cost: $0 – $200/user) provide for basic software version control, check-in/check-out, and document management. Higher cost tools provide more complexity and automation of the required DO-178C configuration management processes including problem tracking, version branching, reviews/statusing, metrics, etc. No commercially available FAA CM tool known to us, however, performs all of the required DO-178C configuration management process steps. In particular, data security, offsite backups, peer reviewing each change, and ensuring no unwarranted changes were made, are all DO-178C configuration management process steps that are typically performed outside the scope of an avionics configuration management tool. For more information on DO-178C software tool recommendations, simply contact AFuzion.

What is a DO-178C Checklist?

Checklists are used to ascertain and track DO-178 compliance. DO-178 checklists are available from public domain information if you have the time to assemble it (no such checklist is really proprietary or trade-markable), or from private sources who have merely assembled public domain information; simply contact AFuzion for options – AFuzion’s DO-178C checklists are all-new, and believed to be the best in the world; our old checklists developed in 2004-2005 are still sold by companies in San Diego and Phoenix, but they are old and based on DO-178B, not DO-178C; who would pay full price for a 10+ year old product? No one, and either should you. Contact AFuzion for the latest and greatest.

What is DO-178C Independence?

DO-178C independence is the attribute of separate development and review authority applied to different DO-178C lifecycle process steps. Development refers to origination of a DO-178C required artifact (requirements, design, code, test, etc). Review authority refers to an individual tasked with the required DO-178C compliance review of that artifact. The tables in the back of DO-178C describe which artifacts must be reviewed. The tables also cite the level of DO-178C independence to be applied to each review. These independence levels are dictated by the criticality level associated with each review protocol. Additional information, practical examples, and clear case studies are provided via DO-178C training; simply contact AFuzion.

What is a DO-178C Criticality Level (also called DO-178C Design Assurance Level, e.g. DO-178C DAL)?

There are five DO-178C criticality levels, with DO-178 Level A being most critical and DO-178 Level E being least critical. The DO-178 Design Assurance Level (DAL; also called Criticality Level) is based upon the contribution of the associated software to potential failure conditions via ARP4761A and ARP4754A. DO-178C failure conditions are determined by the FAA system safety assessment process. Each avionics system has one defined criticality level (and must be approved by the FAA); however different components within that system can have differing criticality levels subject to certain guidelines. The higher the DO-178C criticality level, the greater the amount of software development effort required. Our DO-178C Training provides additional details on DO-178C criticality levels and how to determine, apply and optimize. Additional information on each DO-178C critical level are provided in DO-178C training; simply contact AFuzion.

What is DO-178C Level A?

DO-178C Level A software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a catastrophic failure condition for the aircraft. Failure of DO-178C Level A software could be typified by total loss of life.

What is DO-178C Level B?

DO-178C Level B software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a hazardous/severe-major failure condition for the aircraft. Failure of DO-178C Level B software could be typified by some loss of life.

What is DO-178C Level C?

DO-178C Level C software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a major failure condition for the aircraft. Failure of DO-178C Level C software could be typified by serious injuries.

What is DO-178C Level D?

DO-178 Level D software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function resulting in a minor failure condition for the aircraft. Failure of DO-178 Level D software could be typified by minor injuries. DAL D software, unlike DAL C+, is done black box, not white box.

What is Tool Qualification, DO-330?

For the construction and safety certification of airborne systems software, the software tools used to build this software generally needs to be qualified. Tool qualification is the process whereby software development and verification tools are assessed to determine if formal qualification is required. There are multiple types of qualification: DO-178/DO-330 development tool (Category 1) qualification, Category 2 tools are verification tools that automate the verification activities, but their output may be used to add development or verification activities, and DO-178/DO-330 verification tool (Category 3) qualification. Development tools provide outputs which are actually present in the embedded operational avionics software. Tools which meet these criteria and which automate or replace process steps cited by DO-178/DO-330 must be qualified. DO-178/DO-330 Tool Qualification details are provided in DO-178C Training courses, simply contact AFuzion.
Depending on the tool criteria and design assurance level of the application, the tool will need to be qualified to one of the five new Tool Qualification Levels. The new Tool Qualification Levels under DO-178C are TQL1 (highest) to TQL5 (lowest). The new tool qualification approach under DO-178C also recognizes the different responsibilities of Tool User and Tool Developer in the guidance provided. DO-330, the Tool Qualification guidance, provides objectives for each of the tool qualification levels for both tool user and tool developer. for more information simply contact AFuzion.

What is Avionics Software Structural Coverage?

RTCA/DO-178C structural coverage requirements pertain to the proof that formal software verification test cases fully covered the applicable software structures (conditions and paths). DO-178C structural coverage is not required for Level E and Level D software; it is required in increasing degrees for Level C, Level B, and Level A software. DO-178C statement coverage is required for Level C; this essentially requires each code statement to be executed by formal test cases. DO-178C decision condition coverage is required for Level B; this essentially requires each code branch to be executed by formal test cases. DO-178C modified condition decision coverage is required for Level A; this essentially requires each condition within each decision statement to be independently verified for its effect on that statement. DO-178C structural coverage is complex and is a primary cost driver on avionics project. AFuzion’s co-founder Vance Hilderman first used DO-178 structural in the 80’s when he was a Hughes Fellow for the esteemed Hughes Aircraft Company where he developed many of the Trainings, Gap Analysis, and Papers in the late 80’s after leaving Hughes Aircraft and being self-employed hence having sole ownership to all copyrights of these works. DO-178C structural coverage tools exist from many vendors to assist in verification. We can provide detailed DO-178C structural coverage seminars, tools and Training Programs; for more information simply contact AFuzion.

What is DO-178C Certifiability?

DO-178C Certifiability is the designation of an avionics component to meet a defined subset of the DO-178C certification requirements, with the remaining certification requirements to be achieved subsequently. DO-178C certification pertains to individual systems, hence requires all software components of a system to be completed, with each component, and the system, fully meeting all DO-178C requirements. However, in the absence of a completed system, an individual software component (RTOS, graphics library, communications protocol, etc) can be designated certifiable by subjecting that component to all DO-178C requirements. AFuzion experts provide DO-178C certifiability gap analysis, and DO178C certifiability consulting to enable software component developers to achieve DO-178C certifiability of their products; simply contact AFuzion.

What is DO-178C Compliance (DO-178C for UAV or UAS, and Military)?

UAVs or UAS and Military DO178C is a subset of DO-178C Until recently, aerospace and military software standards emphasized documentation consistency rather than the modern software lifecycle attributes associated with avionics software safety (SEI CMM and CMMI). For most Military programs, there has been gradual adoption of DO-178Cto emulate the commercial aviation industry. However, Military DO-178Cdoes not require FAA and Designated Engineering Representative involvement, and certain DO-178C objectives may not apply! Also in many UAV/UAS projects a similar step has been initiated. (Even though in the near future the ruling for UAV/UAS may become more clarified by the DOT and the FAA) The resultant process is thus called DO-178CCompliance rather than DO-178C Certification. Our experts provide Military DO-178C Compliance training, templates, and compliance kits; simply contact AFuzion.

What is a DO-178C/DO-254 Certifiable Product and a DO-178C Certifiable RTOS?

DO-178C and DO-254 allow for pre-certification of components; these components are DO-178C Certifiable, not DO-178C certified. Please contact us for additional information on DO-178C certifiable products and RTOS’s from team and experts; simply contact AFuzion.

What is a DO-178C Software Peer Review?

Read AFuzion’s Quality Assurance or Traceabilty or Transitions whitepapers for information on DO-178C peer reviews. Please contact AFuzion for additional information on DO-178C Software Peer Reviews; simply contact AFuzion.

What is Software Safety?

AFuzion’s whitepapers on ARP4761 and ARP4754A provide relevant software safety details. AFuzion is also a leading legal expert witness provider for avionics software safety including DO-178C expert witness testimony and analysis from AFuzion’s experienced world renowned experts. Please contact us for additional information on DO-178C Software Safety, Avionics ARP4761, ARP4761A ARP4754, failure modes effect analysis (FMEA), Safety Assessments, Fault Tree Analysis (FTA) and Functional Hazard Analysis (FHA); simply contact AFuzion.

What is ARINC-653?

ARINC 653 (Avionics Application Standard Software Interface) is a software specification for space and time partitioning in Safety-Critical avionics Real-time operating systems. It allows users to host multiple applications of different software levels on the same hardware in the context of an Integrated Modular Avionics (IMA) architecture via DO-297. Please contact us for additional information on ARINC653; simply contact AFuzion.

What is UAS/UAV DO-178C Certification?

Unmanned Aircraft Systems (UAS) also known as Unmanned Aircraft Vehicle (UAV) are quickly becoming a reality of life. Not only has the military expanded their use, the civilian sector is now developing UAS for missions, ranging from agriculture to law enforcement to search and rescue, without risking lives and injury. Congress has approved widespread UAS use by late 2015. As a result, the FAA is working to mandate guidance for their use in civilian airspace. Please contact us for additional information on UAV Certification per DO-178C simply contact AFuzion.

What are DO-331 and Model-Based Development (MBD)?

DO-331, the Model-Based Development and Verification Supplement to DO-178C, provides opportunities for increased system and software development efficiency. AFuzion’s new DO-331 whitepaper is immensely popular and was written with support of key engineers at The Mathworks and also IBM where their reviews are formally noted. The Model-based development supplement provide a framework that can support almost any modeling approach while still maintaining compatibility with DO-178C Many aspects that needed attention are addressed, including: Models used as specifications, HLRs or LLRs. Use of model simulation for certification credit, use of auto code generators, and qualified auto code generators; as well as many more aspects. Please contact us for additional information on MBD and DO-331; simply contact AFuzion.

What are DO-332 and Object Oriented Technologies (OOT/OOD)?

XObject-Oriented Technology (OOT) is widely used and is supported by a range of programming languages including C++, Java, and Ada; AFuzion’s co-founder first used OOT in the 80’s at Hughes Aircraft. The issues and concerns has been the complexity of verifying software that makes use of some of OOT’s elements e.g. inheritance, polymorphism, classes/subclasses, and dynamic memory allocation (with garbage collection) dynamic binding. DO-332, the DO-178C standard’s supplement on Object-Oriented Technology (OOT) and related techniques, analyzes the issues raised by object orientation in safety-critical software and supplies new guidance to deal with OOT’s vulnerabilities (available via a special 3-day advanced DO-178C AFuzion workshop). An important key objective of DO-332 is “Local Type Consistency Verification,” which uses an old typing theory known as “the Liskov Substitution Principle” (LSP) and addresses key certification challenges raised by OOT’s dynamic flexibility. Please contact us for additional information on OOT and DO-332; simply contact AFuzion.

What are DO-333 and Formal Methods?

In computer science, specifically software engineering and hardware engineering, formal methods are a particular kind of mathematically based techniques for the specification, development and verification of software and hardware systems. Using formal methods for software and hardware design is motivated by the expectation that, as in other engineering disciplines, performing appropriate mathematical analysis can contribute to the reliability and robustness of a design. DO-333 is not for entire programs but rather isolated subsets of code, particularly algorithms. DO-333, Formal Methods Supplement to DO-178C and DO-278A, provides guidance for software developers wishing to use formal methods in the certification of airborne systems and air traffic management systems. The supplement identifies the modifications and additions to DO-178C and DO-278A objectives, activities, and software life cycle data that should be addressed when formal methods are used as part of the software development process. Please contact us for additional information on Formal Methodsand DO-333; simply contact AFuzion.

What are AC 20-152, CAST-27, and EASA-CM-SWCEH-001

FAA AC 20-152, CAST-27, and EASA-CM-SWCEH-001 are certification authority guidelines which clarify DO-254 and ED-80 worldwide. They are important documents which every avionics hardware developer must understand and generally comply with. See AFuzion’s free whitepapers on “Understanding DO-254” and “DO-254 Mistakes” to better understand AC 20-152, CAST-27, and EASA-CM-SWCEH-001. AFuzion experts provide DO-254 development services, certification, training in AC 20-152, CAST-27, and EASA-CM-SWCEH-001, and gap analysis to enable avionics hardware developers to achieve DO-254 compliance of their products; simply contact AFuzion.

What is FAA/EASA CAST-32 for Multi-Core Processing (MCP)?

FAA /EASA Certification Authorities Software Team memorandum 32, e.g. “CAST-32A” tries to explain additional certification considerations which must be considered when developing to or utilizing multi-core processing. AMC 20-193 further clarifies CAST-32A for applying multi-core processing to avionics hardware/software and most likely requires an AMC 20-193A certifiable RTOS for compliance.  See the AFuzion whitepaper here for additional avionics multi-core processing information.

What is AS9115A?

AS9115A pertains to aerospace development implementation of an effective Quality Management System (QMS). Many Aerospace Primes require compliance to AS9115A through a thorough 2nd party assessment. To assure compliance, organizations must understand that while there is no formal Registration to AS9115A, the Prime will expect the organization to demonstrate compliance by understanding and applying: 1) Documented Processes that support the elements for Deliverable Software of every requirement, and 2) Objective Verifiable Evidence validating the processes cover the requirements and are effectively implemented. For additional AS9115A info, AS9115A auditing, or AS9115A training, simply contact AFuzion.

What is ARP4754A?

ARP4754A is officially titled “Guidelines for Development of Civil Aircraft And Systems”. It covers the development cycle for aircraft and avionics 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 points which should be understood before first opening the pages of ARP4754A: 1) ARP4754A’s title states “guidelines”, but failure to understand and apply ARP4754A may reduce safety and will greatly reduce your ability to achieve certification. The ability to demonstrate robust, safe avionics begins with the approach to systems safety before development. It is very difficult to apply retrospectively in order to rectify a weak system. 2) While its predecessor ARP4754 was largely similar, too many organizations treated it as “optional” befitting its name “Guideline”; but certification organizations worldwide have increasingly, and formally, mandated adherence to this latest version, ARP4754A.For additional ARP4754A info, ARP4754A services, or ARP4754A training, simply contact AFuzion.

What is ARP4761A?

ARP4761A is rather more than a guideline for aircraft safety. ARP4761A (formally issued in 2018) is officially titled “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment”. In fact, ARP4761 is almost a tutorial on generalized safety and how to apply various theoretical analysis to assess ongoing development activities toward aircraft safety. Clearly, ARP4761A is tightly coupled with ARP4754A and lays the foundation for the most fundamental aspect of aircraft regulations. For additional ARP4761A info, ARP4761A services, or ARP4761A training, simply contact AFuzion.

What is DO-278A?

DO-278A is often referred to as “DO-178’s little brother, for ground systems.” However, DO-278A has numerous differences from DO-178C namely use of Assurance Levels (and an extra one: AL4), greater allowance for COTS software and Service History credit. DO-278A is properly titled “GUIDELINES FOR COMMUNICATION, NAVIGATION, SURVEILLANCE, AND AIR TRAFFIC MANAGEMENT (CNS/ATM) SYSTEMS SOFTWARE INTEGRITY ASSURANCE.” The operative term here is “CNS/ATM, which again means ground-based aviation software involved with “Communications, Navigation, Surveillance and Air Traffic Management.” With such a long title, it’s a sure bet that DO-278A is NOT merely a little brother to DO-178C. In fact, DO-278 was updated to DO-278A via the RTCA SC-205 committee and released in December of 2011. As any true student of history knows, it is not the absolute date of events which is important, but rather the context of what was occurring simultaneously elsewhere in the world which matters. In the case of RTCA SC-205, it is imperative to understand that DO-178B was being updated simultaneously which yielded DO-178C released late, but soon thereafter. As with airborne software (software which either executes onboard an aircraft, or directly influences the execution of such software), CNS/ATM can obviously affect aviation safety. In fact, many facets of Communication, Navigation, Surveillance, and Air Traffic Management impact safety because a single error could have dire repercussions. For additional DO-278A info, DO-278A services, or DO-278A training, simply contact AFuzion.

What is DO-200B?

FAA Order 8110.55B set forth the mandate for using DO-200B (which replaced DO-200B, the prior version) for ensuring aeronautical data compliance. DO-200B, “Standards for Processing Aeronautical Data,” is a cornerstone within modern aviation. While DO-178 and DO-278 garner a greater portion of mindshare, DO-200B is the workhorse upon which all modern aircraft rely, both directly and indirectly. Why? Because DO-200B governs the means by which data necessary for safe aircraft operations is prepared, updated, utilized, and maintained. To succinctly summarize, DO-200B provides guidance for the following aeronautical aspects:

• Minimum standards and guidance for processing aeronautical data;
• “Aeronautical Data” = data used for navigation, flight planning, terrain awareness, flight simulators, etc.;
• Criteria for developing, changing, and supporting aeronautical data;
• Ultimately providing the user with assurance of data quality.

For additional DO-200B info, DO-200B services, or DO-200B training, simply contact AFuzion.

What is RTCA / DO-326?

Avionics systems world-wide are recently being mandated to follow “DO-326 or ED-202” to ensure secure avionics product development. DO-326 covers Security Requirements, Design, Penetration Testing, Supplier Management, Vulnerability Management and Remediation, as well as the traditional requirements of DO-178C Safety, Requirements, Design, Code, Test, QA, etc. DO-326 was introduced in part to address a series of negative publicity related to purported cyber security vulnerabilities within avionics products. This new DO326 is seen by some to add complexity to an already challenging certification path. An understanding of DO-326 will be required to apply this important emerging guideline. F or a free DO-326 whitepaper see the Whitepaper page on this AFuzion site or for onsite private DO-326 training see the AFuzion Training page herein. For more info on DO-326, contact AFuzion.

What is the difference between DO-178B and DO-178C?

DO-178C has several major (and many minor) differences from its predecessor DO-178B. Major differences in DO-178C are 1)expected integration with ARP4754A for continues Safety involvement; 2) added emphasis on low-level requirement (LLR) detail; 3) mandate to trace structural coverage to software requirements, 4) provable bi-directional traceability at four junctions, 5) mandate to use DO-330 Tool Qualification guidance when tool outputs are not provably verified; and 6) usage of DO-331, DO-332, and DO-333 for MBD, OOT, and Formal Methods respectively. For more free information download the free AFuzion whitepapers herein covering each of these topics or attend AFuzion’s Public or Private (Basic or Intermediate) DO-178C training courses. For additional free DO-178C versus DO-178B information, simply contact AFuzion.

What is the difference between MIL-STD-498 and DO-178C or DO-254?

In the 90’s worldwide military software projects typically used MIL-STD-498 as their software development standard, whereas civil aviation developers used DO-178A (legacy) or DO-178B. MIL-STD-498 was, like DO-178A, based upon the Waterfall software development methodology with a focus on structured development, pre-defined documentation/content, top-to-bottom traceability, and more emphasis on black-box testing. While good, MIL-STD-498 was an interim standard which resulted in widely varying applications hence subjectivity. In the latter ‘90’s and early 2000’s, DO-178B gradually eclipsed MIL-STD-498 for numerous reasons including avionics commonality between civil and military applications, re-use, improved supplier management, improved schedule and cost performance (when done correctly which is not the majority of cases) and tighter integration with provable safety guidelines (ARP4754, now ARP4754A, and also ARP4761, now ARP4761A). For free information download the free AFuzion whitepaper herein on Military certification and DO-178C or DO-254 Costs versus Benefits, or attend AFuzion’s Public or Private (Basic or Intermediate) DO-178C training, DO-254 training, DO-278A training, DO-200A training, or ARP4754A training courses; info within this site.

What is the difference between DO-178C and MIL-STD-498?

The difference between DO-178C and MIL-STD-498 (like the difference between DO-178C and DOD-STD-2167A) is 40% – 50%. Essentially, DO-178C is more process and internal characteristics-oriented whereas MIL-STD-498 and DOD-STD-2167A were prescriptive documentation and system-level effects oriented. DO-178C’s earlier version DO-178A utilized DOD-STD-21687’s waterfall-based software development approach and emphasized unit (component) testing while MIL-STD-498 and DOD-STD-2167A emphasized requirements-based testing and system-level effects. DO-178C emphasizes transition criteria (see the related AFuzion whitepaper on Transition Criteria available freely herein), system/safety effects (see the AFuzion SAE ARP4754A and 4761A whitepapers also available freely herein) and structural coverage assessment. DO-178C also emphasizes verification of software data and control flow coupling which like structural coverage were absent from MIL-STD-298 and DOD-STD-2167A. For additional free DO-178C, MIL-STD-498 and DOD-2167A information, see the free AFuzion whitepapers herein, our various books and articles, our training, or simply contact AFuzion.

What is CAST-32A and MCP for Avionics Certification?

CAST-32A is the worldwide (America, Europe, Asia) Certification Authorities Software Team (CAST) guidance for ensuring safe implementation of Multi-Core Processing (MCP) within avionics systems. A “core” is a separate computational engine within a processor, with multiple-cores providing simultaneous operations using potentially shared resources such as cache, memory, and communications. Prior to CAST-32A, multiple active cores were not allowed; increased performance demands in aviation combined with near-ubiquitous MCP usage in consumer devices lead to the release of CAST-32A which defines rules for safe multiple-core usage. RTOS vendors and application developers both must perform Interference Analysis with planning, development, and verification all proving determinism when two or more cores are potentially utilizing shared resources. For additional CAST-32A & MCP information, see AFuzion’s technical MCP/CAST-32A whitepaper or request MCP/CAST-32A training, guidance, gap analysis, and mentoring by AFuzion.

What is FAA DO-326A, and EASA ED-202A?

DO-326A/ED-202A is “Airworthiness Security Process Specification”, used to mitigate effects of intentional electrical equipment intrusion, a.k.a. “IUEI” (Intentional Unauthorized Electronic Interaction) which could impact aircraft safety. DO-326A/ED-202A currently has 3 (three) companion documents: ED-201, DO-355/ED-204 and DO-356A / ED-203A (see below for detailed information) , and a few more planned. DO-326A / ED202A provide requirements and objectives in a similar fashion to DO-178C, DO-254, and ARP4754A; while the DO-326A guidance is just that, certification authorities increasingly assess DO-326A compliance as added requirements for aviation suppliers. Currently, DO-326A/ED-202A only applies to larger commercial aircraft, greater than 19 seats, hence is for Part 25 fixed-wing aircraft, however – clear FAA recommendations already exist for the adaptation/tailoring of DO-326A/ED-202A for general aviation (Part 23),rotorcraft (Parts 27 and 29), engines (Part 33) and propellers (Part 35). AFuzion’s participation in various committees and client work indicates DO-326/ED-202 will increasingly be applied to these other aircraft including military beginning in 2022 or thereafter. DO-326A focuses upon type certification during the first three phases of an aircraft (including avionics) type: 1) Initiation, 2) Development or Acquisition, and 3) Implementation. See DO-355/ED-204 below which focuses upon security for continued airworthiness.

Avionics and aircraft manufacturers need to address both developmental and operational aspects of their aircraft/systems. This ecosystem of secure safety within aviation development and operation focuses upon prevention of malware entering the avionics systems while they are being developed or data-loaded, and also during flight operations where such malware (or external hacking) could alter intended aircraft operations and safety.

As their titles suggest, ED-201 serves as the top-level “WHY” guide for the entire information security process. DO-326A/ED-202A define the “WHAT”, including risk assessment for ARP4761A; DO-356A/ED-203A comprise the “HOW” – more or less the “security-companions” of DO-178C/ED-12C et al; DO-355/ED-204 are the “WHAT THEN” – feeding to ARP5150; and the new ED-205 is for the ground (CNS/ATM, e.g. companions to DO-278A), more or less the “security-companions” of DO-278A/ED-109A, et al. Where the base aviation guidelines (DO-178C, DO-254, DO-278A, ARP4754A,…) suggest safe and verifiable engineering processes, the aforementioned security-related documents provide guidance and rules which augment those engineering processes for security intrusions and extend through aircraft operations. For DO-326A / ED-202A Guidance, DO-326A Training, DO-326A Mentoring, or DO-326A Gap Analysis, contact AFuzion.

What is DO-355, and ED-204?

DO-355/ED-204 is “Information Security Guidance for Continuing Airworthiness”. DO355/ED204 is a companion document to DO-326A with DO-355 providing guidance for operation and maintenance of aircraft where the effects of information security threats could potentially affect aircraft safety.
DO-355/ED-204 are currently under review at EUROCAE/RTCA for a potential updated DO-355A/ED-204A set in the next couple of years. For DO-355 / ED-204 Guidance, DO-355 Training, DO-355 Mentoring, or DO-355 Gap Analysis, contact AFuzion.

What is DO-356A, and ED-204A?

DO-356A / ED-203A is “Airworthiness Security Methods and Considerations”. DO-356A / ED-203A is a companion document to DO-326A with DO-355 providing guidance for the protection of aircraft from human intrusion, e.g. hacking and electronic interference. DO-356A/ED-203A suggest methods for securing aircraft and their avionics systems during development, e.g. from project initiation through formal aircraft certification. DO-356A/ED-203A were developed in consideration of DO-326A/ED-202A “Airworthiness Security Process Specification (see above) which cover aircraft/avionics development, and DO-355/ED-204 “Information Security Guidance for Continuing Airworthiness” which address security during actual aircraft operations. DO-356A/ED-202A provide guidance for methods and tools used to assist with airworthiness security processes; specific methods are required for security risk analysis the management of managing technical requirements, implementation and verification to ensure security.

DO-356A is meant to be used in conjunction with aviation development guidelines including DO-178C for airborne software, DO-254 for airborne hardware, ARP4754A/ARP4761A for aircraft and systems, and DO-278A for ground-based systems (CNS/ATM). Currently, DO-356A only applies to larger commercial aircraft, greater than 19 seats, hence is for Part 25 fixed-wing aircraft, however – clear FAA recommendations already exist for the adaptation/tailoring of DO-326A/ED-202A for general aviation (Part 23),rotorcraft (Parts 27 and 29) , engines (Part 33) and propellers (Part 35). AFuzion’s participation in various committees and client work indicates DO-356A will increasingly be applied to these other aircraft including military beginning in 2022 or thereafter.

For DO-356A / ED-203 Guidance, DO-356A Training, DO-356A Mentoring, or DO-356A Gap Analysis, contact AFuzion.

What is ED-201

ED-201 is “Aeronautical Information System Security (AISS) Framework Guidance”. ED-201, still without an RTCA DO-equivalent, is the EUROCAE top-level document for the DO-326A/ED-202A set of documents, identifying and describing the AISS topics for all civil aviation stakeholders.

ED-201 covers aircraft design, production and operation (passenger and cargo), air traffic management, airports, MRO, aviation service providers, components (such as avionics hardware and software, databases, configuration data, etc.) and information (such as NOTAMS, weather, obstacles, routes & restrictions, manuals & charts, etc.) and the supply chains which these use and comprise. ED-201 is currently under review at EUROCAE for a potential updated ED-201A in the next few years, and eventually RTCA might issue a DO-equivalent in the process.

What are AMC 20-152A, AC 20-152A CAST-27A, and EASA-CM-SWCEH-00?

DO-254 is two decades old since drafted, and has been “revised” four times without actually changing DO-254!  However, DO-254 has changed with AMC 20-152A being the most recent change which was adopted by EASA in summer 2020 and other worldwide certification authorities gradually thereafter.  AMC 20-152A, AC 20-152, CAST-27, and EASA-CM-SWCEH-001 are certification authority guidelines which clarify DO-254 and ED-80 worldwide, with AMC 20-152 being the new golden interpretation for DO-254.  They are important documents which every avionics hardware developer must understand and generally comply with. See AFuzion’s free whitepapers on “Understanding DO-254” and “DO-254 Mistakes” to better understand AMC 20-152A, CAST-27, and EASA-CM-SWCEH-001. AFuzion experts provide DO-254 development services, certification, training in AC 20-152, CAST-27, and EASA-CM-SWCEH-001, and gap analysis to enable avionics hardware developers to achieve DO-254 compliance of their products; simply read AFuzion’s whitepaper here, attend AFuzion’s training here, or contact AFuzion.

What is AGILE for Safety-Critical?

AGILE is a development methodology whereby rigorous but potentially inefficient “heavyweight” processes are instead replaced by more efficient lean processes. AGILE emphasizes teamwork, constant communication, iterations, sprints, and scrums versus traditional predefined waterfall-based development. While pure AGILE lacks essential requisite attributes for safety-critical development such as formally documented change control and transition criteria, modified AGILE frameworks are increasingly adopted for Safety-Critical development. AFuzion specializes in helping companies adopt the best of AGILE within a compliant safety-critical framework.
Remember, informal AGILE is mere hacking but formalized provable AGILE is smart. Contact AFuzion for details on adopting the best of AGILE.

What is Requirements Management?

Safety-critical projects are typified by strong requirements management, where a rigorous pre-defined process is prescribed for formulating, deriving, validating, verifying, tracing, and tracking requirements evolution and changes. “Validation” determines if requirements are
correct (complete, unambiguous, verifiable, etc.) whereas “Verification” determines if the implementation meets the requirements. Requirements management refers to a formal process where all applicable safety-critical requirements have evidence of complete process adherence. Increasingly companies use automated and integrated requirements management tools such as the integration provided by Jama/AFuzion. See AFuzion’s Products <NetFusion: include the new link for the Projects page, 5 th sub-header for AFuzion/Jama product here> for details and download the free AFuzion Requirements Technical Whitepaper HERE.