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”.
Can a project in production development project achieve functional safety requirements when its previous project in the advanced development project doesn’t consider functional safety ?
It is not easy to satisfy functional safety requirements in production project unless being prepared in advanced development project.
Or it will take longer than normal production project.
How to improve this situation?
We can get a hint from SEooC section in the ISO 26262-10, Clause 9
A picture below depicts SEooC development and Item development process
In general, advanced development project starts without customer, so its situation is similar to SEooC development situation. During the project many assumptions are made.
If Advanced Development Project follows like SEooC development process, Production Development Projects might reuse previous results. Additional tasks might be to compare between assumptions and requirements and to bridge gaps.