GigE Vision とは、イーサネット経由で、産業用カメラのコントロールや撮像した映像 信号をパソコンなどに伝送するためのプロトコルで、2006 年 5 月にアメリカの産業用画像機器分野の標準化団体である AIA（Automated Imaging Association）により策定された。
GigE Vision に準拠しているカメラ、アプリケーションであれば、異なるベンダー間の製品においても相互接続できるため、ユーザは様々な選択肢の中から製品を選択することができる。また、GigE Vision は名前のとおり、ギガビットイーサネットでの伝送（1Gbps）が可能であるほか、イーサネットの技術を基にしているため、イーサネットの利点をそのまま 引き継いでいる。
• 100m の長距離伝送が可能。スイッチングハブ接続でさらに延長することも可能。
• PC に標準搭載の LAN ポートに接続可能。専用の画像入力ボードは必要なし。
• 広く普及している安価なイーサネット用のコンポーネントを使用可能（LAN カード、LAN ケーブル、スイッチングハブ等）。
• ネットワーク接続によりフレキシブルなシステム構成が可能（1対1、1対N、N対N 接続など）。
本稿では、この GigE Vision の規格について説明する。
1. GigE Visionシステムの構成
GigE Visionでは、ネットワークに様々な機器が接続されることを考慮し、システムを構成するコンポーネントがクラス分けされ、ストリーミングデータ（映像データ）を取り扱わないデバイスも共通のプロトコルで制御可能となっている。図1にGigE Visionのシステム構成図を示す。
図1 GigE Visionのシステム構成
コンポーネントのクラス分けは以下のとおりである。
• Transmitter：ストリーミングデータを送信することができるデバイス。カメラなどがこれにあたる。
• Receiver：ストリーミングデータを受信することができるデバイス。映像データを画面に表示させるPC（アプリケーション）や、HDMI信号に変換して出力するHDMIコンバータなどがこれにあたる。
• Transceiver：ストリーミングデータを受信することができ、かつ送信もできるデバイス。画像処理装置などがこれにあたる。
• Peripheral：ストリーミングデータの送受信は行わないが、コントロールにGigE Visionのプロトコルを使用するデバイス。ストロボコントローラなどがこれにあたる。
2. GigE Visionプロトコル
2.1 IPアドレスの取得と、デバイスの列挙
ネットワーク上に接続されたデバイスは、まず、IPアドレスを取得する必要がある。また、ホストは通信するべきGigE Visionデバイスをネットワーク上から探す必要がある。GigE Visionでは、これらの動作をデバイスディスカバリとして規定している。
2.1.1 IPアドレスの取得
デバイスはネットワークに接続されると、自身に固定のIPアドレスが割り当てられていないか確認する。固定IPアドレスが割り当てられている際は、固定IPアドレスを適用する。固定IPアドレスが使用できない場合は、次にDHCPサーバよりアドレス取得を試みる。DHCPサーバが見つからない場合は、最終的にLLA（Link-Local Address）にてIPアドレスを取得する（図2）。
図 2 IPアドレスの取得フロー
2.1.2 デバイスの列挙
ホストはネットワーク上のGigE Visionデバイスを検出するために、Device Discoveryコマンドを発行する。このDevice Discoveryコマンドに対して、有効な応答を返してきたデバイスをGigE Visionデバイスとして認識する。
Device Discoveryコマンドは後述のGVCPというプロトコルを用いる。 ネットワーク上のデバイス接続は動的に変化する可能性があるため、GigE Visionではデバイスの着脱を次のように検出することとしている。
【デバイスの切断】
ホストは定期的に個々のGigE Visionデバイスに対し任意のGVCPコマンドを発行する。これに応答しなくなったデバイスをネットワーク上から存在しなくなったものと判断する。この定期的にコマンドが発行される動作をHeart Beatと呼んでいる。
【デバイスの接続】
デバイスのDHCPリクエストの検出をする方法と、Device Discoveryコマンドを定期的に発行する方法がある。前者は、DHCPサーバとGigE Visionのホストアプリケーションでハードインタフェイスウェアが異なる場合、ホストアプリケーションでの検出が困難である。
また、後者は、多くのGigE Visionデバイスがネットワーク上に存在した場合、Device Discoveryコマンドでネットワーク上のトラフィックが増大するという欠点がある。このことから、実際の実装方法はベンダーに委ねられている。
2.2 チャンネル
GigE Visionでは、チャンネルという仮想のリンクを用いて、デバイスの制御や映像データなどのストリームデータの送受信を行う。具体的には、チャンネルごとに異なるUDPポート番号を割り当てる。これにより、複数のストリームデータを取り扱うアプリケーションにおいても、データをポート番号により振り分けることが可能になっている（図3）。
図 3 チャンネルの概念図
下記の3種類のチャンネルが定義されている。
• Control channel：コントロールチャンネルは、デバイスの制御に使用する。プロトコルはGVCPを使用。複数のアプリケーションからひとつのデバイスが制御されると、デバイスの状態とアプリケーションの状態に不整合が起きて問題となることがあるため、コントロールチャンネルには制御権が用意されている。
デバイスに対しフル制御ができるのは1つのアプリケーションだけである（Primary control channel）。その他のアプリケーションは、デバイスの 状態を見ることしかできない（Secondary control channel）。
• Stream channel：ストリームチャンネルは、ストリームデータの送受信に使用する。プロトコルはGVSPを使用。GigE Visionのシステム構成にて示したように、ストリームチャンネルをもたないデバイスも存在する。
• Message channel：メッセージチャンネルは、デバイスからアプリケーションに通知を行う場合に使用する。たとえば、カメラが外部トリガを受け取ったことをアプリケーションに通知する際などに使用される。プロトコルはGVCPを使用。メッセージチャンネルも必要がなければもつ必要はない。
2.3 プロトコル階層
GigE Visionでは、GVCP（GigE Vision control protocol）/GVSP（GigE Vision streaming proto-col）という2種類のプロトコルを定義している。GVCP/GVSPはUDPの上位に位置するアプリケーション層のプロトコルである（図4）。
図 4 プロトコル階層
2.4 GVCP
GVCPでは、GigE Visionデバイスの制御を行うためのコマンド、およびパケット構造が定義されている。GigE Visionデバイスは、内部に仮想のアドレス空間を用意し、そのアドレス空間に各機能の制御を行うレジスタを配置する。アプリケーションは、そのレジスタに対し値を読み書きするという方式でデバイスを制御する。
たとえば、露光時間を制御するレジスタがアドレス0xA000番地に配置されており、露光時間の設定をus単位で設定するカメラの場合、カメラの露光時間を10usとするためには、0xA000番地に10を書き込むといった動作になる（図5）。
図 5 デバイスの制御方法
ここで、GigE Visionデバイスを制御するアプリケーションは、各レジスタが、どのアドレスに配置されていて、どのような値を取りうるかなどの情報をGenICamというアプリケーションインタフェイスを提供する規格に基づいたXML形式のファイルより取得することになっている。
XMLファイルは、デバイスの内部メモリからGVCP経由で読み取るか、もしくは、Webサイトやローカルディスク上からロードする。 GenICam規格の詳細については、本稿では割愛するが、詳しくは、GenICam の規格策定団体である EMVA（European Machine Vision association）のホームページ（http://www.emva.org）を見ていただきたい。
2.5 Bootstrap Registers
GVCPの項で、デバイスの制御方法について示したが、GigE Visionではカメラの露光時間やゲインの制御など、デバイスの機能に関するレジスタはベンダー固有の機能という位置づけで、アドレスは任意に割り付けることができる（それらをXMLファイルに記述することになる）。
一方で、GigE Visionデバイスがもつべき共通の情報はBootstrap Registersとして用意する。Bootstrap Registersのアドレス割り付けは規格により定められている。Bootstrap Registersには、デバイスのMACアドレス、IPアドレス、サブネットマスク、デフォルトゲートウェイなどネットワークに関する情報や、製品情報、XMLファイルの保存先などの情報をもつ。
Bootstrap Registersはアドレス0x0000から配置され、ベンダー固有のレジスタは0xA000以降に配置することになっている（図6）。
図 6 アドレス空間
2.6 GVSP
GVSPでは、ストリームデータのパケット構造が定義されている。 ストリームデータとして、映像データや、それに付随するデータ、測定情報などを送ることができる。 パケットは3パケット構造となっている。
• Data Leader：ストリームデータとして最初に送るパケット。これから送るData Payloadの情報を送る。
• Data Payload：Data Leaderに続いて送る。実際の映像データなど、ストリームデータの本体を送る。送信するデータ量が多い場合は、複数パケットに分けて送信する。
• Data Trailer：ストリームデータの最後に送る。
イーサネットにおいて、1つのパケットで送れるフレーム長は最大で1,500Byteと規定されている。しかし、映像データのように大量のデータを送る場合、1,500Byteずつデータを送っていては、フレームヘッダのオーバーヘッドやインターフレームギャップ（次のフレームを送信する前に96bit分の時間待たなければならないイーサネットの規則）により、伝送効率が低下してしまう。
そこで、伝送効率を向上させる有効な方法としてジャンボフレームを使用することが挙げられる。ジャンボフレームを使用することにより、最大8kByteから16kByteまでのデータが1つのパケットで送ることができるようになる。
ただし、ジャンボフレームはオプション扱いであり最大フレーム長もベンダーによって異なる。かつ100Base-Tではサポートされていないため、複雑なネットワークを構成する場合は、設定したジャンボフレームのパケットの通信ができるかどうかの確認が必要である（図7）。
図 7 ジャンボフレーム使用による伝送効率の向上
2.7 通信の信頼性とエラーリカバリ
GigE Visionはトランスポート層のプロトコルにUDPを使用しているため、TCPを使用した場合に比べ高速な通信が可能だが、通信エラー発生時の再送制御がないため、通信の信頼性という点では劣る。
GigE Visionでは、通信の信頼性向上のために、アプリケーション層のGVCP/GVSPにエラーリカバリを実装している。GVCPでは各コマンドに対しリクエストIDを付加してハンドシェークを行うことで、通信の信頼性を向上させている。
ハンドシェークがタイムアウトした場合は、コマンドの再送を行う。GVSPでも同様に各パケットにIDを付加する。アプリケーションはパケットの取りこぼしを検出したら、デバイスに対しパケットの再送要求をすることができる。ただし、GVSPの再送要求に応えるためにはデバイス側に充分なバッファを用意する必要があるため、GVSPの再送機能の実装は任意となっている（図8、9）。
図 8 GVCPでのエラーリカバリ
図 9 GVSPでのエラーリカバリ
3. GigE Vision の今後の展望
2011年9月現在のGigE Visionのバージョンは1.2である。規格策定団体のAIAでは、GigE Visionの機能をさらに拡張したGigE Visionバージョン2.0を検討している。GigE Visionバージョン2.0で追加される主な仕様を以下に記す。
• 10ギガビットイーサネット対応：GigE Visionは物理層に依存しないプロトコルレイヤーでの規格であるため、これまでのバージョンにおいても、10ギガビットイーサネットへの対応は可能だが、バージョン2.0で、10ギガビットイーサネット対応であることが明確になる。
• リンクアグリゲーション：複数のリンクを仮想的に1つのリンクとしてみなし、トータルの伝送速度を向上させる。たとえば、ギガビットイーサネットを4ポートもつカメラは4リンクを使用して4Gbpsの伝送が可能になる。
• 圧縮画像の取り扱い：ストリームデータのペイロードタイプに圧縮画像のフォーマット（JPEG、JPEG2000、H.264）が追加される。
• GVSPの1パケット化：これまで3パケット構造であったGVSPのストリームデータが1パケットで送れるAll-in Transmission Modeが追加される。これにより、さらなる伝送効率の向上が期待できる。
4. GigE Vision 規格の入手方法
以上、GigE Vision規格の概要について説明したが、正規のGigE Vision規格書は、規格のオーナーであるAIAのホームページ（http://www.machinevisiononline.org）より購入することができる。AIAに加入しているメンバーは$150USD。AIAに加入していないメンバーは$750USDである（2011年9月現在）。
コメントを残す