役員SNS
TuringTechTalk#41 車両が増えても運用へ ─ OTAとフリート管理で実現する車両運用の省力化
はじめに
自動運転の開発というとAIモデルに注目が集まりがちですが、実際にはAIを安定して動かすための車載ソフトウェアやOS、計算機、ハードウェアまで含めた基盤づくりが欠かせません。
今回のTech Talkでは、その中でもOTA（Over-the-Air）によるソフトウェア更新と、開発車両を効率よく管理するフリート管理システムに焦点を当てました。
チューリングでは現在約30台の開発車両を運用しており、車両の増加に伴い、ソフトウェアやセンサー構成の管理を手作業で行うことが難しくなっています。
今回はCTOの山口とDriving System 1チーム シニアエンジニアの安部が登壇し、OTA基盤とフリート管理システムについて、その設計思想からシステム構成、安全なアップデートを実現する仕組みまで紹介しました。
※本記事は「Turing Tech Talk #41」の内容をもとに、一部編集のうえお届けします。
OTAとは何か
山口：みなさん、こんにちは。今回のイベント「Turing Tech Talk #41」は、「車両が増えても運用へ。OTAとフリート管理で実現する車両運用の省力化」をテーマにお届けします。私はチューリングCTOの山口です。本日はドライビングシステム1チームのシニアエンジニア・安部さんに来ていただいています。
安部：よろしくお願いします。
山口：今回のタイトルにもなっている「OTA」は、普段あまり聞き慣れない言葉だと思います。まずはOTAとは何か、というところから教えてください。
安部：OTAは「Over-The-Air」の略で、Wi-FiやLTEなどのネットワーク経由でソフトウェアをダウンロードし、アップデートする一連の仕組みのことです。
山口：例えばiPhoneやAndroidでは、OSアップデートやセキュリティパッチが配信されますよね。あのイメージでしょうか。
安部：はい、そのイメージです。iPhoneのアップデートもOTAの一例です。
山口：スマートフォンでは当たり前になっているOTAですが、自動運転車ではどのように活用されているのでしょうか。今回は、このOTAが車両運用とどのようにつながっているのかを詳しく見ていきます。
まずは安部さんの自己紹介をお願いします。
安部：私は1998年に日本IBMへ入社し、26年間、ハードウェアとOSの間にあるレイヤーの開発に携わってきました。テープドライブの開発を長く担当し、現在はチューリングでも同じように、ハードウェアとOSの間にある基盤ソフトウェアを担当しています。OSの管理や、その上で動作するアプリケーションの基盤を整備し、自動運転AIが安定して動作できる環境を構築することが主な役割です。
山口：安部さんが所属するドライビングシステム1チームでは、車載アプリケーションだけでなく、OSやカーネル、計算機周りまで幅広く開発しています。
チューリングは自動運転AIを開発している会社というイメージを持たれることが多いですが、実際にはAIだけではなく、それを支えるソフトウェアやOS、車載計算機、さらにはハードウェアまで自社で開発しています。
安部：ソフトウェアだけでなく、ハードウェアや配線、電源周りなど、車両全体を対象に開発しています。
山口：今回は、その基盤となる車載システムがどのように管理され、どのようにOTAでアップデートされているのかをご紹介します。
今回はTech Talkでも初めて扱うテーマです。普段あまりお見せすることのない、車載システムの基盤やOTAの仕組みについて、安部さんに詳しく解説してもらいます。
車両が増えると何が難しくなるのか
山口：今回のテーマは「膨らむ更新・管理コストを、OTAとフリート管理でどう解決するか」です。現在チューリングでは約30台の開発車両を運用していますが、データ収集用の車両や実験用の車両など用途はさまざまで、運用形態も日々変化しています。
安部：そうですね。運用が変わることも多く、どの車両がどの用途なのか、常に把握し続ける必要があります。
山口：10台を超えたあたりから、手作業で車両を管理するのはかなり難しくなってきました。
安部：当初はAnsibleを使って各車両へソフトウェアを配布し、センサーの更新も手作業で行っていました。ただ、更新時にエラーが発生すると最初からやり直しになり、全車両への展開に2週間かかることもありました。また、ソフトウェアだけではなく、車両に搭載するハードウェアも変化しています。以前はLiDARを搭載していましたが、現在はすべてカメラベースの構成へ移行しました。GNSSなどの周辺機器も世代交代に合わせて入れ替わっており、どの車両にどのセンサーが搭載されているかも含めて管理する必要があります。
チューリングのFleet管理システム
山口：そこで構築したのが、今回ご紹介するOTAとフリート管理システムです。このあと、その仕組みについて詳しく見ていきます。以前よりも構成はシンプルになりましたが、その一方で、複数車両の状態をどう管理していくかが重要になってきました。
安部：約30台の車両を運用する中で、
- 車両一覧を見たい
- 車両に搭載されているエッジや周辺機器の情報を確認したい
- 車両に載っていない開発用の計算機も管理したい
といった要望が出てきました。また、OTAではネットワーク経由でソフトウェアを更新しますが、更新に失敗して車両が使えなくなると、実験や開発が止まってしまいます。そのため、安全に更新できるようA/Bアップデート方式を採用しました。
このような要件をもとに構築したのが、今回ご紹介するフリート管理システムです。完成したシステムでは、車両IDごとの一覧から、それぞれの車両に搭載されているセンサーやシリアル番号、ソフトウェアの状態などを確認できるようになっています。
現在、約30台の開発車両を管理していて、それぞれがデータ収集を行ったり、AIチームが新しいソフトウェアを載せて走行実験を行ったりと、日々さまざまな用途で運用されています。
10台ほどまでは手作業で管理していました。新しいソフトウェアが完成すると、Ethernet経由でAnsibleを使って各車両へデプロイし、センサーのファームウェア更新も個別に対応していました。更新内容は文書データベースへ記録するなど、すべて手作業で管理していたんです。
ただ、Ansibleによる更新ではエラーが発生することも多く、そのたびに最初からやり直さなければなりませんでした。すべての車両へ展開するまでに2週間ほどかかることもあり、このままでは運用が成り立たないと感じ、システム化を進めることにしました。
山口：ソフトウェアだけではなく、車両に搭載するセンサー構成もかなり変わってきましたよね。以前はデータ収集のためにLiDARを多く搭載していましたが、現在はすべて取り外しています。
安部：はい。現在はLiDARは搭載していません。
山口：GNSSも新しい機種へ置き換えていますし、ハードウェア自体もアップデートが続いています。ソフトウェアだけではなく、「どの車両にどのハードウェアが載っているのか」まで含めて管理する必要が出てきたわけですね。
安部：まずは、チューリングの車載システムの構成をご紹介します。
車両には「エッジ」と呼んでいる車載計算機を搭載しており、NVIDIA Orin SoCを採用しています。エッジにはLTEモジュールとSIMが搭載されていて、外部ネットワークと通信できるようになっています。
さらに、7〜8台のGMSLカメラを接続し、ネットワークスイッチを介してGNSSなどの測位センサーから位置情報を取得しています。以前はLiDARも搭載していましたが、現在はカメラベースの構成へ移行しました。最終的にはECUへ制御指令を送り、車両を制御しています。
山口：車載システムに馴染みのない方向けに補足すると、チューリングの自動運転はカメラベースです。車両の周囲に配置した7台のカメラから取得した映像を、Orin上でリアルタイムに処理しています。また、IMUやGNSSによって車両の位置や姿勢を推定しています。
安部：GNSSはRTK補正情報を利用するため、LTE経由で外部と通信しています。また、平和島の車両基地ではWi-Fiにも接続できるようになっており、大容量のOTAアップデートはWi-Fi経由で実施しています。
山口：以前よりも構成はシンプルになりましたが、その一方で複数車両の状態を管理することが重要になっています。
安部：約30台の車両を運用する中で、「車両一覧を見たい」「開発用の計算機もまとめて管理したい」「周辺機器の情報も確認したい」といった要望が出てきました。そこで構築したのが、このフリート管理システムです。完成したシステムでは、車両IDごとの一覧から、それぞれの車両に搭載されているセンサーやシリアル番号、ソフトウェアの状態などを確認できます。
山口：ブラウザからアクセスできるWebアプリケーションになっていて、社内のメンバーは車両ごとのOSやソフトウェアのバージョンも確認できます。
安部：当初は、この管理画面から車両ごとにOTAを実行していました。ただ、30台規模になると手動運用にも限界があります。現在はスマートフォンのアップデートと同じように、車載ディスプレイへ更新通知を表示し、ドライバーがボタンを押すだけでアップデートできるようにしています。そのため、管理画面からOTAを実行することはほとんどありません。
山口：車両だけではなく、開発用の計算機も同じシステムで管理しているんですよね。
安部：はい。開発用の計算機は約75台あり、自動テストやCIで使用するマシンも、すべてこのシステムで管理しています。また、周辺機器ごとの一覧表示にも対応しています。車両・計算機・周辺機器はリレーショナルデータベースで紐付けられているため、それぞれの視点から状態を確認できます。固定資産の管理にも活用しています。
OTA基盤のアーキテクチャ
安部：OTA基盤は、AWSとMenderを中心に構成しています。フロントエンドにはVercel、データベースにはSupabaseを採用しています。MenderはOTAの配信や進捗管理を担うサービスです。OTA基盤をすべて自前で実装するよりも、実績のあるサービスを活用した方が開発スピードを上げられると考え、採用しました。また、Menderと管理画面を連携させるためにAWS IoT Coreを利用しています。エッジから送られてくる車両の状態はIoT Coreを経由し、最終的にデータベースへ反映されます。
山口：MenderはOTAイメージを配信する役割を担っています。一方で、「どの車両にどのバージョンが入っているのか」といった情報は、AWS IoT Coreを経由してSupabaseへ保存し、Vercel上のWebアプリケーションで可視化しています。
安部：車両を初期セットアップする際は、まずAnsibleでキッティングを行い、Menderへ登録します。
このときAWS IoT Coreにも自動でThing Nameが登録され、エッジはその識別子を使ってIoT Coreへ接続します。その後、接続されているセンサーやソフトウェアの状態をJSON形式でAWS IoT CoreのDevice Shadowへ1分ごとに送信しています。キッティングが完了すると、接続されているセンサーやソフトウェアの状態をJSON形式でAWS IoT CoreのDevice Shadowへ1分ごとに送信します。
山口：1分ごとの更新はかなり頻度が高いですね。
安部：目的はバージョン管理だけではありません。センサーの故障や接続断などを検知したり、エッジが正常に稼働しているかを監視したりするためにも利用しています。
山口：AWS側ではどのように処理しているのでしょうか。
安部：Device Shadowへデータが届くとAWS Lambdaが実行され、Supabaseの情報を更新します。送信するデータは1KB程度なので、負荷も非常に小さく運用できています。
OTA更新の仕組み
山口：実際のOTA更新はどのような流れで行われるのでしょうか。
安部：車両を起動すると、新しいソフトウェアがある場合はディスプレイへ通知が表示されます。ドライバーが更新を開始すると、エッジがMenderへリクエストを送り、OTAが実行されます。更新イメージは約5GBあります。LTE回線ではなく、車両基地のWi-Fiを利用して配信しており、更新時間は約10分です。ドライバーが朝出社して更新を開始し、その間に準備をしているとアップデートが完了するイメージです。
安部：ソフトウェアの作成方法も見直しました。以前のように各車両へAnsibleで個別更新するのではなく、「ゴールデンイメージ」となる基準環境を作成し、そのイメージをOTAで配信しています。
山口：ゴールデンイメージをアップロードした後は、各車両がバージョンを比較し、必要な場合だけ更新する仕組みになっています。
安部： 更新処理では、MenderがOTAの更新ハンドラを呼び出します。
Mender自体は更新処理の入口を担当しており、実際の更新処理はOTAイメージ内に含まれているスクリプトが実行します。
イメージのダウンロード後、更新スクリプトの実行、再起動、起動確認まで順番に処理が進み、最後に正常に起動したことを確認して更新が完了します。
A/Bアップデートによる安全な更新
安部：OTAでは、更新に失敗して車両が起動しなくなることは避けなければなりません。そのため、エッジにはeMMCとNVMeを搭載し、システム領域はA/Bの2つのパーティションに分けています。
例えばA領域で動作している場合は、B領域へ新しいイメージを書き込みます。更新が正常に完了したことを確認してから起動先をBへ切り替えるため、万が一失敗しても元のA領域から起動できます。SSHキーなどの固有情報は共通領域へ保存しているため、更新後もそのまま利用できます。
山口：スマートフォンのOSアップデートと同じ考え方ですね。
安部：Menderは更新処理の入り口を担当するだけで、実際の更新処理はイメージ内のスクリプトで制御しています。Dockerコンテナが正常に起動することまで確認し、問題があればエラーとして更新を中止し、元の環境へ戻るようにしています。
山口：Orinは最初からA/Bアップデートに対応していたのでしょうか。
安部：NVIDIAの開発キットでは対応していましたが、現在利用している車載計算機については、供給元に対応していただきました。
山口：現在はどのくらいの頻度で更新していますか。
安部：新しいリリースは月に1回程度です。運用管理チームと相談しながら展開し、およそ1週間で全車両への更新を完了しています。開発用の計算機は、エンジニアの作業状況に応じて更新を後回しにできるようにしています。
今後の展望
山口：自動運転業界ではSDV（Software Defined Vehicle）が進み、車載システム全体をOTAで更新することが当たり前になりつつあります。今後の改善点はありますか。
安部：現在は約5GBのイメージを配信していますが、変更のない部分まで毎回ダウンロードするのは効率的ではありません。今後は差分アップデートに対応し、更新が必要なモジュールだけを配信することで、数MBから数百MB程度まで通信量を削減できる仕組みを実現したいと考えています。
山口：車両が300台、1,000台と増えていくと、ネットワーク全体を考えた配信設計も重要になりますね。
安部：CDNやMenderのローリングアップデート機能を活用しながら、ネットワーク負荷を抑えつつ、安全に更新を展開できる仕組みへ発展させていきたいと思っています。
チューリングでは、完全自動運転の技術を共に創る仲間を募集しています。今日お話ししたDriving System 1チームはもちろんのこと、機械学習エンジニア、リサーチャー、ソフトウェアエンジニア、組み込みエンジニア、インフラエンジニアなど、非常に幅広いエンジニア職種で仲間を募集しています。ご興味のある方は、ぜひ採用ページをご確認ください。多様な職種がありますので、ご自身がどれに当てはまるか、ぜひチェックしてみてください。
