CLOSE

トヨタの車はソフトウェアエンジニアが作る 〜Why Simple is So Complex〜(全4記事)

コネクティッドカーは難しいが、大きなチャンスがある トヨタの車はソフトウェアエンジニアが作る part.4

TECH PLAY主催のイベント「トヨタの車はソフトウェアエンジニアが作る 〜Why Simple is So Complex〜」で、トヨタ自動車の村田賢一氏が、変革期を迎えるクルマ業界におけるソフトウェア技術の研究・開発に関する取り組みについて共有しました。最後は「これからのコネクティッドカー」について。前回の記事はこちら。

コネクティッドシステムを支えるソフトウェア

村田賢一氏(以下、村田):さて、ここからはコネクティッドシステムを支えていくソフトウェアということで、インフラストラクチャ―、特に将来に対する取り組みについてをお話したいと思います。このお見せしている図の真ん中、通信・エッジコンピューティング、OTA-Software Updateについてです。

先ほどお見せしましたが、どんどんどんどんデータは多くなります。これをなんとかさばいていかなきゃいけないとなると、ちょっと違うことを考えなきゃいけないシーンが出てきます。

通信で言うと5Gの通信網整備が進んでいます。5Gの特徴は高速で大容量で低遅延、そして同時に多接続できるようなことが言われています。これ実は車で使うための要件をきっちり取り込んでいかないといけないんですよね。

実は車だけじゃないんですね。5Gはいろいろなところの産業応用をしっかり考えていこうとしています。こういった特徴を有効に活用していこうということで、いろいろな業界にアプローチを通信業界の方がしています。車、あるいはオートモーティブもそのうちの1つで、こういった機能、特徴を最大限に活かせるようなものに取り組んでいます。

コネクティッドカーのデータ種類と転送量は大幅に増加

我々の視点で言うと、コネクティッドカーの場合はデータの種類とか転送量がどんどん増加するのに対して、どうやって対応するかについて考えています。

もうちょっと具体的にデータ量のオーダーくらいまではご説明しちゃっていいかなと思います。10年以上前からやっていますけど、ナビプローブデータ、ナビの位置情報を集めて統計化して、どこの道が混んでいるみたいなのを取っています。これは最近増えたとしても、1ヶ月あたり数百メガバイト、実際は数十メガバイト程度で済んでいます。数メガバイトから数十メガバイト。

もっと地図を生成しようとしています。これは何を言っているかというと、車載のカメラからどこにどういう地図ができた、ペイントが変わったとかですね。そういったものが作れるんじゃないかと開発を今やっていますが、こういったのはやっぱり1ヶ月あたり数ギガバイトのデータを要します。

車の中のECU、Electronic Control Unitって言うんですけど、車の制御をしているユニットで、中の状態とかをしっかりモニターして車の健康状態みたいなのをずっと監視していくものもあります。こういったものももし全部取ったとすると数ギガバイトかかっちゃいますと。

さらにもっとセンシングのデータとかいう、と数十ギガバイトになっちゃいます。当然こんなデータ全部ネットワークで取ることはできないので、フィルターかけたりいろいろしていかなきゃいけないんです。でも、やっぱりほかの車のデータと比べるみたいなことが必要になってくることはあります。

エッジクラウドを使って、近いところのデータを比較して、比較結果だけを上にあげていく

こういったときにいきなりクラウドにあげるのではなくて、エッジクラウドという、近くのデータを集める場所に集めます。例えば東京の車は東京都内で、大阪走っている車は大阪府の中にあるサーバーに預ける感じです。そこで、データをやりとりして、さらに日本全土といったところのクラウドへどうしようかっていうと、データ量をさらに減らして集めます。

分析が終わったデータが集まったのをさらにみんなに配るみたいな感じですね。例えば、先ほど言った地図生成みたいなやつも、東京の、ここの渋谷で走っている車は渋谷駅周辺を走っている車と道玄坂から下がってくる車とデータを比較するみたいなことは必要かもしれないですけれど、同じ東京でも日本橋を走っている車と渋谷駅前を走っている車のデータを比較する必要はまったくないわけです。

なのでそうやってなるべく近いところのデータを比較して、比較結果だけを上にあげていくと。そういうことによってデータがどんどん少なくなっていくだろう。これがエッジコンピューティングっていう考え方です。

これはもちろんエッジクラウド間で車は移動しますので、そういったもののデータのトレースとかそういったものも含める意味で、専門的に言うと分散コンピューティング、エッジコンピューティングによる分散処理といったようなものになります。

トヨタ主導でエッジコンピューティングのコンソーシアムを設立

これも通信業界も含めていろいろなところと一緒にやっていかなければいけないことで、AECC、Automotive Edge Computing Consortiumをトヨタも主導でコンソーシアムを作りました。これは2018年に作りました。これ(スライドを指して)はAECCのプレゼン資料からいただいてきています。

ロゴが出ていますが、グローバル、かつ、いろいろな業界から集まって、今後こういったデータをネットワークやコンピューティングと組み合わせながら分散処理をしていくためにはどうしたらいいんだろう? みたいなことをこういった企業のみなさんと一緒にいろいろと考えています。「こういった技術を使っていこう」みたいな技術ディスカッションを一生懸命やっています。

AECCのホームページを見ていただければ、みなさんも参加しているメンバー企業の間でディスカッションした結果が、ホワイトペーパーというかたちで一部ディスクローズされていますので、ぜひ見ていただければいいかなと思います。

クラウドネイティブ技術により、効率良くエッジクラウドとクラウドを運用

こういったエッジコンピューティングはどういうことを意味しているのかと言うと、もうちょっとソフトウェアの視点からすると、通信のセルラー網とか、あるいはWi-Fiとかを使ってインターネットも使いながらいろいろなレイヤーでクラウド、あるいはエッジクラウドといったものが、階層化されています。さっきの(スライドでは)縦書きに書いてあったものを今横書きにしています。

ここでは上に行けば行くほど、この図で言うと右に行けば行くほど大きなエリアをカバーする。左に行けば行くほど狭いエリアをカバーするという意味で、その間をコネクティッドカーの普及状況とか必要なデータの取り具合、年代を追ってだんだんデータは増えると先ほど言いました通り、そういうふうにデータがどれくらい増えていくのかに合わせてクラウドもだんだんとスケーラブルに増やしていく発想です。

車の場所に近ければ近いほど当然遅延は少なくなっていくし、中継するところのデータも先ほど言ったように先に処理をして結果だけ上にあげていけばいいとなるので、トラフィックを削減できます。

Kubernetesを使って、コンテナの動的配置・最適化を実現

これを例えばソフトウェアの例で言うと、Kubernetesのようなソフトウェアのコンテナみたいな感じですね。ソフトウェアが動いているのを最初はサポートしていたんだけど、車が増えてきたよねっていうのを自動的に検知して、それをモニタリングして自動的に検知すると、Kubernetesのスケジューラーでアプリケーションがあった場所を変えていくことができます。

アプリケーションがあったロケーションを少しいじって、より近いところにアプリケーションをデプロイしていきます。そういったようなダイナミックなKubernetesのフィーチャーを利用したスケジューラーのようなことにも取り組んでいたりします。

クラウドを追求することにより、安心安全快適な車を使ったユースケースを実現できる

自動車会社がなんでこんなにクラウドのことを一生懸命やっているのかなと思いますが、こういった大量のデータをさばくと、大量のサービスに結び付けられるのとで、より安心安全快適な車を使ったユースケースを実現できる意味が大きいですね。サーバー側のことについても、いろいろな人と協力しながら、いろいろな会社さんと協力しながら車の要件を伝えながら一生懸命こういうことを一緒にやっています。

一緒にやっていると言いますが、実際我々のメンバーもですね、専門用語なんですが、Linux FoundationにLF Edgeというコンソーシアムがあり、そういったところのソフトウェアを実際に使って試したりとかですね。そういうのをしながら要件をソフトウェアで書いて提供したりとかいうことも実はしています。

End-to-Endコンピューティング

さらにもっと進んでいくと、これエッジ、End-to-Endコンピューティングですね。車の中も、これは我々がエッジデバイスと言っているもので、本当の意味のエンドなんです。

左端ですね。車の中でデータをフィルターかけといて、引っかかったデータだけ上にあげる。車のカメラが「ここ道変わったかも。持っている地図と違う」みたいなことがわかった時だけデータをネットワークにあげるいうものですね。それがだんだんだんだん先ほど言った階層化されたクラウドエッジを経由しながら、最終的にクラウドまで上がっていきます。

それが最終的には「何だろう? これは?」って言って、もうちょっと詳しく知りたいって言うともう1回その車のところに聞きにいくみたいなですね。そういったインタラクティブな分散協調システムみたいな。これをEnd-to-Endコンピューティングと言っていますが、車とクラウドがデータを行ったり来たりしながらやっています。

似て非なることなんですが、トヨタってジャストインタイムという言葉が好きなんですよね。必要なときに必要なものだけ取ってくればいいっていう、用意できればいいっていう。そういった考え方がありますが、非常に似ています。

似ているんですけどちょっと違うのは、ジャストインタイムと言うとちょうどぴったりに間に合うところ、早すぎもせず、当然デッドラインを越えてもダメでぴったりにもってこいということなんですが、この場合はぴったりにもってこいといっても、後ろはあんまりなくてですね。ちょっと早くてもしょうがないんです。

でも、必要がないときはデータは取らないよねと。こうやってデータ量を削減しながら必要なものをきちっと取っていくうなものも将来必要になるだろうということで、(スライドの)一番下にData-collection rulesって書いてありますが、こういったデータを集めるためのルール、仕組みの研究開発を進めています。

トヨタとNTTグループが協業して、実証実験を実施

あとNTTさんと協業しているのがプレスに出てたりもしましたので、少しだけみなさまにも紹介しておきます。これは車の通信とデータをどうやってさばくのかについて、エヌティーティーグループの各社様と一緒にやっています。

東京のお台場で車を走らせています。この赤い線がかかっているところが車が走ったところですが、その中でも特に5Gの検証エリアを用意して、実験用の5Gのネットワークを利用しながら5Gとの相性も含めて検討していました。

ここでやったことは、フィールドで実際に車を走らせながらデータを取得したりすることです。「走行データ、画像データ等をクラウドに収集した場合4G、5Gってどう違うのだろうか?」とかを検証しました

「4Gで車の台数とかお客さんがいっぱいいる通信を使っている中で、夜中みたいな人が少ないときとどう違うのだろうか?」というのを実際にフィールドで試しました。

トヨタは現地現物と言って、なんでも現場でちゃんとやらないと納得できない文化がありますので、しっかりやろうということでNTTグループの各社様と一緒にこういうのをやりました。

10ラック分のサーバーを使って、ダミーデータを生成し、500万台分のデータが集まったときの負荷テストを実施

もう1個は負荷検証ということで、例えばこういったデータが500万台集まって動き回っているとしたらどうなるんだろう? 500万台は日本で同時に車が動くとこのくらいの数字になります。こういった500万台といった規模の車が同時にデータをあげたらどんなことになっちゃうんだろうというようなものも検証しています。

もちろんこれは、500万台の車を実験でフィールドテストはできないので、シミュレーションというか、データジェネレーターみたいなのを実際に作って、それを実際に流して、「ソフトウェアとしてどういう挙動になるだろう?」「負荷が分散したほうがいいのか?」「集中してやったほうがいいのか?」とか、そういった負荷のスレッシュホールド(しきい値)を決めることを実際にやりました。

500万台分の車が生成するデータをもし送ったらみたいなやつを生成するだけでも、サーバーを確か10ラック分くらい使って、ダミーというか、生成されたシミュレーテッドデータなんですけど、それだけ使ったんですよ。よくそんなに使ったなぁと思いますが、NTTグループのみなさんにもご協力いただきながら、それだけのサーバーを用意してシミュレーションしました。

地図生成、障害物検知をユースケースに実証実験を行う

じゃあ実際どういった内容、ユースケースでやってきたのかというと、主にこの2つを説明させてください。1つは地図生成。先ほどから言っているように車載のカメラが撮影した動画をデータセンターに上げて、複数の車から見えている道の情報みたいなものから、「道がどう変わったのかな?」「今道になにか落ちていないかな?」みたいな。

「道にタンスが落ちてたり」というのは笑い話のように聞こえるんですけど、本当に高速道路にタンスって落ちているんですよ。引っ越しの荷物が落っことして行ったりとかですね。そういうの危ないですから。そういうのはなるべく通ったカメラの車で見つけて後続の車に危険だよって教えなきゃいけない。

そうやって車から撮影されたものが何かっていうのを調べて周りの車にリアルタイムにお知らせするっていうのが、今後のより重要な、自動運転も含めてですが、重要なファンダメンタルな技術になってきますので、そういうのをやってみようと実験していました。

もう1つ障害物検知です。あ、僕がしゃべっていたのが障害物検知のほうですね。地図生成のほうは道が変わったとか、今工事中でこのレーンが閉鎖されているとか、半分ダイナミックなものをどうやって地図として車で保持するのかに挑んでいます。

ここが、最初にちょっと言ったんですが、自動運転にも関わってくるようなところで、今こういったようなところをコネクティッドカーのユースケースとして実証実験をやっています。

もうちょっと具体的に言うと、車で映る前方カメラで映っている画像と、そのときの車のスピードとか、CANはController Area Networkの略なのですが、車の中のネットワークに流れているデータとか画像を集めて、それをクラウド、ないしはエッジクラウドに上げます。それを地図化します。

地図化する前には最初に加工されたところの地図の画像があるんですけど、これはオルソ画像と言うんですけど、斜めに見えているやつを平に上から見たものにします。Googleさんのマップとかでも同じようなのがありますよね。

こういう画像をまず作って、線がどこにあるかをAIを使って分析して、ここはまたいでいい線か、いけない線かとかですね。入っていいゼブラゾーンかそうじゃないか。あるいは上から見ているんじゃなくて横から見た図に直して、どんな標識があるのかみたいな。そういったものを記号化することを地図化と呼んでいます。

こういうのを用いたり、先ほど言ったようになにか物が落ちてたり、工事中だったりするっていうのをちゃんと判定して、後ろの車に投げる。それで安全にしましょうとなります。

ちょっとだけ余談を言うとですね。この障害物検知ってすごく難しくて、NTTのみなさんともよく「焼き芋屋問題」と言っています。ゆっくり進む車が、これは障害物なのかどうか。

みなさん、焼き芋屋さんとか竿竹屋さんが走っている車は避けていきますよね。後ろについていかないですよね。こういったようなことをどうやって判定するのかっていうのは、これもAIを使ってそういった低速車をどうやって判断してどうやって避けていくべきなのかを課題としています。

交差点のところで、左に曲がりたいなと思って左のレーンに寄せたりしますよね。でも信号変わってもなかなかこのレーン前に進まないな、曲がった先で混んでいるのかなと思うと交差点の手前のパチンコ屋の駐車場に並んでいる列だったとか、よくあるじゃないですか(笑)。それは避けていきたいよねと。

こういったものっていうのは横を通り過ぎていく車の画像から分析できるはずなんだと考えています。今そういったものを、どうやって渋滞を渋滞として認知するのか。これは一時的に止まっているだけなのかみたいな。そういった分析をしていこうと、NTTのグループのみなさまとやっています。

これ非常におもしろくてですね。実用化したいんですが、まだちょっとデータをこれだけ上げられる実環境が、5Gが道路上までまだまだ幅広く広がっていないんですね。

司会者:あー、通信が。

村田:今後はそういうところを進めていけるようになると、通信環境が整えばすぐにこういうのもできてくるかなと期待をしています。

司会者:おもしろそうですね。

村田:これは実際の中のソフトウェアの仕組みみたいなところになっていますが。車両の開発とサービスの開発は、先ほどいったように分析をしていって課題を見つけてみたいなところがあります。

そういうのは裏側にやっぱりデータがありますので。動いているところからデータを取ってきて、それを基盤として分析していくような、こういったクラウドのデータ分析基盤のにも今着手しています。

必要な人に必要な場所で必要な情報を届ける

これは、例えば必要な人に必要な場所で必要な情報を届けるジャストインタイム的な考え方で、例えば特定の曜日で特定の時間帯の特定の気象条件で危険度が高まる地点を特定していくことにチャレンジしています。

弊社のナビを買って使うと、デフォルトだと、「この先危険地域です。交通に十分注意して運転してください」っていう案内が出るんですよね。私、ナビのチーフエンジニアをやっていて言うのもなんなんですけども、ちょっとうざったいなって思うわけですよ(笑)。だいたいそういうのって毎回自分の家のそばの住宅街の中で出るんですね。

これはやっぱり必要な時に必要な分だけ出してもらったほうがよっぽど注意しますよね。毎日出てくると、「なんだいつも出てくるから」って無視しちゃうじゃないですか。いつも出てくるのはなぜかと言うと、過去の統計情報からここは危ないとわかっているところが地図に埋め込まれているので毎日出ちゃうんですよね。

それをちゃんと特定の曜日とか時間帯とか気象条件とかを見ながら、本当に今日は危ないですっていうのを上げるっていう。こういうのが重要なので、こういった分析がデータからできないかっていうのを今一生懸命やっています。

実際にこの実績値と予測値を比較してみるとすごく当たっているところまで出てきていますので、こういったサービスも近々みなさまに提供できるんじゃないかなと思っています。

災害時に通れた道のマッピングを行う

ほかにも通れた道マップ。これは何かと言うと、地震とか洪水とかそういうのが起きた時に、車が1つの道を3台以上通ったらここはきっと通れる道だということで、通れた道としてマークして、これをサーバーに上げて公開しています。

実はこれは弊社だけではなくてホンダさん、日産さんとも一緒にデータを交換してより精度を上げることで通れた道マップを作っています。災害が起きた場合はまずは通れた道マップと検索していただけますと、こういった情報がわかりますので。通れていないところは危険な場所ですので、あんまり行かないようにということも含めて、みなさんに知っていただければなと思っています。

実はそれ以外にもいろいろ取り組んでいまして、例えば札幌でやってみた凍結路の見える化みたいなところも、分析しています。これは車のスリップとかABSの作動条件とか、気象条件もそうですが、いろいろなデータを集めて、それから分析すると、「ここ凍結路だ。危ない」っていうのは実はだいぶの確率で推定ができることがわかっています。

こういったものをサービス化するのがデータ分析による将来のサービスということになっています。

無線通信によって、車のソフトウェアを継続的にアップデートする

最後になりますが、これは私の部署の説明です。今までの説明は他部署の説明でしたが、私もだいぶ関わってきているので説明してきましたが。私の部署の説明で言うと、Over The Air、無線を使ってソフトウェアをアップデートするというものです。パソコンとかスマホでは、これ当たり前じゃないですか。

これをちゃんと車でやっていきたいということで、進めています。実際にアップデートできる車は出てきているので、持ってらっしゃる方もいると思います。やっぱり新しいサービス、機能を車を買ったあとも、どんどんどんどん増やしていきたいという思いが我々はあるので一生懸命やっています。

中身としてはスマホのケースと同じで、我々も例えばナビだとT-Connect Appsと言って自由に選んでダウンロードしてインストールしてっていうようなところもやっています。そういったものはもともとAppsの仕組みが動いています。あるいは地図とかのデータですね。アプリが使うデータっていうのはどんどんどんどん、それは通信使ってダウンロードします。

なんですけど、もともとシステムに入っている組み込みのOSだったり、組み込みアプリ、こういったところはアップデートは今まであんまりやれていなかったところがあります。一部やっていますが。

これはスマホで言うと、例えば、スマホのOS、A社さんのホニャララOSとか、G社さんのAホニャララとかですね。OSがあると思うのですが、そういったものをアップデートする。アプリではないところのOSアップデートと言っているやつですね。それに対してやっていきます。

バグ1つで事故などの大きな問題になる。だからこそ、エンジニアの腕の見せどころになる

ただここ、先ほどからずっと言っていて、「なんで難しいの?」「こんなの当たり前やん」と言われると思います。でもこれ本当にね、バグ1つあっただけで大きな問題になります。例えばソフトウェア不具合で故障で、それが事故になったりとか。あるいは外から悪意を持った介入、侵入があって事故になったとか。これはあっちゃいけないんですね。

我々としては実は車の世界では機能安全規格ISO26262っていうソフトウェアが機能をちゃんと実現できているか。安全に機能を実現できていて、もしそれがなにかあった時はちゃんとフェールセーフの機構にちゃんと渡るかみたいな。そういった規格が実はあって、これに対応しています。

特に制御系のソフトウェアに対してはこれは必須です。こういったものをやるのは非常に難しいんですよ。リアルな世界をちゃんと動かしていこうとすると、バーチャルな世界でちょっと今レスポンス遅かったかな、スクロールがちょっとカクってなったかなとか、メールがまだ届いていないなとか。そういうので済まなくてですね。

ハンドル切ったんだけど、ちょっと車曲がるのが遅かったからガシャンっていうわけにはいかないわけですね。こういったものが我々の中では、難しいのですが、でもすごくやりがいがあって、ソフトウェアエンジニアとしての腕の見せどころになっていると思います。

やっぱり家電業界で私はソフトウェアをやったときに、組み込みソフトウェアの難しさが1回ありました。これはリアルタイムに反応するという意味の難しさです。

それに対してさらに自動車のソフトウェアは絶対に失敗しない。失敗してもちゃんとリカバーできる。あるいは失敗を検知できるな。そういった機能安全が非常に難しいが故にすごくおもしろいところだなと思って、今取り組んでいます。

Connectedは難しいが、大きなチャンスがある

そろそろ時間じゃないかなと思っているんですけど。

司会者:そうですね。あと5分弱くらいですね。

村田:じゃあまとめます。私はConnectedを司る部署にいまして、非常に取り組む課題とか難しさはあります。しかし、それが故に大きなチャンス、難しいところじゃないとやっぱりやりがいはないですからね。しかもそれを背水の陣でしっかりやっていかなきゃいけない状況に今ありますが、それを自分がちゃんと貢献できるという意味では非常に大きなチャンスかなと私は捉えています。

ちなみに今日はわりと全体的なお話をしましたが、今後もこういったものをもうちょっと深掘りするかたちでお話ししたいなと思っています。

これはまだ(仮)と書いてありますが、次回はこういった日程、11月末頃にUI/UXのところに関する取り組みについてもうちょっと深掘りして、私よりもきちっと深掘りして行きたいと思っています。ちょっと次の人にプレッシャーを与えていますが(笑)。

ちゃんと中身の細かいところまで説明してもらえると思ってますので、私がもう1回やることにならないことを祈りながら今日は終わりにしたいと思います。

司会者:村田さん、長時間ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!