Hondaが挑む、ハードとソフトの境界を担う次世代ソフトウェアプラットフォームの実現とは

アーカイブ動画

構成をシンプルにすることで、ソフトウェアの品質・開発スピードを高める

本田技研工業株式会社
電動事業開発本部BEV開発センター
ソフトウェアデファインドモビリティ開発統括部
電子プラットフォーム開発部 部長　久木 隆氏

最初に登壇した久木隆氏は、入社以来ECU（Electronic Control Unit）の開発を担当。主に制御系ECUの開発、内製ソフトウェアの開発に携わり、アメリカ駐在時にはボディ系、インフォテインメント系のECUも担当してきた開発責任者だ。「アメリカでの経験によりクルマ全体を知ることができた」と、久木氏は振り返る。

久木氏は、ものづくりのキーワードでもある「ソフトウェアデファインドでHondaはどのような世界を実現したいのか」について、次のように語った。

「車外と繋がり素早く進化することで、一人ひとりの夢を実現し、移動の喜びを提供していきたい」（久木氏）

具体的にはデータを中心に据え、ユーザー・モビリティ・社会など、関連するステークホルダーと繋がることで、モビリティを素早く進化させていくという。その実現に向けては、車両に搭載されたECUや各種センサー、アクチュエータなどを繋ぐシステム構造であるE＆Eアーキテクチャが必要不可欠となる。

久木氏は以下のスライドを示し、Hondaにおいて、E＆Eアーキテクチャが提唱・定義されるようになったのは、2010年頃だと説明。Hondaはその10年以上前の2000年頃から、すでにECUをCAN（Controller Area Network）で繋いでいた。

2010年代になるとECUの数が増えたため、Gatewayを導入し、CANの多チャンネル化を実現。さらに10年後の2020年になると、インフォテインメント系、パワートレイン系など、各種ドメインのECUを繋いだドメイン型のE＆Eアーキテクチャを構築する。

また、同時期にはOTA（Over The Air）の導入を開始し、サイバーセキュリティにも対応可能となっていた。一方で、課題もあった。

「ハイブリッドシステムの進化、ECUの増加などにより、システムが複雑化しました。ECUの構成はクルマによって異なるため、ネットワーク構成もそれぞれ対応する必要があります。そのままの状態では開発の手間が増えていく一方となるため、ネットワークの構成を統一することにしました」（久木氏）

このような考えから生まれたのが、現在のE＆Eアーキテクチャ「統合ドメインアーキテクチャ」だ。エンジンやブレーキなどはパワートレイン系として統合することで、ドメインをできるだけ少なくする構成となっている。

最新のE＆Eアーキテクチャは、サイバーセキュリティをさらに強化。国連のサイバーセキュリティ法規である「UN-R155／156」にも対応している。

久木氏は、最新のE＆Eアーキテクチャの概念図も示した。パワートレイン系、情報系など各種ECUドメインが統合されたネットワーク構成であること、ファイアウォール機能を有するCGWというGatewayを設けることで、外部とのやり取りのセキュリティを担保していることがわかる。

さらに久木氏は、現在取り組んでいる次世代のE＆Eアーキテクチャ「Central ECU」についても紹介した。Central ECUにアクセスすれば、車両の情報すべてにアクセスできる仕組みとなっている。

さらに車両ごとに異なるECUのタイプも関係なく、Central ECUを設けることで、統合型ドメインがよりシンプルになる構成だ。

「ソフトウェアの制御では電源管理も重要になってくるため、構成をできるだけシンプルに統一することで、電源管理も楽になるでしょう」（久木氏）

このように統一されたCentral ECUに送るソフトウェアは、OTAで接続されたクラウドサーバー上において、CI/CDの開発環境で開発される。

また、開発者がどこにいても業務をスムーズに行うことができるように、コンテナ技術も採用している。最新のソフトウェアをスピーディかつ、継続的に車両にアップデートしていく。まさに、エコシステムの実現をHondaは目指しているのである。

最後に久木氏は、組織についても次のように触れ、セッションを締めた。

「これまではクルマの内と外とでは開発組織も、開発するタイミングも異なっていました。そのため、本番環境に実装した際に不具合が生じることが少なくありませんでした。そこで今後は両開発を1つの組織下で行うことで、開発のさらなるスピードアップを実現していきたいと考えています」（久木氏）

バーチャル空間上で自動検証を行う次世代開発環境構築への挑戦 

本田技研工業株式会社
電動事業開発本部BEV開発センター
ソフトウェアデファインドモビリティ開発統括部
電子プラットフォーム開発部
電子プラットフォーム開発課 課長　中村 徹氏

続いて登壇したのは、久木氏と同じく、入社以来ECU開発を担当してきた中村徹氏だ。入社後17年間エンジン制御を担当し、その後はパワートレイン／シャシー系で、次世代E＆Eアーキテクチャの開発にも携わってきた。

Hondaでは、OTAをSDM（ソフトウェアデファインドモビリティ）における重要な技術基盤と捉えており、各種フェーズで価値を提供している。

具体的には、開発フェーズではテスト車両のソフトウェア管理の効率化、生産フェーズでは部品在庫の削減、販売フェーズではそれぞれのユーザーニーズにマッチしたオプションの選択を提供。販売後は各種機能のアップデートである。

Hondaでは、2018年にディスプレイオーディオのソフトウェアアップデートを皮切りに、2020年には自動制御ユニットのファームウェアアップデートでOTAを利用してきた。ただし、これまでは特定の機能に限定していた。

しかし最新のOTA利用では、パワートレイン、ディスプレイオーディオなど、主要な機能のアップデートで活用している。今後の展望について中村氏は、「さらなる機能拡張を目指しています」と述べた。

中村氏は最新のOTAシステムも紹介した。アップデートが自動もしくは時間設定、手動などで行える点は、スマートフォンと同じだと言えるだろう。一方で、車両は安全安心が絶対条件である。

そのため、トラブルが起きないように細心の配慮を施している。例えば、ソフトウェアをアップデートしたことで走行に支障が起きないように、走行中はあくまでダウンロードを行うのみで、インストールはクルマが走っていない電源がオフの状態で行っている。

また、クルマにおけるOTAの場合は、車載システムだけでもかなりの数があることに加え、ソフトウェアアップデートで使う各種サーバーとの連携など、同じく数多くのITシステムも加わってくる。そのためステークホルダーも含め、大規模なシステムとなる。

「クルマならではの車両システム、ITシステムも大規模であることから、OTAのシステムを開発する際にはトラブルが発生しやすくなる傾向にあります。そのようなことを当然のごとく見据えながら、開発を行ってきました」（中村氏）

安全に深く関わる車両制御系のシステム開発は、これまでの実績もあるウォーターフォール型で行っている。一方、ITシステムに関してはアジャイル型を採用している。

それでも想定外の課題が数多く発生してしまうことがあるという。中村氏はOTAシステムがフリーズしてしまった事例を挙げ、次のように振り返った。

「通信不良への考慮はもちろん、設計段階で行っていました。しかし自動車OTAのような大規模システムでは、実現場でのクラウドの動作や通信状況での変動要素が大きく、設計段階で把握、対応することは困難だということがわかりました」（中村氏）

さらに、ウォーターフォール開発で行うべきスコープはどこか。アジャイル開発で柔軟に品質を高めていくスコープはどこか。その見極めが重要であると、中村氏は強調する。

例えば、システムの基本構造・安全はウォーターフォール開発、ヒューマンインターフェースやユーザビリティ、ネットワーク信頼性などはアジャイル開発で行うといった振り分けである。

次に中村氏は、現在取り組んでいるクルマの品質を維持しながら、スピーディにソフトウェア開発を実現するための次世代開発環境について述べた。

「リアルな車両から得たあらゆるデータをもとに、バーチャル空間上に車両をシミュレーションできる環境を構築します。その環境下で、ソフトウェアの開発から各種システムの結合テストなどを自動で行うことを目指しています」（中村氏）

すでに環境が構築されている事例も示した。OTAシステムである。車両、クラウドシステムがバーチャル環境ですでに再現されている。

これまでの失敗事例、リアルワールドで不具合を出す要因となった不安定な通信状況をシミュレーションし、そのような状況下で自動的にテストを行うことも可能になっている。

E＆Eアーキテクチャの検証においても同じく、自動でさまざまな統合テストが行えるような環境構築を目指しているという。

中村氏は次のように述べ、セッションを締めた。

「ソフトウェアデファインドの実現に向けては、制御ユニット・電源システム・通信ネットワーク・クラウドシステムなど、複雑なシステムのそれぞれのレイヤーを段階的に検証していくことで、問題の早期発見や対応の早期化を目指します。大規模ソフトウェア開発の品質を維持しながら、スピーディに行える環境を構築していきます」（中村氏）

Hondaイズムで実現を目指すソフトウェアプラットフォームの開発舞台裏

本田技研工業株式会社
電動事業開発本部BEV開発センター
ソフトウェアデファインドモビリティ開発統括部
電子プラットフォーム開発部
制御ソフトウェアプラットフォーム開発課 課長　井手 博仁氏

続いて登壇したのは、久木氏・中村氏と同じくエンジン用ECUの内製開発に携わってきたキャリアを持つ井手博仁氏。現在は内製ソフトウェアプラットフォーム開発を推進する組織の立ち上げとリーダーとしての役割を担う。

まず井手氏は、SDM用ソフトウェアプラットフォームについて解説した。二輪・四輪自動車だけでなく、船舶や飛行機など、Hondaは数多くのモビリティを手がけている。これらのモビリティを繋ぐことで、シナジー効果を生み出そうとしているのだ。

従来のアプローチでは、ハードウェアだけでシナジー効果を生み出すことは、難しかった。それがソフトウェアデファインド、ソフトウェアによる開発が台頭してきたことで、シナジー効果を出せるようになってきた。

そのための基盤となるのが、SDM用ソフトウェアプラットフォームだ。なお本セッションにおいては、クルマのスコープに限っての内容となる。

ソフトウェアプラットフォームとは、車両・クラウド・開発環境がシームレスに繋がるプラットフォームであり、その中の車両部分が「Vehicle-OS」と呼ばれる。

Vehicle-OSを搭載することで、PCやスマートフォンのように、各種アプリケーションがOTAによってアップデートされていくのである。

Vehicle-OSを搭載すれば、ハードウェアが異なる車種であっても、アプリケーションは同じものが流用できる。つまり、ハード・ソフトウェアが分離されているため、両者のスケーラビリティが確保できると井手氏は語る。さらに、次のように補足した。

「Vehicle-OSは、基本的にはPCに搭載されているOSと同じ構造や役割だと思ってもらって構いません。どちらもOSを仲介することで、アプリケーションがインストールされていくからです」（井手氏）

さらに井手氏は、これまでのデバイスの進化を挙げ、「歴史は繰り返す」と指摘。特定の機能のみを有していたデバイスが“汎化”することで、新たな価値を創出してきたからだ。

井手氏は「クルマもまさにそのようになる。それがSDVであり、その基盤となるのがVehicle-OSである」と力強く語り、「このような爆速進化を世界で最初に実現したい。そのために内製化を推進しています」と続けた。

これまでのソフトウェア開発では、車種により異なるOSが搭載されていたが、Vehicle-OSが実現すれば、それらが統一されることになる。ソフトウェア開発スピードが爆速化することは明白だ。

ソフトウェアデファインドによる開発では、以前のハードウェア主体の開発とは根本的に異なると、井手氏は言う。

例えば、ハードウェア主体の開発では、そのときに自動車メーカーが考える最高品質の製品を提供すればよかった。しかし、ソフトウェアデファインド的な開発では、個々の顧客が求めるニーズに合致したクルマを提供する必要があるからだ。

「我々はお客さんが望むと思ってうどんを提供したら、実はお客さんはカレーが食べたかった。そのようなイメージです」（井手氏）

そしてそれぞれのスコープで根本的に見直すことが必要であり、開発体制においては中村氏も触れたように、アジャイル開発で行った方が良いと述べた。

一方で、一般的にハードウェア的な開発ではゴールが明確に定まっているため、ウォーターフォール開発も有効である。つまり、両者をハイブリッドで同時並行に進める必要があり、そのことが開発の難しさにもなっているという。

井手氏は改めてVehicle-OSの概念をより詳しくしたスライドを示した。上段がユーザーとの接点が近くなるアプリケーションレイヤーであり、アプリケーションはSDM、ハイパフォーマンス、ハイコンテクストとスコープ分けされている。

さらに、それぞれのアプリケーションやソフトウェア開発に必要な技術スタックも明示し、幅広い領域の知識や技術が必要であることを説明した。

「中でも中央のハイパフォーマンスアプリケーションの開発では、両方を兼ね備えるような技術が必要です」（井手氏）

このような多種多様な技術や知識が、ソフトウェアプラットフォームの開発では必要となることから、井手氏は人材育成ならびに、スピーディに成長するための環境やプロセスの整備について社内でヒアリング調査を行った。

組織立ち上げから数年が経過した現在、開発メンバーにどのような難しさやチャレンジがあったのかを聞くと、技術的な課題はもちろんだが、それよりも開発体制や人材育成・教育の方がボリュームゾーンであることがわかった。

また、井手氏はソフトウェアをただ時間をかけて開発するのではなく、とにかく“試す”開発を繰り返すことの重要さを語った。さらに開発エンジニアが将来的なニーズを考え続けることの大切さとともに、その難しさも吐露した。

「でも実際は、このような思考のシフトはとても難しいと捉えています。しかし難しいからこそエンジニアが考え、仮説検証することのできるプラットフォームが必要であると考えています」（井手氏）

このような苦労も含め、ソフトウェアプラットフォーム開発の取り組みを総括すると「Hondaイズムになる」という。ソフトウェア開発にはさまざまな領域や工程がある。だからこそソフトウェア開発は面白いと、セッションをまとめた。

「Hondaは創業以来、世界初や世界一を目指してチャレンジを繰り返してきました。そのような取り組みの中でHondaイズムが洗練され、残ってきたものでもあると考えれば、ソフトウェアプラットフォームの開発にもまさに、Hondaイズムがフィットするのではないか。そのように感じています」（井手氏）

【Q＆A】参加者からの質問に登壇者が回答

セッション後は、イベントを聴講した参加者からの質問に登壇者が回答した。いくつか抜粋して紹介する。

Q．システムの高度・複雑化による燃費への影響は？

久木：1つのECUが使う電力は、1Aレベルです。そのため、ECUにより大きなエネルギーを得られるようになります。特にEVはブレーキ時にもエネルギーを吸収するので、増えることによるメリットの方が大きく、燃費は年々上がる傾向にあります。

Q．ソフトウェアのアップデートはどのくらい時間がかかるのか？

中村：大規模なものでなければ10分程度で終わります。ディスプレイオーディオや自動運転システムに関するプログラムなどになると、1〜2時間かかるケースもあります。

Q．Central ECUでは、どのように情報のセキュリティを担保しているのか？

久木：Central ECUはすべての制御を行ってデータを集約しているため、外部から攻撃されるリスクは高まります。そこで、物理的には1つのCentral ECUですが、内部のソフトウェア的な構造においてはECUごとにファイアウォールを設け、何重にも重ねることで攻撃されにくいように対策しています。

Q．SDVを推進するにはハイレベルなSoCを必要とするためコストがかかるが、社内でどのように理解を得ていったのか？

久木：前任部長の取り組みになりますが、コストとのバランスも含め、SDVが実現する世界観をイメージできる動画を専門業者に作成してもらいました。その動画を戦略会議で経営層に見せてアピールしながら、理解を得ていったと聞いています。

Q．Vehicle-OSは車両システム全体を対象とした抽象概念との理解で合っているか？

井手：合っていると思います。Vehicle-OSという大枠の中にAUTOSARやPOSIX、Linuxといったものが存在しているからです。イメージとしてはデバイスドライバー、フレームワークなど、さまざまな制御をまとめて行っているWindowsと同じく、クルマ版のWindowsだと理解してもらえればと思います。

Q．プラットフォーム開発環境への移行に際し、メンバーへの意識改革や醸成はどのように行ったのか。

井手：とても難しいと感じています。対話を通じて地道に行っていますが、まだまだ課題はあります。実装されたクルマが世の中に出たタイミングで本当の意味で根付いていくのではないかと考えています。

Q．バーチャル環境テストとはHILSを用いたテストとの理解で合っているか？

中村：違います。バーチャル環境テストとは、クラウド上でクルマの振る舞いを再現し、ソフトウェアを開発していく環境です。そのため、HILSや単体のベンチテストでは再現できないADASがセンシングしている環境情報などを再現し、評価を行っていきます。

バーチャル環境上でソフトウェアの評価をした後、実際にリアルの大規模なアーキテクチャのベンチテストをデプロイして行う。これらが自動で行えるようなテスト環境になります。

Q．バーチャル環境下による自動検証が進んでも、リアルワールドで発生しうるあらゆるユースケースを網羅するのは難しいのではないか？

中村：たしかに、すべてのユースケースを網羅することはできないというのが正直なところです。どのような制約があるのか、守るべき応答性は何なのか、何を達成すべきなのかといった要件を一つひとつ明確にすること。その上で、設計と評価を繰り返していくことが重要だと考えています。

Q．PCではプログラム更新途中に電源遮断や通信が途絶すると、システムが破損する可能性がある。クルマではどうか？

中村：クルマの場合は特に重要なユニットは2系統で担保するなど、冗長構成になっています。そのため、電源遮断により既存のシステムが破壊されたとしても、クルマが動かなくなるといったトラブルが起きないシステムとなっています。

Q．Hondaがソフトウェアデファインドにシフトしていくことによる反発はなかったのか？

久木：ありました。例えば、ソフトウェア開発ではゼロが難しいバグの発生や、リリース後にアップデートで改善すればいいだろうといった考えを、ハードウェアの品質系部門は受け入れられなかったからです。実際、ソフトウェアの不具合により、量産時期が遅れるケースもありました。

しかし、ソフトウェアデファインドを推進すれば、先進的な価値をお客さまにタイムリーにお届けすることが可能になります。だからこそ、やらなければならない。そのためまさに今、新しいルールの導入なども考慮しながら、普及活動をしているところです。

本田技研工業株式会社
https://www.honda.co.jp/

本田技研工業のキャリア採用情報
https://www.honda-jobs.com/