Identification of Safety requirements in a product requirements

My main job is to review all kinds of functional safety documents. Although I don’t know much detail of products, I can help engineers to make our products more safer.

Identifying safety requirement is a 2nd step of functional safety activity. Of course, 1st step is safety planning, and it is very important but many people don’t realize its importance.

Anyway, when I review requirements that regards as ‘safety’, I always ask this question to engineers;

“If this requirement doesn’t meet, it directly leads to violate safety goal?”

If it is safety requirement, it shall be always “yes”, but I experienced to get an answer “no” in many cases.  Then it is not real safety requirement.

Engineers seem to have a custom to identify them as ‘safety requirement’ which look ‘critical’.

For system which control vehicle, it is critical not to ‘sleep’. But not always for system which report to system which has a responsibility to control.

For control system, detecting who is liar is very important because it directly leads to incorrect decision, which results to control unsafely. Of course ‘not to sleep for a long time’ is also important.

But these principles are not always applicable to “reporters”. To tell a lie is worst. To tell nothing is better.

So, “to be honest” is a very important characteristic for “Subordinates”

To summarize, ask this question always. Do Not determine it with your custom.

the question is “If this requirement doesn’t meet, it directly leads to violate safety goal?”


“Doing Nothing” is better than “Doing Wrong”

It is related to identify safety requirement. For safety related systems, to avoid unintended function is essential. But I sometimes find that some engineers have a rule that watchdog function shall be regarded as a safety function.

Is it really true?

It will be critical for company’s financial profit because of quality problem. It surely might be a problem but in safety aspect watchdog is not always related to safety.

Let’s assume that there is a system(sys_A) that report some information to other system(sys_B) which controls vehicle’s movement. A requirement allocated to sys_B is determined as ASIL C, while sys_A is determined as ASIL A or B.

Let assume that sys_B can perceive Sys_A’s liveness by monitoring message that Sys_A sent.

In safety aspect, Sys_A’s safe state might be dead state. It means that when Sys_A detect a fault that leads to violate safety function that is allocated to Sys_A, it is better to do nothing than do wrong.

In this case, what do you think that watchdog fault is safety related or non-safety related ?

In some cases, I found that watchdog function is not a safety function. It is just a general function.

Identifying safety requirement is so important for functional safety manager. Functional safety engineer or functional safety manager have to consider it carefully.

It surely leads to engineers confusing when they regard non-safety functions as safety function. All safety activities after requirement phase will be messed up because there will not be consistent in their work products. Their safety arguments will be no longer convincing.



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”.