Turing Advent Calendar 2023の9日目の記事です。
本日は組込みソフトウェアエンジニアのやべ(@ken_ya_be)が担当です。今年の10月からTuringに在籍し、直近開発している車両の自動運転まわりのところをやっています。何かしらやってみた系の内容を書くのが好きなのですが、在籍期間短くてネタがなかったので、今回は調べもの記事を書いてみました。
はじめに
これを読むとGMSLカメラのことがなんとなくわかるようになる。いろいろな規格が絡んできて深みにハマりがちなので、極力触りだけになるよう努めます。とりあえずざっと読めば、GMSLカメラの仕様を見て「ふむふむなるほど」くらいは言えるようになってるとうれしいです。
なぜGMSLカメラが必要なのか
話を始める前に、GMSLカメラというものがなぜ必要になってきているのか、まずはその背景から簡単に説明します。
自動車分野においてカメラの機能というのはそこまで目新しいものではなく、バックモニターなどでも活用されてきましたが、あくまで補助的なものでした。しかし、近年はADASやインフォテイメントシステム、更には自動運転といった技術分野において、カメラの用途は幅広くなっています。単純にカメラ自体の性能要求が高くなっているだけではなく、必要となるカメラの数も年々増加傾向にあります。自動運転のレベル3を達成するためには、10台以上のカメラが必要になるという話もあります。当然Turingにおいても、大量のカメラをコントロールする能力は不可欠です。
そんな中で、車載用途に耐えられる環境性能や耐久性などを維持しつつ、大量のリンク数を達成するための規格として、GMSLなどが登場してきました。
GMSL規格の概要
GMSLは「Gigabit Multimedia Serial Link」の略称で、Maxim Integrated（以下Maxim）社が開発した技術です。Maxim社は様々なIC製品を開発している会社で、現在はAnalog Devices（以下ADI）社の子会社です。販売している製品の型名には「MAX」がプレフィックスとして付いており、回路設計・組込み関係の方なら目にすることが多いかと思います。
2000年代から徐々に需要が高まってきた、自動車内でのデジタルビデオ信号の堅牢な伝送に対応するための規格ですが、似たような要求は自動車以外での分野でも数多くあるため、利用ユースケースは幅広くなっているようです。
SerDes
GMSLならびに類似の規格はSerDesと呼ばれる技術上で成立しているので、まずはここから説明します。
SerDesとはSerializer/Deserializerの略で、名前の通り「シリアライザ」と「デシリアライザ」の２つの回路が組み合わさったものを指します。なんらかの並列データをシリアライザ側でシリアルデータに変換（PISO）し、それを受け取ったデシリアライザ側でもとの並列データに復元（SIPO）します。
こうすることで回路上では複数の信号バスが必要だったデータがより少ないバスで転送できるようになるため、今回の主題であるGMSLカメラなど物理的に距離があるケースや高速伝送で活躍します。
GMSLのシリアルデータ構造
GMSLはSerDesですので、中間のデータはシリアルデータになっています。GMSL2の場合は、おおよそ以下のようなパケット構造になっています。ビデオやオーディオ、制御情報を含んだデータパケットと、データ特定のためのヘッダーなどで構成されています。
シリアルデータの例
GMSL1の時代は固定フレームで、利用の有無に関わらず常に全データ種別を送っていたようですが、現在は必要なものだけを詰めて送っており、無駄がない構成になっています。帯域幅の空いている領域には任意のデータを入れることもできるそうです。
制御信号の取り扱い
GMSLでは映像信号とともに各種制御信号も扱えることが特徴の一つです。これによりI2C通信などを使ってカメラ側のレジスタ設定などが行えるわけですが、映像信号とは逆方向の伝送が必要となります。例として、MAX96705およびMAX96706の仕様を見てみます。
MAX96705 Block Diagram
MAX96706 Block Diagram
※ADI社のHPより抜粋
これを見ると、シリアライザであるMAX96705のほうに信号のRX回路があり「REVERSE CONTROL CHANNEL」として処理が定義されています。デシリアライザであるMAX96706の方は、同様のチャンネルがTX回路を通って送られています。このチャネルを介して、UARTおよびI2Cが使えるようになっているのが見て取れます
GMSL SerDesの組み合わせについて
先ほど例に上げたMAX96706もそうですが、GMSLという同一の規格に沿っているのであれば任意の組み合わせで利用することが可能です。下位互換性も保つようになっているため、GMSL2とGMSL1を混在して利用することも可能ですが、一定の機能制限がかかることはあります。また、データシートを見ていると対象として想定している組み合わせはある（連番になっていて、奇数側がシリアライザ）ようです。
MAX96706のデータシートより抜粋
おそらくリファレンスや後述するドライバなどの問題を考えると、新規開発の場合はその組み合わせを使うのが良さそうですが、利用するカメラ（シリアライザ）が古い場合でも最新のデシアライザを採用することに問題はありません。
GMSL規格の進化
GMSL2では、GMSL1からデータ・レートの倍増に加えて、ASIL-Bへの対応やトンネリング機能やエラーレートの改善など、車載用途での様々な性能向上が行われました。現在GMSLの最新規格はGMSL3となっており、こちらはデータ・レートが12Gbpsまで向上しています。GMSL3はGMSL2と基本構造は同じですが、信号伝送方式にPAM4（Pulse Amplitude Modulation 4）を採用することで、データレートが倍になりました。GMSL1およびGMSL2では、NRZが採用されています。
ADASの機能向上に伴い、必要となるカメラの性能や台数は年々増加しているため、それに合わせる形でデータ・レートは増加しています。
ADI社のHPより抜粋
次の世代であるGMSL4についても検討は開始されているようです。データ・レートの向上は当然ながら、近年注目を集めているサイバーセキュリティへの対応などが盛り込まれるようですが、詳細は不明です。今後の動向に注目しましょう。
類似規格
GMSLに似た規格として、FPD-Linkというものがあります。「Flat Panel Display Link」の略称で、現在FPD-LinkⅢという規格が最新です。開発したのはNational Semiconductor社で、こちらは現在はTexas Instruments社に買収されています。
ソニーセミコンダクタソリューションズ株式会社が開発したGVIFというものもあります。「Gigabit Video InterFace」の略だそうです。
高速長距離伝送という同じ目標を達成するために各ベンダーが独自の規格を出しているという状況ですので、将来的にどこがデファクトスタンダードになるのかは様子を見る他ありません。
また、Automotive SerDes Alliance（ASA）という規格団体も存在します。
ADI社などもメンバー企業として名を連ねているため、将来的にはこの規格に沿って自由にSerDesが選べるようになるのかもしれません。
GMSLカメラとは
ここまで見てきたように、GMSLは画像伝送用の規格であるため、厳密にはカメラと紐付いているわけではありません。では、GMSLカメラとはどのようなものを指すのでしょうか？
大まかに言えば、このような形でセンサーデータをGMSL経由でホストに伝送するものを「GMSLカメラ」と呼んでいます。センサーデータそのものの取り扱いはGMSLの枠組みの外にあるため、別の仕様・規格が関係します。冒頭で挙げたMAX96706など、GMSLのみで直接カメラのデータを伝送している製品もありますが、最近の製品はMIPI CSI-2規格を利用することが多いようです。
MIPI規格
ウェブで検索すると枕詞に「知名度が低い」が付く傾向にありますが、組込み向けのカメラを触る人はわりと目にするのが「Mobile Industry Processor Interface」、MIPI規格です。ラズパイのカメラもMIPIインターフェースです。
MIPIはGMSLと違い特定のメーカーにより開発されたものではなく、MIPI Allianceという標準化団体によって作成されている規格です。
その中で、CSI-2と呼ばれるものがカメラ用のシリアルインターフェース規格で、MIPI Allianceのなかのカメラワーキンググループによって作成されています。このワーキンググループにはonsemiやSonyといった企業のメンバーが名を連ねています。CSI-2は「Camera Serial Interface 2」の略称で、静止画もしくは動画をカメラのイメージセンサーからホストとなるプロセッサに高速で転送するためのプロトコルです。
GMSLとの関連を見るために、ADI社のGMSLラインナップを見てみましょう。
GMSL製品のセレクタ
Intefaceの項目に注目してみると、CSI-2やC-PHYといった単語が並んでいます。ここを見ることでMIPIに対応しているIC製品であるかがわかります。一例として、MAX96714の仕様を見てみます。
MAX96714の仕様より抜粋
いくつか用語が出てきましたので、それぞれ簡単に説明します。
データレーン
MIPI CSI-2は最大で4レーンの信号入力を行うことができます。MIPI規格ではシリアル差動信号による伝送が行われますが、この差動信号の信号線ペアをレーンと呼んでいます。1レーンあたりの伝送速度がいくら、という計算でカメラの解像度によって必要とするレーン数が決まります。例えばMAX96714の仕様だと、1レーンあたりデータの伝送速度が2.5Gbpsとなっています。
MAX96714の仕様には「1x4レーン」という記述がありますが、これは1ポートで4レーンを扱えることを意味しています。仮に「2x4レーン」という仕様であった場合、ポートごとに4レーンで、2ポートが扱えます。
MAX96714 Functional Diagramsより抜粋
気になるのは、これで実際に何台カメラを接続できるの？という点だと思います。レーン数は1つのセンサーに対して最大でいくつまでのデータレーンを使えるのか、ということを示しているため、接続できるカメラの数はポート数に依存します。つまり「1x4」の仕様の場合は1台のカメラしか接続できませんし、「4x2」であれば4台のカメラまで単一のデシアライザで接続することが可能です。
仮想チャネル
MIPI規格では、仮想チャネルというものが定義されています。MAX96714だと16個までサポートしていると記載されています。
これは単一のデータレーン上に仮想的なチャネルを設定し、複数のセンサーデータを同時に伝送する機能です。例えば、圧縮率の異なる画像を同時に送信するケースや、HDR合成のために露光の異なる複数の画像フレーム（多重露光）を利用するケースなどに利用されます。
MIPI PHY
MIPIには物理層の規格として、C-PHY、D-PHY、A-PHYなどがあります。
- C-PHY（Clock-Aware PHY）
- MIPI CSI-2などのデジタル画像やデータの伝送に利用
- クロックとデータを統合して伝送するため、クロックレーン不要でデータ伝送できる
- D-PHY（Differential PHY）
- MIPI CSI-2などのデジタル画像やデータの伝送に利用
- 差動伝送方式なため、整合性が高く消費電力が低い
- A-PHY（Automotive PHY）
- 車載向けに設計されたSerDesの物理層仕様
- 伝送距離が長く、自動車向けに信頼性も高めている
FAKRA規格
多くの場合、GMSLカメラには同軸ケーブル用のコネクタが付いていますが、おそらくFAKRA規格に沿っていると思います。FAKRAというのは、自動車向けに設計された高周波同軸コネクタです。
FAKRAには11種類のキーコードがあり、それぞれに色分けされており用途も決められています。そのうちウォーターブルーのキーコードZがニュートラル用途となっており、GMSLカメラについてはこちらが使われています。
手元にあったケーブルの写真
GMSLカメラの場合、カメラおよびコンピュータ側にFakraのプラグがついているケースが多いため、ケーブルについては、例えばAmphenol RF社のこちらのケーブルなどを利用します。
なお、GMSLはSTP（Shielded Twisted Pair,差動通信）にも対応していますが、ケーブルコストなどの観点からなのか、もっぱら同軸ケーブルのものしか見かけません。
USBカメラとは何が違うの？
USBカメラは非常に便利なものです。とりあえず買ってきたらどんなコンピュータに接続してもすぐに使えます。これは何故でしょうか？
リモートワークしていたときに活躍した2000円くらいのWebカメラ
答えは、USBにはUSB Video Class、一般的にUVCと言われる規格が定められているからです。USBにはデバイスの情報を管理するディスクリプタというデータが規定されていますが、ここの中にインターフェイスを指定する値があり、0x0Eが動画用になっています。
https://www.usb.org/defined-class-codes より抜粋
これに則った仕様でカメラを開発することで専用のドライバなしでコンピュータに映像を出力することができます。ある程度相性の問題はあるにせよ繋げば使えるわけですから、コンピュータを開発する側からすると非常に強力です。
とはいえUSB自体の限界もあります。例えば、帯域幅やケーブル長の制約、ノイズの問題などが挙げられます。車載などGMSLが選択されるシビアな環境において、USBが使えないわけではないですが利用シーンは限られます。
Linuxでの使い方
ここまででわかったように、GMSLカメラはUSBカメラと異なり、挿せば使えるような類のものではありません。カメラのデータを受けるホスト側の機器に、何らかの準備が必要になります。
最も簡単な使い方
一番簡単に使う方法は、GMSLカメラのメーカーが開発しているUSB変換基板を利用することです。これであればUVCに乗っかることができるため、すぐに映像を確認することができます。例えば、Leopard Imaging社のLI-USB30-AR0231-GMSLなどはこの例に当たります。
LI-USB30-AR0231-GMSLのデータシートより抜粋
この方法は本質的にGMSLを利用する意味があまりないため、ターゲットのカメラがどのような画を出力するのかを確認する用途に使うことが多いかと思います。
Evaluation Boardを利用する
GMSLカメラを販売しているメーカーは、Deserializerが実装されている基板をカメラとセットでEvaluation Board（以下開発キット）として販売しているケースがあります。自身が利用している環境が開発キットの対象になっていることが条件にはなりますが、この方法であればGMSLの恩恵をフルに受けつつ映像の確認をすることができます。例えば、e-con Systems社のNileCAM21_CUOAGXなどはこの例に当たります。
e-con Systems社のHPより抜粋
この製品の場合、Jetson AGX OrinないしはXavierの開発者キットに接続して利用することができます。ドライバコードも提供されるため、PoCなどで検討する用途でも使うことができます。
ドライバおよびデバイスツリーを実装する
カメラを購入した場合、メーカーが保証している環境向けのドライバコードをもらうことができます。前述のEvaluation Board向けのものがそのまま渡されることもあります。
自分たちで開発した基板に何らかのデシアライザを実装する場合、運が良ければそのまま動きますが、動かない場合はそれらをリファレンスとしてカーネルドライバとデバイスツリーの開発が発生します。本格的にカメラメーカーとして開発を行う場合は、イメージセンサやSerDesのデータシートを見ながら1から作り上げる形になるかと思います。
いくつか提供されたカーネルドライバを見てみましたが、SerDesが一体化したようなコードになっていることもありました。理想的にはシリアライザ、デシリアライザ、イメージセンサーのコードはそれぞれ分離し、デバイスツリーでうまくコントロールされ、必要であればカメラ用の実装が多少あるくらいがうれしいのですが、このあたりはまだ過渡期にあるように感じます。
まとめ
GMSLカメラと一口に言っても、いろいろな技術要素が絡んでおり、一言で表現するのはなかなか難しいものになっています。このカメラ使いたい！となったとしても、今の自分の環境で使えるのかどうかよくわからないこともあるかと思います。そういう疑問に対して、この記事が多少でも答える手助けになっていれば幸いです。
さいごに
Turingでは組込みソフトウェアのエンジニアを絶賛募集してます。
今回紹介したようなカメラを触ることもありますし、がっつりLinux OSの下回りやることもありますので、興味のある方いたらぜひご連絡ください！とりあえず話聞いてみたいという方は気軽に見学なんかもできますよ。
Discussion