Cars as we know them today are digital machines with dozens
of distributed computer systems running everything from infotainment and
connectivity features to advanced safety, comfort, and convenience elements. A
late model luxury vehicle may have up to 70 electronic control units (ECUs) that
combine a processor, memory, and software. ECUs are designed to do one thing
only for the life of the vehicle and are not built for functional change or
enhancement. The only way to modify or update the code within an ECU is with a
costly scan tool that is physically connected to the vehicles.
Another key element of today’s vehicles is the Controller
Area Network (CAN) bus. Considered the nervous system of a vehicle, the CAN bus
is an underlying network architecture that connects and enables communication
among the dozens of distributed ECUs.
Moving Toward a Centralized Architecture
While the distributed systems of vehicles have been
practical and functional up until now, newer architectures, more data, and a
movement toward centralized processing
is challenging the limits of traditional automotive design. One such trend is
the consolidation of domains into a centralized computer architecture. Instead
of having several discrete ECUs, they are all housed in a centralized domain
control. This model allows for greater software functionality, more code reuse,
and easier remote management.
Tesla is a classic example of a software-defined car. Unlike
any other vehicle on the market today, Tesla started from a clean sheet of
paper. The goal was to design a car controlled by software and executed on a
centralized compute platform. Tesla’s vehicles are considered software-defined cars because almost
any new feature or modification to an existing feature can be made with
software updates sent over the air. VSI believes Tesla is a proxy for future
vehicle architectures, and many automotive OEMs have begun following suit,
acknowledging it is time to give in to the contemporary architectures necessary
to support future vehicles.
A key enabler to the software-defined car movement is the
consolidation of domains into a centralized computer architecture. This supports
a much better system for software management and computing efficiency.
Furthermore, this architecture allows for feature enablement using Over-the-Air
(OTA) distribution of new software code to the vehicle. Tesla, for example, uses OTA exclusively for
the management of features including the distribution of new functionalities as
well as the improvement of existing ones.
The move toward software-defined vehicles is facilitated by
processor companies that are making more powerful processors optimized to
handle the computing requirements of a centralized approach. Additionally, the
operating system companies can partition the platform whereby a central domain
processing unit may have multiple virtual machines running independent of one
Challenges and Other Considerations
Aside from Tesla, the movement to centralized domain control
has been slow, largely due to the “if it ain’t broke don’t fix it,” mentality.
This is not surprising considering traditional architectures work very well.
But we are at the limit of what those traditional architectures can support
when it comes to lifecycle management. Infotainment proved this and the
OEMs finally gave in a bit. Now we have a greater movement toward intelligent
feature enablement which is always changing and improving. The new architecture
supports this, while the legacy does not.
There are many other hurdles to adopting a centralized
approach. For one, there are software challenges that may be beyond the scope
of many OEMs. However, the software expertise necessary to support the
architecture is becoming better understood at the OEM level and even among tier
one suppliers, and most major tier ones have introduced centralized domain
architectures for ADAS and automated driving.
There are also a lot of software tools to manage the
abstraction layers necessary to support central domain processing. The abstraction layer enables an application
interface from which applications can be managed. Even AUTOSAR has a
specification to support the new architecture. Adaptive AUTOSAR allows an I/O
interface to the most guarded of vehicle applications, most notably those
associated with active safety and automated driving.
It is important to note that centralized domain control does
not consolidate all processing into one box as you might think. There
will be distributed processing that optimizes the system and reduces the
workload on the domain controller. There will need to be several accelerators
pushed out to the edge to deal with so much data. Sensors modules,
braking control modules, body control modules, lighting modules, etc. There is
a lot of expertise at the edge supporting the centralized domain architecture.
One consequence of this software-first movement is that the
vehicle architecture will become a service-oriented architecture (SOA) based on
generalized computing platforms. Developers will create new applications,
artificial-intelligence elements, and operating systems. The differentiation
will not be in the traditional vehicle hardware anymore but in the
user-interface and experience elements powered by software and advanced
The movement toward software-defined cars has been under
development for years, and nearly all OEMs are working on these newer
architectures. You can credit Tesla for accelerating this and proving the
architecture is viable.
So, can the OEMs pull it off? Only time will
tell. There’s no way we can predict exactly how vehicles will transform over
the coming years. But there is no doubt that software is playing a bigger role
in cars of the future and will no doubt continue to do so.