Turing Tech Talk 第16回 「自動運転を支えるLinuxベースのミドルウェア開発」

2025年4月15日、チューリングではTuring Tech Talk 第15回 「自動運転を支えるLinuxベースのミドルウェア開発」と題したオンラインイベントを開催しました。

今回は、我々が自動運転をやるにあたって、自動運転システム開発の中でどのようなミドルウェアがあるのか、どのような開発をしているのかを、AI以外の低レイヤー周りに注目してお話ししました。当社のCTOである山口祐、シニアエンジニアの鈴木勝博が登壇し、現場とマネジメント双方の目線から解説を行いました。当日の模様を、イベントレポートとしてお届けいたします。

山口：皆さんこんにちは。Turing Tech Talk第16回、「車とAIをつなぐ自動運転を支えるベースのミドルウェア開発」を始めていきたいと思います。私はチューリングCTOの山口です。今回は担当エンジニアとして、Driving Softwaareチームからシニアエンジニアの鈴木勝博が来ています。

チューリングは自動運転のAI開発やGPUを作るとTech Talkでお伝えしてきましたが、車載のアプリケーションも内製で作っています。今日はAI以外の部分、特に車と計算機をつなぐ、あるいは計算機の中でも特に低レイヤー周りにフォーカスして開発の裏話をお伝えしていきます。内容に入る前に、まず登壇者の紹介をします。

鈴木：鈴木勝博と申します。ここに書かれている通りではありますが、パナソニックやデンソーに勤めておりました。パナソニックでは家電向けのSOCのハードウェアの制御ドライバーや、ビデオ・オーディオのデコーダーといったミドルウェアの開発に携わっていました。デンソーでは、車載向けのアクセラレーター上で動かすブートローダーやOSなどのソフトウェア開発をしていました。チューリングには去年の11月に入社し、車載ミドルウェアの開発を行っています。

山口：ありがとうございます。これまでハードウェアに近いところとソフトウェアの融合領域を担当してこられて、チューリングに入ってからも同様の分野でご活躍いただいていますね。

鈴木：そうですね。専門性が活かせて嬉しいと思っています。

山口：2024年11月に入社して、約5ヶ月経ちましたね。シニアのソフトエンジニアとして大変活躍いただいているので、今日はミドルウェアの開発周りや、チューリングがどのような思想で開発しているかを含めて話を聞いていきます。

Turing Tech Talkは16回目になりますが、私とエンジニアからチューリングの開発全体についてお伝えする場となっております。

具体的にどのようなことをしているかをお話していきます。完全自動運転は当然ながら簡単にはできず、まずはEnd-to-Endという自動運転AIと呼ばれる限界まで賢いモデルを作ろうとしています。我々は自社で収集した自動運転のデータセットで自動運転のAIモデルを学習し、更に車載計算機の中で動くソフトウェアを開発しています。

スライドの右上が我々の自動運転の車両です。データ収集でも自動運転の走行テストも同じ車両で実施しています。この車両を実際に動かすところを急ピッチで進めているところです。

今日のメインテーマは、車載アプリケーションまたは車とどのように通信するか、になります。Driving Sotfwareチームでは、モダンなソフトウェアスタックを活用しながら生産性の高い開発フローを構築して、日々開発をしています。

余談になりますが、我々はチューリングの本社オフィスがある大崎からライブをお送りしています。このスライドの右下・右上の画像は大崎ではなく我々の車両開発拠点である平和島になります。この拠点で、日々車と向き合っています。

鈴木も含めDriving Sotfwareチームは普段はそちらで活動しており、まさに車の側でどのようなソフトウェア開発を進めているのかをじっくりと聞いていきたいと思っています。

本題に入る前に、今日のトークテーマにも入っているミドルウェアについて簡単に説明させてください。一般的にミドルウェアというものは、コンピュータシステムにおいて、OSとアプリケーションの間をつなぐソフトウェア全般のことを指します。

アプリケーションからすると、通信やデータベース、メッセージング機能などは自分で実装しなくても共通した基盤があったらありがたいのですが、OSの組み込み機能としては存在しないような非常に中途半端な存在です。

それをまとめてソフトウェアとして完備することで、OSとは別にOS上で動くミドルウェアがあり、それを別のアプリケーションが呼び出して使うことができます。それが一般的にミドルウェアと呼ばれるものです。

これはソフトウェア開発全般で定義されているもので、例えば共通機能の提供や、異なる環境下（OSの違い、言語の違い、アプリケーションの違い等）でもうまく通信、結合するという点では重要になっています。

ミドルウェア開発はすごく奥が深く、また昔から盛んに開発が進められており、我々も普段は意識しないけれど実はミドルウェアにお世話になっています。

上記は一般的なソフトウェアのPCやスマートフォン、あるいはこのYouTubeを配信している環境などの話ですが、今日は特に車の中でどのようなミドルウェアがあるのか、どのような開発をしているのかにフォーカスして話をしていきます。

前置きが長くなってしまいましたが、本題の「自動運転を支えるLinuxベースのミドルウェア開発」について始めたいと思います。よろしくお願いします。

鈴木：よろしくお願いします。

一言でミドルウェアと言っても、先ほどの説明のようにさまざまなソフトウェアをまとめて指した用語になっています。

人によってはライブラリもミドルウェアに含めますし、ミドルウェアとして単体で製品で売っているものだけがミドルウェアと考える人もいます。

この説明では、自動運転を実現するために必要なコード以外の基盤となるようなソフトウェアのことを、すべてミドルウェアと呼んでいます。

我々のアプローチはカメラの画像をニューラルネットワークに入れて、どちらへ行ったら良いかの経路を出し、それを直接出力する方式を採用しています。これがアプリケーションだとすると、カメラの画像はどのように入れるのか、もしくは、パスを出したのは良いけれどもそのパスをどのようにハンドルの切れ角にするか、アクセルの開け具合をどのようにするか、また矢印部分に書いてある通信はどうしているんですか、など、そういったところを担うのがミドルウェアの役割になります。

地味ですが、これがないと車載AIコンピュータでは自動運転が実現できません。ここを作るチームが、我々Driving Sotfwareチームとなります。

山口：ありがとうございます。我々は自動運転AIを作っていますが、AIだけを作ったら車が動くかというとまったく違います。先ほど説明があったように、カメラや通信ネットワークがあって、更にそれを描画するなど、多種多様なアプリケーションやOSとのコミュニケーションが必要になってきます。AI以外の部分も、Driving Sotfwareチームは一手にソフトウェア開発をしているんですね。

鈴木：そうです。ただ我々が1から全てのコードを書いているわけではありません。既存の十分に動くライブラリがあればそれを使っていますし、そのライブラリを並べただけでは動かないので、その間をつなぐようなソフトウェアを開発することが主な仕事になります。

もちろん必要なものに関しては自分たちで作っていて、この図で言えばプロセス間通信や、CANと通信をする部分は自分たちで作っているところです。

山口：この中で、プロセス間通信やCANの通信は私がイメージするミドルウェアにかなり近いです。普通のアプリケーションでも、アプリケーション間のメッセージングシステムなどはミドルウェアに属すると思います。車載の場合だと、この辺りがまさにミドルウェアとして振る舞っているんですね。

鈴木：そうですね。我々の自動運転ソフトウェアは、様々な機能を持ったアプリケーションがプロセス間通信でデータをやり取りする作りになっています。そのために、プロセス間通信がこのシステムの根幹を支える部分になります。また、車と繋ぐにはCANが当然必要なので、その部分も車を動かすという意味ではまた1つの根幹です。そのためこの2つは、自動運転のミドルウェアとしては比重が大きいです。

山口：ここで「CANとは何？」と思ってる方がいるかなと思っています。CANについて是非教えてください。

鈴木：CANというのは、Controller Area Networkという単語の略です。40年前に、ドイツのBosch社が開発しました。国際規格のISO11898として標準化されて、世界中で使われてる規格になってます。

特徴としては、CANがない場合は（左図）センサーとECUが複数ある時に、全部を線で直接繋ぐと線だらけになってしまいます。車では1個のセンサーがボンネットにあって、もう1個のセンサーは後ろのトランク側にあるような状況が普通にあるので、そうなると長い線が色々なところに張ってしまいます。

しかしCANがある場合はそれを2本の線にまとめて、それをシェアする形で線の数を劇的に減らしています。これはとても画期的なネットワークで、シンプルになるし、価格が安くもなります。

ただ、信号をまとめて1本にするだけだと、センサーから複数同時に送られてきた時にどうするのかが気になると思います。それについては各ノードにIDが振られていて、衝突回避のシステムがあります。センサーの優先度なども設定できるようになっていて、またデータが壊れたり送ってる間にノイズが発生した場合もチェックができるようになっており、車向けの仕組みが入ったネットワークになってます。通信速度はさほど早くなく、最高でも約1Mbpsのシンプルなネットワークバスになってます。

山口：ありがとうございます。ここを是非詳しく知りたいなと思います。電気信号を流すための線が2つ走っていて、そこへサブ信号が流れてお互い決まっているプロトコルでコミュニケーションするようなイメージですよね。これが40年前のパソコン黎明期にすでに出来ているというのは驚きです。

車にはエンジン、車のボディ、ハンドル、アクセル、ブレーキ、タイヤがあって、皆さんそのようなメカの部分をイメージする方が多いと思います。

最近の車はコンピューターですからECUと呼ばれるものがついていて、例えば車についている自動運転システムのカメラを司るECUもあれば、車の電動パワーステアリングシステムを司るECUもあって、色々なコンピューターがそれらを頻繁に通信することで成り立っています。我々が思っている以上に、車の中は騒がしく通信をしていて、その通信のメインはCANになっています。

鈴木：そうですね。これからイーサネットに置き換わるという話もありますが、CANはまだまだ現役で使われると思います。

山口：おそらく国産車では、基本的にCANの通信をメインでやってるところが多いと思います。それが今後、イーサネットに置き換わっていく、あるいはCAN以外の規格だとLINもあると思います。様々な通信規格がありますが、我々はこのCANを使って車の情報を読んだり制御したりしています。

このCANという規格は、車以外だと家電などでも使われていますか？

鈴木：家電では聞いたことがないですが、産業機器であればもしかしたら使っているかもしれないです。各ネットワークで最適な線の長さと通信距離があり、伸ばせば伸ばすほど（速度が）落ちる規格もあります。

通信できるからといって何でも使って良いわけではないので、CANは車のようなサイズ、使用用途に適してるネットワークなんだと思います。

山口：例えばロボットやロケットなど、産業機器でも使われているのではないかと小耳に挟んだこともあります。一般的な身の回りの製品としては、あまりメジャーではないけれども、車では大変よく使われている特殊な通信の規格だということですね。

鈴木：CANから、ソフトウェアの話に戻ります。

我々の自動運転システムとUI（UIについてはTech Talk #14をご覧ください）とは、Dockerというコンテナのシステムで切り分けられており、お互いに影響を及ぼさない作りになっています。

自動運転システムの中では、各仕事に専念するアプリケーションが何個か立ち上がっています。この図で言うと、modelはAIの推論だけを行い、encoderはカメラの画像をよりサイズの小さな形式に圧縮して記録します。個別に役割を割り当てて、各アプリケーションがプロセス間通信でデータをやり取りして連携する作りになっています。

今回は、車とAIをつなぐコントローラーとCANが出てくる縦のラインのところを紹介していきます。

山口：ありがとうございます。さりげなくTech Talk過去回（#14）についても触れていますが、#14と#12は鈴木と同じDriving Softwareチームのメンバーが登壇して、車載アプリケーションや車載のUIをどう作っているかをお話しました。是非そちらもチェックしてみてください。

この図で表しているところも我々が開発しているところのごく一部の図だと思っていて、実際にはこれより更にとんでもない複雑さがありますよね。

本題に入る前に、この車載システムについて聞いていこうと思います。これはどの様なデバイスの上でこういったソフトウェアが動いているのでしょうか？

鈴木：NVIDIAのJetson Orin NXというSOCが乗った1つの計算機の上で全て動かしています。この図の下に書いてあるカメラや各センサー、SSDなどの記憶体は、全部Orinの乗ったデバイスに接続されている形になります。

※Tech Talk#9にて、チューリングのデータ収集車両徹底解説として車載計算機がどのように繋がってるか等を詳しく解説しています。

山口：車載の計算機は産業用のデスクトップPCをイメージするのが1番近いと思いますが、CPUがARMで、GPUはNVIDIAのOrinが乗っています。CPUもGPUもフルで使い切って、自動運転のためのアプリケーションを動かしていく、あるいはそのためのアプリケーションを作っていくことが我々のやっていることですね。

次にソフトウェアレイヤーについても見ていこうと思います。OSはLinuxで、さらにその上にDockerですね。これは開発用ではなくて、実際に自動運転のシステムが車を動かす時にもDockerが動いているんでしょうか。

鈴木：そうですね。Dockerが動いて、コンテナの中で自動運転システムが動いている形になります。

組み込みでは珍しい構成だと思いますが、CIなどとの相性が良いのと、環境が綺麗に整備しやすいメリットがあります。Web系の開発をされている方には常識かと思いますが、その恩恵を我々も受けられないかと考えてコンテナを使う設計になってます。

山口：車載Edgeの環境開発や組み込みの開発でコンテナを高度に使うことは、多くはないと思います。

実はチューリングはコンテナ上での開発をここ1年くらいしていて、この辺りの開発のプロセスやツール周りもモダンなところを使っています。先ほどCANは40年前の技術を使っているとお話をしましたが、その裏側で動いてるアプリケーション開発部分は最新に近いところになっています。

もう少し上のレイヤーの話もしていきます。ここでcontrollerと書いていますが、ここは車の制御をするところですね。

鈴木：そうです。モデルが「こういう向きに行ってください」とパスを出した後に、「実際どの程度横に行ったらいい？」「どれくらい前に行ったらいい？」という数値に変換されて、それがCANの通信で車のコンピューターに送られる構造になっています。

山口：ハンドル、アクセル、ブレーキをどのくらい動かすかはソフトウェアから信号を送る必要があり、そこを司っているのがcontrollerというモジュールになっているんですね。

それがLinux上のアプリケーションとして実装されてるという部分は理解できましたが、実際に車に伝えるという部分が今日の本題になります。

鈴木：我々の自動運転システムから、行きたい方向を車に伝える「口」の役割をする部分を作る必要があります。

そのために、車にそういった「口」をつける改造もありですが、今だとそんなことをする必要はありません。我々が使っているアルファードには、ADAS（先進運転支援システム）がすでに乗っていて、レーンをキープしたり、前に障害物があったらブレーキをかけるシステムが搭載されています。つまりそれは、車のアクセルやブレーキ、ハンドルを制御できる「口」がすでに存在してるということです。

アルファードの場合は、前方カメラ（ミラー裏）からADAS用のECUにCANが通信されています。そこに我々のシステムを割り込ませて、ADASのシステムを上書きして、行きたい方向に車を走らせてもらう仕組みにしています。それが左下の図になります。

前方カメラから来ているCANを取ってMCUに入れて、MCUから自動運転システムが行きたい方向の信号を載せたCANをADAS ECUに送る仕組みになってます。

前方カメラからCANを取っているのにも理由があります。ADASのシステム全部を上書きして良いわけではなく、例えば加減速を制御する場合は加減速の信号だけ上書きをしたいにも関わらず、その他の信号もCANに載っている状態です。その他の信号についてはスルーして、加減速の信号はフィルターで捨て、その代わりに自動運転システムから入ってきた信号をADAS ECUに送ってあげます。

こうすると、加減速は我々の制御下でありながら、それ以外のADASが動くために必要な信号はそのままとなります。このようにしないと、ADASは前方カメラが壊れたと判定をして止まってしまいますが、それが起きないようにうまく騙すことでADASに我々のやりたい制御をやってもらっています。

山口：アルファードのミラー裏は、皆さんあまり普段は注目しないところかと思います。車にはバックミラーがありますが、実はバックミラーがついてるところの台座部分に力を入れると取ることができます。その中に、コンピューターやECUと呼ばれる車載コンピューターが入っていて、そこがその車の運転を司る司令塔の役割になっています。

そこにコネクタがあって、それがまさにCANの通信を司ってるコネクター線です。そこを抜いて、MCUと書いてる部分で中継器を噛ませて、出てきた信号をオーバーライドしています。もちろん安全性を考慮した上ですが、このようにして上書きするかたちでステアリングやアクセル、ブレーキなどをコントロールしています。

我々は自分たちで車を作っているわけではなくて、既存の車を改造して使用しています。そのため、まるで既存の車をハックするようにして通信を上書きし、車のコントロールをしています。安全性の面で見ると、急に信号が途絶して車がおかしな挙動にならないか等を相当ケアしながら開発をしています。

鈴木：せっかく安全性というお話が出たので、補足させていただきます。NVIDIAのOrinで動かしているシステムはLinuxベースのシステムになりますが、MCUで動かしているシステムについては、実はLinuxは使っていません。Linuxが必要なほど複雑なことをしていない、またCANは例えばハンドルを切るのが遅れることで変な方向に車を動かしてしまうことがあるため、リアルタイムなセーブが必要なシステムになっています。

OSは使っておらず、マイコンの上にベアメタルなシステムを構築して、遅れてはいけない信号をスルーし、我々の信号も遅れないようにADASに伝えるというような仕事をしています。

山口：右側の図でOrinと書いているところは先ほども伝えた車載の計算機で、これはLinuxベースのところです。USBのインターフェースだと思いますが、USBで通信されてくるのはCANの信号ではないんですか？　CANは電気的なサブ信号だと思うのですが、ここは別のプロトコルになっているのでしょうか。

鈴木：USBのプロトコルなのですが、そのパケットの中に入っているものは、CANで伝えて欲しいデータがそのまま入っています。

そのため図の真ん中にCAN変換と書いてあるのは、USBのパケットからデータを取り出してCANのフレームにしてADAS側に送る処理が走っています。

山口：ちなみにCANのUSBで送られてきたパケットを、LinuxのOSでハンドリングするようなものも必要でしょうか。

鈴木：はい。読み出し側もあって、CANに伸びている線がそれになります。こちらは遅れても大丈夫というのもありますが、今の通信ではUSBはリアルタイム性を保証しておらず、読み出し側はそういった作りになってます。

山口：controller部分が車の運動をさせたいとなったら、「ハンドルをこのくらい切る」という命令があり、それをCANの信号に一度LinuxのOS側で変換し、変換したものをUSBを介してMCUに送り、MCUからCANの線に送りこむ流れですね。

この辺りのお話はソフトウェアだけで完結しないですよね。通信やハードウェアの制約もすごくたくさんあると思います。実際にチューリングに入って、車載のミドルウェアを扱って苦労したお話があれば、言える範囲で聞きたいと思いますが、どうでしょうか。

鈴木：この図の中にちょうどあります。USB I/FとOrinを繋いでるのがUSBですが、OrinのUSBが少し特殊で、ハブを介すことで遅くなってしまう挙動をして、MCU側に信号を送るのが遅れてしまう事態に遭遇したことがあります。

このMCUを我々のシステムでは2個使っていますが、1番2番と順番に送ると間に合わないため、送るスレッドを分けて並列で送ることでギリギリ間に合うタイミングで送れることが分かりました。controller部分を改造して並列に送るような対策をして、 今は動かしています。

山口：計算機とUSBのインターフェースのところでハードウェア的な仕様があって、Linux上のアプリケーション側のスレッドをどう使うかという点を、ソフトウェア的に対応することによって解決したということですね。

そのようにハードウェアとの問題の切り分けも難しいと感じますか？

鈴木：そうですね。その問題に関して言えば、NVIDIA製ではない別のUSBコントローラーに接続して同じ問題が出るか、またパソコンだとどうか、プロトコルアナイザーを使って何の信号がどのタイミングで流れているか等を、Orinでしか起きないと突き止めた上で今回の 対策をしています。

山口：せっかくなので、このようなシステムをどういった環境で開発しているのかも聞いていきたいと思います。

車に計算機が乗っているということは先ほど教えてもらいましたが、実際にずっと車に乗って開発してるわけにもいかないと思います。 普段どのような状態で開発しているのでしょうか。

車載計算機はARMだけどx86の開発機などの普通のサーバーで開発しているのか、それとも車載の計算機とリモートで通信して開発しているのか、開発の環境を教えていただけますか。

鈴木：結論を言うと、全部あります。 x86で限定された機能は動くので、それで開発していることもありますし、 車載コンピュータと全く同じものが机の上にあって、それで動かしていることもあります。人によってはクラウド上にARMやx86のコンテナを立ち上げて、その上で開発している人もいます。

我々のシステムが多様な環境でビルドできるようになってるというのもありますが、最も開発スピードが上がるような環境を選んで開発しています。

山口：以前のTech Talkでもお話しましたが、ソフトウェア開発でCI/CDのようなところは、一般的にSaaS開発であればあまり考えることはないと思います。

しかし車載の計算機が絡むと、CI/CDが簡単にできないように考えているのですが、その辺 はどうしていますか。

鈴木：例えば繋がっているセンサーが足りないとか、車のエンジンがかかっていないと来ない信号もあって、そういったものが再現できないので、最後の最後は車に乗っている車載コンピューターで動かして、再現できるところは CI/CDのx86のサーバーやARMのサーバーで自動的にテストを回して労力を減らすという使い分けをしています。

山口：やはり最後は車で動かさないといけないんですね。

鈴木：そうですね。どうしてもその部分が残ってしまうのは組み込み系の辛いところではあります。

山口：車1台丸ごとCIサーバーにするわけにもいかないですもんね。

鈴木：それもちょっと考えましたが、車は邪魔ということもあり今はやっていないです。

山口：現役を引退した車がもし出てきたら、CI機になるかもしれませんね。

鈴木：年中エンジンをかけておくのも給電の面でも現実的ではないですね。

山口：ハードウェアのことも含めて聞いてきましたが、鈴木さん以外にもチームのメンバー がいて、基本的にはこの車載のアプリケーションをみんなで作っていると思います。

ミドルウェアもあればハードウェアに近いところもあるし、ソフトウェアだけで完結するアプリケーションとして作っているところもありますが、その開発フローはどうなっているのでしょうか？　例えばリリースサイクルや共有レビューはどういう形でやってるのでしょうか。

鈴木：我々はGithubに「このような変更を入れたいです」というプルリクエストを作って、 レビューをしてOKとなるとマージされるような割とスタンダードな開発フローを置いています。リリースサイクルはまだ開発中ということもあり、一定期間である程度機能を追加したら出す形になっていますが、これから運用する台数が増えたらリリースバージョンを固定して動かす車などが出てくると思いますので、リリースフローは複雑になると思います。

今はすごくシンプルで、1番新しいものが1番新しいバージョンになって出ていく形になってます。

山口：ソフトウェア開発は組み込みなど低レイヤーなところを使っているけれども、意外と普通のソフトウェアエンジニアリングのフローと近いことをやっているんですね。

そういったモダンな開発のツールや仕組みに乗っかりつつも、車というハードウェアの1番面白いところと連携しながら進めていると。

そのような会社はあまり多くはないと思っていて、ロボット開発の会社でもここまで大規模に複雑なところをやる機会はそうそうないと思います。車ならではの面白さがありますね。

鈴木：安全性に関しての続きになりますが、 先ほどはソフトウェア的なガードの仕組みをご紹介しました。「そもそもガードがバグっていたらどうしますか？」という話は当然あって、そこで無策は良くないです。

すごく原始的な手段ではありますが、我々の自動運転システムとADAS ECUの間に物理的なスイッチを挟んでいます。おかしな動きをして止まらないようなことがあればこれを押すと、自動運転システムからの信号は全て遮断され、少なくともおかしな信号はADAS ECUに行かなくなる仕組みを最後の最後の防壁として設置しています。

また、全て正しいけどおかしい経路というものも自動運転では存在して、「この気候では全て正しいリミットの中の加速度だし切れ角だけど、壁の方に行ってしまう」ようなものは実験の時に乗っているドライバーが判断して止める仕組みになっています。

このようなことが求められるため、腕のあるドライバーの方にご協力いただいて実験をしています。

山口：ありがとうございます。ドライバーも車が急な動きをした時にうまくコントロールする技術がある方が乗っているわけですが、 ソフトウェア的に如何ともし難い時が万が一あった際には、この緊急停止ボタンを使用して、物理的にCANの線を遮断するわけですね。安全性を非常に重要視して、安全に安全を重ねているところです。

※以降では、参加者との質疑応答が展開されました。本イベントの全内容は、ぜひ以下のリンクからご覧ください。

【イベント概要】
Turing Tech Talk #16 自動運転を支えるLinuxベースのミドルウェア開発
https://www.youtube.com/watch?v=SmcX3AHiuCo&list=PL757EZ4TpBICoefL5i5Ys6T2dJ0QsP3lh&index=2