Achieving Design and Manufacturing Efficiencies on the OSP

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.