October 17
32
t
ooLs
& s
oFtwArE
associated with this gap? When organizations
attempt to measure the cost of software devel-
opment, they tend to look at general metrics:
development time for the engineers; testing
time for QA; building materials in the form of
acquiring tool licenses, compilers, and other
infrastructure components. These are import-
ant metrics, but often overlooked are the costs
of failure. If the software in the braking system
fails, what will it cost the business in terms of
rework, recalls, audits, litigation, and loss of
stock value? What if there is a loss of life?
We argue that the cost of quality is the cost of
developing and testing the software, including
all the normal metrics we identified plus the
very tangible costs associated with a failure
in the field. Defects cost automakers a lot of
money. The NHTSA estimates that recalls and
fixes across the industry cost automakers $3
billion annually. When it comes to the cost of
software-related issues, a 2005 estimate from
IEEE put the cost to manufacturers at $350
per car. When you consider the low profit
margins across a line of vehicles, it’s conceiv-
able that a serious enough software defect can
severely hurt the business.
The bottom line is important, but even more
important is that people can become seriously
injured or even die as a result of a software
defect. And it doesn’t matter how far down
the supply chain the defect may originate,
defects and all their associated consequences
become the responsibility of the automaker.
As such, any cost analysis around software
development needs to take the potential costs
of failure into consideration. We’ve argued
that the complexity of the tiered supply chain
for automotive software contributes to the
overall risk associated with safety-critical
systems. We’ve also reiterated the potential
costs to automotive businesses. But there’s
another dimension to this issue that reside in
the cultural difference between engineering
and software development. Software devel-
opment is almost never engineering. That is,
certain concepts from engineering principles,
such as repeatability, well-exercised best prac-
tices, and reliance on building standards have
yet to become firmly established in software
development. Additionally, training for soft-
ware developers can be inconsistent - even
non-existent - and organizations would have
to go through great lengths to verify that their
developers possess adequate knowledge to
build safety-critical software.
This is in contrast to engineering in which the
attitudes, mindsets, and history of the disci-
pline enforce a process that is less prone to
defects when compared to software develop-
ment. That is not to say that engineers know
what they’re doing and software developers
don’t. Rather, it’s to say that automotive engi-
neering as a field is twice as mature as software
development, and that the intangible, tempo-
ral nature of software perpetuates a cavalier
attitude in which if it works, then it’s done.
The emphasis in software development is
around faster delivery and functional require-
ments - how quickly can we have this func-
tionality? There is little incentive from
management to implement sound engineer-
ing practices into the software development
lifecycle. Achieving functional safety in soft-
ware requires operationalizing certain engi-
neering principles: functional safety must
be proactive, processes must be controlled,
measured, and repeatable, defects should be
prevented through the implementation of
standards, testing must be effective, determin-
istic, and should be done for complex mem-
ory problems.
The good news is that the attitudes around
software development have been evolving.
ISO 26262, MISRA, and other standards
seek to normalize software development
for automotive applications by providing a
foundation for implementing engineering
concepts in software development processes.
Some organizations view compliance with
ISO 26262 and other standards as an over-
head-boosting burden without any direct
value, but the truth is that the cost of fail-
ure associated with software defects is much,
much greater than the cost of ensuring qual-
ity. As in electrical standards that specify a
specific gauge of wire to carry a known volt-
age, coding standards can provide the guide-
lines that help avoid disaster.
Figure 1. The amount of software defects has doubled in the last years, and NHTSA estimates that
recalls and fixes cost automakers $3 billion per year.
Figure 2. In modern cars, numerous complex computer systems are installed, with well over a
hundred ECUs processing millions of lines of code.
