A discussion is just starting in the functional safety bubble as to whether and how it is possible to shorten or circumvent prescribed paths.
The reason for this seems to be that development projects are increasingly recognizing that functional safety with its specifications is very time-consuming, documentation-heavy and expensive, i.e. that the effort has a negative impact on the costs, deadlines and results quality of the project, simply causes it.
However, this is the biggest nonsense of all times
and serves only the purpose to have found finally again a culprit.
Deadlines are not met in 98% of projects anyway!
Budgets are exceeded in 80% of the projects anyway!
In 97% of the projects the quality of the results is not as agreed with the stakeholders!
And resource planning is off in almost every project!
Since these are the factors that determine the success or failure of a project, almost 94% of all projects fail; and this does not require any functional safety at all. They get that in the project also in such a way; promised.
But now the mindset, because Functional Security is relatively new to the project (next it will hit the Cyber Security guys, I predict; let's see), that this is exactly what leads to the mess; so in the whole project; in everything that doesn't fit.
There is no architecture and system engineering is not needed; it only costs time and money; and does not show results IMMEDIATELY.
So there is a huge effort in coordination rounds, meetings, discussions between the individual faculties, etc. to get the necessary clarifications and connections; of course without someone who has the hat on for it. The result is an unholy mess, no one can keep track anymore, everyone has coordinated and agreed on something with everyone else and written it down in countless documents, meeting minutes, minutes, LOPs and OPLs.
And now the FuSi engineer comes along and demands a cleanly specified architecture. And that too with a specified notation. The idiot. So now we're building a pseudo-architecture that doesn't fit at all. And who caused this? Exactly, the FuSi man. He did it!
The standards for functional safety do not demand anything new, especially not in process or organization. Especially in software development, the requirements are exactly what other software development standards require (look at IEEE).
But now we are supposed to follow the many, many standards in the development projects with consistency and discipline (by the way: in each case, specialists have thought about it and considered how it works best) and carry out the projects with sense and understanding; exactly in order; like a cooking recipe;
It would be even nicer, but it doesn't work for us because we are different, anyone could come along, we've never done it that way before.
The trick: when I point this out, everyone answers "Yes, that's right, you're right" and continues in exactly the same way.
So everything happens as usual and nothing changes, except that now the FuSi-Man is the culprit (in the past it was the Quality-Man, then there was the SPICE-Man, the whatever-Man). So let's think about how we can put him in his place and continue as before. Let's leave out the tests, and we will probably have to simplify the documentation, and we have done security mechanisms anyway, why show or prove that as well.
What bothers me so much in this discussion is the fact that in the past, we only talked about product performance in quality, i.e. whether the customer is satisfied and will come back or not. Here with Functional Safety, we are talking about whether or not we are killing someone, if necessary.
And from my point of view, that is something completely different!
With calculation, with intent, in order to save a project in the short term and to minimize the loss of face (one's own, mostly with those responsible for the project and their managers).
There I ask myself seriously, which values prevail there today even in the lower ranks of the organization hierarchies (that from a certain hierarchy level corruption, egocentricity and value decay is system-immanent, otherwise one would not be there) that it does not matter whether someone could come to harm or not.
And I find it particularly appalling that such discussions are driven by "experts" in functional safety, but I have already taken a position on these so called "experts" in an earlier blog.
By the way, I just cancelled a project in which I was involved, because the functional safety was completely faked.