車載ネットワークの課題デバイス、テクノロジ、コ …...車載ネットワークの課題: デバイス、テクノロジ、コネクテッドカーを考える

w w w . m e n t o r g . c o . j p

Wh

it

eP

aP

er

E M B E D D E D S O F T W A R E

車載ネットワークの課題 :デバイス、テクノロジ、コネクテッドカーを考える

Patrick Shelly, Mentor Graphics


2w w w. m ento rg .co. jp

はじめに一般消費者向けのモバイル端末と自動車。製品寿命だけでなく、新機能／新モデルがリリースされるスピードという点においてもまったく異なる 2つの製品に対して今、自動車メーカーはジレンマをかかえています。コネクテッドカーを成功させるには、車載インフォテイメント（IVI）システムのソフトウェアを安全で簡単にアップデートする方法に加えて、新しいソフトウェア・コンテンツを部分的に追加できる、少なくとも感覚的には部分的に追加できる方法を提供できなければなりません。これまでの車載システムといえば、放送サービスを提供するだけの単純なアナログオーディオ装置が主流でした。しかし、インターネットベースで対話型のカスタマイズ可能なコンテンツが当たり前になりつつあるなか、よりはっきりとした課題が浮かび上がってきたのです。

ソフトウェアをアップデートする方法については方向性がはっきりしています。つまり、ディーラーでモジュール全体を交換していた従来の方法は、セキュアな USBまたはWi-Fi経由によるアップデートに取って代わられようとしています。いずれは自動車業界も、無線通信業界の動きにならって FOTA（Firmware Over-the-Air）経由で安全にアップデートやプロビジョニングを行うことになるでしょう。

一方、車載インフォテイメント（IVI）システムに新コンテンツを追加する方法については、数々の技術的ソリューションが競い合っています。基本的にはソフトウェアのアップデートと同じ方法で追加できます。しかし、それでは柔軟な対応ができず、ユーザによるカスタマイズもできません。いわゆる「App Store」（アプリストア）方式という選択肢もありますが、これにはセキュリティ上の深刻な懸念点があり、許可するシステムリソースを慎重に選定する必要があります。とはいえ、自動車 OEMが IVIシステムだけでなく、車載プラットフォームのほかのコンポーネントでもアプリケーションの使用を検討しはじめていることを考えると、このアプリストア方式は今後数年のうちに急速に広がっていくと予想されます。

このほかにも、Bluetoothなどの方式で接続したスマートフォンや各種移動体通信機器からコンテンツを実行するケースも多く見られます。米国の調査会社 ABIリサーチによると、自動車内でBlutoothを使って音楽を聞いたり電話をかけたりしやすくなってきたことから、Bluetoothの利用が今後数年間で急増すると見込まれています。Bluetoothを介して車内でメールやメッセージを送受信したり、SNSに投稿したりするのが当たり前になるのは時間の問題でしょう。さらに、Bluetoothであれば安全でシームレスにこうした作業が行えると期待されています。

本稿では、自動車と一般消費者向けモバイル端末の製品ライフサイクルの違いを考慮しつつ、IVIシステムのソフトウェア機能をどのようにアップデートし拡張すべきかについて検討します。また、工場で取り付けられる機器の設計やコストがどう変わっていくかを考えると同時に、各ターゲット層に応じて取るべきアプローチについても言及しています。

課題今日のコネクテッドカーは、接続の実装に関する多くの課題、しかも車内の接続だけでなく、車外との接続に関わる多くの課題を抱えています。車内の接続にまつわる課題としては、持ち込まれる無数の移動体通信機器への接続を提供できるのか、また絶えず変化し続ける AVコンテンツ形式（各システムの半導体パッケージごとに異なる場合が多い）を持続的にサポートできるのかといったことが挙げられます。移動体通信機器との接続も、AVコンテンツ形式への対応も、車両寿命を迎えるまでの間は車載システムをアップグレードし続けられるなんらかの仕組みが整備されていることが前提です。一方、外部接続における課題としては、主にWi-Fi、LTEなどの通信方式によるインターネット接続やリモコンキーのワイヤレス接続に関するものも含まれます。このほかにも、車内でのアプリ使用、アプリケーション・フレームワークの整備といった、提供元の異なるアプリケーションをさまざまな形式で扱えるようにするための課題もあります。

人気の「App Store」方式を採用した車両前部のディスプレイ



IVIシステムの接続性における主な課題

コーデックと接続性

IVIシステムを新しく設計するときにまず直面する課題の 1つに、コーデックと接続の問題があります。コーデックは、ハードウェアに実装するコンポーネント、または基盤となる SoC（システム・オン・チップ）やペリフェラル・シリコンデバイスと密接に連携するソフトウェアベースのコンポーネントのことを指し、マルチメディアのコンテンツを符号化または復号化して別の形式に変換する役割を果たします。一部オープンソースのものもありますが、ライセンスの正規購入を必要とするものもあるため、設計コストとして考慮しなければなりません。最近の半導体アーキテクチャでは、非対称型マルチプロセッシング（AMP）が急速に普及しつつあり、ソフトウェアベースのコーデックはマルチプロセッサ・コアまたはデジタル・シグナル・プロセッサ（DSP）のいずれかに実装されています。またコーデックは、個別のプロセッサまたはシステム・アーキテクチャに応じた最適化が可能です。ここで留意しなければならないは、コーデックとのインタフェースや使用するコンパイル・ツールが多岐にわたるため、コーデックがソフトウェア全体の移植性を低下させてしまう点です。

また車載システムと一般消費者向けデバイスとの接続に関していうと、一般的に議論の中心となるのは接続に使用するインタフェースの種類を何にするかです。最近では、USBまたは Bluetoothを用いるのが一般的です。接続ソリューションの検討にあたっては、プラットフォーム OSに何を選ぶか、またオプションで選択するサードパーティ製の接続ソリューションを何にするかということが接続効率を左右します。同時に、接続ソフトウェア（そして少なくともデバイスの物理的な接続に関しては関連ハードウェア）のアップデートおよび拡張のしやすさにも影響するのです。

さらに、モバイル端末で稼働するアプリケーションとの双方向通信が増えてくると、USBや Bluetoothといった基本的な接続プロトコルでは対処しきれない問題も出てきます。例えば、AAP（Apple Accessory Protocol）、Android Open Accessory Protocol、Microsoft Media Transfer Protocolなどのプロトコルにも対応できる拡張機能が必要になることもあります。これらのプロトコルについては一部、後半のセクションで取り上げます。また、DRM（Digital Rights Management）に対するさまざまな取り組みや、一部の Apple製品を IVIシステムと接続するときには iPodの認証 ICが必要になる点も触れておくべきでしょう。それだけでなく、ほとんどの IVIシステムでは、アナログの AUX入力端子からレガシーデバイスやサポート対象外のデバイスに接続できるようになっています。システム・ソフトウェア開発者であれば、実際の設計作業に入る前にこうした課題を洗い出すと同時に、チップ／ハードウェアのベンダと協力して、しっかりした完璧な IVI接続ソリューションに向けて詳細を詰めておく責任があります。

マルチゾーン・オーディオ接続とマルチメディアゾーン

IVIシステムの新しい接続機能の 1つにマルチゾーン・オーディオ接続があります。これはさらにマルチメディアゾーン間のコンテンツ共有へと広がっていきます。マルチゾーン・オーディオ接続によって、運転者と同乗者がそれぞれ別のエンターテイメントを体験できます。例えば、運転者が車載音声システムを介して音楽を聞いたりナビの指示に従ったりしている隣で、同乗者はワイヤレス・ヘッドセットなどを使って別のマルチメディア・コンテンツを楽しむことができるのです。こうしたマルチゾーン・オーディオ接続モデルは、音声とビデオのディスプレイを別々に扱うことができることから、（USBまたは Bluetoothを介して同乗者のデバイスを IVIシステムに接続することで）マルチメディア・コンテンツを楽しむこともでき、結果的に、車内に複数の「マルチメディアゾーン」が生まれます。こうして車内のヘッドユニットから各自がそれぞれのデジタルコンテンツを受信できるのです。自動車メーカーが取り付けた基本の IVIシステムにはないこうした仕組みは、ディーラーによる取り付けやアフターサービスで後席エンターテイメント（RSE）システムを設置したりすることで使用できるようになります（図 2）。

自動車のアーキテクチャがより統合された包括的な IVIシステムに向けて進化することが期待される一方で、テレマティクス、RSE、インストルメントクラスタ（IC）などの各システムは今後も、それぞれ個別に分散したアーキテクチャとして車載プラットフォームの拡張性を支えていくでしょう。この分散型アーキテクチャでは、工場で取り付けたシステムとアフターサービスで追加したシステムとが混在するようになるのです。



座席位置 1 座席位置 2 座席位置 3

近くのレストランを検索本を読むビデオ視聴

OEMカスタマイズ・アプリケーション

GENIVI準拠ソフトウェア・スタック

非トラストのアプリケーション

Android

HAL

HTML5オプション

Linux Container Linux Container Linux Container

Linux Security Modules（LSM）Mentor Embedded Automotive Technology Platform

マルチコア SoC（ARMTM、ATOMTM）

図 2　xハイパーバイザ、Linuxコンテナ、Linux Security Modules（LSM）などを使用して「トラスト」と「非トラスト」のパーティションが区切られたマルチメディアゾーン

Androidアプリここ数年、Androidに対する関心、特に Androidアプリの自動車内での使用に対する関心は高まる一方です。実際、車載システムを Androidアプリに対応させることは技術的に難しいことではなく、車種によっては大きなセールス・ポイントになるかもしれませんが、深刻な懸念があることも事実です。つまり、システムのセキュリティ上の問題と運転者の注意力妨げにつながる問題です。Androidを組み込む場合のセキュリティ上の問題については、本稿でも対処法をいくつか取り上げています。また、運転者の注意力の妨げの問題は、非常に現実的な脅威であり、NPOや米国政府もこの問題に関与し、対処する姿勢を見せています。

Androidスマートフォンの多くの機種で自動車用 Androidアプリが使用できますが、車載 IVIシステムとして対応しているアプリストア環境を 1種類に限定している自動車メーカーには明らかに不利な点があります。最近では、IVIの実装による差別化が自動車（特に中級車や高級車）の成功の鍵となっている例が増えており、Androidであれ他社であれ、1つのアプリ環境のみに頼っている場合、車載 IVIによるユーザ環境をほかの車両の IVI環境と差別化しようとしてもなかなか限度があるのです（とはいえ、スマートフォンと車内ダッシュボードとの一体感を求める一部のエンドユーザや自動車メーカーにとってこの点には議論の余地があります）。さらに、自動車メーカーは、収益性の観点から「all-app」方式（アプリストアからどのアプリケーションでも自由にダウンロードして使える環境）導入には乗り気ではありません。

こうしたことを考慮してもなお、自動車用アプリ市場には飛躍的な成長が見込まれています。米国の調査会社ABIリサーチによると、自動車内でダウンロードするアプリの数は、現在の年間 1200万件から 2018年末までに43億件へと飛躍的な伸びを見せるだろうと予測されています。

インターネット自動車に接続性を採り入れる際のもう1つの課題が接続そのものの特性です。インターネット接続は、オンボードの無線チップセットを使用するか、USB接続または Bluetoothでペアリングしたモバイル端末を経由するかして確立します。安全性を売りにしたシステムは通常、オンボード無線接続機能を採用していますが、その場合でも、常に変化し、地域ごとに異なる通信技術に自動車 OEMは対応し続けていかなければなりません。通信技術の変化の多くは、単純なソフトウェア・アップデートや FOTAだけでは対応できません。例えば、米国でこれまで普及していた CDMA方式からより高度な LTEテクノロジへと大規模な移行が進んだときがそうでした。これ



により、自動車に乗っているときにオンボード無線機能を基本的な電話通信端末として使用すると、高額の利用料金が請求されることになり兼ねません。

いずれにしても、インターネット接続を提供するということは、同乗者がWi-Fiホットスポットへアクセスできるようになり、また確立したWi-Fiネットワーク（固定 IPアドレスで静的に構成されたネットワークなど）を使用して車内のモジュール間の基本接続を確保できる可能性が生まれます。携帯電話やワイヤレス・モデムなどの移動体通信機器を介して、制限のないWi-Fiホットスポットを提供することも可能です（BMWが始めたサービスもその１つ）。車内Wi-Fiネットワークを実現するオンボード無線チップセットにより、同乗者が新たなサービスを利用できる道が開かれるでしょう。自動車 OEMにとっても、ワイヤ・ハーネス設計の簡素化や新たな接続テクノロジへの柔軟な対応ができるようになるのです。

マルチメディア・コンテンツのストリーミングインターネット接続が可能になるということは、マルチメディア・コンテンツのストリーミングが可能になることでもあります。多くのレガシー RTOS製品でパッケージ化されているような従来のマルチメディアプレーヤは、ファイルからマルチメディアを再生する方式に適しています。したがって、ストリーミングに対応させるには、通常は設計をやり直さなければなりません。しかし、より高度な OS、特にデスクトップ環境対応のインスタンスを持つ OS（Linux®など）であれば、設計をやり直す必要がありません。

アップグレードへの対応このセクションではアップグレードへの対応に関する課題を取り上げます。最近の IVIシステムは、USB接続による簡単なメカニズムなど何らかの方式でソフトウェア・アップデートに対応していなくてはならないものがほとんどです。インターネット接続が可能であれば、FOTAによるソフトウェア・アップデート方式という選択もあります。ただし、その場合は、プロビジョニングに際してソフトウェア・コンポーネントのバージョン互換性に配慮し、各システムにインストールされた現在のコンポーネント・バージョンの構成を把握しておかなければなりません。特に、部分圧縮したアップデート用パッケージ（またはバイナリ差分パッケージ）を配信してアップデートを高速化し、全体的なソフトウェア・アップデート時間を短縮させるのであれば、バージョン構成の理解が非常に重要です。

いずれの方法でアップデートを行う場合でも、ソフトウェアをスムーズにアップデートし、失敗に備えるために冗長メモリ領域を確保しておく必要があることを考えると、各システムのメモリ要件に大きく影響します。

一方、アプリ間の相互依存や基盤システム・サービスへの依存がそれほど複雑でない個別アプリのアップデートは比較的簡単です。アプリストアを利用する方法もありますが、この場合、システム・ソフトウェア（一部の基盤アプリなども含まれる）のアップデートにも対応できるように、包括的な FOTAによるアップデート方式が必要になります。より簡単な方法として、モバイル端末で実際に稼働しているアプリを利用することもできます。次のセクションで説明している既存の接続ソリューションのなかにも、モバイル端末からアプリを直接実行する方法を採用しているものがあります。こうすることで、システム全体のソフトウェア・アップデート（接続用ハードウェアのアップデートも含む）を大幅に簡素化します。モバイル端末のアプリでアップデートを行うことにより、自動車OEMはアップデートに付随する問題から多少なりとも解放されることになるのです。

運転者の注意力低下新しく IVIシステムを設計するときに大きな課題になりつつあるのが、運転者の注意力をいかに阻害しないような工夫をするかということです。現在の一般的な接続メカニズムでは、IVIシステムのディスプレイに表示させる内容を細かく制御することが難しいため、運転者の注意を逸らせてしまう危険性があります。

このため、自動車メーカーには運転者の注意力を低下させないようにするための取り組みが求められているのです。

昨年、米国運輸省国家道路交通安全局（NHTSA）は、運転中の不注意により生じたと見られる自動車事故が急増しており、全米で年間 3,300件以上に達しているという報告をまとめました。事故の急増を受けて、規制当局は自動車メーカーとサプライヤ向けに一連の指針を策定しています。

しかし、指針の定着までに時間がかかる、指針によって革新が抑制されるといった懸念の声も聞かれます。

細かい操作を自動化することで、運転中の注意力低下を防ぐのも 1つの方法でしょう。ほかにも、ドライバーに対する研修の義務化や技術貢献をビジネスとする企業とのより緊密な協力体制によって、不注意運転を減らそうとする試みもあります。



セキュリティ新しい接続アーキテクチャを考えるうえでますます議論されるようになってきているのがセキュリティです。インターネット接続やデバイスとの接続がもたらした開放性によって、自動車エレクトロニクス産業には新たな時代が到来しました。現在行われている議論のほとんどは、基盤ソフトウェアのアップデートおよび安全なアプリ配信とアップデートに関するものです。しかし同時に、インターネット接続そのものの安全性についても考慮しなければなりません（例えばセキュリティ侵害が起こると、莫大な保証費用が発生します）。本稿の執筆中に、不審者が自作した不詳のデバイスを使って「ワイヤレス操作」で自動車に侵入したという事件が報道されました1。この種のセキュリティ侵害は、きまって自動車のリモートキーレスエントリ（RKE）システムに不正に侵入して行われます。今後の不正侵入を減らすためにも、より強固な暗号化プロトコルと安全規定をホスト・ソフトウェアに組み込む必要があります。

また、ハッカーが自動車の中に侵入し、中枢のコントロールをハイジャックできてしまう恐れがあるという報道もありました2。一連の報道が警告しているのは、ハッカーが自動車の電子システムを支配し、予期せぬ事故を無理やり起こせてしまうということです。とはいっても、安全性を左右する重要な機能は、他から切り離され、遮断されたシステムの中で稼働するので、このような事件はそもそも考えにくいのです。さらに、安全性に関わる重要な操作のほとんどは、最終的にメカニカル・エンジニアリングに基づいているため、ソフトウェアに侵入するデジタル・ハッカーの影響を受けることはありません。

個人情報保護にも大きな関心が寄せられています。例えば、スマートフォンを IVIシステムに接続した場合、セキュリティ侵害によって個人の重要なデータが盗まれる危険性があります。これについては、ソフトウェアまたはハードウェア対応のテクノロジがいろいろ考案されてきているので、そのうちこうした脅威の危険性も回避できるようになるでしょう。今のところ実績ある方策として、セキュアブート、SELinux、Linux Security Modules（LSM）をベースにした強制アクセス制御（MAC: Mandatory Access Control）などOSセキュリティ機能の実装、また ARM TrustZoneテクノロジといったハードウェア・セキュリティの拡張機能などが手軽に利用できるので、真剣に検討することをお勧めします。また、後述のとおり、ハイパーバイザ・ソフトウェアを導入しても、セキュリティを強化できます。

GPLライセンス必ずしも懸念事項というわけではありませんが、オープンソースのソフトウェア・コンポーネントの使用許諾を定めた GNU General Public Licenseバージョン 3（GPLv3）についても頭に置いておくことが重要です。Linux OSなどのオープンソースのソフトウェアを使用すると、通常は GPLバージョン 2（GPLv2）のライセンスのもとでオープンソースとなったソフトウェア・コンポーネントの一部である可能性があります。さらに GPLv3のライセンスでは、配布したモジュールをプログラム改変できるように、仕様書、また場合によってはハードウェアとやりとりするソフトウェア・コンポーネントも提供しなければなりません。車載ソフトウェアのプロジェクトやオープンソース化を推進している業界団体（GENIVIなど）は、こうした基本事項をよく認識しており、GPLv3でライセンス許諾されたコンポーネントを製品に含めないようにしています。

OEMによるブランド化自動車メーカーが真剣に検討すべきこととして、OEMとしてのブランド力を取るか、ユーザ・インタフェースの一貫性を取るかという問題があります。携帯電話の画面をそのまま車載インフォテイメント（IVI）システムの画面に再現する方法や IVI画面に表示する内容を携帯電話から起動する方法など、既存の接続テクノロジにはいくつかあることはすでに述べました。こうした方法を用いれば、携帯電話と車載システムとの間に一貫したユーザ・インタフェースを保つことができます。ある意味これは望ましいことですが一方で、OEMにとってはブランド力を制限され、またユーザ環境の構築に参加できないことにもなります。この方法は低価格帯の車両で導入が進んでいますが、中高級車両に展開することに対しては躊躇する意見が出ています。後ほど、HTML5などのWebベースのテクノロジを利用した優れた代案を紹介します。

このセクションで取り上げた課題のほかにも、「内部的な」課題もいくつかあります。例えば、IVIシステムの Tier 1サプライヤが過去からの莫大なコード資産を所有しているかもしれません。たとえ新しい IVIシステムの要件が基本的に既存コード資産との互換性がなかったとしても、新しい IVIシステムでも既存コードを再利用できないか検討したいという要望が出てくるでしょう。



後半は、既存の接続アプローチをいくつか紹介します。その多くは事実上、ポイントソリューションまたは業界標準ではない独自規格のソリューションです。また、前半に取り上げた課題の一般的な対処法もいくつか紹介します。

既存の接続ソリューション

このセクションでは、新規アプリケーションまたはアップデート版を IVIシステムに追加したり、システム機能を拡張したりする際に用いられている現在のテクノロジを検証します。こうしたテクノロジには、最新のアプリケーション・フレームワークへ移行するものから、モバイル端末のアプリや機能を利用して IVIシステムとして再現するものまで、実に多様なソリューションがあることがわかります。いずれのソリューションもある程度の実用性は備えているものの、課題も多く、また独自規格であるがゆえの問題も山積しています。

まずは、技術的な基準として用いられてきた、電子制御装置（ECU）の従来の開発手法について理解しておきましょう。ECUの開発はこれまで、固定されたコンテンツを 1つまたは複数のファイルでシステムを構成するアプローチを取っていました。固定されたコンテンツのファイルは、製造時に不揮発性メモリにプログラムされ、基本的にシステムの拡張はできないようになっており、エンドユーザ側で最低限の再構成ができる程度です。機能の変更または追加が必要な場合は、バイナリファイルを再生成し、デバイスをプログラムしなおす必要があります。ここ数年、ECUブートローダの機能が拡張され、CANなどの車載ネットワークを通じてモジュールのプログラムを変更できるようになったことで、出荷済み車両のプログラム変更もある程度は簡単になりました。

従来のアプローチは、マイクロコントローラをベースにした車載電子モジュール設計が始まった当時からの手法で、ほとんどの車載 ECU設計において現在も使用されています。また AUTOSAR規格準拠のシステム設計や、意外なところではインストルメントクラスタ（IC）やテレマティクスのモジュール開発でも一般的な手法として採り入れられています。

これよりはるかに優れたアプローチは、ネイティブのアプリケーション・フレームワークを使用する方法でしょう。アプリケーションのストレージと起動のフレームワークを IVIシステムが提供し、システムの機能セット拡張が可能です。このアプローチを実装するときに、Qtなど既存のテクノロジや市販されている各種製品のテクノロジを活用することもできます。ネイティブのアプリケーション・フレームワークを使用すると、新しいアプリケーション・コンテンツを展開したり、インストールしたりするときの安全なパッケージング／配信メカニズムを確保できます。また、アプリケーションを認証し、アクセス権限を用いてシステムレベルのリソースへのアクセスを適切に制御できる、安全なアプリケーションランチャーもあるはずです。

コネクテッドカーの既存ソリューション事例

MirrorLink

MirrorLink（旧 Terminal Mode）は、仮想ネットワークコンピューティング（VNC）による比較的簡単な画面の複製機能を完全なプロトコルへと進化させたものであり、アプリケーションレベルで不注意運転を回避する仕組みを備えるだけでなく、アプリケーション認証のプロセスも含まれています。MirrorLinkは、VNC以外にも IP、USB、Wi-Fi、Bluetooth、リアルタイムトランスポートプロトコル（RTP）、Universal Plug-and-Play（UPnP）といった一般的なテクノロジもサポートしています。もともとノキアとCE4A（Consumer Electronics for Automotive）によって開発、推進されてきたMirrorLinkは現在、カー・コネクティビティ・コンソーシアム（CCC）が管理しています。CCCには、世界中の自動車メーカーの 8割以上、またスマートフォンメーカーの 7割以上が参画しています。メンター・グラフィックスが提供する Linuxベースの車載プラットフォームのソリューションもまたMirrorLinkのテクノロジに準拠しています。

MirrorLinkは、トヨタのタッチスクリーン式カーナビゲーションシステム「Entune3」の欧州バージョンである「Toyota Touch」で最初に導入されました。最近では、米自動車メーカーのゼネラルモーターズの準小型車モデルにも一部採用されています。例えば、シボレーの限定車種では廉価版の IVIシステム「MyLink」を搭載していますが、これはMirrorLinkのテクノロジを一部利用しています4。



MirrorLinkを用いると、携帯電話の画面がまったくそのまま IVIシステムのディスプレイに映し出されます。IVIシステムのタッチスクリーンまたはボタンから入力した情報は、携帯電話のアプリケーションに送信されて処理されます。後述するいくつかの手法でも同様ですが、重要なのは、アプリケーション自体はモバイル端末で実行されるという点です。MirrorLinkのインフラストラクチャとモバイル端末との接続さえ準備できれば、IVIシステム上にソフトウェアは必要ありません（図 3）。

ネットワーク

ナビゲーション

エンターテイメント

モバイルオフィス

音声認識エンジン

オーディオ

電話通信

クラウド

IVIソフトウェア

図 3　MirrorLink手法によって、いつも使っているスマートフォン用アプリを自動車のダッシュボードやヘッドユニットに表示させてドライバーの使い慣れた環境を再現

MirrorLinkの手法を用いると、システム機能をユーザ主導で拡張するためのアプリケーション・フレームワークをサポートする必要がありません。この手法のマイナス面を 1つ挙げるなら、表示されるコンテンツに変更を加えられないため、OEMのブランドをアピールしにくくなる点です。しかし、IVIシステムの Tier 1サプライヤやその他のハードウェア・ベンダなどにとっては、新たに開発したハードウェア上で、最新の機能を迅速に試すことができるという利点もあります。MirrorLinkには、端末との接続にWi-Fi、USB、Bluetoothなどあらゆる通信方式を利用できるという強みもあります。

しかも、ユーザのサポートはそれぞれのモバイル端末メーカーが全面的に担うため、OEMの負担を軽減できます。通信プロトコルや接続方式が変更される場合を除いて、ソフトウェアのアップデートは接続するモバイル端末だけで行えば良いのです。MirrorLinkのテクノロジは OSに依存しないと謳われています。しかしながら、これを執筆している時点で Appleは CCCに加入しておらず、iOSベースの端末はMirrorLinkをサポートしていません5。

iPod Out

Appleも非常に似たテクノロジである iPod Outを開発しています。これは、接続した iPodまたは iPhoneの画面が IVIシステムのディスプレイにそのまま出力されるというものです。モバイル端末から IVIシステムへの接続には、Apple独自規格のコネクタが使われており、IVIシステムへ画像が出力されるとともに、IVIのディスプレイから入力した内容もモバイル端末に返されます。IVIとモバイル端末との間の一貫したユーザ・インタフェースによって、優れた使い勝手を実現しています。しかし、IVIシステムのディスプレイにどういうコンテンツをどの形式で表示するかということはモバイル端末に依存するため、ドライバーが画面に気を取られてしまう危険性があります。iPod Outの場合もまた、コンテンツを OEMブランドとして展開できないため、意図せずして「iCar」を作ってしまう可能性もあります。さらに、iPod Outの機能は基本的にマルチメディアと電話通信にしか対応し



ていないため、それ以外のアプリケーションにも対応しているMirrorLinkほどの汎用性がありません。iOS 4に搭載されている iPod Out機能は Apple製品でしか利用できず、現時点で採用しているのは BMWなど少数の自動車メーカーに限られています6。ほかの端末メーカーが似たような機能を開発したとしても、ハードウェアとの接続インタフェースが統一されることはなさそうです。実際、iPhone 5で規格が新しくなった Lightningコネクタでは、一部の重要な信号（映像出力）に対応しなくなったため、iPod Outは利用できなくなってしまいました7。

HTML5

最近、車載システム、特に IVIシステムにWeb関連のテクノロジを利用することへの関心が高まっています。Web関連のテクノロジには多くの利点があります。例えば、HTML5や CSS3などのテクノロジは開発者数も多く、モバイル端末から発信されるコンテンツの再ブランド化や再構築を可能にします。現行の HTML5を実装することで期待できるのは、HTMLコンテンツをローカルの IVIシステム上にも、接続したモバイル端末上にも置くことができ、どちらも IVIシステムのディスプレイに表示できることです。モバイル端末上にコンテンツを置く場合は通常、コンテンツを送受信するための HTTPサーバが必要になります。HTML5にはクラウドコンピューティングの技術が採用されているため、コンテンツをシームレスに移行できます。IVIシステムのアプリケーションやコンテンツをモバイル端末、最終的にはクラウドに移行する際も同じインフラストラクチャを再利用できます（図 4）。

共通HMI

グラフィックスレイヤ管理

ネットワーク





HTML5アプリ


Chromium

Mentor Embedded ATP

ハードウェアレイヤARMマルチコア CPU

GPU

図 4　HTML5はWebKitベースの Chromiumに対応。基盤 SoCに GPUを搭載してパフォーマンスを最適化

Webテクノロジによる手法の主な難点は適応性の低さです。多くの調査で、HTMLによる手法は性能の低いプロセッサには十分に対応しきれていないという結果が出ています。プロセッサ・アーキテクチャやグラフィック・プロセッシング・ユニット（GPU）によっては、HTMLレンダリングエンジンの最適化に相当な努力を要します。ただし、こうした欠点も次第に解消されてくるでしょう。当然、クラウドテクノロジへの信頼性がより高まったとしても、ネットワーク障害や IVIのローカルなシステム不具合による接続障害に備えて、しっかりとしたフォールバック戦略が必要です。



Appleの Siri

Nuanceのテクノロジに基づいて開発された Appleの音声認識ソリューションである Siriは、今後の重要な機能として自動車 OEM向けに大々的に宣伝されています。2012年には、自動車 OEM11社が Siriの「Eyes Free」テクノロジを搭載するというプレス発表もありした。しかし、現実はそれほど簡単ではないと見え、発表から 1年後の 2013年現在、Appleの音声認識テクノロジを採用しているのは GMただ 1社です8。Siriは極めて簡単に統合できます。ハンドル部分のボタンを押しながら音声を入力すると、IVIを経由せずに、iPhoneに音声が直接送信され、対応する操作が実行される仕組みです。

最近、Appleは iOSを車載 IVIシステムと連携させる考えを発表しました。iOSは iPod、iPhone、iPadで採用されている Apple独自の OSであり、「iOS in the Car」は IVIシステムに対応した iOS 7の新機能です。報道される内容の多くは分かりにくく、iOSが IVIシステム上で直接実行されるようになるのか、それとも Appleのモバイル端末上のアプリやサービスが IVIのスクリーンに映し出されるようインタフェースが拡張されるのか明らかではありません。実際のところ、Apple Accessory Protocol（AAP）、iPod Outや前述の Siri Eyes Freeなどの技術によって、すでに多くの IVIシステムで利用できるようになっているのです。

Ford AppLink

Fordの AppLinkは、不注意運転の問題に対処するための優れたソリューションを備えています。これまでに紹介したソリューションと同様、AppLinkは接続したモバイル端末が提供する新しいアプリケーションやサービスをIVIシステムで利用できるというものです。ただし AppLinkの場合、モバイル端末からアプリケーションを起動すると、モバイル端末のディスプレイは無効になり、アプリケーション制御はすべて音声コマンドとハンドル部分のコマンドボタンだけで行われるようになります。

Fordは、AppLink APIのソースコードは GENIVI Allianceが主催するプロジェクト（Smart Device Linkと呼ばれている）を通じて公開されると発表しており、そうなればこのシステムは広く普及する可能性があります9。現在、AppLinkは現行 Ford SYNCに搭載されていますが、ほかの自動車 OEMも追随するかどうかは今のところまだわかりません。

セルラー通信もう 1つ、IVIシステムに関して考えないといけないのは、セルラー通信に、一般的なオンボードモジュールを使うのか、移動体通信機器とのテザリング機能を使うのかということです。どちらの方法にもOEMは対応可能です。しかし、どの方法を選択するかで、通信サービスの継続的な収益がどこに行くのか、またソフトウェア・アップデートや新コンテンツ追加に関するサポート対応をどこが担うのかが決まるので、ビジネス面での影響があります。またオンボード通信機能にするかテザリングによる接続にするかの選択で、非常時のつながりやすさにも関連してきます（例えば携帯電話のバッテリが切れているときやテザリング機能を提供する端末が近くにないときに車の衝突事故が起きてしまった場合などを想定する必要があります）。

ところで、IVIシステムが製品化されて出荷された後でも、その機能を拡張できるソリューションはいろいろ出ています。そうしたソリューションのなかには、IVIシステムに直接実装されるモジュールもあります。この場合、モジュールのソフトウェアをアップデートするための、そのソフトウェアにアクセスできる何らかの仕組みが必要になります。現在のところ、接続したモバイル端末上のアプリケーションやサービスを利用して IVIシステムの機能を拡張する方法が大半のため、IVIモジュールのソフトウェアをアップデートする必要はほとんどありません。また、HTML5を利用したソリューションでは、クラウドベースのアプリケーションやコンテンツをシームレスに利用する可能性も見えてきました。

接続に関する今日の課題にどう対処するか

このセクションでは、本稿を通じて取り上げてきた各種課題への対応策を考察していきます。アプリケーション・フレームワーク、ソフトウェア・アップデート、そして端末の接続に関して何らかの基準（少なくともデファクトスタンダード）が確立されるまでは、多方面からのアプローチが必要でしょう。当面は、安全性を考慮してオンボード通信ネットワーク接続機能を実装しつつ、コンポーネントの頻繁なアップデートや拡張アプリケーションのインストールをモバイル端末側だけに限定する動きが優勢を占めるでしょう。また、基盤となるハードウェアおよび



ソフトウェアのプラットフォームで利用できるセキュリティ機能はすべて積極的に利用することを推奨します。そして可能な場合には、最新のWebベースのテクノロジをアプリケーションやアプリケーション・フレームワークに取り入れることももちろん有効でしょう。

オープンソースソフトウェア（OSS）の利用は、接続に関する問題解決に大いに役立ちます。というのも、新しい接続テクノロジのほとんどは Linux OS環境でプロトタイプ化され、リリースされるからです。メンター・グラフィックスの ATP（Automotive Technology Platform）は、包括的な Linux商用ディストリビューションをベースにしており、GENIVI Allianceのコンポーネントなど IVIに特化したミドルウェアを備えるとともに、最新のビルド環境、高度な開発ツール、車載アプリケーションの各種専門サービスを提供します（図 5）。

Mentor Embedded Automotive Technology Platform

トラスト・アプリ

車載アプリケーション

Mentor ATPユーザ空間

非トラストアプリ

Linux Container

コア・コンポーネント

自動車

ネットワーク／インターネット

マルチメディア・オーディオ／グラフィックス

メンターのアドオン機能

CEデバイスとの接続

セキュリティ

システム

ソフトウェア開発キット

統合プラットフォーム

クロス開発ツールチェーン

IDE/Sourcery CodeBench

エンジニアリング・サービス

カスタマイズ OSとミドルウェアのサポート

ハードウェアのカスタマイズ

グローバルなプロジェクト管理

設計サービスのカスタマイズ

巨大なエンジニアリングプール

製品品質のテストと検証

図 5　メンター・グラフィックスの ATP（Automotive Technology Platform）は、常に進化を続ける柔軟なテクノロジ基盤を備え、IVIソリューションをカスタマイズする高度な仕組みを提供

Linuxでは新しいテクノロジをすぐに利用できるだけでなく、ユーザや開発者の数も多いので、こうしたオープンソースソフトウェアが IVIシステムのソフトウェア・プラットフォームとして採用されるのは当然と言えます。ニッチの非オープンソース系 OSの場合、新しいテクノロジを移植するには長い時間が必要ですが、オープンソースソフトウェアであればこうした時間を開発スケジュールから省けるだけでなく、開発と製造にかかる全体的なコストも大幅に削減できるのです。Linuxにはまた、米国家安全保障局（NSA）が一部主導して開発を進めてきた高度なセキュリティ機能がかなり以前から提供され、継続的に強化されています。

本稿で論じてきた接続に関する各種課題は、IVIシステムに何らかのアプリケーション・フレームワークを用いることで対処できるものが多くあります。開発元の異なるアプリケーションのインストールや起動が可能なフレームワークが理想的です。というのも、各アプリケーションは、HTML、ネイティブ OpenGL、Qt、または一般的な車載 HMI開発システムなど、開発メソドロジやプログラミング技術が多岐にわたるからです。また、今日のスマートフォンに一般的にみられるような、アプリケーションごとに利用できるシステムリソースを制限する仕組みも必要です。例えば、ユーザが許可していれば、カーナビゲーション用アプリや天気情報アプリが GPSデータ（位置情報）にアクセスすることも一般的になるでしょう。しかし、CANなどの車載通信ネットワーク上の情報は慎重な取り扱いが必要なものもあるため、用途が十分に明確化されたアプリケーションに限定して個別にアクセスを許可するべきです。



アプリケーション・フレームワークがあれば、アプリストアの考え方を採り入れることもできます。実際は、Android端末向けアプリストアである Google Playや Amazon Appstoreで提供されるモバイル・アプリに無制限にアクセスできるようにする自動車 OEMはないはずです。しかし、事前に承認した 30～ 50個くらいのアプリを OEM提供のアプリストアから利用できれば便利です。ただし、アプリストアからアプリを安全に配信できるシステムが必要です。インストーラがアプリをファイルとして解凍し、アプリメニューに組み込めなければなりません。また、アプリケーション・フレームワークでは、起動する前にアプリケーションの妥当性を確認する仕組みも必要です。

1つの方法として、Type 1のハイパーバイザ（図 6）を IVIのシステム設計に採り入れることで、いくつかの課題に対処することができます。例えば、レガシーの RTOS環境のソフトウェア・コンポーネントを統合してソフトウェアを再利用する、異なるOS領域を分離してセキュリティを確保する（Android OSや Androidアプリケーションを統合する場合も含む）、AUTOSARなど車両向け OSやソフトウェア・コンポーネントなどを統合するといったことが可能です。Type 1のハイパーバイザはまた、起動高速化要件にも対応できます。さらに、ハイパーバイザを使用することでソフトウェア・ライセンスも分離できるので、ソフトウェアのアップデートが簡単になります。

これ以外に IVIシステムで Android OS環境を安全に実現する一般的な方法として、ハイパーバイザまたは LXC（Linux Containers）上で Androidを稼働させるというものがあります。LXCは Linuxカーネルのバージョン2.6.29から利用できるようになっており、現行ディストリビューションにも対応しています。LXCの使用は、一部の用途には有効ですが、すべてに適しているというわけではありません。例えば、マルチディスプレイに対応した Linuxベース IVIシステムを開発する際、1つのディスプレイに後席エンターテイメント（RSE）システムを実装することもできます。この場合、基盤となる Linuxディストリビューションとそれに関連するミドルウェアを IVIシステムに実装し、LXCで稼働する Androidディストリビューションを RSEのスクリーン用に割り当てます。しかし、それ以上の分割が必要なときはハイパーバイザのほうが有効です。

図 6　Type 1ハイパーバイザの構成オプション : 専用モード（左） - 各ゲストに専用のコアを設置、混在モード（右） - 専用のコアを持つゲストとタイムスライス型のコアを持つゲストが混在

さらに、Androidの Dalvik仮想マシン（DVM）と関連ライブラリを LinuxなどAndroid以外のシステムに移植して使用することもできます。こうした Android互換のアプローチは、単純に Androidのアプリケーションを実行することだけが第一の目的であれば、アーキテクチャのオプションとして便利です。ただし、新バージョンのAndroidがリリースされた場合や、この疑似エミュレーション環境でアプリが正しく動作しなくなった場合など、メンテナンスが面倒になる可能性があります。

もちろん、非対称型マルチプロセッシング（AMP）を用いて、Androidを実装することも可能です。そうすれば、SoCデバイスにある複数コアのうちの 1つのサブセット上で Androidを実行し、残りのコア上で Linuxなどほかの OSを実行できます。このソリューションの難しさは、相互排他的なペリフェラルの割当てを決めておかなくてはならない点です。また、ネイティブの Androidディストリビューションを稼働するときと同様、セキュリティ上の懸念が存在します。しかし、この AMP構成においてハイパーバイザを用いれば、リソースの「監視役」として動作するため、セキュリティ面でも安心です（図 7）。



共通HMI

グラフィックスレイヤ管理

ネットワーク





Androidアプリ

Android OS Linux OS

組込みハイパーバイザ

SoCARMマルチコア CPU

GPU、ペリフェラル

図 7　Type 1ハイパーバイザを使用して 2つの OS環境（LinuxとAndroid）を混在させて実行

こうして考えていくと、環境分離の極端なケースとして、リモート接続したデバイス上でアプリケーションを実行することもできます。この方法は、前半でも取り上げましたが、接続の課題に対するポイントソリューションとして用いられるケースが多いようです。

ここまで、ソフトウェアのアップデート対策の必要性について繰り返し述べてきました。最新の IVIシステム設計を見てみると、設計サイクルが急速に短くなったこともあり、IVIモジュールのソフトウェアをアップデートする何らかの仕組みを必要とするものが増えています。最近登場したソフトウェア・アップデート技術に FOTAがありますが、これは主にワイヤレス通信のインフラストラクチャに基づいた仕組みです。FOTAでないにしても、少なくともUSB接続によるアップデートは可能にしておく必要があります。

アップデートの方法を決めるにあたり、条件付きアップデートとサイレント（または強制）アップデートを比べてみるとよいでしょう。ソフトウェア・コンポーネントのアップデートはユーザが選択的に実行できるようにするのが理想的です。例えば、ユーザが現行の音声認識エンジンの性能に満足しており、新バージョンに心配の声が上がっているのであれば、音声認識データベースのアップデートをユーザが延期できるようにするのが妥当でしょう。また、すでにインストールされているアップデートについては「断る」ことができる機能も必要です。しかし、バージョンの互換性管理が複雑になる可能性があります。そこで、これに対処する正式なアプローチとして現れたのが、オープン・モバイル・アライアンスが策定した OMA-DMのデバイス管理プロトコルです。

最後に、無視できないのがインターネットに対するアクセスのしやすさです。すでにクラウドベースのアプリケーションやサービスへの移行を計画しはじめた開発者もいます。これらの移行計画では、HTML5をはじめとするWebベースのテクノロジを最大限、活用しようとしています。結局のところ、クラウドベースのアプリケーションやコンテンツの一番の利点は、システムのアップデートが簡単で迅速であることに尽きます。クラウドサーバに配信されたアプリケーションのアップデート版は、出荷済みの IVIシステムが次にそのアプリをサーバからリロードまたは起動するタイミングで反映されます。



まとめ自動車と端末の接続に関わる課題は、既存の車載ソフトウェアをアップデートする必要性から、運転者と機器のより安全でシームレスな双方向通信までさまざまですが、利用できるソリューションも各種考案されています。しかし、すぐには解決できない問題もあります。米国の市場調査およびコンサルティング会社である J.D. パワー・アンド・アソシエイツが新型車両の品質について調査した結果、消費者の一番の不満は、車内でエンターテイメント機能やナビゲーション機能を実行しながらスマートフォンを使用するのが難しいことでした10。本稿でも取り上げたように、接続に関する問題の多くは、車載 IVIシステムがスマートフォンの最新リリースに対応していないことが原因です。

設計や開発に何年も費やすことの多い自動車のテクノロジがスマートフォンの最新アップデートやリリースに遅れないようにするにはどうすれば良いのでしょうか。本稿では、主に 2つの選択肢、つまり、自動車メーカーが

投資をして独自の IVIシステムを構築する方法（「内蔵型」アプローチ）とOEMが最新のスマートフォンの機能をダッシュボードのディスプレイに再現する方法（「持込み型」アプローチ）を検討してきました。自動車メーカーの IVIテクノロジに向けた歩みはゆっくりしたものですが、一方で GENIVI Allianceのようなコンソーシアムの取り組みには目を見張るものがあります。最近では、世界的な大手自動車 OEM各社が車載システムとスマートフォンを接続するために CCCが策定したプロトコルへの準拠を進めています。

ほとんどの自動車メーカーは、独自のアプリケーション・フレームワークを構築することが最善策だと考えているといっても過言ではないでしょう。人々が

夢中になっているスマートフォンと同じ機能や使いやすさのほとんどは自動車内で再現することが可能です。さらに、安全性と全体的なユーザ・エクスペリエンスを考えると、包括的な IVIシステムのフレームワークを目指すべきです。

IVIシステム開発アプローチの標準化が進むまでの間は、2つの方法を組み合わせたハイブリッドなアプローチがお勧めです。つまり、独自のアプリケーション・フレームワークの開発をベースにしたテクノロジを検討する一方で、MirrorLinkや HTML5といったテクノロジもなんらかの形で取り入れていくのが良いでしょう。本稿で紹介したソリューションは、市場への製品投入までの時間を短縮するだけでなく、全体的なコストの削減にもつながります。もちろん、IVIシステムの製品開発段階でも高い効果を発揮するでしょう。

最終的には、アプリケーションのプロビジョニングや配信にクラウドベースのアプローチが広く採用されるようになるだろうというのが筆者の意見です。そうなれば、ネットワークへの物理的な接続方式はそれぞれ異なっても（モバイル端末、オンボード通信モジュールなど）、工場でインストールする IVIシステムのモジュールを必要に応じてアップデートすれば良いので、比較的簡易なもので十分なのです。

車載 IVIシステムの一部であるデジタル表示のダッシュボード


本　　社〒140-0001 東京都品川区北品川 4 丁目 7 番 35 号御殿山トラストタワー電話（03）5488-3030 （営業代表）

大阪支店〒532-0004 大阪府大阪市淀川区西宮原 2 丁目 1 番 3 号 SORA 新大阪 21電話（06）6399-9521

名古屋支店〒460-0008 愛知県名古屋市中区栄 4 丁目 2 番 29 号名古屋広小路プレイス電話（052）249-2101

URL http://www.mentorg.co.jp

Copyright © 2014 Mentor Graphics Corporation. All rights reserved.Mentor GraphicsはMentor Graphics Corporationの登録商標です。その他記載されている製品名および会社名は各社の商標または登録商標です。Android は、Google Inc. の登録商標です。この商標の使用は Google Permissions を条件としています。登録商標 Linux は、全世界における商標保持者 Linus Torvalds 氏から排他的ライセンスを受けている LMI（Linux Mark Institute）からの許諾により使用しています。この文書にはメンター・グラフィックスの専有情報が含まれており、その一部または全体のコピーは、元の受領者が社内の業務目的に利用する場合にのみ可能です。この文書を受領されるにあたり、受領者はこの情報の不正な利用を防ぐあらゆる合理的な努力をされることに同意されるものとします。本文献は、「Challenges in Automotive Connectivity: Devices, Technologies, and the Connected Car」を日本語訳したものです。

w w w . m e n t o r g . c o . j p最新の製品情報については、メンター・グラフィックスのウェブサイトから :

MGJ 14-01

参考文献1. http://www.today.com/news/police-admit-theyre-stumped-mystery-car-thefts-6C10169993#

2. http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/

3. http://www.carsnewsweek.com/2011-10-toyota-first-to-market-with-mirrorlink-functionality-in-iq.html

4. http://www.wired.com/autopia/2012/06/my-link-spark/

5. http://www.crutchfield.com/learn/mirrorlink-and-your-car-stereo.html?showAll=N

6. http://techcrunch.com/2010/07/13/ios-4s-hidden-ipod-out-feature-brings-iphone-support-to-your-car-without-the-messy-third-party-ui/

7. http://en.wikipedia.org/wiki/IPhone_5

8. http://www.wired.com/autopia/2013/04/siri-eyes-free-roadblock/

9. http://www.automotiveworld.com/news-releases/ford-extends-commitment-to-app-developers-by-contributing-applink-to-open-source-genivi-alliance/

10. http://autos.jdpower.com/content/press-release/ws4mUEA/2012-u-s-initial-quality-study.html

Documents

車載ネットワークの課題 デバイス、テクノロジ、コ …...車載ネットワークの課題: デバイス、テクノロジ、コネクテッドカーを考える

車載ネットワークの課題デバイス、テクノロジ、コ …...車載ネットワークの課題: デバイス、テクノロジ、コネクテッドカーを考える