なぜトヨタ車は1万種類以上のデータを複雑処理できるのか？　トヨタのエンジニアたちの“泥臭い”工夫

トヨタのクルマ開発の「今」を語る

飯山真一氏（以下、飯山）：第1回から第3回はCASE、UX/UI、コネクティッドを中心とした先端技術活用事例についてお話をしてきました。本日は少し視点を変えて、それらを支えているクルマそのものの開発に注目したお話をしたいと思っています。「ソフトウェアエンジニアが革新するクルマ開発の伝統」というタイトルで、技術的な側面も織り交ぜてお話しできればと考えております。なかなか社外で話されることのないトヨタのクルマの開発についてお話しします。

具体的なデータや事例を基に、開発の現場が向き合っている日々の挑戦の一端をお伝えできればと思っております。内容にはあえて技術的な話を含めていて、少しわかりづらい部分もあると思います。用語については、なるべくわかりやすい言葉にするように努めているんですけど、わかりづらい場合はご了承いただければと思います。

私は飯山と申します。今は制御電子プラットフォーム開発部 制御ネットワーク・アーキ開発室に所属しています。この部署では、クルマの中のネットワークや情報セキュリティに関する開発と車両への適用を担当しています。私自身は2005年に入社して以来、クルマの中のネットワークを中心として主にソフトウェアに関する研究・先行開発、量産開発に携わって参りました。

長尾洋平氏（以下、長尾）：長尾と申します。よろしくお願いします。トヨタ自動車の制御電子プラットフォーム開発部に所属しています。後に話すWoven COREに関しても兼任しており、私は2017年まで電機メーカーに勤めておりまして、2017年からトヨタ自動車に入社しています。

過去には組み込み向けのコンパイラシステムなどを開発しておりまして、高信頼性ソフトウェア技術の開発もやっていました。あとは自動車向けのソフトウェア開発もリーディングしておりまして、今世の中に走っているクルマにはそのソフトウェアが載っていたりします。トヨタ自動車では入社歴はまだ浅いですけど、自動運転や設計手法などに関して業務をしています。よろしくお願いします。

では、本題に入っていく前に今日の中継場所について、少しだけ触れたいなと思います。今日はトヨタ自動車の技術本館という、愛知県豊田市にある建物から中継しています。トヨタ自動車の本社地区はとても広いんですが、その中にある技術本館の建物から中継しています。

もしよければ、お手元にある地図アプリなどで「トヨタ自動車 技術本館」と入れてみていただきたいなと思います。そうするとすぐに「ここだよ」というのが見れるかなと思います。もし、ご興味がある方はそのまま航空写真のモードにしていただいて少し引いていただければ、すぐ北東にトヨタ自動車のテストコースもご覧になることができます。よろしければ見てみてください。

今回のようにトヨタ自動車の技術本館から、不特定多数の方に向けて直接配信することはなかなかないんですね。なので、本当はカメラを今から持ってトヨタ自動車の中のオフィスも紹介したかったんですけど、今日は残念ながら会議室から中継したいと思っています。

私たちがトヨタに入った理由

長尾：それでは少しずつ本題に入っていきたいなと思っております。まずは少し私たちのことを知っていただきたいなと思いまして、我々2人がトヨタ自動車で働いている動機などについて、少しずつご紹介したいなと思っています。

まずは私、長尾から紹介します。私は単純に小さい頃からクルマが好きだったんですね。例えばミニ四駆をやっていたりしたんですけど、従兄弟のおじさんがクルマがすごく好きで、いつも綺麗にしていたりしていました。そういうところから、クルマへの触れ合いが始まっていました。

旅行でクルマをみなさんよく使われたりすると思うんですけど、旅行先でのいろいろな経験を得られるための手段として便利な道具なんだなと、そう考えながら大きくなってきました。

実際は転職前も自動車に関わる仕事をしていたんですけど、やはりシステムのセットメーカーとしてのクルマそのものを作りたい気持ちが強くなりました。これが今回の転職した経緯になっています。

トヨタ自動車をなぜ選んだかと言いますと、大きな事業規模だったからです。ハイブリッドやエンジンや水素といった技術の幅広さに惹かれて、トヨタ自動車を選びました。実はもう少し詳しい話はtalentbookでも説明してありますので、もしご興味がありましたら、他のエンジニアの声も聞けますので、ご覧になっていただけるといいかなと思います。

飯山：私の志望動機なんですけど、私も何かを動かすことが好きでして、学生時代からロボットや電子工作、プログラミングなどをして楽しんでいた感じです。就職にあたっては、小型モーターの会社や電機メーカーのソフトウェア部門など、いろいろな分野に興味を持っていたんですけど、最終的には自動車業界に入ろうと思いました。

後ほど紹介したいと思いますけど、その当時の専門の観点でクルマは特殊な製品だと気付いて、その特殊性に惹かれたのがきっかけです。自分の持つ技術を使って高級車に採用されている安全技術を安くして、より多くのクルマに入れることで、社会全体の交通事故を減らしていきたい夢を持つようになりました。

他社と比較して高いシェアを持っていたトヨタ自動車であれば、その夢を実現しやすいのかなという、若干安易な理由で入社した状況です。

トヨタでクルマ開発に携わる醍醐味

飯山：私がこの自動車業界に入った動機の1つについて説明していきたいなと思っています。スライドに書かれているのは組み込みシステムとしてよく出てくるものになります。左側に家電、右側に航空機、宇宙機、電車という写真やイラストを貼っていますけど、クルマはこの両方の特徴を持っていると私は思っています。

少しの欠陥が人命に関わる点において、航空機、宇宙機、電車は高い信頼性やリアルタイム性が求められます。クルマも同じ程度か、それ以上の信頼性やリアルタイム性が求められるんですが、電車や飛行機は訓練された人が操作して、ほぼ決められた経路の中で運用されることが多いですね。その信頼性をまた確保するために、多重系のシステムを組むことも当たり前だったりします。

一方で自動車はそれほど訓練されていない人誰もが運転できて、移動を楽しむことができます。走る道も運転者の自由ですし、普通に舗装された道路だけではなくて、砂漠のような場所も走ることができます。コスト制約が厳しくて、信頼性を確保するためにシステムを多重系にするのは少し無理という状況です。誰もが使えて身近という意味ではクルマは家電に近いと言えます。

アクセルを踏めば進みますし、ブレーキを踏めば減速し、ハンドルを切れば左右に曲がるという具合です。ある意味、たったこれだけでクルマを操作できますし、自動車メーカーが違ってもほぼ同じというおもしろい製品だと思います。

家電とクルマが決定的に違うのはリアルタイム性だと思っています。例がいいかどうかわからないんですけど、もし炊飯器のタイマーに欠陥があってある日朝ごはんに間に合わなかったとしても命が危険になることはないと思います。

もし同じようにクルマのタイマーに欠陥があって、ブレーキが働かなかった場合、事故につながる可能性があります。事故にならなくても安心という意味では問題になるかなと思います。まとめると、誰もが扱えるという意味で家電のように身近なのに航空機、宇宙機と同じような信頼性が求められてコスト制御が厳しい。そういうものが自動車だと私は考えます。

また、この1台のクルマの中に3万点の部品が組み合わさってできているとよく言われています。この特殊なクルマという1つの製品の中にいろいろな技術が凝縮されています。そういった意味で幅広い技術を経験するチャンスがあってモノを動かす楽しさが感じられると思います。

クルマは自動車メーカー1社だけでは作れないものですから、多くの関係会社のみなさんとつながりあって1つのものを作り上げていく過程を味わえるのもおもしろさの1つかなと思います。

クルマ開発におけるコンピューターネットワークの仕組み

飯山：それでは、本題に入っていきたいなと思います。これまでの会では冒頭に申し上げたように自動運転やMaaS、UX/UIのキーワードでクルマ作りを紹介してきましたが、実際はそれだけではありません。一見華やかに見える開発を支えるような、もう少し泥臭い開発の部分に焦点を当てて今回は説明していきたいなと思います。

クルマを動かすものとして、みなさんがよくご存知の通りエンジン、トランスミッション、サスペンション、ボディフレームといった、いわゆる機械部品メーカーの部分とそれらを便宜的に制御する電子装備部品に分けられます。自動運転を実現させるためにも、こういった部品は必要ですし、時代に則した安心安全を実現するために、負けず劣らずこういった分野も日々新しい開発が続けられています。

機械部品については、よくクルマのカタログや雑誌などに取り上げられる部分ではあると思いますが、電子装備部品についてはなかなか目にする機会は少ないのかなと思います。ですから今回はここにスポットを当てて説明していきたいと思います。

このスライドなんですけど、ここではクルマの中のコンピューターネットワークについて紹介しています。左の図は電子装備部品全体、クルマの中のネットワーク構成を表しています。現在、弊社のクルマの中でもっとも複雑な構成の1つはこんな感じになっています。

右の図はだいぶ昔のモデルのものになるんですけど、クルマの中にある電線だけを抜き出した写真になります。こういった電線がふだん見えないクルマのボディの中に隠れている。所狭しと張っているような感じです。

左側の図に戻ると、この黄色い箱の一つひとつがECUと呼ばれるコンピューターになっています。例えば、エンジンを制御するコンピューターとかブレーキを制御するコンピューター、エアコンを制御するコンピューターというかたちで、それぞれの役割を担っています。

この車両の場合、90個以上のコンピューターがCANと呼ばれる通信のプロトコルを使ってお互いの情報を交換しながら動作しています。

このようなネットワークにつながるコンピューターはどんどん増えていて、2000年頭ぐらいには10個程度だったものが、2017年頃には約190種類ぐらいになっています。さらに、そこに流れるデータは同じ2017年時点で1万3,000種類ぐらいにもなっていて、大規模化で複雑化の意図をたどっているという状況です。

この車両の場合にはクルマ全体のこの90個のECUを統合制御するようなコンピューターというのは実はありません。各コンピューターが独立していて自立的に動いています。どういうことかと言うと、ある1つのコンピューターだけで捕まえるとインプットとアウトプットがその入力と出力が決まっていて、インプットをされたものを処理して出力するかたちになります。

なのでネットワークでつながっている場合には、どこかから届いてきた信号を受け取って、それを他のコンピューターに流すかたちになります。この情報が誰からどのタイミングで来るかは気にしていないというか、動いているコンピューターは気にしていないですし、自分の出した情報が、どのコンピューターに受け取ってもらえるかを気にせずに情報を出していたりします。

とにかく情報が来ましたら、処理をして情報を出すみたいなことをやっています。それだけでも、まるで車両全体を制御している何かがいるように感じられるようになっていると思います。そうしないと、クルマは動かないですからね。不思議に感じられることがあるかと思いますけど、ある意味、非常に高度な自律分散型の制御を行っているとも言えます。

コンピューター制御における技術的な課題

飯山：普通に考えると、1つのコンピューターの中にすべてを詰め込んで、それが人間の大脳のような役割を持って、手足となるセンサーやアクチュエータ、モーターを統合制御してしまえばいいんじゃないかと思われると思います。実は、それは簡単ではなくて、技術的な理由や技術的ではない理由がそれぞれいくつかあります。

技術的な理由としては、各コンピューターに入っているソフトウェアの性質や信頼性、構造がみんな違うんですね。それを1つにまとめるのはそれほど簡単ではないです。極端な話、グラフィック系のソフトとモーター系のモーター制御をするソフトは一緒にできますか？　こう言うと、それはなかなか難しいと思います。

信頼性も違いますので、とくに信頼性の低いほうに引きずられてしまう傾向がありますので、これを1つのソフトウェアにしようとすると、低い信頼性のソフトの持つ要素を再設計し直さないといけないということになります。

コストの問題もあるかなと思います。コンピューターは性能が2倍になるとコストが2倍になるわけではなくて、一般的にはコンピューターの性能が上がるのに対して、指数関数的にコストが上がっていきます。

その場合には統合するメリットはかなり薄くなります。統合するとコンパクトカーやフラッグシップカーという車にも、同じコンピューターを載せることになりますので、なかなかそういうバリエーションが作りにくくなる。こういった事情があって統合化が進まないのが現状になります。

一方で、世界的な流れとしては機能を統合していく動きが進んでいます。クルマの進化を統合化の観点に表現すると、こんな感じになるのかなと思います。

究極的には、いくつかの高性能なコンピューターがほとんどの機能がそのコンピューターに集約されて、手足となるセンサー、アクチュエータを制御する姿です。これまでクラウド上でしか捌けなかった処理もクルマの中でエッジ処理されて、必要なものだけがクラウドにアップされる。

それで常にクラウドと連携しながら動作することが想定されます。今は、この図の中のちょうど真ん中あたりにいる感じです。また、クルマの中のネットワークも大きくする可能性があって、今はクルマ用に開発されたCANという通信規格が主流なんですけど、将来は世の中で一番普及しているイーサネットと呼ばれる通信規格が主流になって、アクチュエータやセンサーまで張り巡らされる世界が来るかもしれません。

そうなるとクルマは街、Cityの一部として溶け込んで、さらに重要な役割を担うことになるんじゃないかなと思います。

システム制御の複雑なパターン

飯山：次は少し話を変えて、クルマの複雑さについて少し紹介したいと思います。これはクルマのシステムのスペック、諸元と制御するソフトウェアの関係を模式的に表したものになります。

クルマを買う時のことを想像していただきたいんですけど、例えば、弊社の場合だとカローラやプリウスなどの車種からどれかを選びましょうと。それを選んだあとに、ガソリンエンジンなのか、ハイブリッドなのかという動力の種類を選んだり、ナビや安全装備が付いている、付いていないかを選んでいきます。

だいたいカタログを見ると、10種類ぐらいお客さまで選んでいただけるものがあります。実を言うと、私たちが開発をする上で、それ以外に選択しなければいけないものがたくさんあります。クルマを開発するにあたっては、最上流の仕様書として車両仕様が決められます。

この中にはクルマのカタログに載っているような車両諸元が書かれていたり、もう少し具体的な部品に対する要求が書かれています。「この部品を使いなさい」「こういうかたちです」などですね。

この仕様書に書かれているパラメータというか、そういう情報だけだとクルマは作れないです。この情報に、さらにいろいろな情報を加えて、最終的に一台一台のクルマの動作が一意に決まるようになります。

クルマのソフトの中には、このように動作を切り替えるスイッチのようなものがたくさんあります。スライド真ん中は一般的にバリエーションポイントという言い方で呼ばれています。それぞれのバリエーションポイントが、オンなのかオフなのかの3つぐらいの値をどれを取るのかが決められていたりします。

人間がその値を決めることもあれば、値が他の値によって自動的に決まることもあったりします。例えば、ここの図の中で一番左上にある動力という名前のバリエーションポイントで、例えばHV、EV、PHVという値を持っています。これがHVやPHVなら、その次のX1というパラメータは100になると決まったりします。

同様にX1という値が決まれば、X2という値も決まって、X2が決まればX4が決まるという感じで順々に値が決まっていき、最終的にクルマのソフトの動作が決まる感じになります。このバリエーションポイントは、およそ1つのクルマに決めるのにだいたい1万個あると推定しています。つまりこの1万ものパラメータを決めないとクルマのソフトウェアは作れないことになります。

これを今我々エンジニアが開発の中でこの手の情報を擦り合わせてクルマの開発をしていると。これがクルマ開発の大変な仕事の1つになっています。

（後半につづく）