Search

In this paper, a comparison of flight path planning algorithms is presented to solve three-dimensional planning problem for a typical flight path scenario for UAV indoor and outdoor applications with oversight into general aviation and paid transport. The algorithms consider the performance of the navigation sensors and expected departure and arrival procedures which use the existing navigation means (VOR, NDB, ILS, GPS). The cruise situation is simplified to GPS navigation and obstacle avoidance. We choose to analyze the selected algorithms from the point of view of the certification issues according to the existing HW and SW requirements on determinism and time consumption. The analysis is made from the point of view of DO-178 standard. We describe the Artificial Intelligence phenomena and discuss the determinism of the currently used algorithms for flight-path panning. Within our work we focus on and summarize advantages and disadvantages of Breadth First Search, A*, Iterative Deepening A*, Theta*, and RRT* algorithms. Their reasoning process and path selection methodology with perspective of aerospace requirements are evaluated. Our main focus will be on the randomization element and uncertainty of these algorithms. We will also describe selected evaluation parameters required by FAA and EASA Technical Standard Order (TSO) documents on electronic systems and what are the conflicts between these requirements and the natural principle of the existing path-planning algorithms.

The RTCA/DO-330 “Software Tool Qualification Consideration” is released after the RTCA/DO-178B was widely used for tool qualification in the latest 20 years. In the RTCA/DO-178C collection, the RTCA/DO-330 is used together with RTCA/DO-178C to define the tool qualification requirements for airborne software development. This paper compares and analyses the different requirements in RTCA/DO-178B and RTCA/DO-178C+DO-330 to provide an indication of what are the new requirements and what has not been changed. For those unfamiliar with the tool qualification requirements in RTCA/DO-178C and RTCA/DO-330, this paper serves to provide an entry point to this new certification guidance.

In this paper, the verification approach developed in accordance with the DO-178B certification requirements of the software of the Unmanned Aerial Vehicle’s (UAV) Flight Control Computer (FCC) and the lessons learned from this approach are presented. The software verification process is a process that is used to verify how the aircraft's flight control computer behaves according to specified requirements and is used to verify that it does not produce unexpected results. The paper will first describe the software architecture, and then the types of tests developed in accordance with the software architecture. Then, test levels will be compared according to different testing parameters. Afterwards, the information regarding the management of test cases will be reviewed in detail with their different scenarios. The traceability controls and the importance of using traceability while writing the test cases and how to blend a traceability inside a test case will be explained. The studies on structural coverage analysis will be covered in a different section. This whole process can be made automated. To help automate the process, various tools are used. These tools also need to be tested, meaning they need to be qualified. Section 8 talks about this. Finally, lessons learned from the DO-178B certification process will be presented at the end of the paper.

Modern vehicles can have millions of lines of software, for vehicle control, infotainment, etc. The correctness and quality of the software play a key role in the safety of whole vehicles. In order to assure the safety, engineers give an effort to prove correctness of individual subsystems or their integration using testing or verification methods. One needs to eventually certify that the developed vehicle as a whole is indeed safe using the artifacts and evidences produced throughout the development cycle. Such a certification process helps to increase the safety confidence of the developed software and reduce OEM's liability. However, software certification in automotive domain is not yet well established, compared to other safety-critical domains, such as avionics and medical devices. At the same time, safety-relevant standards and techniques, including ISO 26262 and assurance cases, have been well adopted. It finally promotes the adoption and development of software certification in the automotive industry. In this paper, we first present a survey of recent research in the domains of aviation, medical devices, and railway systems. After this survey, we summarize current status as well as existing challenges in the automotive software certification. Assurance cases are also presented as a promising technique to automotive software certification. Language: en

Software testing is one of the most important ways to protect civil aviation safety and reliability of software for airborne equipments. D-178B/C standards are used to assure safety of avionics software and control systems and provide certificates according to safety criteria. This paper describes two different phases to achieve structural coverage analysis using DO-178B/C standards. Analysis of structural coverage can be done using to capture the amount of code which is covered of the airborne software. The first phase which contains the instrumentation procedure which instrument the source code at execution time and second phase is generating a report which specifies that which portion of source code is executed and which one is not in the form of percentage. Implementation is done for first metric which is statement coverage.

Statecharts are an established mechanism to model reactive, state-oriented behavior of embedded systems. We here present an approach to automatically generate code from statecharts, with a particular focus on readability and ease of matching the generated code with the original model. This not only saves programming effort and reduces the error rate compared to manual coding, but it also facilitates the task of verifying that the code does what it is supposed to do. We have implemented this approach for the SCCharts language in an open-source framework. A user study confirmed that the generated code tends to be more readable than code from other code generators.

The work presented in this paper takes place in the context of the testing activities of safety critical Air Management Systems for civilian and military aircraft. The applicative software of such systems is developed following DO-178 guidelines, using a model-based approach built on the SCADE modeling language. In the current V&V process, Test Cases (TCs) specify test conditions and expected outcomes on internal data-flows of the SCADE model. TCs are then implemented in the form of concrete Test Procedures (TPs) that are run against the executable object code and can thus only drive the main inputs of the program. TP implementation is a complex task, today performed manually. This paper proposes an approach to assist the generation of TPs, based on a purpose-built domain specific language for test case specification, from which synchronous observers are generated and composed with the applicative software SCADE model. TPs are then obtained by using a model checker to refute the observer output, yielding, after some post-processing a trace of main input values extended with expected outcome checks.

The rapid growth in the use of software in airborne systems and equipment in the early 1980s resulted in a need for industry-accepted guidance for satisfying airworthiness requirements [1]. To assure the reliability of the software and to ultimately ensure the safety of passengers, the U.S. Federal Aviation Administration (FAA) has imposed software certifcation suited to the development of safety-critical systems. The FAA has accepted guidelines developed by the Radio Technical Commission for Aeronautics (RTCA) that respond to the necessity of reliability and safety, which are vital in this feld: DO-178B/EUROCAE ED-12B (DO-178B), titled Software Considerations in Airborne Systems and Equipment Certifcation [1]. DO-178B prescribes design assurance guidance for airborne software. The aim of DO-178B is to assure that software developed for avionics systems is reliable and safe to use in fight [2].

RTCA document DO-297, Integrated Modular Avionics (IMA) Design Guidance and Certification Considerations, is one of several documents that are key to the approval of avionics and ultimately the certification of the host aircraft. The European Organisation for Civil Aviation Equipment (EUROCAE) equivalent of DO-297 is ED-124. The need for DO-297 is derived from the emergence of pioneering IMA architectures on the Airbus A-380 and Boeing B-787. Although DO-297 was too late to be part of the certification basis for these aircraft, the lessons learned from them did guide, in part, the content of DO-297. According to DO-297, IMA is a “shared set of flexible, reusable, and interoperable hardware and software resources that, when integrated, form a platform that provides services, designed and verified to a defined set of safety and performance requirements, to host applications performing aircraft functions”.

The development of industrial software systems increasingly requires safety certification. The certification process causes huge efforts and has to be repeatedly executed for changes of the systems. At the same time, many of the software architectures are developed in a component-based style. This paper presents the results of an industrial software development and certification project in the railway domain. It is a component-based development project that was designed to be certifiable in two steps with this new approach. First, the core of the system will be developed and certified. Secondly, new or adapted plug-in components will be certified individually. Thus, the re-certification effort is reduced to the certification effort of a single component.

Avionic systems for communication, navigation, and flight control, and many other functions are complex and crucial components of any modern aircraft. Present day avionic systems are increasingly based on computers and a growing percentage of system complexity can be attributed to software. An error in the software of a safety-critical avionic system could lead to a catastrophic event, such as multiple deaths and loss of the aircraft. To demonstrate compliance with airworthiness requirements, certification agencies accept the use of RTCA document DO-178 for the software development. Avionics software development is typically complex and is traditionally reliant on a strict plan-driven development process, characterized by early fixture of detailed requirements and late production of working software. In this process, requirement changes and solving software errors can lead to much rework, and create a risk of budget and schedule overruns. This raises the question whether avionics software development could benefit from the application of agile approaches. Based on the results of three activities: (1) a literature study on industrial experience with the use of agile methods in a DO-178 context, (2) an expert assessment of the DO-178 objectives, and (3) a survey conducted among European avionics industry, an outline is presented of an agile development process, where Scrum is extended to achieve the DO-178 objectives. The application of agile methods is expected to support frequent delivery of working software and ability to respond to changes, resulting in reduced risk of budget and schedule overruns.

Ensuring that avionics software meets safety requirements at each development stage is very important to warrant the safe operation of an avionics system. Many safety requirements are imposed by various standards and industrial regulations that must be met by avionics software. One of such standards is DO-178B/C, which provides guidelines e.g., development process and objectives to satisfy in development activities for meeting safety requirements. This paper presents a modeling methodology including a UML profile for specifying safety requirements on a component-based architecture model and a set of design guidelines on avionics software. These safety requirements were identified from both standards mainly DO-178B/C and current engineering practices in the domain of avionics systems. The methodology automatically enforces these safety requirements. We have applied the methodology on an industrial autopilot system, and several previously uncaught faults were revealed. Copyright © 2014 John Wiley & Sons, Ltd.

Software for commercial aircraft is subject to the stringent certification processes described in the DO-178B standard, "Software Considerations in Airborne Systems and Equipment Certification." Issued in 1992, this document focuses strongly on the verification process, with a major emphasis on testing. In 2005, the avionics industry initiated an effort to update DO-178B, in large part to accommodate development practices (including formal verification techniques) that had matured since its publication. A revised standard, DO-178C, was issued in late 2011, incorporating new guidance that allows formal verification to replace certain forms of testing. In this article, the authors describe some of the new objectives and activities in the area of formal methods, explain how these methods may be used instead of testing in a DO-178C context, and summarize the practical experience of Dassault-Aviation and Airbus in successfully applying the new DO-178C approach. The first Web extra at http://youtu.be/tRtK4xOK-8o is part 1 of a video talk by Hervé Delseny, describing Airbus's use of formal methods to verify avionics software and summarizing the integration of formal methods in the upcoming ED-12/DO-178 issue C. The second Web extra at http://youtu.be/BVI5J1GAQ30 is part 2 of a video talk by Hervé Delseny, describing Airbus's use of formal methods to verify avionics software and summarizing the integration of formal methods in the upcoming ED-12/DO-178 issue C. The third Web extra at http://youtu.be/U3G1ZOoqg78 is part 3 of a video talk by Hervé Delseny, describing Airbus's use of formal methods to verify avionics software and summarizing the integration of formal methods in the upcoming ED-12/DO-178 issue C. The fourth Web extra at http://youtu.be/WtlqS-JOHrA is part 4 of a video talk by Hervé Delseny, describing Airbus's use of formal methods to verify avionics software and summarizing the integration of formal methods in the upcoming ED-12/DO-178 issue C.

DO178 is a standard for avionic software for the aerospace industry which can be used as a guidance to determine if the software product will perform reliability in airborne environment. The standard has 5 different certification levels each of which has a certain set of objectives. The certification levels are determined depending on how critical the system or subsystem is. To address DO- 178 objectives, companies need a defined systems and software engineering process that can delineate workflows, inputs, outputs, roles and responsibilities. The major objectives outlined in the DO-178 standard include; - Requirements engineering - Design and development. - Validation and verification - Engineering tasks, such as configuration and change management In this presentation, we will try to explain the main principles of the DO178 standard very briefly and try to give an insight about how the objectives of this standard can be satisfied.

Navy equipment software is safety critical software. Software safety is an important factor for naval equipment achieving combat mission successfully. According to characteristics of navy equipment system and its software, this paper has proposed a software safety engineering method basing on system theory. Further, it has described safety tasks in each stage included in software lifecycle. Finally, according to the goal of software safety, it has presented software safety management system to ensure safety of naval equipment software. The research has positive significance for healthy development of navy equipment software.

Airborne systems are considered to compose a highly complex network of interconnected Cyber-Physical Systems (CPS). Following the ARP-4754A development guidelines, a series of multidisciplinary engineers have to decompose system, hardware and software requirements in order to validate their correctness. System intrinsic complexity though, imposed by CPS(s), constitutes the certification of airborne systems a difficult, time-consuming and often expensive task. In the same line, requirements traceability, validation and verification is considered to be a crucial part of certification processes for both hardware (DO-254) and software (DO-178C) components. In this paper we review challenges and solutions for software certification under the DO-178C standard using formal verification in line with new CPS analysis evolution. We describe current model-based design methodologies followed today in the aerospace domain and comment on new approaches and techniques that could accelerate the software certification processes with respect to CPS(s) requirements.

Software safety must deal with the principles of safety management, safety engineering and software engineering for developing safety-critical computer systems, with the target of making the system safe, risk-free and fail-safe in addition to provide a clarified differentaition for assessing and evaluating the risk, with the principles of software risk management. Problem statement: Prevailing software quality models, standards were not subsisting in adequately addressing the software safety issues for real-time safety-critical embedded systems. At present no standard framework does exist addressing the safety management and safety engineering priniciples for the development of software safety in safety-critical computer systems. Approach: In this study we propose a methodological framework involving safety management practices, safety engineering practices and software development life cycle phases for the development of software safety. In this framework we make use of the safety management practices such as planning, defining priniciples, fixing responsibilities, creteria and targets, risk assessment, design for safety, formulating safety requirements and integrating skills and techniques to address safety issues early with a vision for assurance and so on. In this framework we have also analysed integration of applicability of generic industrial heirarchy and software development heirarchy, with derived cyclical review involving safety professionals generating a nodal point for software safety. Results: This framework is applied to safety-critical software based laboratory prototype Railroad Crossing Control System (RCCS) with a limited complexity. The results have shown that all critical operations were safe and risk free. Conclusion: The development of software based on the proposed framework for RCCS have shown a clarified and improved safety-critical operations of the overall system peformance.

One of the biggest challenges in multi-normative organizations, in the field of industrial areas like aerospace and defense, is to make all technical regulations compatible. A huge amount of effort is spent by these organizations to maintain their accreditations periodically. Although each standard has its own purpose and appraisal procedure, it seems to be useful to know about the commonalities among norms, as well as extracting best practices from the application of its requirements to the accomplishment of the others. Particularly the INCOSE Systems Engineering Handbook can be considered as general lifecycle framework for systems, the Capability Maturity Model for Integration (CMMI) is a reference model to assess the process efficiency and RTCA DO-178B can be used as basis for software certification. In literature very few contributions can be found to explain how these standards interrelate and how they can work together to achieve more efficient organizations. This experience paper aims to shed some light on the common aspects of these three standards applicable for the production of on-board software. The combination proposal included in this paper is the result of the experience of the author in the application of these standards (and others) in the military avionics domain. Conclusions could be useful for their application to other domains or even for future potential combined accreditations.

This paper is the Software Hazard Analysis (SWHA) which will study the managerial process and the technical methode and techniques inherent in the performance of software safety task within the Military Aircraft System Safety program. This SWHA identifies potential hazardous effects on the software intensive systems and provides a comprehensive and qualitative assessment of the software safety. The purpose of this paper is to identify safety critical functions of software in Military A/C. The identified software hazards associated with the design or function will be evaluated for risks and operational constraint to further improve the software design requirement, analysis and testing efforts for safety critical software. This common SWHA, the first time analysis in KOREA, was review all avionics OFP(Operational Flight Program), and focus only on software segments which are safety critical. This paper provides a important understanding between the customer and developer as to how the software safety for the Military A/C will be accomplished. It will also provide the current best solution which may as one consider the necessary step in establishing a credible and cost-effective software safety program.

Software testing is one of the most important ways to protect and enhance civil aviation safety and reliability of software on airborne equipment. Among software testing, test coverage analysis is absolutely necessary. Therefore, based on DO-178B standard, this paper studies the method of software texting coverage analysis. With the example of TCAS software texting established in the test environment of hardware and the testing tools of software, we complete the software test coverage analysis

Several safety-related standards exist for developing and certifying safety-critical systems. System safety assessments are common practice and system certification according to a standard requires submitting relevant system safety information to appropriate authorities. The RTCA DO-178B standard is a software quality assurance, safety-related standard for the development of software aspects of aerospace systems. This research introduces an approach to improve communication and collaboration among safety engineers, software engineers, and certification authorities in the context of RTCA DO-178B. This is achieved by utilizing a Unified Modeling Language (UML) profile that allows software engineers to model safety-related concepts and properties in UML, the de facto software modeling standard. A conceptual meta-model is defined based on RTCA DO-178B, and then a corresponding UML profile, which we call SafeUML, is designed to enable its precise modeling. We show how SafeUML improves communication by, for example, allowing monitoring implementation of safety requirements during the development process, and supporting system certification per RTCA DO-178B. This is enabled through automatic generation of safety and certification-related information from UML models. We validate this approach through a case study on developing an aircraft's navigation controller subsystem.

In recent decades, safety has emerged as a major issue in many embedded applications in the aerospace, aircraft, automobile, railways, nuclear, medical, and other industries. Safety in this context means avoiding harm to individuals or society due to malfunctioning computer equipment or software. The essential requirements for these systems are so strict that they are regulated by government agencies such as the US Federal Aviation Administration (FAA) in the case of both airborne and ground aviation systems.The general concept of safety assurance is to minimize risk that can lead to accidents. This implies that the software tools used to develop the hardware and software components in safety-critical systems must be evaluated as thoroughly as the products themselves.

This paper describes an evaluation of static source code analyzers. The purpose of the evaluation was to determine their adequacy for use in developing realtime embedded software for aviation electronics where the use of development tools and methods is controlled by a federal regulatory agency. It describes the motivation for the evaluation, results, and conclusions.

Modified Condition/Decision Coverage (MCDC) is a structural testing strategy required to verify Level A software used in commercial aviation. In DO-178B, Level A software is defined as software whose anomalous behavior would cause or contribute to a failure of system function resulting in a catastrophic failure condition for the aircraft. Paradoxically, this technique does not detect common errors, yet it consumes a large portion (approximately 25%) of the verification budget because of the number of test cases required to satisfy this coverage. Furthermore, this approach is directly applicable to only high-level languages, making its applicability of limited value to assembly language programs and machine-level code which could have been generated by auto code tools. A simpler approach is suggested in this paper that would better detect these common errors and would be more cost-effective for all applications.

We report on our experience with enhancing the data-management component in the avionics software of the NH90 helicopter at Airbus Helicopters. We describe challenges regarding the evolution of avionics software by means of real-world evolution scenarios that arise in industrial practice. A key role plays a legally-binding certification process, called qualification, which is responsible for most of the development effort and cost. To reduce effort and cost, we propose a novel generative approach to develop qualifiable avionics software by combining model-based and product-line technology. Using this approach, we have already generated code that is running on the NH90 helicopter and that is in the process of replacing the current system code. Based on an interview with two professional developers at Airbus and an analysis of the software repository of the NH90, we systematically compare our approach with established development approaches in the avionics domain, in terms of implementation and qualification effort.

Complex products, such as an aircraft, require a large number of software projects developed in parallel. The development of airborne software, using the DO-178C, is a challenge and metrics can help the evaluation and adherence. This paper provides a summary of master thesis approved in the Brazilian Aeronautics Institute of Technology. The thesis proposes the creation of a set of metrics that evaluates the compliance with DO-178C objectives related to the development phase of the airborne software projects, monitoring delays in the certification schedule of the aircraft. These metrics were created using the PSM model (Software and Systems Measurement Practice) as guidance. Finally, a case study is performed using the metrics in an actual airborne software development.

RTCA Document DO-178C, Software Considerations in Airborne Systems and Equipment Certification, and its predecessor DO-178B are regarded as the “gold standard” for aviation software design assurance leading to safe software on aircraft, but they can impose additional costs on avionics developers, particularly those not experienced with the process. It also cannot easily be applied to previously developed software (PDS) or systems.

Software quality is not easily measured, so software development organizations seek recognition from clients through the quality of their processes. The SEI (Software Engineering Institute) created the CMMI-DEV (Capability Maturity Model Integration for Development) as a model for organizations to improve their processes and to be appraised in many levels. However, CMMI DEV is not recognized as a mean of compliance for airborne embedded software, unlike the norm DO-178C, from RTCA (Radio Technical Commission for Aeronautics), which is recognized by Federal Aviation Administration by the Advisory Circular 20 115C. This study estimates the intersection between those two documents and proposes a methodology to estimate the distance between CMMI-DEV and DO-178C, defining where a generic software organization following CMMI DEV should focus to start creating airborne software.

Aviation systems, both airborne and ground, (e.g., flight controls, avionics, engine control, and air traffic control) are typical examples of safety-critical, real-time systems. Such systems continue to become more complex and are extremely software reliant. Modern aircrafts, composed on numerous software-controlled systems, operate within constraints of a National Airspace System (NAS) that includes air traffic management, weather services, airline and airport operations, communication facilities, navigation infrastructure, and so on. NAS is a software-intensive system of systems with multiple components and of incredible complexity. Software is critical in all aspects of modern aviation, whether it is for development, operation flexibility, or fault tolerance. Technological progress, particularly in the electronics and computing areas, changed the aviation industry. Safety has always been a critical factor for aviation; with increased interconnectivity of networked systems and potential vulnerability for malicious attacks, security becomes likewise important. This chapter presents basic concepts and definitions of safety and security together with their mutual relationship. Representative techniques, methods, and tools used to facilitate software assurance are discussed. In addition, the chapter introduces regulations and certification guidance as applied to the development of software-intensive aviation systems from the perspective of safety and security. Keywords: Safety; security; aviation software; certification; software assurance

Companies related to safety critical systems developments invest efforts and resources to assure that their systems are safe enough. Traditionally reuse strategies have been proposed to reduce these efforts in several domains which criticality is not a key aspect. However reusing software artefacts across different domains establishes new challenges especially between safety critical systems. In fact we need to take into account different domain specific standards requirements at the same time. In this paper we present our experience on cross domain assurance involving a reuse of a software component developed for the railway domain, and to be used for the avionics domain.

Quality of software requirement is an important factor to safety of aviation equipment software. With the increase of software complexity, Artificial software requirement analysis is difficult to find requirement defect caused by multi state combination, multi fault concurrent, multi condition conflict and multi path migration. This paper presents an automatic analysis technology for aviation equipment software requirement safety. First of all, formal modeling of software requirement and extracting safety analysis rules from the failure data are introduced. After that, how to analyze the interfaces, functions and states information automatically in requirement model based on analysis rules and requirement model is discussed. A platform based on this technology is developed and applied to a certain type of aviation engine control software safety analysis project successfully.

The introduction of a new standard for safety-critical systems in a company usually requires investments in training and tools to achieve a deep understanding of the processes, the techniques and the required technological support. In general, for a new standard that is desired to be introduced, it is both relevant and challenging to rate the capability of the company to apply the standard, and consequently to estimate the effort in its adoption. Additionally, questions on the maturity in the application of such standard may still persist for a long time after its introduction. Focusing on prescriptive software standards for critical systems, this paper presents a framework for gap analysis that measures the compliance of a company’s practices, knowledge and skills with the requirements of a standard for the development of safety-critical systems. The framework is exercised in a company to rate its maturity in the usage of the avionic standard DO-178B.

Some applicants, developers, and commercial-off-the-shelf (COTS) software vendors have proposed reverse engineering as an approach for satisfying RTCS/DO-178B objectives for airborne software. RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, serves as the means of compliance for most airborne software in civil aircraft. DO-178B defines reverse engineering as "the method of extracting software design information from the source code" and provides guidance particular to reverse engineering, when it is used to upgrade a development baseline. For purposes of this paper, reverse engineering is an approach for creating software life cycle data that did not originally exist, cannot be found, is not adequate, or is not available to a developer in order to meet applicable DO-178B objectives. Reverse engineering is not just the generation of data - rather it is a process to assure that the data is correct, the software functionality is understood and well documented and the software functions as intended and required by the system. Reverse engineering is not, as some software developers propose, just an effort to generate the software life cycle data without intent to build in quality and the resulting design assurance. This article explores reverse engineering in airborne software projects, by explaining a definition for the certification domain, describing the motivation for its use, and documenting the certification concerns. Two actual cases of reverse engineering are also described to illustrate the certification concerns in real projects.

This paper identifies the minimum subset required for a truly universal safety-critical software standard. This universal software standard could be used in but is not limited to the following application domains: commercial, military and space aviation; medical diagnostic and therapeutic instruments; automotive and transportation systems; industrial process control and robotics; nuclear power plants and weapons control; commercial appliances and ride electronics. The standard takes into account that safety is a system attribute but focuses on software as the critical component. Its roots are based in MoD 00-55, 56, DO-178B, ARP 4754 and 4761, Mil-Std-882 and Software Safety Handbook, IEC 61508, IEC 60880, ANSI/ISA-S84.01, ANSI/AAMI SW68:2001, NASA-STD-8719.13, UL 1998, EN 50128, MISRA Automotive Standard, and IEEE 1228. This minimum subset uses existing system and software technology and can be adapted to future applications. A universal software safety standard would benefit the entire safety-critical industry by lowering the cost and improving the quality of software by having common processes and tools. As an additional benefit, various application sectors could share data on the efficacy of each technique used in the development and verification of safety-critical software. This in turn could improve the overall safety of systems in the future.