Developing Safety-Critical Software
A Practical Guide for Aviation Software and DO-178C Compliance
Leanna Rierson
- 610 pages
- English
- ePUB (mobile friendly)
- Available on iOS & Android
Developing Safety-Critical Software
A Practical Guide for Aviation Software and DO-178C Compliance
Leanna Rierson
About This Book
The amount of software used in safety-critical systems is increasing at a rapid rate. At the same time, software technology is changing, projects are pressed to develop software faster and more cheaply, and the software is being used in more critical ways. Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance equips you with the information you need to effectively and efficiently develop safety-critical, life-critical, and mission-critical software for aviation. The principles also apply to software for automotive, medical, nuclear, and other safety-critical domains.
An international authority on safety-critical software, the author helped write DO-178C and the U.S. Federal Aviation Administration's policy and guidance on safety-critical software. In this book, she draws on more than 20 years of experience as a certification authority, an avionics manufacturer, an aircraft integrator, and a software developer to present best practices, real-world examples, and concrete recommendations.
The book includes:
- An overview of how software fits into the systems and safety processes
- Detailed examination of DO-178C and how to effectively apply the guidance
- Insight into the DO-178C-related documents on tool qualification (DO-330), model-based development (DO-331), object-oriented technology (DO-332), and formal methods (DO-333)
- Practical tips for the successful development of safety-critical software and certification
- Insightful coverage of some of the more challenging topics in safety-critical software development and verification, including real-time operating systems, partitioning, configuration data, software reuse, previously developed software, reverse engineering, and outsourcing and offshoring
An invaluable reference for systems and software managers, developers, and quality assurance personnel, this book provides a wealth of information to help you develop, manage, and approve safety-critical software more confidently.
Frequently asked questions
Information
Part I Introduction
1 Introduction and Overview
Acronym
DER | Designated Engineering Representative |
EASA | European Aviation Safety Agency |
FAA | Federal Aviation Administration |
IEEE | Institute of Electrical and Electronic Engineers |
IMA | Integrated Modular Avionics |
NASA | National Aeronautics and Space Administration |
1.1 Defining Safety-Critical Software
- It resides in a safety-critical system (as determined by a hazard analysis) AND at least one of the following:
- Causes or contributes to a hazard.
- Provides control or mitigation for hazards.
- Controls safety-critical functions.
- Processes safety-critical commands or data.
- Detects and reports, or takes corrective action, if the system reaches a specific hazardous state.
- Mitigates damage if a hazard occurs.
- Resides on the same system (processor) as safety-critical software.
- It processes data or analyzes trends that lead directly to safety decisions.
- It provides full or partial verification or validation of safety-critical systems, including hardware or software systems.
1.2 Importance of Safety Focus
- Increased lines of code: The number of lines of code used in safetycritical systems is increasing. For example, the lines of code from the Boeing 777 to the recently certified Boeing 787 have increased eightfold to tenfold, and future aircraft will have even more software.
- Increased complexity: The complexity of systems and software is increasing. For example, Integrated Modular Avionics (IMA) provides weight savings, easier installation, efficient maintenance, and reduced cost of change. However, IMA also increases the systemâs complexity and results in functions previously isolated to physically different federated hardware being combined onto a single hardware platform with the associated loss of multiple functions should the hardware fail. This increased complexity makes it more difficult to thoroughly analyze safety impact and to prove that intended functionality is met without unintended consequences.
- Increased criticality: At the same time that size and complexity of software are increasing, so is the criticality. For example, flight control surface interfaces were almost exclusively mechanical 10 years ago. Now, many aircraft manufacturers are transitioning to fly-by-wire software to control the flight control surfaces, since the fly-by-wire software includes algorithms to improve aircraft performance and stability.
- Technology changes: Electronics and software technology are changing at a rapid rate. It is challenging to ensure the maturity of a technology before it becomes obsolete. For example, safety domains require robust and proven microprocessors; however, because a new aircraft development takes around 5 years, the microprocessors are often nearly obsolete before the product is flight tested. Additionally, the changes in software technology make it challenging to hire programmers who know Assembly, C, or Ada (the most common languages used for airborne software). These real-time languages are not taught in many universities. Software developers are also getting further away from the actual machine code generated.
- More with less: Because of economic drivers and the pressure to be profitable, many (maybe even most) engineering organizations are being requested to do more with less. Iâve heard it described as follows: âFirst, they took away our secretaries; next, they took away our technical writers; and then, they took away our colleagues.â Most good engineers are doing the work of what was previously done by two or more people. They are spread thin and exhausted. People are less effective after months of overtime. A colleague of mine puts it this way: âOvertime is for sprints, not for marathons.â Yet, many engineers are working overtime for months or even years.
- Increased outsourcing and offshoring: Because of the market demands and the shortage of engineers, more and more safety-critical software is being outsourced and offshored. While not always an issue, oftentimes, outsourced and offshored teams do not have the systems domain knowledge and the safety background needed to effectively find and remove critical errors. In fact, without appropriate oversight, they may even inject errors.
- Attrition of experienced engineers: A number of engineers responsible for the current safety record are retiring. Without a rigorous training and mentoring program, younger engineers and managers do not understand why key decisions and practices were put into place. So they either donât follow them or they have them removed altogether. A colleague recently expressed his dismay after his team gave a presentation on speed brakes to their certification authorityâs new systems engineer who is serving as the systems specialist. After the 2-hour presentation, the new engineer asked: âYou arenât talking about the wheels, are you?â*
- Lack of available training: There are very few safety-focused degree programs. Additionally, there is little formal education available for system and software validation and verification.
1.3 Book Purpose and Important Caveats
- The information herein represents one personâs view. It is written based on personal experiences and observations, as well as research and interactions with some of the brightest and most committed people in the world. Every effort has been made to present accurate and complete advice; however, every day I learn new things that clarify and expand my thinking. Throughout the book terms like typically, usually, normally, most of the time, many times, oftentimes, etc. ...