Reference — ISO 26262:2018
Work products, part by part — what I've actually built.
ISO 26262 is organized into twelve parts, each defining work products a functional safety engineer is responsible for producing or contributing to. This page maps my experience against the standard, part by part, including where I have no direct experience, rather than implying breadth I don't have.
Every row carries a status. “Owned / Co-owned” and “Familiar” describe professional work on OEM and Tier 1 supplier programs. “Independent study / ongoing development” marks topics I'm learning and intend to demonstrate through independent projects; it is not professional experience. Every row is also tagged by what it is: a work product the standard names, an analysis activity that produces content for one, supporting evidence that substantiates compliance, or a supporting process.
The homepage groups this work into four engineering domains. They map to the parts below as follows: 01 Vehicle and system is Part 3 (vehicle level) and Part 4 (system level); 02 ECU software is Part 6; 03 ECU hardware is Part 5; 04 Semiconductor is Part 11, alongside Parts 5 and 6. Software and hardware are parallel branches of the ECU level, not sequential stages.
Representative Programs
- ASIL-D Restraint Control System
- Autonomous Driving Features
- Digital Mirror
- Power Window
- Clutch Actuator
Vocabulary
Defines the terms used across the standard. No work products come from this part; it is the shared language the other parts depend on.
No work products applicable.
Management of Functional Safety
Governs how safety is planned, tracked, and confirmed across a project and an organization: the paperwork that makes safety auditable, not just achieved.
| Work product / activity | Status |
|---|---|
Safety planWork product Planned safety activities, milestones, and responsibilities; created the safety plan for a Tier 1 supplier program. | Owned / Co-owned |
Safety caseWork product Prepared, maintained, and released the ASIL-D safety case for a Restraint Control System: safety arguments, evidence, and compliance justification, including requirement coverage and a risk assessment for anything not covered. | Owned / Co-owned |
Confirmation measures (confirmation reviews, functional safety audit, functional safety assessment)Work product Took part in confirmation measures on the safety work products I prepared. | Owned / Co-owned |
The vehicle-level concept phase: the item is defined, its hazardous events are assessed as they affect the vehicle, and safety goals and the functional safety concept are set before any hardware or software design begins.
| Work product / activity | Status |
|---|---|
Item definitionWork product Scoped and defined items across restraint, ADAS, and closures and mirrors features. | Owned / Co-owned |
Hazard analysis and risk assessment (HARA), including safety goalsWork product Identified hazardous events and derived ASIL ratings from severity, exposure, and controllability across ASIL-A to ASIL-D programs. | Owned / Co-owned |
Functional safety concept (FSC)Work product Developed FSCs that translate safety goals into functional safety requirements. | Owned / Co-owned |
System-level development: the functional safety concept becomes a technical safety concept and system architecture, with requirements traced downward and verification traced back up through integration and safety validation.
| Work product / activity | Status |
|---|---|
Technical safety requirements and technical safety concept (TSC)Work product Derived technical safety requirements from the functional safety requirements and allocated them to the system design. The technical safety concept is the specification of those requirements and their allocation. | Owned / Co-owned |
System-level FMEAAnalysis activity Linked and traced component-level FMEAs to the system FMEA, including variant management across application projects. | Owned / Co-owned |
System-level fault tree analysis (FTA)Analysis activity Evaluated safety goal violations, single-point faults, and latent faults at the system level. | Owned / Co-owned |
Safety requirements traceability and test coverage metricsSupporting evidence Calculated and maintained bidirectional traceability from safety goals to verification evidence. | Owned / Co-owned |
Item integration and testing; safety validationWork product Contributed to V&V reports and reviewed results; I did not own vehicle-level validation execution. | Familiar |
Where safety goals become hardware-level guarantees: diagnostic coverage, redundancy, and quantified residual risk. This is the part of the standard closest to my day-to-day work.
| Work product / activity | Status |
|---|---|
Hardware safety requirements (ECU level)Work product Requirements derived from MCU safety manuals and assumptions of use, to implement selected safety mechanisms in the ECU architecture. | Owned / Co-owned |
Hardware safety analysis (FMEA and FTA)Analysis activity Component-level and system-level analyses that feed one another, from failure mode to safety goal. | Owned / Co-owned |
ECU-level safety mechanism analysisAnalysis activity Power supply monitoring, sensor interface safety, MCU peripheral diagnostics, SPI communication integrity, and watchdogs and external monitoring circuits, analyzed as safety mechanisms in the ECU architecture. | Owned / Co-owned |
FMEDAAnalysis activity Failure-mode distribution, diagnostic coverage per safety mechanism, and the single-point, residual, and latent contributions. ISO 26262-5 defines what must be evaluated; FMEDA is the usual industry method for producing it. | Owned / Co-owned |
Hardware architectural metrics (SPFM, LFM)Supporting evidence Calculated and assessed single-point fault and latent fault metrics against the targets for the ASIL. | Owned / Co-owned |
Probabilistic metric for random hardware failures (PMHF)Supporting evidence Evaluated the random hardware failure target for safety goals alongside the architectural metrics. | Owned / Co-owned |
Diagnostic coverage evaluation and residual fault analysisAnalysis activity Justified diagnostic coverage for each safety mechanism and analyzed the faults that remain; where a mechanism was not implemented, identified the compensating system-level mechanism and recalculated. | Owned / Co-owned |
MCU selection and safety mechanism integrationAnalysis activity Identified the right MCU for the design and evaluated mechanisms for the CPU, memories, DMA, watchdogs, clock monitoring, communication interfaces, and other peripherals, including feasibility and applicability in our configuration. | Owned / Co-owned |
Safety-related pressure sensor evaluationAnalysis activity Evaluated sensor diagnostics, plausibility checks, and the sensor-to-MCU communication path as a single chain. | Owned / Co-owned |
Analysis of dependent failures (hardware)Analysis activity Cascading and common-cause analysis at the hardware level; see also Part 9. | Owned / Co-owned |
Hardware design specificationWork product Consumed and reviewed hardware design from suppliers; I did not author circuit-level design. | Familiar |
- Identify the candidate MCU and read its safety manual and safety package.
- Map each vendor safety mechanism to the failure modes it is claimed to cover.
- Assess whether each mechanism is applicable and feasible in our configuration, and derive the assumptions of use as ECU requirements.
- Where a mechanism is not implemented or not sufficient, select a compensating mechanism at the system level.
- Quantify diagnostic coverage and residual risk, and evaluate the metrics against the ASIL targets.
- Record the result as evidence in the safety case, including a risk assessment for anything that remains uncovered.
Where the standard becomes exacting about how software can be trusted not to interfere with itself. My role here is specifying, analyzing, and integrating software-related safety mechanisms into the ECU safety concept; it is not embedded software implementation.
| Work product / activity | Status |
|---|---|
Software safety requirements specificationWork product Authored software safety requirements as part of feature-level safety work products (SRS). | Owned / Co-owned |
Software dependent failure analysisAnalysis activity Cascading fault analysis, freedom from interference, and common cause analysis at the software level. | Owned / Co-owned |
Software safety mechanism specification and analysisAnalysis activity Watchdog supervision, communication protection and end-to-end data integrity, diagnostic handling, and fault reaction and safe-state transitions, specified and analyzed at the ECU level. Not implemented in code. | Owned / Co-owned |
Software architectural and unit designWork product Reviewed software architecture for safety-relevant partitioning; I did not author unit-level design. | Familiar |
Software verification (unit and integration testing)Work product Contributed to V&V reports; I did not execute unit test suites directly. | Familiar |
Embedded software coding and implementationEngineering activity No hands-on embedded software implementation. | No direct experience |
Production, Operation, Service, Decommissioning
Covers safety-relevant controls in manufacturing and field life: production control plans, service instructions, decommissioning.
No direct experience. My work has been concentrated in the concept-through-verification phases.
Supporting Processes
The cross-cutting disciplines (requirements management, configuration management, interfaces, tool qualification) that keep Parts 2 to 7 trustworthy.
| Work product / activity | Status |
|---|---|
Development interface agreement (DIA)Work product Developed DIAs with MCU and semiconductor suppliers and other development partners, defining responsibilities for safety activities, evidence exchange, and assumptions. | Owned / Co-owned |
Supplier safety documentation and SEooC integrationSupporting evidence Reviewed supplier safety manuals and safety packages, including those from MCU suppliers, and checked that SEooC assumptions are satisfied in the ECU context. | Owned / Co-owned |
Safety requirements management and traceabilitySupporting process Managed safety requirements end to end in IBM DOORS and Codebeamer. | Owned / Co-owned |
Problem resolution and root cause analysisAnalysis activity 8D, Fishbone, and Is/Is-Not methods. These are general problem-solving methods rather than ISO 26262-defined work products. | Owned / Co-owned |
Configuration and change managementSupporting process Worked within established processes; I did not own a configuration management plan. | Familiar |
Qualification of software toolsSupporting process No direct ownership of tool qualification work products. | No direct experience |
ASIL-Oriented and Safety-Oriented Analyses
The analytical toolkit that runs through the other parts, and where much of my work sits.
| Work product / activity | Status |
|---|---|
Dependent failure analysis (DFA)Analysis activity Hardware and software DFA, including cascading failures and common-cause failures. | Owned / Co-owned |
Freedom from interference and coexistence of elementsAnalysis activity Freedom-from-interference analysis at the software level. | Owned / Co-owned |
Safety analyses (FMEA, FTA)Analysis activity Recurring work across system, hardware, and software levels. | Owned / Co-owned |
ASIL decompositionAnalysis activity Applied within HARA and safety concept work. | Owned / Co-owned |
Guideline on ISO 26262
An informative guideline on interpreting and applying the normative parts. I refer to it regularly; it produces no work products of its own.
No work products applicable. Used as an interpretive reference throughout.
Guidelines on Application of ISO 26262 to Semiconductors
Domain 04 · Semiconductor Functional SafetyExtends the standard's hardware guidance to semiconductor devices: the layer between Part 5 and the silicon. I split this part in two, because my professional work and my current study are different things.
Professional semiconductor integration experience
Professional experienceWorking with semiconductor devices as an integrator at the ECU level.
| Work product / activity | Status |
|---|---|
MCU safety manual evaluationAnalysis activity Reviewed multicore MCU safety manuals, identified the relevant blocks for the ECU design, and derived assumptions of use. | Owned / Co-owned |
Safety mechanism applicability and feasibilityAnalysis activity Judged which mechanisms apply in our configuration, and what must compensate at the system level when one does not. | Owned / Co-owned |
SEooC integration assumptionsSupporting evidence Checked that the assumptions a supplier made for an out-of-context element are met in the ECU. | Owned / Co-owned |
Semiconductor supplier coordinationSupporting process Coordinated safety responsibilities and evidence exchange with semiconductor suppliers through DIAs. | Owned / Co-owned |
Hardware failure modes and diagnostic coverage (integrator view)Analysis activity Assessed device failure modes and the diagnostic coverage claimed for them, as used in the ECU-level FMEDA. | Owned / Co-owned |
ECU-level integration and safety evidenceSupporting evidence Assembled the integration evidence that goes into the ECU safety case. | Owned / Co-owned |
Authoring a semiconductor safety manual or safety case as the device manufacturerWork product Not part of my experience. I consume vendor documentation as an integrator; I have not authored it. | No direct experience |
Semiconductor design and verification topics under development
Independent studySubjects I'm studying and intend to demonstrate through independent projects. This is not professional semiconductor design or verification experience. See the engineering explorations.
| Work product / activity | Status |
|---|---|
RTL safety architectureAnalysis activity Hardware versus software safety mechanisms, redundancy and checker structures, and lockstep and self-test concepts at the logic level. Exploration 1. | Independent study / ongoing development |
IP-level safety analysisAnalysis activity Failure modes, failure rates, and safety mechanisms for an individual IP block such as a DMA controller. Exploration 2. | Independent study / ongoing development |
Fault injection methodologyAnalysis activity Stuck-at and transient faults at RTL; observing detection, latency, and propagation. Exploration 3. | Independent study / ongoing development |
Semiconductor-level FMEDAAnalysis activity Failure-mode distribution and diagnostic coverage at IP and device level, and how verification evidence relates to the assumed coverage. | Independent study / ongoing development |
Physical implementation considerationsAnalysis activity Package-level electrical failure modes, pin-related failures, and physical common causes. | Independent study / ongoing development |
Fault detection and propagation through hardwareAnalysis activity How a fault travels through logic to an observable output, and what contains it. | Independent study / ongoing development |
Adaptation for Motorcycles
Adapts the standard to motorcycle-specific architectures and risk profiles.
No direct experience. My program work has been in passenger vehicle systems.
Tools
The platforms this work has run on, across requirements management, hardware safety analysis, and systems modeling.
- IBM DOORS
- Codebeamer
- Medini Analyze
- IQRM
- MagicDraw / Cameo