Constraints of the certification process D1.1

Transcription

1 Collaborative Large-scale Integrating Project Open Platform for EvolutioNary Certification Of Safety-critical Systems Constraints of the certification process D1.1 Work Package: WP1: Use case Specification and Benchmark Dissemination level: PU = Public Status: FINAL Date: 28 March 2012 Responsible partner: F. Tagliabò (CRF) Contact information: fulvio.tagliabo@crf.it PROPRIETARY RIGHTS STATEMENT This document contains information, which is proprietary to the OPENCOSS Consortium. Neither this document nor the information contained herein shall be used, duplicated or communicated by any means to any third party, in whole or in parts, except with prior written consent of the OPENCOSS consortium.

2 Names Laurent Pitot de la Beaujardière, Fabien Belmonte Vincenzo Manni, Giorgio Tagliaferri Jérôme Lambourg, Cyrille Comar Martijn Klabbers Mireille Larnac Fulvio Tagliabò, Alberto Melzi Guy-André Berthon, Cédric Chevrel Contributors Organisation ALSTOM Transport RINA Services SpA AdaCore Eindhoven University of Technology Inspearit (before DNV ITGS) Centro Ricerche Fiat S.C.p.A. THALES Avionics Document History Version Date Remarks V First draft version V Revision on Section 4 from Mireille Larnac (Inspearit) V Additions & revisions on Section 4 from Guy-A. Berthon (THALES Avionics) V Additions & revisions on Sections 6 and 7 (CRF) V Additions & revisions on Sections 5.7 and 6.1 (RINA) V Review (Eric Verhulst, ALT) V0.7a Review (Martijn Klabbers, TU/e) V0.7b Review (Michel Ilkiewicz, Inspearit) V Review (Mike Brownsword ATU) V0.9a Preparation for PB Approval (CRF, THALES Avionics and ALSTOM Transport, with the contribution of additional Annex D1.1.d from AdaCore ) V0.9b Updated after PB Review V Approved by PB

3 TABLE OF CONTENTS 1 EXECUTIVE SUMMARY INTRODUCTION RELATIONSHIPS WITH THE OTHER WPS AND TASKS AUTOMOTIVE DOMAIN REFERENCE STANDARD CERTIFICATION FRAMEWORK Safety management capability and planning Work Products Confirmation measures Processes and Audits Legal point of view Output from Certification framework CRITERIA AND GENERIC ELEMENT FOR COMPOSABILITY OF CERTIFICATION (SEOOC) AVIONICS DOMAIN REGULATORY FRAMEWORK Certification Standards Industry Standards Other Standards DEVELOPMENT ASSURANCE Design Assurance Safety Assurance Process Assurance AUTHORITIES INVOLVEMENT Level of Involvement (LOI) Stages of Involvement (SOI) Domains of involvement CERTIFICATION PROCESS CERTIFICATION ORGANIZATION CERTIFICATION DATA PACKAGE RAILWAY DOMAIN REFERENCE STANDARD CERTIFICATION FRAMEWORK SAFETY CASE Structure of the overall case for safety Contents of the Safety Case SYSTEM/SUBSYSTEM/EQUIPMENT LIFECYCLE CONSTRAINTS ON INDEPENDENCE SAFETY RELATED APPLICATION CONDITIONS INDEPENDENT SAFETY ASSESSMENT Safety Assessment Process Overview Safety Assessment Process in Practice ANALYSIS OF THE COMMONALITIES ACROSS DOMAINS COMMON PART AMONG DIFFERENT DOMAINS AVIONICS versus AUTOMOTIVE RAILWAY versus AUTOMOTIVE AVIONICS versus RAILWAY COMMONALITIES ANALYSIS FP7 project # Page 3 of 73

4 6.2.1 From management to concept From design to the integration Testing/validation Final assessment and release for production Production/Service (Assistance, Repair)/Decommissioning Main supporting processes METHODOLOGIES USED IN CERTIFICATION Agile methods CONCLUSION ABBREVIATIONS AND DEFINITIONS REFERENCES ANNEXES FP7 project # Page 4 of 73

5 List of Figures Figure 2.1. General structure of the Certification Framework... 9 Figure 2.2. Lifecycle of a requirement... 9 Figure 2.3. Classification of needs... 9 Figure 3.1. ISO Safety lifecycle Figure 3.2. Confirmation measures overview (from ISO 26262) Figure 4.1. Certification Basis at various levels of Aircraft, System and Equipment Figure 4.2. Industry standards structure for development and safety assurance of avionics Figure 4.3. Safety Assurance process for avionics systems Figure 4.4. Overall certification process for avionics systems Figure 4.5. Typical organization for certification at avionics manufacturer facilities Figure 5.1. EN Safety lifecycle Figure 5.2 Example of a possible hierarchy of Safety Cases Figure 5.3. Provisions for independence Figure 5.4. Process for handling Safety Related Application Conditions Figure 5.5. Independent Safety Assessment Process Overview FP7 project # Page 5 of 73

6 List of Tables Table 2.1. Example of proposed requirement classification Table 4.1. Main Certification Specifications and Implementing Rules used for avionics Table 4.2. Level Of Involvement (LOI) of Authorities in Avionics Table 4.3. Avionics Data Package categories of submittals to Authorities Table 4.4. Example of data list for Avionics Hardware Table 4.5. Example of data list for Avionics Software Table 4.6. Example of data list for Avionics System Table 4.7. Example of data list for IMA System Table 5.1. Safety Tasks for each phase defined in EN Table 5.2. Typical deliverables for development lifecycle defined in EN FP7 project # Page 6 of 73

7 1 Executive Summary The OPENCOSS project aims at having a substantial impact on the safety critical systems community, reducing costs and time for certification and promoting migration of certified subsystems across multiple application domains (e.g. Avionics, Railway, Automotive), following the fast evolution of the technologies and their related implementation. This document is the starting deliverable of WP1 and provides inputs and basis to the following WPs, contributing with WP2 to the inputs for the definition of the overall project architecture and of the basic approach to a general requirements framework among the various domains (Automotive, Avionics, Railway), from which derive the guidelines for the design of the common certification platform and its integration and validation. The aim of the document, in particular, is to identify in the certification processes from the different domains the constraints and requirements that are to be considered by the project as target for the development of the general framework supporting the design of the common certification platform. The applicable legislative background, the standards and the best practices used by the stakeholders, in order to deliver products to a customer, have been considered. The voluntary and regulatory actions have been also taken into account in the developing process of a certified product in each domain. In the following, the introductory Chapter 2 explains the objectives of the task and summarizes the structure used to classify the requirements that have been collected for each domain in the annexes D1.1.a (Automotive), D1.1.b (Avionics) and D1.1.c (Railway). The annex D1.1.d reports an example of requirements from a methodological point of view considering the Agile Methodology. Then, the Chapters from 3 to 5, one for each domain, describe the processes of conformity/certification assessment used, according to the specific requirements related to the respective domain reference standards. Finally, Chapter 6 resumes the comparisons between the considered domains and outlines a general workflow with the main common steps of the conformity/certification process. The conclusion is reported in the Chapter 7 and Chapter 8 contains the referenced documents. FP7 project # Page 7 of 73

8 2 Introduction Safety assurance and certification are amongst the most expensive and time-consuming tasks in the development of safety-critical embedded systems. European innovation and productivity in this market is curtailed by the lack of affordable (re)certification approaches. Major problems arise when evolutions to a system entail reconstruction of the entire body of certification arguments and evidence. Further, market trends strongly suggest that many future embedded systems will be comprised of heterogeneous, dynamic coalitions of systems of systems. As such, they will have to be built and assessed according to numerous standards and regulations. Current certification practices will be prohibitively costly to apply to this kind of embedded systems. The OPENCOSS project aims to devise a common certification framework that spans different vertical markets for railway, avionics and automotive industries, and to establish an open-source safety certification infrastructure. The infrastructure is being realised as a tightly integrated solution, supporting interoperability with existing development and assurance tools. The ultimate goal of the project is to bring about substantial reductions in recurring safety certification costs, and at the same time increase product safety through the introduction of more systematic certification practices. Both will boost innovation and system upgrades considerably. The project shall set a cornerstone in the safety culture by collecting the best practices from the different application domains, and stressing the common conceptual framework that will be the basis for common approaches and support tools leading to safe systems. In this context Task 1.1 plays a role by identifying in the certification process the constraints (or requirements) that are to be considered by the project as target for improvement. This deliverable is the first and unique output of Task T1.1. The goal of this document is to capture the constraints and requirements related to safety of the conformity/certification process related to the three application domains: Automotive Avionics Railway The document shall consider the applicable legislative background, the standards and the best practices used by the suppliers in order to deliver products to a customer. The voluntary and regulatory domains will be taken into account. A particular focus will be given to issues of cross-acceptance of safety assessments and certifications. This document contains the requirements and needs collected for the project. The requirements are assigned to the different application domains and will be collected in terms of (Figure 2.1): Safety Policy of the organization, in which the policy in terms of safety is evaluated; Safety Processes the safety life cycle is implemented in a safety workflow whereby it is necessary to evaluate all the processes including the supporting processes Safety Planning the safety design flow is applied on a specific project and a safety plan is defined, updated and evaluated according to the safety requirements of the reference standards(s) applied the project FP7 project # Page 8 of 73

9 Safety Product the specific safety measures and safety functions applied on the item in development are evaluated Figure 2.1. General structure of the Certification Framework There is one chapter per application domain (Automotive, Avionics, Railway), summing up all requirements relevant in each domain: these are the chapters from 3 to 5. Throughout the OPENCOSS project a requirement as identified in the annexes could go through the states Proposed, Approved, Implemented or Rejected, as shown in Figure 2.2, and a new version of the annexes could be envisaged in the course of the project (e.g. at the end), once the requirements will be selected and consolidated into the common platform. Figure 2.2. Lifecycle of a requirement The requirements are the result of the analysis of several needs. Each requirement is reported in the annexes of each domain using the framework of the proposed following figure and table (Figure 2.3 and Table 2.1), where also the relationship with the source of the requirement is evidenced: Figure 2.3. Classification of needs FP7 project # Page 9 of 73

10 <CRF> 0001: <Safety Culture> Alias Organization specific rules and processes for functional safety Status Proposed App. Domain Automotive Type Safety Policy Priority High Description To evaluate the existence of a safety culture internally to the organization that supports and encourages the effective achievement of functional safety Derived from ISO Part 2 clause Table 2.1. Example of proposed requirement classification A list of proposed requirements is reported for each domain in the annexes D1.1.a, D1.1.b, and D1.1.c respectively, for Automotive, Avionics and Railway. Additional annex D1.1.d is also available as example of a methodological point of view from Agile method development. The following list is the proposed reference content for every domain specific chapter: DOMAIN REFERENCE STANDARD(S) CERTIFICATION FRAMEWORK Safety management capability and planning Work Products Analysis of the results of the confirmation measures Processes Legal point of view Regulations Type approval and product liability (Homologation) Output from Certification framework CRITERIA AND GENERIC ELEMENT FOR COMPOSABILITY OF CERTIFICATION (SEooC) LIST OF PROPOSED REQUIREMENTS (for each domain) ANNEX Common final part INTEGRATION COMMON PART ACROSS DIFFERENT DOMAINS CONCLUSION 2.1 Relationships with the other WPs and Tasks In WP1 the deliverable D1.1 is the starting job of the first Tasks T1.1 Capture of the constraints of the certification process and, by its way, D1.1 provides the basic reference of the safety assurance process developed in each domain, according to which the industrial case studies can be structured in the second task T1.2 Industrial use case formalization and definition of the business impact. As a whole, WP1 constitutes the general reference scenario for WP2, providing the content to be formalized and transferred to the other Technical WPs (Wp3 to WP7). Thus WP2, in particular, derives information from T1.1 results, considering that the task T2.1 Specification of business cases and user needs refers to the safety certification scenario outlined by D1.1, that contributes to the input for the description of business case scenarios for the proposed platform development. Moreover, the task T2.2 Specification of High-level requirements gets from D1.1, integrating also T2.1 results, the requirements to be specified in details for the development of a high level data base, which summarize the different point of view from each domain. FP7 project # Page 10 of 73

11 3 AUTOMOTIVE DOMAIN 3.1 Reference standard The ISO [1] standard describes the requirements for the deployment of functional safety applied to the development of - on board electrical systems of a vehicle and their relationship with the rest of the vehicle The systems or composition of systems implementing a function to which ISO is applied are defined in the following as items. This standard extends the IEC [2] applied to functional safety of electrical/electronic/programmable electronic safety-related system. But ISO is not only the adaptation of IEC to comply with needs specific to the application sector of electrical and electronic systems within road vehicles. This adaptation, actually, applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic, and software components. Furthermore, while there are more and more risks from systematic failures and random hardware failures, because the trend of increasing technological complexity, software content and mechatronic implementation, ISO includes guidance to avoid these risks, by providing appropriate requirements and processes in a more general, complete, articulated and self consistent framework than in IEC 61508: ISO supports the entire automotive safety lifecycle (management, development, production, operation, service, decommissioning) and contains an automotive scheme for hazards classification. The key issue of the ISO is the definition of the objectives that a component/system, until to the integration level on a vehicle, must fulfill for assuring its compliance with the established safety requirements, depending on the scenario (the vehicle integration, the vehicle characteristics and intended behavior and performances, with related environmental conditions). Moreover, system safety is achieved through a number of safety measures, which are implemented in a variety of technologies (for example: mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic, etc.) and applied at the various levels of the development process, and, although ISO is concerned with functional safety of electrical and electronic systems, its framework can be applied to the safety-related systems based on other technologies. Additionally, its formal and structural completeness, from design until to the decommissioning of a vehicle, assures the level of responsibility (liability) of the car maker with respect to the safety compliance of his products: the application of ISO in the automotive domain aims to produce the necessary documentation that confirm the effectiveness of the safety behavior of the vehicle and its components. This result could be recognized at law level, as the best practice to which refer, but (until now) is not yet certified in an official way by organizational bodies external to the stakeholders. ISO 26262, that is also a reference for the functional safety of the electric vehicles, is constituted of several parts linked to each other. In particular, the safety lifecycle proposed by ISO encompasses the main activities related to the functional safety general process, during the development and after the production start, described in detail in the various parts of the standard. Figure 3.1 represents the reference model of the safety lifecycle to be applied to safety critical systems. The safety workflow, organized in the safety plan,, can also be tailored, provided that the modifications do not have any consequence on the standard safety lifecycle and are well motivated. (Boxes in Figure 4.1 contain the number reference m or m-n to the clauses of the standard, where m stands for Part number and n stands for Clause number). FP7 project # Page 11 of 73

12 After the release for production Product development Concept phase Constraints of the certification process D to 2-7 Management of functional safety Item definition Initiation of the safety lifecycle 3-7 Hazard analysis and risk assessment 3-8 Functional safety concept 4 Product development: system level 7-6 Operation planning 7-5 Production planning 5 HW 6 SW level level Allocation to other technologies Controllability External measures 4-9 Safety validation Functional safety assessment Release for production Production Operation, service and decommissioning In the case of a modification, back to the appropriate lifecycle phase Figure 3.1. ISO Safety lifecycle In the automotive domain this standard recommends that the car maker applies the functional safety requirements, as stated in all its parts from 1 to 9 included, during the overall life cycle of the product. The car maker, moreover, has the responsibility of making the Hazard analysis and the Risk assessment of the Electric/Electronic system(s) under examination and has to give the safety goals and the safety requirements to any involved supplier, defining by a specific document Development Interface Agreement (DIA) his responsibility level and the way of information sharing. Additionally, within the certification framework of a product/process all the technical standards and regulations related to the analysed item will be used, as starting references for the project design of the item and all its functional safety management issues. FP7 project # Page 12 of 73

13 3.2 Certification framework The following provides a general overview of the Conformity/Certification framework from the point of view of the Functional Safety Assessment (FSA) in the automotive domain Safety management capability and planning The car maker, according to ISO 26262, verifies the management capability about the functional safety of its organization, or supplier(s), in charge of the item in development. This should be done in terms of: safety internal culture, existence of specific rules and processes for this aim, specific competences among the persons involved in this job, evidence of quality management (for example: compliance with ISO 9001 [3]). The structure of the staff in charge of the safety goals should be well defined in terms of roles and responsibilities. The safety activities should be planned referring to a safety plan in the project plan, compiling safety cases and planning a Functional Safety Assessment (FSA). The safety plan shall include: Planning of activities (by including the objectives, the dependencies on other activities or information, the resources responsible for the activity, the required resources for performing the job, the starting point and duration of each phase with the identification of the corresponding work products) Project specific safety management Planning of Hazard analysis & risk Assessment (see about the definition and description of Hazard Analysis and Risk Assessment) Eventual tailored safety activities Planning of the development activities Planning of Development Interface Agreement (DIA) Planning of the supporting processes Planning of the verification activities Planning of safety validation activities Planning of the confirmation reviews Planning of initiation of the functional safety audit(s) Planning of initiation of the functional safety assessment Planning of the analysis of dependent failures Planning of the provision of the proven in use arguments (if applicable) Planning of the provision of the confidence in the usage of software tools (if applicable) This flow of evaluation should be carried out in three steps as follows: Overall safety management (the organization or the supplier as a whole) Safety management during item development Safety management after release for production Overall safety management The car manufacturer organization (area, department, business unit) [in the following named simply as organization + and supplier involved in an item development and under examination are evaluated with respect to their safety competence and capability according to the following requirements: FP7 project # Page 13 of 73

14 SAFETY CULTURE The organization or the supplier shall produce a document about the Organization specific rules and processes for functional safety, in which the specific processes and related rules for the application of the functional safety during the item development must be defined. This document will be evaluated about its completeness and correctness together with the verification that the organization or the supplier: has internally the safety culture putting in evidence the behaviours that support and encourage the application of functional safety requires and verifies that the safety culture is also present in all other external organizations that eventually participate and contribute to the same item development makes the documentation compliant with the reference standard and manages it during the safety life cycle execution guarantees the necessary resources for achieving functional safety gives to the actors of functional safety activities the authority suitable for their responsibility COMPETENCE MANAGEMENT The organization or the supplier shall produce document about the Evidence of competence, in which the resources, employed for the item development, and their competences must be outlined. This report will be evaluated about its completeness and correctness together with the verification that the organization or the supplier: involves persons with competences and categories corresponding to their responsibility checks and puts in evidence the same requirement in the other external organizations eventually involved in the development of the item. QUALITY MANAGEMENT DURING THE SAFETY LIFECYCLE The organization or the supplier shall produce a written report about the Evidence of quality management, in which the characteristics of its Quality System that has been applied during the development of the item are reported. This report will be evaluated about its completeness and correctness together with the verification that the organization or the supplier has a system for quality management, compliant with quality reference standards, such as ISO/TS 16949, ISO 9001 or equivalent, and supporting all other reference standards within the certification framework related to the functional safety management. PROJECT INDEPENDENT TAILORING OF THE SAFETY LIFECYCLE The safety lifecycle can be modified, independently from the project under development, if it is demonstrated that all the phases foreseen within the certification framework will be executed Safety management during item development The roles (project manager, safety manager etc. ) have to be defined, with the related responsibilities, for all the phases of the conformity/certification workflow applied to the item. FP7 project # Page 14 of 73

15 ROLES & RESPONSIBILITIES A Project Manager has to be appointed, for the item in development, starting from the initial phase. The Project Manager must be provided with the necessary authority for: assigning a Safety manager to the item development updating the safety activities of functional safety development required for the item, according to the reference standard guaranteeing the compliance with the reference standard distributing in a suitable way the necessary resources according to the planning SAFETY PLANNING The car manufacturer organization and the supplier(s) in charge of the item development must also provide evidence of: o Global project plan o Safety plan o Item integration and testing plan o Validation plan o Software verification plan o Safety case o Confirmation measures plan Safety management after release for production After release for production, the organization or the supplier has to demonstrate proper management of production, by providing evidence that: the processes for assuring the functional safety after the production release are defined the planning of the processes, with the suitable resources and their corresponding responsibility and authority, is executed planning started during the phase of system development and terminated at the beginning of the production phase the processes for monitoring production, in order to verify eventual deviations with respect to the safety level, are defined item traceability is provided production repeatability is guaranteed use and maintenance procedures from the point of view of the safety are defined use and maintenance handbooks have been produced the user manual has been edited Work Products The car maker has to verify the results of the safety activities, defined work products, realized by his organization(s) (area, department, business unit) and/or by the supplier(s), as required according to the reference standard and defined into the safety plan related to the item under development, as follows (according to ISO and related Parts). These work product for the automotive domain are reported into the ANNEX D1.1.a: they are more than 135 and constitute the requirements from the reference standard ISO 26262, to be applied to the safety FP7 project # Page 15 of 73

16 lifecycle of an item during its entire lifecycle, starting from the concept until to the production, service and decommissioning, considering also the general safety management capability of the organization or the supplier in charge of the item development. ISO specifies requirements with regard to the phases and sub-phases of the safety lifecycle, but also includes requirements that apply transversally to several, or all, phases of the safety lifecycle, such as the requirements for the management of functional safety. The management requirements are those already considered in the previous paragraphs, related to plan, coordinate and track the activities for the functional safety assessment (overall management, management during concept and development, management after release for production). The different main phases and sub-phases of the safety lifecycle and the related work product (from those reported in the Annex D1.1a), in Italics, are described as follow. Item definition This is the initiating task of the safety lifecycle and its result provides the description of the item, with regard to its functionality, interfaces, environmental conditions, legal requirements, known hazards, etc. The boundary of the item and its interfaces, as well as assumptions concerning other items, elements, systems and components are determined by this result (ISO Part 3, Clause 5). Initiation of the safety lifecycle Based on the item definition, the safety lifecycle is planned in the safety plan and initiated, by distinguishing between either a new development or a modification of an existing item. If an existing item is modified, the results of an impact analysis are used to tailor the safety lifecycle (ISO Part 3, Clause 6) providing the modifications on the work products influenced by the modifications (e.g. description of the item, safety plan refinement). Hazard Analysis and Risk Assessment (HARA) This task is performed after the initiation of the safety lifecycle (ISO Part 3, Clause 7). Among the work products of ISO 26262, this is a key point that set up the automotive scheme for hazards classification and safety goals definition. Based on the item definition, the objective of the hazard analysis and risk assessment is to identify and to categorize the hazards that malfunctions in the item can trigger and to formulate the safety goals related to the prevention or mitigation of the hazardous events, in order to avoid unreasonable risks. The hazard analysis and risk assessment estimates the probability of exposure (state of being in an operational situation that can be hazardous), the controllability (ability to avoid a specified harm or damage) and the severity (estimate of the extent of harm to one or more persons that can occur in a potentially hazardous situation) of the hazardous events with regard to the item. These parameters, together, determine the ASILs of the hazardous events: the ASIL shall be determined for each hazardous event using the previous parameters (probability of exposure, controllability and severity) in accordance with a specific table, in which the attributes A, B, C and D are assigned, defining the four different classes of ASILs, with the Safety Integrity Level increasing from A to D [and with a QM (Quality Management) attribute additionally defined for a class that do not requires compliance with ISO26262]. FP7 project # Page 16 of 73

17 The ASILs that result from the hazard analysis and risk assessment determine the minimum set of requirements on the item, in order to control or reduce the probability of random hardware failures, and to avoid systematic faults. The hazards shall be determined systematically at item level by using adequate techniques (brainstorming, checklists, quality history, FMEA, FTA,...); hazards shall be defined in terms of the conditions or behaviour that can be observed at the vehicle level. During the subsequent phases and sub-phases, detailed safety requirements are derived from the safety goals. These safety requirements inherit the ASIL of the corresponding safety goals. Functional safety concept Based on the safety goals, a functional safety concept (ISO Part 3, Clause 8) is specified considering preliminary architectural assumptions. The functional safety concept is specified by the functional safety requirements that are allocated to the elements of the item. The functional safety concept can also include other technologies (other than electric/electronic) or interfaces with external measures, provided that the expected behaviours thereof can be validated (validation plan) (ISO Part 4, Clause 9). Item development at the system level After having specified the functional safety concept, the item is developed from the system level perspective (ISO Part 4). The system development process continues, following the concept of a V- model, with the technical safety requirements specification, the system design specification and its related implementation through integration, safety analysis reporting, verification (plan refined and report), validation process, until to the functional safety assessment. The hardware-software interface specification(hsi) is also provided in this phase. Included into the item development, the HW and SW phases are deployed: Item development at the hardware level Based on the system design specification, the item is developed from the hardware level perspective (ISO Part 5). The hardware development process is still based on the concept of a V-model with, in sequence, the hardware safety requirements specification, the hardware design specification and its related implementation, through integration, verification and testing (with reporting). Item development at the software level Again based on the system design specification, the item is developed from the software level perspective (ISO Part 6). The software development process is still based on the concept of a V-model with, in sequence, the software safety requirements specification, the software architectural design specification and its related implementation through software integration, verification and testing (with reporting). Production planning and operation planning The planning for production and operation, and the specification of the associated requirements, starts during the product development at the system level, after the provision of the release for production FP7 project # Page 17 of 73

18 report (ISO Part 4; the requirements for production and operation are given in ISO Part 7, Clauses 5 and 6). Production and operation, service (maintenance and repair) and decommissioning This final phase addresses the production processes relevant for the functional safety goals of the item, i.e. the safety-related special characteristics and the development/management of instructions for the maintenance, repair and decommissioning of the item to ensure functional safety after the item's release for production (ISO Part 7, Clauses 5 and 6). FP7 project # Page 18 of 73

19 3.2.3 Confirmation measures The organization or the supplier implements the safety measures that are technical solutions used during the item design phase to allow the achievement of the safety goals. These safety measures must be confirmed and assessed by the organization or the supplier through the work products in a formal way defined as Confirmation measure, according to the reference standard, to certify that the item development is compliant with the safety goals: Confirmation measures of the safety plan Confirmation measures of the completeness of the safety case Confirmation measures of the hazard analysis and risk assessment of the item Confirmation measures of the item integration and testing plan Confirmation measures of the validation plan Confirmation measures of the proven in use arguments (analysis, data and credit) of the candidates Confirmation measures of the software tool qualification report Confirmation measures of the safety analyses Functional safety audits for processes and Final Functional safety assessment, described in the following, are also confirmation measures. The collection of the overall formal steps of safety assessment that can be classified and summarized under a structure of Confirmation measures procedure is represented in the picture Figure 3.2. Figure 3.2. Confirmation measures overview (from ISO 26262) FP7 project # Page 19 of 73

20 These confirmation measures have to be analysed and reviewed by the organization or the supplier: the confirmation reviews are intended to check the compliance of selected work products corresponding to the requirements of the reference standard. Also a follow-up is required of the recommendations from previous evaluations of functional safety, including eventual corrective actions if applicable Review of the safety plan For this action the following points have to be evaluated: the Confirmation measures of the safety plan the conformity to the functional safety life cycle, as described in the reference standard, of the activities included in the safety plan of the item (Concept phase, Product development at the system level, Product development at the hardware level, Product development at the software level) the eventual modifications and related justifications of these activities the conformity of the planning of the safety plan with the planning requirements of the safety activities as in the reference standard the completeness of the planning in terms of selected resources and defined responsibility the modality of delivery of parts and sub-parts using the Development Interface Agreement (DIA) Review of the completeness of the Safety Case The review of this part is composed of the following steps: The availability of the Safety Case from the organization or the supplier has to be verified The document Confirmation measures of safety case must exist The Safety Case must contain statements clear, complete and supported by testing, that every functionality and related components, used during item development, are not cause of risk: o Functional safety requirements o Justifications of them o Evidences of the real application of every functional safety requirement: - Product statements: everything directly linked to the basic functionality of the item - Process statements: everything directly linked with the development and evaluation process The work products referred to by the Safety Case of the item under examination must be available and complete and have to following characteristics: Traceable and reciprocally referenced Do not have open points that are potentially dangerous with respect to a safety goal Be coherent among them Review of the Hazard Analysis and Risk Assessment (HARA) The review of the potential hazards detected and the evaluation of the associated risks must be done as follows: Evaluation of the Confirmation measures of the hazard analysis and risk assessment Verification that the activity hazard analysis and risk assessment has been performed in compliance with what is foreseen in the safety plan and specified in the referenced standards Evaluation of the work product hazard analysis and risk assessment about: FP7 project # Page 20 of 73

21 - completeness of system boundaries definition (item definition) - completeness of hazards analysis - right evaluation of the hazards considering the estimation of detectability, severity and time of exposition (Risk Assessment) - the right values of ASIL (Automotive Safety Integrity Level ) (ASIL determination: see 3.2.2) - the correctness of safety goals and of eventual safe states Review of the item integration and testing plan This is the review of the plan for the integration and testing of the item, finalized with the verification of its compliance to the reference standard in relation to the activities for the functional safety validation Review of the validation plan This is the review of the validation plan for the item, consisting in the evaluation of its conformity to the requirements of the reference standard in relation to the activities for the functional safety validation Review of the proven in use arguments of the candidates This review is based on: evaluation of the results of proven in use arguments evaluation of the efficiency of the process of work monitoring evaluation of the elements candidates considered by the proven in use arguments Review of the qualification of software tools The review of SW qualification concerns the confidence in the usage of software tools. This kind of revision consists into the evaluation of the report related to the used tools, with the identification and classification of the suitability of these tools in the development of a safety related item Review of the safety analyses The review of the safety analyses consists in the evaluation of the correct execution of the analyses finalized to the identification of the faults or the insufficient safety mechanisms that can lead to the violation of a safety goal Processes and Audits The car maker, moreover, has to evaluate through a functional safety audit the safety processes applied in the design of the functional safety of the item. Also there are confirmation measures as previously stated. Some supporting processes must also exist for the application of the functional safety such as: item development distributed among various actors within the organization, management of safety requirements and configuration, documents verification and organization, SW tools qualification, HW components qualification and testing in use. The functional safety audit consists in the evaluation of the compliance and the right implementation of the processes applied during the functional safety development as following: FP7 project # Page 21 of 73

22 Processes for developing the functional safety planned in the safety plan in accordance with the safety lifecycle as defined in the standard: concept phase, product development at the system level, product development at the hardware level, product development at the software level. Supporting processes applied during the item development, in accordance with the standard requirements: Specification and management of safety requirements Configuration management Change management Interfaces within distributed developments (and related DIA) Verification Documentation Confidence in the use of software tools Qualification of software components Qualification of hardware components Proven in use argument Finally the safety measures evaluation follows. This is a general review of the technical solutions adopted for the achievement of the safety goals of the item: o Checking that all the verification and validation reviews have been done, as defined in the safety lifecycle, during the safety plan execution o Checking that all the results of all the validation and verification reviews applied to the work products are compliant with the functional safety requirements of the project under examination o Checking that all the verification reviews as foreseen in the standard have been executed Legal point of view Regulations The National regulations and laws will apply also as constraints, together with the technical standards during the Certification process, as, for instance, the ECE (Uniform provisions concerning the approval of vehicles with regard to specific requirements for the electric power train) for the electric vehicles, that will apply together with the ISO 6469 and the IEC technical standards groups Type approval and product liability (Homologation) Only as an example, it should be remembered that in Italy the vehicle authorisation for circulating on public roads follows the verification that a department dependent from Ministry of Transportation, the Motorizzazione Civile, organized by provincial offices, does according to the requirements of specific homologation standards. These standards are Italian laws that, as in the other European countries, are derived from the technical rules defined by the specific bodies of the European Community (ISO, IEC...). The vehicle technical standards in Italy, moreover, are also a competence of the Ministry of Transportation, that appoints the activities of rules definition to specific national associations on the matter (ANFIA: Associazione Nazionale Fra Industrie Automobilistiche National association between automotive industries; CUNA: Commissione tecnica di Unificazione dell Autoveicolo Technical commission for vehicle unification). FP7 project # Page 22 of 73

23 The regulations so defined in Italy encompass various themes such as safety, fiscal constraints, number of passengers, maximum payload, emissions, and foresee two main types of procedure: - homologation of type: for series production - homologation as unique specimen: for single vehicles; extendable to other identical vehicles, in a few quantity The kind of propulsion is not specified in the regulations and the rules contain a certain number of requirements that are specific for internal combustion engine that do not apply to electric vehicles with batteries and/or fuel cells. This situation produces in certain cases limitations to the vehicles propelled by electric motors. In general, worldwide, the National or local rules apply for homologation as in Italy and from the point of view of the new technologies can be divided into three classes: - A class: referring to the vehicle characteristics not related to the type of propulsion; all the constraints necessary for users and pedestrians safety (active and passive), identification and handling of vehicles are considered. - B class: considering in some way the type of vehicle propulsion and acceptable only after suitable amendment (internal accessories, braking, weight, fuel tank, defrosting, defogging, heating and conditioning, performances and consumption...) - C class: explicitly referring to vehicles with internal combustion engines (pollutions, emissions, acoustic noise level). The technology evolution requires to be integrated into a frame of standards and laws continuously updated to the actual state of the art, that should constitute the summary of the guarantees for the various components of the society (customers, public) towards the technology itself, in order to not compromise the chances of its acceptance. From this point of view the homologation aspects are strictly linked to the Functional Safety Certification framework, which can promote the generation of new regulations and laws and should be one of the constraints towards the overall certification process Output from Certification framework Final evaluation During the process of the Functional Safety Assessment/Certification all the verification results have to be collected, after being checked for their completeness. The evaluation of them allows final evaluation to start the item production, according to three levels: a) Approved acceptance. b) Conditional acceptance This level of acceptance has to be given only if the functional safety of the item is evident, in spite of the existence of some open points, that must be identified and evaluated by the organization or the supplier responsible of the assessment in order to assess that the functional safety of the item is completely uninfluenced The evaluation should include the gap with respect to the acceptability level and the motivation that justify the specific deviations. c) Refusal In case of refusal corrective actions must be started in order to make the item safe and the process of the Functional Safety Assessment must be repeated FP7 project # Page 23 of 73

24 Final report At the end of the Functional Safety Assessment the car maker has to produce a synthesis report with the final evaluation (this is the final confirmation review). The document collects the evaluations and the reports from the organization or the supplier in charge of the item development, containing the evaluations of the safety management, confirmation measures (previous confirmation reviews), verification reviews, audits and, in case of approved acceptance or conditioned acceptance, the final approval for starting production. FP7 project # Page 24 of 73

25 3.3 Criteria and generic element for composability of certification (SEooC) The automotive industries and Suppliers, develop also generic elements, not integrated into the context of a particular vehicle and therefore they are not classified as items, as defined above and can consist of: parts/subparts for multi-platform vehicles elementary HW components for different applications elementary SW components for different applications These generic elements can be: treated as a safety related element, developed outside of a specific item developed concurrently as a distributed development. Then, these generic elements (system, subsystem, software component, hardware component or part) can be classified as: Safety Element out of Context (SEooC). The SEooC is a safety-related element which is not developed for a specific item. To develop a SEooC it is necessary to make some assumptions to provide consistency to the application of the reference standard (ISO 26262) on developing the generic element(s). The assumptions are made that the requirements (including safety requirements) are placed on the element by the higher levels of the development flow (concept, design, development, integration) and also on the design external to the element. The integration of a SEooC into a specific item is allowed provided the consistency of the assumptions with respect to the specific interfaces of the item are verified. Moreover, to have a complete safety case, the validity of these assumptions is verified in the context of the actual item after integration of the SEooC. In the case that the SEooC does not fulfil the item requirements, a change(s) to the SEooC or a change(s) to the item is necessary. The SEooC is not directly pointed out in the Functional Safety Assessment (ISO Part 2). The SEooC can be developed off line and put on the shelf for future usage (in the future also with the conformity assessment according to OPENCOSS objectives); during the development of a specific vehicle this approach could reduce: the time to market, because you can use component off the shelf already verified and evaluated in terms of conformity assessment (NOTE that, actually, this activity is not foreseen in ISO standard) the effort, because you can use the SEooC for many applications on different models of vehicle The ISO standard requires an evaluation of the SEooC during the integration into the item, in terms of conformity assessment, but in OPENCOSS we could manage the conformity assessment as a type of compositional certification FP7 project # Page 25 of 73

26 4 AVIONICS DOMAIN 4.1 Regulatory framework The Convention on International Civil Aviation (also known as the Chicago Convention) was signed on 7 Dec A few years later it gave birth to the International Civil Aviation Organization (ICAO), a specialized agency of the United Nations (UN). The Convention set forth the purpose of ICAO, which as the international convention became binding by law for the signatory states. It imposed in particular: The adoption of standards and international procedures for airworthiness of aeronautical products, The issue of Type certificates and Certificates of Airworthiness for aeronautical products by the member States, The opening of accidents investigations according to the International Civil Aviation Organization (ICAO )rules. With the following main purposes: To ensure the orderly and safe development of civil aviation all over the world; To meet the needs of people for safe, effective & economic air transportation; To promote the safety and regularity of flights in international aviation community. The ICAO is continuously acting, further to the eighteen (18) technical annexes to the Convention that contain Standards and Recommended Practices (SARPs), in particular Annex 8 Airworthiness of Aircraft. All ICAO member states have developed their civil aviation regulations on the basis of the ICAO annexes. ICAO recommendations or mandates are regularly issued to cater for improvement of safety in civil aviation. Member states Authorities are bound to implement those recommendations and mandates. The following overview essentially focuses on the European Union (EU) civil aviation regulatory environment. Since 2003 the European Agency for Safety in Aviation (EASA) has been acting under the European Commission. It has direct Authority over aircraft manufacturers, equipment suppliers, repair stations and operators all over the European Union. EASA recently extended the scope of Regulation No 1592/2002 to air operations and pilots' licenses. Finally in the near futurethe Commission will be extended to the safety of airport operations and to air navigation. The following will address avionics, i.e. on-board equipment. Definitions: Certification (in Civil Aviation) is the formal recognition and Legal statement (written certificate), by the state authority, that an aeronautical product complies with the applicable regulations. is the procedure by which a written assurance is given that a product, process or service conforms to specified requirements. is generating acceptable documented evidence that the product meets regulations, the product is fit for flight and the product is safe for flight. According to European Community (EC) Basic Regulation No 216/2008 Article 3 (taking into account amendment 1108/2009) for the purposes of Certification and Airworthiness Regulation: Aeronautical Product means an aircraft, *turbine+ engine or propeller; FP7 project # Page 26 of 73

27 Parts and Appliances means any instrument, equipment, mechanism, part, apparatus, hardware accessories, software, and including communication equipment, that is used or intended to be used in operating or controlling an aircraft in flight; it shall include parts of an airframe, engine or propeller, or equipment used to maneuver the aircraft from the ground. Type Certification: The "Type Certificate" (TC) is issued, based on the Type Design of the aeronautical product (aircraft, engine or propeller), when that product is assessed to meet the applicable airworthiness requirements. Type Design: The type design consists of (summarized from EASA Part 21 21A31): 1. Drawings and specifications that define the as designed configuration of the product; 2. Information on materials and processes and on methods of manufacture and assembly; 3. Airworthiness limitations in the instructions for continued airworthiness section; and 4. Other data necessary to allow determination of airworthiness (noise & emissions, fuel venting). Individual Airworthiness: The "Certificate Of Airworthiness" (COA) is issued for each individual Product when conformity is determined to its Type Design, and if it is in condition for safe flight operation. Continued Airworthiness: In-service aircraft must be monitored to maintain its airworthiness in compliance with regulations, and to correct any defect that might affect safety Certification Basis: All applicable certification requirements are defined via EASA Certification Review Items (EASA CRIs) or FAA Issue Papers (FAA IPs). They address every issue from aircraft design to flight testing. Safety: Safety is the built-in ability designed of a system or equipment to meet objectives of reliability, integrity, availability & continuity properties or other characteristics such as aircraft performance or human factors whenever they are related to safety. Approval: The act or instance of giving formal or official acknowledgement of compliance with regulations. In the context of Integrated Modular Avionics (IMA), there are typically two forms of approval: approval of submitted life cycle data by the certification authority (usually demonstrated by issuance of a stamped letter of approval), installation approval by the issuance of an aircraft or engine type certificate and a subsequent individual airworthiness certificate. Acceptance: Acknowledgement by the certification authority, that the module, application, or system complies with its defined requirements. Acceptance is recognition by the certification authority (typically in the form of a letter or stamped data sheet) signifying that the submission of data, justification, or claim of equivalence satisfies applicable guidance or requirements. The goal of acceptance is to achieve credit for future use in a certification project. Incremental acceptance: A process for obtaining credit toward approval and certification by accepting or finding that an Integrated Modular Avionics (IMA) module, application, and/or off-aircraft IMA system complies with specific requirements. This incremental acceptance is divided into tasks. Credit granted for individual tasks contributes to the overall certification goal. Incremental acceptance provides the ability to integrate and accept new applications and/or modules, in an IMA system, and maintain existing applications and/or modules without the need for re-acceptance. FP7 project # Page 27 of 73

28 4.1.1 Certification Standards Certification requirements then derive from legal duties and associated rules & regulations. The Regulations include the technical codes or Certification Specification and Procedures on the basis of which are led the certification of aircraft and parts. Certification Specifications (CS) : Requirements associated with Avionics product design, Certification Procedures (IP): Implementation Procedures, Special Conditions (SC) established for specific purpose (novel features or technology). Airworthiness Regulation Aircraft weight category Aircraft type/procedure EASA CS-23 / FAR 23 >/= 5700 kg (12,500 lb) Small Aeroplanes Fixed wing EASA CS-25 / FAR 25 > 5700 kg (12,500 lb) Large Aeroplanes Fixed wing EASA CS-27 / FAR 27 >/= 3200 kg (7,000 lb) Small Rotorcraft Rotary wing EASA CS-29 / FAR 29 > 3200 kg (7,000 lb) Large Rotorcraft Rotary wing EASA Part 21 / FAR 21 All Certification procedures for Aircraft and related parts. Table 4.1. Main Certification Specifications and Implementing Rules used for avionics Special Conditions are established as part of the Certification Basis (CB) issued for each aircraft project. Figure 4.1. Certification Basis at various levels of Aircraft, System and Equipment FP7 project # Page 28 of 73

29 4.1.2 Industry Standards Industry organisations In compliance with certification regulations, safety requirements, and Authorities expectations, Industry Organizations have developed standards for Authorities, which may adopt those as acceptable means of Compliance with the rules and regulations. Industry Standards provide recognized means: to develop certifiable systems, software and hardware, to conduct activities and/or produce certification artefacts*, to contribute to systems certification and safety processes. *Artefacts: Written records of evidence of process/product results. EUROCAE - European Organisation for Civil Aviation Electronics, Joint Specifications with RTCA: ED12 (S/W), ED-14, ED-79, ED-80 (H/W), ED-124 (IMA), etc., Minimum Performance Specifications (MOPS/MPS) : ED-XXX. Advisory Circulars (via Working Groups) RTCA, Inc. - Requirements and Technical Concepts for Aeronautics Joint Specifications with EUROCAE: DO-178 (S/W), DO-160, DO-254 (H/W), DO-297 (IMA), etc. SAE, Inc. - Society of Automotive Engineers Aerospace Standards: ARP 4754 (System), ARP 4761 (Safety), etc., Advisory Circulars for the FAA (ex. : Lightning, HIRF, etc.), Technical Publications. The following standards are intended towards the needs of airlines (interchangeability, standardization, etc.), and have only an indirect relationship with the airworthiness standards. ARINC, Inc. - Aeronautical Radio Incorporated. Via the AEEC - Airline Electronic Engineering Committee. ATA - Air Transport Association ATA 100, 102, 300 for documentation WATOG - World Airlines Technical Operations Glossary EASA Means of Compliance EASA is using industry Standards adapted with its own certification standards and advisory material to provide guidance in terms of Interpretative Material or Acceptable Means of Compliance (AMC) with applicable regulations. Short list of Industry Standards used into AMC or CRI: Safety : SAE ARP EUROCAE ED-135 System : SAE ARP 4754A - EUROCAE ED-79A Integrated Modular Avionics : RTCA DO EUROCAE ED-124 Software : RTCA DO-178C - EUROCAE ED-12C Hardware : RTCA DO EUROCAE ED-80 Environmental : RTCA DO-160G - EUROCAE ED-14G FP7 project # Page 29 of 73

30 EASA Memos Additionally to Interpretative Materials, but with no formal applicability, EASA issued memos to clarify the Agency s general course of action on specific certification items. These Memos provide guidance on a particular subject and, as non-binding material, may provide complementary information and guidance for compliance demonstration with current standards. They are provided for information purpose only and must not be misconstrued as formally adopted Acceptable Means of Compliance (AMC). They neither introduce new certification requirements nor modify existing certification requirements and do not constitute any legal obligation. However those Memos will be called into a CRI dedicated to a Certification Project. Examples follows that have significant relationship with equipment development and certification: EASA CM-SWCEH-001 Development Assurance of Airborne Electronic Hardware EASA CM-SWCEH-002 Software Aspects of Certification Other Standards Though not specifically required or even recognized by Authorities, organisational certification standards such as ISO-9000 are generally mandated by business contracts between aircraft manufacturers and equipment suppliers. The aviation industry has even developed a specific instance of the standard (EN- 9100). Note however that ISO-9000 is the reference standard for quality organisation certification, which has quite a different purpose from aeronautical product certification. Formal recognition of organisations by certification Authorities can be summarized as follows: DEVELOPMENT - DOA (Design Organisation Approval) Per EASA Part-21, the capability for TC, STC, ETSO/TSO design must be demonstrated and a EASA Design Approval granted to the company performing those tasks. Aircraft manufacturer are EASA approved via DOA. They hold some delegated privileges (e.g.: approval of minor changes). Some equipment manufacturers are holding the A-DOA (Alternate DOA), which is now mandatory to design ETSO/TSO units. PRODUCTION - POA (Production Organisation Approval) Equipment manufacturers are holding EASA Part 21 G POA. The organisation is then recognized to be able to manufacture units of equipment and determine airworthiness prior to releasing those units for installation on aircraft MAINTENANCE - MOA (Maintenance Organisation Approval) Equipment manufacturers Repair Stations are holding EASA Part 145 MOA. The organisation is then recognized to be able to maintain and/or repair the units of equipment and ensure they conform to the original manufacture prior to release those units to service. 4.2 Development Assurance Development Assurance: All of those planned and systematic actions used to substantiate, at an adequate level of confidence, that development errors have been identified and corrected such that the system satisfies the applicable certification basis. The Figure 4.2 outlines the relationships between the various Industry Standards, which provide guidance for system development assurance, safety assurance, and the hardware and software process assurance. FP7 project # Page 30 of 73

31 Aircraft & System Development Process (ARP-4754 / ED-79) Guidelines for Integrated Modular Avionics (DO-297/ED-124) Electronic Hardware Development Process (DO254 / ED-80) Software Development Process (DO178B / ED-12B) Figure 4.2. Industry standards structure for development and safety assurance of avionics The concept of system development assurance is used as a means for showing compliance in certification: Highly-integrated or complex systems present greater opportunities for development error and undesirable unintended effects. Since these errors are generally not deterministic and as suitable numerical methods for characterising them are not available, other qualitative means should be used to establish that the system can satisfy its safety objectives. Development assurance establishes confidence that the system development has been accomplished in a sufficiently disciplined manner to limit the likelihood of development errors that could impact aircraft safety. Development assurance is a process involving specific planned and systematic actions that together provide confidence that errors or omissions in requirements or design have been identified and corrected to the degree that the system, as implemented, satisfies applicable certification requirements. Systems and items are assigned development assurance levels (DAL) based on failure condition classifications associated with aircraft-level functions implemented in the systems and items. The rigor and discipline needed in performing the supporting processes will vary corresponding to the assigned development assurance level. The system DAL is assigned based on the most severe failure condition classification associated with the applicable aircraft-level function(s). Failure Condition (FC) Classification (Detailed definitions in Safety Assurance) Catastrophic Hazardous / Severe Major Major Development Assurance Level (DAL) A B C FP7 project # Page 31 of 73

32 Minor No safety effect D E The Item DAL is allocated on the basis of the overall system architecture through allocation of risk determined using the PSSA (Preliminary System Safety Assessment per SAE ARP-4761). For items that support multiple aircraft functions, the applicable safety requirement should be based on the most severe of the effects resulting from failure or malfunction of any supported aircraft function or any combination of supported functions. If the PSSA shows that the system architecture provides containment for the effects of design errors (i.e. aircraft-level effects of such errors are sufficiently benign), development assurance activities can be conducted at a reduced level of rigor for the system items within the architectural containment boundary. If a system has multiple categories of Failure Conditions associated with its different functions, architectural means may be used to limit the interaction between items. This may allow the separate items to be developed at different assurance levels. System architectural features, such as redundancy, monitoring or partitioning, may be used to eliminate or contain the degree to which an item contributes to a specific failure condition, allowing simplification or reduction of the necessary assurance activity. Assurance that the item level assignments and their independence are acceptable should be validated at the higher level and verified by the SSA (System Safety Assessment, refer to ARP4761). SAE ARP-4754 gives insight into the correspondence between development assurance level and the recommended activities contained within the supporting processes. Note: As shown in figure 4.2, the Development Assurance provided via the development process is closely coordinated with the Safety Assurance provided via the Safety Assessment process. Refer to paragraph for details on Safety Assurance. In addition, those are not purely linear processes, but are conducted using technical methods featuring both top-down, bottom-up or middle-about approaches. Hence it is common that system design solutions might be fed back to system requirements definition. For example, system architecture decisions may have significant impact on Failure Conditions and their classification. The DAL then determines the necessary software and hardware design levels of DO-178B and DO-254. Software level: The software levels and processes for compliance, as defined in EUROCAE ED- 12B/RTCA DO-178B, are related to the failure condition classifications of the ARP4754 DAL. Hardware level: When deterministic techniques cannot be used or are insufficient to demonstrate the safety of hardware design then the EUROCAE ED-80/RTCA DO-254 applies per allocated DAL Design Assurance Historically, DO-178B/ED-12B and DO-254/ED-80 were considered Design Assurance guidance, though their scope extended throughout the entire development life-cycle from Requirements and Design to Implementation, together with supporting process of Validation, Verification, Configuration Management, Process Assurance and Certification Liaison. More recently, the relationship between EUROCAE ED-79 /SAE ARP 4754 and EUROCAE ED-135/SAE ARP 4761, and their relationship with DO-178B/ED-12B and DO-254/ED-80 have been strengthened and FP7 project # Page 32 of 73

33 discrepancies between the documents were addressed. ED-79 /ARP 4754 Rev. A expands the Design Assurance concept for application at the aircraft and system level and standardizes on the use of the term Development Assurance. At aircraft and systems levels, a Functional Development Assurance Level (FDAL) is introduced and the term Item Development Assurance Level (IDAL) is used. Item: One or more hardware and/or software elements treated as a unit, having bounded and well-defined interfaces. Specific to Hardware Item are two Design Assurance approaches that have been in use: - Rely on a comprehensive combination of deterministic testing and analysis for simple hardware items. - Rely on a structured hardware design assurance process--that is, satisfy set objectives. The latter route to compliance is then designated as the Development Assurance process Safety Assurance As shown in figure 4.2, A Safety Assessment process is closely linked to the System Development process. All actions and results related to safety are sometimes referred to as the Safety Assurance process. This process is using dedicated terminology and definitions, hence most of those are provided below. Incident: An occurrence, other than an accident, which is associated with the operation of an aircraft, and that affects or could affect the safety of such operation. Accident: An occurrence associated with the operation of an aircraft, between the time any person boards the aircraft until all such persons have disembarked, and in which one or more persons are fatally or seriously injured, or the aircraft sustained structural damage or complete loss. Failure (ARP-4761): A loss of function or a malfunction of a system or a part thereof. Malfunction: The occurrence of a condition whereby the operation is outside specified limits. Failure Condition (FC): based on ARP A determining factor (one or more failures), which, under adverse operational or environmental circumstances, directly or indirectly affects aircraft or occupants. Failure Conditions are generally classified according to the severity of effects as follows: Minor FC: FC, which would not significantly reduce aeroplane safety, and which involves crew actions that are well within their capabilities. Major FC: FC, which would reduce the capability of the aeroplane or the ability of the crew to cope with adverse operating conditions to the extent that there would be, for example, a significant reduction in safety margins or functional capabilities, a significant increase in crew workload or in conditions impairing crew efficiency, or discomfort to occupants, possibly including injuries. Hazardous FC: FC, which would reduce the capability of the aeroplane or the ability of the crew to cope with adverse operating, conditions to the extent that there would be (i) a large reduction in safety margins or functional capabilities; (ii) physical distress or higher workload such that the flight crew cannot be relied upon to perform their tasks accurately or completely, or (iii) serious or fatal injury to a relatively small number of the occupants. Catastrophic FC: FC, which would prevent the continued safe flight and landing of the aeroplane. FP7 project # Page 33 of 73

34 When using qualitative or quantitative assessments, the following probability terms are used to aid in the engineering judgement for determination of requirement and acceptable means of compliance: Probable FC: Probable FCs are those anticipated to occur one or more times during the operational life of the aeroplane. They have a probability of the order of 1 x 10-5 or greater. Minor FCs may be probable. Improbable FC: Improbable FC are divided into two categories: (i) Remote: Unlikely to occur to the aeroplane during its total life but may occur several times in the operational life of a number of aeroplanes of the same type. They have a probability of the order of 1 x 10-5 or less, but greater than of the order of 1 x Major Failure FCs must be no more frequent than Improbable (Remote). (ii) Extremely Remote. Unlikely to occur in the total operational life of all aeroplanes of the same type, but must be considered possible. They have a probability of the order of 1 x 10-7 or less, but greater than of the order of 1 x Hazardous FCs must be no more frequent than Improbable (Extremely Remote). Extremely Improbable FC: Extremely Improbable FCs are not anticipated to occur during the entire operational life of all aeroplanes of one type. They have a probability of the order of 1 x 10-9 or less. Catastrophic Failure Conditions must be shown to be Extremely Improbable. Hazard (ARP-4761): A Hazard is a potentially unsafe condition resulting from failures, malfunctions, external events, errors or a combination thereof. A Hazard is a Failure Condition that may lead to an incident or accident. Risk: (adapted from ARP-4761). Measurement of "Hazard" in terms of likelihood [probability] of occurrence and associated level [severity] of effects, combined with an exposure [in time] to danger. Functional Hazard Assessment (FHA): Based on SAE ARP A FHA is a systematic, comprehensive examination of functions to identify and classify failure conditions of those functions according to their severity. An FHA is usually performed at two levels: an aircraft-level FHA and a system-level FHA. The aircraft-level FHA is a high level, qualitative assessment of the basic aircraft functions at the beginning of development. The system-level FHA is also a qualitative assessment, iterative in nature, taking into account the system architecture and becomes more defined and settled as the system evolves. The System Safety Assessment Process is the complete process applied during the design of the system to establish safety objectives and to demonstrate compliance with FAR 25/CS and other safety related requirements. The safety assessment process provides a methodology to evaluate aircraft functions and the design of systems performing these functions to determine that the associated hazards have been properly addressed. The safety assessment process is qualitative and can be quantitative. It is of fundamental importance in establishing appropriate safety objectives for the system and determining that the implementation satisfies these objectives. It should be managed to provide the necessary assurance that all relevant failure conditions have been identified and that all significant combinations of failures, which could cause those failure conditions have been considered. The SAE ARP-4761 document presents guidelines for conducting a safety assessment. Refer to figure 4.3 for a detailed illustration of the System Safety Assessment process described below: - Functional Hazard Assessment (FHA): It consists in identifying and classifying the failure condition(s) associated with the aircraft functions and combinations of aircraft functions. These failure condition classifications establish the safety objectives. The output of the FHA is used as the starting point for conducting the PSSA. FP7 project # Page 34 of 73

35 - Postulate Hazards Based on the Failures of Functions; The FHA is independent of H/W and S/W, - Derive Overall Effect of Hazard on System/Aircraft and People Classify Failure Conditions effects, - Assess Severity of Failure Condition Assign Classification. FHA provides the Fault Tree Analysis (FTA) Top Events - Preliminary System Safety Assessment (PSSA): PSSA is a system evaluation of the proposed architecture(s) and implementation(s) based on the Function Hazard Assessment (FHA) failure condition classifications to determine safety requirements of the system. It establishes the safety requirements of the system and determines that the proposed system architecture can reasonably be expected to meet the safety objectives identified by the FHA (i.e. how failures can cause the functional hazards of the FHA). The PSSA is an iterative analysis associated with the design definition and imbedded within the overall development. PSSA provides a systematic means of evaluating safety early in the design process and to reduce surprises at the end of the development program. The PSSA usually takes the form of a Fault Tree Analysis (FTA) (Dependence Diagram (DD) or Markov Analysis (MA) may also be used) and should also include Common Cause Analysis (CCA) (see below). At the end, system level requirements are allocated to items and finally item requirements will be allocated to hardware and software elements. Allocation of risk to items will determine development assurance requirements for both hardware and software (see ARP4754). - System Safety Assessment (SSA): A systematic, comprehensive evaluation of the implemented system to be certified to show that the qualitative and quantitative safety requirements as defined in the FHA and PSSA have been met. It evaluates the implemented system to show that safety objectives from the FHA and derived safety requirements from the PSSA are met. The SSA is usually based on the PSSA FTA (DD or MA may also be used) and uses the quantitative values obtained from the Failure Modes & Effects Analysis (FMEA) and Failure Modes & Effects Summary (FMES). The SSA should verify that all significant effects identified in the FMES are compatible with FTA primary events. The SSA must also include applicable Common Cause Analysis (CCA) results. Additional activities known as Common Causes Analyses (CCA) of safety in aircraft avionics include: Common Mode Analysis (CMA) to address potential common modes of failures across systems, Zonal Safety Analysis (ZSA) to cover specific aspects of systems installation and location on aircraft, Particular Risks Analysis (PRA) to cater for very specific aspects (rotor burst, bird strikes, fire, etc.). Note: Those three types of analysis above can be partially performed at an avionic system level or may involve part or all of an avionic system but they can only be resumed and completed as an integral part of the [Preliminary] Aircraft Safety Assessment (PASA/ASA). FP7 project # Page 35 of 73

36 A/C FHA Σ(SSA) FHA section SSA (+CCA) Figure 4.3. Safety Assurance process for avionics systems Process Assurance Along with the development and certification process, the Process Assurance is a transverse activity implemented to ensure that the development assurance activities are maintained and followed. The objectives of the process assurance activities are: a. To ensure the necessary plans are developed, and then maintained for all aspects of aircraft, system and item development. b. To ensure development activities and processes are conducted in accordance with those plans. c. To establish evidence that the activities and processes adhere to the plans. A Process Assurance Plan is established to describe the means to assure the practices and procedures to be applied during development. Particular emphasis is placed on the certification-related activities. Process Assurance activities are generally part of the conventional Quality Assurance activities, together with the Product Assurance activities, and are conducted with the required independence. FP7 project # Page 36 of 73

37 4.3 Authorities Involvement Level of Involvement (LOI) Depending on the criticality, complexity and novelty of the hardware or software item, and based on other considerations, the Certification Authorities define their Level of Involvement (LOI) from NONE to HIGH. This LOI will then determine both the review effort and data submittal requirements that shall be fulfilled. LOI HIGH MEDIUM LOW NONE Reviews At least 2 on-site reviews (e.g. Design Review, Verification review) + desktop reviews (e.g. Planning Review, Final Certification Review) + additional technical meetings (e.g. novelty) + Review of applicant Review Reports At least 1 on-site review (e.g. combined Design and Verification Reviews) + desktop reviews (e.g. Planning Review and Final Certification Review) + additional technical meetings + Review of applicant Review Reports Desktop reviews + Review of applicant Review Reports Review of applicant Review Reports. Note that EASA may increase its involvement if they decide so. Table 4.2. Level Of Involvement (LOI) of Authorities in Avionics Note that the terminology LOI is used by both EASA and FAA Authorities and is thus internationally used Stages of Involvement (SOI) The development approval process leading to certification is marked by formal reviews conducted along with the process at key milestones known as the Stage Of Involvement (SOI) with Authorities. SOI Reviews [Audits] are planned, prepared and conducted to meet the certification process requirements. SOI #1: Planning Review is conducted when the initial planning process is completed, to determine whether the applicant s plans and standards satisfy the objectives of the standards, both hardware and software. SOI #2: Development Review is conducted when the design process and resulting data are sufficiently complete and mature to ensure that enough evidence exists to show effective implementation of the plans and application of the standards. FP7 project # Page 37 of 73

38 SOI #3: Verification Review is conducted when the verification process and resulting data are sufficiently complete and mature to ensure that representative data exists to show effective implementation of the plans and application of the standards. A common understanding of SOI#2, respectively SOI#3, is to consider them associated with the top-down, i.e. design portion of the development for SOI#2 to be conducted, and the bottom-up, i.e. verification portion of the development for SOI#3 to be conducted, respectively. SOI #4: Final [Certification] Review is conducted when all the development activities are completed for the final configuration identified and considered applicable and valid for the intended to be certified equipment, system, hardware and software. Note that the term SOI was originally an FAA term but is known and used by FAA and EASA Authorities Domains of involvement The development and certification processes may incorporate multiple configuration items, both software and hardware. The concept of Audit Unit or Domain Of Involvement (DOI) is defined to allow a better control, monitoring and reporting of the activities and production of data on a domain per domain basis. Note that the term DOI is not formally used as of today. FP7 project # Page 38 of 73

39 4.4 Certification process The objective of the Certification Process is to demonstrate that the product meets its functional and safety requirements. Depending on the consequences of a failure, a DAL is allocated to the product. The certification process extends from Proof of Concept through project development, including design from requirements to actual code or hardware and verification via analyses and testing, to in-service operations, including continued airworthiness (maintenance). The airworthiness is the ability for an Aeronautical Product (incl. all units of equipment) to satisfy applicable rules & regulations, meet intended functions and be in safe conditions for people. Figure 4.4. Overall certification process for avionics systems Aircraft aspects are under control of the aircraft manufacturer, applicant, then holder of Type Certificate. The certification process, at aircraft level, includes first the establishment of a Certification Basis: Regulatory Certification Requirements and standards based on applicable EASA/FAA regulations + Selection of current amendments + Special Conditions (SC) established by Authorities for specific purpose (novelty of design, features or technology of the aircraft) FAA Advisory Circulars and/or EASA Acceptable Means of Compliance (AMCs), Issues & Interpretations EASA Certification Review Items (CRI) or FAA Issue Papers (IP) allow Official liaison with Authorities Equivalent safety findings if alternative methods, features or processes are used Means of Compliance (MOCs). MOCs are the various types of methods used first at aircraft level, then at any level to show compliance with regulatory requirements along with the development process. The MOCs are independent from the DAL but they are variable in terms of providing extensive assurance (e.g. testing is generally more convincing but sometimes lacks representativity). List of MOCs: MOC # 0: Noted (N). Declarations of Performance or verifiable statements, MOC # 1: Review (R). Design reviews and descriptive data and drawing, MOC # 2: Analysis (A). Miscellaneous engineering and technical analyses, MOC # 3: Failure Analysis (FA). SSA (based on FTA, FMEA or other methods), MOC # 4: Functional Tests (FT). Testing performed on representative test rigs, MOC # 5: Ground Tests (GT). Testing using aircraft test rig & aircraft on ground, MOC # 6: Tests in-flight (TF). Testing using aircraft during roll-out and in-flight, MOC # 7: Inspections (I). Examinations by Authorities representative or their delegates, MOC # 8: Flight Simulations (FS). Evaluations on representative Flight simulators, MOC # 9: Data (D). Qualification (equipment, System S/W & H/W). FP7 project # Page 39 of 73

40 Finally compliance reports and records associated with MOCs are produced and submitted to Authorities. 4.5 Certification organization The organization for certification within manufacturers structure will vary depending on the actual responsibility, whether all or part of the certification responsibility is delegated or not from the aeronautical product manufacturer -who is generally the applicant for certification- to the equipment suppliers who may have already some kind of organization approval in place for a particular scope of work. In addition the organization for certification may differ from one country to another. For example the US FAA system is using designated personnel such as the Designated Engineering Representatives (DERs), while the EU EASA system is based on approval of organizations for design, production, maintenance. The following figure 4.5 shows a typical organization of certification functions within an industrial manufacturer that will become more and more the reference in the future. There are common concepts that can be briefly described. The organization should feature: A Design function responsible for performing the life-cycle activities and producing lifecycle data, while showing compliance with certification requirements, An approval or airworthiness (when formally delegated) function responsible for overseeing the work performed and providing a compliance verification checking, An Airworthiness Assurance Function, which is responsible for setting up and maintaining the organization approvals when needed as part of the delegation. Though sometimes included in a Quality entity, Airworthiness Assurance must not be confused with the Product and Process Assurance parts of Quality Assurance, which are normally associated with the Design Function. The two are of course featuring the appropriate independence characteristics. FP7 project # Page 40 of 73

41 Design Function Specify Design Validate Verify Integrate Establish system and equipments certification documentation (plans, accomplishment summaries, etc) Show compliance with Airworthiness Requirements Note The Design function usually incorporate a Quality Assurance activity dedicated to the project. Independence must be ensured. Approval or Airworthiness Function Discuss the certification basis with customer or authorities Cascade the certification basis to Design function Manage the certification activities of the programmes Focal point to Airworthiness Authorities and Manufacturer Airworthiness Departments Responsible of internal certif. policies and strategy Check the completeness of certification activities Exercise the official privileges (modification approval, etc.) Airworthiness Assurance Function Obtain and maintain Organisation Approvals (Design, Production, Maintenance) Maintain list of responsible and authorised signatories Monitor the correct application of the procedures through surveillance plan and annual audit programme within and at its design suppliers To deploy Airworthiness process training for all staff concerned Focal point for Organization approvals Design Office Entities Certification Direction Entity Quality Organisation Entity Figure 4.5. Typical organization for certification at avionics manufacturer facilities 4.6 Certification Data Package The data packages formally mandated via applicable certification requirements are those established by Industry Standards. In addition only a few documents must be formally submitted, while the others must of course be produced and made available depending on the document, the Level Of Involvement (LOI), the DAL. Three categories are generally established: Submitted For Agreement means that formal approval from Authorities must be explicitly obtained, Submitted For Information means that Authorities will review the document and provide comments, On request means that Authorities may be entitled to examine the document and provide comments. FP7 project # Page 41 of 73

42 Certification Documents to be provided LOI PSAC, TQP PHAC, TQP SAS HAS SCI (VDD) HCI (CID) Other plans SW/HW HIGH MEDIUM LOW For agreement For agreement For information For agreement For agreement For information For information For information For information On request On request On request NONE On request On request On request On request Table 4.3. Avionics Data Package categories of submittals to Authorities As of today, only Software, Hardware and Qualification (i.e. qualification testing to Environmental Conditions) Data Packages are subject to formal and standardized reviews by Authorities. This is commensurate with the fact that the end items installed on-board an aircraft are actually made of hardware and software within an on-board environment. However, Data Packages as a result of Aircraft design and installation, System design, Safety analysis and also Human Factors and many other data at aircraft level (e.g. as they are related to all the MOCs), are submitted or made available to Authorities. The followings provide examples of Data package for Hardware, Software and Systems. Systems may take different forms and extensions: from a single unit or platform (hardware + software), to a fully fitted avionic suite, through Integrated Modular Avionics (IMA) and Avionics Data Network (AND), which are becoming more and more standard architecture concepts. Indeed IMA and AND, as they introduced new development concepts, will push the certification process requirements into more and more standardized practices. It is beyond the scope of this document to examine in details all possible instantiations of systems certification organizations, activities and data. FP7 project # Page 42 of 73

43 Summary example of Hardware Data Package: (S: Submittal to Authorities A: Available for Audits/Reviews): DO-254 ED-80/DO-254 Title S/A Plan for Hardware Aspects of Certification S Hardware Design Plan A Hardware Validation Plan A Hardware Verification Plan S A Hardware Configuration Management plan A Hardware Process Assurance Plan A Hardware requirements standards A Hardware design standards A Validation and verification standard A Hardware Archive Standards A Hardware requirements A Hardware Conceptual Design Data A Hardware Detailed Design Data A Top-Level Drawing S Assembly Drawings A Installation Control Drawings A Hardware / Software Interface Data A Hardware Traceability data A Hardware Review and Analysis Procedures A Hardware Review and Analysis Results A Hardware Test Procedures A Hardware Tests Results A 10.5 Hardware acceptance test criteria A 10.6 Problem reports A 10.7 Hardware configuration management records A 10.8 Hardware Process Assurance Records A 10.9 Hardware accomplishment summary S Table 4.4. Example of data list for Avionics Hardware FP7 project # Page 43 of 73

44 Summary example of Software Data Package: Software and Hardware data package are similar in terms of documents and data to be formally produced. DO-178B ED-12B/DO-178B Title S/A 11.1 Plan for Software Aspects of Certification S 11.2 Software development plan A 11.3 Software verification plan A 11.4 Software configuration management plan A 11.5 Software quality assurance plan A 11.6 Software requirements standards A 11.7 Software design standards A 11.8 Software code standards A 11.9 Software requirements data A Design description A Source code A Executable object code A Software verification cases and procedures A Software verification results A SW life cycle environment configuration index A Software configuration index S Problem reports A Software configuration management records A Software quality assurance records A Software accomplishment summary S Table 4.5. Example of data list for Avionics Software FP7 project # Page 44 of 73

45 Summary example of System data Package: System-level documentation and data are also similar to hardware and software with addition of safety. ARP 4754A ED-79A / ARP 4754A Title S/A Certification Plan S Development Plan A Design Description A Validation Plan A Verification Plan A Configuration Management Plan A Process Assurance Plan A Configuration Index S Functional Hazard Assessment A Preliminary Aircraft / System Safety A Assessment Aircraft / System Safety Assessment S Common Cause Analysis A Validation Data A Verification Data A Evidence of Configuration Management A Evidence of Process Assurance A Certification Summary / Compliance Report S Table 4.6. Example of data list for Avionics System Summary example of IMA Data Package: The IMA introduced new concepts, including Usage Domain definition and validation, incremental acceptance, together with the definition of various items from Components such as Module and Application to Change and Reuse of such components, through both System-level and Aircraft-level acceptance. It is not possible to provide all cases of IMA instantiation. However the following is based on ED-124/DO- 297 for at least data formally submitted. DO-297 ED-124 / DO-297 Title S/A Module Acceptance Plan S & IMA Certification Plan (system and aircraft-level) S & IMA Verification and Validation Plan (system- and aircraft-level) S Ref. DO-160 Environmental Qualification Test (EQT) Plan Ref. DO-160 Environmental Qualification Test (EQT) Reports S S Module Configuration Index(es) S & IMA Configuration Index (system and aircraft-level) S FP7 project # Page 45 of 73

46 DO-297 ED-124 / DO-297 Title S/A Module Acceptance Data Sheet S Safety Assessment Analysis/Report(s) S Module Acceptance Accomplishment Summary S & IMA Accomplishment Summary (system- and aircraft-level) S Table 4.7. Example of data list for IMA System Summary of the main twelve certification principles in Avionics: 1. Certification is a legal duty (by law) established by international and derived state regulations, 2. Certification regulations are safety-oriented in the general meaning, i.e. incl. all aspects of safety, 3. Civil Aviation is international by nature (harmonisation of rules and standard is a leading objective), 4. Evidence of compliance (certification data package) is central as a result of means of compliance, 5. Associated with Safety, the concept of Intended Function is driving the design and development, 6. And the intended function means: Requirement-based Engineering and Validation & Verification, 7. Demonstration effort and Authorities involvement is tailored to criteria such as: novelty, complexity, criticality, and other aspects such as new technology, new methods and tools, 8. A structured development process-oriented approach to development assurance is the preferred route to show compliance with regulation when the product (H/W) is complex and for S/W, 9. Multiple stakeholders are involved in avionics certification (from Suppliers to Authorities through Customer and 3 rd -parties) when compared to Qualification (single Customer-Supplier relationship), 10. Streamlined Configuration Management is mandatory (identification, baselines, problem reporting & change control, release, archive and retrieve), 11. The concept of Development Assurance to include Design Assurance, Safety Assurance and Process assurance, 12. Product Approval must be more and more based and ensured via Organisational Approvals (DOA, POA, MOA, LOA) and the associated procedures and instructions within the organisation. FP7 project # Page 46 of 73

47 5 RAILWAY DOMAIN 5.1 Reference Standard The EN standard [4] covers the specification and demonstration of safety for all railway applications and at all levels of such an application, as appropriate, from complete railway routes to major systems within a railway route, and to individual and combined sub-systems and components within these major systems, including those containing software and hardware. Although this aspect is not emphasized here, the standard also addresses Reliability, Availability, and Maintainability (RAM) as essential aspects of a railway system which contribute to safety. EN serves as the entry point or parent standard for the other European standards for the railway domain which are of major relevance to OPENCOSS (EN [5], EN [6], EN [7]). Figure 5.1 represents the reference model of the safety lifecycle to be applied to safety critical systems. The processes can be also tailored, provided that the modifications do not have any consequence on standard safety lifecycle and are well motivated. (The items in the figure are identified by the number of the phase that the standard defines). Figure 5.1. EN Safety lifecycle FP7 project # Page 47 of 73

48 For each phase, the activities to be carried out for safety assurance are summarized in the following table. LIFECYCLE PHASE PHASE RELATED SAFETY TASKS 1. CONCEPT Review Previously Achieved Safety Performance Consider Safety Implications of Project Review Safety Policy & Safety Targets 2. SYSTEM DEFINITION AND Evaluate Past Experience Data for Safety APPLICATION CONDITIONS Perform Preliminary Hazard Analysis Establish Safety Plan (Overall) Define Tolerability of Risk Criteria Identify Influence on Safety of Existing Infrastructure Constraints 3. RISK ANALYSIS Perform System Hazard & Safety Risk Analysis Set-Up Hazard Log Perform Risk Assessment 4. SYSTEM REQUIREMENTS Specify System Safety Requirements (Overall) Define Safety Acceptance Criteria (Overall) Define Safety Related Functional Requirements Establish Safety Management 5. APPORTIONMENT OF SYSTEM Apportion System Safety Targets & Requirements REQUIREMENTS Specify Sub-System & Component Safety Requirements Define Sub-System & Component Safety Acceptance Criteria Update System Safety Plan 6. DESIGN AND IMPLEMENTATION Implement Safety Plan by Review, Analysis, Testing and Data Assessment, addressing: Hazard Log Hazard Analysis & Risk Assessment Justify Safety Related Design Decisions Undertake Programme Control, covering: Safety Management Control of Sub-Contractors & Suppliers Prepare Generic Safety Case Prepare (if appropriate) Generic Application Safety Case 7. MANUFACTURING Implement Safety Plan by: Review, Analysis, Testing & Data Assessment Use Hazard Log 8. INSTALLATION Establish Installation Programme Implement Installation Programme 9. SYSTEM VALIDATION (INCLUDING Establish Commissioning Programme SAFETY ACCEPTANCE AND Implement Commissioning Programme COMMISSIONING) Prepare Application Specific Safety Case 10. SYSTEM ACCEPTANCE Assess Application Specific Safety Case 11. OPERATION AND MAINTENANCE Undertake On Going Safety Centred Maintenance Perform On Going Safety Performance Monitoring and Hazard Log Maintenance 12. PERFORMANCE MONITORING Collect, Analyse, Evaluate and Use Performance & Safety Statistics 13. MODIFICATION AND RETROFIT Consider Safety Implications for Modification & Retrofit 14. DECOMMISSIONING AND Establish Safety Plan DISPOSAL Perform Hazard Analysis & Risk Assessment Implement Safety Plan Table 5.1. Safety Tasks for each phase defined in EN50126 FP7 project # Page 48 of 73

49 5.2 Certification framework The following section summarises the Certification framework -- the process to achieve and obtain acceptance of the proof of safety assurance, as applied in the railway domain. The safety of a system is meant as the property that the rate of failures with potentially dangerous consequences is low enough to globally reduce the risk (i.e. the probability of injuries, fatalities, damages) to a specified acceptable value. The process requires application of EN 50129, which lists factors that influence RAM and Safety as defined in EN 50126, and adopts a broad risk-management approach to safety. The CENELEC Application Guideline, TR , provides supplements on application of the standard to achieve the case for safety, and includes additional material concerning Safety Assessment, Safety Approval, and Cross-Acceptance. EN defines how the conditions for safety acceptance and approval shall be presented. The conditions shall cover three major themes: Quality Management; Safety Management; Functional and Technical Safety. The documentary evidence that these conditions have been satisfied shall be included in a structured safety justification document known as the Safety Case. Acceptance by qualified organisations and national regulatory bodies of the Safety Case, through the activities of approval, assessment, and cross acceptance, is the ultimate step allowing the railway system to enter passenger service. The following definition of Assessment is taken from EN50129: Assessment - The process of analysis to determine whether the design authority and the validator have achieved a product that meets the specified requirements and to form a judgment as to whether the product is fit for its intended purpose. The phrase the design authority and the validator refers to the manufacturer and encompasses activities of design, testing, V&V, quality and safety assurance processes, facilities and competencies, with related independence constraints on roles and responsibilities. 5.3 Safety Case Structure of the overall case for safety The railway domain uses by normative requirement an approach that is modular: there is an emphasis on the model of the system as broken down into sub-systems and constituent components (generic products), associated for the purpose of safety assurance to a tree-like structure of safety cases embedded within each other. In the figure 5.2, an example of a possible hierarchy of Safety Cases is illustrated, and each is associated to one of the following categories: FP7 project # Page 49 of 73

50 Generic Product Safety Case: addresses a core product used in Generic applications; Generic Application Safety Case: addresses standard developments common to several projects; Specific Application Safety Case: addresses specific data configuration and specific installation for a dedicated project Contents of the Safety Case Figure 5.2 Example of a possible hierarchy of Safety Cases In this section we summarize the main themes and key concepts that must be present in the Safety Case. As specified in EN50129, the precise chapter number for each item is identified. The list below is a selection and does not represent an exhaustive enumeration of the full mandatory contents (items of lower relevance are suppressed for brevity). Certain important themes or concepts are simply listed here and then detailed further below in dedicated sections. Our purpose in describing the contents of the Safety Case document serves as an enumeration of the activities that the safety assurance and V&V population must perform to achieve a development with demonstrable compliance Safety Case Part 1 Definition of System (or sub-system/equipment) This shall precisely define or reference the system/sub-system/equipment to which the Safety Case refers, including version numbers and modification status of all requirements, design and application documentation Safety Case Part 2 Quality Management Report This shall contain the evidence of quality management, as specified in 5.2 of this standard. The first condition for safety acceptance that shall be satisfied is that the quality of the system, sub-system or equipment has been, and shall continue to be, controlled by an effective quality management system throughout its life-cycle. Documentary evidence to demonstrate this shall be provided in the Quality Management Report, which forms part 2 of the Safety Case FP7 project # Page 50 of 73