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.
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.
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.
- FTA shall make sense. It is too obvious.
- 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”.