Developing Safety-Critical Software

A Practical Guide for Aviation Software and DO-178C Compliance

Leanna Rierson

• Éditeur: CRC Press
• Année: 2017
• ISBN:
  9781351834056
• Édition: 1
• Sujet: Computer Science
• Sous-sujet: Software Development

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.

Part I Introduction

Part I sets the foundation for the entire book. It includes an explanation of what safety-critical software is and why it is important in today’s environment. An overview of the book and an explanation of the approach taken are also provided.

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

A general definition for safety is the “freedom from those conditions that can cause death, injury, illness, damage to or loss of equipment or property, or environmental harm” [1]. The definition of safety-critical software is more subjective. The Institute of Electrical and Electronic Engineers (IEEE) defines safety-critical software as: “software whose use in a system can result in unacceptable risk. Safety-critical software includes software whose operation or failure to operate can lead to a hazardous state, software intended to recover from hazardous states, and software intended to mitigate the severity of an accident” [2]. The Software Safety Standard published by the U.S. National Aeronautics and Space Administration (NASA) identifies software as safety-critical if at least one of the following criteria is satisfied [3,4]:

1. 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.
2. It processes data or analyzes trends that lead directly to safety decisions.
3. It provides full or partial verification or validation of safety-critical systems, including hardware or software systems.

From these definitions, it can be concluded that software by itself is neither safe nor unsafe; however, when it is part of a safety-critical system, it can cause or contribute to unsafe conditions. Such software is considered safety critical and is the primary theme of this book.

1.2 Importance of Safety Focus

In 1993, Ruth Wiener wrote in her book Digital Woes: Why We Should Not Depend Upon Software: “Software products—even programs of modest size— are among the most complex artifacts that humans produce, and software development projects are among our most complex undertakings. They soak up however much time or money, however many people we throw at them. The results are only modestly reliable. Even after the most thorough and rigorous testing some bugs remain. We can never test all threads through the system with all possible inputs” [5]. Since that time, society has become more and more reliant on software. We are past the point of returning to purely analog systems. Therefore, we must make every effort to ensure that softwareintensive systems are reliable and safe. The aviation industry has a good track record, but as complexity and criticality increase, care must be taken.

It is not unusual to hear statements similar to: “Software has not caused any major aircraft accidents, so why all the fuss?” The contribution of software to aircraft accidents is debatable, because the software is part of a larger system and most investigations focus on the system-level aspects. However, in other domains (e.g., nuclear, medical, and space) software errors have definitely led to loss of life or mission. The Ariane Five rocket explosion, the Therac-25 radiation overdoses, and a Patriot missile system shutdown during the Gulf War are some of the more well-known examples. The historical record for safety-critical software in civil aviation has been quite respectable. However, now is not the time to sit back and marvel at our past. The future is riskier for the following reasons:

• 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.

Because of these and other risk drivers, it is essential to focus even more on safety than ever before.

1.3 Book Purpose and Important Caveats

I am truly honored and humbled that you have decided to read this book. The purpose of this text is to equip practicing engineers and managers with the information they need to develop safety-critical software for aviation. Over the last 20 years, I’ve had the privilege of working as an avionics developer, aircraft developer, certification authority, Federal Aviation Administration (FAA) Designated Engineering Representative (DER), consultant, and instructor. I’ve evaluated safety-critical software on dozens of systems, such as flight controls, IMA, landing gear, flaps, ice protection, nose wheel steering, flight management, battery management, displays, navigation, terrain awareness and warning, traffic collision and avoidance, real-time operating systems, and many more. I’ve worked with teams of 500 and teams of 3. It has been and continues to be an exciting adventure!

The variety of positions and systems has allowed me to experience and observe common issues, as well as effective solutions, for developing safetycritical software. This book is written using these experiences to help practicing aircraft systems engineers, avionics and electronic systems engineers, software managers, software development and verification engineers, certification authorities and their designees, quality assurance engineers, and others who have a desire to implement and assure safe software.

As a practical guide for developing and verifying safety-critical software, the text provides concrete guidelines and recommendations based on real-life projects. However, it is important to note the following:

• 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. ...