Industrial use cases: Description and business impact D1.2.a Automotive Use Case

Transcription

1 Cllabrative Large-scale Integrating Prject Open Platfrm fr EvlutiNary Certificatin Of Safety-critical Systems Industrial use cases: Descriptin and business impact Autmtive Use Case Wrk Package: WP1: Industrial Use Case Specificatin and Benchmark Disseminatin level: PU Status: FINAL Date: 03 Octber 2012 Respnsible partner: F. Belmnte (Alstm Transprt) Cntact infrmatin: PROPRIETARY RIGHTS STATEMENT This dcument cntains infrmatin, which is prprietary t the OPENCOSS Cnsrtium. Neither this dcument nr the infrmatin cntained herein shall be used, duplicated r cmmunicated by any means t any third party, in whle r in parts, except with prir written cnsent f the OPENCOSS cnsrtium.

2 Names Laurent de la Beaujardière, Fabien Belmnte Fulvi Tagliabò, Albert Melzi Cntributrs Organisatin ALSTOM Transprt CRF Dcument Histry Versin Date Remarks V Template: Cntents f the use cases V First draft versin including wide cverage, with sme incmplete aspects. V First full versin V Ready fr WP review V Ready fr PB review V Apprved by PB FP7 prject # Page 2 f 33

3 TABLE OF CONTENTS EXECUTIVE SUMMARY... 7 REFERENCE DOCUMENTS... 7 GLOSSARY INTRODUCTION SYSTEM DESCRIPTION INDUSTRIAL CASE STUDY ACTORS AND ENVIRONMENT INDUSTRIAL USE CASE OPERATIONAL SCENARIOS MAIN FUNCTIONS PROVIDED BY THE SYSTEM ARCHITECTURE OF THE SYSTEM GENERAL CHARACTERISTICS OF THE SYSTEM DEVELOPMENT LIFECYCLE ACTIVITIES ENGINEERING AND CONFORMITY ASSESSMENT STAKEHOLDERS ACTIVITIES EXECUTED BY STAKEHOLDERS Quality management prcess Safety management prcess Item definitin Safety Plan Technical safety prcess Hazard Analysis and Risk Assessment (HARA) Technical verificatin and cnfirmatin review f HARA Functinal safety cncept Technical safety cncept Hardware and sftware design and system integratin and testing Validity f SEC assumptins and Validatin n vehicle ENGINEERING ENVIRONMENT DESCRIPTION OF THE COMPOSITIONAL APPROACH SUMMARY OF MAIN ARGUMENTS FOR SAFETY RESULTS FROM HAZARD ANALYSIS AND RISK ASSESSMENT (HARA) VERIFICATION REVIEWS VALIDITY VERIFICATION OF ASSUMPTIONS FOR SEOOC VALIDATION (AT SYSTEM LEVEL) CONFIRMATION MEASURES FUNCTIONAL SAFETY AUDITS FUNCTIONAL SAFETY ASSESSMENT IMPACT ANALYSIS CHANGE MANAGEMENT, CONFIGURATION MANAGEMENT AND DOCUMENTATION Change management Cnfiguratin management Dcumentatin management SYSTEM LIFETIME EVENTS SPECIFICATION AND DEFINITION OF THE SYSTEM PLANNING DEVELOPMENT MILESTONES FP7 prject # Page 3 f 33

4 7.4 PRODUCTION OPERATIONS RELATIONSHIP TO CONCEPTUAL AND TECHNICAL WORK PACKAGES AND EXPECTED RESULTS WP4 COMMON CERTIFICATION LANGUAGE WP5 COMPOSITIONAL CERTIFICATION WP6 EVOLUTIONARY EVIDENTIAL CHAIN WP7 TRANSPARENT CERTIFICATION & COMPLIANCE AWARE PROCESS CONCLUSION FP7 prject # Page 4 f 33

5 List f Figures FIGURE 2.1.SCHEMA OF THE EPARK LOCK SYSTEM FIGURE 5.1. EXAMPLE OF AUTOMOTIVE SEOOC USE CASE APPLICATION FIGURE 8.1. AUTOMOTIVE ISO GENERAL SCHEME OF APPLICATION IN OPENCOSS FIGURE 8.2. EXAMPLE OF AUTOMOTIVE SEOOC USE CASE APPLICATION IN OPENCOSS FP7 prject # Page 5 f 33

6 List f Tables TABLE 3.1. ASIL CLASSIFICATION ACCORDING TO ISO FP7 prject # Page 6 f 33

7 Executive summary The dcument reprts the descriptin f an autmtive use case cncerning the develpment f a safety critical system as SEC (Safety Element ut f Cntext- the Cntext is a reference vehicle). The system is the epark: it is the device that cntrls and manages the parking f an electric vehicle. The aim f the dcument is t explain the details f the applicatin f ISO standard during the safety design f the system cncept and t cmplete the descriptin f the standard autmtive requirements applicatin. After the intrductin in Chapter 1, Chapter 2 cntains the descriptin f the system and its schematic representatin, with the main actrs invlved. Then in Chapter 3 a descriptin f the lifecycle activities n the system accrding t the ISO standard is utlined. Chapter 4 reprts an verview abut the actual data management and supprting tls used fr the applicatin f the ISO standard in the cnfrmity assessment prcess fr the autmtive cmpnents. Chapter 5 summarises the cnsidered use case finalizatin as an example f SEC cncept. Chapter 6 is the summary f the main arguments fr safety cnsidered in the entire safety cycle f the system within the ISO standard wrkflw. Chapter 7 briefly summarises the lifecycle events, which are als strictly linked t the safety cycle. Chapter 8 describes the relatinships with the ther wrk-packages in the case f the autmtive dmain fr ISO applicatin. In Chapter 9, the cnclusins are reprted. REFERENCE DOCUMENTS [1] ISO 26262, Rad vehicles Functinal safety [2] ISO 9001, Quality management systems Requirements GLOSSARY AIS Average Injury Scale ASIL Autmtive Safety Integrity Level BPMN Business Prcess Mdel and Ntatin Cntext Reference vehicle FMEA Failure Mdes Effect Analysis FSR Functinal Safety Requirement(s) FTA Fault Tree Analysis HARA Hazard Analysis and Risk Assessment HSI Hardware-Sftware Interface Item System r cmpsitin f systems implementing a functin t which the certificatin/cnfrmity assessment framewrk is applied QM Quality management RC Residual Criticalities SEC Safety Element ut f Cntext SG Safety Gal SS Safe State VCU Vehicle Cntrl Unit FP7 prject # Page 7 f 33

8 1 Intrductin The Autmtive use case presents the epark system fr an electric vehicle. This system is in charge f the management f the park pawl (mechanical engagement) actuatin: this device prvides mechanical lcking f the transmissin when the Parking mde is selected (by the driver r autmatically), aviding unwanted mvement f the vehicle when stpped. The selectin f the Parking mde is actuated by a gear selectr equipped with switches dedicated t the mdes f peratin f the vehicle: Parking (fr the actuatin f the epark functinality and fr setting the electric mtr trque t zer), Drive (fr driving frward), Rear (fr driving backward) and Neutral (idle status and transitins: electric mtr trque set t zer). The system includes specific cmpnents fr the functinality envisaged, made f cnventinal parts (mechanics, electrnics), and is develped as a Safety Element ut f Cntext (SEC), accrding t [1]: ISO Part 10 Clause 9 (SEC Cncept) and Part 2 Clause (Tailring f the Safety Plan fr an element develped separately frm an item). Nte that the SEC cncept under the ISO standard, in general, is the mst suitable way t manage the safety critical systems in the Autmtive dmain, because several parts, in particular the mst innvative, f a vehicle are develped independently frm a specific cntext (vehicle) by the autmakers, r by the suppliers, envisaging t apply them in different types f mdels and versins f vehicles. FP7 prject # Page 8 f 33

9 2 System Descriptin 2.1 Industrial case study actrs and envirnment The system envirnment is cnstituted by the electric vehicle interfaces (mechanical, electrical and electrnic) and nly ne actr is invlved: the driver. The man-machine interface f the vehicle dashbard cmmunicates cntinuusly t the driver the status f the gear shift that he has selected last time and, then, als the parking state, if the case. The cmmunicatin is transmitted by the Vehicle Cntrl Unit (VCU) (see ), which is an electrnic bard in charge f mnitring the cmplete status f the vehicle and, in particular fr this case, the status f the gear shift. The parking actuatin cnsists f a mechanical lck n the vehicle gear. When the vehicle is switched ff, the nly way t alert the driver f the parking actuatin (mechanical) is an acustic alarm (the electrical supply is assured by a direct cnnectin t the 12 V auxiliary battery f the vehicle), whse interventin is triggered when the vehicle dr is pened withut a parking actuatin. 2.2 Industrial use case peratinal scenaris The driver decides t stp the vehicle and, nce he has psitined the vehicle in the desired parking place, he must select the Parking mde (nrmally indicated by a P n the gear shift f an electric vehicle) by the crrespnding switch n the gear shift. The dashbard signals the actual selectin. The driver can pen the dr and leave the vehicle. If the driver des nt select crrectly the Parking mde, the pening f the dr causes an acustic alarm that signals t the driver the uncrrected and dangerus cnditin f the vehicle. 2.3 Main functins prvided by the system The main functin f the epark system is t maintain the transmissin f the electric vehicle blcked, aviding any undesired mtin f the wheels when it is stpped fr parking. This functin f the system is achieved by the management f the park pawl (mechanical engagement) actuatin when the Parking state is entered r exited by the Gear Selectr Mdule lgic (see ), respectively when Parking mde has been selected r deselected by the driver. When the Parking mde is enabled, the trque request sent frm the electrnic Vehicle Cntrl Unit (VCU) t the pwer inverter mdule f the drive train (pwer inverter + electric mtr) is set t zer and the latter is required t remain in trque disabled mde, thus the electric mtr cannt receive any electric current able t make it rtate. When this mde is selected, a request is sent t the lgic f the epark system t engage the park pawl, thus prviding the mechanical lcking f the transmissin. FP7 prject # Page 9 f 33

10 2.4 Architecture f the system The epark system can be cnsidered as cmpsed f the fllwing elements: The epark Cntrl Unit, implementing the high level management lgic; The PRND Switches (Gear Selectr Mdule), implementing the lw level sftware and physically driving the mtr which mves the park pawl; The Parking Lck System, including mainly the park pawl, the mtr fr the actuatin, the mtr psitin sensr and the park pawl psitin sensr. In Figure 1.1 a schematic drawing f its mechanical realisatin is represented. Figure 1.1.Schema f the epark lck system 2.5 General characteristics f the system There are n particular envirnmental cnstraints r perfrmance requirements in terms f actuatin, but the park pawl must be mechanically cnsistent in rder t sustain the blckage f the vehicle als in case f a high degree f rad slpe. The psitin sensrs must be able t guarantee the crrect signalling f the effective actuatin. 3 Develpment Lifecycle Activities 3.1 Engineering and cnfrmity assessment stakehlders The engineering stakehlders are the design team, the prject management team, with a prject manager, and the functinal safety team, with a functinal safety manager. There is n certificatin team, but a cnfrmity assessment team cnstituted by functinal safety assessrs, wh perate at the level f the cnfirmatin reviews and audits f the ISO standard (cnfirmatin measures: see the fllwing and in particular 6.5). FP7 prject # Page 10 f 33

11 3.2 Activities executed by stakehlders Quality management prcess The prject management team (Prject manager and assistants) and the design team (engineers, technical specialists) agree abut the specificatin f the system, based n the main requirements cming frm the market/custmer (represented in a set f dcuments), and abut a general prject plan that cntains the descriptin f the cmplete wrkflw, frm design t implementatin/manufacturing, envisaged fr the system realizatin, accrding t internal general and shared quality requirements that are cmpliant with the ISO 9001 standard [2]. The prject manager signs and cnfirms the prject plan and will be the mnitring stakehlder f the entire wrk prgram. The prject plan is described in an excel dcument with eventually wrd files annexed fr explaining sme technical tpics Safety management prcess A functinal safety manager is appinted by the heads f the main departments invlved in the design team, but he is neither a member f the design team nr the invlved departments. He leads a functinal safety team. The safety manager, in agreement with the safety team, utlines the general safety plan accrding t the specificatin f the system and the related prject plan. The safety manager and the prject manager, cperate fr updating the prject plan, if and when necessary, accrding t the safety activities envisaged in the safety plan. Then the functinal safety manager and the functinal safety team, in cperatin with the design team, wrk n the definitin f the system (item definitin), prviding its descriptin, with regard t its functinality, interfaces, envirnmental cnditins, legal requirements, knwn hazards, etc., based n the analysis f the specificatin and f the peratinal and envirnmental cntext f the system. The bundaries f the item and its interfaces, as well as the assumptins fr a SEC develpment cncerning a reference applicatin cntext, are als determined by this descriptin Item definitin The item definitin is described in a wrd dcument with annexes cntaining tables, drawings and diagrams representing all the relevant characteristics f the system derived frm the fllwing steps: Functinal requirements identificatin (functinal cncept by the cncept design): these cme frm the analysis f the set f dcuments available frm the specificatins f the system and are cllected in a wrd r excel table; the latter cntains in each rw the text descriptin f each requirement, with its item/element f attributin and its identifier (prgressive number in a characteristic label), and the eventual applicable dcuments, if any, frm the system specificatin. Bundary definitin: this is the identificatin f the parts related t the item in the vehicle, distinguishing between the cnstituting parts (e.g. the vehicle cntrl unit) and thse that are nly FP7 prject # Page 11 f 33

12 interfaced (e.g. the gear f the mechanical transmissin); these pieces f infrmatin cme frm the analysis f the specificatins f the system and its applicatin cntext. The infrmatin is gathered in a series f schematic drawings and can be frmatted in a wrd r excel table. Nrmative Requirements and state f the art regulatins cverage: this fllws frm the analysis f the cmpliance with respect t the standards required in the item develpment at the cncept design level, understanding functinal, peratinal, safety and autmtive hmlgatin aspects. This requires the analysis f the cnsidered standards (e.g. technical standards ISO, IEC, SAE,...) (typically pdf files are the matter f the analysis) and prduces: firstly a wrd r excel table fr the classificatin f each applicable standard, with its publishing Cuntry and Agency, its Number, Title and Applicability type (Safety, Functinality, Hmlgatin), and a shrt descriptin f its cntents; secndly, after this classificatin, anther wrd r excel table is prduced reprting the analysis f the cverage in terms f textual cnsideratin, rank f evaluatin (cverage: YES r NOT r Unknwn), reference t the clause number f the standard analysed, including als the related text f each clause, and the reference t ther eventual supprting dcuments frm the specificatin f the system. Assumptins: these cnstitute a fundamental set f additinal requirements fr the SEC cncept and cmplete the item descriptin in terms f definitin (textual) f the characteristics that the epark system must have with respect t the envisaged cntext fr its applicatin (where the envisaged cntext is the electric vehicle in which it shuld be integrated and used) Safety Plan The functinal safety manager and the functinal safety team agree abut the safety plan updating derived frm the previus item definitin. The updated safety plan in an excel dcument that can be integrated r referenced in the prject plan Technical safety prcess The safety prcess starts in parallel t the design prcess, prviding the safety cncepts design derived frm the hazard analysis and risk assessment. This is the mst critical and articulated safety activity fr the cmpliance t the reference standard ISO in the autmtive dmain. The actrs invlved are again the functinal safety manager and the functinal safety team Hazard Analysis and Risk Assessment (HARA) The starting pint at this stage is the Hazard Analysis and Risk Assessment (HARA). It is based n the item definitin and its bjective is t identify and t classify the hazards that ptential malfunctins in the item can trigger and t frmulate the safety gals related t the preventin r mitigatin f the hazardus events, in rder t avid unreasnable risks; the hazards are determined systematically at item level, by using adequate techniques fr safety analyses (brainstrming, checklists, quality histry, FMEA, FTA...); FP7 prject # Page 12 f 33

13 hazards are defined in terms f the cnditins r behaviurs that can be bserved at the vehicle level and are classified as Autmtive Safety Integrity Level (ASIL), in a scale frm A t D. The parameters fr the risk determinatin and the ASIL classificatin are the fllwing: Cntrllability [C]: ability t avid a specified harm r damage thrugh the timely reactins f the persns invlved, pssibly with supprt frm external measures. Expsure time [E]: state f being in an peratinal situatin that can be hazardus if cincident with the failure mde under analysis. Severity [S]: estimate f the extent f harm t ne r mre individuals that can ccur in a ptentially hazardus situatin. The Table 1.1 resumes the schema f the ASIL classificatin: the ASIL values range frm A t D, in a scale f increasing risk; QM (Quality Management) is an attribute defined additinally fr a class that des nt require cmpliance with ISO Cntrllability Expsure time Severity Table 1.1. ASIL classificatin accrding t ISO The hazard analysis and risk assessment is articulated in the fllwing steps: Analysis f the perating cnditins f the item in rder t identify the mst relevant scenaris fr the safety: this is recrded in a wrd r excel table. Analysis and identificatin f the pssible malfunctins (using FMEA and FTA): this prduces a wrd r excel table that cntains the descriptin f the identified malfunctins, with a prgressive number in a characteristic label. List f the hazards derived frm the identified malfunctins (using FMEA and FTA): this prduces a wrd r excel table cntaining the list f the hazards caused by the malfunctins previusly identified, each referred t the crrespnding malfunctin and identified by a prgressive number in a prper characteristic label. Analysis f the ptentially hazardus events by ranking the relative Cntrllability, Severity, Expsure parameters (the hazardus events are thse defined n the basis f the previusly utlined scenaris and hazards and eventual external measures cnsidered, the latter intended as ther FP7 prject # Page 13 f 33

14 systems/elements f ther technlgical slutins invlved fr hazards mitigatin): this analysis allws the determinatin f the level f risk in terms f ASIL, based n the classificatin f the Table 1.1, and prduces again a wrd r excel table, where the severity rank attributin is based n a cmparisn with tables f Average Injury Scale (AIS: e.g. values frm 1 t 6 frm internal classificatin Severity 1 t 3 f ISO generic severity definitin), derived frm in-huse reserved data and dcumentatin, while the cntrllability and expsure ranks attributin is based n testing and ther in-huse reserved data and dcumentatin. Risk Assessment (ASIL definitin fr each hazardus event): this prduces a wrd r excel table that reprts the classified hazards (with identifier, descriptin and related malfunctin) and the textual descriptin f the cnsequent hazardus event with the assciated maximum ASIL (ranked frm A t D, increasing the risk, r QM, Quality Management, in case there is n safety relevance). Frmulatin f the safety gal fr each hazard cnsidered as safety relevant [ASIL > QM - See Table 1.1)]; mrever, a safe state t be maintained r reached has t be identified, in rder t declare the actin(s) t perfrm t ensure aviding the pssibility that the cnsidered failure culd vilate that safety gal; the results are summarised in a wrd r excel table that again cntains the hazards descriptin, but referenced t the safety gal: the latter is described in a textual frmat, tgether with its assciated safe state, and is identified by a prgressive number in a prper characteristic label; if there is n safety relevance (QM: Quality Management), n safety gal and n safe state have significance. The hazard analysis and risk assessment activity, then, prduces the safety gals that, finally, are the tplevel safety requirements allcated t each element f the item: safety gals are nt expressed in terms f technlgical slutins, but in terms f functinal bjectives, and are determined fr each hazardus event with the crrespnding ASIL evaluated in the hazard analysis. The hazard analysis and risk assessment activity results, as previusly described step by step, are integrated in a Risk Assessment reprt (as a wrd r excel file) describing in a summary table all the previus utlined cntents: frm the clumns reprting the hazards descriptins, with their identifiers and the crrespnding causing malfunctins, the table is develped up t the clumns reprting the safety gals descriptins, with their identifiers and assciated safe states, and the final clumns describing the hazardus events with the related ASILs; an additinal clumn is als prvided with the descriptin f the eventual external measures cnsidered and invlved fr the safety. This table, fr better understanding and fr verificatins, cnfirmatin measures and audits purpses, is assciated t annexed files in varius frmats (wrd, excel, diagrams and drawings) representing the detailed results f the safety analyses perfrmed (e.g. FMEA, FTA) Technical verificatin and cnfirmatin review f HARA The hazard analysis and risk assessment results, tgether with the safety gals results, are subjected t a technical verificatin (verificatin review) and t a frmal verificatin (cnfirmatin review). The latter is perfrmed by persns independent frm the design team, prject manager and prject management team, functinal safety manager and functinal safety team, and wh are the functinal safety assessrs in a FP7 prject # Page 14 f 33

15 cnfrmity assessment team. Bth the verificatin and the cnfirmatin activities prduce each a specific reprt (wrd dcument with annexes), that allws t cnstitute the safety case and are part f the dcumentatin required fr the functinal safety assessment Functinal safety cncept The functinal bjectives expressed with the safety gals lead t the definitin f the functinal safety requirements in the design f the system t avid an unreasnable risk fr each hazardus event. The functinal safety requirements cnstitute all the requirements n the design aimed at achieving and ensuring the required ASILs and are allcated t the elements f the preliminary architectural assumptins (they inherit the ASIL f the crrespnding safety gals). The functinal safety requirements cnstitute the functinal safety cncept that is part f the functinal design in prgress. In the case f the epark system, as in ther quite cmplex and safety critical systems n the vehicle, a further deplyment f the safety gals related t hazardus events, identified with the previus analyses, has t be perfrmed. In particular, even if fr each safety gal and applicable safe state at least ne safety requirement has been specified, nevertheless in rder t develp a cmplete set f effective functinal safety requirements and a cmplete functinal safety cncept, an ASIL decmpsitin has t be perfrmed, ging thrugh the elements f the system fr the identificatin and analysis f all cmmn causes f failure and single pints f failure where necessary. Mrever the architectural elements f the epark system are sufficiently independent t allw this kind f decmpsitin, fulfilling als the cnditins t apply redundantly the safety requirements, by the analysis f the functinal redundancies (accrding t ISO Part 9 Clause 5) and the analysis f the faults and failures prpagatin thrugh the elements fr each hazardus event. ASIL DECOMPOSITION The ASIL decmpsitin in this case is applied at functinal level and des nt require a revisin f the functinal safety cncept, because it cntributes directly t the definitin f this cncept. This analysis allcates the functinal requirements t the elements f the system again by means f safety analysis techniques. FUNCTIONAL SAFETY REQUIREMENTS ALLOCATION After the ASIL decmpsitin, all the functinal safety requirements are assigned t the relevant cmpnents. Several functinal safety requirements can be aggregated fr each cmpnent, which will inherit the maximum ASIL frm them. Each functinal safety requirement fr each cmpnent is detailed assciating it, fr traceability requirements, t: Hazard (Hazard name), Safety Gal (SG), Safe State (SF), ASIL (Autmtive Safety Integrity Level), and RC (Residual Criticalities), External cnstraints and Cnstraints fr assembly FP7 prject # Page 15 f 33

16 The External cnstraints and Cnstraints fr assembly prvides infrmatin already useful fr the future prductin phase (The planning fr prductin and peratin, and the specificatin f the assciated requirements, starts during the prduct develpment at the system level, after the prvisin f the release fr prductin reprt: ISO Part 4; the requirements fr prductin and peratin are given in ISO Part 7, Clauses 5 and 6). At this stage a Verificatin review and a Cnfirmatin review f the safety analyses are required: the first is the technical review f the safety analyses, while the secnd is a frmal evaluatin f the crrect executin f the safety analyses; bth can identify faults r inadequate safety requirements that can lead t the vilatin f a safety gal. The Cnfirmatin review is perfrmed again by persns independent frm the design team, prject manager and prject management team, functinal safety manager and functinal safety team, and wh are the functinal safety assessrs in a cnfrmity assessment team. The cnfirmatin activity prduces a specific reprt (wrd dcument with annexes), that allws t cnstitute the safety case and is part f the dcumentatin required fr the functinal safety assessment The functinal safety cncept is then cmpleted and, after that, a technical verificatin f the functinal safety cncept is executed by the functinal safety manager, prducing a specific reprt (wrd dcument with annexes), that allws t cnstitute the safety case and is part f the dcumentatin required fr the functinal safety assessment Technical safety cncept After having specified and verified its functinal safety cncept, the epark system is develped frm the system level perspective, as given in ISO Part 4. The system develpment prcess at this stage, accrding t ISO 26262, cntinues based n the cncept f a V-mdel with the specificatin f the technical safety requirements, the system architecture, the system design and implementatin n the left hand branch and the integratin, verificatin, validatin and the functinal safety assessment n the right hand branch. The actrs invlved during the system design develpment are again the prject manager and the design team, wrking nw at system level, while, during the technical safety cncept definitin, the stakehlder are the functinal safety manager and the functinal safety team in cperatin with the design team, fr the technical safety requirements definitin Hardware and sftware design and system integratin and testing The technical safety requirements f the epark system frm the technical safety cncept are implemented as safety mechanisms, sftware slutins and safety requirements n the elements in the stages f hardware and sftware develpment. Then the elements are integrated and tested at varius levels frm hardware and sftware levels, t the system level and finally t the vehicle level. The testing phase is planned and executed. The system ges n the shelf, available fr the intended vehicle applicatins. FP7 prject # Page 16 f 33

17 Validity f SEC assumptins and Validatin n vehicle T establish the validity f the assumptins is necessary t demnstrate that the epark develped n the shelf as SEC is cnsistent with the requirements in the cntext (vehicle) where it is intended t be used, with reference t the previus item definitin (see ). The epark is a cmplex system and the validity verificatin f its assumptins applies at the end f its cmplete hardware and sftware develpment and integratin (but in sme ther cases f simple SEC, like hardware single cmpnents, e.g. micrcntrller r sftware mdules, the validity verificatin applies befre the level f system integratin and is perfrmed at the hardware r sftware level crrespndingly). If the validity f the assumptins made during the SEC develpment cannt be established during its integratin int the vehicle, a change t the SEC is made (ISO Part 8, Clause 8: Change Management See 6.9). The validity f the assumptins is established prducing a reprt. Befre the final functinal safety assessment, a Validatin f the system integrated n the vehicle is perfrmed (see 6.4) with the aim t assure, by examinatin and tests, that the safety gals are sufficient and have been achieved. The Validatin prduces a reprt. All the ther main arguments fr safety and lifecycle events that fllw accrding t ISO26262, nt directly cnsidered and available in the previus descriptins fr the epark system, are reprted fr cmpleteness (tgether with thse already described) in a general verview, respectively in Chapter 6 and Chapter 7, cnsidering that change management (and cnfiguratin management) and dcumentatin culd impact all these aspects when the SEC assumptins were shwn t be invalid. FP7 prject # Page 17 f 33

18 4 Engineering Envirnment The management f the dcument is cmpliant with ISO 9001 by an in-huse rganized practice. The safety relevant dcuments are mainly cnstituted by wrd and excel files and are the utput f the activities accrding t ISO A basic practice still in prgress t manage the cllectin and the relatinships f the safety lifecycle activity results is the BPMN 2.0 language with the ADONIS tl. This is a way in rder t maintain evidence f the safety prcess wrkflw and its results and their relatins with the design and the cnfrmity assessment teams. The tl can prvide a cmplete descriptin f the verall ISO safety cycle f the systems and f the SEC like in the use case: The OPENCOSS platfrm culd prvide the way f applying the cmpsitinal and evlutinary apprach thrugh change management, traceability and tailring f the safety lifecycle, assuring the integratin f the prven in use argument methdlgy, as well as the hardware cmpnents and sftware cmpnents qualificatin prcesses and, finally, the SEC cncept applicatin. ISO prvides the structure(s), the flw(s), the mdel(s) t which the implementatin in the platfrm f these methdlgies, prcesses and cncepts culd be matched. BPMN 2.0 with ADONIS can ffer the basic representatin f these structure(s), flw(s) and mdel(s) frm the general framewrk f ISO The OPENCOSS platfrm culd prvide the integratin f these structures(s), flw(s) and mdel(s), and hw apply change management and traceability, taking int accunt als the dcumentatin management prcess. 5 Descriptin f the Cmpsitinal Apprach The system cnsidered as SEC, mre specifically, des nt reuse cmpnent frm ther cntexts, but is itself a cmpnent reusable fr varius cntexts. The epark system is an example f an SEC applicatin, fr which the safety is assured by a clsed lp in ISO 26262: a list f assumptins t be used fr the applicatin f the system in new cntexts is utlined as a part f the item definitin (see ) and this list will be verified during the integratin f the system in the vehicle. If the assumptins are shwn t be invalid, the impact analysis and the related cnfiguratin management and change management wrkflws will supprt the further mdificatins f the varius safety wrk prducts fr the envisined aims. The SEC can be viewed as a cmplementary way with respect t that f the prven in use argument: the secnd is a new element derived frm a knwn and tested cntext (vehicle) and has t be integrated in a different cntext (vehicle), while SEC is a knwn system (n the shelf) fr an assumed cntext (vehicle) in which it shuld be integrated, nce the initial assumptins wuld be shwn. FP7 prject # Page 18 f 33

19 The epark system is a safety element ut f cntext in the sense that it is nt develped fr a defined electric vehicle, but it is assumed t be cmpliant t certain characteristics f an electric vehicle fr its applicatin (the assumptins). These characteristics are related t the vehicle maximum speed, weight and available sensrs signals, and with respect t the electric/electrnic basic interface f the dashbard and t the mechanical interface f the transmissin. All the vehicles which have the suitable characteristics within a certain limited range (e.g. vehicle speed and weight under a certain maximum value, sme standard interfaces fr sensr signals and cmmunicatin data, value f mechanical strength f parking pawl) can integrate this system after the verificatin f the assumptins. In the fllwing Figure 1.2 a schematic detail f an example fr the SEC applicatin is reprted, derived frm the previus Errr! Reference surce nt fund.. Figure 1.2. Example f autmtive SEC use case applicatin FP7 prject # Page 19 f 33

20 6 Summary f main arguments fr safety The main arguments fr arguing the safety f the item, accrding t ISO 26262, are related t: Hazard Analysis and Risk Assessment Prduces requirements fr safety design specificatins at hardware, sftware and system level Verificatin reviews Supprting Prcesses. Requires a plan and prduce reprts Validity verificatin f assumptins fr SEC while integrating int the applicatin cntext (reference vehicle) Activity with a reprt as utput (see and 6.3) Validatin at system (vehicle) level Main Prcess; requires a plan and prduces a reprt Cnfirmatin measures: Cnfirmatin reviews and Functinal Safety Audits External reviews; prduce reprts Functinal Safety Assessment: final audit cmpiling all the safety arguments, cllected as the safety case, and the verificatin reviews, the validatin(s) and the cnfirmatin measures Main Prcess; requires a plan and prduces a reprt. Each argument is detailed in the fllwing subsectins Additinally, during the safety cycle the fllwing actins/prcesses are perfrmed when necessary, impacting and managing the arguments fr safety: Impact analysis Activity with a reprt as utput Change management Supprting Prcess; requires a plan at the input Cnfiguratin management ( wrk prducts traceability) Supprting Prcess; requires a plan Dcumentatin (management) Supprting Prcess; requires a plan Impact analysis and Change management are linked tgether. Impact analysis is the analysis after mdificatins t the system. Change management ensures the systematic planning, cntrl, mnitring, implementatin and dcumentatin f changes. Cnfiguratin management. is the general supprting prcess that identifies uniquely the wrk prducts and ensures that the relatins and differences between earlier and current versins f them can be traced (traceability). Dcumentatin (management) is the general supprting prcess that manages the entire safety cycle dcuments. Change management, Cnfiguratin management and Dcumentatin (management) are each subjected t a Functinal safety audit. 6.1 Results frm Hazard Analysis and Risk Assessment (HARA) The Hazard analysis and Risk Assessment prduces the safety gals (see paragraph ), which are the basis fr the implementatin f the technical safety requirements (leading t the safety mechanisms, safety measures, safety slutins in the technical safety cncept that have t be realized, designed, integrated and tested at system level) derived frm the functinal safety requirements (functinal safety cncept) defined by the risks assessed thrugh the ASILs prcessing and ranking after the hazards analysis. FP7 prject # Page 20 f 33

21 The wrk flw f these analyses and definitins is detailed up t the hardware and sftware levels, in which the safety mechanisms, safety measures and slutins are parts f the hardware and sftware designs, starting frm the hardware and sftware requirements specifically derived frm the technical safety requirements applied at hardware and sftware levels. 6.2 Verificatin reviews They are the applicatin f the supprting Verificatin Prcess which aims t ensure that the wrk prducts f the safety cycle cmply with their requirements and which is applied t the fllwing phases f the safety lifecycle: In the cncept phase: the verificatin review ensures that the cncept is crrect, cmplete and cnsistent with respect t the bundary cnditins and that the defined bundary cnditins themselves are crrect, cmplete and cnsistent, s that the cncept can be realised In the prduct develpment phase, the verificatin review is cnducted in different frms, as described belw: in the design phases: verificatin is the evaluatin f the wrk prducts, such as requirement specificatin, architectural design, mdels r sftware cde, thus ensuring that they cmply with previusly established requirements fr crrectness, cmpleteness and cnsistency; evaluatin can be perfrmed by review, simulatin r analysis techniques. The evaluatin is planned, specified, executed and dcumented in a systematic manner; design phases are ISO Part 4, Clause 7 (System design), ISO Part 5, Clause 7 (Hardware design), ISO Part 6, Clause 7 (Sftware architectural design) and ISO Part 6, Clause 8 (Sftware unit design and implementatin) in the test phases: verificatin is the evaluatin f the wrk prducts within a test envirnment t ensure that they cmply with their requirements; the tests are planned, specified, executed, evaluated and dcumented in a systematic manner In the prductin and peratin phases, the verificatin review ensures that: the safety requirements are apprpriately realised in the prductin prcess, user manuals and repair and maintenance instructins the safety-related prperties f the item are met by the applicatin f cntrl measures within the prductin prcess The Verificatin reviews are transversal technical verificatins which g thrugh the analysis f the results achieved during the safety lifecycle activities, applying firstly t the Hazard Analysis and Risk Assessment and, subsequently, t the ther tpic pints f the ISO standard prducing a reprt fr each tpic in the sequence given in the fllwing, with the aim f prviding evidence fr the cmpliance and cnsistency f each tpic with respect t its safety scpe: Verificatin review reprt f Hazard Analysis and Risk Assessment and Safety Gals Verificatin review reprt f the Functinal Safety Cncept Verificatin review reprt f Technical Safety Requirements (system verificatin reprt) Verificatin review reprt f System design (system verificatin reprt updated) Verificatin review reprt f hardware safety requirements Verificatin review reprt f hardware design FP7 prject # Page 21 f 33

22 Verificatin review reprt f results f the hardware architectural metrics applied Verificatin review reprt f evaluatin f the effectiveness f the architecture f the item t cpe with the randm hardware failures Verificatin review reprt f evaluatin f safety gal vilatins due t randm hardware failures Verificatin review reprts f sftware (the verificatin activity abut sftware is planned, specified and prgressively updated during sftware develpment, accrding t ISO Part 6: safety requirements, hardware-sftware interface, architectural design, implementatin) Verificatin review reprt f qualificatin f the applicable sftware tls Verificatin review reprt f hardware cmpnent qualificatin Verificatin review reprt f sftware cmpnent qualificatin Verificatin review reprt f safety analyses 6.3 Validity verificatin f assumptins fr SEC The develpment f an SEC invlves making assumptins n requirements f its crrespnding phase in ISO vehicle safety lifecycle. These assumptins are related t SEC use with respect t a reference vehicle cntext and the crrespnding external interfaces and are verified during integratin f the system (epark in this use case) int the actual vehicle. An SEC is thus develped based n assumptins n an intended functinality, use cntext, including external interfaces. These assumptins are set up in a way that addresses a superset f vehicles, s that the SEC can be used in multiple different but similar vehicles later. Finally, during the actual vehicle develpment, the validity verificatin f SEC requires that: the validity f the assumed requirements and the ther assumptins, e.g. assumptins n the design external t the SEC, are established; examinatin and tests demnstrate that the develped SEC is cnsistent with the requirements in the cntext where it is intended t be used. 6.4 Validatin (at system level) The Validatin is the transversal assurance at system level with the aim t validate, by examinatin and tests, the safety gals f the system in relatin t the vehicle cntext, based n the fllwing: Cntrllability [Cntrllability can be validated using perating scenaris, including intended use and freseeable misuse] Effectiveness f safety measures fr cntrlling randm and systematic failures Effectiveness f the external measures Effectiveness f the elements f ther technlgies The Validatin is planned at the beginning f prduct develpment at system design level. Then, it is updated after the definitin f the technical safety requirements and, finally, prduces a reprt. FP7 prject # Page 22 f 33

23 6.5 Cnfirmatin Measures The Cnfirmatin Measures (cnfirmatin reviews and audits) are transversal reviews that aim t check the cmpliance f selected wrk prducts crrespnding t the requirements f the ISO reference standard. The cnfirmatin measures are frmal reviews f the main steps and related wrk prducts f the ISO lifecycle. Their scpe is t evaluate the system s achievement f functinal safety, including a cnfirmatin f: the prper definitin, tailring and executin f the safety activities perfrmed during the system develpment and f the implemented safety prcesses, with regard t the ISO requirements; the prper cntents f the wrk prducts with regard t the crrespnding ISO requirements. They are perfrmed fr thse wrk prducts that are specified in ISO Part 2 (Clause Table 1) and required by the safety plan; each cnfirmatin review includes the checking f crrectness with respect t frmality, cntents, adequacy and cmpleteness regarding the requirements frm the standard; the cnfirmatin reviews and audits are the fllwing: Cnfirmatin review f the hazard analysis and risk assessment Cnfirmatin review f the safety plan Cnfirmatin review f the safety analyses Cnfirmatin review f the qualificatin f sftware tls Cnfirmatin review f the prven in use arguments f the candidates, if applicable Cnfirmatin review f the item integratin and testing plan(s) Cnfirmatin review f the validatin plan Cnfirmatin review f the cmpleteness f the safety case Functinal safety audits (applied t supprting prcesses) (see 6.6) Functinal safety assessment audit (see 6.7) [ Each f them prduces a reprt] The cnfirmatin measures intrduce the criteria f independence between the actrs f the safety assessment in functin f the ASIL f the system: the standard requires specific levels f independence between the persn respnsible fr the cnfirmatin measure executin and the department respnsible fr the cnsidered wrk prduct(s) regarding management, resurces and release authrity. The cnfirmatin measures are perfrmed in accrdance with the required level f independence (accrding t ISO Part 2, Clause Table 1). Functinal safety audits fr supprting prcesses and Final Functinal safety assessment audit, described in the fllwing, are als cnfirmatin measures. FP7 prject # Page 23 f 33

24 6.6 Functinal Safety Audits The Functinal Safety Audits are evaluatins addressing the implementatin f the functinal safety prcesses, cnsidering the executin f them, with respect t the definitins f the activities referenced r specified in the safety plan. The Functinal safety audits prduce reprts fr: Cnfiguratin management prcess Distributed develpment management prcess (in case f supplier) Change management prcess Verificatin prcess Dcumentatin prcess Qualificatin f SW cmpnents Qualificatin f HW cmpnents 6.7 Functinal Safety Assessment The functinal safety assessment applies at vehicle level: it must be planned (i.e. its agenda must be defined) and it applies t the highest ASIL amng the safety gals f the item; independence with regard t the develpers f the item and prject management is required; it cnsists mainly n the fllwing: Evaluatin f the cmpliance f the wrk prducts required by the safety plan with the crrespnding requirements f ISO 26262, including but nt limited t the wrk prducts that require a cnfirmatin review; the results f the cnfirmatin reviews are als cnsidered Evaluatin f the implementatin f the functinal safety prcesses, cnsidering the results f the perfrmed functinal safety audit(s) A review f the apprpriateness and effectiveness f the implemented safety measures that can be assessed during the item develpment Fllw-up f the recmmendatins resulting frm the previus functinal safety assessments, including any perfrmed crrective actins, if applicable Fr each step f the safety lifecycle the specific tpics t be addressed by the functinal safety assessment shall be identified. [The functinal safety assessment shall be cnducted in accrdance with ISO Part 2, clause (Functinal safety assessment)] A functinal safety assessment reprt shall include a recmmendatin fr acceptance, cnditinal acceptance, r rejectin f the functinal safety f the item. In the case f cnditinal acceptance: a) cnditinal acceptance shall nly be given if the functinal safety f the item is cnsidered evident, despite the identified pen issues; b) the recmmendatin fr cnditinal acceptance shall include the deviatins frm the functinal safety assessment criteria and the ratinales as t why the specific deviatins are cnsidered acceptable. FP7 prject # Page 24 f 33

25 If the recmmendatin in a functinal safety assessment reprt is a cnditinal acceptance f the achieved functinal safety, the crrective actins prvided in the functinal safety assessment reprt shuld be carried ut. If the recmmendatin in a functinal safety assessment reprt is a rejectin f the achieved functinal safety, then: a) adequate crrective actins shall be initiated b) the functinal safety assessment shall be repeated The Functinal safety assessment dcumentatin cnsists f: Definitin f the Safety Case: the safety case is the prgressive cmpilatin f the wrk prducts f the ISO standard that are generated during the safety lifecycle executin Safety plan (last refined) Functinal safety assessment plan (last refined) Cnfirmatin measures reprts (cnfirmatin review reprts and audit reprts) The Functinal safety assessment is subject t an audit in the framewrk f the cnfirmatin measures. It is the frmal independent analysis f the functinal safety assessment prcess, prducing a final reprt. 6.8 Impact Analysis The Impact Analysis is the analysis after mdificatins t the system (design, implementatin, envirnment...). Mdificatins t the envirnment f the system can result frm the installatin f the system in a new target envirnment (e.g. anther vehicle variant) r by the upgrading f ther cmpnents r elements interacting with (r in the vicinity f) the system. The implicatin f the mdificatin with regard t functinal safety are identified and described in a reprt: The affected wrk prducts that need t be updated are identified and rewrked The safety activities are tailred in accrdance with the applicable lifecycle phases (the tailring is based n the results f the impact analysis) The results f tailring are included in the safety plan (ISO Part2) 6.9 Change Management, Cnfiguratin management and Dcumentatin The wrk prducts required in the safety plan are subject t cnfiguratin management, change management and dcumentatin management, in accrdance with ISO Part 8 (Clauses 7, 8 and 10 respectively), n later than the time f entering the phase prduct develpment at system level in the V schema f the safety cycle. FP7 prject # Page 25 f 33

26 6.9.1 Change management This prcess aims t analyse and cntrl changes t safety-related wrk prducts thrughut the safety lifecycle: the change management ensures the systematic planning, cntrl, mnitring, implementatin and dcumentatin f changes, while maintaining the cnsistency f each wrk prduct. Ptential impacts n functinal safety are assessed befre changes are made; fr this purpse decisin-making prcesses fr change are intrduced and established and respnsibilities are assigned t the parties invlved; cnfiguratin management and change management are initiated at the same time: interfaces between the tw prcesses are defined and maintained t enable the traceability f changes. The wrk prducts t be subject t change management are identified and include thse wrk prducts required by ISO t be placed under cnfiguratin management. The change management prcess includes: Change request: a unique identifier is assigned t each change request; as a minimum, every change request includes the fllwing infrmatin: the date the reasn fr the requested change the exact descriptin f the requested change the cnfiguratin n which the requested change is based Change request analysis: an impact analysis n the system invlved, its interfaces and cnnected elements, are carried ut fr each change request and the fllwing tpics are addressed: the type f change request (pssible types f changes include: errr reslutin, adaptatin, enhancement, preventin) the identificatin f the wrk prducts t be changed and the wrk prducts affected (Each change t wrk prducts initiates the return t the applicable phase f the safety lifecycle) the identificatin and invlvement f the parties affected (in the case f a distributed develpment) the ptential impact f the change n functinal safety the schedule fr the realisatin and verificatin f the change Change request evaluatin: the change request is evaluated using the results f the impact analysis (see 6.8) in cmpliance with the abve analysis and a decisin regarding acceptance, rejectin r delay is made by the authrized persns (Fr each accepted change request it is decided wh carries ut the change and when the change is due; this decisin cnsiders the interfaces invlved in carrying ut the change request) Dcumenting the change: the change must be verified as planned (If the change has an impact n safety-related functins, the assessment f functinal safety and the applicable cnfirmatin reviews are updated befre releasing the item]; the dcumentatin f the change cntains the fllwing infrmatin: the list f changed wrk prducts at an apprpriate level including cnfiguratins and versins (reference t cnfiguratin management plan) the details f the change carried ut the planned date fr the deplyment f the change FP7 prject # Page 26 f 33

27 In the case f a rejected change request, the change request and the ratinale fr the rejectin are als dcumented Cnfiguratin management This prcess aims: t ensure that the wrk prducts, and the principles and general cnditins f their creatin, can be uniquely identified and reprduced in a cntrlled manner at any time t ensure that the relatins and differences between earlier and current versins can be traced (Each wrk prduct f ISO is managed by cnfiguratin management) It is maintained thrughut the entire lifecycle Dcumentatin management The primary bjective is t develp a dcumentatin management strategy fr the entire safety lifecycle in rder t facilitate an effective and repeatable dcumentatin management prcess. The prcess is funded n the fllwing main steps: Dcumentatin planning: the dcumentatin prcess is planned in rder t make dcumentatin available: a) during each phase f the entire safety lifecycle fr the effective cmpletin f the phases and verificatin activities [The identificatin f a wrk prduct in ISO shall be interpreted as a requirement fr dcumentatin cntaining the infrmatin cncerning the results f the assciated requirements; NOTE: the dcumentatin can be in the frm f a single dcument cntaining the cmplete infrmatin fr the wrk prduct r a set f dcuments that tgether cntain the cmplete infrmatin fr the wrk prduct] b) fr the management f functinal safety c) as an input t the functinal safety assessment Dcumentatin structuring: a suitable guideline f dcumentatin shuld be defined in rder t guarantee the prper identificatin, maintainability, change histry, traceability f each dcument (ISO Part 8, Clauses frm t ) FP7 prject # Page 27 f 33

28 7 System lifetime events The lifetime events during the develpment f an autmtive system are strictly linked t the ISO standard, therefre they are mainly summarised in relatin t the safety cycle steps. In the fllwing list, anyway, a summary trace is reprted, adding mre in details the events fllwing the release fr prductin. 7.1 Specificatin and Definitin f the system These events are the starting milestnes: the specificatin cmes frm the cmmitment and the definitin encmpasses what is already described abut the item definitin accrding t ISO (see ). 7.2 Planning This peratin utlines the entire realizatin prcess f the prduct cnsidering the functinal/manufacturing and safety issues thrugh: Definitin f the prject plan Definitin f the safety plan and related revisin f the prject plan Bth plans will be revised during the lifecycle and safety cycle implementatin accrding t the needs t be cmpliant with ISO standards and t the quality standards. 7.3 Develpment Milestnes The milestnes during the develpment are the steps t be achieved during the executin f the prject plan and the safety plan. Hereafter the mst significant nes are listed: Start f HARA Start f Design End f Design (start f HW/SW executin) End f Prttype develpment (start f functinal testing) n bench End f Prttype testing n bench Validatin f assumptins fr SEC while integrating n the applicatin cntext (reference vehicle) Integratin n vehicle (after the verificatin f the assumptins) Cnfrmity and Functinal safety assessment at vehicle level Release fr prductin (at vehicle level) 7.4 Prductin During this phase a prductin prcess is develped and maintained. In the cntext f ISO 26262, the bjective is t achieve functinal safety during the cmplete prductin prcess. FP7 prject # Page 28 f 33

29 The cmpliance with safety-related special characteristics f systems r elements during their prductin, determined during the develpment phases, is necessary t achieve the functinal safety. Examples f such safety-related special characteristics are specific prcess parameters (e.g. temperature range r fastening trque), material characteristics, prductin tlerance r cnfiguratin. This phase defines requirements ensuring that functinal safety is achieved during the prductin prcess by including these safety-related special characteristics in the prductin planning and cntrl. Prerequisites and supprting infrmatin fr this phase: requirements specificatin fr prductin, peratin, service and decmmissining in accrdance with ISO Part 4, Clause and ISO Part 5,Clause specificatin f dedicated measures fr hardware in accrdance with ISO Part 5, Clause release fr prductin reprt in accrdance with ISO Part, Clause prductin plan prductin cntrl plan The prductin phase is characterized by the fllwing requirements accrding t ISO 26262: Safety planning in prductin: safety related cntents f the prductin plan resulting frm the prductin steps, sequence and methds (tgether with the necessary test equipment, tls and test criteria) required t achieve the functinal safety f the system. Safety planning in prductin cntrl: safety related cntents f the prductin cntrl plan (prcess failures ccurring during prductin (including deviatin f safety-related special characteristics frm their authrised range) and their ptential effects n functinal safety are analysed, the apprpriate measures are taken and their ability t maintain functinal safety is verified; the test equipment is subject t cntrl f mnitring and measuring devices). Cntrl measures reprting: the cntrls are perfrmed in accrdance with the prductin cntrl plan and the related cntrl reprt includes the fllwing infrmatin: the cntrl date, the identificatin f cntrlled bject and the cntrl results. Safety requirements n prductin (prduct level): the system, hardware and sftware develpment level safety requirements related t the prducibility f the system, arising during prductin planning, are specified and directed t the persns respnsible fr the develpment (ISO Part 4, ISO Part 5 and ISO Part 6) Prductin prcess assessment: differences between pre-prductin prcess and target prductin prcess are analysed in rder t identify which part f the prductin prcess can be assessed at the pre-prductin stage and fr which part f the target prductin prcess an assessment will be required; the capability f the fllwing shall be assessed and maintained with regard t functinal safety: a) prductin prcess b) means f prductin c) tls and test equipment FP7 prject # Page 29 f 33

30 7.5 Operatins This phase encmpasses the fllwing sub-phases: Service (Maintenance and Repair): related t the custmer assistance. Decmmissining: end f the lifecycle f the system (vehicle). Accrding t ISO the bjective f the first sub-phase is t specify the custmer infrmatin, maintenance and repair instructins, as well as disassembly instructins regarding the system fr the service, in rder t maintain the functinal safety ver the lifecycle f the vehicle. This includes the prvisin f requirements fr develping repair instructins and related user infrmatin, fr prducing the user manual and the planning, executing and mnitring f the maintenance wrk, taking int accunt the safety related special characteristics f the system. During decmmissining, the phases befre disassembling, disassembling and after disassembling can be distinguished. ISO addresses nly thse activities befre disassembling. The decmmissining instructins describe the activities and measures t be applied befre disassembly, and required t prevent the vilatin f a safety gal during disassembling, handling r decmmissining f the vehicle (e.g. instructins fr the deactivatin f airbags befre the disassembly f the vehicle t avid harm t the decmmissining persnnel). FP7 prject # Page 30 f 33

31 8 Relatinship t cnceptual and technical wrk packages and expected results Errr! Reference surce nt fund. represents the main relatinships between the autmtive dmain pint f view by ISO and the OPENCOSS platfrm implementatin. Figure 1.3. Autmtive ISO general scheme f applicatin in OPENCOSS 8.1 WP4 Cmmn Certificatin Language Frm the pint f view f the Autmtive dmain, the ISO standard is the basic framewrk f what is intended mst prperly as cnfrmity assessment structure and encmpasses the verall prcess fr achieving such cnfrmity assessment. The Cmmn Certificatin Language shuld prvide the way fr implementing the mdelling f this prcess and the safety case relatinships amng the wrk prducts f the ISO standard. 8.2 WP5 Cmpsitinal Certificatin The cmpsitinal certificatin accrding t ISO is prvided thrugh specific wrk prducts f the standard such as: prven in use argument, qualificatin f hardware cmpnent, qualificatin f sftware cmpnent and, finally and mainly, by the SEC (Safety Element ut f Cntext) cncept. The latter, in FP7 prject # Page 31 f 33

32 particular, shuld be implemented in the scpe f WP5, integrating the specific requirement f SEC in the Cmmn Certificatin Language accrding t WP4. The use case frm the autmtive dmain in this dcument is an applicatin f the SEC cncept. In Figure 1.4 the detailed view f an example fr the SEC safety cncept applied within the OPENCOSS platfrm is represented, accrding t the general scheme f previus Figure 1.3 and the SEC scheme n Figure 1.2. Figure 1.4. Example f autmtive SEC Use Case applicatin in OPENCOSS 8.3 WP6 Evlutinary Evidential Chain Cnsidering, then, the cmpleteness f the ISO framewrk fr the case f the autmtive dmain, the evlutinary chain shuld reprduce the wrkflw f the standard, integrating the ISO mdelling implemented by WP4 and WP5, the latter fr the SEC cncept. 8.4 WP7 Transparent Certificatin & Cmpliance Aware Prcess The prcess f the safety assessment in the autmtive dmain, as previusly stated, des nt lead t a certificatin result, but t a cnfrmity assessment and is cmpletely managed by the ISO standard. Frm this pint f view the evlutinary chain f the ISO standard is already self aware and des nt require specific interpretatin, because the surce f safety evidences/arguments is the standard itself and, therefre, the safety evidences/arguments are strictly linked t the prcess represented by the wrkflw f the standard. FP7 prject # Page 32 f 33