HTML5プラットフォームを志向する「Tizen IVI」の特徴：Tizen IVI基礎解説（後編）（2/5 ページ）

Linuxベースの車載情報機器向けプラットフォームである「Tizen IVI」。前編では「Moblin for IVI」から始まり、Tizen IVIに至るまでの歴史と、Tizen IVIの開発に関わるさまざまな組織について紹介した。後編では、HTML5プラットフォームへの志向を強めるTizen IVIの特徴について解説する。

[高橋成人（ターボシステムズ），MONOist]

ミドルウェアのコンポーネント

　HTML5への積極的な姿勢はミドルウェアの構成からもうかがえる。

　ミドルウェアを解説する前にTizenのアーキテクチャについて解説しておこう。Tizenのベースとなるアーキテクチャは図1を参照していただきたい。一番下のレイヤーにはカーネルとドライバ、カーネルの上にはミドルウェアのcore層がある。そして、アプリケーションを作成するためのフレームワーク層があり、一番上のレイヤーはアプリケーション層となる。これはTizen mobileのアーキテクチャが基になっている。

図1　Tizenのアーキテクチャ（クリックで拡大）

　Tizen IVIでは、この基本アーキテクチャに以下のような変更が行われている。

• Tizen WRT（Web RunTime） on Waylandへの変更
• Automotive Message Brokerの追加
• WRT Vehicle API Pluginの追加
• Ghostclusterの追加
• Native Frameworkの削除
• dLeynaの追加

　ここからは、これら6つの変更点について詳しく説明する。

Tizen WRT on Wayland

　「Tizen WRT on Wayland（以下、WRT）」は、「Tizen Web App」を動作するためのランタイムである。Tizen Web Appは、W3Cが定義した「Packaged Web Apps」に準拠したHTMLコンテンツで、WRTはHTMLコンテンツにシステムアプリの振る舞いをさせるHTMLレンダリングプログラムというわけだ。

　WRTのレンダリングエンジンは「WebkitEFL」、JavaScriptの評価器は「JavaScriptCore」を使用する。WRTはプラグインフレームワークを搭載しており、プラグインの追加によって「JavaScript API」を利用できるようになる。なお、HTMLからシステムやデバイスをたたく「Tizen Device API」は、「wrt-plugin-tizen」というプラグインで提供されている。

　Tizen mobileのWRTはXorgベースで動作しTizen IVIのWRTはWaylandベースで動作する。バックエンドは違うが、Tizen Web Appは同じ挙動をすることが保証されている。

Automotive Message Broker（amb）

　「Automotive message broker（amb）」は、車両データを抽象化するミドルウェアであり、車両データをアプリケーション層に引き渡すデーモン（常駐プログラム）でもある。

　図2はambのアーキテクチャである。入力プラグイン（ソースプラグイン）が車両データを受け取り、フォーマットに合わせたデータを中継役兼デーモンの「amb core」へ送信する。車両データを受信したamb coreは出力プラグイン（シンクプラグイン）にデータを発行し、出力プラグインを経由してアプリケーション層に車両データが届く。これが、車両データを車載情報機器のアプリケーション層まで伝播（でんぱ）する一連の流れとなっている。

図2 ambアーキテクチャ（クリックで拡大）

　車両データを受け取るハードウェア部から車載情報機器のアプリケーション層に車両データが届くまで冗長な流れになってしまうが、入出力をプラグイン化することで、プラットフォーム提供者は入力プラグインに、アプリケーション提供者は出力プラグインに開発を注力することができるようになる。また、車両データを出力する側とアプリケーション層の結合強度が疎結合になるという利点も生まれる。

　入力プラグインが車両データを取得する際には、カーネルや、CAN、OBD-II、ELM-327などの車載ネットワークを経由することになる。入力プラグインを、それらの車載ネットワークに対応させることで、どんな車両データも取得可能になる。車載ネットワーク以外にも、ユーザーランドでランダムな入力をし続けるプラグインや、USBインタフェースのハンドルコントローラ経由でデータを取得するプラグインがサンプルとして入っている。

　出力プラグインからのデータ送信は、UNIXの「シグナル」やAndroidの「ブロードキャストインテント」といったプロセス間通信（IPC：InterProcess Communication）に似ている。どちらも非同期でメッセージを送信する方法であり、メッセージの送信者は特定の受信者を想定せずにメッセージ送信が可能だ。

　出力プラグインは「DBus」と「Websocket」という2つの実装方法が用意されている。DBusは、もともとはLinuxデスクトップPC向けのプロセス間通信のデーモンとして作られているが、今では「init」の代替の「systemd」やインプットメソッドフレームワークの「ibus」などで採用されており、Linuxのシステム全体のプロセス間通信用プロトコルとして利用されている。

　一方、Websocketは、HTTPプロトコルでrawデータをソケット通信するためのプロトコルだ。もともとはJavaScriptからソケット通信をするために考案されたプロトコルであるが、Tizen IVIではWebsocketをプロセス間通信として利用しようと試みている。システムのリソースとWeb Appとのデータのやりとりをシームレスにするための取り組みだ。

WRT Vehicle API Plugin

　「WRT Vehicle API Plugin」は、Tizen IVI 3.0に搭載される予定の機能だ。

　ambは、Websocket経由で車両データをやりとりできるので、Webアプリケーション側で車両データを受信することが容易になった（図3）。

図3　現状の車両データ取得の流れ（クリックで拡大）

　しかしながら、それはWebアプリケーション側で、Websocketの受信処理の管理や、受信したデータの変換の処理が必要なことを意味する。つまり、車両データを取得するWebアプリケーションを作成するには、Websocketの仕様に関する知識、データ受信の管理方法やデータの変換方法など各アプリケーションで異なる実装を行うためのノウハウが必要になるわけだ。もちろん、アプリケーションを作成する際の負担は大きくなる。

　WRT Vehicle API Pluginは、このアプリケーション作成における負担を減らすべく作成されている。

　ambの出力プラグインは、Webアプリケーションではなく、WRT Vehicle API Pluginに車両データを送信し、WRT Vehicle API Plugin側でデータ受信とWebアプリケーションにおけるイベント発生を管理する（図4）。アプリケーションの作成にWRT Vehicle API Pluginから提供されたAPIを利用すれば、Websocketとのやりとりやイベント管理から解放され、容易に開発を進められるようになる。

図4　将来的な車両データ取得の流れ（クリックで拡大）

　WRT Vehicle API Pluginが提供するAPIは、Vehicle Information APIという名称でW3Cによるドラフトも作成されている。