October 17
31
t
ooLs
& s
oFtwArE
How to leverage automotive software
development standards to mitigate risk
By Arthur Hicken,
Parasoft
This article discusses some of the
issues contributing to automotive
software complexity, as well as the
risks associated with automotive soft-
ware development. We’ll also discuss
how implementing known
development best practices, such as
ISO 26262, helps organizations
mitigate those risks.
When average non-engineer consumers
think of electronic systems in automobiles,
they likely think of integrated GPS, info-
tainment systems, and probably some vague
notion that there is a computer somewhere
in the car controlling some of the safety fea-
tures. Of course, the reality is that modern
cars are significantly more complex with
software playing an increasingly larger role
in all facets of functionality, including many
safety-critical functions. In fact, cars have
been leveraging electronic systems for critical
functionality for decades, and market changes,
such as the push toward an Internet of Things,
have nudged automakers towards embedding
a greater number of complex computer sys-
tems that run the gamut of criticality.
The business structures and supply chains
associated with system development further
adds to the complexity. It’s rare, if it happens at
all, that a manufacturer engineers and builds
every component and subsystem in their cars
from the ground up, leading to potential inte-
gration issues. A transmission is taken from
this model, a good braking system from that
one. While they may have worked well in their
previous environment, in a totally new com-
plex system they may well have unintended
and unexpected results. As a result, automo-
tive software is often a complex hodgepodge
of systems that may or may not have been suf-
ficiently tested. Implementing components
in an ad-hoc manner without proper testing,
especially in safety-critical applications, can
be extremely costly.
The upside, though, is that there are known
practices for helping automakers mitigate the
risk of failure by building software quality
into their development processes. According
to some estimates, a standard mid-range car
can have well over a hundred electronic con-
trol units (ECU) processing millions of lines
of code - and this number is increasing. It’s
not uncommon for a manufacturer to have
several models of cars with over one hundred
million lines of code. There is a perception
that the more expensive the car, the more soft-
ware is embedded - and that most of the soft-
ware is dedicated to high-end infotainment
components. While it’s true that these systems
become increasing complex as you move up
the model line, even introductory lines of cars
use software to control steering, brake systems,
electrical power distribution, and so on. And
even seemingly minor shifts in features, such
as Bluetooth, climate control, cruise control,
etc, lead to exponential growth of code.
We can assume that more code translates to
more complexity - and therefore risk, but the
impact may not necessarily be significant. A
larger contributor to business risk associ-
ated with automotive software is the inte-
gration of code developed from a variety of
sources across multiple tiers. Most compo-
nents, including ECU-based components, are
subcontracted to second-tier providers who
subcontract to third-tier providers and so on.
Each preceding tier has specific requirements
associated with the component they’re devel-
oping. Organizations often (but not always)
have practices in place for analyzing incoming
code to ensure that the components function
as expected.
But this assumes that every component along
the supply chain is a new development. In real-
ity, downstream tiers are branching off code
written for a specific make, model, and year.
The mutation and reuse of code takes place
throughout the supply chain, which leads to
a testing problem. How does the manufac-
turer implement end-to-end testing in such a
chaotic ecosystem of software development?
When the ECU in the steering wheel was orig-
inally developed for one vehicle and the ECU
in the dashboard was developed for another
vehicle, and neither ECU was designed for the
vehicle they are currently embedded in, what’s
the impact? How can you ensure that the
complete system functions as expected? It is
entirely possible for both systems to pass test-
ing as functional but be unable to communi-
cate properly in all situations. What is the risk
