Qorivva MPC5604E

もう1つ発表されたQorivvaの新製品がこちら。この記事にもある通り、車載向けカメラをEthernetを使って実現するためのソリューションである(Photo34)。MPC5604Eはカメラごとに置かれ、カメラからの入力画像をMotion JPEGにエンコードし、これをEthernet経由で送り出すという仕組みである。

Photo34:実際に実装となると、CCDあるいはCMOSベースのカメラモジュールと、このMPC5604Eが一体化したものが車体内に最大5カ所置かれ、これらがEthernetで繋がる形になると思われる。

受け取ったほうは、最大5つのカメラからの映像を元にBird's Viewを再構成して表示する(Photo35)という訳だ。ここで特徴的なのは、車内にもかかわらず配線にEthernetを使うという話であるが(Photo36)、Lehmann氏曰く「このシステムはBMW及びDaimlerが既に実現しているもので、当社は彼らと共にこれを実装した」という返事が返ってきた。MPC5604Eそのものはそれほど性能は高くなく、JPEG Video Encoderを搭載してもまだ、1台のカメラ映像のエンコードが精一杯だという(Photo37)。Technical Labでは動作デモも行われていた。

Photo35:いわゆるBird's Eye映像。この合成処理はPowerPCでは性能的に無理であり、i.MXあたりを使って行うことになると思われる。もっとも今はこうしたBird's Viewが付加価値扱いされているからという話で、もしこれが必須になった場合は例えば専用の画像変形/合成アクセラレータを搭載したPowerPCベースのチップとかが登場するかもしれない。

Photo36:内部構成例。今はまだPilot Project扱いである。このあたりは後述。

Photo37:内部構造。Lin/CANはそもそもカメラのOn/Offといった制御に使われるもので、メインはEthernetということになる。処理の大半はMPEG video encoderで行われることもあってか、CPUコアの性能はそれほどではない(VLEを搭載しているあたりがちょっと面白いが)。

さて、なぜにMJPEGという話だが、このシステムの場合はフレームごとに画像を展開し、カメラ位置に合わせて変形、最後に全カメラの映像を合成して出力ということになるから、MPEGを始めとする諸々の動画フォーマットだと伝送サイズこそ減るものの、フレームごと展開に余分な時間(Iフレームはともかく、BフレームとかPフレームだと、前後のIフレームの映像が送られてくるまで映像が作れない)やコスト(デコード処理に必要となるCPU性能とメモリ量は、MJPEGよりはるかに大きい)が必要になるので、システム全体で考えた場合はMJPEGの方が効果的である。データ量の多さは、転送速度を上げれば解決できる問題でもあるからだ。

Photo38:右がMPC5604Eベースのカメラモジュール、左がi.MXベースの表示モジュール(これはデモ用にとりあえず作ったものだとか)で、間をEthernetで繋いでいるのが判る。

Photo39:MJPEGで撮影した画像。色差成分がやや落ちているとか、スムーズというにはちょっとかくかくしているといった気もするが、Bird's Viewを構成するには十分だろう。右端に筆者がちょっとだけ写り込んでいる。

消費電力やコストの問題もそうで、動画フォーマットにするとどうしても高いCPU性能が必要だから消費電力もあがり、コストもこれに合わせて上がることになる。原価を抑えるためには、なるべくカメラ側の処理は簡単な方が良い。

もう1つの問題はEthernetを使うことの是非であるが、これについてはDaimlerによる"Ethernet for Vehicle-internal Communication"というTechnical Sessionで細かな説明があった(Photo40)ので、が開催されたので、こちらの内容をかいつまんでご紹介したい。

Photo40:説明を行ったDaimlerのThilo Streichert博士

短期的なEthernetベースのメリットは、安価に利用できることである(Photo41)。既存のLVDS方式だとシールド式の4対のケーブルが必要だが、Ethernetの場合は10BASE-Tでよければ、2対のアンシールドケーブルで足りる。

Photo41:Ethernetを使う場合、MJPEGのエンコード/デコードの分処理は増えるが、コスト的には既存のLVDSベースよりも安価に仕上がる可能性がある。

もちろん消費電力そのものはやや増えるが(Photo42)、カメラあたりの消費電力増分が概ね500mW以内に収められるとしており、一方ケーブルの重さはLVDSの34g/mから16g/mに節約できるため、こちらの効果が大きいとみなされたわけだ。車載というとノイズ耐性が気になるところだが、もともとTwisted Pairということもあり、外部からのノイズに関してはそれほど問題は無かった、という説明だった。ただ、では何も問題はないのか? というとそういう話でもなく、こちらには色々な要求がまとめられている(Photo43)。2012年頃までの車載用カメラにはこれで足りるが、その先はもっと要求が高まるだろう、という事を示唆している。

Photo42:Summaryにもあるが、消費電力が増えるのはカメラの稼働中のみであり、一方配線の重さは常にかかってくる。だからメートルあたり18gの節約が実現できれば、稼働中に若干消費電力が増えても、トータルとしては(重量節約による)エネルギー削減が可能、という訳だ。

Photo43:その意味では、MPC5604Eは「現在の」要求を満たしてはいるが、ここに上げられている「Encode/Decodeを10ms以内」「カラー深度を12bit化」「将来はH.264のサポートが必要」といった項目が今後の課題になるわけだ。

ところでEthernetを使って通信と簡単に言うものの、既存のIPベースの通信は伝達保障などが行われないし、到着時間も不貞である。このあたりを解決するためにIEEE1722を使うことを考慮しているという(Photo44)。

Photo44:Photo43に出てきたAVBの中身がこちら。ただ実装するためには、少なくともMCU側もIEEE1722を半分ハードウェア的に実装するようにしないとコストなどの面からは難しいだろう。

IEEE1722はIEEE802.1 AVB(Audio/Video Bridging)のL2用プロトコルとして標準化されたもので、本来は名前の通りオーディオ/映像機器をEthernet経由で接続する際に必要となる機能をまとめたプロトコルであるが、ここのTime SyncronizationやTraffic Shapingは今回のような車載カメラ接続にも役立つという話である。これに関する調査は既に同社も行っており、例えば温度変化によるTime Syncronizationのテスト結果なども示された(Photo45)。またEthernet経由でのWakeupをどうするのか、といったことも今後の課題になるようだ。

Photo45:2つの恒温槽に個別に機器をセットて通信させながら、恒温槽の温度を-40℃～85℃の範囲で、2℃/分の頻度で変化させた(Slow temperature change)場合と、5秒で-40℃～85℃まで変化させた(Shock test)場合でのジッターを測定するというもので、これはShock Testの結果。一時的に変動する場合はあるが、概ね温度にかかわらず一定のジッターに収まる、というのがここでの結論である。

そんなわけで、今後更に広く普及するかどうかという観点ではまだまだ問題は色々あるのだろうが、直近で利用できる技術としてEthernetは既に(限られつつも)普及期に入ったという訳で、ここに向けた製品がこのMPC5604Eという訳だ。

Photo46:どの方式も一長一短があるため、今のところこれといった決め手はないそうな。配線節約という観点ではPower over EthernetやEnergy Detectionとなるが、今度は配線の安全性(何かの理由で被覆が剥がれてボディに接触するとそこでショートする羽目になる)の問題もあるわけで、このあたりは簡単に答えが出ないだろう。