Search NASA⌕ Search

SEARCH · Search NASA

Results for “DO-178C”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

13 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Certification of Safety-Critical Software Under DO-178C and DO-278A

The RTCA has recently released DO-178C and DO-278A as new certification guidance for the production of airborne and ground-based air traffic management software, respectively. Additionally, RTCA special committee SC-205 has also produced, at the same time, five other companion documents. These documents are RTCA DO-248C, DO-330, DO-331, DO- 332, and DO-333. These supplements address frequently asked questions about software certification, provide guidance on tool qualification requirements, and illustrate the modifications recommended to DO-178C when using model-based software design, object oriented programming, and formal methods. The objective of this paper is to first explain the relationship of DO-178C to the former DO-178B in order to give those familiar with DO- 178B an indication of what has been changed and what has not been changed. With this background, the relationship of DO-178C and DO-278 to the new DO-278A document for ground-based software development is shown. Last, an overview of the new guidance contained in the tool qualification document and the three new supplements to DO-178C and DO-278A is presented. For those unfamiliar with DO-178B, this paper serves to provide an entry point to this new certification guidance for airborne and ground-based CNS/ATM software certification.

Jacklin, Stephen A.↗
NASA NTRS2013

Making the Implicit Explicit: Towards an Assurance Case for DO-178C

For about two decades, compliance with Software Considerations in Airborne Systems and Equipment Certification (DO-178B) has been the primary means for receiving regulatory approval for using software on commercial airplanes. A new edition of the standard, DO-178C, was published in December 2011, and regulatory bodies have started the process towards recognizing this edition. The stated purpose of DO-178C remains unchanged from its predecessor: providing guidance “for the production of software for airborne systems and equipment that performs its intended function with a level of confidence in safety that complies with airworthiness requirements.” Within the text of the guidance, little or no rationale is given for how a particular objective or collection of objectives contributes to achieving this purpose. Thus the assurance case for the document is implicit. This paper discusses a current effort to make the implicit explicit. In particular, the paper describes the current status of the research seeking to identify the specific arguments contained in, or implied by, the DO-178C guidance that implicitly justify the assumption that the document meets its stated purpose.

Holloway, C. Michael↗
NASA NTRS2012

Towards Understanding the DO-178C / ED-12C Assurance Case

This paper describes initial work towards building an explicit assurance case for DO-178C / ED-12C. Two specific questions are explored: (1) What are some of the assumptions upon which the guidance in the document relies, and (2) What claims are made concerning test coverage analysis?

Holloway, C M.↗
NASA NTRS2015

Explicate '78: Uncovering the Implicit Assurance Case in DO-178C

For about two decades, compliance with Software Considerations in Airborne Systems and Equipment Certification (DO-178B/ED-12B) has been the primary means for receiving regulatory approval for using software on commercial airplanes. A new edition of the standard, DO-178C/ED-12C, was published in December 2011, and recognized by regulatory bodies in 2013. The purpose remains unchanged: to provide guidance 'for the production of software for airborne systems and equipment that performs its intended function with a level of confidence in safety that complies with airworthiness requirements.' The text of the guidance does not directly explain how its collection of objectives contributes to achieving this purpose; thus, the assurance case for the document is implicit. This paper presents an explicit assurance case developed as part of research jointly sponsored by the Federal Aviation Administration and the National Aeronautics and Space Administration.

Holloway, C. Michael↗
NASA NTRS2014

Formal Methods Case Studies for DO-333

RTCA 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. This report presents three case studies describing the use of different classes of formal methods to satisfy certification objectives for a common avionics example - a dual-channel Flight Guidance System. The three case studies illustrate the use of theorem proving, model checking, and abstract interpretation. The material presented is not intended to represent a complete certification effort. Rather, the purpose is to illustrate how formal methods can be used in a realistic avionics software development project, with a focus on the evidence produced that could be used to satisfy the verification objectives found in Section 6 of DO-178C.

Cofer, Darren↗
NASA NTRS2010

Guidance for Using Formal Methods in a Certification Context

This paper discusses some of the challenges to using formal methods in a certification context and describes the effort by the Formal Methods Subgroup of RTCA SC-205/EUROCAE WG-71 to propose guidance to make the use of formal methods a recognized approach. This guidance, expected to take the form of a Formal Methods Technical Supplement to DO-178C/ED-12C, is described, including the activities that are needed when using formal methods, new or modified objectives with respect to the core DO-178C/ED-12C document, and evidence needed for meeting those objectives.

Brown, Duncan↗
NASA NTRS2014

IKOS: A Framework for Static Analysis based on Abstract Interpretation (Tool Paper)

The RTCA standard (DO-178C) for developing avionic software and getting certification credits includes an extension (DO-333) that describes how developers can use static analysis in certification. In this paper, we give an overview of the IKOS static analysis framework that helps developing static analyses that are both precise and scalable. IKOS harnesses the power of Abstract Interpretation and makes it accessible to a larger class of static analysis developers by separating concerns such as code parsing, model development, abstract domain management, results management, and analysis strategy. The benefits of the approach is demonstrated by a buffer overflow analysis applied to flight control systems.

Abstract Interpretation↗
NASA NTRS2015

Understanding and Evaluating Assurance Cases

Assurance cases are a method for providing assurance for a system by giving an argument to justify a claim about the system, based on evidence about its design, development, and tested behavior. In comparison with assurance based on guidelines or standards (which essentially specify only the evidence to be produced), the chief novelty in assurance cases is provision of an explicit argument. In principle, this can allow assurance cases to be more finely tuned to the specific circumstances of the system, and more agile than guidelines in adapting to new techniques and applications. The first part of this report (Sections 1-4) provides an introduction to assurance cases. Although this material should be accessible to all those with an interest in these topics, the examples focus on software for airborne systems, traditionally assured using the DO-178C guidelines and its predecessors. A brief survey of some existing assurance cases is provided in Section 5. The second part (Section 6) considers the criteria, methods, and tools that may be used to evaluate whether an assurance case provides sufficient confidence that a particular system or service is fit for its intended use. An assurance case cannot provide unequivocal "proof" for its claim, so much of the discussion focuses on the interpretation of such less-than-definitive arguments, and on methods to counteract confirmation bias and other fallibilities in human reasoning.

Rushby, John↗
NASA NTRS2017

Formal Methods Tool Qualification

Formal methods tools have been shown to be effective at finding defects in safety-critical digital systems including avionics systems. The publication of DO-178C and the accompanying formal methods supplement DO-333 allows applicants to obtain certification credit for the use of formal methods without providing justification for them as an alternative method. This project conducted an extensive study of existing formal methods tools, identifying obstacles to their qualification and proposing mitigations for those obstacles. Further, it interprets the qualification guidance for existing formal methods tools and provides case study examples for open source tools. This project also investigates the feasibility of verifying formal methods tools by generating proof certificates which capture proof of the formal methods tool's claim, which can be checked by an independent, proof certificate checking tool. Finally, the project investigates the feasibility of qualifying this proof certificate checker, in the DO-330 framework, in lieu of qualifying the model checker itself.

Wagner, Lucas G.↗
NASA NTRS2021

Retrospectively Documenting Satisfaction of the Overarching Properties: An Exploratory Prototype

Software-intensive aviation systems are typically developed in accordance with recognized development process, safety analysis, and software development standards such as SAE ARP4754A, SAE ARP4761, and RTCA DO-178C. Efforts to streamline assurance processes and make them flexible enough to handle future assurance challenges have produced the Overarching Properties (OPs) for airworthiness approval. Each of the three OPs is a property systems must possess to be certifiable. There is no mandated means of documenting possession of the OPs. To explore possible means, we have prepared retrospective documentation showing that a specimen software system possesses the OPs. The specimen system, Safeguard, enforces geofencing restrictions on unmanned aerial vehicles. Our OP-possession case for its airborne component comprises eight arguments in the Goal Structuring Notation (GSN): a main argument for each OP and five cross-cutting auxiliary arguments. We present this argument as an example for discussion and further research, e.g., into means of assessing OP possession.

safety case↗
NASA NTRSDate not supplied

Certification Considerations for Adaptive Stress Testing of Airborne Software

eduAdaptive Stress Testing (AST) has shown promise in identifying errant corner cases in complex software used in aerospace applications including Flight Management Systems (FMS). The strength of AST is performing test-based verification of complex aerospace software intensive systems at scale in simulated operational environments.Simulating and capturing the realistic operational complexities in integrated verification environments may exposeflaws in the softwareprior to field deployment, whereas the software may perform just fine to traditional requirements-basedunit and component level testing.AST can be used to test the whole system.Individual components may behave safely, but together can result in complex interactions and emergent failures, so it is important to test at the integrated system level.Motivated by the observed benefitsat the prototype proof of concept scale, this paper considers how AST may be integrated into a production workflow and used to generate objective evidence in a processthat delivers certified aerospace software.The research includes evaluation of alignment with both DO-178C and Overarching Properties(OP). The paper addresses questions such as “where should AST fit in the Plan for Software Aspects of Certification (PSAC) and Software Verification Plan (SVP), what aspects of AST do not fit, and what objectives does it satisfy?” The paper concludes that AST is in fact useful at locating errors in complex airborne application software and in doing so provides benefits to suppliers and end users. Furthermore, AST appears appropriate to add value in both DO-178Cbased and Overarching Properties based certification approaches.

certification↗
NASA NTRS2022

Run Time Assurance for Electric Vertical Takeoff and Landing Aircraft

NASA is conducting research to demonstrate and evaluate the application of Run Time Assurance (RTA) as a means to assure safety in Electric Vertical Takeoff and Landing (eVTOL) aircraft with highly automated or autonomous flight capability supervised by a single onboard pilot. The work described in this report demonstrates an application of RTA and examines the implications for design and analysis of aircraft functions and systems; aircraft safety hazards; safety assurance; development assurance; and pilot tasks and performance. This research effort also seeks to assess the efficacy of the combined application of traditional Functional Hazard Analysis (FHA) and the more modern System Theoretic Process Analysis (STPA) techniques to perform hazard analyses on aircraft with complex automated and autonomous systems and an onboard pilot. During the research effort we developed architectural designs of two alternate eVTOL aircraft, generally following the process characterized in the SAE standards ARP4754 and ARP4761. The design has focused on the control architectures of these aircraft, which are identical except that one incorporates RTA techniques to reduce the criticality of some key software components. Artifacts of this process include a taxonomy of aircraft-level functions, aircraft-level architecture diagrams, aircraft-level functional hazard assessments (AFHA), function allocations onto aircraft systems and subsystems, functional block diagrams for a select set of control-related functions, and system-level functional hazard assessments (SFHA) for those functions. This project has highlighted the notion that DAL D is something of a sweet spot for low-confidence controllers in an RTA-based design. Among the many activities described in DO-178C, the activities related to requirement verifiability, algorithmic accuracy, and test coverage can be the most challenging for the kinds of advanced control techniques that may be desirable in novel UAM designs, such as adaptive control, machine-learning, artificial intelligence, numerical search, and Monte Carlo based algorithms. Moreover, the standard requires that development teams demonstrate that errors leading to unacceptable failure conditions have been removed from the software. The RTA architecture, which cordons off the low-confidence function, makes it much easier to show this for these kinds of algorithms. With regard to the use of STPA and FHA as complementary hazard analysis techniques, our research effort led us to the conclusion that STPA should be used to derive requirements for hardware and software systems and/or components. Also, STPA is a natural complement to other processes in ARP4754A involving design studies and iteration.

Run-time assurance↗
NASA NTRS2015

A Flexible and Non-instrusive Approach for Computing Complex Structural Coverage Metrics

Software analysis tools and techniques often leverage structural code coverage information to reason about the dynamic behavior of software. Existing techniques instrument the code with the required structural obligations and then monitor the execution of the compiled code to report coverage. Instrumentation based approaches often incur considerable runtime overhead for complex structural coverage metrics such as Modified Condition/Decision (MC/DC). Code instrumentation, in general, has to be approached with great care to ensure it does not modify the behavior of the original code. Furthermore, instrumented code cannot be used in conjunction with other analyses that reason about the structure and semantics of the code under test. In this work, we introduce a non-intrusive preprocessing approach for computing structural coverage information. It uses a static partial evaluation of the decisions in the source code and a source-to-bytecode mapping to generate the information necessary to efficiently track structural coverage metrics during execution. Our technique is flexible; the results of the preprocessing can be used by a variety of coverage-driven software analysis tasks, including automated analyses that are not possible for instrumented code. Experimental results in the context of symbolic execution show the efficiency and flexibility of our nonintrusive approach for computing code coverage information

DO-178C↗