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.
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.
ISO 26262 requires many kinds of documents. In my experience, engineers do not consider the scope. Thus it is apt to duplicate contents in many documents.
Assuming that such duplication is not allowed, and we have to think about what contents should be contained in specific document. These documents should be co-related each other, structures for documents are also necessary.
Topic that I pointed out is not engineer’s interest. It is prepared by functional safety manager or functional safety process organization group. If these consideration are not carefully applied, it will obviously have trouble with traceability, consistency and completeness attributes.
For example, can you distinguish between Software integration testing and Software testing? Can you trace from SW architecture to SW integration testing? and Can you trace from SW requirement to SW testing? What are difference between System requirements and SW requirements?
If they are not clear, systematic faults can be latent. As I mentioned in the past posting, engineers are not interested in this topic in general. Functional Safety Manager should care this kinds of fault by functional safety training or by safety plan.