Your SlideShare is downloading. ×
Softwcare Article - Software Safety Certification: A Multi-domain Problem
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Softwcare Article - Software Safety Certification: A Multi-domain Problem


Published on

This article focuses on software-safety certification, …

This article focuses on software-safety certification,
which will be considered as part of the overall system-safety certification.

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. ©1999 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. Multi-domain sof t ware-intensive systems, such as space systems used for aircraf t navigation, raise crucial cer tification issues. How do system safet y requirements translate into sof t ware requirements? What sof t ware verification methods can demonstrate the system’s safet y? Which organizations can legally suppor t safet y cer tification for such systems? Software Safety Certification: A Multi-domain Problem Patricia Rodríguez-Dapena, European Space Agency ertification is the “procedure by which a third-party gives written as- C surance that a product, process, or service conforms to specified re- quirements.”1 These certifications should assure conformance with the applicable requirements for a given purpose, within specific operations scenarios. Product certification focuses on specific, limited aspects and functions. For ex- ample, Y2K certification evaluates how effectively software will perform before, dur- ing, and after the date conversion, avoiding Y2K-related problems. In the aviation and nuclear domains, certification normally focuses on safety, or safety certifications, in which the requirements are based on safety objectives of the system. Following the above definition of certification, software certification should ensure that programs put on the market conform to a certain level of quality. ISO defines it as “the total- ity of characteristics of an entity that bear on its ability to satisfy stated or implied needs.”2 Software-safety certification corresponds specifically to safety objectives. 2 IEEE Software July/August 1999 0740-7459/99/$10.00 © 1999 IEEE
  • 2. Because software is not unsafe itself, and only con- when we cannot easily define 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 certification, which will be considered as part of the when one subsystem already exists and possible overall system-safety certification. new regulations and standards do not apply to it. In many application domains, safety certification 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 certification is the responsibility of na- rapidly, with critical functions increasingly imple- tional certification authorities, who cover all certifi- mented using software. For example, computer- cation aspects for systems belonging to specific ap- plication domains. It is also Many new systems are composed of subsys- based on well-known do- tems from different application domains. main-specific technical 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 defining 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 ification 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 definition 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 defined 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 certification of other purposes. For consumers and system opera- such a system is a complicated and largely uncharted tors, certification schemes legally recognized by na- area—no historical databases exist as a basis for the tional governments secure protection for their in- certification of the complex technical and interdo- vestments, efforts, and safety operations. main safety requirements. Further, no certification In some countries, any person, association, or authorities have yet been appointed due to the need company can set up a certification 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 certification on interdomain systems effective supervision.3 July/August 1999 IEEE Software 3
  • 3. Certification 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 certifies 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 fly. 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 certification au- tionally recognized certification 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 certifi- A legal problem arises when we build new sys- cation present an even more difficult 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 certifi- 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 certifica- plication domains, because no certification scheme tions, are based on safety objectives. exists yet for these interdomain systems. To define, agree upon, and apply a certification scheme for the Iterative certification process overall system, we need agreements between the For existing systems, safety certification follows various certification 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 certification 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 certificate, certification authori- certification scheme or historical information for the ties, and many other issues have not yet been de- new interdomain and software-intensive systems, fined for these new systems. the first certification of such systems will be based In addition, we need internationally recognized on validation of their new operation and perfor- accreditation of certification agencies, such as test- mance requirements, and on the verification 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 certification schemes and accredited subsystems. certification agencies—few accredited certification The process by which the certification authority agencies have expertise in software safety issues, and the applicant interact is often iterative, running which are not generally well defined 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 fication 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. fication. Developing a system based on stringent re- ESA is currently working in various international quirements, standards, and plans might not be committees intended to define and set the certifi- enough for system certification. 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 certification, 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 specifically 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
  • 4. 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 certification 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 certification, cul- from a later phase; the failure of the Ariane 5 first minating in the safety demonstration. This safety test flight6 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 overflow caused the catastrophic ment that the system is safe. event. To prevent the failure, developers could have Certifiers 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 verifications 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 certifications 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 fine 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
  • 5. INTERNATIONAL SOFTWARE SAFETY INITIATIVES FAA-SSAC ( FAA began Esprit Project 22187: Serene—Safety and Risk Evaluation the Streamlining Software Aspects of Certification (SSAC) program Using Bayesian Nets ( to address concerns about time and expense associated with soft- The project’s objectives are to develop a method for constructing ware aspects of certification. The primary objectives are to software safety arguments using BBNs, to adapt an existing BBN ♦ analyze the current software approval process for certifi- 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 quantified comparison the current processes. of the performance of the proposed method and tool compared to ISO JTC1/SC7 ( 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 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, certification, and evaluation process for safety- IEC Technical Committee 56 ( 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)” ( 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 clarification 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 ♦ 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 ( 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 define adoption, modification, or rejection; a combined harmonized approach to gain confidence 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 define “dependability criteria” de- scribing this harmonized approach and apply these criteria to a demonstrator system. normally applied at the end of the software devel- added cost required to fulfill 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 defined in development do not clearly define this parallel the first 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 defined 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
  • 6. safety explicitly, but either cover certification-only as diversification. issues, such as Do178B for the certification of soft- Software requirements and constraints derived ware in airborne systems,8 or belong to specific 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- specific aspects that should be analyzed in more de- dling, coding constraints related to the application tail. The relationship between system and software of specific 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 certification process starts at the sys- together the system and software safety fields and tem level: analyzing the system’s potential hazards to define 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 certification 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 influence 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 final 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 specification be correct later during the sys- point can cause catastrophic consequences. If tem certification. 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
  • 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 define descriptions. Developers can then manipulate such boundaries that ensure their safety. specifications 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 difficult to apply.4 As another ex- Only practical demonstrations can validate the ample, DO178B specifies a diffi- usability of some of the verification 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 certification 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 flight 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 fidence about possible design and code constraints. usability of some of the verification methods. These Some international initiatives could share experiences demonstrations can address several issues: and combine projects from different application do- ♦ The efficiency 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 statement coverage Verification 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
  • 8. ♦ How verification-oriented software develop- the boxed text, “International Software Safety ment will improve final product quality Initiatives,” on p. XX. SOME INTERNATIONAL INITIATIVES THE FUTURE: BUILDING SAFE SYSTEMS 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 certification, 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-specific technical aspects will affect the tech- ance for requirement definition 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 deficiencies discussed here, the state “what types of techniques are acceptable and what of international, interdomain safety certification 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 verification activities (e.g. no clear direction plemented without a mature certification 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 verification). 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 benefits 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 clarification 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 verification process and the process of incorporating COTS tools in critical application. The IEEE software safety group is examining ex- R EFERENCES 1. EN 45020:1993 General Terms and Definitions 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 Certification 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, modification, 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, about these and other international initiatives in tidc/press/press96/ariane5rep.html. July/August 1999 IEEE Software 9
  • 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 Certification, RTCA, Washington DC, 1992. 9. ECSS standards series, European Cooperation for Space Standardization, ESA Publications Division, 10. FAA Streamlining Software Aspects of Certification, Tech. Report NASA/TM-1998-207648, 1998, 11. Formal methods specification and analysis guidebook for the verification of software and computer systems. NASA-GB-001- 97, 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 verification 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