No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
White, J., Reza, H. Deriving DO-178C Requirements within the Appropriate Level of Hierarchy.
... A number of studies have supported their work with examples and case studies of avionics systems that involve some piece of software (e.g., [8,[21][22][23]). Others report on the development of avionics systems that rely on software for controlling the behaviour of such systems (e.g., [3,18]). ...
... A number of studies have supported their work with examples and case studies of avionics systems that involve some piece of software (e.g., [8,[21][22][23]). Leveson et al. [8] describe a requirements speci cation language for process-control systems. ...
... White et al.'s work in [21] is closely related to the work presented in this paper. It falls into the rst category of related work, although, it has some elements of the second category. ...
As with many of the products and systems that pervade us, aircraft rely more and more on software for controlling the behaviour of their systems. In consequence, the field has seen increased work around more up-to-date, effective software engineering technologies for aiding avionics software providers in reducing software and development complexities and supporting them in their certification endeavours. However, there is a lack in the literature of reusable, comprehensive references about avionics software developments in conformance with DO-178C. Moreover, there is a need for a benchmark specification to support the evaluation of proposed engineering approaches in the field. This paper presents a software development case study of an avionics control software for a landing gear system. All the documentation for the software’s requirements specification and design has been developed to conform with the DO-178C guideline and the applicable DO-331 and DO-332 supplements for model-based and object-oriented development, respectively. A requirements specification and design methodology is proposed and followed for the construction of the software in the case study. Furthermore, the paper discusses the observations, and challenges and issues experienced throughout the process.
... 40 In general, the mapping of requirements to the appropriate level of hierarchy from system level to low-level requirements is not trivial, especially for derived requirements. 41 The requirements for MiPlEx existed implicitly in several artifacts, like unit tests, test protocols and tickets from a change management system. The formalization procedure was intended to go from natural language descriptions to structured natural language descriptions and finally to formal properties. ...
The aerospace domain is a safety-critical domain. Therefore software has to be of high quality. Software development and testing in safety-critical domains is regulated by standards, such as DO-178B and DO-178C for the aerospace domain. However, the test approach in these standards is stochastic in nature, which means that errors in the code are tried to be identified by a large set of test cases. The trust in such software products and the overall quality is achieved by traceability to requirements and strict coverage criteria as well as general conformance to processes and rigorous documentation, but any absence of errors can usually not be proved. On the other hand, the use of formal methods for software, which is now standardized by the introduction of the Supplement DO-333, promises a true validation of certain safety-critical properties. This paper shows how formal requirements and model-checking were introduced to our test strategy for an automated planning and guidance software module. The requirements for an existing software artifact were elicited and then formalized into Linear Temporal Logic and Computation Tree Logic, which are two derivatives of temporal logic. A formal model for the software was developed and NuSMV was used as a model-checking tool to analyze the requirements in regards to the model. Furthermore, the corresponding certifcation considerations for this formal method are discussed according to the relevant standards.
The term Model-Based Development (MBD) is typically used to describe software development approaches in which models of software systems are created and systematically transformed to concrete implementations. In this paper, due to the increase of MBD utilization, an overview of how models can be used to specify software low-level requirements is provided to achieve airborne software certification in aircraft projects. This paper provides the guidance materials and the need of future perspectives and expands the impacts software planning, development and verification.
Embedded systems in aerospace become more and more integrated in order to reduce weight, volume/size, and power of hardware for more fuel-effi ciency. Such integration tendencies change architectural approaches of system ar chi tec tures, which subsequently change non-functional requirements for plat forms. This paper provides some insight into state-of-the-practice of non-func tional requirements for developing ultra-critical embedded systems in the aero space industry, including recent changes and trends. In particular, formal requi re ment capture and formal analysis of non-functional requirements of avionic systems - including hard-real time, fault-tolerance, reliability, and per for mance - are exemplified by means of recent developments in SAL and HiLiTE.
The goal of software inspection and test is to reduce the expected cost of software failure over the life of a product. The authors extend the use of defect triggers, the events that cause defects to be discovered, to help evaluate the effectiveness of inspections and test scenarios. In the case of inspections, the defect trigger is defined as a set of values that associate the skills of the inspector with the discovered defect. Similarly, for test scenarios, the defect trigger values embody the deferring strategies being used in creating these scenarios. The usefulness of triggers in evaluating the effectiveness of software inspections and tests is demonstrated by evaluating the inspection and test activities of some software products. These evaluations are used to point to deficiencies in inspection and test strategies, and to progress made in improving such strategies. The trigger distribution of the entire inspection or test series may then be used to highlight areas for further investigation, with the aim of improving the design, implementation, and test processes
This paper describes a process of dual certification for software that meets both FAA safety requirements and NIST/NSA security requirements. The commercial avionics industry depends on RTCA DO-178B, for software assurance while security products are evaluated according to the Common Criteria. The two sets of requirements from DO-178B and the Common Criteria are assessed for similarity of function with non-corresponding parts identified. Each certification process is outlined and a merged certification procedure is presented.
The complexity of telecom systems and their production, coupled with today's globalization of markets, customers, and development teams, have made it critical to define and institutionalize an effective strategy for requirements traceability. Being able to trace the life of requirements from their origin, through their allocation to components, to the finished product provides a basis for collaboration and control of functionality, quality, and changes. With the benefits of current software engineering techniques and tools, organizations can cost-effectively implement traceability aligned with the organization's business goals, software engineering maturity, project attributes, and team culture. Within Alcatel-Lucent, several business units have engaged in implementing traceability and our team has developed an automated traceability environment. Based on these experiences we present a framework of guidelines for designing effective traceability strategies and tools. © 2008 Alcatel-Lucent.
Traceability—the ability to follow the life of software artifacts—is a topic of great interest to software developers in general,
and to requirements engineers and model-driven developers in particular. This article aims to bring those stakeholders together
by providing an overview of the current state of traceability research and practice in both areas. As part of an extensive
literature survey, we identify commonalities and differences in these areas and uncover several unresolved challenges which
affect both domains. A good common foundation for further advances regarding these challenges appears to be a combination
of the formal basis and the automated recording opportunities of MDD on the one hand, and the more holistic view of traceability
in the requirements engineering domain on the other hand.
In this paper1, we investigate and discuss the underlying nature
of the requirements traceability problem. Our work is based on
empirical studies, involving over 100 practitioners, and an
evaluation of current support. We introduce the distinction
between pre-requirements specification (pre-RS) traceability
and post-requirements specification (post-RS) traceability, to
demonstrate why an all-encompassing solution to the problem is
unlikely, and to provide a framework through which to
understand its multifaceted nature. We report how the majority
of the problems attributed to poor requirements traceability are
due to inadequate pre-RS traceability and show the fundamental
need for improvements here. In the remainder of the paper, we
present an analysis of the main barriers confronting such
improvements in practice, identify relevant areas in which
advances have been (or can be) made, and make
recommendations for research.
This tutorial provides a practical approach to assessing modified condition/decision coverage (MC/DC) for aviation software products that must comply with regulatory guidance for DO-178B level A software. The tutorial's approach to MC/DC is a 5-step process that allows a certification authority or verification analyst to evaluate MC/DC claims without the aid of a coverage tool. In addition to the MC/DC approach, the tutorial addresses factors to consider in selecting and qualifying a structural coverage analysis tool, tips for reviewing life cycle data related to MC/DC, and pitfalls common to structural coverage analysis.
This paper discusses a method and its supporting tool to select the software architecture for a family of software systems (commonly known as architectural styles) that meets the needs of the user. Our approach emphasizes the importance of basing architecture on non-functional requirements (NFRs). To this end, we have utilized a scenario-based approach that will determine NFRs of software architecture. NFRs are then mapped to optimal software architecture of a system by a set of table. Tables are applied to properly bridge the gap between NFRs and its corresponding software architecture.
Requirements traceability is intended to ensure continued alignment between stakeholder requirements and various outputs of the system development process. To be useful, traces must be organized according to some modeling framework. Indeed, several such frameworks have been proposed, mostly based on theoretical considerations or analysis of other literature. This paper, in contrast, follows an empirical approach. Focus groups and interviews conducted in 26 major software development organizations demonstrate a wide range of traceability practices with distinct low-end and high-end users of traceability. From these observations, reference models comprising the most important kinds of traceability links for various development tasks have been synthesized. The resulting models have been validated in case studies and are incorporated in a number of traceability tools. A detailed case study on the use of the models is presented. Four kinds of traceability link types are identified and critical issues that must be resolved for implementing each type and potential solutions are discussed. Implications for the design of next-generation traceability methods and tools are discussed and illustrated
Summary of Difference Between DO-178B and DO-178C
- Consulting Qualtech
- Inc
Qualtech Consulting Inc, " Summary of Difference Between
DO-178B
and
DO-178C",
http://www.faaconsultants.com/html/do-178c.html.
DO-178B, Software considerations in airborne systems and equipment certification
- L A Johnson
Johnson, L. A., "DO-178B, Software considerations in
airborne
systems
and
equipment
certification",
http://www.dcs.gla.ac.uk/~johnson/teaching/safety/reports/sch
ad.html.