Item Definition & Concept-Phase Initiation
Master the zeroth step of ISO 26262-3, the item definition that seeds Clause 5 through Clause 7. Set the item boundary, interfaces, operating modes, and assumptions of use that every later hazard analysis and safety goal inherits.
- Chapters
- 10
- Chapters
- Clause 5 to 7 Steps
- 3
- Clause 5 to 7 Steps
- Hierarchy Terms
- 4
- Hierarchy Terms
- Visual Diagrams
- 6
- Visual Diagrams
- 01Why It Sets Everything Up
- 02What Is an Item?
- 03Contents of an Item Definition
- 04Interfaces & Assumptions
- 05Operating Modes & States
Why it pays for itself
Set an unambiguous HARA scope
The item boundary decides what the hazard analysis covers. Learn to draw it explicitly - which sensors, controllers, and actuators are in, which are out - so the HARA starts clean.
Author a complete item definition
A structured template covers functions, interfaces, operating modes, assumptions of use, and legal and environmental constraints - everything ISO 26262-3 Clause 5 expects documented before hazard analysis can begin.
Catch errors while they are cheap
Defects cost roughly 1x at requirements and 10x to 100x at integration. Boundary mistakes and undocumented assumptions propagate silently into ASIL and safety-goal gaps downstream.
What you’ll be able to do
Draw a precise item boundary
Decide what is inside and outside the item so the HARA scope is unambiguous and free of scope creep.
Author a complete item definition
Populate a structured template covering function, interfaces, modes, assumptions, and constraints before HARA starts.
Enumerate operating modes for HARA
Name and connect every mode and state so no mode-specific hazard scenario or exposure rating is missed.
Trace item content to safety goals
Follow the path from item function to malfunctioning behavior to hazard to safety goal with full traceability.
Scope new versus modified work
Apply lifecycle initiation and impact analysis to size the safety activities a change actually requires.
Run an item definition review
Use a structured checklist to catch undocumented assumptions, missing modes, and wrong-boundary anti-patterns.
Chapter by chapter
- 01
Why It Sets Everything Up
The item definition is the zeroth-order document that HARA, the Functional Safety Concept, and every downstream activity take as primary input, so errors here propagate silently.
- Primary input to HARA, FSC, TSC, and the safety case
- Garbage in, garbage out: silent ASIL and safety-goal gaps
- Defects cost roughly 1x at requirements, 10x to 100x at integration
- 02
What Is an Item?
Precise ISO 26262-1 vocabulary, item, system, element, and component, with the vehicle-level function criterion that decides which clauses and requirements apply.
- Item, system, element, and component definitions from ISO 26262-1
- Vehicle-level function criterion separates items from elements
- An item is vehicle-specific, so a SEooC can never be an item
- 03
Contents of an Item Definition
A structured template covering everything ISO 26262-3 Clause 5 expects to be documented before hazard analysis can begin.
- What Clause 5 of ISO 26262-3 actually requires
- Structured template spanning functional and non-functional content
- Readiness checklist gating the start of HARA
- 04
Interfaces & Assumptions
Where the item ends and the rest of the vehicle begins, plus what the item is allowed to assume about everything outside its boundary.
- Drawing the system boundary, what is in and what is out
- Interfaces to other items and the wider vehicle
- Assumptions of use and preliminary architectural assumptions
- 05
Operating Modes & States
Every mode the item can occupy must be named, defined, and connected, because each one generates its own hazard scenarios and exposure ratings.
- Standard mode taxonomy, off, init, normal, degraded, fault
- State transition requirements between modes
- How each mode shapes hazard exposure in HARA
- 06
Legal & Environmental Constraints
Regulations, standards, and the physical environment impose constraints on the item before any design decision is taken.
- Regulatory frameworks the item must satisfy
- Environmental operating conditions, temperature, EMC, vibration
- Reasonably foreseeable misuse as a HARA input
- 07
New vs Modified Items
Lifecycle initiation determines whether full development, partial re-development, or impact analysis applies, and scopes the safety activities accordingly.
- The lifecycle initiation decision per ISO 26262-2
- Three pathways, new, modified, and impact analysis
- Impact analysis scopes which safety activities repeat
- 08
From Item Definition to HARA
How the item definition content becomes the raw material for hazard analysis and how traceability from item to safety goal is maintained.
- Item content feeds malfunctioning-behavior derivation
- Deriving malfunctions at the vehicle level
- Traceability from item to hazard to safety goal
- 09
Mistakes & Checklist
The most common item definition anti-patterns seen in practice, paired with a structured review checklist to prevent them.
- The most dangerous item definition anti-patterns
- A structured review checklist to catch gaps
- Good practice summary before formal sign-off
- 10
Worked Example
A complete item definition for an Autonomous Emergency Braking (AEB) system, boundary through assumptions, then the first HARA hazard it enables.
- AEB item overview, boundary, and elements
- Interfaces, assumptions, and operating modes
- The first HARA hazard this definition enables
Not just text: the visual toolkit
Concept Phase Timeline
ISO 26262-3 concept phase laid out as Clause 5 item definition, Clause 6 HARA, and Clause 7 functional safety concept in sequence.
Item Boundary Diagram
The item boundary drawn explicitly, showing which sensors, controllers, and actuators sit inside versus outside the item.
Item, System, Element Hierarchy
Interactive hierarchy relating item, system, element, and component so safety requirements are allocated at the correct level.
Operating Modes State Machine
States and transitions across off, init, normal, degraded, and fault modes, each carrying its own hazard exposure.
Assumptions and Interfaces Tree
Assumptions of use and external interfaces branching out from the item boundary toward the surrounding vehicle.
Inputs and Outputs Matrix
Matrix mapping the item signal inputs and outputs against the neighboring systems they exchange with.
Item Definition for an Autonomous Emergency Braking (AEB) System
A full item definition for an AEB system that fuses front radar, camera, and a braking actuator interface, worked from boundary to the first hazard it enables in HARA.
- Item overview: AEB as a combination of systems delivering a vehicle-level braking function
- Item boundary and elements: radar, camera, fusion ECU, and braking actuator interface
- Interfaces and assumptions: signals to neighboring systems plus assumptions of use
- Operating modes: standby, active intervention, degraded, and fault handling
- Legal and environmental constraints bounding the operating envelope
- The first HARA hazard this item definition enables, including its operating situation
Unlock the full interfaces, modes, and first HARA hazard
Who this guide is for
- Engineers kicking off safety work for a new E/E vehicle function
- OEM concept teams preparing the inputs a HARA workshop needs
- Suppliers verifying the boundary and assumptions a customer item definition hands them
- Reviewers gating whether the concept phase is actually ready to start
Frequently Asked Questions
Common questions about Item Definition & Concept-Phase Initiation
Start the course today
A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 77-guide library. No credit card required.