When designing high-performance compute (HPC) platforms to
support software-defined vehicles, the first steps are to
consolidate domain functionality and to abstract software from hardware. But
there are distinct advantages in going a step further and isolating the main
system-on-a-chip (SoC) onto a system-in-a-package, or SiP.
A SiP bundles the SoC with a couple of other key components,
such as additional memory and power management integrated circuits, into a
standard-size package that can then be soldered directly onto the mainboard of
an HPC device.
The mainboard has all of the interfaces required for data coming
into the HPC and data going out. For example, a mainboard for an HPC device
such as Aptiv’s open server platform (OSP) for user experience
would hold deserializers for video streams coming from interior sensing
cameras, outputs for high-definition displays, audio interfaces, an Ethernet switch and any other communications
interfaces, such as Bluetooth, Wi-Fi, GNSS and USB. The mainboard would also
contain a “housekeeping” microcontroller to handle communications inside the
vehicle, oversee the peripheral startup sequence and manage the sleeping and
waking up of the SoC.
Using a SiP decouples the development of the mainboard with all of its connections and peripherals from the development of the SoC and its higher-level software.
What makes SiP easy to swallow
While SiP has long benefited the computer industry, applying this approach to automotive yields several distinct advantages.
First, it enables OEMs to easily replace one SoC with another, which is a key capability for building supply chain resiliency. With minor changes to base-level software, two SiPs with the same footprint — each with a different SoC — can be interchanged onto the same mainboard. In the past, moving from one SoC to another could take up to 26 weeks; with a SiP, the migration could be just six to eight weeks.
Second, decoupling the manufacturing of the mainboard and the
SiP allows each to be developed separately. An SoC requires more layers on the
board, so it can save costs to have an SoC on the smaller SiP board.
Third, this interchangeability promotes scalability. An OEM
could use the same mainboard with different vehicle models, from entry-level to
premium, and just use a different SiP to support a different level of
functionality. Alternatively, designers could drop the same SiP into different
mainboard form factors for different vehicles. Depending on where it fitted
within a vehicle, an HPC device could have a very different shape, and
designers would only have to focus on developing the mainboard to meet those
size and shape requirements before adding in the fully developed SiP.
Fourth, Aptiv believes the SiP approach could be applied to all
compute throughout a vehicle. While the highest-profile HPC device in Aptiv’s Smart Vehicle Architecture™ product portfolio
is the OSP, the SiP design is also able to achieve the same advantages in the central vehicle controller for lower-level
functions, or even in a zone controller. Some vehicle architectures may use
hybrids of these devices — such as a combination central vehicle controller and
zone controller — and the SiP approach is suitable there, as well. In all
cases, OEMs can save time and cost by validating SiPs separately from each of
the devices in which they reside.
Part of
the big picture
To be sure, abstracting the software from the hardware is
another key enabler, and the hardware design must support that approach. By
using tools such as middleware, the Wind River Helix hypervisor and the VxWorks
real-time operating system, developers can swap out one SiP for another and
maintain the same software functionality.
But with a SiP approach, the SiP — not the entire board —
becomes the platform. That means software maintenance is easier. If there is a
bug on the platform, it can be fixed on the SiP — no matter what mainboard it
is attached to.
In short, a SiP-based architecture provides the hardware
flexibility that OEMs need to create software-defined vehicles, given global
supply chain uncertainty, scalability requirements and the need to evolve over
time. Aptiv uses SiPs in our products to achieve supplier flexibility, and we
are creating our own SiPs for future compute products.