IEEE1394 規格

IEEE1394 とは

規格制定団体である1394 Trade Association(以下 1394TA)により制定され、1995 年に IEEE によって標準化(IEEE1394 ~1995)された汎用高速シリアルインタフェイスの規格である。

その後、電源制御など一部仕様を追加したIEEE1394a-2000(以下 IEEE1394.a)、3,200Mbps まで帯域を拡張しコネクタ および信号仕様を変更した IEEE1394b-2002(以下 IEEE1394.b)に仕様拡張される。規格の別の名称として、FireWire、i.Link、DV 端子などがある(i.Link および DV 端子は IEEE1394.a のみの呼称)。

AV 機器、車載等用途ごとの詳細規格は1394TA の各担当ワーキンググループにより制定され、産業用カメラ規格 Instrumentation and Industrial Digital Camera(以下IIDC)が Instrumentation and Industrial Control Working Group によって制定されている。IEEE1394 規格には多くの特徴があるが、産業用に関連するものを抜粋すると以下のとおりである。

• 最大 3.2Gbps の高速シリアル通信(2011年現在、1.6Gbps まで製品化されている)。
• 活線挿抜可能な小型コネクタ1つで高速通信、電源が接続可能。
• メタル接続によるケーブル長は最大 4.5m、ハブ等で 32 本までケーブルを延長可能
(最大144m)。

映像等のストリームデータ通信機能が充実しており、通信帯域が逼迫している環境においてもデータ欠落のない確実な映像出力が可能。映像等ストリームデータの受信は処理の殆どがハードウェアで行われるため、大容量データ受信でもホスト PC の負荷は非常に低い。1対 1、1対 N、N 対 N 接続が行なえ、バス帯域が許す限り同一バス上で複数台カメラの映像を取得することができる。

バス上はホスト PC、カメラを含む周辺機器間でコネクタ、通信仕様上の差がなく、コネクタを 2 つ以上備えたカメラの場合はディジーチェーン接続も可能。本項では、この IEEE1394 の規格について説明する。

1. IEEE1394システムの構成

1.1 バストポロジ
IEEE1394のバストポロジは、ハブを中心としたスター型ネットワークと、ディジーチェーンによるライン型ネットワークの両方を有したハイブリット型ネットワークとなっている。IEEE1394バス上、接続されている機器(以下ノード)はホスト、周辺機器の差はなく、すべて対等である。同一バス上に複数のホストPCを接続することも許可されている。図1に、IEEE1394バスの構成例を示す。


図1 IEEE1394 バス構成例

1.2 ケーブルとコネクタ
IEEE1394では、次のケーブル接続が規格化されている。

• 近距離接続用メタルケーブル
一般的に、IEEE1394ケーブルとはこれを示す。3.2Gbpsで最大4.5mの電気信号による伝送が行える。

•長距離接続用メタルケーブル
Ethernet用カテゴリ5eケーブルを使用したものである。800Mbpsで最大100mの電気信号による伝送が行る。

• 光ファイバケーブル
プラスチックおよびガラス光ファイバを利用したものである。プラスチックの場合200Mbps、ガラスの場合1.6Gbpsで、どちらも最大100mの光信号による伝送が行える。

近距離接続用メタルケーブルの構成は図2のように、TPA+/-、TPB+/-のシールド付きツイストペア信号線2対と、VP/VGの電源線2本がある(電源サポートなしタイプの場合、VP/VGなし)。

なお、TPAとTPBは、ケーブル内部でクロスされる。 TPAとTPBの役割は、IEEE1394.aとIEEE1394.bで異なる。IEEE1394.aは、Data-Strobeモード(以下DSモード)と呼ばれる。これは半2重通信であり、データをTPBに、データとクロックの排他的論理和信号(Strobe信号)をTPAにそれぞれ割り振る。


図 2 IEEE1394ケーブルの構成

IEEE1394.bは、Betaモードと呼ばれる。データエンコード方式に、データとクロック両方を1対の信号線路に送信できる8b/10bを採用している。このためTPBに送信データ、TPAに受信データを割り振る全2重通信が実現されている。

DSモードとBetaモードは互換性がない。このため、DSモードのみ対応したDS-onlyポートと、Betaモードのみ対応したBeta-onlyポートに加えて、DSモードおよびBetaモードに両対応したBilingualポートが規格化されている(図3)。


図 3 IEEE1394のポート互換性

コネクタは、表1に示すとおり、ポート種別ごとに4種類のコネクタが規格化されている。 


表1

写真1は、IEEE1394.aで使用されている4ピンおよび6ピンコネクタケーブルである。4ピンコネクタはデジタルビデオカメラなどの小型機器に、6ピンコネクタはPCや外付けハードディスクなどの一般機器に多く利用されている。

写真2は、IEEE1394.bで使用されている9ピンコネクタケーブルである。コネクタはBeta-onlyとBilingualの2種類がある。これは、DSモードをサポートしていない機器がIEEE1394.aネットワークに接続されないようにするためである。

Bilingualコネクタは写真2のようにスリット部分が狭く、Beta-onlyコネクタの機器に物理的に刺さらないようになっている。またIEEE1394.bコネクタケーブルは、写真3のように産業用にネジロック機構が追加されたものも規格化されている。ネジロックを使用することにより、振動、衝撃耐性が大幅に増大する。

2. IEEE1394 バスのコンフィグレーション

図4は、バス動作が開始されてから定常動作に至るまでのバスコンフィグレーション動作を表す。


図 4 IEEE1394バスコンフィグレーション(抜粋)

2.1 バスリセット
バスの初期化のため、バスリセットが発生する。バスリセットは以下の条件においても発生する。
• ノードの接続が変更された(デバイスの追加、切断)。
• バス上で致命的なエラーが発生した(バスのデッドロック、不整合等)。
• ノードからバスリセット発行要求があった。

2.2 バスマネージャー決定
バス上のルートとなるバスマネージャーを決定する。始めに、各ノードは自分のポートが他のノードに接続されているか識別し、未接続のポートにoffとラベルを振る。

その結果、1つのポートしか接続されていないノードをリーフ・ノード、複数のポートが接続されているノードをブランチ・ノードと認識する。次に、リーフ・ノードは接続先デバイスにparent_notifyという通知を行い、これを受けたノードは応答としてchild_notifyを 返す。

parent_notifyを受信したノードがブランチ・ノードの場合、通知がないポートが1箇所になるまで待つ。その後残ったポートより、さらに次のノードへ通知を行う。parent_notifyをリーフ・ノードが受信した場合、もしくはブランチ・ノードのすべてのポートにparent_notifyが受信された場合、そのノードがバスマネージャーとなる(図5)。

通知を開始するタイミングは、各ノードで様々である。このため同一接続のバスにおいても、どのノードがバスマネージャーに割り当てられるかは不定となる。


図 5 IEEE1394 バスマネージャー決定

2.3 ノード列挙、物理ID決定
バスマネージャー決定後、バス上のノードを識別するために使用する物理IDを決定する。バスマネージャーは、最も優先順位が高いポート(ハードウェアで固定)に接続されたノードにバス権を貸与する。

貸与されたノードがリーフ・ノードの場合、自身の物理IDを0番として、その旨を通知するパケット(SelfIDパケット)を送信する。このパケットはすべてのノードに配信され、物理ID=0が割り当て済みであることを認識する(図6)。


図 6 物理 ID 決定-1

その後、バスマネージャーは次に優先順位が高いポートに接続されたノードに対し同様に動作する。貸与されたノードがブランチ・ノードの場合、バスマネージャー同様にバス権貸与を行う。最終的にバス権を貸与されたノードは自身の物理IDを1番として、SelfIDパケットを送信する(図7)。


図 7 物理 ID 決定-2

以上を、すべてのノードが物理IDを設定するまで繰り返す。最後に設定を行うのはバスマネージャーであり、これによりバスマネージャーの物理IDは最も番号の大きいものとなる(図8)。


図 8 物理 ID 決定-3

2.4 バスコンフィグレーションにおける注意点

2.4.1 物理IDについて
同一の接続状態にあるIEEE1394バスにおいて、物理IDが毎回必ず同じ番号になる保証はない。物理IDはバスが有効である状態の、一時的な識別子にしか過ぎない。

このことは、バス運用中にバスリセットが発生した際にも当てはまる。理想的なバス構成においても、不慮のデータエラーが生じバスリセットが発生する可能性がある。このバスリセット後のコンフィグレーションで、物理IDの構成に変化が生じる可能性もある。

デバイスの特定には、コンフィグレーションROMにあるChip IDを用いる必要があり、またバスリセットが発生するたびにこれを取得し直す必要がある。

2.4.2 不測のバスリセットについて
IEEE1394に関わらず、シリアルバスは必ずデータエラーが発生する。理想的な構成においても、エラー発生確率は低減するが0にはならない。

このエラーがバスの構成上致命的である場合、IEEE1394ではバスリセットが発生し修復を試みる。カメラおよびアプリケーションは、どのような状況においてもバスリセットが発生することを念頭に設計する必要がある。

3. IEEE1394プロトコル

3.1 パケットのデータ単位
IEEE1394の殆どのパケットは、4Byteずつのデータに区切られる。このデータ区切りのため、IEEE1394ではQuadletというデータ単位が使用される(1 Quadlet=4Byte)。送受信されるデータがQuadlet単位ではなく端数が生じる場合は、Quadlet単位になるように不要な領域を0で埋める。

3.2 パケットの種類
IEEE1394には、大きく分けてPHYパケット、Acknowledgeパケット(以下ACKパケット)、Primaryパ ケットの3種 類 が ある。この 中でPrimaryパケットは、さらにAsynchronousパケットとIsochronousパケットに分類される(図9)。


図 9 パケットの種類

PHYパケットは、節2.3で説明したSelfIDパケット等のバスの物理層を制御するために用いられるパケットである。パケット長は2Quadletで構成されている。Primaryパケットは、ノード間の通信に使用される。カメラの場合、状態制御や映像出力などに用いられる。パケット長は3 Quadlet以上で構成されている。

ACKパケットは、Primaryパケットを受信した際の応答に使用される。パケット長は1Byteで構成されている。IEEE1394バスにおいて、ACKパケットは唯一Quadlet単位ではないパケットである。主なACKパケットを表2に示す。


表 2 ACKパケット(抜粋)

3.3 Asynchronous転送とIsochronous転送
Primaryパケットは、AsynchronousパケットとIsochronousパケットに分類される。これらは、それぞれAsynchronous転送とIsochronous転送に使用される。Asynchronous転送は、Busyやパケット再送等の強固なフロー制御を備えた転送方式、Isochronous転送は帯域保護とリアルタイム性を備えた転送方法である。IIDCでは、カメラ制御にAsynchronous転送、映像出力にIsochronous転送を用いるよう定められている。

3.4 Asynchronous転送の概要
Asynchronous転送では、ノード内部のアドレス空間に読み書き等のアクセスを行うことにより実現する(後述のAsynchronous Stream転送を除く)(表3)。

WRITEアクセスはノードに対する書き込み動作、READアクセスはノードからの読み出し動作を行う。LOCKアクセスは、ノードに対する書き込みとともにその際変化したデータの読み出しを同時に行う。

Cycle StartはIsochronous転送の送信タイミング生成に使用される(後述)。データ単位は、QuadletとBlockの2種類がある。Quadletは1 Quadlet固定、Blockは可変長データブロックのアクセスが行える。


表 3 Asynchronous 転送

3.4.1 Unified Transaction
実際の転送動作では、PrimaryパケットとACKパケットを用いたハンドシェイクで行われる。このハンドシェイク通信を、Subactionと呼ぶ。そして、1回のSubactionで構成される通信を、Unified Transactionと呼ぶ。

受信側ノードはPrimaryパケット受信後直ちに内容確認を行い、約0.2μsec以内にACKパケット応答を開始する必要がある(応答処理開始後、若干遅延させることは可能)。

この応答までの時間が非常に短く、パケット内容の詳細確認(指定されたアドレスが、現在アクセス可能かなど)が難しいケースがある。この場合パケットの構造チェック(データ長、CRC等)のみ行い、その結果だけを元にACKパケット応答を行うことも許可されている(図10)。


図10 UnifiedTransaction

3.4.2 Split Transaction
Unified Transactionに対して、2回のSubactionで構成される通信をSplit Transactionと呼ぶ。1回目のSubactionでアクセス要求(Request Subaction)を行い、2回目のSubactionでそれに対する応答(Response Subaction)を行う(図11)。


図11 Split Transaction

Request Subactionでは、受信側ノード(カメラ)はパケット構造に問題がなければack_pendingを返す。その後、カメラは内部処理を行い、処理が完了した際にResponse Subactionを開始しする。

この送受信は応答であるため、送信ノード、受信ノードが入れ替わる(カメラが送信ノード、ホストPCが受信ノード)。Response Subactionにおいて送信側ノード(カメラ)は、Write responseパケットではACKパケットと同様に、WRITEアクセスの可否、エラー内容を通知する。

Read response for data quadlet/block, Lock responseパケットはそれに加えて、読み出されたデータが添付さる。Request SubactionからResponse Subactionまでの期間は、標準で100msecまで延長することが許されている。

ACKパケット応答の0.2μsecと比較し十分時間があるため、パケット内容の詳細確認を行えるケースが多いと考えられる。 なおREADアクセス、LOCKアクセスは読み出しデータの応答が必要であるため、Split Transactionしか存在しない。

3.4.3 Broadcast Transaction
WRITEアクセスにはUnified Transaction、 Split Transactionのほかに、Broadcast Transac-tionがある。これは、バス上のすべてのノードに対して同時に書き込みを行うというものである(図12)。


図12 Broadcast Transaction

Broadcast Transactionでは複数のノードに対して同時に送信を行うため、ACKパケット応答がない。このため、アクセスが正常に行われたか判別が難しいという欠点がある。

しかし、複数のノードに対して時間的なズレを最小としたアクセスが行える点は、厳しいタイミング制約が要求される産業用カメラに対し大きな利点となる。

その他IEEE1394では、Split TransactionにおけるRequest SubactionのACKパケットとRe-sponse SubactionのPrimaryパケットを結合して送信するConcatenated Transaction、Re-quest SubactionとResponse Subactionの間に、他のアクセスを割り込んで実行するPending Transactionが定義されている。

3.5 Isochronous転送の概要

Isochronous転送は、リアルタイム性を最優先に考えた転送方法である。Asynchronous転送と比較し、以下の特徴がある。

• Asynchronous転送に割り込まれることのない、帯域が保証された転送方法。
• バス帯域の80%(1ノードでは約67%)まで利用可能。
• 利用帯域は事前登録制であり、Isochronous転送同士で帯域が競合しない。
• パケット処理を簡素化するために、Broadcast Transactionのみサポート。

3.5.1 Isochronous転送タイミング
定常状態のIEEE1394バスには、Asynchro-nous CycleとIsochronous Cycleの2つの状態が交互に切り替わるバスサイクルがある。Asynchronous CycleはAsynchronous転送のみ、Isochronous CycleではIsochronous転送のみそれぞれ行うことができる。

バスサイクルの管理は、サイクルマスタが行う。これはバスマネージャーが兼任する。バスサイクルは、125μsec単位で循環する。サイクルマスターははじめに、サイクルの開始を示すCycle Startパケットを送信する。

このパケットの送信が完了すると、バスはIsochronous Cycleに移行する。Isochronous Cycleに移行後、Isochronous転送を行いたいノードは直ちに送信を開始する。送信を行うノードがなく、一定期間パケットが送信されない期間(Subaction Gap)経過すると、バスはAsynchronous Cycleに移行する(図13)。

Isochronous Cycleはバス全体域の80%まで占有することができ、残りの帯域がAsynchro-nous Cycleに割り当てられる。バスサイクル後、直ちにIsochronous Cycleに入るため、Asyn-chronous転送よりIsochronous転送が優先的に処理される。


図13 バスサイクル

3.5.2 Isochronous転送の帯域管理
Isochronous転送の帯域管理は、Isochronous Resource Manager(以下IRM)が行う。これはバスマネージャーが兼任する。Isochronous転送を行いたいノードは、IRMに対し帯域の確保を要求する。

IIDCの場合、この帯域確保は実際にIsochronous転送を行うカメラではなく、Isochronous転送を受信するホストPCが行う。仕様上、1つのノードがIsochronous帯域すべてを占有することはできない。表4に、バス速度ごとの有効帯域をまとめる。


表 4 Isochronous帯域

3.5.3 Isochronousパケットの送受信
 前述のとおり、Isochronous転送はすべてBroadcast Transactionとなる。これにより、Isochronousパケットには宛先(DestinationID)フィールドがない。また、送信元(SourceID)を示すフィールドもない。

Isochronous転送のルーティングは、Isochronous Channelを使用して行われる。 Isochronous ChannelはIEEE1394バス上で64個(Channel 31は後述のAsynchronous Streamで使用するため、実質63個)存在し、その管理はIRMが行う。

Isochronous転送を行いたいノードは帯域同様に、IRMに対しChannelの確保を行う。IIDCでは、Channel確保もホストPCが行う。 Isochronous転送において、送信側はIso-chronous ChannelをIsochronousパケットに付記する。

受信側はIsochronous Channelからデータ判別を行い、受信する。 Isochronous転送では、ACKパケットを使用しない。送信側はデータ準備が整い次第、受信側の確認なしに送信を行える(図14)。


図14 Isochronous パケット送信

3.6 Asynchronous Streamパケットの概要
Asynchronous Streamパケットは、Asyn-chronous転送とIsochronous転送の両方の特徴をもっている。

• 転送が行われるのはAsynchronous Cycleであり、帯域は保護されない。
• Isochronousパケットと同じ構造であり、Isochronous Channel(標準ではChannel31)を用いてルーティングが行われる。
• 転送はBroadcast Transactionで行われ、ACKパケットは存在しない。 

Asynchronous Streamパケットを拡張したものに、Global Asynchronous Stream Packet(以下GASP)があり、これはパケットのデータフィールドに、独自の構造を定義したものである。

GASPの最も大きな特徴は、追加された構造によってマルチキャスト通信を実現した点にある。これによって、IP over 1394(IEEE1394バスでEthernet接続を実現)が可能になった。 

産業用では殆ど利用されていないが、東芝テリー社製カメラ「FireDragon2シリーズ」ではイベント通知(カメラ内部の状態を能動的に通知)機能で使用されている。

4. IEEE1394 の今後の展望

民生機器では停滞しているものの、現在、産業用に幅広く利用されている。一部のメーカからS1600をサポートした機器が発表されており、今後さらなる広帯域化と拡張が進むと予想される。

5. IEEE1394 規格の入手方法

IEEE1394の規格は、IEEEが管理しており、規格書はIEEEホームページ(http://www.ieee.org/)のオンラインショップで購入できる。2011年現在、最新版である「1394-2008 IEEE Standard for High-Performance Serial Bus」が$346(IEEEメンバーは$275)で販売されている。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください