日産自動車、協業型とプラットフォーム先行開発への転換でAIディファインドビークルを加速する

　また、開発モデルと並んで変革を要するのが、開発プロセスだ。従来の「並列型」は、アプリケーション（APP）とプラットフォーム（PF）を同時並行で開発し、完成後に統合する手法だった。

　日産は「APP層で20年以上の内製化実績を持ち、モデルベース開発によるシフトレフトを着実に実現してきた」と杉本氏は強調する。しかし車載ソフトウェアの標準化規格「AUTOSAR」やミドルウェアといったPF領域は「ECU（Electronic Control Unit：電子制御ユニット）のハードウェアサプライヤーに紙の仕様書を提出し『この通りにPFとECUの箱を用意してほしい』という形で委託してきた」（同）

　APPとPFを並行開発し、後から統合すると「必ずインテグレーション時に不具合が出る」（杉本氏）という。この統合フェーズでの手戻りこそが、開発スピードを落としてきた根本的な要因でもある。

　PF先行型では、PFを先に開発して確定し、その上でAPPを開発する。OTA（Over The Air：無線通信を介したソフトウェア更新）やUCD（ユーザー接続デバイス）を生かした先進的なAPP開発が可能になるのも、PFが事前に安定しているからこそだ。もっとも「APP開発に比べてPF開発はそう単純な話ではない」とも杉本氏は述べるが「どこまでを自社で担い、どのパートナーと役割を分担するかの最適解を現在探っている」（同）段階だ。

車載アーキテクチャーは縦と横で分ける

　開発モデルと開発プロセスの変革を支えるのが、車載ソフトウェアアーキテクチャーの再設計だ。杉本氏は（1）「縦の分離」、（2）「横の分離」という2軸で整理する（図3）。

図3：車載ソフトウェアにおける縦／横分離の構成

　縦の分離とは「車載ソフトウェアを『素早く進化していく世界』と『信頼性を担う世界』に明確に分けること」（杉本氏）だ。前者はAI技術や新機能が動くLinuxベースの領域、後者は走行・操舵・制動など基本機能を担うAUTOSARの領域となる。

　杉本氏は「これを合わせてしまうと元々のアセットが使いづらくなり、最終的には開発スピードが落ちる」と指摘する。OSレベル、さらにはチップやコアのレベルで「完全に分離することで、進化する側のAPPを実車なしに独立して検証可能な環境が実現する」（同）という。

　一方の横の分離は「ソフトウェアとハードウェアの依存関係を『Vehicle API（Application Programming Interface）』で切り離すこと」（杉本氏）だ。APIによってハードウェアの機能制約や安全設計を抽象化し、ハードウェアが変わっても影響を最小化する。日産は自社で独自のAPIを定義するとともに「車載ソフトウェアやネットワークの標準化団体JASPAR（Japan Automotive Software Platform and ARchitecture）内で、トヨタやホンダとともに『ビークルAPI』の実装も並行して進めている」（同）という。

EV以外でのAIDV拡張を視野に入れる

　縦／横分離の設計思想が真価を発揮するのが、ICE（Internal Combustion Engine：ガソリン）車やHV（Hybrid Vehicle：ハイブリッド車）などへのAIDV対応だ。日産は「AIDVの対象をEVだけに限定しない」（杉本氏）点で、競合との明確な違いを持っている。

　EV専業各社は、車体に大容量バッテリーを積むため、Linuxシステムをスタンバイ状態で維持できる。しかし「鉛バッテリーのみを持つICE車で同じことを試みると、1週間も経たずにバッテリーが上がってしまう」と杉本氏は説明する。かといって「完全にシャットダウンして毎回立ち上げようとすると何十秒もかかる」（同）のが現状だ。

　そこでAIDVに必要なのは（1）クラウドへの接続ポイントの確保、（2）セキュリティリスクの最小化、（3）起動時間の短縮、の3つの要件の両立だ。実際、日産は「LinuxとリアルタイムOS、AUTOSARを組み合わせる構成」（杉本氏）を採っている（図4）。

図4：車両セキュリティを実現するためのソフトウェアの構成

　高性能処理を担うパフォーマンスコア（Performance Core）でLinuxを動かす一方、リアルタイムコア（Real Time Core）ではリアルタイムOSとAUTOSAR準拠のソフトウェア基盤が従来の車両制御を担う。高速起動とセキュリティを両立し「進化し続けるセキュリティモジュールを、車両へ迅速に取り込める仕組みを目指している」（杉本氏）

コンテナ技術の車載適用により“ハードなし”で品質を証明する

　日産がさらに検討を進めるのがコンテナ技術の車載適用だ。杉本氏は「APP同士の競合を避けながら、影響範囲を限定してOTAが実行できるようにする狙いがある」と説明する。極力小さな単位でバリデーション（検証）を回して証明していくために「コンテナ空間単位で品質を確認し、確認済みのコンテナを車両に展開する」（同）考えだ。

　理想として杉本氏が描くのは「コンテナ上ですべての品質確認が完了すれば、ハードウェアが不要になり、クラウド上のソフトウェア開発環境だけでバリデーションが完結する」世界だ。「実機を用意するコストと時間を削減すれば、開発のサイクルはさらに速くなる」と期待を寄せる。