These changes allow for a less prescriptive method for involvement for FAA, DER and ODA personnel. However, coordination and agreement on the appropriate level of involvement should be documented in the PHAC and submitted early in the program to ensure sufficient oversight and to avoid issues later. It is a good idea to review the LOFI worksheet in Appendix C of this Order, together with your FAA or ODA representative, and to include this evaluation in the appendix of your PHAC to show justification for the level of involvement reviews and schedule defined in your plan.
RTCA/DO-178, also known as Eurocae ED-12: Software Considerations in Airborne Systems and Equipment Certification:. RTCA is the acronym for Radio Technical Commission for Aeronautics and is located at 1828 L Street, NW, Suite 805, Washington, D.C. 20036. RTCA/DO-178 was developed by the commercial avionics industry to establish software guidelines for avionics software developers. The first version, DO-178 covered the basic avionics software lifecycle. 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-178 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-178 is merely a guideline. In reality, it is a strict requirement. At around 100 pages, DO-178 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.
Faa Job Aid Conducting Software Reviews
DO-254 (also known as DO254, D0254 and Eurocae ED-80) is a formal avionics standard which 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-178 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 the DO-254 trainers. For information on DO254 training options simply contact us.
A DER (Designated Engineering Representative) is an appointed 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. 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 us.
RTCA DO-178C is the latest revision to DO-178; DO178C was initiated in 2005 with formal publication in 2013. Our DERs have provided input to DO178C and also participate in the ongoing committee meetings. D0-178C will have the following key attributes which differ, or clarify DO-178B: improved clarification on avionics object oriented technology; formal avionics software modeling; avionics systems versus software boundaries; more consistency across the avionics software lifecycle; and consolidate various RTCA avionics documents. Otherwise, D0178C will maintain most of the principles of its predecessor. For more information on DO-178C, simply contact us.
DO-178 can add 30-150% to avionics software development costs. It should only add 25%-40%, if basic plans and approaches to software engineering principles are used from the onset. Our team can show how to minimize avionics software development costs.
Yes, while DO-178 applies principally to new, custom software, there are provisions to apply DO-178 reverse-engineering to previously developed software, preserving most of the already completed work.
DO178 Gap Analysis is an evaluation of your current avionics software engineering process and artifacts as contrasted to those required by DO-178. While DO-178 was principally written to cover original, custom developed avionics software, there is recognition that previously developed software can be DO-178 certified. In many cases, particularly military avionics software, DO-178 Compliance is used instead of DO-178 certification. DO-178 Compliance is near-certification but does not require FAA involvement and several of the formal DO-178 requirements are lessened. DO-178 Gap Analysis is typically performed by trained DO-178 consultants or Designated Engineering Representatives. The resultant DO-178 Gap Analysis Roadmap assesses all of the software processes and artifacts. It provides details for filling the gap to meet DO-178 compliance or certification requirements. For information on DO-178 Roadmaps and Analysis, visit our Gap Analysis.
DO-178 dead code is executable (binary) software that will never be executed during runtime operations. Dead code has no requirements! 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-178.
DO-178 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-178 deactivated code aspects must be followed. These are fully described in our DO-178 Training.
High order languages (requiring a compiler with complex syntax construction capabilities) are strongly preferred as they are simply safer. Safe avionics software? Yes, DO-178 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.
There are five DO-178 criticality levels, with DO-178 Level A being most critical and DO-178 Level E being least critical. The DO-178 criticality level is based upon the contribution of the associated software to potential failure conditions. DO-178 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-178 criticality level, the greater the amount of software development effort required. Our DO-178 Training provides additional details on DO-178 criticality levels and how to determine, apply and optimize.
DO-178 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-178 Level A software could be typified by total loss of life.
DO-178 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-178 Level B software could be typified by some loss of life.
DO-178 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-178 Level C software could be typified by serious injuries.
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.
DO-178 Level E software is software whose anomalous behavior, as shown by the system safety assessment process, would cause or contribute to a failure of system function with no effect on aircraft operational capability or pilot workload. Failure of DO-178 Level E software would have no impact on passenger or aircraft safety. Approximately 10% of avionics systems and 5% of avionics software code must meet DO-178 Level E criteria (note however that the amount of DO-178 Level E source code is increasing due to passenger entertainment and internet communications subsystems that are currently designated Level E; it is deemed likely by us that the criticality levels of these systems will increase due to integration with other, more critical, avionics systems).
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-178 Training courses. 2ff7e9595c
Comments