(Paper comment) Integrating STPA into ISO 26262 Process for Requirement Development

Likewise my previous posting, it give us to understand what STPA is and why it is necessary. In my understanding, it is more useful to OEM than suppliers. STPA handles vehicle level safety analysis.

If OEM wants to invent new operation concepts for autonomous vehicle, safety analysis in the vehicle level is necessary. ISO26262 has a weak point.

It explains well how weak point of ISO 26262 can be covered by STPA and how they can be integrated together.

Additionally, very interesting materials are referenced in the reference. In the next, I’d like to study a free program for safety hazard analysis tool – SafetyHAT. (Link; https://www.volpe.dot.gov/infrastructure-systems-and-technology/advanced-vehicle-technology/safetyhat-transportation-system)

 

 

 

(Paper Comment) A System Safety Perspective into Chevy Bolt’s One Pedal Driving

It explain when we should invent “new operation concept” what needs to be considered.

The author of this paper seems to be an safety engineer in GM, and he may be involved in new concept car. I understand that in this author’s circumstance why SOTIF is considered and other considerations are necessary. I read a STAMP/STPA approach in couple of years ago, but I understand the concept better. It is very useful approach for OEM to have a new operational concept.

If I compare ISO26262 and STPA, ISO 26262 focus on the “item”. It is a subsystem in the vehicle level. Even though HARA is considered a risk in the vehicle level, main focus is “item”. ISO 26262 is hard to cover when new operation concept is invented. Operation concept should be handled in the vehicle level, and STPA considers safety aspect in the vehicle level. Any it is very helpful idea to suggest that unsafe can be happen not only fault in subsystem, but also incorrect interaction between subsystems.

Anyway it is very helpful paper. I’d like to recommend to read it essentially.

 

 

(Paper comment) Toward a Framework for Highly Automated Vehicle Safety Validation

When I read this paper, I focus on the term “validation”. “Verification” is different “Validation”. Verification does not consider whether requirement is not wrong. It just checks if its implements meet its requirements. Weak point of verification can be revealed when the requirements are wrong or incomplete.

My colleague told a story that his customers asked to produce product. They gave a verified SW model and requirement. Even though it worked in the customers’ system architecture, it cannot be guaranteed that it also works in the new system architecture, obviously. He received verified model and verified again, but it failed eventually.

Automated vehicle requires new operation concept. In the CNS/ATM domain, they call it ConOps(Operation concepts). It is higher hierarchy than Item(system) development process. For convenience,  I’d like to distinguish terms with hierarchy.

Vehicle consists of many items. Item is a product that is developed by supplier.

Safety depends on ConOps. How can we validate safety? It means that how ConOps is matured.

And one more comment is that OEM should consider that vehicle accident can be  inevitable, then how OEM should avoid legal responsibility. Enough evidences shall tell that OEM has no fault.