ISO26262 安全案例Safety Case.docx

1、ISO26262 安全案例Safety CaseSafety Case1Table of Contents2Revision HistoryVersionECN no.Changed byChange from last version01The change history shall be a detailed enough description of what sections that have been changed since the last version. Depending on the changes that have been made it may be nec

2、essary to describe the changes more in detail.Blue text in italic is information/explanation directed to the issuer of the document.Before releasing the Work Product (document) all blue italic text must be removed.Mark unused sections of this document as “NOT APPLICABLE”, do not remove the paragraph

3、 heading.Text marked with a is to be replaced by something specific. This shall be used if there are specific keywords within standardized paragraphs that shall be replaced when creating the Work Product from the template.3IntroductionGeneral overview has chosen KA as the supplier of to the platform

4、. The Electronics of the is called . has performed a Hazard Analysis and Risk Assessment in accordance with ISO26262 resulting in Safety Goals. The Safety Goals have been refined into Technical Safety Requirements allocated to the . The highest ASIL of these Safety Requirements is ASIL .The safety r

5、esponsibilities are further detailed in the KA- Development Interface Agreement, DIA, ref R11.KA will have to ensure that the Production, Operation and Service of the as well as the shall satisfy the requirements of ISO26262 at a level that corresponds with the highest ASIL allocated.KA is responsib

6、le for the overall Technical Safety of the complete as well as the .About this documentThis document contains the Safety Case for the in the . The Safety Case constitutes the argumentation why the is free from unreasonable risk in accordance with the Automotive Functional Safety Standard ISO26262 re

7、f R1, R2, R3, R4, R5, R6, R7, R8, R9, R10.The Safety Work Products and documents listed in the Safety Case are considered with the respective tailoring that has been done in the Safety Plan, ref R12.AbbreviationsAbbreviationKAXX AutomotiveN/ANot ApplicableTBCTo Be ConfirmedTBDTo Be Defined4Reference

8、sRefIdIssueDocument NameR1ISO26262:12011VocabularyR2ISO26262:22011Management of functional safetyR3ISO26262:32011Concept phaseR4ISO26262:42011Product development at the system levelR5ISO26262:52011Product development at the hardware levelR6ISO26262:62011Product development at the software levelR7ISO

9、26262:72011Production and operationR8ISO26262:82011Supporting processesR9ISO26262:92011Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analysesR10ISO26262:102012Guideline on ISO 26262R11KA- Development Interface Agreement (DIA)R12Safety PlanR135Statement of SafetyKA hereby stat

10、e that the is free from unreasonable risk with respect to “Malfunctioning behavior of E/E safety-related systems”. That is based on that ISO26262, ref R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, has been applied during the development of the and during the planning of the production. This claim is buil

11、t on the statements provided in this document.This document constitutes the Safety Case for the in the .6Overview of Created Functional Safety Work ProductsThe following table lists all the Work Products developed in accordance with the Project Safety Plan, ref , and the status of each Work Product.

12、Work ProductDocument titleDocument id & latest reviewed revisionReview Protocol id & revisionWork Product Status (OK, CondOK, NOK)(WP-X:X.X.X) 7DeviationsList all deviations from the planned baseline here, together with a summary of the risk that the deviation results in.8Functional Safety Managemen

13、tOverall Safety ManagementSafety CultureState the safety culture in KA. Describe how KA focuses on safety in relation to other tasks and milestones in the project. Provide an argument for that KA has an adequate attitude towards safety issues.Organization Specific rules and processes to comply with

14、ISO26262Describe the rules and the framework for handling ISO26262 related tasks.Quality ManagementKA is certified according to ISO/TS 16949.Safety Management during the Concept Phase and the Product DevelopmentDescribe the project organization briefly and provide a reference to all Safety Related R

15、oles, their appointments and the safety background/competence of the persons having those roles.Safety Management after the Items Release for ProductionDescribe how the safety management will be organised after the start of production and the closure of the development project.9Main Safety Argumenta

16、tionTechnical Safety ConceptOverviewProvide an overview of the safety related mechanisms in the product.Safety ArchitectureDescribe the Technical Safety Architecture here, including the derivation of the Technical Safety Requirements on the System Level.References to more detailed informationReferen

17、ce additional information such as specifications and requirements.Hardware Safety RequirementsOverviewIn this section, describe how Hardware Safety Requirements have been derived from Technical Safety Requirements on the System Level. Also describe how they have been reviewed for correctness and how

18、 they have been verified.References to more detailed informationReference additional information such as specifications and requirements.Software Safety RequirementsOverviewIn this section, describe how Software Safety Requirements have been derived from Technical Safety Requirements on the System L

19、evel. Also describe how they have been reviewed for correctness and how they have been verified.References to more detailed informationReference additional information such as specifications and requirements.Verification & ValidationSummary of Safety Requirements verificationSummarize the verificati

20、on of the safety requirements.Electronic Unit Safety TestingElectronic Unit System Safety Test ResultsSummarize the test results from the Safety Testing on System Level in this section.Electronic Unit Hardware Safety Test ResultsSummarize the test results from the Hardware Safety Testing in this sec

21、tion.Electronic Unit Software Safety Test ResultsSummarize the test results from the Software Safety Testing in this section.Safety Requirements Review ResultsIn case some Safety Requirements are verified by review, summarize the review results in this section.Qualification testingFunctional testing

22、 on complete assembly level (mechanical and electronical)Summarize the testing on the complete assembly level, combining both mechanical and electronical systems in this section.EMC testingSummarize the EMC testing on the complete assembly level, combining both mechanical and electronical systems in

23、 this section.Environmental testingSummarize the environmental testing on the complete assembly level, combining both mechanical and electronical systems in this section.Safety AnalysesMethods & ResultsDescribe and detail the results from the safety analyses as well as the methods that have been use

24、d.Hardware MetricsSummarize the Hardware Metrics from the FMEDA in this section.10Supporting ArgumentationKA has an extensive process to ensure quality, timing and safety during the entire product development.The KA product development process is called KBD, “Knowledge Based Development”. It is desc

25、ribed by a set of pages on the KA Intranet, in the section “XX Automotive Management System”, visualizing the process phases and steps in a graphical way.ProductionProduction Plan & Production Control PlanDescribe how the Production Plan and Production Control Plan handle safety critical tasks and h

26、ow faults that can be safety related are handled when found during the production.Operation, Service and DecommissioningOperationDescribe how the end user documentation relays safety related information to the end user where applicable. If end user documentation is omitted, argue for why that is acc

27、eptable.ServiceDescribe the limitations for service in order to not breach safety compatibility.DecommissioningIf there are any special considerations for the safe decommissioning of the product, describe how that information is relayed to the personnell responsible for such tasks.Field MonitoringDe

28、scribe the KA field monitoring process used in the project.Requirements ManagementDescribe how requirements are handled in the project. If applicable, reference the KA Requirements Management process.Configuration ManagementReference the KA Configuration Management Process.Change ManagementReference

29、 the KA Change Management Process.VerificationSee section 9.4.DocumentationArgue that an adequate amount of Safety Documentation has been performed, reference the Safety Plan and state if all listed documentation has been performed.Confidence in the Use of Software ToolsArgue that all software used

30、during all phases have been assigned a Tool Impact Level and that all tools that have been identified as possibly affecting the safety also have been classified and verified for their intended use.Reference the report from the analysis of the confidence in the software tools.Qualification of Software ComponentsIf re-use of Software Components