HondaのAndroid Automotive OSを用いた空間体験レベルアップへの挑戦──車載ダンジョンの攻略体験記

アーカイブ動画

Honda初となる「IVI」の内製開発に至った理由とは

本田技研工業株式会社
電動事業開発本部BEV開発センターソフトウェアデファインドモビリティ開発統括部
情報通信システム開発部　部長　清家 小太郎氏

最初に登壇したのは、カーナビメーカーでIVIのアーキテクチャを担当した後、2018年にHondaに入社。現在はインフォテイメント領域の責任者を務める清家小太郎氏だ。

2023年より米国で先行販売している11代目の新型アコードには、AAOSが実装されたスマホライクな車載用システムが搭載されている。高性能音声認識エンジンや、Androidスマホと同等の地図アプリ、音楽再生サービスを中心としたアプリストアなど、コネクテッドでパーソナライズされた車内の空間体験を実現している。

Hondaにおける従来のソフトウェア開発体制は、複数のTier1に仕様書を送り、開発を依頼するスタイルだった。今回のテーマであるIVIにおいても同様だ。ところがIVI機能の複雑化により、ソフトウェアの開発規模が増大し、開発費も増えていった。

また、OTA（Over The Air）技術などの登場により、柔軟かつ迅速な機能や仕様変更を求められるようになったが、従来の開発体制ではどうしても時間がかかってしまうという課題も生じていた。

このような課題はソフトウェア領域に限らず、ハードウェアなど他の領域でも同じだろうと清家氏は語る。そして、一般論と前置きしつつ対策案を紹介。「どれか1つの対策を選択するのではなく、組み合わせて対応することがよい」といった見解を述べた。

実際、Honda初となるIVIの内製開発化、オープン化を選択。オープン化に際しては、AAOSの採用も決まる。

「しかし、AAOSを採用すれば課題が簡単に解決するものではありませんでした」（清家氏）

清家氏はこのように語り、どのような苦労があったのか。続いて登壇するメンバーにバトンを渡した。

リーダーを筆頭に、チームワークで突然の大規模仕様変更をクリア

本田技研工業株式会社
電動事業開発本部BEV開発センターソフトウェアデファインドモビリティ開発統括部
情報通信システム開発部 IVIプラットフォーム開発課 武川 哲也氏

続いては、IVI内製ソフトウェア組織が立ち上がったタイミングでHondaに入社し、IVI内製ソフトウェアの開発の統括責任者を務める武川哲也氏が登壇した。

IVIの内製開発を進めるために、開発チームは当初いくつかの目標を掲げた。内製化ではあるが、従来通りTier1などのパートナー企業に協力してもらう。

ただし、あくまでHondaが主導し、仕様においては従来のHondaのIVIに沿って進める。期限は数年後と設定した。さらに目的達成に向け最適なメンバーを集め、開発内容の調査や試作開発なども行っていった。

武川氏はAndroidを構成するソフトウェアのフレームワークやスタックを紹介するとともに、自分たちが担当する領域も示した。具体的には以下スライドの赤点線、HAL（Hardware Abstraction Layer）の上のレイヤーであり、下のレイヤーとハードウェア領域においては、これまで通りTier1に担当してもらうこととした。

※本セッションでは、プロジェクトを達成するまでのストーリーをロールプレイングゲーム（以下、RPG）仕立てで紹介しており、それに準じたデザインや言葉が度々登場する。

プロジェクトがスタートしてから数年が経過したある日、「当初のHonda仕様ではなく、スマホライクなIVIに変更する」という大規模な仕様変更が言い渡される。ただし、Hondaが主導することと期間は変わらない。

武川氏はその時の心境を次のようにRPG風に吐露した。本セッションはハイブリッド開催であったため会場からは笑い声、イベント視聴者からは笑いスタンプが多く飛び交った。

「事前に予定していたダンジョンに突入していたら急にバグが発生し、ダンジョン内の地図は変わってしまっているし、目の前には強いモンスターが次々と出てくる。仕様変更を伝えた王様もスライドのように、青色に見えましたね」（武川氏）

RPG風ではなく、一般的に表現すればプロジェクトのならびにメンバーに激震が走ったと言えるだろう。一方で、チームリーダーは迅速に対応する。新しい仕様の内容を理解すること。既存仕様との変更点を明確にすること。そして、これらの取り組みを2カ月で終わらせることをメンバーに告げた。

当初、2カ月での対応は無理難題だと思ったと、武川氏は正直な胸の内を明かす。というのもIVIは幅広い機能があるからだ。一方で、アーキテクトグループにはAndroidに詳しい人たちが集まり、設計を担当しているチームがあった。

この精鋭メンバーを集め、新しい仕様の内容を咀嚼し、ドキュメントとして各開発グループが同じく内容を理解する際の手助けとした。武川氏は成果を次のように振り返る。

「ソフトウェア開発では、ある考えに則ってつくるようなことがあります。それを文章化したイメージです。同時に、理解が難しい箇所はお互いが相談し合える体制も構築しました」（武川氏）

このような取り組みの結果、仕様変更後の状況が見えてきた。当初行った開発分担は変わらない。一方でスマホライクなIVIというのは、ほぼスマートフォンである。

その結果、従来のHonda仕様に合わせて変更していた箇所を、再び変更する必要性があるという結論に行き着く。

武川氏たちは取り組みを実行すべく、まずは変更点の調査を行うことにした。しかし、与えられた期間の2カ月では調査が終わらないことも見えてきた。すると再びリーダーが動く。日程の緩和を開発責任者に交渉したのである。

スケジュールの変更はプロジェクトが大きくなればなるほど、容易ではない。特に自動車開発においては、ステークホルダーが多いため顕著である。本当に可能なのかどうか疑問に思っていたが、そのような不安に反してリーダーは日程の延期を勝ち取る。

しかし、課題は期限だけではなかった。既存のHonda仕様では、スマホライクなIVIを実現することが難しかったのだ。そこで、リーダーが再び動く。Hondaの仕様を変更しようと、再び責任者にかけ合ったのである。

このようなリーダーの迅速な対応や動きが奏功し、結果としてダンジョンから抜け出すことができた。一方で現場が大変だったことは明白であり、結局のところは現場メンバーの地道で泥臭い努力や協力が大きかったと、武川氏はプロジェクトを振り返った。

武川氏たちは、今回のプロジェクトをきっかけに、複雑化していた従来のHonda仕様をスリム化する動きも見せた。今後の開発において、工数削減に寄与するというさらなる成果を得たのである。

武川氏は今回のプロジェクトを改めて振り返り、次のように述べセッションを締めた。

「Hondaのメンバーに限らず、プロジェクトに携わるメンバー全員がいま何を行っているかを理解して、タッグを組んで積極的に前に進めよう。そのような気持ちやチームワークが、今回のプロジェクトを成功に導いた要因だと思っています」（武川氏）

サウンド設計で生じた様々なトラブルと解決までの苦労と道のり

本田技研工業株式会社
電動事業開発本部BEV開発センターソフトウェアデファインドモビリティ開発統括部
情報通信システム開発部 IVIプラットフォーム開発課　日下部 雄一氏

続いては、長年カーナビのIVI開発に携わってきた日下部雄一氏が登壇した。日下部氏がHondaに入社したのは2020年。現在はIVIソフトウェア内製化のリードアーキテクトならびにOSPO（Open Source Program Office）を担当する。

OSSコンプライアンスプログラムの国際標準である、OpenChain ISO/IEC 5230の自己認証取得にも携わっており、OpenChainの国際会議で配布されたロゴがイラストされたTシャツを着用して、サウンド設計に関する内容を紹介した。

まず紹介したのは、AAOSのAudioスタックストラクチャーだ。スライド左側はAndroidと同じフレームワークであり、音声再生の処理中枢であるAudioFlingerが中心に位置していることが分かる。

ここに、AAOSの場合は右側のコンポーネント。車載向けならではのCarAudioManagerが加わる。車載ならではの外付けAMP対応など、拡張機能に対応するためだ。

サウンドではラジオ音声、カーナビの案内など、複数のオーディオ機器から上がってくるサウンドをどの順番で、あるいは同時に流すかを決めることが重要であり、設計業務の約6割を占める。

ただし、AAOSではすでに同仕組みや概念が備わっている。AudioFocusという機能だ。アプリケーション側はこのAudioFocusをAPI経由でリクエストすることで、まさにどの音を先に出すのか、無数の音声マトリックスに対応している。

しかし例外があり、すべてのアプリケーションが同ルールに準ずるわけではなく、アプリケーションの音が出ないといった問題が発生することもある。

「僕がプラットフォーム側だったこともあり、当初はアプリ側に問題があると思っていました。ところが、AudioFocusに依存して設計してはならない。そのことがAAOSのドキュメントに書いてあるという指摘を受けたのです」（日下部氏）

実際にドキュメントを調べてみると、指摘通りであった。そのため自分たちではコントロールできない領域も検討する必要があり、非常に苦労していると述べた。

一部のAudioアプリでは、非常に厳しい非機能要件（性能）があるという。マイクの音声を何ミリ秒以内にアプリケーションに届ける、アプリケーションの音声を同じく何ミリ秒以内にスピーカーから出すといった要求だ。

このような要求に対しては、各要求を分析した後、ハードウェアも含めたシステム設計を実施することで対応していった。

そのような取り組みの中、低レイテンシーを実現するために利用したのがAAOSで提供しているAAudioという機能だ。しかし、こちらの取り組みでも苦労が生じた。Nativeで実装されているため、実際に使ってみると不具合が20件ほど発生したからだ。

「これまで見たことのない不具合も出ていましたから、他のメーカーはAAudioを使っていないのでは、と思うぐらいでしたね」（日下部氏）

日下部氏たちが打開策に向けて活用したのは、Hondaでよく行われる課題解決フレームワークである。問題を紙に印刷して壁に貼りつけ、見える化することで解決していく。

さらにはAndroidに詳しい有識者を集め、解決策を探っていった。その結果、最終的に不具合を2件にまで軽減。AAudioのコードを修正することで解決に至る。

日下部氏は、AAudioなどのNative機能を使用する際には、「ドキュメントをしっかりと読むことが重要だ」と視聴者にアドバイスを送る。例えば、状態推移ですぐにストップをかけたい場合、AAudioのAPIを叩くだけでは、すぐに止まらないからだ。

Javaとは異なり、ハードウェアを意識したつくりとなっているため、ソフトウェアの設計においても、ハードウェアをある程度意識した設計が必要になってくる。その点でとても苦労したと、日下部氏は振り返ってコメントした。

性能に関しては他にも考慮すべき問題があった。こちらもハードウェアであるSoCのパフォーマンスを適切に引き出す必要があったからだ。

日下部氏たちが使用しているSoCでは、異なる性能のCPUが3つ入っているモバイル向け、省電力タイプがベースとなっている。そのためCPUが本来持つパフォーマンスを発揮するには、意図的に高負荷の状態を作り出す必要があったからである。

そこでCPUガバナーの設定を変更すると同時に、高負荷の状態でも音切れがしないように、ショックプルーフの見直しなども行った。

AAOSではさまざまな機能が後から追加され、その度にバージョンが変更される。そのため、より高性能にするためにカスタマイズをし過ぎてしまうと、そのバージョン変更に追従できなくなる。

そのため、あえて自分たちがゴリゴリ手を動かすことはしていないという。「結果として、時代進化に追従していくことになると考えている」。日下部氏はこのように述べ、セッションを締めた。

「難問を愛そう」の精神で検証を繰り返し、自車位置の精度向上を実現

本田技研工業株式会社
電動事業開発本部BEV開発センターソフトウェアデファインドモビリティ開発統括部
情報通信システム開発部 IVIプラットフォーム開発課　課長　坂 輔氏

最後の登壇者は、オーディオやカーナビの開発業務に長く携わり、現在はIVIプラットフォーム開発課で課長を務める坂輔氏である。坂氏の講演テーマは、自車位置精度向上への挑戦。まずは、Hondaのカーナビ開発の歴史を振り返った。

Hondaは1981年に、世界で初めてカーナビの量産化を果たす。以降40年以上に渡ってカーナビを世に送り出し続けているが、ナビゲーションシステムやシステム構成、開発体制などは大きく変化してきた。

例えば2000年代当初は、冒頭で紹介したようにHondaが作成した仕様書を元に、Tier1と共に開発するスタイルが一般的であった。2016年頃からは、AAOSやスマートフォンベースのナビアプリが登場したことで、関連アプリの開発も担うようになった。

そして近年では、ハードウェアとソフトウェアの分離開発が進むとともに、北米で発売されたアコードでは、Google Mapsが搭載されている。

車が自車の位置を推定する仕組みは、スマートフォンの位置推定と同じく衛星を使ったGNSS（Global Navigation Satellite System／全地球航法衛星システム）がまずある。ただ同方式だけでは、地下や施設内などの電波が受信できない状況では機能しない。

そこで、車両自体に搭載された各種センサーの情報により、位置を推定する「自律航法」も活用する。ただし、自律航法もセンサーの誤差蓄積などによって推定位置にズレが生じていくため、この両方をハイブリッド的に活用して自車位置を推定している。

だが、このハイブリッド方式でも完璧に自車位置を推定することは難しいという。坂氏は、次のように語った。

「トンネル内などに車が入ると大体の位置情報は把握できますが、正確な位置はどうしてもズレてきてしまいます。そこで地図の道路情報を活用し、そのズレを補正していくマップマッチングという方式を最終的には採用しています」（坂氏）

マップマッチング方式では、以前であれば自車位置を測定するためのナビゲーションアプリやセンサーの開発などを一緒に行っており、バランスが取れていたと坂氏は振り返る。

一方、マップマッチング方式を活用した自車位置推定開発では、Googleのメンバーはもちろん、他の開発メンバーが増えることで、議論の回数や場が増えていった。また、Google Mapsの挙動に合わせて、自動車側がチューニングする必要があった。

そして、このようなチューニングはシミュレーションによる解析だけでは不十分だと、坂氏は、RPG風の言葉で気持ちを表現した。

「実際の運転シーンでは、道路の状況は周りの温度などさまざまな要素があるため、まったく同じ状況というのはありません。最終的にはフィールドに何度も出て経験し、検証する必要があります。言ってみれば次々と出てくるモンスターを倒していくようなものです」（坂氏）

坂氏は課題解決への取り組みを、実例と合わせてゲーム風に紹介していった。まずは初期、レベル1である。当初は減速時の算出方法が正しくなく、スライドの左側で示したように、実際の位置とナビが示した推定位置が大きくズレていることが分かる。

レベル20では、レベル1と比べるとズレはだいぶ減ったが、方位計算が正しくなかったことで、車の向きにズレが生じていた。レベル40になると、かなり正確に推定できるようにはなったが、道路ではない場所を走行しているとの事象が発生。その後、GNSSの精度が低いことが原因だと判明し、改善した。

GNSSからの電波は、ビルの壁や海面による反射といった電波、マルチパスもあるため、そのような電波を拾ってしまうことが誤差の原因になることが多い。レベル50として挙げられたレインボーブリッジは、まさにそのような難敵であった。

海面からの反射波に加え、下層部の道路はレインボーブリッジにより正確な電場を取得することが難しいからだ。実際、海の上を車が走行するとこの事象が発生する。だが、精度の悪いGNSS情報は採用しないようにチューニングすることで、見事クリアを果たす。

周囲をコンクリートに囲われ、かつ自動車が垂直方向ではほぼ同じ位置をぐるぐるまわっている立体駐車場も難敵だと坂氏。こちらもGNSSの採用条件を見直し、自律航法の計算精度を改善することで、見事クリアしていった。

そしていよいよゲームの最終シーン、ラスボスはシカゴである。多くの高層ビルやテレビ局が多く集まっているエリアのため、その他の電波も飛び交っている街だからだ。

加えて道路が碁盤目状に整備されており、どの通りを走っているのか判断することも難しい。さらには碁盤目状の道路は地上だけでなく、地下にも張り巡っているため、まさにラスボスに相応しいエリアと言えるだろう。

しかし坂氏たちのチームはこれまで通り、課題をロジカルに分析・対策し、見事、ラスボスも乗り越える。

しかし、ゲーム（課題解決）はここで終わらない。裏ボスがいたのだ。大橋ジャンクションである。1周約400ｍのループ状の道路4周からなる構造で、高低差は約70ｍ。立体駐車場をより難しくした場所と言えるだろう。

世界でも稀に見る構造物であり、「建てるときにナビ屋に相談してほしかった（苦笑）」と坂氏はコメント。視聴者からの笑いを誘った。

しかし裏ボスも、ロジカルに対応することで解決。見事、ゲームクリアとなる。坂氏は以下のスライドを掲げて次のように語り、セッションを締めた。

「定めた品質基準をクリアするために、みんなで考え抜いて、公道で検証を行う。そこでの事象を元に解析・対策を行い、改めて効果を確認する。今回は100回ほどこのサイクルを繰り返しましたが、クリアした結果としてノウハウが蓄積されました。Hondaが掲げている難問を愛そうというのは、こういうことなのだと思います」（坂氏）

パネルディスカッション 「ソフトウェアエンジニアの曲者冒険記」

セッション後は坂氏がファシリテーターを務め、登壇メンバーによるパネルディスカッションが行われた。以下、要約を紹介する。

■内製化チームについて

坂：まずは、内製化チームが立ち上がった頃の状況についてお聞かせください。

武川：私は立ち上がったタイミングでジョインしましたが、私を入れて4名しかいない状況でした。オフィスも小さく、プリンターもなく、パソコンのスペックも低い。この状態で業務ができるのかといった状態からのスタートでしたね。

坂：ターニングポイントは何だったのでしょう？

清家：おそらくメンバーが増えていったことが大きいと思います。特に、自動車関連のエンジニアだけでなく、テレビや携帯電話を手がけていた人たちが入社してくれたのは、大きかった。CI環境の整備など次第に組織がつくられていった印象です。

日下部：僕が入ったのはアコード向けの量産ハードウェアが出てきたタイミングでした。ただその頃はカーナビの起動・終了といった動作もまともではない状態でした。

結果として初回リリースにはしっかりと動作するようになったのですが、一方でバッテリーが上がるような設定にしてしまった失敗もありました。カーナビの設計は大変だと実感した瞬間でもありました。

■OSSについて

坂：OSSの取り組みについて聞かせてください。

日下部：現在、600ほどのOSSを使っています。ただ当初は利用において明確なルールがありませんでした。そこでOpenChainの内容などを参考にしながら、OSS利用のプロセスを作成していきました。

坂：OSSをたくさん使うのは、セキュリティも含めて難しくないですか？

武川：セキュリティは課題の一つです。ただ、IVIのような大規模ソフトウェアを組み上げる際に、OSSの利用なしには考えられないという実情があります。そのため、OSSを使う際にはセキュリティ担保のためのルールを設け、そのルールに則ってOSSを使うという運用をしています。また、自動車会社のOSS活動についてですが、最近では、各社がIVIの開発により深くかかわるようになった結果、OSSのコミュニティ活動において自動車会社の名前が多く見られるようになってきました。HondaとしてもOSSを大切にしていて、積極的に参加・活用していく考えです。もちろん活用だけでなく還元や貢献も考えています。実際、Open Source Summit Japan 2023ではプラチナスポンサーとなりました。

■Hondaに入社してみて

坂：日下部さんはHondaに入社前、Tier1でご活躍されていました。当時の状況や立場と現在を比べていかがですか。

日下部：前職でもカーナビプラットフォームチームのPLをやっていたので、仕事内容は現在とそれほど変わりません。一方で、OEMならではのやりがいを感じることもあります。

例えば、音声マトリックスであれば、自分たちでお客様視点に立ち、仕様を考えることができる。そして、その仕様を設計にまで自分たちの手で落とし込めるのは、OEMならではだと感じています。

今でも印象に残っているエピソードがあるので紹介します。1つ目は、どうにも解決できない問題があった際に、「人を介入して解決するのであれば、費用のことは後から考えればよいから、とにかくすぐ動きなさい」と、言われたことです。

2つ目も今のエピソードに近いですが、セキュリティ対策であるツールを使う必要がありました。予算を申請すると、「アカウントの数が申請したもので足りるのか」と、逆に心配されてしまって(笑)。フットワークの軽さは、やはりOEMならではだと改めて思いましたね。

もう1つは入社して2カ月ほどした頃に、たまたま清家さんとオフィスで会ったので、抱えていた課題を立ち話で伝えたんですね。するとその後、清家さんからDMが来て、ソースコードレビューならびに具体的な解決策を教えてくれました。「ソフトウェアがしっかりと分かる人が上司にいるんだ」と感じたことを思い出します。

Hondaには「120％の良品を目指せ」との言葉があります。人がやる以上ミスは起こるけど、120％を目指して取り組んでいれば、ミスしてもお客様には100％のものが届くという考えです。ソフトウェアのプロフェッショナルとして、エンジニア魂のこもったものを今後も開発していきたいと思います。

武川：近年は様々な業界から新しいメンバーが加わっている状況なので、いわゆるHondaの文化のようなものは次第に薄れて、雑多な文化になっている印象を持っています。

当然、摩擦や軋轢が生じることもありますが、ボトムアップという文化がHondaにはあり、比較的自由で、自分たちで文化をつくればよいという環境です。そのため、上から押し付けられるようなこともありません。

坂：Hondaには、人間尊重という企業理念が根付いています。そのため外から来た人を否定することもしないし、その人の提案が正しく楽しそうであれば、僕らが従う。そのような文化がHondaという会社にはあると感じています。

【Q＆A】参加者からの質問に対しても後日に登壇者が回答

Q．要求仕様に対してソフトウェア側で対応するか、ハードウェアや低レベルのコードで対応するかの切り分けは開発のどのタイミングでおこないましたか？

HWアシストを最大限活用したSW設計を行う基本方針を持っており、その方針に従い、要求仕様が出て来たタイミングで機能配置を検討しています。

Q．AAOS自体による苦労が多いように思います。それでもAAOSを利用するメリットはエンジニアの多さやインフォメーションの多さでしょうか？

ベース環境が無い状況において、AAOSがサポートしている機能をスタート地点にする事は開発工数削減に大きく寄与しており、今回のプロジェクトが上手く行った要因の一つになります。

Q．開発プロセスはアジャイルを利用していますか？

レイヤーにより使い分けており、ウォーターフォールとアジャイル両方を使用しています。

Q．ソフトウェアの標準化のために、ハードウェア側に要求(CRF)を出すこともあるのでしょうか？

ソフトウェアの開発に大きく影響する部品(例えばSoCやメモリ等)については、HWに対する要求を出して、一緒に検討しています。

Q．いかに仕様に優先度をつけ、必要なモノのみをどのように絞り込んだのか知りたいです。

お客様の操作性とAAOSのカスタマイズの規模を軸にして、社内議論を重ねて仕様調整しました。

Q．サウンド系だとCPU負荷による音飛びとかも発生したかと思います。CPU負荷100％でも音飛びしないようにできたとお話がありましたが、AAOSいじらずに調整したのは音声データのBuffer増やしたりしたのでしょうか？

Bufferの段数以外にはスレッドの優先度の見直し、CPU Affinityの調整を実施して、最適なシステム設計/検証を実施しました。

Q．OSSの話が出ていましたが、どのようなイベントにスポンサーしていたのか教えて下さい。

Linux Foundationが主催しているOSSJにスポンサーシップしており、今回のソフト開発の取り組みを紹介させて頂きました。
https://events.linuxfoundation.org/archive/2023/open-source-summit-japan/about/about-oss-ja/

Q．AAudioの不具合はAndroidに還元されたのでしょうか？

当時はソフトリリースを優先してアップストリームの活動が出来てませんでしたが、今後はアップストリーム活動を実施していく予定です。

Q．発表者は全員、自動車関連技術に深いバックグラウンドを持っているようです。 そのようなバックグラウンドのない開発者が、どうやって開発者としてこの業界に参入するのでしょうか？

車載向けのソフト開発におけるガイドラインを作成しています。例えばクランキング発生時の対処内容など、車載専用要件に対するガイドを全開発者向けに実施しています。

Q．SBOMの話が少しありましたが、工夫している点などがあれば教えて下さい。

OSSについてはOpenChainを参考にして、開発プロセスにOSSに関係する内容を今回追加しました。またSBOMについては、SPDX Liteを採用する事で、エクセルで管理する事が可能となり、会社間の情報共有がスムーズに実施できています。

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

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

本田技研工業の採用情報
https://global.honda/jp/jobs/?from=navi_footer_www