Everybody wants to make money on what they sell. Companies that don’t make money quickly disappear. The FFC (full factory cost) of a product depends on both the development cost to produce the very first product and the manufacturing cost for each instance of that product thereafter. To some extent the development cost can dominate, as that has to be paid whether the product ever sells or not. To break even on a product, you need to at least get enough profit to return your development cost. For software there is no manufacturing cost as such and it is all development cost. For industrial safety systems the volumes are often low compared to standard products and so the development costs can weigh more heavily.
To quote the book Digital Woes – Why We Should Not Depend On Software when discussing methods required to develop safe software “These methods are arduous, time-consuming and expensive, so we are seldom willing to use them as extensively as we should."
Philip Koopman in his book Better Embedded System Software states “As your failure rate approaches never, the cost to create such a system approaches infinity. So, you need to pick an acceptable failure rate, and then figure out how you are going to achieve that realistic goal.” Later in the book he states, “Hiring good developers is always a good starting point for improving software quality” and if we assume good developers cost more than standard developers that is another cost to account for. He later states “improved software process reduces the number of defects that make it to the field. And, it’s the only way we really know to approach this problem.” Therefore, we need a good process and good people both of which can be expensive. People who know how to develop to these safe standards don’t grow on trees.
You could argue that everyone of our products should be the same high level of safety but one difference with functional safety is that a product not alone needs to be safe, but you need to have a lot of documentation and analysis to demonstrate that safety. If you can’t prove the safety it is worthless. It all costs money.
All this then begs the question, how much extra does it cost to follow a process such as that in IEC 61508, ISO 26262, D0178C or similar.
The direct cost includes:
Additionally, indirect costs include
In some markets these costs can be passed onto customers and in others they are table stakes (don’t bid for the business unless it is safety compliant).
This blog will explore data available in papers etc on the estimated costs of safety and will be followed up in two weeks’ time by what it may cost if you don’t spend money on safety.
Standard products are typically not good enough for use in safety applications as explained very nicely by the quote below.
See here for the source of the above which is an article on automation.com regarding Profibus. Of course, combinations of standard products either in a redundant configuration or with external diagnostics may be sufficient (taking care of safety at the system level) but that is not the topic under discussion today.
As a starting point let’s throw the following out there for discussion purposes.
If nothing else this estimate shows that the cost depends on the SIL/ASIL. In case anybody argues that there should only be one safety level such as SIL 3/ASIL D the standard has multiple safety levels because the experts on the standards committee recognized that some applications need more risk reduction than others and the goal is a sufficient level of risk reduction. For more details look at the ALARP principle.
A more comprehensive set of figures is given in a LinkedIn post by Dr. Hans Herrmann.
In this paper Dr. Hermann explains that the cost increase for safety is greater for low complexity products. This sounds like a surprise but he goes on to say that for high complexity products there is a need for rigor regardless of functional safety just to manage the project and that this management rigor overlaps nicely with the rigor required for functional safety.
These low complexity numbers here map well to the initial table already given but the numbers show a very small premium for safety in high complexity products.
Once you have decided to spend the money how do you get your customers to pay you extra for the safety product. To quote the book Software for Dependable Systems – Sufficient Evidence, “Economists have established that if consumers cannot reliably observe quality before they buy, sellers may get little economic benefit from providing higher quality than their competitors, and overall quality can decline." This is where external certification may come into play. Being able to say “certified for use in a SIL 3 system by <insert your favorite assessors name here>” may be a way to demonstrate the extra quality you have achieved.
Then there are those who will argue that functional safety doesn’t add any cost at all.
Such an argument could be based on the above from Nancy Leveson where because functional safety front loads a project with extra planning and upfront analysis, bugs are caught earlier where they are cheaper to fix.
Similarly, Hilderman and Baghai in their excellent book Avionics Certification page 44 claim the benefits of following D0-178B include:
From an IC suppliers point of view this may translate to less tape-outs but there is evidence available from a Mentor paper entitled Will safety critical design practices improve first silicon success that this isn’t true.
In summary the cost premium for safety is probably somewhere between 0% and 60% which isn’t of much help. I think there are just too many variables to give a neat answer and it will have to be calculated on a case by case basis largely using engineering judgement.
While this blog concentrated on the cost of adding functional safety to a product a future blog will look at the cost of not adding functional safety.
The point about the cost of safety being higher for simpler products may have some validity. In a previous role and company we found that our safety developments released faster and required fewer integration cycles and were much easier to maintain throughout their life than non-safety developments. We were developing complex systems both safety and non-safety. So I have seen firsthand how safety principles can potentially lower cost as complexity increases.
Good article to consider as a ball park estimation for project effort scoping. The biggest challenge is to achieve QM with ASPICE level2/3 in automotive industry. If can achieve this achieving Safety level is like considering one/few more functional requirements based on Hazard analysis which needs to be included in the Feature by Phase plan of the project. End game is to clearly show traceability from Safety requirements to safety Validation.