3、ISO26262道路车辆功能安全 培训资料、模板、讲义、 ISO 26262培训资料、工作模板等 ISO26262应用模板 Templte_ Item Definition

Date17-12月-2015Item DefinitionRevisionPage13 of 13StatusIn review / released Item DefinitionRELEASE/REVISION:RELEASE/REVISION DATE:RELEASED BY:TBDDD-MMM-YYYYTBDUSING THIS TEMPLATETo create an instance of this document: Insert relevant information on cover sheet and in placeholders throughout. Insert relevant information in header page and tile page by updating the document properties, e.g. the keyword field needs to contain the relevant project information A yellow box containing CONTENTS OF THIS SECTION is provided at the beginning of most sections and subsections. After determining what specific information will be included in your document, you can remove this yellow box or leave it to serve as a quick-reference section overview for your readers. Consider hyper-linking key words used in the document with their entries in the Reference section or other location in which they are defined. Choose Insert Hyperlink.Note: The objective of the template is to give guidance in creating the specific work product by providing a predefined structure and information of the expected content for each section which are derived from ISO26262 standards. The provided structure may be tailored to suit specific tools.Table of Contents1Document Management and Configuration Control Information32Purpose43Scope54Acronyms & Definitions54.1Acronyms54.2Definitions55Functional Description55.1Function 1: 55.2Function 2: 55.3Function n: 56Non Functional Requirements66.1Environmental Conditions66.2Operational Requirements66.3Restrictions67Legal Requirements68Applied Safety Standards and legal Safety Requirements68.1Behavior achieved by similar functions78.2Behavior expected from item78.3Potential consequences of insufficient behavior incl. Failure modes and hazards79Boundaries89.1Internal Boundaries89.2External Boundaries910Interfaces910.1Mechanical Interfaces1010.2Sensor Interface1010.2.1Internal Sensor-Interfaces1010.2.2External Sensor-Interfaces1110.3Actuator Interface1110.3.1Internal Actuator-Interfaces1210.3.2External Actuator-Interfaces1210.4Communication with other ECUs1310.5Signal / Bus Communication1310.6Additional Control Inputs1410.7Additional Control Outputs1410.8Further Signals1410.9Interaction with other items1410.10Requirements from other items1410.11Requirements on other items1510.12Allocation and distribution of functions among the items and elements involved1511LIMITATIONS1512References1513Stakeholders1514Approval1515Distribution161 Document Management and Configuration Control InformationCONTENTS OF THIS SECTION: This section identifies the release number, release date, and other relevant management and configuration control information associated with the current version of the document. Optional items for this section include: change history and an overview of significant changes from version to version.ReleaseDatePrepared ByReviewed ByRemarks / ChangesN.M.DD-MMM-YYYY2 Purpose The document “Item Definition” has the purpose to identify and describe a core- or application development at its initial phase whit focus on functional safety aspects.It shall create an adequate understanding of it with the task that each activity defined in the safety lifecycle of the ISO 26262 can be performed adequately. According to the standard, the item definition is to develop a description of the item with regard to its functionality, interfaces, environmental conditions, legal requirements, known hazards etc. The boundary of the system and its interfaces, as well as assumptions concerning other items, systems and components are determined. Based on the Item Definition, various functional safety work products such as the Hazard Analysis and Risk Assessment, safety concepts and safety analyses shall be carried out or derived from (see following figure).Fig. 1: Functional Safety Lifecycle (ISO 26262)Remark:In general the system is defined as entire application or function within a vehicle, including input signals, control function and output devices. For most applications/functions this can only be done by the VM (vehicle manufacturer). Further relevant information on input and output signals should be listed in this document but these are assumptions regarding the described elements. For these elements a separate Item Definition should created by the relevant supplier(s) or VM(s).3 ScopeCONTENTS OF THIS SECTION: This section explains the overall scope of this document. This document applies to the . 4 Acronyms & Definitions4.1 AcronymsAcronym / TermFull Form / DefinitionASILAutomotive Safety Integrity Level (ISO 26262)VMVehicle Manufacturer (also Original Equipment Manufacturer (OEM)SSPPSystem Safety Program Plan To Be Defined: Used as placeholder in the template document. Such placeholders should be replaced with appropriate project specific information when the template is tailored for the specific project.4.2 DefinitionsDefinitionsFull Form / Definition5 Functional DescriptionCONTENTS OF THIS SECTION: Within this section the different functions of the items are listed. These are the base for the subsequently performed Hazard and Risk Assessment.Remark: For all below listed functions of the item a short description of function details shall be created. This short description is helpful for a better understanding and eases subsequent analyses.5.1 Function 1: CONTENTS OF THIS SECTION: List of high level functional requirements / use cases of the item which shall includes the functional concept, describing the purpose and functionality, including the operating modes and states of the item.TBD: high level functional requirements / use cases5.2 Function 2: 5.3 Function n: 6 Non Functional RequirementsCONTENTS OF THIS SECTION: This section shall describe the non functional requirements. Non functional requirements are environmental and operational requirements and if applicable restrictions.6.1 Environmental ConditionsExample: The system is designed to operate in the temperature range of 40C to 120C. Function outside this temperature range cannot be guaranteed. Low temperature performance of the Hydraulic Control Unit has been proven according customer specification until -20C.6.2 Operational RequirementsExample: The operating voltage of the SCS system shall be from 9.0V to 16V 6.3 RestrictionsExample: The Hydraulic Control Unit (HCU) must be filled with brake fluid no later than six months after its date of manufacture because of negative characteristics of brake fluids due to ageing. 7 Legal RequirementsCONTENTS OF THIS SECTION: All legal requirements (laws and regulations) and national and international standards known at time of creation of the item definition. Example SCS Systems:Legal RequirementSourceTitleECE-R 13Braking on vehicles of categories M, N and O- Rev.6 - Amend.5 (11 May 2010) Table 1: Legal Requirements8 Applied Safety Standards and legal Safety RequirementsCONTENTS OF THIS SECTION: List section shall identify:- all known legal requirements (especially laws and regulations), national and international standards- behaviour achieved by similar functions, items or elements, if any;- assumptions on behaviour expected from the item; and- potential consequences of behaviour shortfalls including known failure modes and hazards. Example SCS Systems:Known legal Safety RequirementsReferenceCommentECE-R 13Braking on vehicles of categories M, N and O- Rev.6 - Amend.5 (11 May 2010) ECE-R 13H / Braking of passenger carsRev.1 - Amend.4 (11 May 2010)Table 2: Known Safety Requirements 8.1 Behavior achieved by similar functionsExample: No functions/applications known who can achieve similar behavior. 8.2 Behavior expected from itemExamples: a) The SCS is intended to be installed into the vehicle to improve active safety. It shall provide improved functionality to reduce crashes or mitigate the resulting severity due to enhanced controllability within unstable or dangerous driving scenarios.b) The ACU is installed on a vehicle to improve overall vehicle safety. It shall provide improved safety by lowering the severe injury and fatality rates for vehicle collisions. 8.3 Potential consequences of insufficient behavior incl. Failure modes and hazardsThe possible malfunctions, potential consequences and hazards will be addressd within the Hazard Analysis and Risk Assessment in detail.In general, folllowing malfunctions which may potentially lead to violate a safety goal shall be considered: Example: SystemFailure Mode IDPossible Failure Modes of the System (including sub-systems)SCS-FM-1Individual rear wheel underbrakedSCS-FM-2Individual rear wheel overbrakedSCS-FM-3Individual rear wheel lockedSCS-FM-4Rear axle underbrakedSCS-FM-5Rear axle overbraked9 Boundaries CONTENTS OF THIS SECTION: List section shall identify the boundary of the item, its interfaces, and the assumptions concerning its interaction with other items and elements, shall be defined considering:a) the elements of the item;b) the assumptions concerning the effects of the items behaviour on other items or elements, that is the environment of the item;c) interactions of the item with other items or elements;d) functionality required by other items, elements and the environment;e) functionality required from other items, elements and the environment; f) the allocation and distribution of functions among the involved systems and elements; andg) the operating scenarios which impact the functionality of the item.9.1 Internal Boundaries Example:Note: The following figure is based on preliminary architectural assumptions:Fig. 2: Internal Boundaries Internal BoundariesPhysical TouchingEnergy TransferMaterial ExchangeInformation ExchangeTable 3: Internal Boundaries9.2 External Boundaries Example:Fig. 3: External Boundaries External BoundariesPhysical TouchingEnergy TransferMaterial ExchangeInformation ExchangeElectric Park Brake (EPB)/Exchange of functional information such as release for EPB execution requests or status if EPB is implemented. (optional)10 InterfacesCONTENTS OF THIS SECTION :Within this section, more detailed descriptions of the item interfaces are listed. 10.1 Mechanical Interfaces Example:Fig. 4: Mechanical Interfaces Mechanical InterfacesProvided informationCommentBracket Mechanical fixation of SCS (ECU + HCU)The SCS itself is mechanically attached to the vehicle via bracket.Table 4: Mechanical-Interfaces10.2 Sensor Interface10.2.1 Internal Sensor-Interfaces Example:Fig. 5: Internal Sensor-Interfaces Internal Sensor-InterfacesProvided informationCommentPressure Sensor hydraulic pressure within HCUECU reads out hydraulic pressure sensor of HCU. Analogue SignalTable 5: Internal Sensor-Interfaces10.2.2 External Sensor-Interfaces Example:Fig. 6: External Sensor-Interfaces External Sensor-InterfacesProvided informationCommentWheel Speed Sensors (4x)wheel speeddirection of wheel rotationOptionalTable 6: External Sensor-Interfaces.10.3 Actuator Interface10.3.1 Internal Actuator-Interfaces Example:Fig. 7: Internal Actuator-Interfaces Internal Actuator-Interfaces(inside SCS)Provided informationCommentSolenoid ValvesElectrical control of solenoid valves within HCUTable 7: Internal Actuator-Interfaces10.3.2 External Actuator-Interfaces Example:Fig. 8: External Actuator-Interfaces External Actuator-InterfacesProvided informationCommentBrake BoosterIntervention response to DriverTable 8: External Actuator-Interfaces10.4 Communication with other ECUs Example:Fig. 9: Communication with other ECUs Communication with other ECUECU SCSSCS ECUCommentEPBto be defined if implementedto be defined if implementedNot considered here because EPB is not part of standard system.Table 9: Communication with other ECUs10.5 Signal / Bus CommunicationExample:CommunicationCommenthigh-speed CANTable 10: Signal / Bus Communication10.6 Additional Control InputsExample:Control InputsCommentInput force (brake pedal / brake booster)Table 11: Control Inputs10.7 Further SignalsThe following further optional in- and outputs shall be available:Example:Further SignalsCommentDiagnosisData LoggerTable 12: Further Signals10.8 Interaction with other itemsInteraction with other items has to be defined in Functional and Technical Safety Concept. No additional interaction requirements are assumed exept as described above.Example:Interaction with other itemsPurposeCommentBatteryElectric powerTable 13: Interaction with other items10.9 Requirements from other items Example:No requirements either than described above from other items are known or allocated to the System. It is assumed that the VM will analyze other items and perform adequate risk reduction to assure freedom of unreasonable risk associated with these items.After the Functional Safety Concept (FSC) is finished, (safety) requirements will be allocated the SCS coming from other items and elements invol