When beginning to develop any feature, whether it will ultimately involve functional safety attributes or not, where does one start? Using a systems engineering methodology is a good place.

In the ISO 26262 Standard this is covered in part 3 clause 5, the Item Definition. In this clause, the standard provides numerous hints as to what to include in the Item Definition. However, engineers often tend to provide too much information. This is especially true when ISO 26262 is being applied to an already existing product. In this case, the temptation is to list “everything”.

A guiding principle that may help here is to think about what information is needed to perform the Hazard Analysis and Risk Assessment. In preparing to do the HARA, we need to identify malfunctions at the “vehicle” level, i.e. those that the driver would experience.

With this in mind, what is needed in the Item Definition are three main things:

  • What is the purpose of the feature?
  • What is the functionality of the feature?
  • What is an implementation independent boundary diagram?

In systems engineering vocabulary, the boundary diagram is often referred to as a context diagram. It includes the set of information needed to perform the functionality from various high level sources, i.e. vehicle speed source, etc. Actual sources and specific electronic modules are the subject of the implementation specific architecture, developed for the Technical Safety Concept. The purpose and functionality descriptions in the Item Definition are natural language descriptions of the desired capabilities of the feature.

Following this line of thinking will allow one to quickly develop the required inputs needed to perform the HARA. In the HARA, we are interested in how the intended functionality can malfunction as experienced at the vehicle level. These malfunctions produce the hazards and in combination with the vehicle operational scenarios produce the hazardous events which get classified in the HARA. Implementation details of the feature are not needed in the Concept Phase of the safety analysis. In fact, too much detail can slow down the process and delay progress. Keep it high level and keep it simple are the guiding thoughts that will get the project to the detailed design phase quickly.

Leave a Reply.

You can use the following tags to spruce up your comments: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>