(57)【要約】手術室内のバックボーンに接続されているアプリケーション同士の間のリアルタイム制御を有効化して、これらのデバイスが、効果的に、リアルタイムに連絡し、かつ、インタラクトできるようにする手術室システム。
2008534173.tif 000002
【特許請求の範囲】
【請求項１】
単一のバス構成に接続されている多重デバイスの手術室管理のための集積化システムであって、
バスに接続されているリアルタイム通信データポートを有する外科の手術室で使用可能な第一のデバイスと、
該第一のデバイス上で動作する第一のアプリケーション・プログラムと、
前記バスに接続されているリアルタイム通信データポートを有する外科の手術室で使用可能な第二のデバイスと、
該第二のデバイス上で動作する第二のアプリケーション・プログラムと、
を含む集積化システムにおいて、
前記バス構成は、前記第一のデバイスが、前記第二のデバイスとリアルタイムに連絡し、かつ、前記バス構成に接続されている他のデバイスともリアルタイムに連絡することを可能にする、
ことを特徴とする集積化システム。
【請求項２】
前記第一のデバイスは、前記バス構成にリアルタイムに接続される他のデバイスと直接連絡する、請求項１記載の集積化システム。
【請求項３】
前記第一のデバイスは、前記バス構成にリアルタイムに接続される多重の他のデバイスと同時に連絡する、請求項１記載の集積化システム。
【請求項４】
前記バスは、高帯域幅データ通信を支える、請求項１記載の集積化システム。
【請求項５】
前記データは、１００Ｍｂｓより速い速度で転送される、請求項４記載の集積化システム。
【請求項６】
前記バス構成に接続されている各デバイスは、予め指定された一定の間隔でリアルタイム・アクセスを有する、請求項１記載の集積化システム。
【請求項７】
前記予め指定された一定の間隔は、１ｍｓに等しいか、あるいは、それ以下である、請求項６記載の集積化システム。
【請求項８】
前記バスは、大量のデータを転送することができる、請求項１記載の集積化システム。
【請求項９】
リアルタイム通信は、前記大量のデータの転送と共存する、請求項８記載の集積化システム。
【請求項１０】
前記バス構成に接続されている各デバイスは、デバイス自体のデータの流れを管理する、請求項１記載の集積化システム。
【請求項１１】
いかなる単一のデバイスも、全てのデータを処理することに責任がない、請求項１０記載の集積化システム。
【請求項１２】
前記バス構成に接続されている各デバイスは、バス動作中に、前記バスに追加できる、あるいは、前記バスから取り外せる、請求項１記載の集積化システム。
【請求項１３】
前記バス構成は、デバイスが、追加される、あるいは、取り外される時、動的に再構成する、請求項１２記載の集積化システム。
【請求項１４】
前記バス構成は、前記バス構成に接続されているいかなるデバイスにも電力を供給することができる、請求項１記載の集積化システム。
【請求項１５】
前記バス構成に接続されている各デバイスは、前記バス構成に電力を供給することができる、請求項１記載の集積化システム。
【請求項１６】
前記第一のアプリケーション・プログラムは、前記第二のアプリケーション・プログラムにデータを供給し、かつ、前記バス構成に接続されている第三のデバイス上で動作する第三のアプリケーション・プログラムにもデータを供給する、請求項１記載の集積化システム。
【請求項１７】
前記第一のアプリケーション・プログラムは、先ず、前記第一のアプリケーション・プログラムとインタラクトすることができる、前記バス構成に接続されている特定のアプリケーション・プログラムを識別する、請求項１６記載の集積化システム。
【請求項１８】
前記第一のアプリケーション・プログラムは、前記第二のアプリケーション・プログラムにデータを供給し、かつ、前記バス構成に接続されている第三のデバイス上で動作する第三のアプリケーション・プログラムにもデータを供給する、請求項１記載の集積化システム。
【請求項１９】
前記バスは、ＩＥＥＥ-１３９４バスである、請求項１記載の集積化システム。
【請求項２０】
前記第一のデバイスは、前記第一のデバイスへの電源が、オフに切り換えられた時、前記バスから電力を供給することができる通信レイヤを有している、請求項１９記載の集積化システム。
【請求項２１】
前記第二のアプリケーション・プログラムは、前記第二のデバイスと関連するリードオンリーメモリ・デバイス内に含まれている、請求項１記載の集積化システム。
【請求項２２】
前記第一のデバイスは、コンピュータであり、かつ、前記第一のアプリケーション・プログラムは、ナビゲーション・システムである、請求項１記載の集積化システム。
【請求項２３】
手術室環境内で、バス構成によって共に接続されている多重のデバイス同士の間でリアルタイム通信を行なう方法であって、前記方法は、
前記リアルタイム通信リンクを用いて、第一のデバイスを前記バス構成に接続する工程であって、前記第一のデバイスは、該第一のデバイス上で動作するアプリケーション・プログラムを有している工程と、
前記リアルタイム通信リンクを用いて、他のデバイスを前記バス構成に接続する工程であって、各他のデバイスは、前記他のデバイス上で動作する他のアプリケーション・プログラムを有している工程と、
前記リアルタイム通信リンクを介して、前記第一のアプリケーションから前記他のアプリケーションへ、データのパケットを渡して、前記第一のアプリケーションが、前記他のアプリケーション・プログラムと連絡することを可能にし、かつ、前記第一のアプリケーションが、少なくとも一つの他のアプリケーションまたは少なくとも一つの他のデバイスを制御することを可能にする工程と、
を含むことを特徴とする方法。
【請求項２４】
前記第一のデバイスは、コンピュータである、請求項２３記載の方法。
【請求項２５】
前記他のアプリケーション・プログラムは、リードオンリーメモリに収容されている、請求項２３記載の方法。
【請求項２６】
前記方法はまた、前記第一のデバイスが、前記他のデバイスとインタラクトすることができることを判定する工程も含んでいる、請求項２３記載の方法。
【請求項２７】
前記方法はまた、デバイスの電力状態を判定し、かつ、そのデバイスへの電力の流れを制御する工程も含んでいる、請求項２３記載の方法。
【請求項２８】
データの前記パケットは、前記第一のアプリケーションから前記他のアプリケーションへ直接渡される、請求項２３記載の方法。
【請求項２９】
前記第一のアプリケーションは、多重の他のアプリケーションに、同時に連絡する、請求項２３記載の方法。
【請求項３０】
データの前記パケットは、１００Ｍｂｓより速い速度で渡される、請求項２３記載の方法。
【請求項３１】
各デバイスは、そのデバイス自体のデータの流れを管理する、請求項２３記載の方法。
【請求項３２】
いかなる単一のデバイスも、全てのデータを処理しない、請求項２３記載の方法。
【請求項３３】
手術室環境内で多重のデバイスをリアルタイムに管理する集積化システムにおいて、
第一のノードを有するバス構成であって、前記第一のノードは、前記バス構成に接続されているバス構成と、
前記第一のノードに接続されている第一のデバイスであって、前記第一のデバイスは、第一のアプリケーション・プログラムを動作させる第一のデバイスと、
前記バス構成に接続されている複数の他のノードと、
前記他のノードのそれぞれに接続されている他のデバイスであって、各デバイスは、前記他のデバイス上で動作する他のアプリケーション・プログラムを有している他のデバイスと、
前記第一のアプリケーションと前記他のアプリケーションとの間のリアルタイム通信を可能にするためのＡＰＩであって、該ＡＰＩは、前記他のアプリケーションの前記バス構成への接続、前記第一のアプリケーションと前記他のアプリケーションとの間のネゴシエーション、および前記第一のアプリケーションと前記他のアプリケーションとの間のデータの送信および受信を管理するＡＰＩと、
を含むことを特徴とする集積化システム。
【請求項３４】
前記第一のデバイスは、それぞれの他のデバイスに、それが、前記バス構成に接続されている時、問い合わせて、前記第一のデバイスが、前記他のデバイスとインタラクトすることができるかどうかを判定する、請求項３３記載の集積化システム。
【請求項３５】
前記第一のアプリケーション・プログラムは、前記他のアプリケーション・プログラムをカスタマイズし、かつ、前記第一のアプリケーション・プログラムは、前記他のデバイス上で動作する前記他のアプリケーション・プログラムを制御する、請求項３３記載の集積化システム。
【請求項３６】
前記ＡＰＩは、前記第一のデバイスおよび前記他のデバイスへの電力の制御を有効化する、請求項３３記載の集積化システム。
【請求項３７】
前記第一のデバイスは、前記第一のデバイスへの電源が、オフに切り換えられた時、前記バスから電力を供給することができる通信レイヤを有している、請求項３６記載の集積化システム。
【請求項３８】
前記バス構成は、ＩＥＥＥ-１３９４バスである、請求項３３記載の集積化システム。
【請求項３９】
前記他のアプリケーション・プログラムは、前記他のデバイスと関連するリードオンリーメモリ・デバイスに含まれている、請求項３３記載の集積化システム。
【請求項４０】
前記第一のデバイスは、前記バス構成に、リアルタイムに接続される他のデバイスと直接連絡する、請求項３３記載の集積化システム。
【請求項４１】
前記第一のデバイスは、前記バス構成にリアルタイムに接続される多重の他のデバイスと同時に連絡する、請求項３３記載の集積化システム。
【請求項４２】
前記バスは、高帯域幅データ通信を支持する、請求項３３記載の集積化システム。
【請求項４３】
前記データは、１００Ｍｂｓより速い速度で転送される、請求項４２記載の集積化システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、外科の手術室内で使用するための通信バスおよび方法に関する。より具体的には、本発明は、外科の手術室内で使用されている各種のデバイスが、能率的に、かつ、リアルタイムに連絡できるようにする通信バスおよび方法に関する。
【背景技術】
【０００２】
高速度データ・リンクの開発は、各種のデバイスを繋ぎ合わせて、コヒーシブなネットワークを形成し、所望の結果を得ることを可能にした。データ・リンクを渡る通信の速度は、真のリアルタイムなインタラクションを問題の有るものにする場合が多かった。ある種のアプリケーションでは、命令を実行する際のいくらかの遅延は、許容できる。しかし、健康管理環境におけるデータ・リンクを含む、他のタイム・クリティカルなアプリケーションでは、ユーザは、コンピュータ、制御デバイスなどによって制御できる周辺機器のリアルタイムな制御を期待している。
【０００３】
各種のＩＥＥＥ-１３９４規格で記述されている高速度シリアルバスのトポロジーは、バックボーンであって、その内部で、リアルタイム命令が、シリアルバスに接続された分散デバイスにおいて実行されるバックボーンを提案している。ＩＥＥＥ-１３９４規格を使用するシステムは、リアルタイムな制御およびインタラクションに近づいているが、これらのシステムは、病院の外科手術室内などのタイム・クリティカルなアプリケーションで使用するのに必要な密接なリアルタイム・インタラクションには手が届いていない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
各種のデバイス、およびこれらのデバイス上で動作して、真に単一のユニットとして動作するアプリケーションを可能にする通信リンケージまたはバスに対するニーズが有る。これは、各種のデバイスおよびアプリケーションのセットアップおよびカスタマイゼーションを援助して、ユーザが、ユーザの好みおよび仕様に合わせてカスタマイズできるシームレス・システムを作り出すニーズも含んでいる。手術室環境内では、多くの外科医が、やや異なるやり方で特定の手順にアプローチする。デバイスのセットアップを援助して、外科医が熟知したやり方で動作するシステムは、時間を節約し、かつ、患者に対してより最適な結果を得るのに役立つ。
【課題を解決するための手段】
【０００５】
本発明の一実施形態によれば、バス構成によって共に接続されている多重のデバイスの手術室管理のための集積化システムは、バス構成に接続されているリアルタイム通信ポートを有する外科の手術室内で使用可能な第一のデバイス、および第一のデバイス上で動作する第一のアプリケーションを含んでいる。システムはまた、バス構成に接続されているリアルタイム通信ポートを有する外科の手術室内で使用可能な第二のデバイス、および第二のデバイス上で動作する第二のアプリケーションを有している。バス構成は、第一のデバイスが、第二のデバイスとリアルタイムに連絡し、かつ、バス構成に接続されている他のデバイスともリアルタイムに連絡することを可能にする。
【０００６】
本発明のさらなる実施形態は、手術室環境内の多重のデバイス同士の間でリアルタイム通信を行なう方法を含んでいる。この方法は、リアルタイム通信リンクを用いて、第一のデバイスをバス構成に接続する工程であって、該工程は、第一のデバイス上で動作するアプリケーション・プログラムを有している工程を含んでいる。この方法はまた、リアルタイム通信リンクを用いて、他のデバイスをバス構成に接続する工程であって、該工程は、各他のデバイスが、他のデバイス上で動作する他のアプリケーション・プログラムを有している工程を含んでいる。この方法はさらに、リアルタイム通信リンクを介して、第一のアプリケーションから他のアプリケーションへ、データのパケットを渡して、第一のアプリケーションが、少なくとも一つの他のアプリケーションまたは少なくとも一つの他のデバイスを制御することを可能にする工程を含んでいる。
【０００７】
本発明のまた別のさらなる実施形態は、バス構成に接続されているノードおよびデバイス上で動作する第一のアプリケーション・プログラムを含むノードに接続されている第一のデバイスを有するバス構成を含む手術室環境内のアプリケーションを管理するための集積化システムを含んでいる。このシステムは、バス構成に接続されている複数の他のノードおよびノードのそれぞれに接続されている他のデバイスであって、各デバイスは、他のデバイス上で動作する他のアプリケーションを有している他のデバイスをさらに含んでいる。加えて、このシステムは、第一のアプリケーションと他のアプリケーションとの間のリアルタイム通信を可能にするＡＰＩを含んでおり、ＡＰＩは、他のアプリケーションのバス構成への接続、第一のアプリケーションと他のアプリケーションとの間のネゴシエーション、および第一のアプリケーションと他のアプリケーションとの間のデータの送信および受信を管理する。
【発明を実施するための最良の形態】
【０００８】
図１を参照すると、代表的なバス構成２０は、それに接続された多数のデバイスを有している。これらは、外科のナビゲーション・システム２２を動作させるパーソナル・コンピュータ、ツール・コンソール２４、第二のツール・コンソール２６、ネットワーク・ブリッジ２８、手術室在庫品システム３０を動作させるパーソナル・コンピュータ、フット・コントローラ３２、ビデオ・システム３４、手術室用環境システム３６、ボイス・コントロール・デバイス３８、患者モニタリング・デバイス４０、遠隔制御ブリッジ４２、診断機器４４、および患者記録システム４６を含んでいる。また、バス構成２０には、ネットワーク・ブリッジ２８を介して、請求書作成および在庫品システムまたはシステム群５０を動作させるコンピュータ、外部ネットワーク５２（ここではイーサネット（登録商標）・ネットワークとして識別されている）、およびインターネット５４への接続部が接続されている。任意の適当なバス構成２０が、使用できるが、バス構成２０は、ＩＥＥＥ-１３９４コンプライアント・シリアルバスであることが好ましい。ＩＥＥＥ-１３９４コンプライアント・バスは、ＩＥＥＥ１３９４〜１９９５など、シリアルバス用の適用可能なＩＥＥＥ規格（ＩＥＥＥ-１３９４ａ、およびＩＥＥＥ-１３９４ｂ規格およびこれらの規格に対する任意の継承規格）のいずれかに従った任意のバスを意味している。上に示したように、バスの特定のトポロジーは、他のデバイスを介して接続するある種のデバイスを含むことができる。例えば、フット・コントローラ３２は、ツール・コンソール２４を介して、バス構成２０に接続することができる。
【０００９】
本発明の一実施形態では、バス構成２０内を渡るデータ・パケットは、バス構成２０に接続されている各デバイスを有効化して、バス構成２０に接続されている任意の他のデバイスと直接連絡する。これはまた、特定のデバイス上で動作して、中間のデバイス処理ユニットを通過することなしに、他のデバイス上で動作するアプリケーションと直接連絡することができるアプリケーションを有効化する。バス構成２０を介して伝送されるデータは、１００Ｍｂsより速い速度で転送されるデータなどの高帯域幅のデータであることが多い。このトポロジーは、バス構成２０上で大量のデータ転送と共存するリアルタイム制御を可能にする。さらに、バス構成２０は、バス構成２０に接続されているいかなる単一のデバイスも、バス構成２０を通過する全てのデータを処理する責任が無いよう、データの分散処理を可能にする。また、各デバイスは、そのデバイス自体のデータの流れを管理する責任が有る。本システムの利点は、単一のデバイスが、同様に、バス構成２０にリアルタイムに接続されている一つまたはそれ以上のデバイスと直接連絡することができることである。また、各デバイスは、バス構成２０の特性によって、必要なら、一般に１ｍｓを超えない予め指定された一定の間隔で、リアルタイムなアクセスを有するようにすることができる。
【００１０】
図２は、１３９４バスへの接続に適したデバイス６０の概略図を示す。デバイス６０は、一般に、デバイス６０をバス構成２０に接続するための多重１３９４コネクタ６２ａ、６２ｂ、および６２ｃを含んでいる。コネクタ６２ａ〜６２ｃは、リンク集積回路６６に接続されているＰＨＹ集積回路６４に接続されている。ＰＨＹ ＩＣ６４およびコネクタ６２ａ-ｃのみは、多くのＩＥＥＥ-１３９４コンプライアント・デバイスのため、常時電力が供給される。これらのプライア・デバイスにおけるＰＨＹ ＩＣ６４は、バス構成２０によって直接、あるいは、たとえデバイス６０以外のものがパワーダウンした場合でも、デバイス６０が、ＰＨＹ ＩＣ６４への電力を常時維持するように、何らかの電力スキームによって電力が供給される。
【００１１】
次いで、リンクＩＣ６６は、非等時性（ａｓｙｎｃｈｒｏｎｏｕｓ）インタフェース６８、および等時性（ｉｓｏｃｈｒｏｎｏｕｓ）インタフェース７０に接続されている。非等時性インタフェース６８と等時性インタフェース７０の両方は、デバイス６０で動作するアプリケーション７２と連絡することが可能である。コネクタ６２ａ〜６２ｃ、ＰＨＹ ＩＣ６４、リンクＩＣ６６、非等時性インタフェース６８、および等時性インタフェース７０は全て、デバイス６０の通信レイヤの一部と考えられる。本発明の好適な実施形態では、通信レイヤの全ての要素には、常時、電力が供給される。電力は、バス構成２０から直接到来するようにするか、あるいは、デバイス６０が、オン状態に切り換えられるオプショナルの電源を有している場合は、通信レイヤには、そのオプショナルの電源によって電力を供給することができる。これは、電力マネジャーが、バス構成２０からの電力を必要とする他のデバイスによって使用されるべき電力を、再割り当てすることを可能にする。最も簡単なレベルでは、消費者デバイス、ＰＨＹ ＩＣ６４、リンクＩＣ６６、非等時性インタフェース６８、および等時性インタフェース７０は全て、バス構成２０によってＰＨＹ ＩＣ６４に供給される３.３ボルトの電源に接続されるそれらのVDD端子を有している。アプリケーション７２は、アプリケーション・レイヤと考えられる。
【００１２】
アプリケーション７２と非等時性インタフェース６８および等時性インタフェース７０との間の通信は、矢印７４および７６によって示すように、双方向である。非等時性インタフェース６８はまた、矢印７８で示す等時性インタフェース７０に接続されており、かつ、等時性インタフェース７０と連絡可能である。ある種の好適な実施形態では、非等時性インタフェース６８は、等時性インタフェース７０をプログラムあるいは制御することができる。リンクＩＣ６６とアプリケーション７２との間には、矢印８０によって示される直接通信が存在する。ある種の好適な実施形態では、リンクＩＣ６６とアプリケーション７２との間のこの直接通信が望ましい。
【００１３】
前述のように、好適な実施形態では、デバイス６０の通信レイヤには、常時電力が供給されている。この電力は、バス構成２０によって直接、あるいは、デバイス６０の内部のまたは外部の直接電源によって供給される。この外部電源を取り外した場合は、その後、バス構成２０が、このデバイス６０の通信レイヤに電力を供給する。リンクＩＣ６６、非等時性インタフェース６８および等時性インタフェース７０への電力を維持することは、二つの非常に重要な利点となる。先ず、バス構成２０は、アプリケーション・レイヤが、オンまたはオフに切り換えられるごとに、バス・リセットを行なうことになる。第二の利点は、非等時性インタフェース６８も、アプリケーション・レイヤへの電力を制御するソフトウェアを含むことができることである。これは、電力マネジャーが、パワー・オフまたはパワー・オン・コマンドを、特定のデバイスの通信レイヤに送信して、特定のアプリケーション・レイヤの電源をオンまたはオフすることを可能にする。これは、電力マネジャーが、現在のニーズに基づき、バス構成２０に接続されているアプリケーションを動的に再構成すること、そして、バス・リセットを行なうことなしに、そうすることを可能にする。
【００１４】
図３は、バス構成２０に取り付けられた選択されたデバイス上で動作するある種のアプリケーションが、バス構成２０に取り付けられた他のデバイス上で動作する他のアプリケーションのいずれかに送信し得るコマンドの部分的リストである。フット・コントローラ３２またはボイス・コントローラ３８などのある種のデバイスは、コマンドに応答することだけしかできず、「コネクト」および「ディスコネクト」コマンドなどのコマンドのサブセットのみを開始または送信することができる。
【００１５】
図４は、バス構成２０に取り付けられたデバイス上で動作する全てのアプリケーションが、図３にリスト化した対応するコマンドに対して応答する際に返すレスポンスのリストである。例えば、あるアプリケーションは、アプリケーションからのコネクト・コマンドの受信に応答して、コネクト・レスポンスを送信する。
【００１６】
既に示したように、あるアプリケーションが、バス構成２０を渡って、他のアプリケーションと連絡したい場合は、そのアプリケーションは、先ず、他のアプリケーションが、いかにしてそのアプリケーションに接触し、かつ、そのアプリケーションに、メッセージおよびコマンドを送信するかの仕方が分かるように、それ自体を登録しておかなければならない。全てのコマンド、レスポンスおよび自発的なメッセージは、図５に示すフォーマットで存在する。各メッセージは、ワード０が、常にスタート・フラグであり、そのアドレスが、０に等しいｎ個のワードで構成されている。最後のワードｎは、常に、全てのワード０〜ｎ−１に対して計算されるチェックサムである。チェックサムは、データ・ワード０〜ｍにおける０xＡ５の使用を可能にする。このシステムは、スタート・フラグ０ｘＡ５が、常に、そのメッセージの最後のワードとしての有効なチェックサムで終わることを確実にする。ワード１は、メッセージのタイプである。各コマンド、レスポンスおよびメッセージに対するメッセージのタイプを、図２〜４に示す。ワード２は、「Ａｐｐハンドル」である。これは、コマンドを送信しつつある特定のアプリケーション、レスポンスが向けられているアプリケーション、あるいは、特定のアプリケーションが、バス構成２０に接続しており、かつ、「Ａｐｐハンドル」を必要とすることを示す値０ｘＦＦＦＥのアイデンティティーである。ワード３は、ｎ−４に等しいメッセージｍの長さである。ワード４〜ｎ−１は、メッセージのデータを含んでいる。後述するように、ある種のコマンド、およびメッセージは、ゼロに等しい長さを有する場合があり、これは、メッセージが、データを全く含んでいないことを意味する。
【００１７】
「コネクト」コマンドは、あるアプリケーションが、初めてバス構成２０に接続する時使用される。そのアプリケーションは、まだ、Ａｐｐハンドルを有していないため、「コネクト」コマンドは、必ず「Ａｐｐハンドル」０ｘＦＦＦＥを含むことになる。「コネクト」コマンド内のデータは、アプリケーションが処理し得る最大パケット・サイズおよびアプリケーションの記述を含むことになる。「コネクト」レスポンスは、アプリケーションに対する「Ａｐｐハンドル」の値、アプリケーションに対するアドレシング情報、ＥＵＩＤ、一意のＩＤ、およびノードＩＤを含むことになる。レスポンスはまた、バス構成２０についての改訂データ、およびデバイスが等時性通信可能かどうかなど、アプリケーションが動作しているデバイスについての状態情報含むこともできる。チェックサムに加えて、レスポンスは、バス構成２０に接続しているアプリケーションのアイデンティティーを確認するための、アプリケーションについての情報を含むこともできる。
【００１８】
「ディスコネクト」コマンドは、あるアプリケーションをバス構成２０から外すのに使用される。このコマンドが、成功した場合は、アプリケーションに割り当てられたバッファは、解放され、かつ、他のアプリケーションによる使用が可能な状態になされる。「ディスコネクト」コマンドに対するレスポンスは、ディスコネクトが成功したかどうかを示す単一のデータワードを有している。
【００１９】
「接続デバイスの数をゲット（取得）（Ｇｅｔ  Ｎｕｍｂｅｒ  ｏｆ Ｃｏｎｎｅｃｔｅｄ Ｄｅｖｉｃｅｓ）」コマンド、「接続デバイスをゲット（取得）（Ｇｅｔ  Ｃｏｎｎｅｃｔｅｄ Ｄｅｖｉｃｅｓ）」コマンドおよび当該レスポンスは、あるアプリケーションが、バス構成２０上の他のデバイスのアイデンティティーおよび場所を判定することを可能にする。「数をゲット」コマンドは、フィルターを用いて、レスポンスを、フィルターの記述にマッチするデバイスに限定することが多い。フィルターを使用せず、かつ、バス構成２０に接続されている全てのデバイスの数を返すことは可能である。フィルターの使用は、バス構成２０上の通信量を限定し、かつ、フィルターのアイデンティティーは、特定のアプリケーションが効果的に連絡することが可能な認容できるデバイスのデータベースを基にすることができる。レスポンスは、使用されているフィルターにマッチしている、バス構成２０に取り付けられたデバイスの数を返す。「接続デバイスをゲット」コマンドは、「数をゲット」コマンド・レスポンスによって識別されるデバイスの数に対するデバイスの記述を返す。レスポンスは、デバイス情報を含んでいる。
【００２０】
コマンドおよびレスポンスの次のセットは、特定のノードまたはデバイス上で動作しているアプリケーションの数およびアイデンティティーについて尋ねる以外は、上記と同様である。「アプリケーション数をゲット（Ｇｅｔ  Ｎｕｍｂｅｒ  ｏｆ Ａｐｐｌｉｃａｔｉｏｎｓ）」コマンドに対するレスポンスは、コマンド内で識別されるデバイス上で動作している、あるいは、それに登録されているアプリケーションの数となる。この数は、いかなるアプリケーションも、そのデバイス上で現在動作していない場合は、ゼロであることができる。「アプリケーションの情報をゲット（Ｇｅｔ  Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ）」コマンドは、デバイスまたはノードに登録されている、あるいは、その上で動作しているアプリケーションのアイデンティティーおよび特性についての情報を得るものである。
【００２１】
「ネットワーク時間をゲット（Ｇｅｔ  Ｎｅｔｗｏｒｋ  Ｔｉｍｅ）」コマンドは、時間同期化を維持しているアプリケーションの一部として、アプリケーションによって使用される。時間パルスが、バス構成２０に沿って移動する際には、いくらかの遅延が存在するので、バス構成２０に沿って、ネットワーク時間のスキューが僅かに存在する。最大許容スキューは、１２５マイクロ秒である。これは、ＩＥＥＥ-１３９４バス仕様によって使用される期間の長さである。人間の視覚からは、最大１２５マイクロ秒の遅延は、手術室環境に対するリアルタイム・アプリケーションにとって許容できる。なぜなら、最大１２５マイクロ秒の遅延は、人間のユーザには、知覚できないからである。
【００２２】
「パワーをトグル（Ｔｏｇｇｌｅ  Ｐｏｗｅｒ）」コマンドは、パワー・イネーブル・ピンおよびリセット・イネーブル・ピンをトグルするのに使用される。このメッセージは、アプリケーションをバス構成２０から切り離す時間の長さを示すデータを含んでいる。このコマンドは、単一のアプリケーションまたは全てのアプリケーションに送信することができる。このコマンドに応答すると、パワー・イネーブル・ピンは、非活性状態となり、リセット・イネーブル・ピンは、活性状態となる。非等時性インタフェース６８は、これらのピンを制御する。コマンド内に指定されたオフ・タイムの期間後は、リセット・イネーブル・ピンは、非活性状態となり、パワー・イネーブル・ピンは、活性状態となる。このコマンドに対するレスポンス・メッセージは存在しない。
【００２３】
「埋込み状態をゲット（Ｇｅｔ  Ｅｍｂｅｄｄｅｄ  Ｓｔａｔｕｓ）」コマンドは、ターゲットが埋め込まれたノードの現在の状態を示すよう求める、特定のノードに対する要求である。現在の構成では、このコマンドは、ターゲット・ノードの電力状態を示すレスポンスを返すことになる。一つのフラグは、デバイスへ電力を供給するためのオプショナルの電力ジャックの存在を示すことになる。また、別のフラグは、デバイスが、バス構成２０から電力を取り出す権限を与えられているかどうかを示すことになる。全てのデバイスは、それらが、デバイスのアプリケーション・レイヤに対して、電力を取り出す権限を有していない、と仮定して、バス構成２０に接続することになる。
【００２４】
「パワー・オン・パケットをセンド（Ｓｅｎｄ  Ｐｏｗｅｒ  Ｏｎ  Ｐａｃｋｅｔ）」、「パワー・オフ・パケットをセンド（Ｓｅｎｄ  Ｐｏｗｅｒ  Ｏｆｆ  Ｐａｃｋｅｔ）」、および当該レスポンスは、バス構成２０に取り付けられた電力マネジャーが、バス構成２０に接続されているデバイスまたはノードにコマンドを送信して、ノードにバス構成２０から電力を取り出す権限を与えるか、あるいは、以前に与えられた電力を取り出す権限を取り消すことができるようにするものである。
【００２５】
加えて、等時性および非等時性チャネルを通るデータの流れを管理するメッセージも存在する。これらコマンドは、ＩＥＥＥ-１３９４シリアルバスを渡るいかなる通信にも一般的であるので、さらに説明することはしない。
【００２６】
上記のコマンドのいずれかの結果として、エラーが発生したかどうかを示す自発的なメッセージが存在する。このメッセージは、エラーの原因を判定する際に役立つエラー・コードを返す。「バス・リセット（Ｂｕｓ  Ｒｅｓｅｔ）」メッセージは、バス構成２０上でバス・リセットが生じた時には何時でも、全てのノードに放送される。このメッセージは、リセット後に、いずれかの等時性チャネルが、再獲得されたかどうかを示すことになる。
【００２７】
図６は、あるアプリケーションをバス構成２０に接続するプロセスを通して進行する流れの図である。ブロック１００は、上記の「コネクト（Ｃｏｎｎｅｃｔ）」コマンドを使用して、アプリケーション・ハンドルを得る。アプリケーション・ハンドルは、コマンド・レスポンスの一部として返される。次に、ブロック１０２は、「接続デバイスの数をゲット」コマンドを送信する。前述のように、このコマンドは、コマンドに含まれているオプショナルのフィルターにマッチしている、バス構成２０に接続されているデバイスまたはノードの数を返す。システムが、ひとたび、当該接続デバイスの数を知ると、ブロック１０４は、次いで、「接続デバイスの情報をゲット」コマンドを使用して、接続デバイスについての情報を得る。リターン・メッセージは、問われているデバイスについて、詳細な情報を与える。制御は、次いで、ブロック１０６に渡り、ブロック１０６は、ブロック１０４で識別されたデバイスから選択された特定のデバイス上で動作しているアプリケーションの数を判定する。ブロック１０６によって、アプリケーションの数についての問合せに対して、レスポンスが受信されると、制御は、次いで、ブロック１０８に渡り、ブロック１０８は、ブロック１０６によって識別された各アプリケーションについての情報を判定する。制御は、次いで、ブロック１１０に渡り、ブロック１１０は、問合せおよび返された情報のパラメータに基づいて、特定のアプリケーションを選択する。制御は、次いで、ブロック１１２に渡り、ブロック１１２は、ブロック１１０で選択されたアプリケーションとの通信を始める。
【００２８】
図７は、一つのアプリケーションが、第二のアプリケーションを捜し、それをカスタマイズして、第一のアプリケーションと共に、より密接に働くようにする場合の二つのアプリケーション同士の間のインタラクションのフロー図である。ブロック１２０は、図１２のフォーマットによるアプリケーション情報を、受信する。この情報に基づいて、ブロック１２２は、ブロック１２０によって識別されたアプリケーションが、カスタマイズできるかどうかを判定する。ブロック１２２は、共に働くことができるデバイスおよびアプリケーションを含むデータベース１２４からの情報も受信することができるし、あるいは、ブロック１２２は、ブロック１２０からの情報だけに基づいたカスタマイゼーション決定を行なうこともできる。ブロック１２２が、ターゲット・アプリケーションは、カスタマイズすることができないと判定した場合は、ルーチンは、「ノー」ブランチを介して、ブロック１３４に分岐し、終了する。
【００２９】
ターゲット・アプリケーションが、カスタマイゼーション可能な場合は、制御は、「イエス」ブランチを介して、ブロック１２６に渡り、ブロック１２６は、次いで、当該データをターゲット・アプリケーションに送信して、アプリケーションをカスタマイズして、第一およびセンド・アプリケーションが、シームレス環境内で共に働けるようにする。一般に、この情報は、非等時性形態で、ターゲット・アプリケーションに送られる。アプリケーションが、ひとたびカスタマイズされると、システムは、次いで、制御をブロック１２８に渡し、ブロック１２８は、二つのアプリケーション同士の間の通信のモードを判定する。バス構成２０は、等時性および非等時性通信の両方を可能にする。ブロック１２８は、二つのアプリケーション同士の間の進行中の通信が、等時性モードであるか、あるいは、非等時性モードであるかを判定する。通信のモードが、非等時性である場合は、制御は、非等時性ブランチを介して、ブロック１３０に渡り、ブロック１３０は、上記のコマンドを使用して、通信を開始する。ブロック１２８が、通信は、等時性である、と判定した場合は、制御は、ブロック１３２に渡り、ブロック１３２は、等時性通信用のチャネルを開く。ブロック１３２が、ひとたび、チャネルを開くと、制御は、ブロック１３０に渡り、通信が、始まる。この点において、ルーチンは、次いで、ブロック１３４で終了する。
【００３０】
図８は、カスタマイゼーション・プロセスの概要のフロー図である。カスタマイゼーションは、ユーザの好みにより、全体的に、あるいは、部分的に行なうことができることに注目されたい。例えば、外科の環境内では、外科医は、好みを基に、特定のやり方で機器をセットアップし、かつ、構成することができる。図８のフロー図は、このセットアップおよび構成のプロセスを容易にする。このプロセスは、ブロック１５０から始まり、ブロック１５０は、カスタマイゼーション・メッセージおよびデータを受信する。ブロック１５０によって受信されたメッセージに基づき、制御は、ブロック１５２に渡り、ブロック１５２は、受信アプリケーション内に、有効化すべき機能が有るかどうかを判定する。命令が、受信アプリケーションの特定の機能または能力の有効化を要求している場合、かつ、受信アプリケーションが、そのようにカスタマイズ、あるいは、有効化できる場合は、ブロック１５２は、「イエス」ブランチを介して、ブロック１５４に分岐し、ブロック１５４は、メッセージ命令に基づいて、当該機能を有効化する。例えば、ユーザは、フット・コントローラが、あるレベルの感度に設定されていることを望む場合がある。フット・コントローラを、そのようにプログラムできる場合は、ブロック１５４は、当該最高出力およびインクレメントを設定し、ユーザが望むカスタマイゼーションが、達成できるようにする。カスタマイゼーションが、成し遂げられると、制御は、ブロック１５６に渡る。ブロック１５０によって受信された命令が、いかなる機能の有効化も要求していない場合、あるいは、アプリケーションが、有効化できるいかなる機能も有していない場合は、ブロック１５２は、「ノー」ブランチを介して、ブロック１５６に分岐する。
【００３１】
ブロック１５６は、ブロック１５０によって受信された命令に基づいて、ターゲットまたは受信アプリケーションの何らかの不能にすべき機能または能力が有るかどうかを判定する。ある種の機能を不能にする命令が存在する場合、かつ、機能を不能にすることができる場合は、制御は、ブロック１５８に渡り、ブロック１５８は、機能を不能にする。例えば、特定の外科のアプローチでは、ある種のメニューまたは画面は、必要ではなく、これらのメニューまたは画面をバイパスして、所望の手続きの流れの中で、ユーザの注意散漫を最小限に抑えることが望ましい。ブロック１５８が、当該要素を不能にした後で、制御は、ブロック１６０に渡り、ブロック１６０は、ルーチンを終了する。ブロック１５６が、不能にすべき当該機能が無い、と判定した場合は、ブロック１５６は、「ノー」ブランチを介して、ブロック１６０に分岐し、終了する。
【００３２】
上記のデータ構成および論理素子は、Ｃ＋＋（登録商標）などの既知のプログラミング言語のうちのいずれかで実行することができる。コードも、ＣＤなどの取り外し可能なメディアを使用して、ある種のデバイスにロードすることができ、あるいは、更新可能な場合もあるファームウェアに埋め込むことができる。
【図面の簡単な説明】
【００３３】
【図１】本発明の一実施形態で有用なデータ・リンクのトポロジーの概略図である。
【図２】本発明の各種の実施形態で有用な代表的な１３９４コンプライアント・デバイスおよびその上で動作するアプリケーションの概略図である。
【図３】本発明の一実施形態用のコマンドの部分的リストである。
【図４】本発明の一実施形態用のコマンドに対するレスポンスの部分的リストである。
【図５】本発明の一実施形態のコマンド、レスポンス、およびメッセージの一般的構成である。
【図６】本発明の実施形態の一アスペクトのフロー図である。
【図７】本発明の実施形態のさらなるアスペクトのフロー図である。
【図８】本発明の実施形態のまた別のアスペクトのフロー図である。
【図１】
2008534173.tif 000003
【図２】
2008534173.tif 000004
【図３】
2008534173.tif 000005
【図４】
2008534173.tif 000006
【図５】
2008534173.tif 000007
【図６】
2008534173.tif 000008
【図７】
2008534173.tif 000009
【図８】
2008534173.tif 000010
【国際調査報告】
2008534173.tif 000011
2008534173.tif 000012