Category Archives: 61508

Let’s think about the order of system FMEA and HW/SW FMEA

I got inspired from ECSS-Q-ST-30-02C, and I post it regarding this topic.

I’m not sure how many FMEAs are required, but let’s assume that there are 3 kinds of FMEAs; System FMEA, HW FMEA and SW FMEA.

In this case, which FMEA should be performed at first ?

My conclusion is that System FMEA should be performed at last, and HW and SW FMEA should be  performed at first.

The reason is that FMEA is bottom up approach, and If we consider to begin System FMEA and then perform HW and SW FMEA, it is hard to bridge between System level and lower level(SW, HW).

System FMEA is upper level of analysis, and HW and SW FMEA is lower level of analysis. If FMEA is bottom up approach, then why we do not perform HW and SW FMEA at first?I

What I perceived from my colleagues is that some seem to agree my opinion even though we didn’t do so far, and the others shows their opinion that it is not reasonable; it is not possible.

I don’t want to persuade persons. They really can feel comfortable to do so. So I should not neglect their opinion. Anyway in this situation, I have to set a verification criteria(or principle that they should follow) to keep high quality of FMEA results.

Though I assumed that there are 3 kinds of FMEAs in the beginning, but I don’t like this practice, actually. Maybe I’ll post about this topic in the next.



Specification of Safety Requirements

In the ISO 26262, there are 4 kinds of safety requirements – FSR, TSR, SSR and HSR. But I’d like to recommend that you don’t have to divide into 4 pieces exactly.

FSR can be defined conceptually from customer side, and safety requirements can be identified for supplier side. If system is complex (i.e, a system of systems) it can be possible to consider a system that consists of sub-systems that consists of TSR, SSR and HSR. In this case, it is not a good practice just to think that level of safety requirements are system level, SW and HW level. if you have such category, it will prohibit to manage safety requirements. Managing in the unit of sub-system is easier.

To specify safety requirements, it should be identified from product requirements.


if they are identified, then detailed review with safety aspect should be perform (so we call it safety analysis)

Proper fault model and fault propagation model is prerequisite to conduct it.


After impact of considered failure mode, remedy(safety mechanisms, or additional processes) needs to be decided. So how to detect faults and how to handle faults should be considered.



All of safety mechanisms needs to be traceable to results of safety analysis, and all of evidence for identified additional processes needs to be traceable. They are required in order to build safety case.

Specification for A-SPICE or ISO 26262

In the A-SPICE, there are various kinds of requirements; System Requirement, System Design, SW Requirement, SW architecture, SW Unit design. ISO 26262 requires similarly .

To manage traceability rigid decomposition of requirements into these are beneficial.

You can integrate all kinds of requirements into one documents. Then you will face a fact that managing traceability is not a easy task.

To specify, it requires different kinds of technical skills. It is not related engineering knowledge. It is closely related to logical thinking and writing technique.

You may wonder if I emphasize that writing technique is core skill to comply engineering process, because writing technique seems not to be related to engineering knowledge.

To Know it and to explain what you know are different. Sometimes it takes much time or infinite time to understand a document, because it is hard to understand.  Requirement obfuscation is not good for team’s productivity and team’s communication. It also makes hard to achieve A-SPICE or functional safety standard.

So, engineers are required to learn how to specify requirements. It shall be educated.

To engineers, please do not blame readers because of their poor engineering knowledge, and do not think that it is a reason they do not understand your document. It is not good.

For reference,

  1. Requirements_Engineering_Management_Handbook explains how to specify requirements.
  2. safety driven model based system engineering methodology(Part 1, Part 2) shows example.
  3. AUTOSAR Use Case Example CP Release 4.3.1