Software-Definedビークルをサポートする 高性能コンピュート（HPC）プラットフォームを設計する場合、最初のステップはドメイン機能を統合し、ハードウェアからソフトウェアを抽象化することです。しかし、さらに一歩進んで、メインのシステムオンチップ（SoC）をシステムインパッケージ（SiP）に分離することには、明確な利点があります。
SiPはSoCと、追加メモリや電源管理集積回路などの他の主要コンポーネントを標準サイズのパッケージに纏め、HPCデバイスのメインボードに直接はんだ付けできるようにします。
メインボードには、HPCに入力されるデータと出力されるデータに必要なすべてのインターフェースが搭載されています。例えば、Aptivのユーザー・エクスペリエンス用 オープン・サーバー・プラットフォーム（OSP）のようなHPCデバイスのメインボードには、車内のセンシング・カメラから送られてくるビデオ・ストリームのデシリアライザー、高解像度ディスプレイの出力、オーディオ・インターフェース、イーサネット・スイッチ、その他Bluetooth、Wi-Fi、GNSS、USBなどの通信インターフェースが搭載されます。メインボードには、車両内の通信を処理し、周辺機器の起動シーケンスを監督し、SoCのスリープとウェイクアップを管理する「ハウスキーピング」マイクロコントローラーも含まれます。
SiPを使用することで、すべての接続と周辺機器を備えたメインボードの開発を、SoCとその上位レベルのソフトウェアの開発から切り離すことができます。
SiPの使いやすさ
SiPは長い間コンピューター業界で重宝されましたが、このアプローチを自動車にも応用することでも利点が生まれます。
まずOEMは1つのSoCを別のSoCに簡単に交換することができ、これはサプライチェーンの安定性に繋がります。ベースレベルのソフトウェアにわずかな変更を加えるだけで、同じフットプリントを持つ2つのSiP（それぞれ異なるSoCを搭載）を同じメインボード上で交換することができます。今まではあるSoCから別のSoCへの移行には最大26週間を要しましたが、SiPではわずか6～8週間で移行できます。
またメインボードとSiPの製造を切り離すことで、それぞれを別々に開発できます。SoCは基板上でより多くの層を必要とするため、より小さなSiP基板上にSoCを搭載することでコストを削減できます。
そしてこの互換性は拡張性に繋がります。OEMはエントリーレベルからプレミアムまで様々な車種に同じメインボードを使用しつつ、異なるSiPを使用することで多様なレベルの機能をサポートできます。あるいは設計で同じSiPを異なる車種用の異なるメインボードフォームファクターに組み込むこともできます。つまり設計時、完全に開発されたSiPを追加する前に、そのサイズと形状の要件を満たすメインボードの開発に集中するだけでよいのです。
最後にAptivはSiPアプローチが車両全体のすべてのコンピュートに適用できると考えています。Aptivの Smart Vehicle Architecture™製品ポートフォリオの中で最も注目度の高いHPCデバイスはOSPですが、SiP設計はより低レベルの機能用の中央コントローラ、あるいは ゾーンコントローラでも同じ利点を達成することができます。一部の車両アーキテクチャでは、中央コントローラとゾーンコントローラの組み合わせなど、これらのデバイスのハイブリッドが使用されることがあり、SiPアプローチはそれにも最適です。どのような場合でも、OEMはSiPを、それを搭載するデバイスとは別に検証することで、時間とコストを節約できます。
全体像の一部
ソフトウェアをハードウェアから抽象化することも重要で、ハードウェア設計はそのアプローチをサポートする必要があります。ミドルウェア、Wind River Helixハイパーバイザー、VxWorksリアルタイムオペレーティングシステムなどのツールを使用することで、開発者はSiPを別のSiPに交換しても、同じソフトウェア機能を維持することができます。
しかしSiPアプローチでは、ボード全体ではなくSiPがプラットフォームになります。つまり、ソフトウェアのメンテナンスが容易になるのです。プラットフォームにバグがあっても、SiP上で修正することができます。
つまりSiPベースのアーキテクチャは、世界的サプライチェーンの不確実性、拡張性、長期的な技術更新の必要性を考慮した上で、OEMがソフトウェア定義車両を開発するために必要なハードウェアの柔軟性を提供します。Aptivはサプライヤーの柔軟性を実現するためにSiPを製品に使用しており、将来のコンピュート製品向けに独自のSiPを開発しています。