【ブースレポート】QNX Cabin と dSPACE VEOS Player によるクラウド上のコックピット開発の展示を訪問してきた #AWSSummit
こんにちは、製造ビジネステクノロジー部の若槻です。
2026 年 6 月 25 日〜26 日に幕張メッセで AWS Summit Japan 2026 が開催されました。
本記事では、その 2 日目に AWS for Industries Zone で訪問した「Engineering and Development Hub (EDH)」ブース（A029）の展示内容をレポートします。QNX（BlackBerry）と dSPACE のツールを AWS 上で組み合わせ、実機がなくても車載コックピットのソフトウェア開発・検証ができるという展示でした。
前回の記事で紹介した AWS × NVIDIA の自動運転 / ADAS 展示と同じゾーンにあったブースです。
登場するプロダクト早見表
展示には QNX / dSPACE / Qualcomm / AWS と、複数のベンダーのものが入り混じって登場します。読み進める前に「どこ製で、アーキテクチャのどこを担当しているのか」だけ先に整理しておきます。
| プロダクト | どこ製 | この展示での役割 |
|---|---|---|
| QNX（OS） | BlackBerry | 車載向けリアルタイム OS（RTOS）。クラウド側の EC2 でも実機の SoC でも、スタックの最下層で動く |
| QNX Cabin | BlackBerry | デモの主役。デジタルコックピット開発のリファレンス実装で、QNX Hypervisor 上に QNX Host / Android Guest / Linux Guest を同居させる。デモ画面の上半分 |
| dSPACE VEOS / VEOS Player | dSPACE（ドイツ） | SIL シミュレーション基盤。車速・ホイール速度などの車両信号を生成し、QNX Cabin に流し込む。デモ画面の下半分 |
| AUTOSAR Classic | 業界標準規格（特定ベンダーの製品ではない） | 実機側で実際に車を制御する ECU のソフトウェアスタック。クラウド側ではこの部分こそが dSPACE VEOS のシミュレート対象になる |
| SoC 開発ボード | Qualcomm | 実機側のターゲットハードウェア。QNX を動かす「載せ先」として置かれていた |
| EC2 / AWS Graviton | AWS | クラウド側の実行基盤。Arm（aarch64）なので車載 SoC とバイナリ互換になる |
これらの関係を図にすると、以下のようになります（矢印は信号の流れ）。
図の囲みは「どこで動いていたか」を表しています。下の枠（Signal Service から上）は、AWS 上でも実機のボード上でもまったく同じバイナリが動く部分で、差し替わるのは Connector とその下（シミュレータか実機のバスか）だけ、というのがこの展示の肝です。
AWS 上で動いていたのは、Arm ベースの EC2（AWS Graviton）インスタンス 2 台でした。
- 1 台目：dSPACE VEOS Player（図の左上）— 車両の挙動をシミュレートして信号を生成する側
- 2 台目：QNX + QNX Cabin（図の下の枠のクラウド側）— コックピットのソフトウェア本体
デモ画面に映っていたのは、この 2 台のデスクトップです。一方、図の右上（AUTOSAR Classic と実デバイス）と下の枠の実機側は AWS ではなく、ブースのテーブルに置かれた Qualcomm 製 SoC ボードとその配線で動いていました。なお、「AWS 固有のサービスは何を使っているのか」と聞いたところ、見た目上はインフラ（EC2）だけという回答で、マネージドサービスの類は使われていないとのことでした。
それぞれの詳細は、記事後半の「関連プロダクトの詳細」で改めて触れます。
展示内容
ここからは、ブース担当者の方に説明していただいた展示内容を紹介します。
「Engineering and Development Hub (EDH) - 自動車開発に関わるパートナー様のツール群を AWS クラウドに集約」
ブースの掲示は「自動車開発に関わるパートナー様のツール群を AWS クラウドに集約」というメッセージで、今回はその一例として QNX + dSPACE の組み合わせが動いていました。
デモの構成：クラウド側と車両側を並べて見せる
このブースの肝は、同じコックピットソフトウェアを「クラウド上の仮想環境」と「実機の SoC」の両方で動かし、横に並べて見せていた点です。
QNX Cabin – dSpace VEOS Player クラウド連携のアーキテクチャ図
図の中央に破線があり、雲アイコン（☁️）の左側がクラウド、車アイコン（🚗）の右側が実機の車両を表しています。
構成を整理すると以下のとおりです。
クラウド側（図の左、AWS Graviton 上）
- 最下段が QNX / AWS Graviton Processor。つまり QNX が Arm ベースの EC2 インスタンス上で動いています
- その上に dSPACE Connector と Playback Connector が乗り、それぞれ dSpace VEOS Player と Playback Tool につながります
- さらに上に Signal Service（信号を集約するハブ）
- 一番上が Host（Cluster） / Android Guest（Application / Runtime / VHAL） / Linux Guest（Application / Kernel） の 3 つの実行環境
車両側（図の右、実機 SoC 上）
- 最下段が QNX / SoC。実機の SoC 上で QNX が動きます
- その上に SPI Connector と Ethernet Connector が乗り、SPI / Ethernet / CAN といった本物の車載バスにつながります（図の下部から実際のカメラに配線が伸びています）
- さらに左には AUTOSAR Classic（SWC / RTE / IpduM / IpduR / CanIf / SpiIf / EthIf / Microcontroller）のスタックがあり、こちらが実際の ECU 側です
- Signal Service より上の構成（QNX Host / Android Guest / Linux Guest）は、クラウド側とまったく同じ
つまり、
アプリケーション層は左右で変わらず、差し替わるのは最下層の「Connector」だけ
という設計です。クラウドでは信号の出どころが dSPACE のシミュレータ、実機では本物の SPI / Ethernet / CAN になる、という違いだけで、その上に乗るアプリは同じバイナリを動かせます。ブース担当者の方も「開発のやり方は左右で同じです」と説明されていました。
これにより、実機がなくても開発の初期段階からアプリケーションの開発とテストができ、できあがったものをそのまま実機に持っていける、というのが最大の訴求ポイントとのことでした。いわゆる「シフトレフト」ですね。
実際に動いていたデモ
デモは 1 枚のディスプレイを上下に分けて、2 つの EC2 インスタンスのデスクトップを並べて表示していました。
なお、私が訪問した時点ではライブのデモが上手く動いておらず、画面には事前に収録された画面キャプチャの動画が再生されている状態でした。そのため以下は、その再生映像とブース担当者の方の解説にもとづく紹介になります。
上半分が QNX Cabin のコックピット画面、下半分が dSPACE のシミュレータ
- 上半分：QNX Cabin が動いているインスタンス。下半分のシミュレータから流れてくる信号を受け取って、コックピットの画面を描画しています
- 下半分：もう 1 つのインスタンス。dSPACE のシミュレータが動いていて、左に実験・シナリオ設定の UI、右にコースを走る車両の 3D ビューが表示されています。ここでシミュレーションの信号を生成します
上半分の QNX Cabin 側をよく見ると、下のシミュレータで走っている車の状態がそのまま反映されているのが分かります。
4 輪それぞれのホイール速度・タイヤ空気圧・ブレーキ圧、車速、エンジン回転数、GPS 座標、空調温度などが表示されている
- 左のデジタルクラスターに車速（36 km/h）とナビ地図
- 中央に dSPACE から流れてくる車両信号 — 車速 40 km/h、エンジン回転数 0.9 ×1000 rpm、4 輪それぞれのホイール速度 / タイヤ空気圧 / ブレーキ圧、GPS 座標（51.75343, 8.70785）、運転席・助手席の空調温度（21.0℃ / 23.0℃）
- さらに右にブラウザのウィンドウ（YouTube の QNX チャンネル）— 上の切り抜きでは範囲外ですが、1 つ前のデモ画面全体の写真で確認できます
この右のブラウザが、QNX ネイティブではないゲスト OS 側のアプリケーションにあたります。担当者の方によると、このデモでは QNX ネイティブのアプリケーション、Android のアプリケーション、Linux のアプリケーションの 3 つが同時に動いているとのことでした。
なお、インパネ上部の帯状の領域（フロントカメラ映像が出るはずの部分）は当日は映っておらず、「調整中」とのことでした。本来はここにもシミュレータからの映像が出る想定だそうです。
QNX Hypervisor と 3 つの実行環境
ここでデモ画面からいったん離れて、もう一度アーキテクチャ図に戻ります。デモで「QNX ネイティブ / Android / Linux の 3 つのアプリケーションが同時に動いている」と説明された部分が、図の上ではどう表現されているのかを見ておきたいためです。
次の写真は図の右側（車両側）を拡大したものですが、先に整理したとおり Signal Service より上の構成はクラウド側とまったく同じなので、ここはそのままクラウド側の説明としても読めます。この上半分を見ると、QNX Hypervisor 上で複数の OS が同居している構成が読み取れます。
車両側の構成。QNX Host / Android Guest / Linux Guest と AUTOSAR Classic
| 実行環境 | 中身 | Signal Service との接続 |
|---|---|---|
| QNX Host | Cluster（メータ表示） | VSOME Adaptor 経由、ara::com |
| Android Guest | Application / Runtime / VHAL | Android Adaptor 経由、gRPC / vsock |
| Linux Guest | Application / Kernel | Signal Adaptor 経由 |
ポイントは、どの実行環境から見ても信号の入口が Signal Service に一本化されていることです。Signal Service の下に Connector（クラウドなら dSPACE、実機なら SPI / Ethernet）がぶら下がる構造なので、アプリ側は信号の出どころがシミュレータか実機かを意識しなくて済みます。
ara::com は AUTOSAR Adaptive Platform の通信 API、VHAL（Vehicle HAL）は Android Automotive が車両信号を扱うための抽象化層です。それぞれの世界の「お作法」に合わせたアダプタが用意されている、という作りになっています。
「なぜ Android がいるのか」と質問したところ、「今主流の車のメーカーは Android ベースのアプリが結構多いため」とのことでした。実際 QNX Cabin は、安全性が要求される機能を ASIL D 認証済みの QNX 上で動かしつつ、それ以外を Android Automotive や Linux のゲスト OS で動かす、というミックスクリティカリティ構成を前提にした製品です。
実機側のハードウェア
実機側は、テーブルの上に置かれた Qualcomm 製の SoC 開発ボード（QNX のステッカーが貼られていました）と、アーキテクチャ図の下に固定された実物のカメラで構成されていました。
QNX のステッカーが貼られた Qualcomm 製の SoC ボード。ここで実機側の QNX Cabin が動いている
「カメラのような実機依存の部分は、やはり実機じゃないと難しいのでは？」と聞いてみたところ、クラウド側でも（シミュレータ経由で）できるという回答でした。ただし実機と違ってくるのはスピード（レイテンシ）なので、そこは実機で確認する必要がある、という整理のようです。
ここでいうレイテンシは、カメラが撮ってから、その映像がコックピットの画面に出る（あるいはアプリが処理し終える）までの時間のことです。実機では「カメラ → SerDes / MIPI → SoC の画像処理 → 描画」という物理的な経路を通りますが、クラウドではその経路がまるごとシミュレータからのデータ供給に置き換わり、EC2 インスタンス間の通信も挟まります。「映像が出るか」「その映像を使うアプリが正しく動くか」という機能面はクラウドで確認できるが、「何ミリ秒で出るか」は実機でないと分からない、という切り分けですね。
ブース全景。奥に AWS for Industries Zone の看板
AUTOSAR Classic 側（実 ECU）の役割
図の右端にある AUTOSAR Classic のスタックについても聞いてみました。
こちらは実際に車を制御する部分で、ドアの開閉、エンジン、ブレーキといった制御が対象とのことです。マイコン（Microcontroller）上で動く、いわゆるクラシックな車載 ECU のソフトウェアスタックですね。
「この部分がなくても、コックピット側だけで動くのか？」と聞いたところ、表示系のアプリケーションだけなら動くが、自動運転向けの開発など車両制御が絡んでくる場合はこの部分が必須になる、という回答でした。
なお、クラウド側の図には AUTOSAR Classic のブロックがありません。クラウドではこの部分こそが dSPACE VEOS でシミュレートされる対象、という関係になっています。
関連プロダクトの詳細
ここで、展示に登場した主要なプロダクトを補足します。
QNX
まず私（若槻）がブース担当者の方に「QNX はクアルコムのサービスなんですか？」と聞いてしまったのですが、QNX は BlackBerry の製品です。もともとリアルタイム OS（RTOS）のベンダーで、現在は車載ソフトウェアの領域で広く使われています。展示で Qualcomm のボードが使われていたのは、あくまで QNX を動かすターゲット SoC としてでした。
QNX Cabin
デモの主役だったプロダクトです。デジタルコックピット開発のためのプリインテグレーション済みリファレンス / 開発フレームワークという位置づけで、以下で構成されています。
- QNX Hypervisor（ミックスクリティカリティ環境）
- QNX Advanced Virtualization Frameworks（ゲスト OS 統合）
- QNX Screen（ディスプレイ管理）
- QNX Acoustics Management Platform（オーディオ処理）
VirtIO による抽象化でソフトウェアを特定ハードウェアから切り離しており、クラウドインスタンスとターゲット SoC でバイナリの互換性（binary parity）が保たれるのが特徴です。今回の展示で「クラウドで作ったものをそのまま実機に持っていける」と説明されていたのは、この性質によるものですね。
「メーカーごと・車種ごとに UI は違うはずだが、どう作るのか」という質問もしてみたのですが、こちらはあくまでリファレンス実装であり、実際の HMI は各社が作り込むもの、という理解でよさそうです。QNX Cabin が提供するのはその開発と検証の基盤、という説明でした。
dSPACE VEOS / VEOS Player
dSPACE の SIL（Software-in-the-Loop）シミュレーション用プラットフォームです。仮想 ECU（V-ECU）とネットワーク通信を PC / クラウド上でシミュレートできます。
- V-ECU やレストバスモデルを使って、実機がない ECU の振る舞いを再現できる
- Docker 化してクラウドに分散させ、テストを並列実行できる
- Arm ベースの AWS Graviton にも対応
「使ったことがあるのは CARLA なのですが、シミュレータは dSPACE 以外でもいけますか？」と聞いたところ、他のシミュレータでも可能とのことでした。
AWS Graviton 上の QNX
QNX が EC2 の Graviton インスタンス上で動くこと自体は、以前から AWS 公式ブログで紹介されています。車載 SoC と Graviton がどちらも aarch64 であるため、同じアプリケーションイメージ（バイナリ）を車内・クラウドの両方で実行できるというのが肝です。
QNX Hypervisor と組み合わせてクラスタ（メータ）ソフトウェアを開発する話も公開されています。
また、dSPACE VEOS と AWS Graviton を組み合わせて車載 E/E アーキテクチャをシミュレートする構成についても解説記事があります。今回の展示は、この延長線上にコックピット（QNX Cabin）を載せたもの、と捉えると分かりやすいです。
おわりに
QNX が実際に自動車メーカーでも使われているのか聞いてみたところ、実際の OEM でも採用されているとのことでした。
車載ソフトウェア開発というと、どうしても「実機（ターゲットボード）待ち」がボトルネックになるイメージがありましたが、ハイパーバイザと VirtIO による抽象化、そして車載 SoC とクラウドの ISA が揃ったことで、ここまで綺麗に「クラウドで作って実機に持っていく」が成立するのかと感心しました。
アプリケーション層を一切変えずに最下層の Connector だけを差し替える、という割り切った設計もシンプルで良いですね。自動運転のようにセンサやアクチュエータのリアルタイム性が効いてくる領域ではまだ実機が要るものの、コックピット / IVI の領域では相当な部分をクラウドに寄せられそうです。
以上
