Safety Certification of Software-Intensive Systems with Reusable Components

Transcription

1 Safety Certification of Software-Intensive Systems with Reusable Components Report type Report name Deliverable D4.4.1 Guidelines for tools and methodology integration for reusability of component in other domains (on tools/interface level) Dissemination level PU Status Final version Version number 1.0 Date of preparation The SafeCer Consortium 1 (41)

2 Authors Authors Petr Böhm, AIT Thomas Gruber, AIT Stefano Puri, INTECS Ricardo Moreno Ruano, TAS-E Sanchez Angel Alvaro, TAS-E Arjan Geven, TTTECH Ainhoa Aristimuno, ULMA The SafeCer Consortium 2 (41)

3 Revision chart and history log Version Date Reason AIT: TOC first draft AIT: Update after first telco AIT: Update after second telco, Chapter 3.1 and 5 updated INTECS/TAS-E: Contribution to Chapter and AIT: Chapters 1, 2 and 8. AIT:Updates after thirst telco TTTECH: First contribution to Chapters and 4.3 First Ideas to Chapter 5 AIT: Merge the contributions from ULMA and INTECS Small text corrections TTTECH: Conclusions ULMA: Chapter AIT: Chapters 5 and 6 Merge the contributions Last updates Finalizing of the document before the review Finalizing the document after reviews The SafeCer Consortium 3 (41)

4 List of abbreviations API ASIL GG2E CMMI DAL DECOS EMC EPF FMEA FTA GPM HW IEC ISO MTTF PAS PES PFD PLC PSAC SAS SIL SEooC SWooC SFTA SPL SPLE SOUP SW THR V&V Application Program Interface Automotive Safety Integrity Level Club des Grandes Entreprises de l Embarque Capability Maturity Model Integration Design Assurance Level Dependable Embedded Components and Systems Electromagnetic Compatibility Eclipse Process Framework Failure Mode and Effects Analysis Fault Tree Analysis Generic Process Model Hardware International Electrotechnical Commission International Standardization Organization Mean Time To Failure Publicly available specification (in IEC, ISO pre-standard-like) Programmable Electronic System Probability of Failure on Demand Programmable Logic Controller Plan for Software Aspects of Certification Software Accomplishment Summary Safety Integrity Level Safety Element out of Context Software out of Context Software Fault Tree analysis Software Product Line Software Product Line Engineering Software Of Unknown Pedigree Software Tolerable Hazard Rate Verification and Validation The SafeCer Consortium 4 (41)

5 Table of contents Authors... 2 Revision chart and history log... 3 List of abbreviations... 4 Table of contents... 5 List of Figures... 7 List of Tables Introduction Scope of this document Structure of this document Input from previous psafecer work Standards in Other Domains Overview of the Standards for Other Domains IEC and IEC (Healthcare Domain) IEC 61508, IEC 61511, IEC (Industry Domain) ECSS-E-ST-40C and ECSS-Q-ST-80C (Space Domain) Comparison of the Other Domain Standards with IEC Commonalities and differences for the Healthcare Domain Commonalities and differences for the Industry Domain Commonalities and differences for the Space Domain Reuse of Components in Other Domains Healthcare Domain - IEC and IEC Introduction Handling of Safety Case and Evidence for reuse of Software Reuse of Safety related subsystems and components Qualifications Proven In Use Handling Product lines Industry Domain - IEC 61508, IEC 61511, IEC Introduction Handling of Safety Case and Evidence for reuse of Software Reuse of Safety related subsystems and components Qualification Proven In Use Handling Product lines The SafeCer Consortium 5 (41)

6 4.2.7 Strategies for reuse Space Domain - ECSS-E-ST-40C and ECSS-Q-ST-80C Introduction Handling of Safety Case and Evidence for reuse of Software Reuse of Safety related subsystems and components Qualification Proven In Use Handling Product lines Strategies for reuse Results Results for the Healthcare Sector Results for the Industrial Sector Results for the Space Sector Outline for an Open, Extendable and Adaptable Framework for Component Reuse 37 6 Contribution to overall psafecer objectives Conclusions References The SafeCer Consortium 6 (41)

7 List of Figures Figure 1: Relationship of key medical device standards to IEC extracted extracted from [2] - Annex C Figure 2: ECSS Architecture (from ECSS website) Figure 3: Reuse activities Figure 4: Tool qualification activities Figure 5: Mapping of standards from different domains The SafeCer Consortium 7 (41)

8 List of Tables Table 1: Mapping of the parameters used to determine the safety integrity level (Healthcare) Table 2: Severity of Consequences (Table extracted from ECSS-Q-ST-40C) Table 3: Mapping of the parameters used to determine the safety integrity level (Space) The SafeCer Consortium 8 (41)

9 1 Introduction 1.1 Scope of this document This document describes the psafecer Deliverable D4.4.1 Guidelines for tools and methodology integration for reusability of component in other domains (on tools/interface level). The document covers the following domains and standards: Healthcare Domain - IEC and IEC Industry Domain - IEC 61508, IEC and IEC Space Domain - ECSS-E-ST-40C and ECSS-Q-ST-80C 1.2 Structure of this document This document starts with an Overview of the Standards for Other Domains (Healthcare, Industry, Space) in Chapter 3.1. In Chapter 3.2 the comparison with the Standard IEC is given. The Chapter 4 focuses on the reuse of components put forward by the domain-specific standards. Reuse of components can be achieved in different forms and follows different lines, from small building blocks to large complex applications, and the way this reuse is handled in the different domains also varies. This chapter is split between the sections on safety-case aspects, application re-use, qualification, proven in use, and product lines. The Chapter 5 summarizes - in three domain-specific sections - the results of the analysis of the standards-related constraints forming an obstacle to an unified methodology. Subsequently, Chapter 5.4 presents an Outline for an Open, Extendable and Adaptable Framework for Component Reuse. Finally, contribution to the overall psafecer objectives is provided in Chapter 6 and conclusions are provided in Chapter 7. The SafeCer Consortium 9 (41)

10 2 Input from previous psafecer work The results and the experiences from psafecer WP2.1 and WP4.1 are used as a basis, especially the combined Deliverable D2.1.4./D Guidelines with respect to different standards. Modeling and methodology for reusing software in automotive, construction equipment, avionics and railway domains [9] and D2.1.1 A Generic Process Model for Integrated Certification and Development of Component-based Systems [10] The SafeCer Consortium 10 (41)

11 3 Standards in Other Domains In this Chapter an overview of the Standards for Other Domains (Healthcare, Industry, Space) and the comparison with the Standard IEC are given. 3.1 Overview of the Standards for Other Domains IEC and IEC (Healthcare Domain) IEC , Second Edition, is an international standard for the safety of medical electrical equipment. It is actually a set of standards that is broken up into three distinct areas: 1. IEC covers all the general requirements for all electrical medical based products. 2. The collateral standards cover horizontal issues such as system integration, EMC, radiation protection, and programmable electronic medical systems (software, firmware, etc.). The standard numbers are IEC , -1-2, -1-3, and -1-4 respectively. 3. Particular standards deal with a specific type of medical device. The particular standards are identified as IEC XX where XX identifies the particular standard number for the particular type of medical equipment. An example would be IEC is the particular standard for High Frequency Surgical Devices IEC refers to IEC The IEC standard is the base for safety in medical electrical equipment. IEC 62304:2006 (Medical device software Software life cycle processes), defines the life cycle requirements for medical device software. The set of processes, activities, and tasks described in this standard establishes a common framework for medical device software life cycle processes IEC 61508, IEC 61511, IEC (Industry Domain) IEC61508 is regarded as one of the oldest safety standards and therefore the basis for several standards related to generic system functional safety. In this sense, large parts of the IEC61508 are similar to other domains (e.g.. railway and automotive) although at places significant differences and generalizations exist. While IEC61508 is a generic standard for design, construction, and operation of electrical/electronic/programmable electronic systems, IEC61511 focuses attention on one type of instrumented safety system used within the process industry sector, the Safety Instrumented System (SIS). An SIS is engineered to perform specific control functions to failsafe or maintain safe operation of a process when unacceptable or dangerous conditions occur. IEC61131 is a standard applicable for programmable controllers. The IEC is an international standard of rules applied in industry. It is titled Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems (E/E/PE or E/E/PES). This standard sets out a generic approach for all safety lifecycle activities for systems comprised of electrical and/or electronic and/or programmable electronic elements that are used to perform safety functions. As usually safety is achieved by a number of systems which rely on different technologies (e.g. mechanical, hydraulic, electrical etc.), any safety strategy must therefore consider not only all the elements within an individual system but also all the safetyrelated systems making up the total combination of safety-related systems. Although this standard is concerned with E/E/PE safety-related systems, it may also provide a framework within which safety-related systems based on other technologies may be considered. The SafeCer Consortium 11 (41)

12 This standard is organized into 7 parts: Part1: o o o o o Development of the overall safety requirements Allocation of the safety requirements to the E/E/PE safety-related systems Specification of the system safety requirements for the E/E/PE safety-related systems Installation, commissioning & safety validation of E/E/PE safety-related systems Operation, maintenance, repair, modification and retrofit, decommissioning or disposal of E/E/PE safety-related systems Documentation Management of functional safety Functional safety assessment o o o Part2: o Part3: o Realization phase for safety-related software Part4: o Definitions & abbreviations Part5: o Example of methods for the determination of safety integrity levels Part6: o Guidelines for the application of Parts 2 & 3 Part7: o Realization phase for E/E/PE safety-related systems (mainly hardware considerations) Overview of techniques and measures Regarding SW development with a focus on reuse of software components, the standard does not address the development of software-out-of-context. Safety is a matter that concerns the system as a whole. When software is going to be reused, the reused component has to fit into the safety concept of the system. There are two chapters in the standard that directly address SW reuse. These are the chapters and of Part 3 of the standard. They basically state that SW can be reused if either the SW has been developed in compliance with this standard or evidence can be provided that the SW is proven in use or the assessment of non-compliant development according to of Part 3 is positive. Furthermore the chapter C.2.10 of Part 7 of the standard addresses techniques and measures for the use of trusted/verified software elements ECSS-E-ST-40C and ECSS-Q-ST-80C (Space Domain) In any software project, both ECSS-E-40 and ECSS-Q-80 apply, and they complement each other. ECSS Q ST 80 specifies requirements to ensure the software is developed to perform as expected and safely in the operational environment meeting the quality objectives agreed for the project. ECSS-Q-ST-80 requires to identify the safety criticality classification, the methods and techniques for safety analysis, and the technical requirements for software, in relation to the overall aim at system level to protect flight and ground personnel, the launch vehicle, associated payloads, ground support equipment, the general public, public and private property, the space system and associated segments and the environment from hazards associated with European space systems. The supplier shall perform safety audits or reviews to verify compliance to project safety policy and requirements. In particular the supplier shall submit a safety data package to support reviews. The safety data package shall contain at least the following safety related documentation: The SafeCer Consortium 12 (41)

13 1. Safety analysis report; 2. Supporting analysis (if applicable); 3. Safety risk assessment (if applicable); 4. Hazardous ground operations list and procedures; 5. Safety verification tracking log (SVTL). The ECSS-M branch defines the requirements to be applied to the management of space projects. ECSS-E-ST-40 and ECSS-Q-ST-80 describe how the ECSS-M series of standards apply to the management of software projects. In addition, requirements that cannot be found in the M-branch because they are specific to software product assurance are defined in ECSS-Q-ST-80. In the ECSS no significant development process or requirements are addressed to the development of the software intended to be reused. For instance ECSS-E-ST-40 states that if the software is written for the reuse, then its provided functionality, from an external point of view, and its external interfaces must be documented. ECSS-E-ST-40 contains some specific clauses applicable to projects that intend to reuse software products from other space projects and third-party commercial off-the-shelf products to be part of the software product. In this respect, the ECSS-E-ST-40 makes reference to the Software Reuse File (SRF). The purpose of the SRF is to document the identification and analysis that is to be performed on existing software which is intended to be reused. The ECSS handbook (ECSS-Q-HB-80-01A) provides guidance on the approach that can be taken when defining the implementation of activities for the reuse of existing software within a space project. Existing software is defined in ECSS Q ST 80 as follows: Any software from previous developments that is used for the project development as is or with adaptation. It also includes software supplied by the customer for use in the project development. Any software including any software developed outside the contract to which ECSS software standards are applicable. Any software including products such as freeware and open source software products. The SafeCer Consortium 13 (41)

14 3.2 Comparison of the Other Domain Standards with IEC In this Chapter a comparison of the Standards for Healthcare, Industry and Space domain with the Standard IEC will be described Commonalities and differences for the Healthcare Domain In the healthcare domain, the reference standard for software is IEC Software is considered a subsystem of the medical device or is itself a medical device. This standard is to be used together with other appropriate standards when developing a medical device. Medical device management standards such as ISO and ISO provide a management environment that lays a foundation for an organization to develop products. Standards such as IEC and IEC give specific direction for creating safe medical devices. When software is a part of these medical device, IEC provides more detailed direction on what is required to develop and maintain safe medical device software. Many other standards such as ISO/IEC 12207, IEC and ISO/IEC can be looked at as a source of methods, tools and techniques that can be used to implement the requirements in IEC Figure 1 shows the relationship of these standards. Figure 1: Relationship of key medical device standards to IEC extracted extracted from [2] - Annex C. The SafeCer Consortium 14 (41)

15 The standard makes the following mention concerning the standard IEC 61508: The question has been raised whether this standard, being concerned with the design of SAFETYcritical software, should follow the principles of IEC The following explains the stance of this standard. IEC addresses 3 main issues: 1) RISK MANAGEMENT life cycle and life cycle PROCESSES; 2) definition of Safety Integrity Levels; 3) recommendation of techniques, tools and methods for software development and levels of independence of personnel responsible for performing different TASKS. Issue 1) is covered in this standard by a normative reference to ISO (the MEDICAL DEVICE sector standard for RISK MANAGEMENT). The effect of this reference is to adopt ISO s approach to RISK MANAGEMENT as an integral part of the software PROCESS for MEDICAL DEVICE SOFTWARE. For issue 2), this standard takes a simpler approach than IEC The latter classifies software into 4 Safety Integrity Levels defined in terms of reliability objectives. The reliability objectives are identified after RISK ANALYSIS, which quantifies both the severity and the probability of HARM caused by a failure of the software. This standard simplifies issue 2) by disallowing consideration of probability of software failure prior to classification. Classification into 3 software safety classes is based only on the severity of that HARM caused by a failure. After classification, different PROCESSES are required for different software safety classes: the intention is to further reduce the probability of failure of the software. Issue 3) is not addressed by this standard. Readers of the standard are encouraged to use IEC as a source for good software methods, techniques and tools, while recognizing that other approaches, both present and future, can provide equally good results. This standard makes no recommendation concerning independence of people responsible for one software ACTIVITY (for example VERIFICATION) from those responsible for another (for example design). In particular, this standard makes no requirement for an independent safety assessor, since this is a matter for ISO In summary, even if both IEC and IEC describe lifecycle related activities, IEC is more prescriptive than IEC specially in the measures/techniques to be applied in each stage. Software classification follows a different approach on IEC and IEC The latter is not probability aware. They share in common that they modulate lifecycle activity and documentation effort according to software classification. The remaining sections further describe differences and commonalities arranged in a way that will ease comparison with other domains High Level Process In medical domain, V-cycle is a reference but manufacturers can choose their own. IEC is similar to DO-178 in this sense. But in general, in terms of high-level process, it can be determined that the standards IEC and IEC are similar.iec requires a connection to a risk management process described in ISO In this sense, risk management plays the main role in the development in the same way as safety does for IEC The SafeCer Consortium 15 (41)

16 Integrated Safety or "External" Safety Systems The Risk Control Measures are defined in ISO (Medical devices Application of risk management to medical devices). ISO does not specify which architecture should be used, whether internal or external. Anyway, IEC implicitly assumes an integrated approach Objective-Oriented or Product-Oriented Approach Due to the increasing importance of software in medical devices, standards are undergoing a shift to take into account the software development process as experience has shown that exclusively paying attention to the product doesn t necessarily cover software related risk issues. Therefore, standards such as IEC aim to mitigate software related risks with an objective-oriented approach Severity and Assurance/Safety Integrity Levels As mentioned in the beginning of this chapter, the classification that IEC standard makes is different from IEC The safety class assigned to each software system shall be made according to the possible effects on the patient, operator, or other people resulting from a hazard to which the software system can contribute. The software safety classes shall initially be assigned based on severity as follows: Class A: No injury or damage to health is possible Class B: Non-serious injury is possible Class C: Death or serious injury is possible Besides, the source of failure is not categorized as in IEC 61508, there is not a mention for random hardware faults or systematic development faults. IEC mentions IEC as a reference but it doesn t mandate you follow a particular approach to avoid systematic faults Hazard and Risk Analysis and Tolerable Hazard Rate In order to perform this analysis, the standard ISO14971 should be followed. The concept of risk is the combination of the following two components: - the probability of occurrence of harm (where the definitions for probability can be different for different product families); - the consequences of that harm, i.e., how severe it might be. Parameter according to IEC /14971 Frequency of, and exposure time of hazardous situation Consequence of hazard Possibility of avoiding hazard Probability of the unwanted occurrence Not used Severity Risk Control Probability Table 1: Mapping of the parameters used to determine the safety integrity level (Healthcare) The SafeCer Consortium 16 (41)

17 Risk estimation can be quantitative or qualitative. In situations where sufficient data are available, a quantitative categorization of probability levels is preferred. If this is not possible, a qualitative description should be given. A good qualitative description is preferable to an inaccurate quantitative description Comparison and Consolidation of Functional Safety Standards: Current Initiatives Nothing to add. This section is kept to ease comparison with other domains Classification of Requirements in Standards with respect to Different Criteria In the standard IEC 62304, the methods, tools and techniques that can be used to implement the requirements defined in the standards are not defined, and it suggests other standards (including IEC 61508) as an information source Conclusions Although at a high level of comparison, IEC and IEC have a similar lifecycle based approach, IEC can not be grouped together with standards derived from IEC or with the avionics domain as software classification in IEC and Safety Integrity Levels in IEC not only have different definitions but also the implications in the development are handled differently. IEC isn t an standalone standard and must be applied in close collaboration with ISO and ISO not to mention collateral standards specific to each device type. Nevertheless, IEC provides a more demanding framework for safety software development and it could be argued that it can cover IEC requirements Commonalities and differences for the Industry Domain The IEC is already heavily referred to in D2.1.4/4.1.2 Chapter 3. Therefore, no additional commonalities or differences can be identified Commonalities and differences for the Space Domain The European Cooperation for Space Standardization (ECSS) is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the development of a coherent, single set of user-friendly standards for use in all European space activities. The result of this effort is the ECSS series of standards (ST), handbooks (HB) and Technical Memoranda (TM) which are organized in four branches (M: Space project management; Q: Space product assurance; E: Space engineering; U: Space sustainability) under a global heading of ECSS-X-YY-ZZ where X stands for the branch of standardization, YY for the kind of document and ZZ for a number associated to a specific field. E.g: ECSS-Q-ST-80C means the Quality Standard for Software (revision C). See Figure 2 for a more detailed view of the ECSS branches and addressed disciplines. The SafeCer Consortium 17 (41)

18 Figure 2: ECSS Architecture (from ECSS website) The endorsement of ECSS as European Norm is currently in progress; currently there is no general policy or enforcements by laws regarding the adaption of the ECSS for the development of space systems. ECSS does not regard itself in any way as a certification authority; each European country is in charge to define the proper restriction rules about space installations and procedures. In the rest of this document the name ECSS is used to refer to the standard series, if not otherwise stated High Level Process One of the fundamental principles of the ECSS standard series, and distinctive difference compared to the standards from the other domains, is the explicit customer-supplier relationship, assumed for all system and software developments, where the supplier demonstrates compliance with the customer requirements and provides the specified evidence of compliance. How and which parts of the ECSS must be applied is specified through contract, in a way that depends on the given mission. In the ECSS the development of the software is always related to a complete space project and its different phases, with a strong focus on the integration with system level activities. The main software standard is ECSS-E-ST-40, part of the ECSS engineering branch (E). It covers all aspects of space software engineering, from requirements definition to retirement. It defines the scope of the space software engineering processes, including details of the verification and validation processes, and their interfaces with management and product assurance, which are addressed in the management (M) and product assurance (Q) branches of the ECSS system. The SafeCer Consortium 18 (41)

19 ECSS-E-ST-40 refers the ECSS-Q-ST-80 for the Software Product Assurance requirements related to the development and maintenance of software for Space Systems. Both two apply to any software project. According to the approach of ISO/IEC the ECSS-E-ST-40 provides a process model for the SW development activities, without prescribing a particular software life cycle Integrated Safety or "External" Safety Systems According to ECSS hazards that are not eliminated through design selection shall be reduced and made controllable through the use of automatic safety devices as part of the system, subsystem or equipment. However it is stated that software in automatic safety devices should be avoided, or justification for its usage shall be provided Process-Oriented or Product-Oriented ECSS is both a process-based and product- based framework, although more process-oriented as it takes origin from ISO/IEC In fact, ECSS is based on processes, and lets the user choose an own life-cycle and approach, with appropriate methods and tools. ECSS-Q-ST-80C does not impose constraints on the way software safety assurance issues must be addressed; it only requires that, during the definition of the project, a specific software safety assurance plan is prepared, where the customer and the supplier take care of a list of well identified topics. Such list depends on the criticality level of the considered software, e.g. in order to properly apply, in turn, subsequent software safety and dependability methods and techniques Categorizing Severity and Assurance/Safety Integrity Levels Space systems are required to be evaluated from the safety and dependability points of view, at early stages of their definition and partitioning, by assigning a criticality level (from A to D) to each of its components or subsystems, including the software components or subsystems. The criticality classification required by [ECSS-Q-40] and [ECSS-Q-30] is based on the severity of the consequences of system hazardous events and system failures. The severity categories (Catastrophic, Critical, Major and Minor/Negligible) are defined in a table which is shared by the two standards (see table 2). Safety is only concerned with the two highest levels of the severity scale, whereas dependability spans across the three lowest severity categories. The SafeCer Consortium 19 (41)

20 Severity Level Dependability (refer to ECSS-Q-ST-30) Extract from ECSS-Q-ST-30 Safety (ECSS-Q-ST-40) Catastrophic 1 Failures propagation Loss of life, life-threatening or permanently disabling injury or occupational illness; Loss of system; Loss of an interfacing manned flight system; Loss of launch site facilities; Severe detrimental environmental effects. Critical 2 Loss of mission Temporarily disabling but not lifethreatening injury, or temporary occupational illness; Major 3 Major mission degradation --- Minor or Negligible 4 Minor mission degradation or any other effect Major damage to interfacing flight system; Major damage to ground facilities; Major damage to public or private property; Major detrimental environmental effects. NOTE: When several categories can be applied to the system or system component, the highest severity takes priority --- Table 2: Severity of Consequences (Table extracted from ECSS-Q-ST-40C) The Common Notion of Safety in the Considered Standards No differences here to be outlined Hazard and Risk Analysis and Tolerable Hazard Rate In ECSS the hazard analysis is covered by ECSS-Q-ST-40-02C where the steps and tasks necessary to identify and classify hazards, and to achieve their reduction, are outlined. Table 3 below integrates the information provided in deliverable D214_D412-table1 by mapping the parameters of the generic standard IEC to the corresponding parameters of the ECSS, and so highlighting the different origins of these two standards. The SafeCer Consortium 20 (41)

21 Parameter according to IEC Frequency of, and exposure time of hazardous situation Consequence of hazard Possibility of avoiding hazard Probability of the unwanted occurrence ECSS Not used Severity Not used Not used Table 3: Mapping of the parameters used to determine the safety integrity level (Space) Regarding dependability, the probability targets concerning tolerable failure rates are explicitly mentioned in the standard itself, but their values are not defined. These targets are set on a project by project basis Other Commonalities and Differences in the Standards ECSS has the peculiarity of allowing the tailoring, on project-basis. No other standards envisage this by rule. Tailoring means that on a project-basis, and hierarchically in the chain, each Customer may determine the applicable ECSS standards and requirements therein, for his own Suppliers. This tailoring must be justified, coherent, and consistent throughout the Customer-Supplier chain, and always be visible to the higher level Customer. ECSS E-ST-40C and Q-ST-80C contain criticality-driven applicability tables, fully equivalent to those provided by the standards above. As usual, in such tables each requirement is made applicable or not according to the criticality level of the concerned software. The difference lies in the fact that such tables actually represent an indication only (namely, suggested criticality-driven tailoring). On a project basis they may be waived Classification of Requirements in Standards with respect to Different Criteria Methods, techniques and tools are covered by ECSS Handbooks. Handbooks are not standards and thus they are not normative. However, they contain requirements and suggestions that, on a project basis, may be incorporated and made applicable. Sometimes handbooks contain requirements in beta-test. These latter, once consolidated and reviewed, are then incorporated in new (or updated) standards. Similarly to topics covered in DO-178C Technology Supplements (e.g. DO-331[9]), some subjects are actually covered in ECSS standards or handbooks (namely Modeldriven, tool qualification and auto-code matters); However, not as exhaustive and not in a restrictive way as in DO-178C Conclusions ECSS has different origin than IEC 61508, so they share very little similarities. ECSS can be grouped into the avionics domain class. ECSS in fact cites several other standards (e.g. ISO/IEC 12207). However the only domain-specific standard (not ISO, not IEC, not IEEE) that is cited in the bibliography, and multiply taken into account, is the ED-12B/DO-178B. The SafeCer Consortium 21 (41)

22 4 Reuse of Components in Other Domains The focus of this chapter is on the reuse of components put forward by the domain-specific standards. Reuse of components can be achieved in different forms and follows different lines, from small building blocks to large complex applications, and the way this reuse is handled in the different domains also varies. The chapter is split between the sections on safety-case aspects, application re-use, qualification, proven in use, and product lines. Figure 3 below is taken from the ECSS Q HB 80 01A (the ECSS handbook covering Reuse of existing software) and shows the following phases that should be performed for each reused existing software item, also taking into account the relationship with the project input/output and the role of the customer: Requirements phase definition of the requirements to be fulfilled by the existing software candidates by requirements identification, gap analysis and definition of derived requirements. Assessment phase selection and justification of the best choice according to the identified requirements from the previous phase and identification of corrective actions. Integration Phase acquisition, inspection, adaptation, configuration management of the selected reused existing software into the system software of the project. Qualification Phase qualification activities performed on the existing software reused in parallel to current software development. Figure 3: Reuse activities The SafeCer Consortium 22 (41)

23 4.1 Healthcare Domain - IEC and IEC Introduction There are three components to distinguish in terms of reuse according to IEC 62304: - Software item: any identifiable part of a computer program - Software system: integrated collection of software organized to accomplish a specific function or set of functions. - SOUP: Software Of Unknown Provenance (acronym): software that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device (also known as off-the-shelf software ) or software previously developed for which adequate records of the development processes are not available SOUP should not be confused with ISO Safety Element out of Context definition. In the following chapters the reuse approaches are described according to the component type Handling of Safety Case and Evidence for reuse of Software Medical devices industry uses a Risk Management File instead of a safety case, although they are not directly equivalent. The ISO is the standard for application of risk management to medical devices, and the technical report IEC/TR guides on the application of ISO to medical device software. The standard doesn t mention the reuse of components, but according to technical report IEC/TR a reused component should be treated as SOUP. In addition, the following procedures must be done: Software development process: A software development plan shall be established in order to achieve the fixed scope. This plan has to include the following information: - software configuration and change management, including SOUP configuration items and software used to support development - the standard, methods and tools - integration and integration testing planning (also including SOUP) and verification planning - a risk management process (Risk Management File). These all documentation shall be properly referenced (title, responsible, purpose, etc). The items to be controlled shall include tools, items or settings, used to develop the medical device software, which could impact the medical device software. The interfaces between items (even sw or hw, or SOUP) must be identified, as well as the proper operation of the SOUP item. Software maintenance process: A maintenance plan must be defined, where the risk of modification of items (including SOUP) must be defined. Software risk management process: The items that could contribute to a hazardous situation must be identified and implement risk control measures to control or avoid them. The causes can be: a) incorrect or incomplete specification of functionality; b) software defects in the identified software item functionality; The SafeCer Consortium 23 (41)

24 c) failure or unexpected results from SOUP; d) hardware failures or other software defects that could result in unpredictable software operation; and e) reasonably foreseeable misuse. These control measures must be also verified. When changes are made in items (including the SOUP) the risk that this could arise must be taken into account. Software configuration management process: All the configuration must be identified properly and changes must be controlled Reuse of Safety related subsystems and components As mentioned in Chapter 4.1.2, different measures should be taken when reusing components Reusing SOUP If the software component to reuse is a SOUP, the following steps should be followed: Software development process: - Development plan: The SOUP must be included in the configuration management together with the other items. The SOUP should be in the integration plan. The SOUP should be taken into account when carrying out the risk management development. - Software requirements analysis: The SOUP requirements should be taken into account. - Software architectural design: The functional and performance requirements for the SOUP item shall be specified as well as the system hardware and software required by the SOUP. Software maintenance process: Establish a software maintenance plan where upgrades, bug fixes, patches and obsolescence of SOUP are evaluated Software risk management process: If failure or unexpected results from SOUP is a potential cause of the software item contributing to a hazardous situation, the list of anomalies published by the supplier shall be evaluated. to determine if any of the known anomalies result in a sequence of events that could result in a hazardous situation. Software configuration management process: The following information shall be documented for each SOUP configuration item being used: a) the title, b) the manufacturer, and c) the unique SOUP designator The SafeCer Consortium 24 (41)

25 Reusing software item If the software component to reuse is a software item, for example a software component that is already used in a certified product, the following records are needed (besides the ones defined in the Chapter 4.1.2): - Component classification - Software detailed design - Software unit implementation and verification - Software integration and integration testing If reusing this type of item, it is supposed that the records already exist Qualifications IEC does not specify neither software component nor tool qualification requirements for reuse. Software reuse needs to take the SOUP approach, and this implies that previous evidence is not a guarantee for next developments or products. Tool qualification isn t specifically mentioned although it can be implicitly understood from a risk management perspective that verification activities are required if a hazardous situation can arise from a tool usage Proven In Use As mentioned in 4.1.4, the concept proven in use does not apply to software components but it could be used for providing evidence for tools Handling Product lines Nowadays product lines of medical equipment in general and in particular defibrillators share several features together. In the case of Osatu defibrillator products, each model has its own set of functional features, and it shares many of them with other models. Usually, those shared features are core product features and main differences remain in the GUI. The purpose is to identify the components that could make them independent from the environment so they can be easily integrated in other platforms or products. The SafeCer Consortium 25 (41)

26 4.2 Industry Domain - IEC 61508, IEC 61511, IEC Introduction Chapter of Part 3 of the IEC directly addresses the topic of pre-existing software. The concept of SWooC (software out of context) does not exist in the IEC 61508, but a proper modular software design approach with a clear separation of concerns will fulfill the same goal. Besides the software code itself, reuse may comprise all development process artifacts, the safety manual as well as the testing artifacts Handling of Safety Case and Evidence for reuse of Software The term Safety Case does not exist in the IEC On the other hand the term Functional Safety exists, which determines the part of the overall safety relating to the Equipment under Control (EUC) and the EUC control system that depends on the correct functioning of the E/E/PE safety-related systems and other risk reduction measures. So putting the focus on SW components the safety case can be considered as satisfying Functional Safety for the SW component to be reused with respect to the overall safety case of the system. Depending on the reusability factor only a subset of the evidence artifacts or all evidence artifacts can be reused. There no mechanism for a separate artifact which only considers the reuse aspects Reuse of Safety related subsystems and components For SW reuse the IEC61508 part 3 chapter the preconditions to be met are defined. According to part 3 pre-existing SW can be reused when the following requirements for systematic safety integrity are met: a) One of the following requirements are met: a. The pre-existing SW component has been developed compliant to this standard and the desired safety integrity level b. The pre-existing SW component can be considered as proven in use. c. If the development has been done non-compliant evidence has to be shown that the development process used can be seen as equivalent to that of this standard. Detailed description of this process can be found in chapter of IEC61508 part 3. b) Provide a safety manual that gives a sufficiently precise and complete description of the SW component to make possible an assessment of the integrity of a specific function that depends wholly or partly on the pre-existing SW component Qualification Depending on the context the term qualification is used, two cases can be distinguished: a) Qualification as the process of showing evidence that a pre-existing SW component may be reused in a safety-related system. This has been already described in chapter b) Qualification as the process of proper tool selection for tools for development support. Here again two cases can be distinguished: The SafeCer Consortium 26 (41)

27 a. Software on-line Tool. The standard defines a tool as on-line if the tool can directly influence safety during its run time. In case the tool has to be seen as SW element of the safety-related system and therefore tool development has to follow the same process as any SW component of a safety-related system. b. Software off-line Tool. The standard defines a tool as off-line tool if the tool cannot directly influence the safety-related system during its run time. For off-line tools three severity levels exists. The severity level is derived from the influence of the tools output to the safety-related system. Depending on the severity level the qualification effort increases. While for a T1 level tool almost no documentation and validation has to be provided, T3 requires providing proper product documentation, evidence that the tool conforms to its specification and validation Proven In Use Proven in use is detailed in the IEC The chapter part 3 Pre-existing SW addresses this topic. A SW component can be seen as proven in use if evidence can be provided that the previous conditions of use of the SW component are the same as those that will be experienced by the element in the E/E/PE safety-related system and the dangerous failure rate has not been exceeded in previous use. If there are differences between the previous conditions of use and those that will be experienced in the E/E/PE safety-related system, then an impact analysis has to prove the required safety integrity level of the safety functions that use the SW component is achieved (more detailed description can be found in chapter of IEC61508 part 2) Handling Product lines Companies more and more try to base product lines to reusable software components on the basis of a generic software platform. A software platform usually is a set of modules used for a certain product line. As the products in the product line may slightly differ, scalable software platforms give the companies the advantage of utilizing modularization and variability for adding or removing features from product variants. Reusability of software components and their certification evidence save a lot of certification costs as usually the integrity level does not differ within the product line. This usually justifies possible higher development costs for scalable software platforms. Support for product lines is not explicitly stated in the IEC Strategies for reuse Reuse within the scope of IEC follows the lines indicated in the previous chapters, i.e. focusing on a modular software design approach and the possibility to utilize software platforms. In order to plan strategies for reuse, it is therefore necessary to identify those sections of software that might be reused in the future and to set up the modularity of the software design in such a form that it supports the integration of components from different sources. These sources entail: - Standard and SIL-level compliant previously developed components - Proven-in-use components - Equivalency-compliant developed components In addition, the utilization of a safety manual that specifies the scope of the functional safety aspects of a software component (i.e. under which preconditions will the component behave safely) allows for the assessment of the integrity of each function. The SafeCer Consortium 27 (41)

28 4.3 Space Domain - ECSS-E-ST-40C and ECSS-Q-ST-80C Introduction Different existing software artifacts can be considered for reuse in each application engineering processes: requirements analysis, design, coding, integration, testing, installation, maintenance and operations. Therefore, there are specific activities that should be performed at a very early phase of the project in order to ensure that the most suitable existing software is considered for reuse in the current application. The suppliers should assess different options relevant to reuse and new development, evaluating them with respect to criteria such as risks, cost and benefits. These options include: a. Purchase an off-the-shelf, COTS software (no source code available) that satisfies the requirements b. Develop the software product or obtain the software service internally c. Develop the software product or obtain the external software service through contract d. Use open source software products that satisfies the requirements e. A combination of a, b, c and d above f. Enhance an existing software product or service Choosing between creating the software in-house or reusing existing software is not an easy decision. This choice should be made very early in the project, when often there is still no information about the full set of functionalities nor the design. Only when systematic reuse is an established policy in an organization, reusing existing software can be the starting approach in any project. The organization would have the reuse-related processes deployed (see [ISO12207]) and any project would first access the library of existing reusable products to check for any one that could fit into the project concerned. Nevertheless, no matter what the organizational situation is, a systems approach should be taken to consider how the existing software will fit into the new software application to be developed Handling of Safety Case and Evidence for reuse of Software The term safety case is not explicitly mentioned by the ECSS, however it can be considered as resulting from the conformance to the ECSS-Q-ST-80C product assurance and ECSS-Q-ST-40C safety standards. In particular the ECSS-Q-ST-40C refers to the safety data package (see Chapter 3.2.3) as the collection of all the information produced during the safety-related processes which each supplier participating in a safety review shall prepare, and submit for review. Regarding reuse, a single Software Reuse File (SRF) document is expected to cover ALL the reused existing software foreseen in the context of a software project, but it may be appropriate to produce specific SRFs targeted to individual existing software products when they are large, numerous or complex. The SRF should present the existing SW elements candidates and their suppliers, describing both technical and management information of the elements to be reused; a gap analysis should be included that covers the different development phases and more relevant characteristics (performance, code quality, size of code ). Finally a reasoned conclusion with a Reuse Qualification Plan is presented. It should be noted that documentation concerning reused or existing software is not simply limited to the SRF. There are software requirements that call for adequate planning concerning reused software to be present in the software development, software configuration management, software product assurance and software verification and validation plans. Furthermore, it is clear that The SafeCer Consortium 28 (41)