JP2004104254A - 情報処理システム、情報処理装置、情報処理方法、プログラム及び記憶媒体 - Google Patents

Abstract

【課題】ＩＥＥＥ１３９４バスの２つのチャネルを用いて効率的なデータ転送を行うこと。
【解決手段】ＩＥＥＥ１３９４に準拠した通信制御バスに接続されたイニシエータとターゲットを含む情報処理システムであって、イニシエータは、ロジカルユニット１つを使って、ひとつのコマンドＯＲＢに対し２つのデータバッファを用意し、ターゲットは、２つのデータバッファのいずれか一方に対するデータ通信が完了したことを示すステータスブロックをイニシエータのステータスＦＩＦＯに送る。
【選択図】　図４１

Description

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

Claims (11)

1. 通信制御バスで接続された第１、第２機器を含む情報処理システムであって、前記第１機器は、ロジカルユニット１つを使ってひとつのコマンドＯＲＢに対して複数割り当てられたデータバッファを有し、
   前記第２機器は、複数の前記データバッファのいずれか一つに対するデータ通信が完了したことを通知する完了通知手段を有し、
   前記第１機器は、更に、前記完了通知手段による通知に基づき、データ通信が完了していないデータバッファに対しては更新を行わず、完了しているデータバッファに対して更新を行う手段を有することを特徴とする情報処理システム。
2. 前記通信制御バスは、ＩＥＥＥ１３９４に準拠した通信制御バスであり、前記第１機器と前記第２機器との間では、シリアルバスプロトコル３を通信プロトコルとしてデータ通信を行うことを特徴とする請求項１記載の情報処理システム。
3. 前記完了通知手段は、前記第１機器のステータスＦＩＦＯに、前記２つのデータバッファの内、データ通信が完了したデータバッファを示すステータスを発行することを特徴とする請求項１または２に記載の情報処理システム。
4. 前記第１機器は、前記複数のデータバッファに格納されているデータの識別情報を前記ＯＲＢに含むことを特徴とする請求項１、２または３に記載の情報処理システム。
5. 通信制御バスで接続された２つの機器間における通信方法であって、
   １つのコマンドＯＲＢに対し複数のデータバッファを参照する工程と、
   前記ＯＲＢで指定される複数のデータバッファのいずれかがデータ通信を完了した場合に、その完了を通知する完了通知工程と、
   前記データバッファの更新情報を通知する工程と、
   を含むことを特徴とする通信方法。
6. 他の機器と通信制御バスで接続された情報処理装置であって、
   ロジカルユニット１つを使ってひとつのコマンドＯＲＢに対して複数割り当てられたデータバッファと、
   前記他の機器から、複数の前記データバッファのいずれか一つに対するデータ通信が完了したことを示す完了通知を受信する手段と、
   前記完了通知に基づき、データ通信が完了していないデータバッファに対しては更新を行わず、完了しているデータバッファに対して更新を行う手段とを有することを特徴とする情報処理装置。
7. 他の機器と通信制御バスで接続された情報処理装置であって、
   ロジカルユニット１つを使って、ひとつのコマンドＯＲＢに対し複数のデータバッファを用意した他の機器に対し、データ通信を完了していないデータバッファに対しては更新を行わせず、完了しているデータバッファに対して更新を行わせるために、前記複数のデータバッファのいずれか一つに対するデータ通信が完了したことを通知する完了通知手段を有することを特徴とする情報処理装置。
8. 他の機器と通信制御バスで接続された情報処理装置における通信方法であって、
   ロジカルユニット１つを使って、ひとつのコマンドＯＲＢに対し複数のデータバッファを用意し、
   前記他の機器から、前記複数のデータバッファのいずれか一つに対するデータ通信が完了したことを示す完了通知を受信し、
   前記完了通知に基づき、完了していないデータバッファに対して更新を行わず、完了しているデータバッファに対して更新を行うことを特徴とする通信方法。
9. 他の機器と通信制御バスで接続された情報処理装置における通信方法であって、
   ロジカルユニット１つを使って、ひとつのコマンドＯＲＢに対し複数のデータバッファを用意した他の機器に対し、完了していないデータバッファに対して更新を行わせず、完了しているデータバッファに対して更新を行わせるために、前記複数のデータバッファのいずれか一つに対するデータ通信が完了したことを通知することを特徴とする通信方法。
10. 請求項５，８または９に記載の通信方法をコンピュータに実現させることを特徴とするプログラム。
11. 前記請求項１０に記載のプログラムを格納したことを特徴とするコンピュータ読取り可能な記憶媒体。

Images