Safety Certification of Software-Intensive Systems with Reusable Components

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 07-05-2013 The SafeCer Consortium 1 (41)

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 E-mail petr.boehm@ait.ac.at thomas.gruber@ait.ac.at stefano.puri@intecs.it ricardo.morenoruano@thalesaleniaspace.com angel.alvaro@thalesaleniaspace.com arjan.geven@tttech.com aaristimuno@ulmaembedded.com The SafeCer Consortium 2 (41)

Revision chart and history log Version Date Reason 0.1 2012-12-20 AIT: TOC first draft 0.2 2013-01-15 AIT: Update after first telco 0.3 2013-01-21 AIT: Update after second telco, Chapter 3.1 and 5 updated INTECS/TAS-E: Contribution to Chapter 3.2.3 and 4.3 0.4 2013-03-12 AIT: Chapters 1, 2 and 8. AIT:Updates after thirst telco 0.5 2013-03-15 2013-03-28 TTTECH: First contribution to Chapters 3.2.3 and 4.3 First Ideas to Chapter 5 AIT: Merge the contributions from ULMA and INTECS Small text corrections. 0.6 2013-04-10 TTTECH: Conclusions ULMA: Chapter 3.1.1 AIT: Chapters 5 and 6 Merge the contributions 0.7 2013-04-17 Last updates Finalizing of the document before the review 1.0 2013-05-07 Finalizing the document after reviews The SafeCer Consortium 3 (41)

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)

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... 8 1 Introduction... 9 1.1 Scope of this document... 9 1.2 Structure of this document... 9 2 Input from previous psafecer work... 10 3 Standards in Other Domains... 11 3.1 Overview of the Standards for Other Domains... 11 3.1.1 IEC 62304 and IEC 60601 (Healthcare Domain)... 11 3.1.2 IEC 61508, IEC 61511, IEC 61131-6 (Industry Domain)... 11 3.1.3 ECSS-E-ST-40C and ECSS-Q-ST-80C (Space Domain)... 12 3.2 Comparison of the Other Domain Standards with IEC 61508... 14 3.2.1 Commonalities and differences for the Healthcare Domain... 14 3.2.2 Commonalities and differences for the Industry Domain... 17 3.2.3 Commonalities and differences for the Space Domain... 17 4 Reuse of Components in Other Domains... 22 4.1 Healthcare Domain - IEC 62304 and IEC 60601... 23 4.1.1 Introduction... 23 4.1.2 Handling of Safety Case and Evidence for reuse of Software... 23 4.1.3 Reuse of Safety related subsystems and components... 24 4.1.4 Qualifications... 25 4.1.5 Proven In Use... 25 4.1.6 Handling Product lines... 25 4.2 Industry Domain - IEC 61508, IEC 61511, IEC 61131-6... 26 4.2.1 Introduction... 26 4.2.2 Handling of Safety Case and Evidence for reuse of Software... 26 4.2.3 Reuse of Safety related subsystems and components... 26 4.2.4 Qualification... 26 4.2.5 Proven In Use... 27 4.2.6 Handling Product lines... 27 The SafeCer Consortium 5 (41)

4.2.7 Strategies for reuse... 27 4.3 Space Domain - ECSS-E-ST-40C and ECSS-Q-ST-80C... 28 4.3.1 Introduction... 28 4.3.2 Handling of Safety Case and Evidence for reuse of Software... 28 4.3.3 Reuse of Safety related subsystems and components... 29 4.3.4 Qualification... 30 4.3.5 Proven In Use... 31 4.3.6 Handling Product lines... 32 4.3.7 Strategies for reuse... 32 5 Results... 34 5.1 Results for the Healthcare Sector... 34 5.2 Results for the Industrial Sector... 35 5.3 Results for the Space Sector... 36 5.4 Outline for an Open, Extendable and Adaptable Framework for Component Reuse 37 6 Contribution to overall psafecer objectives... 38 7 Conclusions... 39 8 References... 41 The SafeCer Consortium 6 (41)

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

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

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 62304 and IEC 60601 Industry Domain - IEC 61508, IEC 61511 and IEC 61131-6 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 61508 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)

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.4.1.2 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)

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 61508 are given. 3.1 Overview of the Standards for Other Domains 3.1.1 IEC 62304 and IEC 60601 (Healthcare Domain) IEC60601-1, 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. IEC60601-1 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 IEC60601-1-1, -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 IEC60601-2-XX where XX identifies the particular standard number for the particular type of medical equipment. An example would be IEC60601-2-2 is the particular standard for High Frequency Surgical Devices IEC60601-1 refers to IEC 62304. The IEC 62304 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. 3.1.2 IEC 61508, IEC 61511, IEC 61131-6 (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 61508 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)

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 7.4.2.12 and 7.4.6.1 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 7.4.2.13 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. 3.1.3 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)

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)

3.2 Comparison of the Other Domain Standards with IEC 61508 In this Chapter a comparison of the Standards for Healthcare, Industry and Space domain with the Standard IEC 61508 will be described. 3.2.1 Commonalities and differences for the Healthcare Domain In the healthcare domain, the reference standard for software is IEC 62304. 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 13485 and ISO 14971 provide a management environment that lays a foundation for an organization to develop products. Standards such as IEC 60601-1 and IEC 61010-1 give specific direction for creating safe medical devices. When software is a part of these medical device, IEC 62304 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 61508-3 and ISO/IEC 90003 can be looked at as a source of methods, tools and techniques that can be used to implement the requirements in IEC 62304. Figure 1 shows the relationship of these standards. Figure 1: Relationship of key medical device standards to IEC 62304 extracted extracted from [2] - Annex C. The SafeCer Consortium 14 (41)

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 61508. The following explains the stance of this standard. IEC 61508 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 14971 (the MEDICAL DEVICE sector standard for RISK MANAGEMENT). The effect of this reference is to adopt ISO 14971 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 61508. 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 61508 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 14971. In summary, even if both IEC 61508 and IEC 62304 describe lifecycle related activities, IEC 61508 is more prescriptive than IEC 62304 specially in the measures/techniques to be applied in each stage. Software classification follows a different approach on IEC 61508 and IEC 62304. 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. 3.2.1.1 High Level Process In medical domain, V-cycle is a reference but manufacturers can choose their own. IEC 62304 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 61508 and IEC 62304 are similar.iec 62304 requires a connection to a risk management process described in ISO 14971. In this sense, risk management plays the main role in the development in the same way as safety does for IEC 61508. The SafeCer Consortium 15 (41)

3.2.1.2 Integrated Safety or "External" Safety Systems The Risk Control Measures are defined in ISO 14971 (Medical devices Application of risk management to medical devices). ISO 14971 does not specify which architecture should be used, whether internal or external. Anyway, IEC 62304 implicitly assumes an integrated approach. 3.2.1.3 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 62304 aim to mitigate software related risks with an objective-oriented approach. 3.2.1.4 Severity and Assurance/Safety Integrity Levels As mentioned in the beginning of this chapter, the classification that IEC 62304 standard makes is different from IEC 61508. 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 62304 mentions IEC 61508 as a reference but it doesn t mandate you follow a particular approach to avoid systematic faults. 3.2.1.5 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-61508 62304/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)

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. 3.2.1.6 Comparison and Consolidation of Functional Safety Standards: Current Initiatives Nothing to add. This section is kept to ease comparison with other domains. 3.2.1.7 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. 3.2.1.8 Conclusions Although at a high level of comparison, IEC 62304 and IEC 61508 have a similar lifecycle based approach, IEC 62304 can not be grouped together with standards derived from IEC 61508 or with the avionics domain as software classification in IEC 62304 and Safety Integrity Levels in IEC 61508 not only have different definitions but also the implications in the development are handled differently. IEC 62304 isn t an standalone standard and must be applied in close collaboration with ISO 14971 and ISO 60601 not to mention collateral standards specific to each device type. Nevertheless, IEC 61508 provides a more demanding framework for safety software development and it could be argued that it can cover IEC 62304 requirements. 3.2.2 Commonalities and differences for the Industry Domain The IEC 61508 is already heavily referred to in D2.1.4/4.1.2 Chapter 3. Therefore, no additional commonalities or differences can be identified. 3.2.3 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)

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. 3.2.3.1 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)

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 12207 the ECSS-E-ST-40 provides a process model for the SW development activities, without prescribing a particular software life cycle. 3.2.3.2 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. 3.2.3.3 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 12207. 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. 3.2.3.4 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)

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) 3.2.3.5 The Common Notion of Safety in the Considered Standards No differences here to be outlined. 3.2.3.6 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-61508 to the corresponding parameters of the ECSS, and so highlighting the different origins of these two standards. The SafeCer Consortium 20 (41)

Parameter according to IEC-61508 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. 3.2.3.7 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. 3.2.3.8 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. 3.2.3.9 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)

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)

4.1 Healthcare Domain - IEC 62304 and IEC 60601 4.1.1 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 26262 Safety Element out of Context definition. In the following chapters the reuse approaches are described according to the component type. 4.1.2 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 14971 is the standard for application of risk management to medical devices, and the technical report IEC/TR 80002-1 guides on the application of ISO 14971 to medical device software. The standard doesn t mention the reuse of components, but according to technical report IEC/TR 80002-1 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)

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. 4.1.3 Reuse of Safety related subsystems and components As mentioned in Chapter 4.1.2, different measures should be taken when reusing components. 4.1.3.1 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)

4.1.3.2 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. 4.1.4 Qualifications IEC 62304 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. 4.1.5 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. 4.1.6 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)

4.2 Industry Domain - IEC 61508, IEC 61511, IEC 61131-6 4.2.1 Introduction Chapter 7.4.2.12 of Part 3 of the IEC 61508 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. 4.2.2 Handling of Safety Case and Evidence for reuse of Software The term Safety Case does not exist in the IEC61508. 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. 4.2.3 Reuse of Safety related subsystems and components For SW reuse the IEC61508 part 3 chapter 7.4.2.12 the preconditions to be met are defined. According to 7.4.2.12 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 7.4.2.13 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. 4.2.4 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 4.2.3. 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)

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. 4.2.5 Proven In Use Proven in use is detailed in the IEC 61508. The chapter 7.4.2.12 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 7.4.10 of IEC61508 part 2). 4.2.6 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 61508. 4.2.7 Strategies for reuse Reuse within the scope of IEC 61508 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)

4.3 Space Domain - ECSS-E-ST-40C and ECSS-Q-ST-80C 4.3.1 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. 4.3.2 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)

reused software considerations should be properly covered (if needed) in a wider set of documents (e.g. Software Design Document, IR, and Software Problem Report). Reporting on activities concerning existing software is also expected in the Software Product Assurance Milestone Report and software progress reports. Lastly, software supplier should comply also with all software requirements relating with configuration management and control of reused software and tools. The use and modification of existing software can involve a new development environment, a new target processor or other hardware, or integration with other software than what is used for the original application. Guidance for change of application or development environment includes: The rigor of the evaluation of an application change should particularly consider the complexity and sophistication of the programming language. For example, the rigor of the evaluation for Ada language generics is greater if the generic parameters are different in the new application. If a different compiler or different set of compiler options are used resulting in different object code, the results from a previous software verification process activity using the object code may not be valid and should not be used for the new application. In this case, previous test results may no longer be valid for the structural coverage criteria of the new application. Similarly, compiler assumptions about optimization may not be valid. If a different processor is used then: 1. The results from a previous software verification process activity directed at the hardware/software interface should not be used for the new application. 2. The previous hardware/software integration tests should be executed for the new application. 3. Reviews of hardware/software compatibility should be repeated. 4. Additional hardware/software integration tests and reviews can be required. Verification of software interfaces should be conducted where existing software is used with different interfacing software. ECSS-Q-HB-80-01A, the handbook about reuse, states that a qualification phase should be performed for each reused existing software; the qualification is performed along with the existing software integration and concerns the qualification of the existing software in the frame of the current project. This aims at subjecting all reused existing software to exactly the same verification & validation requirements as the new software of the same criticality is subjected to; when this is not feasible (for instance for available COTS product) a certification data package may be required. 4.3.3 Reuse of Safety related subsystems and components As in Avionics domain, there is no such a concept as Safety Element out of Context. For instance the ECSS E ST 40 contains a set of requirements about the SRF content: in particular it is stated that the SRF must contain a presentation of the software intended to be reused, but no reference to safety related aspects or qualification properties are addressed by the standards. Concerning reuse, ECSS E ST 40 requires the evaluation of the reuse potential of the software to be performed through the identification of the reuse components with respect to the functional requirements baseline. Moreover ECSS E ST 40 requires a quality evaluation of these intended to be reused components by applying ECSS-Q-ST-80 requirements concerning reuse of existing software; as introduced in Chapter 4.3.1, a set of these requirements relevant to SafeCer are the following: The SafeCer Consortium 29 (41)

The existing software shall be assessed with regards to the applicable functional, performance and quality requirements. The quality level of the existing software shall be analyzed with respect to the project requirements, according to the criticality of the system function implemented The results of the reused software analysis shall be recorded in the Software Reuse File (SRF), together with an assessment of the possible level of reuse and a description of the assumptions and the methods applied when estimating the level of reuse. Corrective actions shall be identified, documented in the reuse file and applied to the reused software not meeting the applicable requirements related to the aspects as specified in clauses It can be summarized that, when requirements match in two different projects, certification documentation can be re-used to prove certification of SW components. 4.3.4 Qualification 4.3.4.1 Software qualification SW component qualification can be achieved by either following full lifecycle processes according to ECSS-E-ST-40C and ECSS-Q-ST-80C (development from scratch), or by selecting and reusing an existing SW component. Regarding safety-critical functions ECSS-Q-ST-40 states that: the safety-critical characteristics of all safety-critical functions shall be qualified by test. Safety-critical function qualification testing shall include the determination of performance margins considering worst case combinations of induced and natural environments and operating conditions. Qualification by similarity shall not be applied except after customer approval on a caseby-case basis When reusing an existing SW component the qualification is performed along with the existing software integration and concerns the qualification of the existing software in the frame of the current project. 4.3.4.2 Tool qualification Qualification of a tool is needed when processes or activities of the project requirements and standards are eliminated, reduced or automated by the use of a software tool without its output being verified. The objectives of the tool qualification process is to ensure that the tool provides confidence at least equivalent to that of the process(es) eliminated, reduced or automated. Different Tool Qualification Levels (TQL) are defined following the logic presented in Figure 3 (taken from ECSS-Q-HB-80-01A and heavily based on DO178 standard): The SafeCer Consortium 30 (41)

Figure 4: Tool qualification activities 4.3.5 Proven In Use The ECSS-Q_ST-80C refers to the usage of product service history for software products whose life cycle data from previous development are not available and reverse engineering techniques are not fully applicable. Product Service History is the utilization of the information about previous in-service experience of the component that is relevant to the new intended application and that can constitute evidence of product dependability. In addition, more credit is given if the product was used in an application with the same or a higher criticality software level. In particular product service history has to be used to provide evidence of the product s suitability for the current application, for instance regarding actual error rates like mean time between failures. Product service history is beneficial for the gain in confidence on the reused software dependability. However, its benefit for safety aspects is not ensured since system safety should be demonstrated for each system at system level, and cannot be demonstrated by any of its subsystems in isolation. The following attributes should be evaluated in determining the credit that can or cannot be granted for service history: Service duration length; Change control during service; Proposed use versus service use; Proposed environment to service environment; The SafeCer Consortium 31 (41)

Number of significant modifications during service; Number of software modifications during service; Number of hardware modifications during service; Error detection capability; Error reporting capability; Number of in-service errors; Number of services outages; Flawless service duration length; Service outage length; Amount and quality of service history data available and reviewed 4.3.6 Handling Product lines In Space Systems, Software Product Lines are emerging as part of this innovation frame: they are based on increasing reuse of software and on new approaches supporting the conception and design of new software for its intended reuse. This makes the space software community more close to other software intensive industrial sectors (like automation, telecommunications, and defence systems) and allows sharing experiences relevant to business reengineering. SAVOIR (Space Avionics Open Interface architecture) is an initiative to federate the space avionics community and to work together in order to improve the way that the European Space community builds avionics subsystems. SAVOIR is based on the definition of an avionics reference architecture (1) allowing defining building blocks (2) suitable for a domain of reuse. For selected building blocks, generic functional specification is produced, that includes the necessary variability to cover the domain of reuse (3). Industry develops and reuses the building blocks. The process is measured (4) and restarted in order to refine the architecture or the generic specification according to the building block success. The expected benefits / goals of Savoir are: - for customers, streamline the procurement process of spacecraft avionics, - for system integrators, facilitate the integration of the spacecraft avionics, - for suppliers, prepare the technical conditions for a more efficient product line organization. 4.3.7 Strategies for reuse Usually, the reuse verification and validation processes identify verification and validation objectives that cannot be met using traditional means. The ECSS handbook for the reuse of existing software provides few different methods and techniques that can be used to document and support the qualification process of a project reusing existing software. They are grouped as follows: Verification techniques SW design techniques HW architectural techniques The SafeCer Consortium 32 (41)

Reverse engineering Product service history Development process examination The SafeCer Consortium 33 (41)

5 Results In the following three sections, the results for the healthcare, industrial and space domains are summarized. Finally, the last section tries to draw general conclusions and depicts an Outline for an Open, Extendable and Adaptable Framework for Component Reuse. 5.1 Results for the Healthcare Sector For the healthcare sector, several specific norms apply; they were compared to IEC 61508 with respect to several aspects of their requirements. Risk management and the safety life cycle are covered by ISO 14971, quality management aspects are added by ISO 13485. Regarding the high level process, the healthcare sector standards are widely similar to IEC 61508 despite of some differences in hazard assessment terminology, which can be overcome by a mapping, which is, however, not bijective (The IEC 61508 parameter Frequency of, and exposure time of hazardous situation is not covered by the healthcare standards). The process standard IEC 62304 was also analyzed and compared to IEC 61508. A general observation is that IEC 62304 is primarily objectives-based, whereas IEC 61508 is mainly meansprescriptive - this difference is also comparable with the relation between the avionics standards and the generic IEC norm. When it comes to details, many more differences show up and a mapping to IEC 61508 is not any more possible. Regarding recommendation of techniques, tools and methods for software development, the standard refers to IEC 61508 anyway. IEC/TR 80002-1 guides on the application of ISO 14971 for medical device software. The standard doesn t mention the reuse of components, but according to technical report IEC/TR 80002-1 a reused component should be treated as SOUP (software of unknown provenience). This implies specific steps including Software development, maintenance, risk management, and configuration management processes. The concept of proven-in-use components (cf. IEC 61508) is not treated in the healthcare standards. Several more healthcare specific standards give additional guidance on how to construct safe medical devices like in particular the medical product standards 61010-1 and IEC 60601. The latter is split into many sub-standards addressing individual types of medical electrical devices. Their specific requirements have no 1:1 correspondence to the generic IEC standard and must be added to the generic process model in the process of instantiation. The conclusion from the standards comparison which yielded mainly dissimilarities is that, for the medical sector, not much of a generic certification process model remains and most of the specific model has to be added by instantiation. With regards to software component reuse, the assumptions for SOUP apply, which implies fully integrating the reused components by implementing conformant requirements management, software development (including software classification, detailed design, V&V, integration testing), maintenance, risk management, and configuration management processes. Summarizing we can state that, except for the high-level lifecycle model, the healthcare domain exposes a high degree of dissimilarity with the generic IEC 61508-compliant process model; in addition, many device specific standards impose product specific requirements. Software components to be reused are treated as SOUP; as a consequence, the concept of contract based composition of components is not integrated in the Health domain standards. The SafeCer Consortium 34 (41)

5.2 Results for the Industrial Sector Chapter 3.1.2 Commonalities and differences for the Industry Domain refers to the detailed elaboration about IEC 61508 in in D2.1.4/4.1.2 Chapter 3 and points out that no additional differences could be identified. Reuse of pre-existing software is allowed for three cases: for software previously developed in compliance with IEC 61508, for proven-in-use software, and for non-compliant software, for which evidence shows that the development process can be seen as equivalent to IEC 61508. There are, moreover, several other standards relevant in particular to PLC (programmable logic controllers) based industrial process control systems, which are mentioned in Chapter 3.2.2: IEC 61511 Functional safety: Safety instrumented systems for the process industry sector IEC 61131-6 Programmable controllers: Functional Safety. IEC 61511 details the generic IEC 61508 requirements for PLC controlled process industry systems and enables a simplified and therefore cost-saving approach for PLC based applications up to SIL3, relying on a standardized, mostly proven-in-use hardware of known reliability and defined behavior in case of faults, with a standardized pre-validated system software, and with application logic programmes formulated in a fixed or limited variability language. IEC61131-6 follows the concept of IEC 61508 and covers for PLC systems - the product specific requirements stated in IEC 61508-1, 61508-2, and 61508-3 including mechanical, climatic and EMC requirements. The standard equally fits to the concepts of IEC 61511. In the sense of instantiations, IEC 61511 together with IEC 61131-6 represent a subclass of the generic standard IEC 61508. The pre-validated PLC (hardware and operating system) with known reliability or PFD and known maximum SIL represent a component to which the application logic program as a software component - interfaces. Under the condition of using a low or limited variability language, the application software is subject to lower requirements wrt. verification and validation than stated in IEC 61508. The consequences for the process model are that the concept of pre-validated, standard-compliant components applies, and that based on the assumption of using a fixed or limited variability language - some verification and validation steps in the detailed process model are conducted in a specific (effort-saving) manner. The general conclusion is that both consequences fit into the generic process model of IEC 61508. The process of instantiation is therefore limited to merely a specific interpretation of the requirements of IEC 61508. For the component model, however, the PLC specific concepts imply additional properties in the component interface. This question is analyzed in more detail in D131.1 Specification of the requirements on the generic component model (second release). Recapitulating the above mentioned results, the standards applicable to the industrial control domain are compliant with IEC 61508. The process model fits, instantiation refers here to the selection of specific variants of the prescribed certification steps. IEC 61508 includes appropriate component concepts; for the particular case of PLC based control applications, compliance with IEC 61511 and IEC 61131 implies some additional specific properties at the component interface. The SafeCer Consortium 35 (41)

5.3 Results for the Space Sector The main applicable standards are ECSS-E-ST-40 for space software engineering, ECSS-Q-ST-80 for the Software Product Assurance requirements, ECSS-Q-30 (Derating EEE components), and ECSS-Q-HB-80-01A (ECSS handbook Space product assurance, Reuse of existing software ). ECSS is both a process-based and product- based framework, with emphasis on processorientation as it is derived from ISO/IEC 12207. A fundamental principle of the ECSS standards and distinctive difference compared to the other standards is the explicit customer-supplier relationship. Moreover, ECSS has the peculiarity of allowing tailoring on project-basis: It is specified by contract which parts of the ECSS must be applied for the specific mission. 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 (comparable to Consequence of hazard in IEC 61508). The other hazard analysis parameters of IEC 61508 (Frequency of, and exposure time of hazardous situation; Possibility of avoiding hazard; Probability of the unwanted occurrence) are not considered for the ECSS criticality classification. Space systems have to be evaluated wrt. safety and dependability assigning a criticality level (from A to D) to each of its components or subsystems, including software. Safety is only concerned with the two highest levels of the severity scale, whereas dependability spans across the three lowest severity categories. The hazards that are not eliminated through design selection shall be reduced and made controllable through the use of automatic safety devices in which SW shall be avoided. ECSS-Q-ST-80C does not impose constraints on the means for safety assurance; it only requires the definition of a specific software safety assurance plan. According to the approach of ISO/IEC 12207, the ECSS-E-ST-40 provides a process model for the SW development activities, without prescribing a particular software life cycle. Methods, techniques and tools are covered by ECSS Handbooks, which are not normative but can be incorporated on a project basis. As for software reuse, ECSS-E-ST-40 makes reference to the Software Reuse File (SRF), which documents the identification and analysis to be performed on existing software intended to be reused; the ECSS handbook (in particular ECSS-Q-HB-80-01A Space product assurance, Reuse of existing software ) provides guidance. It applies to previously developed software, software from outside ESA contracts, and freeware as well as open source software. Summarizing, the space domain is governed by ECSS product assurance standards and handbooks. There is no overall safety lifecycle model, and the actual product assurance steps are agreed individually for each mission on a by contract basis. Reuse of software is encouraged and guided by a specific space product assurance handbook. The process described therein, however, cannot be simply mapped to the generic IEC standard. The SafeCer Consortium 36 (41)

5.4 Outline for an Open, Extendable and Adaptable Framework for Component Reuse In order to extend and generalize the results of the psafecer project (with focus on automotive, aerospace and railway domains), this document shows that it is possible to adapt the existing results and transfer them to the domains of healthcare, industry and space. The procedure ( cookbook ) for instantiation of SafeCer results to these new domains has been the same and can be presented in a generalized way, relating to the steps described in this document as well as in the combined deliverable D2.1.4/D4.1.2, and particularly chapter 3 of that document. The procedure applied is the following: 1) Analyze the domain-independent aspects identified in D2.1.4/D4.1.2 and compare this to the applicable standard(s) for the new domain at hand 2) Analyze those domain-specific aspects related to: a. Handling of Safety Case b. Reuse of Safety-related subsystems and components c. Qualification d. Proven in Use e. Product Lines f. Strategies for re-use After these two analysis steps, the next phase deals with the domain-specific adaptation of SafeCer-specific components, i.e. the Generic Process Model, the Component Model, and the tool framework. 3) Extend the SafeCer core Generic Process Model (GPM) to include the necessary new relations (extends/replaces/contributes) formed by the domain-specific aspects identified Guidance is found in D4.1.2 where the GPM instantiation process is described in detail. 4) Instantiate the component model language to the modeling language of choice, requiring a mapping to the language constructs used in the specific modeling language. Guidance can be found in D.4.1.3 where the CM instantiation process is defined 5) Set the proper SafeCer tool platform environment, in particular by allowing the CAR (see D3.1.5) to be instructed with respect to the information available in the extended process model, and so to guarantee a better tool support for the domain specific certification process. The SafeCer Consortium 37 (41)

6 Contribution to overall psafecer objectives This deliverable builds on the combined deliverable psafecer D2.1.4/4.1.2 Guidelines with respect to different standards / Modeling and methodology for reusing software in automotive, construction equipment, avionics and railway domains [9] and extends its scope with respect to reuse to new domains, which are now represented by new nsafecer partners, or to domains which were investigated based on standards. The main idea of SafeCer is to increase efficiency and reuse in development and certification of safety-relevant embedded systems by providing process and technology that enable composable qualification and certification, i.e. qualification/certification of systems/subsystems based on reuse of already established arguments for and properties of their parts. This idea was formulated as three priorities in the psafecer project proposal: 1. Reduction in development lifecycle costs for systems requiring qualification and certification 2. Reduced effort and time required for re-validation and recertification of systems 3. Cross sector reusability of embedded systems devices and interoperable components Like D2.1.4/4.1.2, this deliverable addresses all three of these priorities; in particular, however, it emphasizes the third one. Continuing the above mentioned predecessor deliverable, this document treats the healthcare, industry and space segments; it aims at reducing overhead in the development lifecycle for these domains and is in this sense fully in line with Priority #1. Priority #2 is addressed just as well in that the work in this deliverable treats the way how to integrate tools and methods in order to obtain a high degree of component re-use. As a result, verification and validation costs are decreased significantly. Last but not least, Priority #3 is in the focus of this deliverable. The document analyses the applicable functional safety standards of three new domains; it points out specific practices in respect to safety-case aspects, application re-use, qualification, proven in use arguments, and product lines. This enables a high degree of cross-domain reuse. Summarizing, we may state that this deliverable is fully in line with the SafeCer objectives and addresses all three priorities as defined in the project s Technical Annex [1]. The SafeCer Consortium 38 (41)

7 Conclusions The definition of a common, multi-domain psafecer methodological approach for composable safety certification has been proposed in the context of the psafecer deliverables D2.1.1 and D2.1.4/D4.1.2 focusing on the domain-specific specialties that need to be taken into account when applying this approach in one of the domains of automotive, construction equipment, aerospace or railway. This document, D4.4.1, has extended the previous efforts to include new domains and their safety standards (healthcare, space, and industrial domains). These domains are related (as they all refer to safety in a similar way) but also have distinct properties that need to be taken into account. Whereas domain-invariants between the three initial domains have been defined in D2.1.4/D4.1.2, it was not necessarily the case that these stay invariant when additional domains are added. As such, the commonalities are only valid with respect to the analyzed domains. In other words, the value of the defined commonalities is not absolute, but relative to the subset of domains covered in SafeCer. This is also indicated in the analysis of the healthcare and space domains, where smaller and larger deviances occur from the standards analyzed so far. Healthcare Domain: The main difference of this domain is the definition of the safety class for each component, which differs from other classifications described in this document. Other features differ from IEC61508 but they can find a common ground with other domains. Industrial Domain: No further differences from the common base were found, as (1) the main industrial safety standard, IEC 61508, is already covered in the original analysis of commonalities and differences, and (2) the requirements of IEC 61511 and IEC 61131-6 are a specific subclass of those in IEC 61508; Space Domain: The space domain is covered by a process-driven standard not unlike the avionics standard, with the difference that the customer/supplier relations are covered in the area of space. Since the process is procedural rather than product-driven, many of the aspects covered in i.e. IEC61508 are covered only indirectly or in associated handbooks as best practices. In the second part of the document the focus is on domain-specific aspects related to softwarereuse, i.e. the differences from the common base, and how this can be dealt with in respect of each individual domain (healthcare, industrial, space). The focus is here not specifically on component-based model-driven development, but rather addresses the multitude of re-use possibilities that are allowed under various lifecycle approaches and software components in their various characteristics. Finally, based on the analysis of the in total seven domains covered by the two deliverables, an approach is deducted that highlights the instantiation process that would need to be applied for the transfer of the project results to other domains. Therefore, the cookbook approach described in Chapter 5 gives a short but practical overview of the procedure required for this instantiation. Depending on the amount of variability, this might take more or less work. Since the common base is relative and not absolute, it is unfortunately not possible to describe a one-fits-all solution that generically applies to any future other domain. Based on the analysis of the domains so far, a mapping of standards can be undertaken based on the specificity of the respective standard and whether the standard is goal-oriented or meansprescriptive. This mapping is shown in Figure 4, indicating several families of standards which are similar. The larger the (vertical) distance between the standards, the more differences are found and the more extensive the instantiation process will be. The SafeCer Consortium 39 (41)

Figure 5: Mapping of standards from different domains Since many domains have already been covered, it is unlikely (although not impossible) that the commonalities and differences in such new domain and associate standards are completely tangential to the currently defined aspects. Therefore, there is good hope that this is doable in a finite amount of time. The SafeCer Consortium 40 (41)

8 References [1] psafecer, nsafecer Technical Annex, Version 2.2, 2012. [2] IEC 62304 Medical device software Software life cycle processes [3] IEC 60601 Medical Electrical Equipment [4] IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems [5] IEC 61511 Functional safety Safety instrumented systems for the process industry sector [6] IEC 61131-6 Programmable Logic Controllers - Functional safety [7] ECSS-E-ST-40C Space engineering - Software [8] ECSS-Q-ST-80C Space product assurance - Software product assurance [9] psafecer Deliverable D42.1.4/D4.1.2 Guidelines with respect to different standards. Modeling and methodology for reusing software in automotive, construction equipment, avionics and railway domains [10] psafecer Deliverable D2.1.1 A Generic Process Model for Integrated Certification and Development of Component-based Systems The SafeCer Consortium 41 (41)