(57)【要約】【課題】１３９４バスの２つのチャネルを用いて効率的なデータ転送を行うこと。【解決手段】ＩＥＥＥ１３９４に準拠した通信制御バスに接続されたイニシエータとターゲットとを含む情報処理システムであって、イニシエータは、ひとつのコマンドＯＲＢに対し２つのデータバッファを有し、ターゲットは、２つ目のバッファに対する処理のみが完了した場合、１度目のステータスブロックで、それを通知し、１つ目のバッファの処理が完了した場合、２度目のステータスブロックで、それを通知する。２つのバッファの両方に対するデータ通信が終了した場合、１つのステータスブロックで通知することもできる。【選択図】　図３６
2004104255.tif 000002
【特許請求の範囲】
【請求項１】
通信制御バスで接続された第１、第２機器を含む情報処理システムであって、前記第１機器は、１つのコマンドブロックに対し複数のデータバッファを割り当て、
前記第２機器は、前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを前記第１機器に通知する完了通知手段を有することを特徴とする情報処理システム。
【請求項２】
通信制御バスで接続された第１、第２機器を含む情報処理システムであって、前記第１機器は、ロジカルユニット１つを使って１つのコマンドＯＲＢに対して割り当てられた２つのデータバッファを有し、
前記第２機器は、前記２つのデータバッファとの間でデータ通信を行うディスクリプタと、前記２つのデータバッファのいずれか一方に対するデータ通信が完了したことを通知する完了通知手段とを有することを特徴とする情報処理システム。
【請求項３】
前記通信制御バスはＩＥＥＥ１３９４に準拠しており、前記第１機器と前記第２機器との間では、シリアルバスプロトコル３を通信プロトコルとしてデータ通信を行うことを特徴とする請求項１または２に記載の情報処理システム。
【請求項４】
前記完了通知手段は、前記第１機器のステータスＦＩＦＯに、前記データバッファの内、データ通信が完了したデータバッファを示すステータスを発行することを特徴とする請求項１、２または３に記載の情報処理システム。
【請求項５】
前記完了通知手段は、前記データバッファごとに独立してデータ通信の完了を通知することを特徴とする請求項１、２、３または４に記載の情報処理システム。
【請求項６】
前記完了通知手段は、更に、前記複数のデータバッファの全てに対するデータ通信の完了を通知することを特徴とする請求項１乃至５のいずれかに記載の情報処理システム。
【請求項７】
前記第１機器は、前記データバッファに格納されているデータの識別情報を前記ＯＲＢに含むことを特徴とする請求項１乃至６のいずれかに記載の情報処理システム。
【請求項８】
通信制御バスで接続された第１、第２機器間における通信方法であって、前記第１機器から前記第２機器へ送信する１つのコマンドブロックに対し複数のデータバッファを割り当て、前記第２機器は、前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを前記第１機器に通知することを特徴とする通信方法。
【請求項９】
通信制御バスで接続された２機器間における通信方法であって、１つのコマンドＯＲＢに対し２つのデータバッファを参照する工程と、
前記ＯＲＢで指定されるディスクリプタのいずれかがデータ通信を完了した場合に、その完了を通知する完了通知工程と、
前記データバッファの更新情報を通知する工程と、
を含むことを特徴とする通信方法。
【請求項１０】
他の機器と通信制御バスで接続された情報処理装置であって、
１つのコマンドブロックに対し複数のデータバッファを割り当て、
他の機器から前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを示す完了通知を受信する手段を有することを特徴とする情報処理装置。
【請求項１１】
他の機器と通信制御バスで接続された情報処理装置であって、
１つのコマンドブロックに対し複数のデータバッファを割り当てた他の機器に対して、前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを通知する完了通知手段を有することを特徴とする情報処理装置。
【請求項１２】
ロジカルユニット１つを使って１つのコマンドＯＲＢに対して割り当てられた２つのデータバッファを有する他の機器と、通信制御バスで接続された情報処理装置であって、
前記２つのデータバッファとの間でデータ通信を行うディスクリプタと、前記２つのデータバッファのいずれか一方に対するデータ通信が完了したことを通知する完了通知手段を有することを特徴とする情報処理装置。
【請求項１３】
他の機器と通信制御バスで接続された情報処理装置における通信方法であって、
１つのコマンドブロックに対し複数のデータバッファを割り当て、
他の機器から前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを示す完了通知を受信することを特徴とする通信方法。
【請求項１４】
他の機器と通信制御バスに接続された情報処理装置における通信方法であって、
１つのコマンドブロックに対し複数のデータバッファを割り当てた他の機器に対して、前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを通知することを特徴とする通信方法。
【請求項１５】
ロジカルユニット１つを使って１つのコマンドＯＲＢに対して割り当てられた２つのデータバッファを有する他の機器と、通信制御バスで接続された情報処理装置における通信方法であって、
前記２つのデータバッファとの間でデータ通信を行うディスクリプタを用いて、前記２つのデータバッファのいずれか一方に対するデータ通信が完了したことを通知することを特徴とする通信方法。
【請求項１６】
請求項８、９、１３、１４または１５に記載の通信方法をコンピュータに実現させることを特徴とするプログラム。
【請求項１７】
前記請求項１６に記載のプログラムを格納したことを特徴とするコンピュータ読取り可能な記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４等のインターフェースで接続される情報処理システム、情報処理装置、情報処理方法、プログラム及び記憶媒体に関するものである。
【０００２】
【従来の技術】
セントロニクス、ＵＳＢ、そしてＩＥＥＥ１３９４等の各種インターフェースにおいてホストとデバイスの１対１接続、通信を行なう場合、ホスト・デバイス間でデバイスの各種機能を制御するためにために通信プロトコルの１セッション中に複数の論理チャネル接続を樹立し、チャネルごとにデータ転送を行なう。
【０００３】
ＩＥＥＥ１３９４上のデータ通信プロトコルであるＳＢＰ（シリアルバスプロトコル）−２は、それ自体では、ひとつのロジカルユニットにおいて、データ転送の単位であるＯＲＢ（オペレーションリクエストブロック）１個に対して１つのデータバッファが参照されるため、片方向の単一データチャネル、片方向半二重のデータ通信を行なう仕組みになっており、複数論理チャネルを実現するのは困難であった。現在規格策定中のＳＢＰ−２の機能拡張版であるＳＢＰ−３においては、この点に注目し、ロジカルユニットにおけるデータ転送の単位であるＯＲＢに対して２つのデータバッファを参照できるようにして１ロジカルユニットにつき２つのデータ転送チャネルを実現することを可能とする拡張が行なわれた。
【０００４】
【発明が解決しようとする課題】
しかしながらＳＢＰ−３のデータ転送においては２つのデータ転送チャネルのフローコントロールはあくまでもＯＲＢ単位で行なわれるため、何らかの理由によりどちらかのデータ転送チャネルにおいてデータの送受信ができなくなった場合、またどちらかのデータ転送チャネルのデータ転送が他のチャネルよりも遅い場合、正常に転送されているチャネル、速いほうのチャネルが影響を受けてしまう。
【０００５】
これは、片方のデータバッファに対するアクセスが正常終了しても、もう片方のデータバッファアクセスが完了しないとそのＯＲＢに対する完了通知をＳＢＰ−３のイニシエータに対して通知できず、ロジカルユニットとしてのデータ転送が滞ってしまうためである。
【０００６】
本発明は、上記従来技術の課題を解決するためになされたもので、その目的とするところは、ＩＥＥＥ１３９４バス等の２つのチャネルを用いて効率的なデータ転送を行うことにある。
【０００７】
【課題を解決するための手段】
上記目的を達成するため、本発明に係るシステムは、
通信制御バスで接続された第１、第２機器を含む情報処理システムであって、前記第１機器は、１つのコマンドブロックに対し複数のデータバッファを割り当て、
前記第２機器は、前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを前記第１機器に通知する完了通知手段を有することを特徴とする。
【０００８】
通信制御バスで接続された第１、第２機器を含む情報処理システムであって、前記第１機器は、ロジカルユニット１つを使って１つのコマンドＯＲＢに対して割り当てられた２つのデータバッファを有し、
前記第２機器は、前記２つのデータバッファとの間でデータ通信を行うディスクリプタと、前記２つのデータバッファのいずれか一方に対するデータ通信が完了したことを通知する完了通知手段とを有することを特徴とする。
【０００９】
前記通信制御バスはＩＥＥＥ１３９４に準拠しており、前記第１機器と前記第２機器との間では、シリアルバスプロトコル３を通信プロトコルとしてデータ通信を行うことを特徴とする。
【００１０】
前記完了通知手段は、前記第１機器のステータスＦＩＦＯに、前記データバッファの内、データ通信が完了したデータバッファを示すステータスを発行することを特徴とする。
【００１１】
前記完了通知手段は、前記データバッファごとに独立してデータ通信の完了を通知することを特徴とする。
【００１２】
前記完了通知手段は、更に、前記複数のデータバッファの全てに対するデータ通信の完了を通知することを特徴とする。
【００１３】
前記第１機器は、前記データバッファに格納されているデータの識別情報を前記ＯＲＢに含むことを特徴とする。
【００１４】
上記目的を達成するため、本発明に係る方法は、
通信制御バスで接続された第１、第２機器間における通信方法であって、前記第１機器から前記第２機器へ送信する１つのコマンドブロックに対し複数のデータバッファを割り当て、前記第２機器は、前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを前記第１機器に通知することを特徴とする。
【００１５】
通信制御バスで接続された２機器間における通信方法であって、１つのコマンドＯＲＢに対し２つのデータバッファを参照する工程と、
前記ＯＲＢで指定されるディスクリプタのいずれかがデータ通信を完了した場合に、その完了を通知する完了通知工程と、
前記データバッファの更新情報を通知する工程と、
を含むことを特徴とする。
【００１６】
上記目的を達成するため、本発明に係る装置は、
他の機器と通信制御バスで接続された情報処理装置であって、
１つのコマンドブロックに対し複数のデータバッファを割り当て、
他の機器から前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを示す完了通知を受信する手段を有することを特徴とする。
【００１７】
他の機器と通信制御バスで接続された情報処理装置であって、
１つのコマンドブロックに対し複数のデータバッファを割り当てた他の機器に対して、前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを通知する完了通知手段を有することを特徴とする。
【００１８】
ロジカルユニット１つを使って１つのコマンドＯＲＢに対して割り当てられた２つのデータバッファを有する他の機器と、通信制御バスで接続された情報処理装置であって、
前記２つのデータバッファとの間でデータ通信を行うディスクリプタと、前記２つのデータバッファのいずれか一方に対するデータ通信が完了したことを通知する完了通知手段を有することを特徴とする。
【００１９】
他の機器と通信制御バスで接続された情報処理装置における通信方法であって、
１つのコマンドブロックに対し複数のデータバッファを割り当て、
他の機器から前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを示す完了通知を受信することを特徴とする。
【００２０】
他の機器と通信制御バスに接続された情報処理装置における通信方法であって、
１つのコマンドブロックに対し複数のデータバッファを割り当てた他の機器に対して、前記複数のデータバッファのいずれか１つに対するデータ通信が完了したことを通知することを特徴とする。
【００２１】
ロジカルユニット１つを使って１つのコマンドＯＲＢに対して割り当てられた２つのデータバッファを有する他の機器と、通信制御バスで接続された情報処理装置における通信方法であって、
前記２つのデータバッファとの間でデータ通信を行うディスクリプタを用いて、前記２つのデータバッファのいずれか一方に対するデータ通信が完了したことを通知することを特徴とする。
【００２２】
また、上記目的を達成するため、本発明に係るプログラムは、上記通信方法をコンピュータに実現させる。また、本発明に係る記憶媒体は、そのプログラムを格納する。
【００２３】
【発明の実施の形態】
以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されている構成要素の相対配置、表示画面等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。
【００２４】
（第１実施形態）
本発明の第１実施形態としての情報処理システムについて説明する前に、ＩＥＥＥ１３９４の技術の概要について説明する。
【００２５】
〈ＩＥＥＥ１３９４の技術の概要〉
以下、本実施の形態のデジタルインタフェースに適用されるＩＥＥＥ１３９４−１９９５規格の技術について簡単に説明する。尚、ＩＥＥＥ１３９４−１９９５規格（以下、ＩＥＥＥ１３９４規格）についての詳細は、１９９６年の８月３０日にＩＥＥＥ（Ｔｈｅ　Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｅｌｅｃｔｒｉｃａｌ　ａｎｄ　Ｅｌｅｃｔｒｏｎｉｃｓ　Ｅｎｇｉｎｅｅｒｓ，　Ｉｎｃ．）から出版された「ＩＥＥＥ　Ｓｔａｎｄａｒｄ　ｆｏｒ　ａ　Ｈｉｇｈ　Ｐｅｒｆｏｒｍａｎｃｅ　Ｓｅｒｉａｌ　Ｂｕｓ」に記述されている。
【００２６】
（１）概要
図２にＩＥＥＥ１３９４規格に準拠したデジタルインタフェース（以下、１３９４インタフェース）を具備するノードにより構成される通信システム（以下、１３９４ネットワーク）の一例を示す。１３９４ネットワークは、シリアルデータの通信可能なバス型ネットワークを構成するものである。
【００２７】
図２において、各ノードＡ〜Ｆは、ＩＥＥＥ１３９４規格に準拠した通信ケーブルを介して接続されている。これらのノードＡ〜Ｈは、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）、デジタルＶＴＲ（Ｖｉｄｅｏ　Ｔａｐｅ　Ｒｅｃｏｒｄｅｒ）、ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｉｄｅｏ　Ｄｉｓｃ）プレーヤ、デジタルカメラ、ハードディスク、モニタ等の電子機器である。
【００２８】
１３９４ネットワークの接続方式は、ディジーチェーン方式とノード分岐方式とに対応しており、自由度の高い接続を可能としている。
【００２９】
又、１３９４ネットワークでは、例えば、既存の機器を削除したり、新たな機器を追加したり、既存の機器の電源をＯＮ／ＯＦＦしたりした場合に、自動的にバスリセットを行う。このバスリセットを行うことにより、１３９４ネットワークは、新たな接続構成の認識と各機器に対するＩＤ情報の割り当てとを自動的に行うことができる。この機能によって、１３９４ネットワークは、ネットワークの接続構成を常時認識することができる。
【００３０】
又、１３９４ネットワークは、他の機器から転送されたデータを中継する機能を有している。この機能により、全ての機器がバスの動作状況を把握することができる。
【００３１】
又、１３９４ネットワークは、Ｐｌｕｇ＆Ｐｌａｙと呼ばれる機能を有している。この機能により、全ての機器の電源をＯＦＦにすることなく、接続するだけで自動に接続機器を認識することができる。
【００３２】
又、１３９４ネットワークは、１００／２００／４００Ｍｂｐｓのデータ転送速度に対応している。上位のデータ転送速度を持つ機器は、下位のデータ転送速度をサポートすることができるため、異なるデータ転送速度に対応する機器同士を接続することができる。
【００３３】
更に、１３９４ネットワークは、２つの異なるデータ転送方式（即ち、アシンクロナス転送モードとアイソクロナス転送モード）に対応している。
【００３４】
アシンクロナス（Ａｓｙｎｃｈｒｏｎｏｕｓ）転送モードは、必要に応じて非同期に転送することが要求されるデータ（即ち、コントロール信号やファイルデータ等）を転送する際に有効である。又、アイソクロナス（Ｉｓｏｃｈｒｏｎｏｕｓ）転送モードは、所定量のデータを一定のデータレートで連続的に転送することが要求されるデータ（即ち、ビデオデータやオーディオデータ等）を転送する際に有効である。
【００３５】
アシンクロナス転送モードとアイソクロナス転送モードとは、各通信サイクル（通常１サイクルは、１２５μＳ）内において、混在させることが可能である。各転送モードは、サイクルの開始を示すサイクル・スタート・パケット（以下、ＣＳＰ）の転送後に実行される。
【００３６】
尚、各通信サイクル期間において、アイソクロナス転送モードは、アシンクロナス転送モードよりも優先順位が高く設定されている。又、アイソクロナス転送モードの転送帯域は、各通信サイクル内で保証されている。
【００３７】
（２）アーキテクチャ
次に、図３を用いて１３９４インタフェースの構成要素を説明する。
【００３８】
１３９４インタフェースは、機能的に複数のレイヤ（階層）から構成されている。図３において、１３９４インタフェースは、ＩＥＥＥ１３９４規格に準拠した通信ケーブル３０１を介して他のノードの１３９４インタフェースと接続される。又、１３９４インタフェースは、１つ以上の通信ポート３０２を有し、通信ポート３０２は、ハードウェア部に含まれるフィジカル・レイヤ３０３と接続される。
【００３９】
図３において、ハードウェア部は、フィジカル・レイヤ３０３とリンク・レイヤ３０４とから構成されている。フィジカル・レイヤ３０３は、他のノードとの物理的、電気的なインタフェース、バスリセットの検出とそれに伴う処理、入出力信号の符号化／復号化、バス使用権の調停等を行う。又、リンク・レイヤ３０４は、通信パケットの生成と送受信、サイクルタイマの制御等を行なう。
【００４０】
又、図３において、ファームウェア部は、トランザクション・レイヤ３０５とシリアル・バス・マネージメント３０６とを含んでいる。トランザクション・レイヤ３０５は、アシンクロナス転送モードを管理し、各種のトランザクション（リード、ライト、ロック）を提供する。シリアル・バス・マネージメント３０６は、後述するＣＳＲアーキテクチャに基づいて、自ノードの制御、自ノードの接続状態の管理、自ノードのＩＤ情報の管理、シリアルバスネットワークの資源管理を行う機能を提供する。
【００４１】
以上、ハードウェア部とファームウェア部とが実質的に１３９４インタフェースを構成するものであり、それらの基本構成は、ＩＥＥＥ１３９４規格により規定されている。
【００４２】
又、ソフトウェア部に含まれるアプリケーション・レイヤ３０７は、使用するアプリケーションソフトによって異なり、ネットワーク上でどのようにデータを通信するのかを制御する。例えば、デジタルＶＴＲの動画像データの場合は、ＡＶ／Ｃプロトコルなどの通信プロトコルによって規定されている。
【００４３】
（２−１）リンク・レイヤ３０４
図４は、リンク・レイヤ３０４の提供可能なサービスを示す図である。図４において、リンク・レイヤ３０４は、次の４つのサービスを提供する。即ち、▲１▼応答ノードに対して所定のパケットの転送を要求するリンク要求（ＬＫ＿ＤＡＴＡ．ｒｅｑｕｅｓｔ）、▲２▼応答ノードに所定のパケットの受信を通知するリンク通知（ＬＫ＿ＤＡＴＡ．ｉｎｄｉｃａｔｉｏｎ）、▲３▼応答ノードからのアクノリッジを受信したことを示すリンク応答（ＬＫ＿ＤＡＴＡ．ｒｅｓｐｏｎｓｅ）、▲４▼要求ノードからのアクノリッジを確認するリンク確認（ＬＫ＿ＤＡＴＡ．ｃｏｎｆｉｒｍａｔｉｏｎ）である。尚、リンク応答（ＬＫ＿ＤＡＴＡ．ｒｅｓｐｏｎｓｅ）は、ブロードキャスト通信、アイソクロナスパケットの転送の場合には存在しない。
【００４４】
又、リンク・レイヤ３０４は、上述のサービスに基づいて、上述の２種類の転送方式、即ち、アシンクロナス転送モード、アイソクロナス転送モードを実現する。
【００４５】
（２−２）トランザクション・レイヤ３０５
図５は、トランザクション・レイヤ３０５の提供可能なサービスを示す図である。図５において、トランザクション・レイヤ３０５は、次の４つのサービスを提供する。即ち、▲１▼応答ノードに対して所定のトランザクションを要求するトランザクション要求（ＴＲ＿ＤＡＴＡ．ｒｅｑｕｅｓｔ）、▲２▼応答ノードに所定のトランザクション要求の受信を通知するトランザクション通知（ＴＲ＿ＤＡＴＡ．ｉｎｄｉｃａｔｉｏｎ）、▲３▼応答ノードからの状態情報（ライト、ロックの場合は、データを含む）を受信したことを示すトランザクション応答（ＴＲ＿ＤＡＴＡ．ｒｅｓｐｏｎｓｅ）、▲４▼要求ノードからの状態情報を確認するトランザクション確認（ＴＲ＿ＤＡＴＡ．ｃｏｎｆｉｒｍａｔｉｏｎ）である。
【００４６】
又、トランザクション・レイヤ３０５は、上述のサービスに基づいてアシンクロナス転送を管理し、次の３種類のトランザクション、即ち、▲１▼リード・トランザクション、▲２▼ライト・トランザクション、▲３▼ロック・トランザクションを実現する。
【００４７】
▲１▼リード・トランザクションは、要求ノードが応答ノードの特定アドレスに格納された情報を読み取る。
【００４８】
▲２▼ライト・トランザクションは、要求ノードが応答ノードの特定アドレスに所定の情報を書き込む。
【００４９】
▲３▼ロック・トランザクションは、要求ノードが応答ノードに対して参照データと更新データとを転送し、応答ノードの特定アドレスの情報とその参照データとを比較し、その比較結果に応じて特定アドレスの情報を更新データに更新する。
【００５０】
（２−３）シリアル・バス・マネージメント３０６
シリアル・バス・マネージメント３０６は、具体的に、次の３つの機能を提供することができる。３つの機能とは、即ち、▲１▼ノード制御、▲２▼アイソクロナス・リソース・マネージャ（以下、ＩＲＭ）、▲３▼バスマネージャである。
【００５１】
▲１▼ノード制御は、上述の各レイヤを管理し、他のノードとの間で実行されるアシンクロナス転送を管理する機能を提供する。
【００５２】
▲２▼ＩＲＭは、他のノードとの間で実行されるアイソクロナス転送を管理する機能を提供する。具体的には、転送帯域幅とチャネル番号の割り当てに必要な情報を管理し、これらの情報を他のノードに対して提供する。
【００５３】
ＩＲＭは、ローカルバス上に唯一存在し、バスリセット毎に他の候補者（ＩＲＭの機能を有するノード）の中から動的に選出される。又、ＩＲＭは、後述のバスマネージャの提供可能な機能（接続構成の管理、電源管理、速度情報の管理等）の一部を提供してもよい。
【００５４】
▲３▼バスマネージャは、ＩＲＭの機能を有し、ＩＲＭよりも高度なバス管理機能を提供する。具体的には、より高度な電源管理（通信ケーブルを介して電源の供給が可能か否か、電源の供給が必要か否か等の情報を各ノード毎に管理）、より高度な速度情報の管理（各ノード間の最大転送速度の管理）、より高度な接続構成の管理（トポロジ・マップの作成）、これらの管理情報に基づくバスの最適化等を行ない、更にこれらの情報を他のノードに提供する機能を有する。
【００５５】
又、バスマネージャは、シリアルバスネットワークを制御するためのサービスをアプリケーションに対して提供できる。ここで、サービスには、シリアルバス制御要求（ＳＢ＿ＣＯＮＴＲＯＬ．ｒｅｑｕｅｓｔ）、シリアルバス・イベント制御確認（ＳＢ＿ＣＯＮＴＲＯＬ．ｃｏｎｆｉｒｍａｔｉｏｎ）、シリアルバス・イベント通知（ＳＢ＿ＣＯＮＴＲＯＬ．ｉｎｄｉｃａｔｉｏｎ）等がある。
【００５６】
ＳＢ＿ＣＯＮＴＲＯＬ．ｒｅｑｕｅｓｔは、アプリケーションがバスリセットを要求するサービスである。ＳＢ＿ＣＯＮＴＲＯＬ．ｃｏｎｆｉｒｍａｔｉｏｎは、ＳＢ＿ＣＯＮＴＲＯＬ．ｒｅｑｕｅｓｔをアプリケーションに対して確認するサービスである。ＳＢ＿ＣＯＮＴＲＯＬ．ｉｎｄｉｃａｔｉｏｎは、非同期に発生するイベントをアプリケーションに対して通知するサービスである。
【００５７】
（３）アドレス指定
図６は、１３９４インタフェースにおけるアドレス空間を説明する図である。尚、１３９４インタフェースは、ＩＳＯ／ＩＥＣ　１３２１３：１９９４に準じたＣＳＲ（Ｃｏｍｍａｎｄ　ａｎｄ　Ｓｔａｔｕｓ　Ｒｅｇｉｓｔｅｒ）アーキテクチャに従い、６４ビット幅のアドレス空間を規定している。
【００５８】
図６において、最初の１０ビットのフィールド６０１は、所定のバスを指定するＩＤ番号に使用され、次の６ビットのフィールド６０２は、所定の機器（ノード）を指定するＩＤ番号に使用される。この上位１６ビットを「ノードＩＤ」と呼び、各ノードはこのノードＩＤにより他のノードを識別する。又、各ノードは、このノードＩＤを用いて相手を識別した通信を行うことができる。
【００５９】
残りの４８ビットからなるフィールドは、各ノードの具備するアドレス空間（２５６Ｍバイト構造）を指定する。その内の２０ビットのフィールド６０３は、アドレス空間を構成する複数の領域を指定する。
【００６０】
フィールド６０３において、「０〜０ｘＦＦＦＦＤ」の部分は、メモリ空間と呼ばれる。「０ｘＦＦＦＦＥ」の部分は、プライベート空間と呼ばれ、各ノードで自由に利用できるアドレスである。又、「０ｘＦＦＦＦＥ」の部分は、レジスタ空間と呼ばれ、バスに接続されたノード間において共通の情報を格納する。各ノードは、レジスタ空間の情報を用いることにより、各ノード間の通信を管理することができる。
【００６１】
最後の２８ビットのフィールド６０４は、各ノードにおいて共通或いは固有となる情報が格納されるアドレスを指定する。
【００６２】
例えば、レジスタ空間において、最初の５１２バイトは、ＣＳＲアーキテクチャーのコア（ＣＳＲコア）レジスタ用に使用される。ＣＳＲコア・レジスタに格納される情報のアドレス及び機能を図７に示す。図中のオフセットは、「０ｘＦＦＦＦＦ０００００００」からの相対位置である。
【００６３】
次の５１２バイトは、シリアルバス用のレジスタとして使用される。シリアルバス・レジスタに格納される情報のアドレス及び機能を図８に示す。図中のオフセットは、「０ｘＦＦＦＦＦ００００２００」からの相対位置である。
【００６４】
その次の１０２４バイトは、コンフィグレーションＲＯＭ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ　ＲＯＭ）用に使用される。
【００６５】
コンフィグレーションＲＯＭには最小形式と一般形式とがあり、「０ｘＦＦＦＦＦ００００４００」から配置される。最小形式のコンフィグレーションＲＯＭを図９に示す。図９において、ベンダＩＤは、ＩＥＥＥにより各ベンダに対して固有に割り当てられた２４ビットの数値である。
【００６６】
又、一般形式のコンフィグレーションＲＯＭを図１０に示す。図１０において、上述のベンダＩＤは、ルートディレクトリ（Ｒｏｏｔ　Ｄｉｒｅｃｔｏｒｙ）１００２に格納されている。Ｂｕｓ　Ｉｎｆｏ　Ｂｌｏｃｋ１００１とＲｏｏｔ　Ｌｅａｆ１００５とには、各ノードを識別する固有のＩＤ情報としてノードユニークＩＤを保持することが可能である。
【００６７】
ここで、ノードユニークＩＤは、メーカー、機種に関わらず、１つのノードを特定することのできる固有のＩＤを定めるようになっている。ノードユニークＩＤは６４ビットにより構成され、上位２４ビットは上述のベンダＩＤを示し、下位４８ビットは各ノードを製造するメーカーにおいて自由に設定可能な情報（例えば、ノードの製造番号等）を示す。尚、このノードユニークＩＤは、例えばバスリセットの前後で継続して特定のノードを認識する場合に使用される。
【００６８】
又、図１０において、ルートディレクトリ１００２には、ノードの基本的な機能に関する情報を保持することが可能である。詳細な機能情報は、ルートディレクトリ１００２からオフセットされるサブディレクトリとしてのユニットディレクトリ（Ｕｎｉｔ　Ｄｉｒｅｃｔｏｒｉｅｓ）１００４に格納される。ユニットディレクトリ１００４には、例えば、ノードのサポートするソフトウェアユニットに関する情報が格納される。具体的には、ノード間のデータ通信を行うためのデータ転送プロトコル、所定の通信手順を定義するコマンドセット等に関する情報が保持される。
【００６９】
又、図１０において、ノード依存情報ディレクトリ（Ｎｏｄｅ　Ｄｅｐｅｎｄｅｎｔ　Ｉｎｆｏ　Ｄｉｒｅｃｔｏｒｙ）１００３には、デバイス固有の情報を保持することが可能である。ノード依存情報ディレクトリ１００３は、ルートディレクトリ１００２によりオフセットされる。
【００７０】
更に、図１０において、ベンダー依存情報（Ｖｅｎｄｏｒ　Ｄｅｐｅｎｄｅｎｔ　Ｉｎｆｏｒｍａｔｉｏｎ）１００６には、ノードを製造、或いは販売するベンダ固有の情報を保持することができる。
【００７１】
残りの領域は、ユニット空間と呼ばれ、各ノード固有の情報、例えば、各機器の識別情報（会社名、機種名等）や使用条件等が格納されたアドレスを指定する。ユニット空間のシリアルバス装置レジスタに格納される情報のアドレス及び機能を図１１に示す。図中のオフセットは、「０ｘＦＦＦＦＦ００００８００」からの相対位置である。
【００７２】
尚、一般的に、異種のバスシステムの設計を簡略化したい場合、各ノードは、レジスタ空間の最初の２０４８バイトのみを使うべきである。つまり、ＣＳＲコア・レジスタ、シリアルバス・レジスタ、コンフィグレーションＲＯＭ、ユニット空間の最初の２０４８バイトの合わせて４０９６バイトで構成することが望ましい。
【００７３】
（４）通信ケーブルの構成
図１２にＩＥＥＥ１３９４規格に準拠した通信ケーブルの断面図を示す。
【００７４】
通信ケーブルは、２組のツイストペア信号線と電源ラインとにより構成されている。電源ラインを設けることによって、１３９４インタフェースは、主電源のＯＦＦとなった機器、故障により電力低下した機器等にも電力を供給することができる。尚、電源線内を流れる電源の電圧は８〜４０Ｖ、電流は最大電流ＤＣ１．５Ａと規定されている。
【００７５】
２組のツイストペア信号線には、ＤＳ−Ｌｉｎｋ（Ｄａｔａ／Ｓｔｒｏｂｅ　Ｌｉｎｋ）符号化方式にて符号化された情報信号が伝送される。図１３は、ＤＳ−Ｌｉｎｋ符号化方式を説明する図である。
【００７６】
このＤＳ−Ｌｉｎｋ符号化方式は、高速なシリアルデータ通信に適しており、その構成は、２組のより対線を必要とする。一組のより対線は、データ信号を送り、他のより対線は、ストローブ信号を送る構成になっている。受信側は、２組の信号線から受信したデータ信号とストローブ信号との排他的論理和をとることによって、クロックを再現することができる。
【００７７】
尚、ＤＳ−Ｌｉｎｋ符号化方式を用いることにより、１３９４インタフェースには、例えば次のような利点がある。▲１▼他の符号化方式に比べて転送効率が高い。▲２▼ＰＬＬ回路が不要となり、コントローラＬＳＩの回路規模を小さくできる。▲３▼アイドル状態であることを示す情報を送る必要が無いため、トランシーバ回路をスリープ状態とし易く、消費電力の低減を図ることができる。
【００７８】
（５）バスリセット
各ノードの１３９４インタフェースは、ネットワークの接続構成に変化が生じたことを自動的に検出することができる。この場合、１３９４ネットワークは以下に示す手順によりバスリセットと呼ばれる処理を行う。尚、接続構成の変化は、各ノードの具備する通信ポートにかかるバイアス電圧の変化により検知することができる。
【００７９】
ネットワークの接続構成の変化（例えば、ノードの挿抜、ノードの電源のＯＮ／ＯＦＦなどによるノード数の増減）を検出したノード、又は新たな接続構成を認識する必要のあるノードは、１３９４インタフェースを介して、バス上にバスリセット信号を送信する。
【００８０】
バスリセット信号を受信したノードの１３９４インタフェースは、バスリセットの発生を自身のリンク・レイヤ３０４に伝達すると共に、そのバスリセット信号を他のノードに転送する。バスリセット信号を受信したノードは、今まで認識していたネットワークの接続構成及び各機器に割り当てられたノードＩＤをクリアにする。最終的に全てのノードがバスリセット信号を検知した後、各ノードは、バスリセットに伴う初期化処理（即ち、新たな接続構成の認識と新たなノードＩＤの割り当て）を自動的に行う。
【００８１】
尚、バスリセットは、先に述べたような接続構成の変化による起動の他に、ホスト側の制御によって、アプリケーション・レイヤ３０７がフィジカル・レイヤ３０３に対して直接命令を出すことによって起動させることも可能である。
【００８２】
又、バスリセットが起動するとデータ転送は一時中断され、バスリセットに伴う初期化処理の終了後、新しいネットワークのもとで再開される。
【００８３】
（６）バスリセット起動後のシーケンス
バスリセットの起動後、各ノードの１３９４インタフェースは、新たな接続構成の認識と新たなノードＩＤの割り当てとを自動的に実行する。以下、バスリセットの開始からノードＩＤの割り当て処理までの基本的なシーケンスを図１４〜１６を用いて説明する。
【００８４】
図１４は、図２の１３９４ネットワークにおけるバスリセット起動後の状態を説明する図である。
【００８５】
図１４において、ノードＡは１つの通信ポート、ノードＢは２つの通信ポート、ノードＣは２つの通信ポート、ノードＤは３つの通信ポート、ノードＥは１つの通信ポート、ノードＦは１つの通信ポートを具備している。各ノードの通信ポートには、各ポートを識別するためにポート番号を付されている。
【００８６】
以下、図１４におけるバスリセットの開始からノードＩＤの割り当てまでを図１５のフローチャートを用いて説明する。
【００８７】
図１５において、１３９４ネットワークを構成する各ノードＡ〜Ｆは、バスリセットが発生したか否かを常時監視している（ステップＳ１５０１）。接続構成の変化を検出したノードからバスリセット信号が出力されると、各ノードは以下の処理を実行する。
【００８８】
バスリセットの発生後、各ノードは、夫々の具備する通信ポート間において親子関係の宣言を行なう（ステップＳ１５０２）。
【００８９】
各ノードは、全てのノード間の親子関係が決定されるまで、ステップＳ１５０２の処理を繰り返し行なう（ステップＳ１５０３）。
【００９０】
全てのノード間の親子関係が決定した後、１３９４ネットワークは、ネットワークの調停を行なうノード、即ちルートを決定する。（ステップＳ１５０４）。
【００９１】
ルートを決定した後、各ノードの１３９４インタフェース夫々は、自己のノードＩＤを自動的に設定する作業を実行する（ステップＳ１５０５）。
【００９２】
全てのノードに対してノードＩＤの設定がなされるまで、各ノードは所定の手順に基づきステップＳ１５０５の処理を実行する（ステップＳ１５０６）。
【００９３】
最終的に全てのノードに対してノードＩＤが設定された後、各ノードは、アイソクロナス転送或いはアシンクロナス転送を実行する（ステップＳ１５０７）。
【００９４】
ステップＳ１５０７の処理を実行すると共に、各ノードの１３９４インタフェースは、再びバスリセットの発生を監視する。バスリセットが発生した場合には、ステップＳ１５０１以降の処理を再び実行する。
【００９５】
以上の手順により、各ノードの１３９４インタフェースは、バスリセットが起動する毎に、新たな接続構成の認識と新たなノードＩＤの割り当てとを自動的に実行することができる。
【００９６】
（７）親子関係の決定
次に、図１６を用いて、図１５に示したステップＳ１５０２の処理（即ち、各ノード間の親子関係を認識する処理）について詳細に説明する。
【００９７】
図１６において、バスリセットの発生後、１３９４ネットワーク上の各ノードＡ〜Ｆは、自分の具備する通信ポートの接続状態（接続又は未接続）を確認する（ステップＳ１６０１）。
【００９８】
通信ポートの接続状態の確認後、各ノードは、他のノードと接続されている通信ポート（以下、接続ポート）の数をカウントする（ステップＳ１６０２）。
【００９９】
ステップＳ１６０２の処理の結果、接続ポートの数が１つである場合、そのノードは、自分が「リーフ」であると認識する（ステップＳ１６０３）。ここで、リーフとは、１つのノードとのみ接続されているノードのことである。
【０１００】
リーフとなるノードは、その接続ポートに接続されているノードに対して、「自分は子（Ｃｈｉｌｄ）」であることを宣言する（ステップＳ１６０４）。このとき、リーフは、その接続ポートが「親ポート（親ノードと接続された通信ポート）」であると認識する。
【０１０１】
ここで、親子関係の宣言は、まず、ネットワークの末端であるリーフとブランチとの間にて行われ、続いて、ブランチとブランチとの間で順次に行われる。各ノード間の親子関係は、早く宣言の行なえる通信ポートから順に決定される。又、各ノード間において、子であることを宣言した通信ポートは「親ポート」であると認識され、その宣言を受けた通信ポートは「子ポート（子ノードと接続された通信ポート）」であると認識される。例えば、図１４において、ノードＡ、Ｅ、Ｆは、自分がリーフであると認識した後、親子関係の宣言を行う。これにより、ノードＡ−Ｂ間では子−親、ノードＥ−Ｄ間では子−親、ノードＦ−Ｄ間では子−親と決定される。
【０１０２】
又、ステップＳ１６０２の処理の結果、接続ポートの数が２つ以上の場合、そのノードは、自分を「ブランチ」であると認識する（ステップＳ１６０５）。ここで、ブランチとは、２つ以上のノードと接続されているノードのことである。
【０１０３】
ブランチとなるノードは、各接続ポートのノードから親子関係の宣言を受け付ける（ステップＳ１６０６）。宣言を受け付けた接続ポートは、「子ポート」として認識される。
【０１０４】
１つの接続ポートを「子ポート」と認識した後、ブランチは、まだ親子関係の決定されていない接続ポート（即ち、未定義ポート）が２つ以上あるか否かを検出する（ステップＳ１６０７）。その結果、未定義ポートが２つ以上ある場合、ブランチは、再びステップＳ１６０６の動作を行う。
【０１０５】
ステップＳ１６０７の結果、未定義ポートが１つだけ存在する場合、ブランチは、その未定義ポートが「親ポート」であると認識し、そのポートに接続されているノードに対して「自分は子」であることを宣言する（ステップＳ１６０８、Ｓ１６０９）。
【０１０６】
ここで、ブランチは、残りの未定義ポートが１つになるまで自分自身が子であると他のノードに対して宣言することができない。例えば、図１４において、ノードＢ、Ｃ、Ｄは、自分がブランチであると認識すると共に、リーフ或いは他のブランチからの宣言を受け付ける。ノードＤは、Ｄ−Ｅ間、Ｄ−Ｆ間の親子関係が決定した後、ノードＣに対して親子関係の宣言を行っている。又、ノードＤからの宣言を受けたノードＣは、ノードＢに対して親子関係の宣言を行っている。
【０１０７】
又、ステップＳ１６０８の処理の結果、未定義ポートが存在しない場合（つまり、ブランチの具備する全ての接続ポートが親ポートとなった場合）、そのブランチは、自分自身がルートであることを認識する。（ステップＳ１６１０）。
【０１０８】
例えば、図１４において、接続ポートの全てが親ポートとなったノードＢは、１３９４ネットワーク上の通信を調停するルートとして他のノードに認識される。ここで、ノードＢがルートと決定されたが、ノードＢの親子関係を宣言するタイミングが、ノードＣの宣言するタイミングに比べて早い場合には、他のノードがルートになる可能性もある。即ち、宣言するタイミングによっては、どのノードもルートとなる可能性がある。従って、同じネットワーク構成であっても同じノードがルートになるとは限らない。
【０１０９】
このように全ての接続ポートの親子関係が宣言されることによって、各ノードは、１３９４ネットワークの接続構成を階層構造（ツリー構造）として認識することができる（ステップＳ１６１１）。尚、上述の親ノードは階層構造における上位であり、子ノードは階層構造における下位となる。
【０１１０】
（８）ノードＩＤの割り当て
図１７は、図１５に示したステップＳ１５０５の処理（即ち、自動的に各ノードのノードＩＤを割り当てる処理）を詳細に説明するフローチャートである。ここで、ノードＩＤは、バス番号とノード番号とから構成されるが、本実施の形態では、各ノードを同一バス上に接続するものとし、各ノードには同一のバス番号が割り当てられるものとする。
【０１１１】
図１７において、ルートは、ノードＩＤが未設定のノードが接続されている子ポートの内、最小番号を有する通信ポートに対してノードＩＤの設定許可を与える（ステップＳ１７０１）。
【０１１２】
尚、図１７において、ルートは、最小番号の子ポートに接続されている全ノードのノードＩＤを設定した後、その子ポートを設定済とし、次に最小となる子ポートに対して同様の制御を行なう。最終的に子ポートに接続された全てのノードのＩＤ設定が終了した後、ルート自身のノードＩＤを設定する。尚、ノードＩＤに含まれるノード番号は、基本的にリーフ、ブランチの順に０、１、２…と割り当てられる。従って、ルートが最も大きなノード番号を有することになる。
【０１１３】
ステップＳ１７０１において、設定許可を得たノードは、自分の子ポートの内、ノードＩＤが未設定となるノードを含む子ポートがあるか否かを判断する（ステップＳ１７０２）。
【０１１４】
ステップＳ１７０２において、未設定ノードを含む子ポートが検出された場合、上述の設定許可を得たノードは、その子ポートに直接接続されたノードに対してその設定許可を与えるように制御する（ステップＳ１７０３）。
【０１１５】
ステップＳ１７０３の処理後、上述の設定許可を得たノードは、自分の子ポートの内、ノードＩＤが未設定であるノードを含む子ポートがあるか否かを判断する（ステップＳ１７０４）。ここで、ステップＳ１７０４の処理後、未設定ノードを含む子ポートの存在が検出された場合、そのノードは、再びステップＳ１７０３の処理を実行する。
【０１１６】
又、ステップＳ１７０２或いはＳ１７０４において、未設定ノードを含む子ポートが検出されなかった場合、設定許可を得たノードは、自分自身のノードＩＤを設定する（ステップＳ１７０５）。
【０１１７】
自分のノードＩＤを設定したノードは、自己のノード番号、通信ポートの接続状態に関する情報等を含んだセルフＩＤパケットをブロードキャストする（ステップＳ１７０６）。尚、ブロードキャストとは、あるノードの通信パケットを、１３９４ネットワークを構成する不特定多数のノードに対して転送することである。
【０１１８】
ここで、各ノードは、このセルフＩＤパケットを受信することにより、各ノードに割り当てられたノート番号を認識することができ、自分に割り当てられるノード番号を知ることができる。例えば、図１４において、ルートであるノードＢは、最小ポート番号「＃１」の通信ポートに接続されたノードＡに対してノードＩＤ設定の許可を与える。ノードＡは、自己のノード番号「Ｎｏ．０」と割り当て、自分自身に対してバス番号とノード番号とからなるノードＩＤを設定する。又、ノードＡは、そのノード番号を含むセルフＩＤパケットをブロードキャストする。
【０１１９】
図１８にセルフＩＤパケットの構成例を示す。図１８において、１８０１はセルフＩＤパケットを送出したノードのノード番号を格納するフィールド、１８０２は対応可能な転送速度に関する情報を格納するフィールド、１８０３はバス管理機能（バスマネージャの能力の有無等）の有無を示すフィールド、１８０４は電力の消費及び供給の特性に関する情報を格納するフィールドである。
【０１２０】
又、図１８において、１８０５はポート番号「＃０」となる通信ポートの接続状態に関する情報（接続、未接続、通信ポートの親子関係等）を格納するフィールド、１８０６はポート番号「＃１」となる通信ポートの接続状態に関する情報（接続、未接続、通信ポートの親子関係等）を格納するフィールド、１８０７はポート番号「＃２」となる通信ポートの接続状態に関する情報（接続、未接続、通信ポートの親子関係等）を格納するフィールドである。
【０１２１】
尚、セルフＩＤパケットを送出するノードにバスマネージャとなり得る能力がある場合には、フィールド１８０３に示すコンテンダビットを「１」とし、なり得る能力がなければ、コンテンダビットを０とする。
【０１２２】
ここで、バスマネージャとは、上述のセルフＩＤパケットに含まれる各種の情報に基づいて、バスの電源管理（通信ケーブルを介して電源の供給が可能か否か、電源の供給が必要か否か等の情報を各ノード毎に管理する）、速度情報の管理（各ノードの対応可能な転送速度に関する情報から各ノード間の最大転送速度を管理する）、トポロジ・マップ情報の管理（通信ポートの親子関係情報からネットワークの接続構成を管理する）、トポロジ・マップ情報に基づくバスの最適化等を行ない、それらの情報を他のノードに提供する機能を有するノードである。これらの機能により、バスマネージャとなるノードは１３９４ネットワーク全体のバス管理を行なうことができる。
【０１２３】
ステップＳ１７０６の処理後、ノードＩＤの設定を行ったノードは、親ノードがあるか否かを判断する（ステップＳ１７０７）。親ノードがある場合、その親ノードが、ステップＳ１７０２以下の処理を再び実行する。そして、まだノードＩＤの設定されていないノードに対して許可を与える。
【０１２４】
又、親ノードが存在しない場合、そのノードは、ルート自身であると判断される。ルートは、全ての子ポートに接続されたノードに対してノードＩＤが設定されたか否かを判別する（ステップＳ１７０８）。
【０１２５】
ステップＳ１７０８において、全てのノードに対するＩＤ設定処理が終了しなかった場合、ルートは、そのノードを含む子ポートの内、最小番号となる子ポートに対してＩＤ設定の許可を与える（ステップＳ１７０１）。その後、ステップＳ１７０２以下の処理を実行する。
【０１２６】
又、全てのノードに対するＩＤ設定処理が終了した場合、ルートは、自分自身のノードＩＤの設定を実行する（ステップＳ１７０９）。ノードＩＤの設定後、ルートは、セルフＩＤパケットをブロードキャストする（ステップＳ１７１０）。
【０１２７】
以上の処理によって、１３９４ネットワークは、各ノードに対して自動的にノードＩＤを割り当てることができる。
【０１２８】
ここで、ノードＩＤの設定処理後、複数のノードがバスマネージャの能力を具備する場合、ノード番号の最も大きいノードがバスマネージャとなる。つまり、ネットワーク内で最大となるノード番号を持つルートがバスマネージャになり得る機能を有している場合には、ルートがバスマネージャとなる。
【０１２９】
しかしながら、ルートにその機能が備わっていない場合には、ルートの次に大きいノード番号を具備するノードがバスマネージャとなる。又、どのノードがバスマネージャになったかについては、各ノードがブロードキャストするセルフＩＤパケット内のコンテンダビット１８０３をチェックすることにより把握することができる。
【０１３０】
（９）アービトレーション
図１９は、図１の１３９４ネットワークにおけるアービトレーションを説明する図である。
【０１３１】
１３９４ネットワークでは、データ転送に先立って、必ずバス使用権のアービトレーション（調停）を行なう。１３９４ネットワークは、論理的なバス型ネットワークであり、各ノードから転送された通信パケットを他のノードに中継することによって、ネットワーク内の全てのノードに同じ通信パケットを転送することのできる。従って、通信パケットの衝突を防ぐために、必ずアービトレーションが必要となる。これによって、ある時間において一つのノードのみが転送を行なうことができる。
【０１３２】
図１９（ａ）は、ノードＢとノードＦとが、バス使用権の要求を発している場合について説明する図である。
【０１３３】
アービトレーションが始まるとノードＢ、Ｆは、夫々親ノードに向かって、バス使用権の要求を発する。ノードＢの要求を受けた親ノード（即ち、ノードＣ）は、自分の親ノード（即ち、ノードＤ）に向かって、そのバス使用権を中継する。この要求は、最終的に調停を行なうルート（ノードＤ）に届けられる。
【０１３４】
バス使用要求を受けたルートは、どのノードにバスを使用させるかを決める。この調停作業はルートとなるノードのみが行なえるものであり、調停によって勝ったノードにはバスの使用許可が与えられる。
【０１３５】
図１９（ｂ）は、ノードＦの要求が許可され、ノードＢの要求が拒否されたことを示す図である。
【０１３６】
アービトレーションに負けたノードに対してルートは、ＤＰ（Ｄａｔａ　ｐｒｅｆｉｘ）パケットを送り、拒否されたことを知らせる。拒否されたノードは、次回のアービトレーションまでバス使用要求を待機する。
【０１３７】
以上のようにアービトレーションを制御することによって、１３９４ネットワークは、バスの使用権を管理することができる。
【０１３８】
（１０）通信サイクル
アイソクロナス転送モードとアシンクロナス転送モードとは、各通信サイクル期間内において時分割に混在させることができる。ここで、通信サイクルの期間は、通常、１２５μＳである。
【０１３９】
図２０は、１通信サイクルにおいてアイソクロナス転送モードとアシンクロナス転送モードとを混在させた場合を説明する図である。
【０１４０】
アイソクロナス転送モードは、アシンクロナス転送モードより優先して実行される。その理由は、サイクル・スタート・パケットの後、アシンクロナス転送を起動するために必要なアイドル期間（ｓｕｂａｃｔｉｏｎ　ｇａｐ）が、アイソクロナス転送を起動するため必要なアイドル期間（ｉｓｏｃｈｒｏｎｏｕｓ　ｇａｐ）よりも長くなるように設定されているためである。これにより、アイソクロナス転送は、アシンクロナス転送に優先して実行される。
【０１４１】
図２０において、各通信サイクルのスタート時には、サイクル・スタート・パケット（以下、ＣＳＰ）が所定のノードから転送される。各ノードは、このＣＳＰを用いて時刻調整を行うことによって、他のノードと同じ時間を計時することができる。
【０１４２】
（１１）アイソクロナス転送モード
アイソクロナス転送モードは、同期型の転送方式である。アイソクロナスモード転送は、通信サイクルの開始後、所定の期間において実行可能である。又、アイソクロナス転送モードは、リアルタイム転送を維持するために、各サイクル毎に必ず実行される。
【０１４３】
アイソクロナス転送モードは、特に動画像データや音声データ等のリアルタイムな転送を必要とするデータの転送に適した転送モードである。アイソクロナス転送モードは、アシンクロナス転送モードのように１対１の通信ではなく、ブロードキャスト通信である。つまり、あるノードから送出されたパケットは、ネットワーク上の全てのノードに対して一様に転送される。尚、アイソクロナス転送には、ａｃｋ（受信確認用返信コード）は存在しない。
【０１４４】
図２０において、チャネルｅ（ｃｈ　ｅ）、チャネルｓ（ｃｈ　ｓ）、チャネルｋ（ｃｈｋ）は、各ノードがアイソクロナス転送を行う期間を示す。１３９４インタフェースでは、複数の異なるアイソクロナス転送を区別するために、夫々異なるチャネル番号を与えている。これにより、複数ノード間でのアイソクロナス転送が可能となる。ここで、このチャネル番号は、送信先を特定するものではなく、データに対する論理的な番号を与えているに過ぎない。
【０１４５】
又、図２０に示したアイソクロナス　ｇａｐとは、バスのアイドル状態を示すものである。このアイドル状態が一定時間を経過した後、アイソクロナス転送を希望するノードは、バスが使用できると判断し、アービトレーションを実行する。
【０１４６】
次に、図２１にアイソクロナス転送モードに基づいて転送される通信パケットのフォーマットを示す。以下、アイソクロナス転送モードに基づいて転送される通信パケットを、アイソクロナスパケットと称する。
【０１４７】
図２１において、アイソクロナスパケットはヘッダ部２１０１、ヘッダＣＲＣ２１０２、データ部２１０３、データＣＲＣ２１０４から構成される。
【０１４８】
ヘッダ部２１０１には、データ部２１０３のデータ長を格納するフィールド２１０５、アイソクロナスパケットのフォーマット情報を格納するフィールド２１０６、アイソクロナスパケットのチャネル番号を格納するフィールド２１０７、パケットのフォーマット及び実行しなければならない処理を識別するトランザクションコード（ｔｃｏｄｅ）を格納するフィールド２１０８、同期化コードを格納するフィールド２１０９がある。
【０１４９】
（１２）アシンクロナス転送モード
アシンクロナス転送モードは、非同期型の転送方式である。アシンクロナス転送は、アイソクロナス転送期間の終了後、次の通信サイクルが開始されるまでの間（即ち、次の通信サイクルのＣＳＰが転送されるまでの間）、実行可能である。
【０１５０】
図２０において、最初のサブアクション・ギャップ（ｓｕｂａｃｔｉｏｎ　ｇａｐ）は、バスのアイドル状態を示すものである。このアイドル時間が一定値になった後、アシンクロナス転送を希望するノードは、バスが使用できると判断し、アービトレーションを実行する。
【０１５１】
アービトレーションによりバスの使用権を得たノードは、図２２に示すパケットを所定のノードに対して転送する。このパケットを受信したノードは、ａｃｋ（受信確認用返送コード）或いは応答パケットをａｃｋ　ｇａｐ後に返送する。
【０１５２】
図２２は、アシンクロナス転送モードに基づく通信パケットのフォーマットを示す図である。以下、アシンクロナス転送モードに基づいて転送される通信パケットを、アシンクロナスパケットと称する。
【０１５３】
図２２において、アシンクロナスパケットは、ヘッダ部２２０１、ヘッダＣＲＣ２２０２、データ部２２０３、データＣＲＣ２２０４から構成される。
【０１５４】
ヘッダ部２２０１において、フィールド２２０５には宛先となるノードのノードＩＤ、フィールド２２０６にはソースとなるノードのノードＩＤ、フィールド２２０７には一連のトランザクションを示すためのラベル、フィールド２２０８には再送ステータスを示すコード、フィールド２２０９にはパケットのフォーマット及び実行しなければならない処理を識別するトランザクションコード（ｔｃｏｄｅ）、フィールド２２１０には優先順位、フィールド２２１１には宛先のメモリ・アドレス、フィールド２２１２にはデータ部のデータ長、フィールド２２１３には拡張されたトランザクション・コードが格納される。
【０１５５】
又、アシンクロナス転送は、自己ノードから相手ノードへの１対１の通信である。転送元ノードから転送されたパケットは、ネットワーク中の各ノードに行き渡るが、自分宛てのアドレス以外のものは無視される。従って、宛先となるノードのみが、そのパケットを読み込むことができる。
【０１５６】
尚、アシンクロナス転送中に次のＣＳＰを転送すべき時間に至った場合、無理に転送を中断せず、その転送が終了した後、次のＣＳＰを送信する。これにより、１つの通信サイクルが１２５μＳ以上続いたときは、その分、次の通信サイクル期間を短縮する。このようにすることによって、１３９４ネットワークは、ほぼ一定の通信サイクルを保持することができる。
【０１５７】
（１３）デバイスマップ
デバイスマップを作成するためにアプリケーションが１３９４ネットワークのトポロジーを知る手段として、ＩＥＥＥ１３９４規格上は以下の手段がある。
【０１５８】
１．バスマネージャーのトポロジーマップレジスターをリードする
２．バスリセット時にセルフＩＤパケットから推定する
しかし上記１、２の手段では、各ノードの親子関係によるケーブル接続順のトポロジーは判明するものの、物理的な位置関係のトポロジーを知ることはできない（実装されていないポートまで見えてしまう、といった問題もある）。
【０１５９】
また、デバイスマップを作成するための情報を、コンフィギュレーションＲＯＭ以外のデータベースとして持つ、といった手段もあるが、その場合、各種情報を得る手段はデータベースアクセスのためのプロトコルに依存してしまう。
【０１６０】
ところで、コンフィギュレーションＲＯＭ自体やコンフィギュレーションＲＯＭを読む機能は、ＩＥＥＥ１３９４規格を遵守したデバイスが必ず持つものである。そこで、デバイスの位置、機能等の情報を各ノードのコンフィギュレーションＲＯＭに格納し、それらをアプリケーションから読む機能を与えることにより、データベースアクセス、データ転送等の特定のプロトコルに依存することなく、各ノードのアプリケーションがいわゆるデバイスマップ表示機能を実装することができる。
【０１６１】
すなわち、コンフィグレーションＲＯＭにはノード固有の情報として物理的な位置、機能などが格納可能であり、デバイスマップ表示機能の実現に使用することが可能である。
【０１６２】
この場合、アプリケーションが物理的な位置関係による１３９４ネットワークトポロジーを知る手段としては、バスリセット時やユーザからの要求時に、各ノードのコンフィギュレーションＲＯＭを読み取ることにより、１３９４ネットワークのトポロジーを知る、という方法が可能となる。さらに、コンフィギュレーションＲＯＭ内にノードの物理的位置のみならず、機能などの各種ノード情報も記述すれば、コンフィギュレーションＲＯＭを読むことで、ノードの物理的位置と同時に各ノードの機能情報等も得ることができる。アプリケーションが各ノードのコンフィギュレーションＲＯＭ情報を取得する際には、指定ノードの任意のコンフィギュレーションＲＯＭ情報を取得するＡＰＩを用いる。
【０１６３】
このような手段を用いることにより、ＩＥＥＥ１３９４ネットワーク上のデバイスのアプリケーションは、物理的なトポロジーマップ、各ノードの機能マップなど、用途に応じて様々なデバイスマップを作成することができ、ユーザが必要な機能をもつデバイスを選択する、といったことも可能となる。
【０１６４】
（１４）ＳＢＰ−２の概要
ＳＢＰ−２（Ｓｅｒｉａｌ　Ｂｕｓ　Ｐｒｏｔｏｃｏｌ２）は、ＮＣＩＴＳ傘下のＴｅｃｈｎｉｃａｌ　Ｃｏｍｍｉｔｔｅｅ　Ｔ１０のプロジェクトとして１９９６より標準化の審議が進められ、１９９８年にＡＮＳＩ　ＮＣＩＴＳ　３２５−１９９８として標準化が認可された、ＩＥＥＥ１３９４バスに関するプロトコルである。レイヤとしては、ＩＥＥＥ１３９４−１９９５のトランザクション層の上位に位置するコマンド／データ転送プロトコルである。当初ＳＢＰ−２は、ＳＣＳＩコマンドによって、ＩＥＥＥ１３９４上のデバイスを動作させることを、主な目的として開発されたが、ＳＣＳＩコマンドに限らず、他のコマンドを載せることもできる。
【０１６５】
ＳＢＰ−２の特徴として以下の４つが挙げられる。
【０１６６】
１）イニシエータ（Ｉｎｉｔｉａｔｏｒ）／ターゲット（Ｔａｒｇｅｔ）構成のマスタスレイブモデル（Ｍａｓｔｅｒ　Ｓｌａｖｅ　Ｍｏｄｅｌ）であり、マスタであるイニシエータがログイン、ログアウト、タスク、マネージメント、コマンド発行等の全ての権限と責任を持つ。
【０１６７】
２）バスモデルとしてのＩＥＥＥ１３９４の特徴を生かした共有メモリモデル（Ｓｈａｒｅｄ　Ｍｅｍｏｒｙ　Ｍｏｄｅｌ）である。コマンド等のターゲットへの要求内容は、基本的には全てシステムメモリ内に置かれ、要求を受けたターゲットがシステムメモリの内容を読みに行く。又は、システムメモリへ要求されたステータス等の情報を書きこむ。
【０１６８】
即ち、通信のためのリソースを一箇所に集中できるので、リソースの負担を非常に軽くでき、かつターゲットが自分のペースでシステムメモリへ読み書きできるので、ターゲットの設計の自由度が高く、システムメモリのアクセスをＨ／Ｗ化することにより高速化が容易である。つまり、高性能にも、徹底した低コストモデルにもできる。
【０１６９】
３）メッセージ交換のためのコマンド群を一連のリンクリストとして記述する仕組みがあるため、レイテンシによる効率低下を隠蔽できるため、ＩＥＥＥ１３９４バスの特徴を生かした、高速で効率の高いデータ通信を実現できる。
【０１７０】
４）コマンドセットに依存しない構造である。つまり様々なコマンドセットに対応可能である。
【０１７１】
特徴１）に示したように、ＳＢＰ−２はマスタであるイニシエータが全ての権限と責任を持つマスタスレイブモデルであるため、全てはイニシエータからの動作をトリガーにして行われる。イニシエータからのログイン、ログアウト要求やタスクマネージメント要求、コマンド等は、ＯＲＢ（Ｏｐｅｒａｔｉｏｎ　Ｒｅｑｕｅｓｔ　Ｂｌｏｃｋ）と呼ぶデータ構造に内包された形でターゲットに送られる。正しくは、イニシエータが自メモリに置き、ターゲットがそれを読み出す。図２３に、主なＯＲＢの種類を示す。
【０１７２】
１）ダミーＯＲＢ：ターゲットフェッチエージェントのイニシャライズ時、タスクのキャンセル等に使用する。ターゲットにはｎｏ　ｏｐｅｒａｔｉｏｎとして扱われる。
【０１７３】
２）コマンドブロックＯＲＢ：データ転送コマンド、デバイス制御コマンド等のコマンドを内包するＯＲＢである。詳細を図２４に示す。対応するデータバッファ又はページテーブルのアドレス及びサイズを示すデータディスクリプタ（ｄａｔａ＿ｄｅｓｃｒｉｐｔｏｒ）、データサイズフィールド（ｄａｔａ＿ｓｉｚｅ）を有する。また、次のコマンドブロックＯＲＢのアドレスを示すネクストＯＲＢフィールド（ｎｅｘｔ＿ＯＲＢ）を有するので、コマンドをリンクできるのが特徴である。
【０１７４】
３）マネージメントＯＲＢ：マネージメント要求（ログイン、ログアウトを含むアクセス要求、及びタスクマネージメント要求）を内包するＯＲＢである。詳細を図２５に示す。タスクマネージメントの要求内容（アボートタスクセット（Ａｂｏｒｔ　Ｔａｓｋ　Ｓｅｔ）、ターゲットリセット等）を示すファンクションフィールド（ｆｕｎｃｔｉｏｎ）と、ターゲットからの完了ステータスのアドレスを示すステータスＦＩＦＯ（Ｓｔａｔｕｓ＿ＦＩＦＯ）のフィールドを有するのが特徴である。
【０１７５】
この内、マネージメントＯＲＢについては、イニシエータは、ターゲットが応答を返すまで次のＯＲＢを発行することができない。一方、ダミーＯＲＢを含むコマンドブロックＯＲＢには、図２４のようにネクストＯＲＢフィールドとして次のＯＲＢのアドレスを指示するフィールドがあるため、次々とコマンドを連結し、図２６のようにリンクリストの形で一連のコマンド列を発行することができる。このネクストＯＲＢフィールドがｎｕｌｌの場合は、次に続くＯＲＢがないことを示す。
【０１７６】
また、このコマンドブロックＯＲＢの他のフィールドにはデータバッファ又はページテーブルのアドレス及びサイズを示すフィールド（データディスクリプタ及びデータサイズ）があり、例えばコマンドの内容がライトコマンドならば、ターゲットはデータディスクリプタで示されたシステムメモリ上のデータバッファにアクセスし、そこからライトデータを読みこむ。また、コマンドの内容がリードコマンドならば、ターゲットはデータディスクリプタで示されたシステムメモリ上のデータバッファにアクセスし、そこへコマンドの要求するデータを書きこむ。
【０１７７】
図２７及び図２８に、データバッファを直接示す場合と、ページテーブルを経由する場合を示す。物理的に不連続な領域のデータバッファを、ページテーブルにより、連続的に扱うことができ、仮想記憶による連続論理領域を物理的に再配置する必要がなくなるわけである。
【０１７８】
イニシエータからの様々な要求を実行するターゲット側の仕組みを、エージェント（Ａｇｅｎｔ）と称する。エージェントには、マネージメントＯＲＢを実行するマネージメントエージェントと、コマンドブロックＯＲＢを実行するコマンドブロックエージェントがある。
【０１７９】
マネージメントエージェントには、マネージメントＯＲＢのアドレスをイニシエータがターゲットに知らせるためにストアする、マネージメントエージェントレジスタがある。
【０１８０】
コマンドブロックエージェントは、イニシエータのコマンドリンクリストからコマンドをフェッチしてくるため、フェッチエージェントとも呼ばれる。フェッチエージェントにも、コマンドブロックＯＲＢの先頭アドレスをイニシエータがストアするＯＲＢポインタレジスタと、イニシエータがターゲットにコマンドをＦｅｔｃｈして貰いたいことを知らせるドアベルレジスタ等を含む、コマンドブロックエージェントレジスタがある。
【０１８１】
ターゲットはイニシエータからのＯＲＢの実行を完了すると、その実行完了のステータスを、ステータスブロックと言うデータ構造の形で（完了の成否に拘らず）イニシエータのステータスＦＩＦＯの示すアドレスにストアする。ステータスブロックの例を、図２９に示す。
【０１８２】
ターゲットは最低８バイト、最大３２バイトのステータス情報をストアすることができる。マネージメントＯＲＢの場合は、図２５のステータスＦＩＦＯフィールドにＯＲＢの一部として明示的にステータスＦＩＦＯアドレスが提供されるので、ターゲットは指定されたアドレスにステータスブロックをストアする。それ以外の場合は、フェッチエージェントのコンテキストから得られるステータスＦＩＦＯにステータスブロックをストアする。コマンドブロックＯＲＢの場合は、イニシエータはステータスＦＩＦＯアドレスをログイン要求の一部として提供する。
【０１８３】
通常ターゲットは、イニシエータの発するＯＲＢに対してステータスＦＩＦＯアドレスにステータスブロックを書き込むことによって応答するが、デバイス側に変化が発生し、ロジカルユニットに影響する場合は、イニシエータからの要求が無くても自発的にアンソリシテッドステータス（Ｕｎｓｏｌｉｃｉｔｅｄ　Ｓｔａｔｕｓ）を返すこともできる。この場合のステータスＦＩＦＯアドレスは、イニシエータからのログイン要求の際にイニシエータから提供されるステータスＦＩＦＯアドレスである。
【０１８４】
ＳＢＰ−２におけるイニシエータとターゲットの動作を、図３０の動作モデルを用いて説明する。
【０１８５】
ＳＢＰ−２の動作は、イニシエータが、ターゲットに対してログイン要求のためのマネージメントＯＲＢ（ログインＯＲＢ）を発行することから始まる。ターゲットは、イニシエータからの要求に対してログインレスポンスで応える。
【０１８６】
ログイン要求が受け入れられると、ターゲットからはログインレスポンスとしてコマンドブロックエージェントレジスタの先頭アドレスがかえされる。
【０１８７】
ログイン要求が受け入れられると、ターゲットのマネージメントエージェントは、イニシエータからのその後のタスクマネージメント要求を受け付ける。イニシエータは、タスクマネージメントＯＲＢを発行して、タスクの実行に必要な情報のやり取りをターゲットとの間で行う。ターゲットはイニシエータの発するＯＲＢに対してステータスＦＩＦＯにステータスブロックを書き込むことによって応答するが、デバイス側に変化が発生し、ロジカルユニットに影響する場合は、イニシエータからの要求が無くても自主的にアンソリシテッドステータスを返すこともできることは前述の通りである。
【０１８８】
タスクマネージメントに関するやり取りに続いて、イニシエータは必要なコマンドブロックＯＲＢ（ｌｉｓｔ）を自分のメモリ領域に形成する。そして、図３１のように、ターゲットのコマンドブロックエージェントレジスタのＯＲＢポインタにＯＲＢの先頭アドレスを書きこむか又はコマンドブロックエージェントレジスタのドアベルレジスタを叩いて、ターゲットに対して通信すべきＯＲＢがイニシエータにあることを知らせる。
【０１８９】
これに応じて、ターゲットは、図３２のように、ＯＲＢポインタに書かれたＯＲＢの先頭アドレス情報をもとにイニシエータのメモリにアクセスし、ＯＲＢを順次処理する。
【０１９０】
ところで、タスクの実行モデルには、オーダードモデルとアンオーダードモデルがある。オーダードモデルでは、ＯＲＢはリストの順番に沿って行われ、ターゲットの完了ステータスも順番に返される。アンオーダードモデルでは、ＯＲＢの実行順位に制約は無いが、どの順位でも最終的に同じ実行結果が得られるようにイニシエータが責任を持たなければならない。
【０１９１】
イニシエータからターゲットへのデータ転送はターゲットからシステムメモリへのリードトランザクションによって行われ、一方ターゲットからイニシエータへのデータ転送は、システムメモリへのライトトランザクションによって行われる。即ちデータバッファの転送は方向によらずターゲットが主導する。逆に言えば、ターゲットは自分に都合の良いペースでシステムメモリからのデータを読み出すことができる訳である。イニシエータはターゲットがＯＲＢを実行中でも、リストの最後のＯＲＢのネクストアドレスを次のＯＲＢのアドレスに書き換え、ターゲットのドアベルレジスタを再び叩いてターゲットに変更を知らせることにより、リンクリストにＯＲＢを追加することができる。ターゲットは、イニシエータのステータスＦＩＦＯのアドレスに完了ステータス（ステータスブロック）を返す。イニシエータは完了ステータス（ステータスブロック）が返されたのを見て、その対象ＯＲＢのターゲットによる実行が完了したことを知る。完了したＯＲＢは、（ネクストＯＲＢフィールドがｎｕｌｌでなければ）タスクセットのリンクリストから外すことができる、イニシエータはその空いたリソースを利用して、必要なら次のコマンドをコマンドリンクリストの最後に追加しても良い。
【０１９２】
このようにしてＯＲＢが実行されタスクが実行される。
【０１９３】
タスクが終了し、アクセスをつづける必要が無い場合は、イニシエータはログアウトＯＲＢを発行し、ターゲットが応えてログアウトが完了する。
【０１９４】
（１５）ＳＢＰ−３の概要
ＳＢＰ−３（Ｓｅｒｉａｌ　Ｂｕｓ　Ｐｒｏｔｏｃｏｌ３）は、ＳＢＰ−２を拡張し機能を追加することによりＳＢＰ−２において効率が悪かった点、欠いていた機能を補充する目的で２０００年後半から規格化作業が行なわれている。
【０１９５】
ＳＢＰ−３において拡張された代表的な機能を挙げると以下の通りになる。
１．アイソクロナスデータ転送機能
２．デバイスハンドルによるイニシエータ／ターゲット特定にとるノードＩＤ非依存機能
３．１つのＯＲＢ内の双方向データ転送機能
ここでは上記機能のうち３について説明する。
【０１９６】
ＳＢＰ−３はＳＢＰ−２と下位互換性を持っており、その基本的なデータ転送シーケンスはＳＢＰ−２の概要で説明した通りである。すなわち、イニシエータからターゲットへのデータ転送はターゲットからシステムメモリへのリードトランザクションによって行われ、一方ターゲットからイニシエータへのデータ転送は、システムメモリへのライトトランザクションによって行われる。ターゲットは自分に都合の良いペースでＯＲＢを読み出し、ＯＲＢの内容をデコードすることによって転送動作の種別情報を知る。ターゲットはＯＲＢに対応する転送動作がイニシエータからターゲットへのデータ転送か、ターゲットからイニシエータへのデータ転送なのか、そしてその転送動作がイニシエータ内のどのシステムメモリ領域に対して行なわれるか、をデコードし、該当する転送動作を行なう。またターゲットはそのＯＲＢで指定された転送動作を完了した際には、イニシエータのステータスＦＩＦＯのアドレスに完了ステータス（ステータスブロック）を返す。
【０１９７】
ＳＢＰ−３ではコマンドブロックＯＲＢ、つまり、データ転送コマンド、デバイス制御コマンド等のコマンドを内包するＯＲＢを２種類定義している。ひとつはコマンドブロックＯＲＢが有するリクエストフォーマットフィールドの値が０のものであり、ＳＢＰ−２で定義されたコマンドブロックＯＲＢと同一のものである。「（１４）ＳＢＰ−２の概要」で説明したように、ＯＲＢが参照するデータバッファ又はページテーブルのアドレス及びサイズを示すデータディスクリプタ、データサイズフィールド、次のコマンドブロックＯＲＢのアドレスを示すネクストＯＲＢフィールド、そしてデータバッファに対するデータ転送方向を示すディレクションフィールドに代表されるデータ転送に関わるパラメータを指定するフィールドからなる。
【０１９８】
ＳＢＰ−３で新規に定義されたコマンドブロックＯＲＢはリクエストフォーマットフィールドの値が１となっており従来のＯＲＢと区別がつけられる。
【０１９９】
このＯＲＢの特徴は１つのＯＲＢから２つのデータバッファが参照されるということである。
【０２００】
データバッファ又はページテーブルのアドレス及びサイズを示すデータディスクリプタ、データサイズフィールド、ディレクションフィールド等データバッファに関するフィールドがそれぞれ２組用意され、これによりＯＲＢから２つのデータバッファの参照が可能となる。
【０２０１】
このＯＲＢを使用し、一つのデータバッファはターゲットへのライト用バッファ、もう一方のデータバッファはターゲットからのリード用バッファとして使うことにより双方向ＯＲＢとして活用することができる。
【０２０２】
イニシエータは必要なコマンドブロックＯＲＢリストを自分のメモリ領域に形成し、上記のように双方向ＯＲＢをアペンドしてターゲットのコマンドブロックエージェントレジスタのＯＲＢポインタにＯＲＢリストの先頭アドレスを書きこむか又はコマンドブロックエージェントレジスタのドアベルレジスタを叩いて、ターゲットに対して通信すべきＯＲＢがイニシエータにあることを知らせる。ターゲットは、ＯＲＢポインタに書かれたＯＲＢの先頭アドレス情報をもとにイニシエータのメモリにアクセスし、ＯＲＢをフェッチし、順次処理する。
【０２０３】
双方向ＯＲＢをフェッチしたターゲットは指定された２つのデータバッファそれぞれに対してデータ転送処理を行なう。片側のバッファに対応するディレクションフィールドは０となっていて、ターゲットはデータディスクリプタで示されたシステムメモリ上のデータバッファにアクセスし、そこからライトデータを読みこむ。またもう片方のバッファに対応するディレクションフィールドは１となっていてターゲットはデータディスクリプタで示されたシステムメモリ上のデータバッファにアクセスし、そこへコマンドの要求するデータを書きこむ。
【０２０４】
両方のデータバッファアクセスが完了するとターゲットはイニシエータのステータスＦＩＦＯのアドレスに完了ステータス（ステータスブロック）を返し、そのＯＲＢの実行完了を通知する。
【０２０５】
図３３は、ＳＢＰ−３でのコマンドブロックＯＲＢの動作を示す図である。図３２で示したＳＢＰ−２と比較すると、ＳＢＰ−３では１つのＯＲＢに対してデータバッファアクセスを示す線が２本になっており、ＳＢＰ−２が１つのデータバッファへのアクセスしかできなかった点が変更されている。２つのデータバッファに独立してアクセスできることにより、イニシエータからターゲットへの２つのデータチャネルを１つのＯＲＢに当てはめることができる。データバッファへのデータの流れる方向はそれぞれのデータバッファで規定できる。つまり、２つのデータチャネルをイニシエータからターゲットへのデータ送信に用いることもできるし、一方をイニシエータからターゲットへのデータ送信、他方をターゲットからイニシエータへのデータ送信に用いることもできる。また、もちろん、ターゲットからイニシエータへのデータ送信に２つのデータチャネルを用いることもできる。更に、ホストとプリンタで使うような場合、一方をホストからプリンタへの印字データのために使い、他方をプリンタからホストへのステータス情報を流すために使うことも可能となる。
【０２０６】
図３４にＳＢＰ−３の２つのデータバッファを保持する場合のコマンドブロックＯＲＢの詳細を示している。ＳＢＰ−２と異なり、２組のデータバッファを扱えるようにするために、２つのデータディスクリプタと２つのバッファ情報フィールドが用意されている。図中”ｄ”で示したフィールドにそれぞれのデータバッファの方向を指定することができる。その内容はＳＢＰ−２と同様であって、０であればイニシエータからターゲット、１であればターゲットからイニシエータへの方向を示している。
【０２０７】
〈本実施形態に係る情報処理システム〉
図１は、本実施形態の情報処理システムを示す図であり、ＩＥＥＥ１３９４で接続されたホストコンピュータ（以下ホスト）１ａとプリンタ１ｂを表している。
【０２０８】
ホスト１ａとプリンタ１ｂの通信はＩＥＥＥ１３９４インターフェース上で使われる代表的なデータ転送プロトコルであるＳＢＰ（Ｓｅｒｉａｌ　Ｂｕｓ　Ｐｒｏｔｏｃｏｌ）−３プロトコルを使って行なわれ、ホスト−プリンタ間のデータ転送を行なうための通信チャネルとしてロジカルユニット０が予め定められている。
【０２０９】
図１中、ホスト１ａはＳＢＰ−３プロトコルを用いたイニシエータとしてＳＢＰ−３のターゲットであるプリンタ装置１ｂとの間で通信を行うシステムである。またこの通信システムの場合、ＳＢＰ−３プロトコルの上位コマンドセットとして予め規定されたプリンタ制御用通信コマンドプロトコルに基づいてホスト−プリンタ間通信が行なわれ、コマンドに従った処理が行なわれる。
【０２１０】
プリンタ１ｂはホスト１ａから送られたプリンタコントロール、並びにプリントデータを受信し処理する機能と、プリンタ１ｂへのコントロールに対応して現在のプリンタステータスデータをホストに送信する機能とをそれぞれ提供する複数のデータ転送チャネルＣＨ１，ＣＨ２を備える。またこれらのデータ転送チャネル用の通信セッション確立、切断といったマネージメントリクエストを処理するマネージメントエージェントＭＡを装備している。
【０２１１】
各データ転送チャネルＣＨ１，ＣＨ２はＳＢＰ−３プロトコルで定義されたデュアルデータディスクリプタを備えたＯＲＢの活用によりデータ転送が行なわれる。それぞれのチャネルは二つのデータディスクリプタで指定されるデータバッファによりデータ転送を行なう。フェッチエージェントＦＡによりフェッチされるＯＲＢはコマンドブロック・エージェントＣＡにより実行状態が管理され、ＯＲＢで指定される２つのデータバッファに対する所定の処理はエクセキューション・エージェントＥＡ０、ＥＡ１によりライト、またはリード処理される。フェッチエージェントはＳＢＰ−２／３のオーダードモデルに従いイニシエータから発行されるＯＲＢをシーケンシャルに処理することにより上記所定の処理を実行させる仕組みとなっている。
【０２１２】
本実施形態では、プリンタ制御用通信コマンドプロトコルとしてＳＢＰ−３を使用することにより、ＯＲＢ中二つのデータディスクリプタで指定されるデータバッファをそれぞれデータ転送チャネルとしてアロケートし、一方のデータ転送チャネルにはプリントデータを、もう一方のデータ転送チャネルにはプリンタ制御コマンドの転送が行なわれるモデル仕様として定義されている。
【０２１３】
〈本実施形態に係るステータスブロック〉
通常、ＳＢＰ−３ではターゲットはＯＲＢで指定されたデータバッファに対する処理が完了した際に、それをイニシエータに通知するための完了通知としてイニシエータのステータスＦＩＦＯのアドレスに完了ステータス（ステータスブロック）を発行する。しかし、図３３のように、１つのＯＲＢにおいて２つのデータディスクリプタフィールドを用い２つのデータバッファが指定されている場合に、両方のデータバッファ処理が完了した時点でのみ完了ステータス（ステータスブロック）が発行される。片方のデータバッファに対するアクセスが正常終了しても、もう片方のデータバッファアクセスが完了しないとそのＯＲＢに対する完了通知をＳＢＰ−３のイニシエータに対して通知できず、ロジカルユニットとしてのデータ転送が滞ってしまう。このため、何らかの理由によりどちらかのデータ転送チャネルにおいてデータの送受信ができなくなった場合、またどちらかのデータ転送チャネルのデータ転送が他のチャネルよりも遅い場合、正常に転送されているチャネル、速いほうのチャネルが影響を受けてしまう。
【０２１４】
本実施形態に係るシステムにおいて、１つのデータバッファを印字データ、もう１つをステータスのために使うとすると、プリンタが印字データのデータバッファを全て受け取るまで、ホストに対してステータスを戻せないことが発生する。これではステータス情報を随時受け取りことができないことになる。
【０２１５】
そこで、本実施形態では、図３５に示すようなステータスブロックを発行し、データバッファごとのアクセス完了を通知できる構成となっている。
【０２１６】
図３５は、本実施の形態に係るプリンタ制御用通信コマンドプロトコルでの、データバッファ処理が完了した時点で発行する完了ステータス（ステータスブロック）を示す図である。
【０２１７】
図３５に示すように、このステータスブロックには、コマンドセット依存フィールドにデータバッファ毎の完了ステータスをあらわすフィールドとしてａ，ｂ１，ｂ２が定義されている。
【０２１８】
ａ，ｂ１，ｂ２は、それぞれ、データバッファを表していて、ｂ１は図３４で示した１番目のデータディスクリプタが示すデータバッファに対応しており、ｂ２は２番目のデータディスクリプタが示すデータバッファに対応している。ａはこれら２つのデータディスクリプタが示す両方のデータバッファに対応する。ａ，ｂ１，ｂ２のフィールドにはそれぞれ０または１の値がセットされ、１の場合に対応するバッファの完了を示し、０であれば対応するバッファの未完了を示す。つまり、ａに１が指定された場合、２つのバッファに対するデータ通信が同時に完了したことを示す。ａ，ｂ１，ｂ２の３つのフィールドに対する値のセットにより、１つ目のバッファの完了、２つ目のバッファの完了、１，２両方のバッファの完了を個別あるいは同時に通知することができる。
【０２１９】
図３６は、このようなステータスブロックを採用した場合のコマンドブロックＯＲＢの動作を示す図である。図のように、ステータスＦＩＦＯに対するアクセスは、複数回（この場合２回）行われる。ここで、ステータスＦＩＦＯへのアクセスは図３５に示したステータスブロックで行われ、ａ，ｂ１，ｂ２のいずれかのビットに１が設定される。例えば、２つ目のバッファに対する処理のみが完了した場合、１度目のステータスブロックで、ｂ２に１、ｂ１に０がセットされ、１つ目のバッファの処理が完了した場合、２度目のステータスブロックで、ｂ２に０、ｂ１に１がセットされる。このように、それぞれのバッファについて、個別にステータスブロックが送信される。ｂ１，ｂ２共に完了が通知されたので、処理していたＯＲＢの完了が通知されたことになる。また、ａ，に１を設定することで２つのバッファに対するデータ通信の終了を１つのステータスブロックで行うこともできる。
【０２２０】
以上のように、本実施形態の情報処理システムでは、コマンドブロックに複数のデータバッファを有するようなコマンド実行処理において、個別のデータバッファに対する完了通知を指定することが可能となり、よりバッファの制御を詳細に行うことができる。また同時に複数のデータバッファの完了通知がそろうことによりコマンドブロックの完了と判断することが可能なため、完了通知の回数を少なくすることができる。また１度で全てのデータバッファの完了を通知することが可能となり、完了通知を簡略化することと従来技術との互換性を保つことができる。
【０２２１】
ひいては、データバッファごとに独立してステータスＦＩＦＯにステータスを書き込むことができるので、印字データとは独立してステータスのみを連続してホストに返すことのできるプリントシステムを実現できる。
【０２２２】
（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。また、上記実施形態では通信制御バスとしてＩＥＥＥ１３９４を利用した例について説明したが、本発明はこれに限定されるものではなく、ＵＳＢなどの他の規格のバスを利用しても良い。
【０２２３】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。
【０２２４】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０２２５】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０２２６】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【０２２７】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【０２２８】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０２２９】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０２３０】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【０２３１】
【発明の効果】
本発明によれば、ＩＥＥＥ１３９４バス等の２つのチャネルを用いて効率的なデータ転送を行うことができる。
【図面の簡単な説明】
【図１】本発明のホスト・プリンタ通信システムの構成を示した図である。
【図２】１３９４シリアルバスのネットワークの構成を示した図である。
【図３】本発明の１３９４シリアルバスの構成要素を示した図である。
【図４】本発明の１３９４シリアルバスのリンク・レイヤ提供可能なサービスを示す図である。
【図５】本発明の１３９４シリアルバスのトランズアクション・レイヤ提供可能なサービスを示す図である。
【図６】１３９４インタフェースにおけるアドレス空間を説明する図である
【図７】１３９４インタフェースにおけるＣＳＲコア・レジスタに格納される情報のアドレス及び機能を示す図である。
【図８】１３９４インタフェースにおけるシリアルバス・レジスタに格納される情報のアドレス及び機能を示す図である。
【図９】１３９４インタフェースにおける最小形式のコンフィグレーションＲＯＭを示す図である。
【図１０】１３９４インタフェースにおける一般形式のコンフィグレーションＲＯＭを示す図である。
【図１１】１３９４インタフェースにおけるシリアルバス装置レジスタに格納される情報のアドレス及び機能を示す図である。
【図１２】ＩＥＥＥ１３９４規格に準拠した通信ケーブルの断面図である。
【図１３】ＤＳ−Ｌｉｎｋ符号化方式を説明する図である。
【図１４】バスリセットの開始からノードＩＤの割り当て処理までの基本的なシーケンスを示した図である。
【図１５】バスリセットの開始からノードＩＤの割り当て処理までの基本的なシーケンスを示した図である。
【図１６】バスリセットの開始からノードＩＤの割り当て処理までの基本的なシーケンスを示した図である。
【図１７】図１５に示したステップＳ１５０５の処理（即ち、自動的に各ノードのノードＩＤを割り当てる処理）を詳細に説明するフローチャートである。
【図１８】１３９４インターフェースにおけるセルフＩＤパケットの構成を示した図である。
【図１９】１３９４ネットワークにおけるアービトレーションを説明する図である。
【図２０】１通信サイクルにおいてアイソクロナス転送モードとアシンクロナス転送モードとを混在させた場合を説明する図である。
【図２１】アイソクロナス転送モードに基づいて転送される通信パケットのフォーマットを示した図である。
【図２２】本発明のアシンクロナス転送のパケットフォーマットを示した図である。
【図２３】ＳＢＰ−２におけるＯＲＢ種別を示した図である。
【図２４】ＳＢＰ−２におけるコマンドブロックＯＲＢのフォーマットを示した図である。
【図２５】ＳＢＰ−２におけるマネージメントＯＲＢのフォーマットを示した図である。
【図２６】ＳＢＰ−２におけるコマンドブロックＯＲＢのリンクリストを示した図である。
【図２７】ＳＢＰ−２におけるデータバッファの直接アクセスを示した図である。
【図２８】ＳＢＰ−２におけるページテーブルの使用を示した図である。
【図２９】ＳＢＰ−２におけるステータスＦＩＦＯのフォーマットを示した図である。
【図３０】ＳＢＰ−２におけるログイン動作を示した図である。
【図３１】ＳＢＰ−２にタスク実行の最初の動作を示した図である。
【図３２】ＳＢＰ−２におけるコマンドＯＲＢの動作を示した図である。
【図３３】ＳＢＰ−３におけるコマンドＯＲＢの動作を示した図である。
【図３４】ＳＢＰ−３におけるコマンドブロックＯＲＢのフォーマットを示した図である。
【図３５】本発明の実施形態としての情報処理システムにおけるステータスブロックのフォーマットを示した図である。
【図３６】本発明の実施形態としての情報処理システムにおけるコマンドＯＲＢの動作を示した図である。
【図１】
2004104255.tif 000003
【図２】
2004104255.tif 000004
【図３】
2004104255.tif 000005
【図４】
2004104255.tif 000006
【図５】
2004104255.tif 000007
【図６】
2004104255.tif 000008
【図７】
2004104255.tif 000009
【図８】
2004104255.tif 000010
【図９】
2004104255.tif 000011
【図１０】
2004104255.tif 000012
【図１１】
2004104255.tif 000013
【図１２】
2004104255.tif 000014
【図１３】
2004104255.tif 000015
【図１４】
2004104255.tif 000016
【図１５】
2004104255.tif 000017
【図１６】
2004104255.tif 000018
【図１７】
2004104255.tif 000019
【図１８】
2004104255.tif 000020
【図１９】
2004104255.tif 000021
【図２０】
2004104255.tif 000022
【図２１】
2004104255.tif 000023
【図２２】
2004104255.tif 000024
【図２３】
2004104255.tif 000025
【図２４】
2004104255.tif 000026
【図２５】
2004104255.tif 000027
【図２６】
2004104255.tif 000028
【図２７】
2004104255.tif 000029
【図２８】
2004104255.tif 000030
【図２９】
2004104255.tif 000031
【図３０】
2004104255.tif 000032
【図３１】
2004104255.tif 000033
【図３２】
2004104255.tif 000034
【図３３】
2004104255.tif 000035
【図３４】
2004104255.tif 000036
【図３５】
2004104255.tif 000037
【図３６】
2004104255.tif 000038