Because software is not unsafe itself, and only con- when we cannot easily deﬁne and verify a set of re-
tributes indirectly to accidents, software safety prob- quirements? The different domains are still working
lems must be evaluated within the context of sys- in isolation, under different regulations and stan-
tem safety. This article focuses on software-safety dards. Certification becomes even more difficult
certiﬁcation, which will be considered as part of the when one subsystem already exists and possible
overall system-safety certiﬁcation. new regulations and standards do not apply to it.
In many application domains, safety certiﬁcation To further complicate the situation, the propor-
is mandatory before a system is put in operation. tion of subsystems containing software is increasing
Currently, this certiﬁcation is the responsibility of na- rapidly, with critical functions increasingly imple-
tional certiﬁcation authorities, who cover all certiﬁ- mented using software. For example, computer-
cation aspects for systems
belonging to speciﬁc ap-
plication domains. It is also
Many new systems are composed of subsys-
based on well-known do- tems from different application domains.
and operational requirements, historical information based devices govern many aircraft command control
about the reliability of the different subsystems, and functions, and cars may have 15 or more microcom-
historical accident data. puters for monitoring, control, and navigation.
Decisions about the use of safety-critical systems Software failures have potentially severe effects.
often rely on an assessment of the risk involved. When software is constructed, it is usually spe-
These risks can be derived from historical informa- cially constructed to one system, so no historical in-
tion about the reliability of the individual compo- formation exists about its reliability. This means
nents and the models that define the connection deﬁning safety constraints for the software require-
between these components, or historical accident ments, design, and implementation, and using ver-
data about similar systems. Many new systems are iﬁcation analysis methods. Such techniques are im-
composed of subsystems belonging to different ap- mature, but several standardization bodies and
plication domains, and some are built to be used working groups have begun analyzing and address-
and operated internationally. The failure of these ing the problems of international, interdomain,
safety-critical systems can have catastrophic conse- safety-critical software-based systems, often as in-
quences to human lives. The deﬁnition of the safety ternational collaborations (see the boxed text,
objectives for these systems and the process and “International Software Safety Initiatives,”on p. XX).
methods to ensure their safety are completely new,
not proven before and being deﬁned while the sys-
tems are being built. LEGAL CERTIFICATION ISSUES
Both producers and consumers increasingly rec-
SYSTEMS THAT CROSS BORDERS ognize the need for certification. For producers, it
implies more quality in the products and sometimes
The Global Navigation Satellite System uses satel- a reduction in their liability for defects. An example
lites for navigation and automatic surveillance of air, is limited liability when the products are used for
maritime, and land systems. Safety certiﬁcation of other purposes. For consumers and system opera-
such a system is a complicated and largely uncharted tors, certiﬁcation schemes legally recognized by na-
area—no historical databases exist as a basis for the tional governments secure protection for their in-
certiﬁcation of the complex technical and interdo- vestments, efforts, and safety operations.
main safety requirements. Further, no certiﬁcation In some countries, any person, association, or
authorities have yet been appointed due to the need company can set up a certiﬁcation business—cred-
for international and interdisciplinary legal recogni- ibility lies in commercial success rather than any
tion—an intensely political matter. legal mandate. In general, national governments
Similarly, remote telemedicine systems use satel- recognize and accredit certification agencies for
lite communication links for remote consultation, each application domain, particularly in domains
surgery, and other medical procedures. How do we where safety is essential, to provide more structured,
perform safety certiﬁcation on interdomain systems effective supervision.3
July/August 1999 IEEE Software 3
Certiﬁcation is mandatory before a system is put that the approval, certification, and evaluation
in operation in some application domains. For ex- process for safety-critical systems, in which a soft-
ample, every country certiﬁes new aircraft to ensure ware failure could be a safety hazard, is handled
compliance with airworthiness requirements before within the EU to support the single European mar-
allowing them to ﬂy. Up to now, we have been con- ket. I hope more initiatives like this one will start in
tent with multiple domain-specific certification order to solve other legal issues that still remain
schemes, standards, and organizations through na- open, such as liability, international certiﬁcation au-
tionally recognized certiﬁcation authorities. For ex- thority, and international recognition.
ample, the Federal Aviation Authority regulates both
technical and legal certification of US aircraft and
related products and parts; individual European TECHNICAL CERTIFICATION ISSUES
Community member states have their own regula-
tory authorities for similar matters. The technical aspects of software safety certiﬁ-
A legal problem arises when we build new sys- cation present an even more difﬁcult challenge. We
must ensure that the product complies
with the applicable technical require-
We need internationally recognized ments by following a process agreed
accredidation agencies to bolster the upon by the producer and the certiﬁ-
authority of safety demonstrations. cation organization. It must also be
based on a set of applicable technical
tems from subsystems that come from different ap- requirements which, for the system safety certiﬁca-
plication domains, because no certiﬁcation scheme tions, are based on safety objectives.
exists yet for these interdomain systems. To deﬁne,
agree upon, and apply a certiﬁcation scheme for the Iterative certiﬁcation process
overall system, we need agreements between the For existing systems, safety certiﬁcation follows
various certiﬁcation authorities and application do- a known process, agreed on by the parties in ad-
mains. In addition, if these new systems will be op- vance, where the certiﬁcation requirements are set
erated and used internationally, international agree- up and progressively updated based on technology
ments are also needed. Liability issues, international evolution and lessons learned. In the absence of a
recognition of the certiﬁcate, certiﬁcation authori- certiﬁcation scheme or historical information for the
ties, and many other issues have not yet been de- new interdomain and software-intensive systems,
ﬁned for these new systems. the ﬁrst certiﬁcation of such systems will be based
In addition, we need internationally recognized on validation of their new operation and perfor-
accreditation of certiﬁcation agencies, such as test- mance requirements, and on the veriﬁcation that no
ing laboratories, to bolster the authority of safety mistakes are made in the safety analysis of the sys-
demonstrations. Software poses a particular prob- tem and in the construction of both the system and
lem to existing certiﬁcation schemes and accredited subsystems.
certiﬁcation agencies—few accredited certiﬁcation The process by which the certiﬁcation authority
agencies have expertise in software safety issues, and the applicant interact is often iterative, running
which are not generally well deﬁned or understood. while the system is being developed. Without this
This problem is internationally recognized among iteration—if the applicant intends to request certi-
those who have attempted to perform in-depth ﬁcation at the end of system development—there is
evaluations for new multidomain software-inten- a high risk of incurring extra costs to achieve certi-
sive systems. ﬁcation. Developing a system based on stringent re-
ESA is currently working in various international quirements, standards, and plans might not be
committees intended to deﬁne and set the certiﬁ- enough for system certiﬁcation.
cation schemes for new complex software-intensive The iterative approach certainly offers a more cost-
systems, such as GNSS. The European Committee for effective and secure way to obtain certiﬁcation, but it
Standardisation (CEN) has created the Information is not always possible for every part of a system.
Society Standardisation System (ISSS) with a work- Because COTS products are often not speciﬁcally de-
ing groups entitled, “Accredited Testing of Software veloped to work as part of a safety-critical system, ev-
in Safety-Critical Systems.”Its major goal is to ensure idence rarely exists that they are robust and will not
4 IEEE Software July/August 1999
Figure 1. Parallel software analysis cycle.
introduce extra hazards into the system. Their safety by errors at any software life-cycle stage. They could
analysis is performed after they are developed. be introduced in the software requirements phase.
Figure 1 shows a sample iterative reference For example, aviation software written for use in
process for safety certiﬁcation focusing on the soft- the northern hemisphere often creates problems
ware product development process. The process when used in the southern hemisphere, or at alti-
starts by defining the system safety requirements tudes below sea level. Faults could also originate
as a basis for the software safety certiﬁcation, cul- from a later phase; the failure of the Ariane 5 first
minating in the safety demonstration. This safety test ﬂight6 was the result of a software variable that
demonstration can be defined in many different was not checked under software exception han-
ways, depending on the method selected to docu- dling control—its overﬂow caused the catastrophic
ment that the system is safe. event. To prevent the failure, developers could have
Certiﬁers and/or developers can tailor this refer- implemented a control mechanism for hazardous
ence process to their system’s applicable certifica- software behavior.
tion requirements and methods. There are several This suggests that safety verifications must be
methods for individual domain-specific safety done in parallel to software development.
demonstrations; the safety case approach is an ex- Developers can derive design and implementation
ample.4 However, no validated method yet exists for constraints from these safety veriﬁcations to apply
multidomain, international, software-intensive sys- to later software implementation phases. These con-
tems. Any method that system developers use will straints may vary depending on the criticality class
serve for pilot trials, and future certiﬁcations will val- of the software product and its nature, such as COTS
idate them and aid in improving the safety assess- versus custom software.
ments of these systems. In any case, the system The sample process in Figure 1 should be
safety demonstration will reuse information from adapted on a case-by-case basis. Developers can de-
the different safety analyses produced at each phase ﬁne different life-cycle approaches, such as the spi-
of the software development life cycle. ral model, JAD, and the iterative life-cycle model (as
Because software can contribute to system haz- typified by object-oriented development); not all
ards, eliminating or controlling hazardous software steps can be performed in every case. For example,
behavior will reduce or prevent accidents and, in the process in Figure 1 cannot be applied to soft-
turn, reduce risk.5 Software faults might be caused ware COTS products. Their certification process is
July/August 1999 IEEE Software 5
INTERNATIONAL SOFTWARE SAFETY INITIATIVES
FAA-SSAC (http://shemesh.larc.nasa.gov/ssac/). FAA began Esprit Project 22187: Serene—Safety and Risk Evaluation
the Streamlining Software Aspects of Certiﬁcation (SSAC) program Using Bayesian Nets (http://www.cordis.lu/esprit/src/22187.htm).
to address concerns about time and expense associated with soft- The project’s objectives are to develop a method for constructing
ware aspects of certiﬁcation. The primary objectives are to software safety arguments using BBNs, to adapt an existing BBN
♦ analyze the current software approval process for certiﬁ- tool to support the method, and to evaluate the application of the
cation and identify target areas for improvement, method and tool through practical trials. The results are the provi-
♦ determine if the desired safety benefit justifies the ex- sion of manual detailing procedures for identifying and structur-
pense burden, and ing evidence so that a system meets the safety requirements of IEC
♦ if necessary, establish streamlined processes for software 1508, the provision of a tool using BBN technology to automate
aspects of certification that are faster and less expensive than the implementation of the method, and a quantiﬁed comparison
the current processes. of the performance of the proposed method and tool compared to
ISO JTC1/SC7 (http://saturne.info.uqam.ca/Labo_Recherche/ conventional methods.
Lrgl/sc7/index_e_frameset.html). This committee is responsible Information Society Standardization System (http://www.
for developing ISO standards for software engineering. A liaison cenorm.be/isss). Created by the European Committee for
has been established with ISO/TC 176 and IEC/TC 56. Two of its Standardization, ISSS offers a workshop, “Accredited Testing of
related working groups are WG 9 Software Integrity and WG 6 Software in Safety-Critical Systems.”This group’s goal is to ensure
Software Evaluation and Metrics. that the approval, certiﬁcation, and evaluation process for safety-
IEC Technical Committee 56 (http://www.iec.ch/home- critical systems in which a software failure could be a safety haz-
e.htm). This committee works on standards for availability, reli- ard is handled within the EU to support the single market.
ability, maintainability, and maintenance support in any tech- RTCA/EUROCAE SC-190/WG-52 “Application Guidelines
nological areas considered appropriate, including those not for RTCA DO-178B (Softwa re)” (http://forum.pr.erau.edu/
normally dealt with by IEC Technical Committees. Some of its sc190/). Special Committee 190 has formed a Joint Activity with
software safety-related working groups include EUROCAE Working Group 52 to develop a series of position pa-
♦ TC 56/WG 10: Software Aspects, which develops several pers that will provide consistent clariﬁcation of ambiguities and
international standards related to dependability assessment of problems encountered in the application of RTCA DO-178B.
software (IEC 61704, IEC 61713, IEC 61714, IEC 61720); IEEE Sa fety Study Group instituted by the IEEE Software
♦ SC 65A/WG 9: Safe Software, which is responsible for the Engineering Standardization Committee, this group was created
publication of IEC 61508, functional safety of electrical, electronic, in November 1997 and is chaired by Victoria Stavridou. To be-
and programmable electronic safety-related systems Part 3; and come a member, contact her at firstname.lastname@example.org.
♦ SC 65A/WG 10: Functional Safety of Programmable The charter of the SSG is to:
Electronic Systems (PESR), which is responsible for the publica- ♦ Examine the existing standards collection to discover
tion of IEC 61508, functional safety of electrical, electronic, and places where safety requirements should be incorporated dur-
programmable electronic safety-related systems Parts 1-2, 4-7. ing the next revision cycle;
Squale—Security, Safety, and Quality Evaluation for ♦ Study the compatibility of existing IEEE standards with
Dependable Systems (http://albion.ncl.ac.uk/squale/index.html). IEC standards;
The objective of this Esprit project is to analyze the existing stan- ♦ Track the development of IEC 61508 and recommend
dards and practices in the safety and security area and to deﬁne adoption, modiﬁcation, or rejection;
a combined harmonized approach to gain conﬁdence in the cor- ♦ Recommend further actions; and
rectness and effectiveness of systems with safety and security re- ♦ Report back to SESC in 6-monthly intervals.
quirements. The project will deﬁne “dependability criteria” de-
scribing this harmonized approach and apply these criteria to a
normally applied at the end of the software devel- added cost required to fulﬁll the necessary safety re-
opment process. It consists of checking the fulfill- quirements and constraints.
ment of the derived system safety requirements and The current international standards for software
constraints for the software product, as deﬁned in development do not clearly define this parallel
the ﬁrst system development phases. Accepting the safety process. ISO 12207 mentions safety only as
product as part of the system—or as part of the soft- requirements to be implemented in the software,7
ware development or system testing environ- but safety should be deﬁned as a complete and vis-
ment—depends on the remaining level of risk and ible parallel process. Other standards do identify
6 IEEE Software July/August 1999
safety explicitly, but either cover certiﬁcation-only as diversiﬁcation.
issues, such as Do178B for the certiﬁcation of soft- Software requirements and constraints derived
ware in airborne systems,8 or belong to speciﬁc do- from system safety requirements can be applied to
mains, such as the British Defense Standards.4 any software development phase. Examples include
The certification process shown in Figure 1 has design constraints regarding software error han-
speciﬁc aspects that should be analyzed in more de- dling, coding constraints related to the application
tail. The relationship between system and software of speciﬁc coding rules, and stress tests to demon-
deserves special attention, since it is a subject of dis- strate system safety. Methods for translating system
cussion among different organizations and stan- safety requirements to software requirements are
dardization groups. immature,10 and the issue is even more complicated
when the systems are multidisciplinary.
System and software safety relationship A few international initiatives are trying to bring
The safety certiﬁcation process starts at the sys- together the system and software safety ﬁelds and
tem level: analyzing the system’s potential hazards to deﬁne standard requirements and methods for
and evaluating their probability and the severity of software safety
their consequences. Any project entails risks; risk (for more details The safety certiﬁcation
management is gaining importance as a discipline see the boxed
and as an integral part of project management. Risk text,
process starts at the
data forms the basis for multi-attribute decision mak- “International system level.
ing.9 Software Safety
Risk management includes these two factors: Initiatives,”on p. XX). These methods, requirements,
♦ systematically identifying and evaluating all and constraints are linked with the system safety crit-
risk causes and consequences prior to defining and icality levels that apply to software products and are
implementing a decision to accept, monitor, or also assigned from the system safety analysis. Part
take action. of IEC 61508, a generic system safety standard from
♦ systematically defining, implementing, con- the International Electrotechnical Commission’s Tech-
trolling, and verifying actions for eliminating risk or nical Committee 56, is dedicated to software safety.
reducing it to an acceptable level. Although IEC 61508 provides a general framework
When the risk is too high, developers must ei- for the safety of software systems many technical de-
ther eliminate or control hazards. They may need tails remain unresolved for multinational systems to
to define protection devices as part of the system operate effectively all around the world.
design. For example, they can add hardware in-
terlocks or software safe states. An alternative is Requirements engineering
to define protection procedures for system Requirements engineering is the initial step of the
usage—like defining what an operator should do software life cycle. It consists of acquiring the vari-
when the red emergency alarm light is on—to ous requirements for the software, including func-
control hazards in the system. Some of these sys- tional needs of potential users and nonfunctional
tem hazard controls can be in the software re- concerns about quality, performance, costs, and so
quirements. They could be defined as software on; precisely specifying these requirements; and
safety requirements or as functional, performance, evaluating if they are correct and feasible. This step
or any other kind of requirements including de- is critical in the software life cycle, because a variety
sign and implementation constraints. of errors can be introduced at this stage that may
In many cases, developers perform a system-level negatively inﬂuence the subsequent development
hazard analysis at the system design stage to en- process and the quality of the resulting software
sure they meet safety requirements. By applying the product. Requirements engineering must be carried
analyses to the ﬁnal design, it should demonstrate out with great care and precision since it is critical
that, for example, no single failure or double failure that the speciﬁcation be correct later during the sys-
point can cause catastrophic consequences. If tem certiﬁcation. In most domains, developers spec-
needed, developers can revise the system design to ify system requirements textually, with no way to
have completely redundant subsystems, a physically formally verify their correctness and completeness.
independent checking and monitoring subsystem, Recently proposed formal methods seek to help
or some software implementation constraints, such engineers capture and specify software require-
July/August 1999 IEEE Software 7
ments more precisely. These methods express re- methods may vary depending on the software’s crit-
quirements in a formal language, often based on icality class, life-cycle stage, and nature. For exam-
mathematical logic equipped with suitable struc- ple, COTS products require different analyses to ei-
turing mechanisms for organizing large, complex ther reject their use for a particular system or deﬁne
descriptions. Developers can then manipulate such boundaries that ensure their safety.
speciﬁcations formally. For example, they can check The safety analyses performed at each software
desired properties and detect errors using auto- development phase vary among standards and the
mated theorem proving techniques or obtain exe- different application domains. For example, formal
cutable prototypes using transformation tech- arguments to demonstrate that the object code sat-
niques. Most current requirements engineering isfies the formal specification in Def. Stan 00-554
methods are limited, however, since they are highly might not be required by standards used in other
application domains, or might be
difﬁcult to apply.4 As another ex-
Only practical demonstrations can validate the ample, DO178B specifies a diffi-
usability of some of the veriﬁcation methods. cult and expensive set of require-
ments to ensure that software
restricted in scope and provide very little support code does not have run-time errors for all test meth-
for capturing nonfunctional requirements and in- ods proposed.8
formation about the environment in which the soft- Software verification approaches fall into two
ware will run. More work is required in this area to main groups: dynamic and static. Existing stan-
ensure that certiﬁcation is based on a complete and dards use both to verify the software as part of
consistent set of requirements. the safety analysis shown in Figure 1. However,
these verification techniques are not advanced
Design and implementation constraints enough in relation to the safety integrity levels
Safety- or mission-critical subsystems have long needed for software. Formal verification tech-
been designed with fault-tolerant mechanisms, re- niques still have major drawbacks. First, they are
dundancies, and other techniques covering inher- not entirely practical. For example, showing con-
ited system-level safety requirements. Software fault sistency between the requirements and the code
tolerance is still a subject of research. For example, does not ensure confidence in safety since most
diversification, exception handling, or error recov- safety problems stem from flaws in the require-
ery mechanisms require further validation of their ments.5 Another drawback is feasibility, since the
usability and relationship with the safety integrity few formal verifications applied to real programs
levels. This is particularly on the new software-in- require massive effort for relatively small software,
tensive systems. Some existing standards require few properties can be verified using formal meth-
the use of specific design and coding constraints ods,11 and many formal methods are not readable
and, if carefully applied, can be the basis for accu- by system engineers and application experts who
mulating historical data on the use of these meth- should perform these analyses. System develop-
ods in safety-critical systems. Some recommenda- ers should use non-formal verification techniques
tions based on lessons from the Ariane 5 test ﬂight to complement dynamic and formal verification
failure were considered in defining the new set of methods for analyzing software-intensive safety-
European Space standards.9 critical systems.
More effort is required in these areas to gain con- Only practical demonstrations can validate the
ﬁdence about possible design and code constraints. usability of some of the veriﬁcation methods. These
Some international initiatives could share experiences demonstrations can address several issues:
and combine projects from different application do- ♦ The efﬁciency of using sometimes-expensive,
mains. For example, how is N-version programming 100 percent statement test coverage versus com-
related to the different software integrity levels? plementary methods when reaching 80 percent
Veriﬁcation methods ♦ The application of fault tree analysis to soft-
Because we cannot rely on historical data for ware design and code
safety verification of the software, developers ♦ Which metrics should be used to analyze the
should use other methods. The different analysis code, and their limits in relation to the integrity levels
8 IEEE Software July/August 1999
♦ How veriﬁcation-oriented software develop- the boxed text, “International Software Safety
ment will improve ﬁnal product quality Initiatives,” on p. XX.
SOME INTERNATIONAL INITIATIVES THE FUTURE: BUILDING SAFE
All of the above technical aspects are being an-
alyzed by several international standardization Many international initiatives have begun to an-
groups either individually or jointly. Both the Federal alyze and improve software safety and certiﬁcation,
Aviation Authority and Radio Technical Commission addressing both the legal and technical aspects.
for Aeronautics are working to improve the DO-178B Major changes will be needed regarding the exist-
standard8 for software considerations in airborne ing standards and methods to be used when build-
systems and equipment certification. An FAA sur- ing software that is embedded in multidomain sys-
vey10 described some of the problems encountered tems. An international certification authority will
when applying the RTCA standard DO-178B. The fol- emerge to certify the safety of the new systems.
lowing list is extracted from that FAA survey: Identifying the parallel safety process for the soft-
♦ DO-178B has inadequate and ambiguous guid- ware-speciﬁc technical aspects will affect the tech-
ance for requirement deﬁnition and analysis. niques and methods for development and testing,
♦ DO-178B has inadequate and ambiguous guid- as well as software management planning, cost, or-
ance for partitioning (e.g. The growing importance ganization, and development interfaces.
of partitioning is recognized and questions like Despite the deﬁciencies discussed here, the state
“what types of techniques are acceptable and what of international, interdomain safety certiﬁcation is
are the criteria to accept a partitioning strategy?”are slowly improving. New systems that contain soft-
still to be answered). ware-based safety-critical functions and are com-
♦ DO-178B has inadequate and ambiguous guid- posed of varied subsystems have already been im-
ance for veriﬁcation activities (e.g. no clear direction plemented without a mature certiﬁcation scheme
on regression analysis, different interpretations of in place. The current state of the art does not pro-
the applicability of coverage analysis techniques to vide answers to all the fundamental issues. We can-
different stages of veriﬁcation). not wait for all the answers that will free us from ac-
♦ DO-178B has inadequate and ambiguous guid- cidents and losses before building and using these
ance for COTS software. systems. “The beneﬁts of continued development
♦ DO-178B inadequately addresses the effect of seem to outweigh the perceived risks.”12 y
software on the safety of the overall system.
RTCA has created several working groups to pro-
vide consistent clariﬁcation of ambiguities and prob- A CKNOWLEDGMENTS
lems encountered in the application of RTCA DO- I thank several of my colleagues at ESA for their support
and valuable comments on an earlier draft of this article, as
178B. Working groups have been created to tackle well as my colleagues at the university.
DO178B details, such as the veriﬁcation process and
the process of incorporating COTS tools in critical
The IEEE software safety group is examining ex- R EFERENCES
1. EN 45020:1993 General Terms and Deﬁnitions Concerning
isting IEEE standards to identify areas where safety Standardization and Related Activities, CEN, Brussels, 1993.
requirements should be incorporated during the 2. ISO 8402:1994 Quality Management and Quality Assurance—
standards’ next revision cycle. The group is also Vocabulary, ISO, Geneva, 1994.
3. SCOPE: Esprit 2151 (Esprit Second Framework Programme),
studying the compatibility of existing IEEE standards Software Certiﬁcation on Program in Europe, DGIII, European
with IEC standards and is tracking the development Commission, Brussels.
of IEC 61508 with the ultimate goal of recommend- 4. Def Stan 00-55, Requirements for Safety-Related Software in
Defence Equipment, Issue 2, British Defence Standards, Ministry
ing its adoption, modiﬁcation, or rejection. of Defence, Glasgow, 1997.
Several separate European initiatives address de- 5. N. Leveson, Safeware: System Safety and Computers, Addison
pendability and other issues of safety-critical soft- Wesley Longman, Reading, Mass., 1995.
6. J.L. Lions, “Ariane 5 Flight 501 Failure: Report of the Inquiry
ware-intensive systems. Find more information Board,” Paris, 19 July 1996, http://www.esrin.esa.it/htdocs/
about these and other international initiatives in tidc/press/press96/ariane5rep.html.
July/August 1999 IEEE Software 9
7. ISO/IEC International Standard 12207, Information Technology -
Software Life-Cycle Processes, ISO/IEC, Geneva, 1995.
8. RTCA DO-178B, Software Considerations in Airborne Systems and
Equipment Certiﬁcation, RTCA, Washington DC, 1992.
9. ECSS standards series, European Cooperation for Space
Standardization, ESA Publications Division,
10. FAA Streamlining Software Aspects of Certiﬁcation, Tech. Report
11. Formal methods speciﬁcation and analysis guidebook for the
veriﬁcation of software and computer systems. NASA-GB-001-
12. P.V. Bhansali, “Universal Safety Standard Is Infeasible—For
Now,” IEEE Software, Mar. 1996, pp. 8, 10.
About the Author
Patricia Rodríguez-Dapena has been a
software engineer in the software engi-
neering and standards section of the
European Space Agency since 1992. Her
main interest is software engineering
and veriﬁcation for software in safety
critical systems; she is also interested in
software engineering standardization
and in software process modeling, implementation, and soft-
ware process assessment models. She has been employed in
the software industry since 1987 and has worked as a
programmer, analyst, and researcher.
Rodríguez-Dapena received an MS in computer science
from the Polytechnical University of Madrid (UPM), where she
is currently preparing her PhD.
Readers may contact Rodríguez-Dapena at ESA/ESTEC,
Keplerlan 1, 2200AG Noordwijk, The Netherlands; e-mail paro-
10 IEEE Software July/August 1999