Category Archives: 07. Validation

Safety Analysis – FTA and FMEA

I’m not sure my opinion is aligned to ISO standard, but I believe it’s practical.

When starting safety analysis, I’m recognizing that it can be used as eliciting additional safety requirement. For me, FMEA(Failure Modes and Effect Analysis) is more comfortable.

FMEA is an activity of finding SPF, while FTA(Fault Tree Analysis) is finding both SPF(Single Point Fault) and MPF(Multiple Point Fault). If FTA can reveals SPF only, I’m not sure why I conduct FTA. Based on FMEA, FTA can be extracted automatically. If additional information about SM are considered in FMEA then some MPF can be drawn in FTA. So I believe that the purpose of FTA is to find MPF, not SPF.

I have one more comment about FTA.

It is a kinds of logical expressions. So MPF can be extracted by analyzing identified safety requirements. Let’s assume that Safety Requirements are specified as follows;

Top Requirement = AND(Group_REQ1, Group_REQ2, Group_REQ3)

Group_REQ1 = OR(REQ11, REQ12)

Group_REQ2 = AND(OR(REQ21, REQ22), OR(REQ23, REQ24))

Group_REQ3 = OR(AND(REQ31, REQ32), AND(REQ33, REQ31), REQ35))


Violation of Safety Goal is Negation of Top Requirement.

Based on this, Violation of SG can be expressed as logical expression.

To find CF, CCF, and MPF, these logical expression should be prepared, and it is during safety requirement elicitation phase.

Safety analysis in the architecture level is a deeper level of elicitation of safety requirement.

There is a mechanical procedure of drawing FTA from architecture such as Hip-Hops method. But its demerit is they do not consider logically expressed safety requirements, so constructing logical expression is weak point. It surely reviewed by safety analyzer.



Why are you born? Meaning of safety requirement existence

If some requirement are regarded as safety attribute, it means that in-achievement of safety requirement leads to threaten safety.

The rationale is explained in the somewhere. I believe that system FTA or system FMEA are proper means of why they are born.

After they are identified, safety engineers shall suggest methods how to handle them. Their suggestions are called safety mechanisms in ISO standard.

Sometimes, engineers forget this simple principle. So non-safety related requirements are mis-perceived as safety requirements.

All safety requirements have birth-registered? Unregistered has a potential to threat safety. Don’t forget to register. It is natural like happened in our society.

logical leap in FTA

When I review a system FTA, I feel that the system engineer has a trouble with analyzing cause of failure events.

In fact I recall a book which title is “If It’s Raining in Brazil, Buy Starbucks.”

Of course it is an investing book. It was useful to me. But general people don’t usually think that there is not close association between ‘raining in brazil’ and ‘profit increase of Starbucks’. It looks like that there is logical leap.


To drawing FTA is a kind of logical thinking. It should be followed by logical rule.

  1. FTA shall make sense. It is too obvious.
  2. there is no leap between cause and result. if the distance is too big, it looks like
    I ate breakfast, so I dead. It might be a true, but there are big leap.

common mistake is to think that causes of a safety goal are “stack overflow”, “divide by zero”.

They might be causes. But ….. it doesn’t look convincing.

Such FTA can be applicable for every system. So FTA has no additional benefit, if we drawing FTA in this way. Then, all we have to do is to find such errors.

My opinion is that don’t do that. You have to draw FTA using system architecture not knowledges of “common errors”.