1、功能安全工作模板 Sfety CseVIP

Safety CasePart/material No.Part/material nameAuthorStatusDocument No.Project NoProject nameOwnerDoc typeDoc partVersionProduct groupCustomerDocument descriptionSafety Case1 Table of Contents1Table of Contents22Revision History43Introduction53.1General overview53.2About this document53.3Abbreviations54References75Statement of Safety86Overview of Created Functional Safety Work Products87Deviations98Functional Safety Management108.1Overall Safety Management108.2Safety Culture108.3Organization Specific rules and processes to comply with ISO26262108.4Quality Management108.5Safety Management during the Concept Phase and the Product Development108.6Safety Management after the Items Release for Production109Main Safety Argumentation119.1Technical Safety Concept119.1.1Overview119.1.2Safety Architecture119.1.3References to more detailed information119.2Hardware Safety Requirements119.2.1Overview119.2.2References to more detailed information119.3Software Safety Requirements119.3.1Overview119.3.2References to more detailed information119.4Verification & Validation129.4.1Summary of Safety Requirements verification129.4.2Electronic Unit Safety Testing129.4.3Electronic Unit Software Safety Test Results129.4.4Safety Requirements Review Results129.4.5Qualification testing129.5Safety Analyses139.5.1Methods & Results139.5.2Hardware Metrics1310Supporting Argumentation1310.1Production1310.1.1Production Plan & Production Control Plan1310.2Operation, Service and Decommissioning1310.2.1Operation1310.2.2Service1310.2.3Decommissioning1310.3Field Monitoring1310.4Requirements Management1410.5Configuration Management1410.6Change Management1410.7Verification1410.8Documentation1410.9Confidence in the Use of Software Tools1410.10Qualification of Software Components1410.11Qualification of Hardware Components1410.12Proven in Use Arguments1411Development Interface Agreements152 Revision 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 necessary 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 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.3 Introduction3.1 General overview has chosen KA as the supplier of to the platform. 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 responsibilities 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 responsible for the overall Technical Safety of the complete as well as the .3.2 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 ref 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.3.3 AbbreviationsAbbreviationKAXX AutomotiveN/ANot ApplicableTBCTo Be ConfirmedTBDTo Be Defined4 ReferencesRefIdIssueDocument 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 levelR7ISO26262:72011Production and operationR8ISO26262:82011Supporting processesR9ISO26262:92011Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analysesR10ISO26262:102012Guideline on ISO 26262R11KA- Development Interface Agreement (DIA)R12Safety PlanR135 Statement of SafetyKA hereby state 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 built on the statements provided in this document.This document constitutes the Safety Case for the in the .6 Overview 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.Work ProductDocument titleDocument id & latest reviewed revisionReview Protocol id & revisionWork Product Status (OK, CondOK, NOK)(WP-X:X.X.X) 7 DeviationsList all deviations from the planned baseline here, together with a summary of the risk that the deviation results in.8 Functional Safety Management8.1 Overall Safety Management8.1.1 Safety 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.8.1.2 Organization Specific rules and processes to comply with ISO26262Describe the rules and the framework for handling ISO26262 related tasks.8.1.3 Quality ManagementKA is certified according to ISO/TS 16949.8.2 Safety Management during the Concept Phase and the Product DevelopmentDescribe the project organization briefly and provide a reference to all Safety Related Roles, their appointments and the safety background/competence of the persons having those roles.8.3 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.9 Main Safety Argumentation9.1 Technical Safety Concept9.1.1 OverviewProvide an overview of the safety related mechanisms in the product.9.1.2 Safety ArchitectureDescribe the Technical Safety Architecture here, including the derivation of the Technical Safety Requirements on the System Level.9.1.3 References to more detailed informationReference additional information such as specifications and requirements.9.2 Hardware Safety Requirements9.2.1 OverviewIn 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 they have been verified.9.2.2 References to more detailed informationReference additional information such as specifications and requirements.9.3 Software Safety Requirements9.3.1 OverviewIn this section, describe how Software Safety Requirements have been derived from Technical Safety Requirements on the System Level. Also describe how they have been reviewed for correctness and how they have been verified.9.3.2 References to more detailed informationReference additional information such as specifications and requirements.9.4 Verification & Validation9.4.1 Summary of Safety Requirements verificationSummarize the verification of the safety requirements.9.4.2 Electronic Unit Safety Testing Electronic 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 section.9.4.3 Electronic Unit Software Safety Test ResultsSummarize the test results from the Software Safety Testing in this section.9.4.4 Safety Requirements Review ResultsIn case some Safety Requirements are verified by review, summarize the review results in this section.9.4.5 Qualification testing Functional testing 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 this section. Environmental testingSummarize the environmental testing on the complete assembly level, combining both mechanical and electronical systems in this section.9.5 Safety Analyses9.5.1 Methods & ResultsDescribe and detail the results from the safety analyses as well as the methods that have been used.9.5.2 Hardware MetricsSummarize the Hardware Metrics from the FMEDA in this section.10 Supporting 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 described 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.10.1 Production10.1.1 Production Plan & Production Control PlanDescribe how the Production Plan and Production Control Plan handle safety critical tasks and how faults that can be safety related are handled when found during the production.10.2 Operation, Service and Decommissioning10.2.1 OperationDescribe 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 acceptable.10.2.2 ServiceDescribe the limitations for service in order to not breach safety compatibility.10.2.3 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.10.3 Field MonitoringDescribe the KA field monitoring process used in the project.10.4 Requirements ManagementDescribe how requirements are handled in the project. If applicable, reference the KA Requirements Management process.10.5 Configuration ManagementReference the KA Configuration Management Process.10.6 Change ManagementReference the KA Change Management Process.10.7 VerificationSee section DocumentationArgue that an adequate amount of Safety Documentation has been performed, reference the Safety Plan and state if all l