DO-178B identifies a set of Software
Levels Definitions A through E that
roughly correspond to the DALs, with
level A software the highest criticality
and level E the lowest. The objectives to
be met depend upon the software level
assigned to the project. This article discusses activities and objectives associated with level A.
software engineering 101
illustratioN by aQuatic creature / shutterstocK.coM
In the preface of Nancy Leveson’s
Safeware: System Safety and Computers, the
author cites “One obvious lesson is that
most accidents are not the result of unknown scientific principles but rather of
a failure to apply well-known, standard
engineering practices. A second lesson
is that accidents will not be prevented
by technological fixes alone, but will require control of all aspects of the development and operation of the system.”
4
Definition and control of the software
development process is the first key to
creating safety-critical systems.
The objectives and activities identified in DO-178B should be familiar to
anyone who was attentive during software engineering courses in college.
The key points are that activities and
work-products are defined and repeatable. A software life cycle model must
be identified, and transition criteria
between processes must be documented. In short, things are written down.
There are plans and standards used by
software development and verification
teams, and those activities are audited
to ensure compliance with those plans
and standards. These plans include:
˲ ˲ Plan for Software Aspects of Certification (PSAC). The primary means of
communicating the overall project plan
to the certification authority.
˲ ˲ Software Development Plan (SDP).
Defines the software life cycle and development environment.
˲ ˲Software Verification Plan (SVP).
Describes how the software verification
process objectives will be satisfied.
˲ ˲Software Configuration Management Plan (SCMP). Describes how artifacts will be managed.
˲ ˲Software Quality Assurance Plan
SQAP). Describes how the SQA (
Software Quality Assurance) function will
ensure plans are followed and standards are met.
DO-178B demands three standards
be present: requirements, design, and
source code.
A software configuration manage-
ment (SCM) system consistent with
the SCMP must be provided. Addition-
ally, an issue-tracking or bug-tracking
system must be provided to document
issues with either the software or com-
pliance to standards and processes. All
of these activities, plans, and standards
(with the exception of the PSAC) are
things that a well-run organization at
SEI3 level 2 or 3 would have in place.
no surprises
What does it mean to be safe If
complete safety were defined as the
complete absence of hazards, then it
would be difficult to imagine any practical and useful real-world system ever
being completely safe. The safeness
of a particular system is, therefore, a
relative notion defined by the identified potential hazards within the system, the likelihood of each hazard’s
occurrence, and the effectiveness of
the mitigations put in place for each
of those hazards.
In order to inventory and understand
the hazards for a system, you must first
understand what the system is supposed to do. Otherwise, how can you
tell if it is doing it wrong (or what might
result)? A strong set of requirements
is necessary for the foundation of any
safety-critical system. Further, the requirements will appear at various levels
of abstraction beginning as high as the
requirements for the airframe and descending into systems, line-replaceable
units, CSCIs (computer software configuration items) for a particular subsystem, high-level requirements for that
subsystem, and low-level requirements.
The particular levels of abstraction
present will depend on the particulars
