An Advanced Guide to ISO 26262 -eBook www.iso26262-conference.comWhitepaper Safety Cases and Their Role in ISO 26262 Functional Safety AssessmentPart 12CONTENT1 Introduction Page 32 Safety Argument CategoriesPage 43 Industrial Case StudyPage 74 Analysis and DiscussionPage 125 Concluding RemarksPage 146 ReferencesPage 15Abstract Compliance with the automotive standard ISO 26262 requires the development of a safety case for electrical and/orelectronic(E/E)systemswhosemalfunction has the potential to lead to an unreasonable level of risk.Inordertojustifyfreedomfromunreasonable risk, a safety argument should be developed in which thesafetyrequirementsareshowntobecomplete and satised by the evidence generated from the ISO 26262workproducts.However,thestandarddoes notprovidepracticalguidelinesforhowitshould bedevelopedandreviewed.Moreimportantly,the standard does not describe how the safety argument shouldbeevaluatedinthefunctionalsafety assessmentprocess.Inthispaper,wecategorise andanalysethemainargumentstructuresrequired ofasafetycaseandspecifytherelationshipsthat exist between these structures. Particular emphasis isplacedontheimportanceoftheproduct-based safetyrationalewithintheargumentandtherole thisrationaleshouldplayinassessingfunctional safety. The approach is evaluated in an industrial case study. The paper concludes with a discussion of the potential benets and challenges of structured safety arguments for evaluating the rationale, assumptions and evidence put forward when claiming compliance with ISO 26262.1 AVL Powertrain UK Ltd, Basildon, UK; 2 Jaguar Land Rover, Coventry, UK; 3 University of York, York, UK; 4 TRW Conekt, Solihull, UK;5 Ricardo UK Ltd, Cambridge, UK; 6 Delphi Diesel Systems; 7 Peter Jesty Consulting Ltd, Tadcaster, UK; 8 Protean Electric Ltd, Surrey, UK31IntroductionCriticalfunctionsinroadvehiclesareincreasingly being implemented using electrical and/or electronic (E/E)systems.Themalfunctioningbehaviourof thesesystemscancontributetothesafetyriskto thevehicleoccupantsand/orotherroadusers.As such, it is necessary to provide assurance that any unreasonable residual risks have been avoided. The safetystandardISO26262hasbeendeveloped toaddressthisnecessitybyprovidingguidance, intheformofrequirementsandprocesses,for avoidingunreasonableresidualriskcausedbythe malfunctioning behaviour of E/E systems [1]. Likemany safety standards that cover complex software-basedsystems,ISO26262denesrequirements for the creation of work products i.e. outputs from the safety lifecycle, and leaves it to the developers tointerprettheserequirementsinthecontextof theirproducts[2].Inordertoprovideaproduct-specicjustication,compliancewiththeISO 26262standardrequiresthedevelopmentand evaluationofasafetycaseforthesafety-related items. Thestandarddenesanitemasa system or array of systems to implement a function at the vehiclelevel[1].Inordertojustifyfreedomfrom unreasonablerisk,asafetycaseargumentshould be developed in which the safety requirements are shown to be complete and satised by the evidence generatedfromtheISO26262workproducts. However,thestandarddoesnotprovidepractical guidanceonthedevelopmentandreviewofthe safety argument, nor does it describe how the safety argumentshouldbeevaluatedinthefunctional safety assessment process. In this paper, we build on the experience of the authors in developing and evaluating safety cases in the context of ISO 26262. Weexaminethesignicanceandnatureofthe product-based safety rationale within the argument and the role this rationale should play in assessing functionalsafety. Thepaperalsobuildsonexisting work on safety cases across different domains [3 - 5], and in the automotive industry in particular [6], [7], taking into account issues related to product-based andprocess-basedassurance[8],theprocessof compliance [9] and assessment of condence [10], [11]. Thepaperisorganisedasfollows.InSection 2,wecategoriseandanalysethemainargument structuresofasafetycaseandtherelationships thatexistbetweenthesafetycaseandtheISO 26262 functional safety assessment. The approach isevaluatedinanindustrialcasestudyinSection 3.InSection4,wediscussthepotentialbenets andchallengesofstructuredsafetyargumentsfor evaluating the rationale, assumptions and evidence put forward when claiming compliance with the ISO 26262 standard.Introduction42 Safety Argument CategoriesTheimplicitsafetyargumentinISO26262is centred on the following chain of reasoning (Fig. 1). A sufcient and an acceptable level of safety of an E/E system is achieved by demonstrating absence of unreasonable risk associated with each hazardous eventcausedbythemalfunctioningbehaviour oftheitem(otherhazardcausesareoutsidethe scope of the standard). This is achieved by dening safety goals to avoid unreasonable risk through the prevention or mitigation of the identied hazardousevents.Ahazardouseventistheoccurrenceofa hazardinparticularoperationalsituations.Each hazardouseventisassignedan AutomotiveSafety Integrity Level (ASIL), based on the combination of three parameters: severity (extent of human harm), probabilityofexposure(tooperationalsituations) and controllability (ability for persons at risk to take action to avoid harm). Claims are then asserted that each safety goal is satised by the development of afunctionalsafetyconcept. Thefunctionalsafety conceptspeciessafetymeasureswithinthe contextofthevehiclearchitecture,includingfault ISO26262denesasafetycaseasan argumentthatthesafetyrequirementsforanitemare completeandsatisedbyevidencecompiledfromworkproductsofthesafetyactivitiesduring development[1]. Thatis,theargumentshouldplayacentralroleinjustifyingwhytheavailable evidence, in the form of work products (e.g. design and analysis artefacts), has achieved a set of safety requirements and, therefore, why an acceptable level of safety has been achieved. Compliance withISO26262,basedonthenormativepartsofthestandard,mandatesthesatisfactionofa specic set of objectives by the generation of a concrete set of work products. As a result, all E/E systems that are compliant with the standard share a common safety argument structure linking the top-level safety requirements to the available evidence. Unfortunately, this common argument structure is implicit and is not documented in the standard.2.1 Implicit Safety Argument in ISO 26262FIG. 1. IMPLICIT ISO 26262 SAFETY ARGUMENT STRUCTURE Safety Argument Categories5 Safety Goals (hierarchy 1) the vehicle in its environment; Functional Safety Requirements (hierarchy 2) the vehicle and its systems; Technical Safety Requirements (hierarchy 3) the E/E system; and Hardware and software requirements (hierarchy 4) component and part levelFor each hierarchy, ISO 26262 prescribes evidence, intheformofworkproducts,forsubstantiating theseclaims.Additionally,thestandardidenties methodsforgeneratingtheseworkproductsin accordance with the required ASIL. For example, inorder to substantiate a claim that the technical safety requirementshavebeencorrectlyimplementedat thehardware-softwarelevel,evidenceshouldbe provided through methods such as a requirements-basedtest,faultinjectiontestorback-to-backtest (Table 1, Part 4). This evidence should be captured in anIntegration TestingReport(WorkProduct8.5.3, Part 4).TheimplicitsafetyargumentinISO26262has twomaincategoriesofclaim:productclaimsand processclaims.Basedonthehazardanalysisand risk assessment, the product claims focus primarily onthesafetygoalsandsafetyrequirements(i.e. specifyinganddemonstratingbehaviourwhichis freefromunreasonablerisk).Theprocessclaims focusontheadequacyoftheorganisations, people,lifecycles,methodsandtoolsinvolvedin the generation of the work products. The nature of these process claims and the rigour of the evidence needed to support them vary with the ASIL assigned tothesafetygoalsandtheircorrespondingsafety requirements(i.e.highlevelsofriskrequirehigh levels of process rigour).CompliancewithISO26262andtheevaluationof theaboveimplicitargumentisdemonstrated,in part,usingtwotypesofconrmationmeasures: functionalsafetyauditandfunctionalsafety assessment.Therequirementsforboth,andthe necessary independence, are specied in Part 2 of the standard. The functional safety audit is concerned with reviewing the implementation of the processes requiredforfunctionalsafety.Functionalsafety assessment is concerned with making a judgement onthefunctionalsafetyachievedbytheitemand henceisconcernedwiththecharacteristicsofthe product.Theassessmentincludesevaluatingthe workproductsspeciedintheitemssafetyplan, therequiredprocesses(i.e.thefunctionalsafety audit) and the appropriateness and effectiveness of the safety measures that are implemented.detectionandfailuremitigationmechanisms,to satisfythesafetygoals. Twofurtherhierarchiesof claimaredenedforassertinghowthefunctional safetyconceptisadequatelyrenedandsatised byatechnicalsafetyconceptandhardwareand software components (again to the required ASIL). As a result, the implicit argument follows a hierarchy of claims that can be grouped as follows: Safety Argument CategoriesSafety Argument Categories Safety Argument Categories62.2 Product-Specic Safety RationaleAlegitimatequestionatthispointshouldbe:why isitnecessarytodocumenttheabovesafety argument if it is common to all items compliant with ISO 26262? What is the added value of developing, reviewingandmaintainingthiscommonsafety argument?Inthispaper,wecontendthatthe challengedoesnotlieinmerelycapturingthis common,implicit,argument.Instead,mostofthe effort should focus on justifying, through an explicit argumentstructure,howonehierarchyofclaims, e.g.concerningabsenceofunreasonablerisk,is supported by another hierarchy of claims, e.g. safety goalsthataddressanyunreasonablerisk(Fig.1). Thesesub-argumentsshouldcapturetheproduct-specic safety rationale which typically varies from oneitemtoanother. Thatis,althoughtheoverall structure of the argument is stable (i.e. assessmentof hazardous events and specication, development andassessmentofsafetygoalsandsafety requirements),theassurancechallengeliesin providingproductspecicrationale,assumptions andjusticationsforwhy,givenanoperational environment,avehiclecongurationandthe conditionofothervehiclesystems,theavailable evidence is sufcient to support the asserted claims. Typically,theseclaims,andtheircorresponding argumentsandevidence,arethefocusofthe functionalsafetyassessmentprocessasthey address the product-specic safety rationale that is oftenassociatedwithuniquecharacteristicsofthe system and its environment.Aclaimistypicallymadethattheabsenceof unreasonableriskofahazardouseventhasbeen addressed by conforming to a safety goal. However, it would be nave to dene a safety goal as simply a negation of a hazardous event and simply to assignan ASIL to that safety goal. Although this approach is arguably valid from the perspective of literal ISO 26262compliance,itissimplisticasitlimitsrisk mitigation to reducing the probability of the hazardous malfunction. Other risk reduction strategies related toreducingseverity,improvingcontrollabilityand/orreducingexposure(typicallythroughameasure externaltotheitem,whichcanbeanotherE/E system)canbetakenintoaccount.Forexample, ifasafetygoalstipulatesthatthesystemshall transitiontoasafestateinthepresenceoffaults thatcouldotherwisecausethecorresponding hazardousevent,thenanargumentandevidence forwhythespeciedsafestateisconsideredto beadequatelysafeshouldbeprovided.Thiscan beachievedbyjustifyingthat,werethevehicle behaviourinthesafestatetobesubjecttoISO 26262hazardclassicationcriteria,thenitwould beclassiedQM(QualityManagement).QMin ISO 26262 denotes a risk that does not require the satisfactionofanyspecicsafetyrequirements, thereby implying that the level of risk is reasonable and no further risk reduction is necessary. The main claim here would be that the residual risk associated with the hazardous event, after achieving the safety goal, has been reduced to a level that is reasonable. Thesubsequentargumentusedtosupportsucha claim would then need to explicitly assert which risk parameters (controllability, severity or exposure) would be reduced if the residual risk were classied in this way.A typical approach may be to provide an argument thatsomerecongurationordegradationscheme iscapableofplacingasystemintoasafestate Safety Argument Categories Industrial Case Study7suchthatthecontrollabilityofanyreaction,e.g. toanundemandeddrivetorque,iseffectivelyC0 (controllable in general) whereas the hazardous event itself will have been classied with the controllability parametertakingavalueofC1,C2orC3. Another approachmaybetoplaceasysteminasafestate by preventing a vehicle exceeding a speed thresholdupon detection of a fault that can cause the hazardous event such that the exposure parameter that could beassociatedwiththesafestateiseffectivelyE0 (incredible).Suchreasoningisproduct-specicand the implicit safety argument in ISO 26262 does not prescribe any product-specic safety rationale.ThesafetyargumentstructureinFig.1includes referencestoveproduct-specicsafetyrationale sub-arguments.Thesesub-argumentsshould providejusticationfortheinferentialtransition from one hierarchy of safety claims to another. For instance,thefunctionalsafetyconceptrationale argumentshouldincludeajusticationforwhy thedeploymentofsafetymeasuressuchasfault detection,failuremitigationand/ordriverwarnings should lead to the satisfaction of the corresponding safety goals.3 Industrial Case StudyThis case study is based on a typical electric vehicle architecture (technology-specicdetails have been abstracted for reasons of commercial sensitivity), in which a basicItem Denition and hazardous event are considered. The purpose of the case study isto examine the product-based safety rationale arguments, discussed in Section 2, forthe corresponding Safety Goal and Functional Safety Concept.3.1 Item DenitionThe Item Denition is shown in Fig. 2. The pertinent nominal operation is as follows: Driver requests positive longitudinal vehicle acceleration by depressing acceleratorpedalAccelerator pedal provides a low voltage electrical signal to indicate pedal positionto the Controller Controller reads this pedal signal and places a corresponding torque demand on theHigh Voltage Power Inverter (HVPI) via the Controller Area Network (CAN) HVPI converts a certain quantity of electrical energy from the High Voltage Batteryto high voltage electrical power supplied to the Electric Machine, according tothe torque demand from the ControllerIndustrial Case Study8 High voltage electrical power supplied to the Electric Machine induces a mechanicaltorque in the Electric Machine, which is transferred through the transmission tothe vehicles rear wheels.FIG. 2. ELECTRIC VEHICLE PROPULSION SYSTEM3.2 Hazard Analysis and Risk AssessmentThiscasestudyfocusesontheHazardousEvent Unintendedvehicleaccelerationduringalow speedmanoeuvreamongstpedestrians,whichis classied as ASIL B based on values of E3 (medium probability), S2 (severe and life-threatening injuries,survivalprobable),C3(difculttocontrolor uncontrollable)fortheExposure,Severityand Controllability parameters respectively. The rationale for this classication requires a detailed description ofthevehicle,theoperationalandenvironmental constraints and peer systems and as such it has not been included for brevity.3.3 Safety Goal and its Rationale ArgumentThesafetygoalthathasbeendenedtoaddress theriskassociatedwiththeHazardousEventis Vehiclepositivelongitudinalaccelerationshallnot exceed driver demand by > 1.5 m s2 for longer than 1s.However,thequestionthatasafetyassessor mayrightlyaskiswhybymeetingthissafetygoal is unreasonable risk avoided? It is not typical within industryfortheanswertoquestionsofthistype tobedocumented,butdoingsoshouldhelpthe engineertobeclearaboutwhythesafetygoal achievesfreedomfromunreasonablerisk,andto communicate that to the safety assessor.Industrial Case Study Industrial Case Study9The argument for this particular case study, presented in Goal Structuring Notation (GSN) [12] in Fig. 3, is based on improving controllability; specically if the unintendedaccelerationiskeptbelowthestated threshold,thedriverisabletoslowandstopthe vehicle before a collision with the pedestrian occurs. Within this argument, the Absence of Unreasonable ResidualRiskstrategyisgeneric,andcouldbe appliedtoanysafetygoal,whereastheResidual Risk Controllability Classication strategy is specic to this particular safety goal.FIG. 3. SAFETY GOAL RATIONALE ARGUMENTIndustrial Case Study103.4 Functional Safety Concept and its Rationale ArgumentThe functional safety concept that has been chosen toachievethesafetygoal,namedDistributed detection and mitigation of torque errors, is based ondegradation;wherebyallfaultsthatcanlead toexcessiveaccelerationaredetectedwithinan acceptable time interval. On detection of a fault, the vehicle acceleration is limited to a value below that speciedinthesafetygoal. Theconceptisbased on the assertion that only malfunctioning behaviour oftheItemthatcanviolatethesafetygoal(which isspeciedintermsofvehicle-levelbehaviour; acceleration)isthedeliveryofexcessivetorqueto theTransmission;behaviourwhichisspeciedat the Item-level. The concept features are as follows (Fig. 4):1. Detection of all faults that would otherwise lead to excessive torque delivery:(a) Controller detects accelerator pedal faults by comparing and arbitrating between the outputs from two independent pedal position measurement sensors(b) Controller self-detects torque-request errors by comparing its nal torque request to the HVPI (output) with the accelerator pedal position (input)(c) HVPI self-detects torque-demand errors by comparing the quantity of high voltage electrical power supplied to the Electric Machine (output) with the torque request from the Controller (input)2. Upon detection of errors, outputs are electronically limited to a xed value that ensures thatthe magnitude of excessive torque delivered to the Transmission is below that required toviolate the safety goals acceleration criteria.Industrial Case Study Industrial Case Study11FIG. 4. FUNCTIONAL SAFETY CONCEPT RATIONALE ARGUMENTAnalysis and Discussion12Typically,acompanywoulddocumentthefailure modesoftheconceptinananalysisreport,e.g. usingFailureModeandEffectsAnalysis(FMEA), andmanagesafetygoalandfunctionalsafety requirementsinarequirementsdatabase.It would also have vehicle test reports or simulations demonstrating that the safety goals had been met. However, the rationale explaining how this evidence tstogetherisnotoftendocumented. Thismeans thatwhoeverperformstheFunctionalSafety Assessmenthastodeducethisforthemselves byreadingbetweenthelines,andforcomplex andhighlyinterconnectedsystems,tenuousleaps may need to be made. The added value of formally documenting the rationale, as in Fig. 4, is not only thatithelpstheengineerstoidentifypotential decienciesinthesafetyargument,butalsothat iteasesthesubsequenttaskofperformingthe FunctionalSafetyAssessment,andmayhighlight the need for further work.3.5 Item Functional Safety ArgumentThetwoargumentspresentedinFig.3andFig. 4canbereferencedasAwayGoals[12]within thecompletesafetyargumentfortheItem(Fig. 5).Otherstructureswithinthecompletesafety argument should include condence-based process claimsthatrefertotheASIL-specicprocesses usedtodeveloptheworkproducts. Thecomplete argumentwouldalsorequirefurtherdevelopment tojustifyhowthefunctionalsafetyconcepthas beenimplementedbythechosentechnicalsafety conceptandsubsequentlybythehardwareand software safety requirements. Although this has not been the focus of this paper, it has been found that theargumentstructureatthelevelofsafetygoals andfunctionalsafetyconceptcanbesuccessfully repeatedatlowerlevels,withthecapabilityto partition the argument to represent the distributed developmentcommonlyseenbetweenavehicle manufacturer and its suppliers.4 Analysis and DiscussionWithout a clear safety argument structure, a checklist approach to safety assurance, based on the creation of work products and requirements traceability, tends to be used. Important as this is, the rationale behind the requirements is often not documented. An important aspect of capturing the product-based safety rationale is that it helps the engineers identify potential deciencies in the argument in a timely manner and supports the subsequent task of performing the Functional Safety Assessment. In this section, we reect on the insights gained from different engineering perspectives.Analysis and Discussion Analysis and Discussion134.1 Original Equipment Manufacturer (OEM) PerspectiveTypically, a large list of safety requirements and work productsispresentedtoanOEM,i.e.thevehicle manufacturer,forwhichtheremaybetraceability tothesafetygoalsbutno,oronlytenuous,basis forunderstandingwhetherandhowthesafety goalshavebeenfullysatised.Consequentlythe adequacy of the deliverables can only be determined byextensivequestionandanswersessions.This oftenrevealsthattheimportantsafetyrationaleis not documented and only exists in the heads of theengineers. It also often reveals that there are many undocumentedassumptionswhichneedtobe validatedandwouldbebettertreatedassafety requirements.Wheretheapproachpresented inthispaperisadopted,engineersgainadeeper understandingofthesystemtheyaredesigning. Further,documentationisgeneratedatamore appropriatelifecyclestagetoenableeffectiveand timelyassessment.Becauseofthehierarchical natureoftheexplicitsafetyargument,andthe observationthatitsstructurerepeatsbetween levels,theargumentlendsitselftobeingsplit between organisations. For example, an OEM may typically develop the safety argument down to, and including, the level of functional safety concept. The supplierresponsiblefordevelopingthetechnical safetyconceptandhardwareandsoftwaresafety requirementscanthendeveloptherelevant downstreamrationaleinasimilarmannertothe OEM in order to justify the safety requirements they have developed.4.2 Supplier PerspectiveE/Esystemsuppliersareheavilydependenton requirements received from the OEM, as the OEM has a complete view of the vehicle, its systems and their dependencies. However, by developing an E/E system and hardware and/or software components, asupplierwillgenerallyownahighproportionof thefaultsthatcancontributetohazardousevents. As such, suppliers will be responsible for the design requirements, safety analysis and verication of the E/Esystemtosupporttheclaimthatvehiclelevel safety will be assured and that the requirements of thefunctionalsafetyconcepthavebeenachieved. Withthispartitioningofresponsibilitiescomesthe need to demonstrate accountability i.e. the need for suppliers to provide a safety argument to justify that their design/implementation supports certain safety goalsatthevehiclelevel.Astructuredargument provides this much needed visibility between parties at the different assessment stages.Further, suppliers traditionally develop common E/Eplatforms prior to OEM engagement. For example, asupplierdevelopinganenginemanagement systemforfuturevehicleemissionlegislationwill identify requirements years before involving OEMs. Itisimportantthatanysafety-relatedcomponent/element,whichisdevelopedwithoutaspecic applicationcontext,isassessed. Thesupplierwill needtocaptureassumptions,mostlikelybased onpreviousexperience,andpossiblyinisolation. Theseassumptionsandthesafetyrationaleare verywellsuitedtoanargumentstructurethat clearlyidentiesproductsafetyclaimsinrelation Concluding Remarks144.3 Safety Assessor PerspectiveIntheinfancyofISO26262,earlyproject assessmentshavebeenbasedsolelyonwork productsandprocesses.Thishasresultedin lengthyprotractedassessments,trawlingthrough documentationandrelyingheavilyoninterviews todiscoverundocumentedrationale.Thishas highlightedtheneedtohaveasafetycasewitha clear structure and purpose. It has also been found that it is both possible and benecial to assess the top down safety argument iteratively, as the design of an item evolves. For example, the safety assessor can review the safety goal rationale argument in Fig. 1beforethefunctionalsafetyortechnicalsafety concepts have been developed, rather than waiting until the later lifecycle stages. This helps to identify weaknesses in the eventual safety argument earlier onintheprojectlifecycle,reducingthecostand effort resulting from any subsequent rework.Finally,theautomotiveindustrylikemanyother domainsisdrivenbytightmarginsandtime constraints. Once a project is underway, momentum increasesquickly.Itisthereforeessentialthatthe visibilityoftheprojectstechnicalandassurance attributesandanyinfringementsidentiedearly sothatundesiredconsequencesareaddressed. Thisleadstotheconclusionthatthereviewand assessmentofthesafetycaseatkeyproduct gateways will not only keep focus on the emergence of the projects and products safety attributes, but ismorelikelytohaveasafetycaseatthenal functionalsafetyassessmentthatislegibleand more readily analysable.5 Concluding RemarksSafetycasedevelopmentisarelativelynew conceptformanysafetypractitionersinthe automotiveindustry.Thetimelygenerationof well-focussedsafetycasesiscapableofbringing considerable benet in the context of development andassessment,andthusofcontributingtothe safetyassuranceofautomotiveE/Esystems. Ourexperiencetodatesuggeststhattheprimary focusofmanydocumentedsafetycasesforISO 26262-compliant systems and components remains onprocesses.Inextremecases,thiscanresultin bulkydocumentationthatdoeslittlemorethan renderexplicitthestandardsimplicitarguments or, even, recapitulate its requirements in a different form. Broadly, we perceive an educational challenge to exist in this area even among automotive safety engineerswithconsiderableexperienceinother areas.toassumedhazards,safetygoalsandconcepts.A clearlydenedargumentstructureimprovesthe engagementofcustomerswithnewapplications not only to provide the safety justication but also toidentifyassumptionsthatrequireconrmation, redressandalsotheallocationofriskmitigation responsibilities to customers when needed.References Concluding Remarks15Other characteristics have reduced the effectiveness ofcertainsafetycasesproducedtomeetthe requirementsofISO26262.Theseinclude:lack offocusandbrevity;unnecessaryrepetitionof informationavailableelsewhere;andtheuseof inappropriate means of expression (e.g. use of GSN where a table might be more effective and vice versa). Similarly,safetycasesintheautomotiveindustry areassusceptibleasthoseinotherindustries todecienciessuchasfallaciesandfailuresto acknowledgelimitations.Theseweaknessesare foundinsafetycasesinotherindustriesbut,we believe, may best be countered by didactic material thatistargetedspecicallyattheautomotive industry in order to improve outreach.6References 1.ISO: ISO 26262 Road Vehicles -- Functional Safety. ISO Standard (2011)2. Graydon, P., Habli, I., Hawkins, R., Kelly, T., Knight.: Arguing conformance. IEEE Software, vol. 29, issue 3 (2012)3. Bishop, P., Bloomeld, R.: A methodology for safety case development. In: Proc. 6th Safety-critical Sys.Symp. (1998)4. Kelly, T.: A systematic approach to safety case management. In: Proc. Society of Automotive Engineers (SAE) World Congress (2004)5. The Health Foundation, Using Safety Cases in Industry and Healthcare. ISBN: 978-1-906461-43-0, (2012)6. Dittel, T., Aryus, H.: How to Survive a safety case according to ISO 26262. SAFECOMP 2010, Vienna, Austria,(2010)7. Palin, R., Habli, I.: Assurance of automotive safety: a safety case approach. SAFECOMP 2010, Vienna, Austria, (2010)8. Habli, I., Kelly, I.: Process and product certication arguments: getting the balance right. SIGBED Review, vol. 3,issue 4 (2006)9. Langari, Z., Maibaum, T.: Safety cases: a review of challenges. International Workshop on Assurance Cases forSoftware-intensive Systems (ASSURE 2013) San Francisco (2013)10.Denney, E., Pai, G., Habli, I.: Towards measurement of condence in safety cases. In: Proc. 5th Intl. Symp. onEmpirical Soft. Eng. and Measurement. pp. 380383 (Sep 2011)11. Ayoub, A., Kim, B., Lee, I., Sokolsky, O.: A systematic approach to justifying sufcient condence in software safety arguments. SAFECOMP 2012, Magdeburg, Germany (2012)12.Goal Structuring Notation Working Group: GSN Community Standard Version 1 (2011)16 www.iso26262-conference.com5th International ConferenceISO 26262Tackling functional safety challenges on all levels23 26 March 2015 | Steigenberger Hotel Berlin, GermanyGain insight into the next generation ISO from ISO 26262 committee members to ensure anoptimised implementation Identify interactions between automotive safety andsecurity and benefit from best practiceexamples to ensure an efficient co-existenceDiscover how ISO 26262 can be successfully implemented on a global scale at optimal costsJoin the technical Chassis or Powertrain stream and collect state-of-the-art solution approaches to tackle domain-specific challengesExamine the implications the move towards automated and autonomous functions will haveon ISO 26262 implementation to be prepared for the functional safety of the future 5th International ConferenceISO 26262Tackling functional safety challenges on all levels23 26 March 2015 | Steigenberger Hotel Berlin, GermanyMeet and exchange with leading functional safety experts from all over the world Visit our download center for free white papers, articles and much more!www.iso26262-conference.com/MMHighlight speakers include:Dr. Hakan Sivencrona, Functional Safety Manager, Lead SystemEngineer,Delphi Automotive Systems and ISO 26262International Committee Member, SwedenAdamSchnellbach, Functional Safety Group Leader,MAGNA PowertrainAG & Co. KG, GermanyPeter Mller,Development specialist, System- and Functional Safety Powertrain,BMWGroup, GermanyFulvioTagliab, Global FunctionalSafety Manager,Magneti Marelli, ItalyMeet experts from the following companies:Excellent networking opportunity. A very good forumto exchange on functional safety topicsRafa Dorociak, Functional Safety Manager, Hella KGaA Hueck & Co.Embedded Systems1010010010100100101001001010 0100101001001010010010100100 1010010010100100101001001010 010010100100 101001001010010 0101001001010010010100100101 00100 1010010010100100101001 0010100100101001001010010010 1001001010010010100100101001 001010010010100100 101001001 0100100101001001010010010100 100101001001010010010100100101001001010 0100101001001010010010100100 1010010010100100101001001010 010010100100 101001001010010 0101001001010010010100100101 00100 1010010010100100101001 0010100100101001001010010010 1001001010010010100100101001 001010010010100100 101001001 0100100101001001010010010100 10010100100 1010010010100100101001001010 0100101001001010010010100100 1010010010100100101001001010 010010100100 101001001010010 0101001001010010010100100101 00100 1010010010100100101001 0010100100101001001010010010 1001001010010010100100101001 001010010010100100 101001001 0100100101001001010010010100 10010100100Workshops 1: Legal requirements to apply ISO 262622: MBSE: A continuing source of myth and pitfalls?3: Efcient evaluation of hardware metrics using combinational methods like FMEDA and FTA4: Efcient system analysis and design for safety-relevant products5: Integrated security and safety processes6:Fault trees for methods, tools and processes: Nothing to calculate stilla lot to take away7: Re-assessing SEooC: Shared experiencesToRegister:T+49(0)3020913388|F+49(0)3020913210|Eeq@iqpc.de|www.iso26262-conference.com/MMSAVEup to 600,- with ourEarly Birds if you book

and pay by 23 January 2015!Sponsors:Academy Day 23 March 2015Download the latest agenda:www.iso26262-conference.com