ISO 26262 Edition 3: Part 3 and Part 4 – Item and System Level
By Johannes Hoffmann, SRES Senior Consultant and Vice-Chair of SCC/TC 22
This article examines the planned ISO 26262 Edition 3 updates to Part 3 (Item Level) and Part 4 (System Level), highlighting structural changes, new ADS and SOTIF considerations, and what these updates mean for functional safety activities across the system development lifecycle.
Looking to go deeper? SRES provides expert-led functional safety training, including certificate-based programs, as well as hands-on consulting support to help organizations implement ISO 26262 and related functional safety requirements across the product lifecycle.
ISO 26262 Edition 3 – Second Blog
In the previous ISO 26262 Edition 3 blog, we focused on its revised Part 1 (Vocabulary) and Part 2 (Management of Functional Safety) – exploring how new definitions like Automated Driving System (ADS) and fail-operational, the elevation of the Safety Manual to a normative work product, and the introduction of the Safety Policy. Find the previous blog here: ISO 26262 Edition 3: Standardization Timing, Vocabulary, and Management of Functional Safety.
In this blog, we will turn our attention to the next parts being reshaped under Edition 3. We review the planned changes to Part 3 (formerly termed “Concept Phase”, soon to be “Product Development at the Item Level”) and Part 4 (“Product Development at the System Level”). These updates include reorganized content, new ADS-related notes, and closer alignment with adjacent standards such as the ISO 21448 (Safety of the intended functionality – SOTIF) standard. We will also see a stronger emphasis on how E/E systems interact with other vehicle technologies.
Please note: all information in this blog is based on ongoing standardization work and may be subject to change.
ISO 26262 Edition 3 Part 3 – Product Development at the Item Level
Renaming “Concept phase” to “Product development at the item level”
In Edition 2, Part 3 in ISO 26262:2018 is called “Concept Phase”. In Edition 3, this is planned to be renamed to “Product Development at the Item Level”.
| ISO 26262:2018 | ISO 26262 Ed 3 | What changed? | |
|---|---|---|---|
| Part 3 | Concept phase | Product development at the item level | Renamed |
| Part 4 | Product development at the system level | ||
| Part 5 | Product development at the hardware level | ||
| Part 6 | Product development at the software level | ||
As a result, the work product “Functional safety concept” will become “Functional safety concept at the item level”. From a structural standpoint, the new name is more logical, but it will take time to get used to and will require effort to update or map work product titles and content once we officially transition to Edition 3.
Moving Vehicle-level Topics from Part 4 to Part 3
Another planned change in Edition 3 is to consolidate all vehicle level topics within Part 3. This affects clauses and sub-clauses in Part 4 that address vehicle level aspects, namely “Item integration and testing” and “Safety validation”, both of which are planned to be moved to Part 3. It’s important to note that the hardware-software and system integration and testing phases will still remain in Part 4 Clause 7. We will discuss this more later.
The table below highlights the planned updates to the Part 3 clauses and their naming:
| Part 3 – Product development at the item level | ||||
|---|---|---|---|---|
| Clause | ISO 26262:2018 | ISO 26262 Ed 3 | What changed? | |
| 4 | Requirements for compliance | |||
| 5 | Item definition | |||
| 6 | Hazard analysis and risk assessment | |||
| 7 | Functional safety concept | Functional safety concept at the item level | Renamed | |
| 8 | (does not exist) | Item integration and testing | Moved from Part 4-7.4.4 | |
| 9 | (does not exist) | Safety validation | Moved from Part 4-8 | |
SOTIF Considerations
ISO 26262 Edition 3 is intended to include explicit references to the Safety Of The Intended Functionality (SOTIF) standard, ISO 21448, addressing potential hazards caused by nominal performance or intended functionality. As a result, the item definition shall be expanded to also specify performance requirements and actuator capabilities to remain consistent with ISO 21448 Clause 5. The HARA should also account for hazardous events arising from nominal performance to remain consistent with ISO 21448 Clause 6. Reasonably foreseeable misuse was already included in the 2018 edition of the standard; however, this section has now been expanded with an explicit reference to ISO 21448 and further elaboration. For example, conditions where item failures occurring during hands-off vehicle operations can lead to hazards during handover to a driver should be considered within the HARA.
SOTIF and specifically ADS considerations are woven throughout Part 3 in examples and notes:
- The Operational Design Domain (ODD) must be factored into the HARA, capturing differences in controllability during normal driving versus a handover from ADS to a fallback driver.
- Even when ADS is available to reduce the risk for hazards to occur the controllability shall be considered with the driver in control, not the electronics. The ADS’ ability to respond quickly is then allocated as a hazard mitigation measure.
Other technologies
Other technology (OT) in the context of ISO 26262 is defined as technology different from electrical and/or electronic (E/E) systems. In the 2018 Edition examples are mechanical and hydraulic technology. Edition 3 adds chemical technology to the examples. Electric Vehicle (EV) batteries come to mind.
The 2018 version explicitly stated that “no ASIL should be assigned to safety requirements allocated to […] elements [of other technology].” In Edition 3 a safety attribute may be assigned to requirements allocated to OT. A safety attribute can be an ASIL, but with further explanation.
While OT were considered to some extent in the 2018 edition, their role in Edition 3 is planned to be significantly expanded. Information from OT must be included in the item definition and used as input to the HARA whenever the E/E system can address hazards from OT. A new subclause is intended to be added to discuss technology-related hazards – both those caused by malfunctioning OT elements and those not caused by malfunctioning, with electric shock given as an example. Hazards not rooted in technology – such as those arising from human foreseeable misuse – but for which E/E systems can reduce the risk (e.g. Automated Emergency Braking or AEB) is also a related category. However, these are already addressed (although implicitly) in the current edition of ISO 26262.
ISO 26262 Edition 3 Part 4 – Product Development at the System Level
Renaming as “Functional safety concept on system level” and moving vehicle level aspects to Part 3
Building on the changes in Part 3, the “Technical safety concept” is planned to be renamed “Functional safety concept at the system level”. Additionally, the sub-clause “Vehicle integration and testing” and clause “Safety validation” are slated to move to Part 3 as noted above.
| Part 4 – Product development at the system level | |||
|---|---|---|---|
| Clause | ISO 26262:2018 | ISO 26262 Ed 3 | What changed? |
| 4 | Requirements for compliance | ||
| 5 | General topics for the product development at the system level | ||
| 6 | Technical safety concept | Functional safety concept at the system level | Renamed |
| 7 | System and item integration and testing | System integration and testing | Renamed |
| 7.4.4 | Vehicle integration and testing | (does not exist) | Moved to Part 3-8 |
| 8 | Safety validation | (does not exist) | Moved to Part 3-9 |
These changes have editorial implications throughout Edition 3 Part 4, affecting several descriptions and figures. The principal implication for Part 4 is highlighted below:
SOTIF Considerations
A note is planned to be added that SOTIF measures can be integrated into the functional safety concept on system level.
Technical Safety Requirements and Technical Safety Concept are becoming one work product
The two work products “Technical safety requirements specification” and “Technical safety concept” are now combined into one work product “Functional safety concept on system level”.
Hardware-Software Interface (HSI) specification
A note has been added stating that the HSI can include hardware and software design requirements. The HSI remains an important, multi-faceted work product that both guides hardware and software design and documents their interaction. The update now places clearer emphasis on the ability of the HSI to contain hardware and software requirements.
System integration and testing
There are several refinements in this chapter.
- If Other Technologies (OT) are used, they must be considered during system integration and testing, including interactions between non-E/E elements and E/E components. This change is in line with the expanded focus on OT.
- Integration and testing can be confirmed by analyzing field data and considering the results of safety analyses and fault models. Analyzing field data is almost a necessary consequence of new technologies. Safety analyses shouldn’t just be completed and “shelved” during product development on the “left side of the development V” but should remain a living document throughout the verification and validation focused “right side of the development V”
- A verification report is now explicitly added to the system integration and testing sub-clause which didn’t exist before and could be considered an omission in the previous edition.
Disclaimer
This blog reflects both consensus positions from committee discussions and the interpretation of Johannes Hoffmann, member of the Standards Council Canada (SCC), in accordance with ISO’s communication policy.
Working group documents and meeting minutes are confidential and cannot be shared externally.
The topics highlighted in this blog – and the emphasis placed on them – are based on Johannes’ personal experience and judgment.
Need Help with ISO 26262?
Interested in training on ISO 26262 or other automotive safety standards?
🔗 Functional Safety Training by SRES
Need direct support or consulting?
🔗 Contact SRES
Have insights or questions? Send us an email at info@sres.ai or leave a comment below—we welcome thoughtful discussion from our technical community.
Interested in learning more about our approach? Explore why teams choose SRES training and how we help automotive organizations with consulting support across functional safety, cybersecurity, autonomy safety, and EV development.
