特許 7463615 副ロボットコントローラに制御を移行するための外科用ロボットシステム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-03-29

(45)【発行日】2024-04-08

(54)【発明の名称】副ロボットコントローラに制御を移行するための外科用ロボットシステム及び方法

(51)【国際特許分類】

   A61B 34/35 20160101AFI20240401BHJP

【ＦＩ】

A61B34/35

【請求項の数】 20

(21)【出願番号】P 2023507664

(86)(22)【出願日】2020-08-04

(65)【公表番号】

(43)【公表日】2023-10-04

(86)【国際出願番号】 US2020044885

(87)【国際公開番号】W WO2022031271

(87)【国際公開日】2022-02-10

【審査請求日】2023-07-14

(31)【優先権主張番号】16/984,704

(32)【優先日】2020-08-04

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】516133124

【氏名又は名称】バーブ サージカル インコーポレイテッド

【氏名又は名称原語表記】Ｖｅｒｂ Ｓｕｒｇｉｃａｌ Ｉｎｃ．

(74)【代理人】

【識別番号】100088605

【弁理士】

【氏名又は名称】加藤 公延

(74)【代理人】

【識別番号】100130384

【弁理士】

【氏名又は名称】大島 孝文

(72)【発明者】

【氏名】デサイ・ジグネシュ

【審査官】近藤 裕之

(56)【参考文献】

【文献】国際公開第２０１９／２２２６４１（ＷＯ，Ａ１）

【文献】特開２０１０－０４４５０１（ＪＰ，Ａ）

【文献】特開２０１７－１５９０２７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ａ６１Ｂ ３４／３５

Ａ６１Ｂ ３４／３０

(57)【特許請求の範囲】

【請求項1】

外科用ロボットであって、
ユーザコンソールと、
前記ユーザコンソールからの第１の入力に応答して前記外科用ロボットを制御するように構成された主コントローラと、
前記ユーザコンソールから遠隔の第２の入力に応答して前記外科用ロボットを制御するように構成された副コントローラと、を備え、
前記副コントローラは、前記主コントローラから通信を受信するように構成されており、
前記外科用ロボットの制御が、前記主コントローラからの前記通信の失敗に応答して前記主コントローラから前記副コントローラに移行され、
前記主コントローラは、前記外科用ロボットを制御するための第１の複数のプロセスを備え、前記副コントローラは、前記第１の複数のプロセスの休止状態にされたコピーを備える、外科用ロボット。

【請求項2】

前記主コントローラが第１のメディエータを含み、前記副コントローラが第２のメディエータを含む、請求項１に記載の外科用ロボット。

【請求項3】

前記主コントローラからの前記通信が、所定のレートで前記第１のメディエータによって送信される心拍メッセージを含む、請求項２に記載の外科用ロボット。

【請求項4】

前記主コントローラからの前記通信の前記失敗が、前記第２のメディエータが１つ以上の前記心拍メッセージを受信できないときに検出される、請求項３に記載の外科用ロボット。

【請求項5】

前記主コントローラが、前記主コントローラが機能状態にあるかどうかを前記第１のメディエータに通知するように構成されたスーパーバイザプロセスを更に備え、前記第１のメディエータが、前記主コントローラが前記機能状態にあるときのみ、前記心拍メッセージを前記第２のメディエータに送信するように構成されている、請求項３に記載の外科用ロボット。

【請求項6】

前記外科用ロボットの前記制御を前記副コントローラに移行することが、前記外科用ロボットを制御するための前記第１の複数のプロセスの前記休止状態にされたコピーをアクティブ化することを含む、請求項１に記載の外科用ロボット。

【請求項7】

前記主コントローラが、前記外科用ロボットを制御するとき、前記外科用ロボットから状態情報を受信するように更に構成されている、請求項１に記載の外科用ロボット。

【請求項8】

前記外科用ロボットの前記制御を前記副コントローラに移行することが、前記状態情報を前記外科用ロボットから前記副コントローラにルーティングすることを含む、請求項７に記載の外科用ロボット。

【請求項9】

前記副コントローラが前記外科用ロボットを制御しているとき、前記副コントローラから所定のレートで心拍メッセージを受信するように構成されたバックアップコントローラを更に備え、
前記外科用ロボットの前記制御が、１つ以上の前記心拍メッセージの欠落に応答して、前記副コントローラから前記バックアップコントローラに移行される、請求項１に記載の外科用ロボット。

【請求項10】

前記副コントローラが、前記外科用ロボットを制御するための第２の複数のプロセスを含み、
前記バックアップコントローラが、前記第２の複数のプロセスの休止状態にされたコピーを含み、
前記外科用ロボットの前記制御を前記バックアップコントローラに移行することが、前記外科用ロボットを制御するための前記第２の複数のプロセスの前記休止状態にされたコピーをアクティブ化することを含む、請求項９に記載の外科用ロボット。

【請求項11】

前記副コントローラが、前記外科用ロボットを制御するとき、前記外科用ロボットから状態情報を受信するように構成されており、前記外科用ロボットの前記制御を前記バックアップコントローラに移行することが、前記外科用ロボットから前記バックアップコントローラに前記状態情報をルーティングすることを含む、請求項９に記載の外科用ロボット。

【請求項12】

前記バックアップコントローラが、前記副コントローラへの電力をオフにするように配電構成要素に命令するように更に構成されている、請求項９に記載の外科用ロボット。

【請求項13】

外科用ロボットシステムであって、
手術台に取り付けられた１つ以上のロボットアームと、
前記手術台の遠隔にある第１のユーザインターフェースデバイスを含むユーザコンソールと、
前記ユーザコンソールにおいて前記第１のユーザインターフェースデバイスから受信された入力に応答して前記１つ以上のロボットアームを制御するように構成された主コントローラと、
前記主コントローラの故障に応答して、前記主コントローラから前記手術台内に位置付けられた副コントローラに前記１つ以上のロボットアームの制御を移行するための手段であって、前記副コントローラが、前記１つ以上のロボットアーム及び前記副コントローラに結合された第２のユーザインターフェースデバイスから受信された入力に応答して前記１つ以上のロボットアームを操縦するように構成されている、手段と、を備え、
前記制御を移行するための手段が、（１）前記副コントローラにおける、前記主コントローラによる前記１つ以上のロボットアームを制御するためのプロセスの休止状態にされたコピーのアクティブ化、又は（２）前記１つ以上のロボットアームを制御する際に前記１つ以上のロボットアームから受信された状態情報が前記１つ以上のロボットアームから前記副コントローラにルーティングされることを含む、外科用ロボットシステム。

【請求項14】

前記１つ以上のロボットアームの制御が、前記主コントローラからの通信の失敗に応答して前記主コントローラから前記副コントローラに移行される、請求項１３に記載の外科用ロボットシステム。

【請求項15】

前記主コントローラが第１のメディエータを含み、前記副コントローラが第２のメディエータを含み、前記主コントローラからの前記通信が、所定のレートで前記第１のメディエータによって送信される心拍メッセージを含む、請求項１４に記載の外科用ロボットシステム。

【請求項16】

前記主コントローラが、前記主コントローラが機能状態にあるかどうかを前記第１のメディエータに通知するように構成されたスーパーバイザプロセスを更に備え、前記第１のメディエータが、前記主コントローラが前記機能状態にあるときのみ、前記心拍メッセージを前記第２のメディエータに送信するように構成されている、請求項１５に記載の外科用ロボットシステム。

【請求項17】

前記主コントローラからの前記通信の前記失敗が、前記副コントローラが１つ以上の心拍メッセージを受信できないときに検出される、請求項１４に記載の外科用ロボットシステム。

【請求項18】

メディエータが、前記外科用ロボットを制御するための前記プロセスの前記休止状態にされたコピーの前記アクティブ化によって、前記外科用ロボットの前記制御を前記副コントローラに移行するように構成されている、請求項１３に記載の外科用ロボットシステム。

【請求項19】

前記副コントローラが前記１つ以上のロボットアームを制御しているとき、前記副コントローラから所定のレートで心拍メッセージを受信するように構成されたバックアップコントローラを更に備え、
前記外科用ロボットの前記制御が、１つ以上の心拍メッセージの欠落に応答して、前記副コントローラから前記バックアップコントローラに移行される、請求項１３に記載の外科用ロボットシステム。

【請求項20】

外科用ロボットであって、
ユーザコンソールと、
前記ユーザコンソールからの第１の入力に応答して前記外科用ロボットを制御するように構成された主コントローラと、
前記ユーザコンソールから遠隔の第２の入力に応答して前記外科用ロボットを制御するように構成された副コントローラであって、
前記副コントローラは、前記主コントローラから通信を受信するように構成されており、
前記外科用ロボットの制御が、前記主コントローラからの前記通信の失敗に応答して前記主コントローラから前記副コントローラに移行される、副コントローラと、
前記副コントローラが前記外科用ロボットを制御しているとき、前記副コントローラから所定のレートで心拍メッセージを受信するように構成されたバックアップコントローラと、を備え、
前記外科用ロボットの前記制御が、１つ以上の心拍メッセージの欠落に応答して、前記副コントローラから前記バックアップコントローラに移行され、
前記副コントローラが、前記外科用ロボットを制御するとき、前記外科用ロボットから状態情報を受信するように構成されており、前記外科用ロボットの前記制御を前記バックアップコントローラに移行することが、前記外科用ロボットから前記バックアップコントローラに前記状態情報をルーティングすることを含む、外科用ロボット。

【発明の詳細な説明】

【技術分野】

【0001】

本技術は、概して、ロボット工学及び手術システムに関し、より具体的には、低侵襲手術用の外科用ロボットシステムのシステムアーキテクチャー及び構成要素に関する。

【背景技術】

【0002】

腹腔鏡手術などの低侵襲手術（minimally-invasive surgery、ＭＩＳ）は、外科手術中の組織損傷を低減することを意図した技術を伴う。例えば、腹腔鏡手術は、典型的には、患者に（例えば、腹部に）いくつかの小さな切開部を作成することと、切開部を通じて患者に、１つ以上の外科用ツール（例えば、エンドエフェクタ及び内視鏡）を導入することとを伴う。次いで、導入された外科用ツールを使用し、内視鏡によって提供される視覚化補助を用いて、外科手術が実行され得る。

【0003】

一般に、ＭＩＳは、患者に残る傷跡が小さく、患者の疼痛が少なく、患者の回復期間が短縮され、患者の回復に関連する医療コストが低減できるなど、複数の利点を提供する。近年の技術開発は、より多くのＭＩＳを、遠隔オペレータからのコマンドに基づいて外科用ツールを操作するための１本以上のロボットアームを含むロボットシステムを用いて実行することを可能にしている。ロボットアームは、例えば、その遠位端において、外科用エンドエフェクタ、撮像デバイス、患者の体腔及び器官へのアクセスを提供するためのカニューレ等の種々のデバイスを支持し得る。ロボットＭＩＳシステムでは、ロボットアームによって支持される外科用器具のために高い位置精度を確立及び維持することが望ましい場合がある。

【0004】

既存のロボット支援手術システムは、通常、患者と同じ手術室に存在する外科医コンソールと、コンソールから制御される４つの対話型ロボットアームを有する患者側カートとからなる。アームのうちの３つは、メス、鋏、又は把持具などの器具を保持し、第４のアームは、内視鏡カメラを支持する。外科手術中に患者を再配置するために、外科スタッフは、器具／アームをドッキング解除し、アーム／患者カートを再配置し、器具／アームを再ドッキングしなければならない場合がある。

【発明の概要】

【課題を解決するための手段】

【0005】

いくつかの態様では、本明細書に開示される外科用ロボットは、ユーザコンソールと、ユーザコンソールからの第１の入力に応答して外科用ロボットを制御するように構成された主コントローラと、ユーザコンソールから遠隔の第２の入力に応答して外科用ロボットを制御するように構成された副コントローラとを備える。副コントローラは、主コントローラから通信を受信するように構成されており、外科用ロボットの制御は、主コントローラからの通信の失敗に応答して、主コントローラから副コントローラに移行される。

【0006】

いくつかの変形形態では、主コントローラは第１のメディエータを含み、副コントローラは第２のメディエータを含む。主コントローラからの通信は、所定のレートで第１のメディエータによって送信される心拍メッセージを含む。主コントローラからの通信の失敗は、第２のメディエータが１つ以上の心拍メッセージを受信できないときに検出される。主コントローラは、主コントローラが機能状態にあるかどうかを第１のメディエータに通知するように構成されたスーパーバイザプロセスを更に備え、第１のメディエータは、主コントローラが機能状態にあるときのみ心拍メッセージを第２のメディエータに送信するように構成されている。主コントローラは、外科用ロボットを制御するための第１の複数のプロセスを備え、副コントローラは、第１の複数のプロセスの休止状態にされたコピーを備える。外科用ロボットの制御を副コントローラに移行することは、外科用ロボットを制御するための第１の複数のプロセスの休止状態にされたコピーをアクティブ化することを含む。主コントローラは、外科用ロボットを制御するときに外科用ロボットから状態情報を受信するように更に構成されている。外科用ロボットの制御を副コントローラに移行することは、状態情報を外科用ロボットから副コントローラにルーティングすることを含む。

【0007】

いくつかの変形例では、外科用ロボットは、副コントローラが外科用ロボットを制御しているときに、副コントローラから所定のレートで心拍メッセージを受信するように構成されたバックアップコントローラを更に備え、外科用ロボットの制御は、１つ以上の心拍メッセージの欠落に応答して、副コントローラからバックアップコントローラに移行される。副コントローラは、外科用ロボットを制御するための第２の複数のプロセスを含み、バックアップコントローラは、第２の複数のプロセスの休止状態にされたコピーを含み、外科用ロボットの制御をバックアップコントローラに移行することは、外科用ロボットを制御するための第２の複数のプロセスの休止状態にされたコピーをアクティブ化することを含む。副コントローラは、外科用ロボットを制御するときに外科用ロボットから状態情報を受信するように構成されており、外科用ロボットの制御をバックアップコントローラに移行することは、状態情報を外科用ロボットからバックアップコントローラにルーティングすることを含む。バックアップコントローラは、副コントローラへの電力をオフにするように配電構成要素に命令するように更に構成されている。

【0008】

いくつかの態様では、本明細書に開示されるロボット方法は、第１の入力デバイスからの入力に基づいて、主ロボットコントローラによって外科用ロボットの動きを制御することと、主ロボットコントローラが外科用ロボットを制御している間、副ロボットコントローラによって主ロボットコントローラから心拍メッセージを受信することと、１つ以上の心拍メッセージの受信に失敗したことに応答して、外科用ロボットの制御を副ロボットコントローラに移行することと、第１の入力デバイスとは異なる第２の入力デバイスからの入力に基づいて、副ロボットコントローラによって外科用ロボットの動きを制御することとを含む。

【0009】

いくつかの変形例では、主ロボットコントローラからの心拍メッセージの受信に失敗することは、主ロボットコントローラにおける電源の故障、ハードウェアの故障、ソフトウェアの故障、及び通信の故障のうちの少なくとも１つによって引き起こされる。外科用ロボットの制御を移行することは、副ロボットコントローラ内のプロセスを休止状態から解除することを含み、副ロボットコントローラ内のプロセスは、外科用ロボットを制御するための主ロボットコントローラ内のプロセスのコピーである。外科用ロボットの制御を移行することは、外科用ロボットから主ロボットコントローラの代わりに副ロボットコントローラに通信をルーティングすることを更に含む。副ロボットコントローラが外科用ロボットの動きを制御することができないと判定したことに応答して、外科用ロボットの制御を副入力デバイスに結合されたバックアップロボットコントローラに移行することであって、外科用ロボットの制御をバックアップロボットコントローラに移行することは、バックアップロボットコントローラ内のプロセスを休止状態から解除することと、外科用ロボットから副ロボットコントローラの代わりにバックアップコントローラに通信をルーティングすることとを含む。

【0010】

いくつかの態様では、本明細書に開示される外科用ロボットシステムは、手術台に取り付けられた１つ以上のロボットアームと、手術台から遠隔の第１のユーザインターフェースデバイスを含むユーザコンソールと、ユーザコンソールにおいて第１のユーザインターフェースデバイスから受信される入力に応答して、１つ以上のロボットアームを制御するように構成された主コントローラと、主コントローラの故障に応答して、１つ以上のロボットアームの制御を、主コントローラから手術台内に位置付けられた副コントローラに移行するための手段であって、副コントローラが、１つ以上のロボットアーム及び副コントローラに結合された第２のユーザインターフェースデバイスから受信された入力に応答して、１つ以上のロボットアームを操縦するように構成されている、手段と、を備える。

【図面の簡単な説明】

【0011】

【図1】主題技術の態様による、外科用ロボットシステムを備えた例示的な手術室環境を示す図である。

【図2】主題技術の態様による、外科用ロボットシステムの例示的なハードウェア構成要素を示すブロック図である。

【図3】一実施形態のネットワークトポロジの図である。

【図4】一実施形態による、外科用ロボットシステムのブロック図である。

【図5】主ロボットアームコントローラにおけるプロセスの故障を検出するための一実施形態の方法のフローチャートである。

【図6】心拍メッセージを監視するための一実施形態の方法のフローチャートである。

【発明を実施するための形態】

【0012】

主題技術の様々な態様及び変形例の例が本明細書に記載され、添付の図面に例示される。以下の説明は、本発明をこれらの実施形態に限定することを意図するものではなく、むしろ、当業者が本発明を作製及び使用することを可能にすることを意図するものである。

【0013】

システムの概要
本明細書では、外科医が低侵襲手術（ＭＩＳ）を行うように設計されたソフトウェア制御の電気機械システムであるロボット支援手術システムが開示される。外科用ロボットシステムは、３つの主要なサブシステム、すなわち、外科医サブシステムであるユーザコンソール（外科医コンソール又は外科医ブリッジ）、中央制御サブシステムである制御タワー、並びに患者サブシステムであるテーブル及びロボットアームから構成され得る。ユーザコンソールの外科医席に着座した外科医は、マスタユーザ入力デバイス（ＵＩＤ）及びフットペダルを使用して、互換性のある器具の動きを制御し得る。外科医は、高解像度オープンステレオディスプレイ上で三次元（３Ｄ）内視鏡画像を見ることができ、その画像は、アイコン、アプリ、及び他のユーザインターフェース特徴と共に、患者の解剖学的構造及び器具類のビューを外科医に提供する。ユーザコンソールはまた、外科医シートの後部から引き出すことができる潜望鏡を使用して没入型ディスプレイのためのオプションを提供してもよい。

【0014】

制御タワーは、外科用ロボットシステムの制御及び通信センターとして機能することができる。制御タワーは、タッチスクリーンディスプレイを収容する治療現場移動カートであってもよく、他の支援電子及び処理機器の中でも、器具、安全システム、グラフィカルユーザインターフェース（ＧＵＩ）、高度光エンジン（光源とも称される）、並びにビデオ及びグラフィックプロセッサの外科医のロボット支援操作を制御するコンピュータを含んでもよい。制御タワーはまた、電気外科発生器ユニット（electrosurgical generator unit、ＥＳＵ）、並びに吹入器及びＣＯ_２タンクのようなサードパーティデバイスを収容することができる。

【0015】

患者サブシステムは、例えば、標的患者生体構造の上に位置付けられる最大４つの統合ロボットアームを伴う、関節式手術室（operating room、ＯＲ）の台であってもよい。手術システムのロボットアームは、遠隔中心設計を組み込んでもよく、すなわち、各アームは、カニューレが患者の体壁を通過する空間内の固定点を中心に枢動する。これにより、カニューレの横方向の動きが減少し、患者の体壁上の応力が最小になる。互換性のあるツール一式は、各アームの遠位端に搭載された器具ドライバから着脱させることができ、外科医が種々の外科タスクを行うことを可能にする。器具ドライバは、手術部位への体内アクセス、滅菌インターフェースを介した互換性のあるツールの機械的作動、並びに滅菌インターフェース及びユーザタッチポイントを介した互換性のあるツールとの通信を提供することができる。内視鏡は、任意のアームに取り付けることができ、外科医に患者の解剖学的構造の高解像度の三次元ビューを提供することができる。内視鏡はまた、手術の開始時に内視鏡的に（手持ち型で）使用され、次いで４つのアームのうちのいずれか１つに取り付けることができる。外科用ロボットシステムによって処置を行うために、トロカール（スリーブ、シールカートリッジ、及び栓子とも称される）及びドレープなどの他の付属品も必要であり得る。

【0016】

外科用ロボットシステムは、内視鏡、互換性のある内視鏡器具、及び付属品と共に使用することができる。システムは、手術室環境において訓練された医師によって使用され、ロボット支援の泌尿器科、婦人科、及び他の腹腔鏡外科手術の間、互換性のある内視鏡器具の正確な制御を支援し得る。システムはまた、手術スタッフが、泌尿器科、婦人科、及び他の腹腔鏡外科手術の間、ロボットアームのドッキングを解除することなく、台を調節することによって、患者を再配置することを可能にする。手術システムと共に使用するための互換性のある内視鏡器具及び付属品は、把持、切断、鈍的及び鋭的切開、接近、結紮、電気焼灼、並びに縫合を含む、組織の内視鏡操作を目的とする。

【0017】

ここで図面を参照すると、図１は、主題技術の態様による、外科用ロボットシステム１００を有する例示的な手術室環境を示す図である。図１に示されるように、外科用ロボットシステム１００は、ユーザコンソール１１０と、制御タワー１３０と、手術プラットフォーム１２４（例えば、台又はベッド等）上に搭載された１つ以上の外科用ロボットアーム１２２を有する外科用ロボット１２０とを備え、エンドエフェクタ（例えば、メス、鋏、又は把持具）を有する外科用ツールが、外科手術を実行するためにロボットアーム１２２の遠位端に取り付けられる。ロボットアーム１２２は、台に装着されたシステムとして示されているが、他の構成では、ロボットアームは、カート、天井、若しくは側壁、又は別の好適な構造的支持面に装着され得る。

【0018】

一般に、外科医又は他の操作者などのユーザが、ユーザコンソール１１０に着座して、ロボットアーム１２２及び／又は外科用ツールを遠隔操作し得る（例えば、テレオペレーション）。ユーザコンソール１１０は、図１に示すように、ロボットシステム１００と同じ手術室内に位置してもよい。その他の環境では、ユーザコンソール１１０は、隣接する若しくは近くの部屋に位置してもよいし、又は異なる建物、都市、若しくは国内の遠隔地から遠隔操作されてもよい。ユーザコンソール１１０は、座席１１２と、ペダル１１４と、１つ以上の手持ち型ユーザインターフェースデバイス（user interface device、ＵＩＤ）１１６と、例えば、患者内の手術部位の視野を表示するように構成されたオープンディスプレイ１１８とを備えてもよい。例示的なユーザコンソール１１０に示すように、座席１１２に座ってオープンディスプレイ１１８を見ている外科医は、ペダル１１４及び／又は手持ち型ユーザインターフェースデバイス１１６を操作して、ロボットアーム１２２及び／又はアーム１２２の遠位端に取り付けられた手術器具を遠隔制御し得る。

【0019】

いくつかの変形例では、ユーザはまた、「ベッド対面」（over the bed、ＯＴＢ）モードで外科用ロボットシステム１００を動作させてもよく、ＯＴＢモードでは、ユーザは患者の側にいて、ロボット駆動ツール／それに取り付けられたエンドエフェクタ（例えば、片手に保持された手持ち型ユーザインターフェースデバイス１１６を用いて）及び手動腹腔鏡ツールを同時に操作する。例えば、ユーザの左手は、手持ち型ユーザインターフェースデバイス１１６を操作して、ロボット手術構成要素を制御する一方、ユーザの右手は、手動式腹腔鏡ツールを操作していてもよい。したがって、これらの変形例では、ユーザは、ロボット支援ＭＩＳ及び手動腹腔鏡手術の両方を患者に実施し得る。

【0020】

例示的な処置又は手術の間、患者は、麻酔を達成するために、滅菌されて準備され覆われている。手術部位への当初のアクセスは、手動で実行され得るが、ロボットシステム１００は、手術部位へのアクセスを容易にするために収容構成又は撤収構成にある。アクセスが完了すると、ロボットシステムの初期配置又は準備が実行され得る。処置中、ユーザコンソール１１０内の外科医は、ペダル１１４及び／又はユーザインターフェースデバイス１１６を利用して、種々のエンドエフェクタ及び／又は撮像システムを操作し、手術を実行し得る。組織を開創すること、又は１つ以上のロボットアーム１２２を伴う手動再位置付け若しくはツール交換を行うことを含むが、それらに限定されないタスクを行い得る、手術台での無菌管理者による手動支援も提供され得る。また、ユーザコンソール１１０において外科医を支援するために、非滅菌要員も存在し得る。処置又は手術が完了すると、ロボットシステム１００及び／又はユーザコンソール１１０は、ロボットシステム１００の洗浄及び／又は滅菌、及び／又はユーザコンソール１１０を介するような、健康管理記録の入力若しくはプリントアウト（電子的であるか又はハードコピーであるかにかかわらない）を含むがこれらに限定されない、１つ以上の術後処置を容易にする状態に構成又は設定され得る。

【0021】

いくつかの態様では、外科用ロボット１２０とユーザコンソール１１０との間の通信は、制御タワー１３０を介して行われてもよく、制御タワー１３０は、ユーザコンソール１１０からのユーザ入力をロボット制御コマンドに変換し、制御コマンドを外科用ロボット１２０に送信することができる。制御タワー１３０はまた、ロボット１２０からのステータス及びフィードバックをユーザコンソール１１０に返送し得る。外科用ロボット１２０と、ユーザコンソール１１０と、制御タワー１３０との間の接続は、有線及び／又は無線リンクを介してもよく、独自であってもよく、及び／又は様々なデータ通信プロトコルの任意のものを使用して行われてもよい。任意の有線接続が、手術室の床及び／又は壁若しくは天井に任意選択的に内蔵されていてもよい。外科用ロボットシステム１００は、手術室内のディスプレイ、並びにインターネット又はその他のネットワークを介してアクセス可能である遠隔ディスプレイを含む、１つ以上のディスプレイにビデオ出力を提供してもよい。ビデオ出力又はフィードはまた、プライバシーを確保するために暗号化されてもよく、ビデオ出力のすべて又は一部は、サーバ又は電子健康管理記録システムに保存されてもよい。

【0022】

外科用ロボットシステムで手術を開始する前に、外科チームは術前セットアップを実行し得る。術前セットアップ中、外科用ロボットシステムの主要な構成要素（台１２４及びロボットアーム１２２、制御タワー１３０、及びユーザコンソール１１０）が手術室に位置付けられ、接続され、電力が供給される。台１２４及びロボットアーム１２２は、保管及び／又は輸送の目的のために、アーム１２２が台１２４の下にある完全に収納された構成であってもよい。外科チームは、無菌ドレーピングのためにアームをそれらの収容位置から延長させることができる。ドレーピング後、使用に必要になるまで、アーム１２２を部分的に引き込むことができる。トロカール配置及び吹入を含むいくつかの従来の腹腔鏡の工程が、実施される必要があり得る。例えば、各スリーブは、閉塞具の助けを借りて、小さな切開部に、かつ体壁を介して挿入され得る。スリーブ及び閉塞具は、挿入中の組織層の視覚化のための光学的入口を可能にして、配置中の損傷のリスクを最小限に抑える。内視鏡は、典型的には、最初に配置されて、その他のトロカールの配置のための手持ち型カメラの視覚化を提供する。吹入後、必要に応じて、手動器具がスリーブを通じて挿入され、任意の腹腔鏡の工程を手動で行うことができる。

【0023】

次に、外科チームは、ロボットアーム１２２を患者の上に位置付け、各アーム１２２をその対応するスリーブに取り付け得る。外科用ロボットシステム１００は、各ツール（内視鏡及び外科用器具）が取り付けられるとすぐにそれらを個別に特定し、ツールタイプ及びアーム位置を、例えば、ユーザコンソール１１０のオープン又は没入型ディスプレイ１１８、並びに制御タワー１３０上のタッチスクリーンディスプレイに表示する能力を有する。対応するツール機能を有効にして、ＵＩＤ１１６及びフットペダル１１４を使用して起動させ得る。患者側のアシスタントは、処置全体を通じて、必要に応じてツールを取り付けたり取り外したりすることができる。ユーザコンソール１１０に着座した外科医は、２つのマスタＵＩＤ１１６及びフットペダル１１４によって制御されるツールを使用して手術を行い始めることができる。システムは、外科医の手、手首、及び指の動きを、マスタＵＩＤ１１６を介して、外科用ツールの正確なリアルタイムの動きに変換する。したがって、システムは、外科医のあらゆる手術操作を常に監視し、システムが外科医の手の動きを正確に反映することができない場合、器具の移動を一時停止する。内視鏡が手術中に一方のアームから他方のアームに移動する場合、システムは、器具の位置合わせのためにマスタＵＩＤ１１６を調節し、器具の制御及び運動を継続することができる。フットペダル１１４は、マスタＵＩＤ１１６から外科医の手を離すことなく、内視鏡制御並びに単極及び双極焼灼を含む様々な器具機能などの各種システムモードを起動させるために使用されてもよい。

【0024】

台１２４は手術中に再位置決めすることができる。安全上の理由から、すべてのツール先端は、ユーザコンソール１１０において、外科医によって視認され、能動的制御下にあるべきである。能動的な外科医の制御下にない器具は取り外されなければならず、台の脚は係止されなければならない。台の動作中、一体型ロボットアーム１２２は、台の動きに受動的に追従し得る。音声及び視覚キューを使用して、台の動作中に外科チームを誘導することができる。音声キューは、トーン及び音声プロンプトを含んでもよい。ユーザコンソール１１０及び制御タワー１３０におけるディスプレイ上の視覚的メッセージは、外科チームに台動作ステータスを通知することができる。

【0025】

システムアーキテクチャー
図２は、主題技術の態様による、外科用ロボットシステム６００の例示的なハードウェア構成要素を示すブロック図である。例示的な外科用ロボットシステム６００は、ユーザコンソール１１０、外科用ロボット１２０、及び制御タワー１３０を含み得る。外科用ロボットシステム６００は、他の又は追加のハードウェア構成要素を含み得るため、図は、一例として提供されるものであり、このシステムアーキテクチャーへの限定ではない。

【0026】

上述したように、ユーザコンソール１１０は、コンソールコンピュータ６１１と、１つ以上のＵＩＤ６１２と、コンソールアクチュエータ６１３と、ディスプレイ６１４と、ＵＩＤトラッカ６１５と、フットペダル６１６と、ネットワークインターフェース６１８とを備える。ユーザコンソール１１０に着座しているユーザ又は外科医は、ユーザコンソール１１０の人間工学的な設定を手動で調整することができ、又は設定は、ユーザプロファイル又は選好に従って自動的に調整され得る。手動調整及び自動調整は、ユーザ入力又はコンソールコンピュータ６１１によって記憶された構成に基づいてコンソールアクチュエータ６１３を駆動することを通じて達成され得る。ユーザは、２つのマスタＵＩＤ６１２及びフットペダル６１６を使用して外科用ロボット１２０を制御することによって、ロボット支援手術を行い得る。ＵＩＤ６１２の位置及び向きは、ＵＩＤトラッカ６１５によって継続的に追跡され、状態の変化は、コンソールコンピュータ６１１によってユーザ入力として記録されて、ネットワークインターフェース６１８を介して制御タワー１３０に送られる。患者の解剖学的構造のリアルタイム手術ビデオ、器具使用、及び関連するソフトウェアアプリケーションは、開放型又は没入型ディスプレイを含む、高解像度三次元ディスプレイ６１４上でユーザに提示することができる。

【0027】

他の既存の外科用ロボットシステムとは異なり、本明細書に開示されるユーザコンソール１１０は、単一の光ファイバケーブルを通じて制御タワー１３０に通信可能に結合され得る。ユーザコンソールはまた、改善された人間工学のための追加的な特徴も提供する。例えば、没入型ディスプレイのみと比較して、開放型ディスプレイ及び没入型ディスプレイ両方が提供される。更に、人間工学的改善のために、外科医のための高度に調整可能な椅子及び電磁又は光トラッカを通じて追跡されるマスタＵＩＤがユーザコンソール１１０に含まれる。安全性を向上させるために、視線追跡、頭部追跡、及び／又は椅子の旋回追跡を実行して、例えばユーザの視線が所定の期間を超えて開放型ディスプレイの手術部位に係合されていないときに遠隔操作を一時停止又はロックすることによって、偶発的なツールの運動を防止することができる。

【0028】

制御タワー１３０は、タッチスクリーンディスプレイ、外科医のロボット支援型の器具の操作を制御するコンピュータ、安全システム、グラフィカルユーザインターフェース（graphical user interface、ＧＵＩ）、光源、並びにビデオ及びグラフィックコンピュータを収容する治療現場移動カートとすることができる。図２に示されるように、制御タワー１３０は、少なくとも視覚化コンピュータ、制御コンピュータ、及び補助コンピュータを含む中央コンピュータ６３１と、チームディスプレイ及び看護師ディスプレイを含む様々なディスプレイ６３３と、制御タワー１３０をユーザコンソール１１０及び外科用ロボット１２０の両方に結合するネットワークインターフェース６３８と、を含み得る。制御タワー１３０はまた、高度な光エンジン６３２、電気外科用発電ユニット（electrosurgical generator unit、ＥＳＵ）６３４、並びに吹入器及びＣＯ_２タンク６３５などの、サードパーティデバイスも収容し得る。制御タワー１３０は、看護師ディスプレイタッチスクリーン、ソフトパワー及びＥ－ホールドボタン、ビデオ及び静止画像のためのユーザフェーシングＵＳＢ、並びに電子キャスタ制御インターフェースなどの、ユーザの利便性のための追加的な特徴を提供し得る。補助コンピュータはまた、リアルタイムＬｉｎｕｘを実行し得、ロギング／監視、及びクラウドベースのウェブサービスとの相互作用を提供する。

【0029】

外科用ロボット１２０は、標的の患者の解剖学的構造の上に位置付けることができる複数の一体型アーム６２２を有する、関節運動手術台６２４を含む。互換性のあるツール６２３一式は、アーム６２２の遠位端に取り付けること、又はそこから取り外すことができるツール６２３を含み、外科医が、様々な外科手術を行うことを可能にする。外科用ロボット１２０はまた、アーム６２２、台６２４、及びツール６２３の手動制御のための制御インターフェース６２５も含み得る。制御インターフェースは、限定されないが、遠隔制御装置、ボタン、パネル、及びタッチスクリーンなどのアイテムを含むことができる。システムによって処置を行うために、トロカール（スリーブ、シールカートリッジ、及び栓子）及びドレープなどの他の付属品も必要であり得る。いくつかの変形例では、複数のアーム６２２は、各側に２つのアームを有する、手術台６２４の両側上に装着された４つのアームを含む。特定の外科手術の場合、台の一方の側に装着されたアームは、台及び他方の側に装着されたアームの下に伸ばして交差させることによって、台の反対側に位置付けることができ、これにより台６２４の同じ側に位置付けられた合計で３つのアームをもたらす。外科用ツールはまた、台のコンピュータ６２１（以下で説明する台アダプタコントローラ７００など）と、外科用ロボット１２０を制御タワー１３０と通信状態に置くことができるネットワークインターフェース６２８とを備えることができる。

【0030】

ネットワークトポロジ
一実施形態では、制御タワー、台コントローラ、及びロボットアームは、リングネットワークなどのネットワークを介して互いに通信するが、他のタイプのネットワークを使用することもできる。図３は、一実施形態のネットワークトポロジの図である。図３に示すように、制御タワーの制御コンピュータ６３１は、コントローラＲｉｎｇＮｅｔインターフェース（controller RingNet interface、ＣＲＩ）６３８を使用して、本明細書でＲｉｎｇＮｅｔ－Ｃと呼ばれるプロトコルを使用して台のコンピュータ（ここでは、本明細書で「ベースコントローラ」とも呼ばれる台のアダプタコントローラ（table adapter controller、ＴＡＣ）７００）と通信し、「Ｃ」は「コントローラＲｉｎｇＮｅｔインターフェース」を指す。ＴＡＣ７００は、本明細書でＲｉｎｇＮｅｔ－Ａとして指定された異なるプロトコルを使用してロボットアーム６２２と通信し、「Ａ」は「アーム」を指す。図３に示すように、ＴＡＣ７００は、台６２４の構成要素のクラスタ（本明細書では「ＴＡＣクラスタ」と呼ばれることもある）と通信することもできる。例えば、この実施形態では、台６２４は関節式に連結され、台の旋回コントローラ（table pivot controller、ＴＰＣ）７１０によって制御される駆動モータを有して、台上面の傾斜、移動などを行う。また、図３に示すように、台の配電ボード（table power distribution board、ＴＰＤ）７２０、台のベースコントローラボード（ＴＢＣ）７３０、及び台のスピーカボード（table speaker board、ＴＳＢ）７３５は、コントローラエリアネットワーク（controller area network、ＣＡＮ）を介してＴＡＣ７００と通信する。もちろん、現在存在するか又は将来開発される他の構成要素及びネットワークプロトコルを使用することができる。ＴＡＣクラスタ内の様々な台の構成要素は、台のエンドポイントと呼ばれることもある。

【0031】

この実施形態における各ロボットアームは、隣接するリンク間に複数のノードを含む。本明細書で使用される場合、「ノード」は、概して、ロボット手術システム（例えば、ＴＡＣ７００）のコントローラと通信する構成要素を指すことができる。本明細書で「関節モジュール」と呼ばれることもある「ノード」は、（例えば、一連のプーリ及びプーリを接続する一連のバンドを動かして４バーリンク機構の動きを容易にするためにモータを使用することによって）ロボットアームの１つのリンクを別のリンクに対して作動させるために使用することができる。外部コントローラ（以下でより詳細に説明する）からのコマンドに応答して、ノードを使用して、ロボットアーム内の様々なリンクを関節運動させて、外科手術のためにアームを操作することができる。ノードの例としては、限定するものではないが、単一モータ（例えば、サーボモータ、枢動リンクモータ、関節モータ、及びツール駆動モータ）、二重モータ（例えば、個々のモータ出力を組み合わせるための差動歯車駆動を伴う）、無線ツールインターフェース（例えば、ツール無線ボード）、位置センサ（例えば、アームリンク／セグメントの変位を測定するエンコーダ）、力／トルクセンサ、入力／出力ボード、電力及び／又は通信リンクを監視する構成要素、又はデータを受信／伝送することができる任意の他の構成要素のうちの１つ以上が挙げられる。ノードはまた、限定するものではないが、モータコントローラ／ドライバ、信号プロセッサ、及び／又は回路基板上の通信電子機器などの様々な電子機器を含むことができる。

【0032】

コントローラのいずれも、任意の好適な様式で実装され得ることに留意されたい。例えば、コントローラは、処理回路、マイクロプロセッサ又はプロセッサ、並びに（マイクロ）プロセッサ、論理ゲート、スイッチ、特定用途向け集積回路（application specific integrated circuit、ＡＳＩＣ）、プログラマブル論理コントローラ、及び埋め込みマイクロコントローラによって実行可能なコンピュータ可読プログラムコード（例えば、ファームウェア）を記憶するコンピュータ可読媒体の形態をとることができる。コントローラは、以下で説明され、フロー図に示される様々な機能を実行するために、ハードウェア及び／又はファームウェアで構成することができる。より一般的には、コントローラ（又はモジュール）は、様々な動作を実行するように構成された「回路」を含むことができる。本明細書で使用される場合、「回路」という用語は、中央処理装置（Central Processing Unit、ＣＰＵ）、マイクロコントローラ、若しくはマイクロプロセッサなどの命令プロセッサ；又は特定用途向け集積回路（Application Specific Integrated Circuit、ＡＳＩＣ）、プログラマブルロジックデバイス（Programmable Logic Device、ＰＬＤ）、若しくはフィールドプログラマブルゲートアレイ（Field Programmable Gate Array、ＦＰＧＡ）；又はアナログ回路構成要素、デジタル回路構成要素、若しくはその両方を含む、離散論理若しくは他の回路構成要素の集合；あるいはそれらの任意の組み合わせを指すことができる。回路は、例として、個別の相互接続されたハードウェア構成要素を含んでもよく、若しくは単一の集積回路ダイ上で組み合わされてもよく、複数の集積回路ダイの間で分散されてもよく、又は共通パッケージ内の複数の集積回路ダイのマルチチップモジュール（Multiple Chip Module、ＭＣＭ）内に実装されてもよい。したがって、「回路」は、実行するための命令を記憶してもよく又は命令にアクセスしてもよく、又はその機能をハードウェアのみで実装してもよい。

【0033】

制御ＰＣ（マスタコントローラ）６３１は、ロボットアーム６２２又はＴＡＣクラスタ内の構成要素（例えば、ＴＰＤ７２０、ＴＢＣ７３０、及びＴＳＢ７３５）と情報を通信することができる。動作中、制御ＰＣ６３１は、情報のフレームをＴＡＣ７００に送信し、ＴＡＣ７００内のＦＰＧＡは、そのフレームをＴＡＣクラスタ又はロボットアーム６２２にルーティングするかどうかを決定する。一実施形態では、制御ＰＣ６３１とロボットアーム６２２との間の通信は、リアルタイム（又は略リアルタイム）で行われるが、ＴＡＣ７００に接続されたクラスタ内の様々な構成要素との通信は、疑似又は非リアルタイムで行うことができる。ロボットアーム６２２が患者と相互作用しているため、制御ＰＣ６３１とロボットアーム６２２の様々なノード（例えば、ＤＳＰモータコントローラ）との間のコマンド／応答通信が妨げられず、待ち時間がほとんど又は全くなく、ジッタが最小であることが好ましい。いくつかの実施形態では、アーム６２２は、予期される時間内に制御ＰＣ６３１から通信を受信しない場合、エラーメッセージを送信してもよい。本明細書で使用される場合、通信は、その通信の受信のために設定された期限までに通信が受信される場合、リアルタイムで発生する。略リアルタイムとは、送信遅延に起因して期限外に受信されるが、それでも許容可能であり得る通信を指す。

【0034】

対照的に、制御ＰＣ６３１とＴＡＣクラスタとの間の通信は、重要であるが、それほど緊急ではない。例えば、台のベースコントローラ（ＴＢＣ）７３０内のハードウェアは、（例えば、重力ベクトルの変化を検出することによって）台の角度が変化したことを検出することができ、又は台の配電（ＴＰＤ）ボード７２０内のハードウェアは、ロボットアーム６２２のうちの１つにおける過電流状況を検出してもよく、それらの構成要素内のソフトウェアは、制御ＰＣ６３１に警告メッセージを送り返すことができる（例えば、制御ＰＣ６３１のグラフィカルユーザインターフェース上に警告を表示することができる）。この場合も、この情報は重要であるが、ロボットアーム６２２とのコマンド／応答通信において許容されるよりも多くの待ち時間及び／又はジッタで制御ＰＣ６３１に通信することができる。そのような通信は、非リアルタイム又は疑似リアルタイムであり得る（すなわち、通信は、特定の期限までに受信される必要はない）。

【0035】

上述したように、ＴＡＣフレーム及びアームフレームは別個のフレームであってもよく、ＴＡＣ７００は、フレームをロボットアーム６２２又はＴＡＣクラスタに適宜ルーティングする。一実施形態では、アームフレームは、４ｋＨｚ（２５０マイクロ秒）毎に制御ＰＣ６３１によって送信される一定長フレームであり、ＴＡＣフレームは、（制御ＰＣ６３１が、ＴＡＣクラスタ内の複数のエンドポイントからの情報を要求する場合があり、応答長が変動する場合があるため）可変長フレームである。再び、一実施形態では、アームフレームは、リアルタイム又は略リアルタイムベースで通信され、ＴＡＣフレームは、疑似又は非リアルタイムベースで通信される。アーム及びＴＡＣフレームは、ファイバ内で時間多重化することができる。

【0036】

移行制御
ユーザコンソールとＴＡＣとの間の通信チャネルに故障が発生する可能性があり、その結果、外科医がユーザコンソールのユーザ入力デバイスを用いてロボットアームを移動させることができなくなる可能性がある。これが発生する場合、ロボットアームは、おそらく患者の内部で、適所で作動停止させることができる。これは、患者がロボットアームによって捕らえられる危険な状況を招く可能性がある。以下の実施形態を使用して、主コンピュータの損失による患者の捕捉を軽減するために、そのような故障を検出し、制御タワー内の故障した主コンピュータからＴＡＣ内の副コンピュータ（及び必要に応じて１つ以上のバックアップ）への制御の移行をトリガする／容易にすることができる。

【0037】

一般に、主及び／又は副ロボット制御コンピュータが故障したときに、遠隔操作モード（遠隔操作）からスタンドアロンモードへの検出、トリガ、及び移行を容易にする電気インフラストラクチャと相互作用するために、ソフトウェア機構を使用することができる。通常の動作条件下では、制御タワーをホストとするコンピュータは、ロボットの主コントローラである。遠隔操作（すなわち、遠隔制御又は遠隔モード）は、この主コンピュータが健全である場合にのみ許可される。主コンピュータの損失は、患者の捕捉に関連する危険な状況につながる可能性がある。そのような状況に対するハードウェア軽減として、バックアップを有するスタンバイ副コンピュータが提供される。ソフトウェア故障、ハードウェア故障、及び／又は通信故障の検出、並びに切り替えのトリガは、ハードウェア及び／又はソフトウェアによって実行することができる。例えば、一実施形態では、故障を検出し、副コンピュータへの切り替えをトリガする問題は、ソフトウェア機構を介するものであり、ソフトウェア機構はハードウェアと共に、副コンピュータへの遠隔からスタンドアロンへの移行を達成する。一実施形態では、副コンピュータが故障した場合、バックアップコンピュータへの切り替えを行うことができる。以下の段落は、この実施形態の１つの例示的な実装形態を説明する。これは一例に過ぎず、他の実装形態が使用され得ることを理解されたい。

【0038】

再度図面に戻ると、図４は、一実施形態の外科用ロボットシステムのブロック図である。構成要素のいくつかは、他の図面に関連して先に説明されている。図４に示されるように、システム全体は、概して、ユーザコンソール１１０と、主ロボットアームコントローラ６３１（本明細書では、制御ＰＣと称されることもあり、制御タワー１３０の一部であり得る）と、台のアダプタコントローラ（ＴＡＣ）７００と、１つ以上のロボットアーム６２２とを備える。

【0039】

この実施形態では、ユーザコンソール１１０は、１つ以上のユーザ入力デバイス６１２及びディスプレイ６１４を備える。遠隔操作モードでは、外科医は、ディスプレイ６１４上で手術部位を見て、ユーザ入力デバイス６１２を使用してロボットアーム６２２を操作する。これを行うために、ユーザ入力デバイス６１２の操作によって生成された信号は、制御タワー１３０内の主ロボットアームコントローラ６３１に送信され、主ロボットアームコントローラ６３１は、これらの信号をロボット制御信号に変換し、ロボット制御信号は、（例えば、ＲｉｎｇＮｅｔ－Ｃ上の）ＴＡＣ７００に送信される。次いで、ＴＡＣ７００は、ＲｉｎｇＮｅｔ－Ａを介してロボット制御信号をロボットアーム６２２に送出して、ユーザ入力デバイス６１２の外科医の動きに従ってそれらを動かす。ロボットアーム６２２からのフィードバック及び他の情報は、（例えば、同様にＲｉｎｇＮｅｔ－Ｃ上の）ＴＡＣ７００を介して、主ロボットアームコントローラ６３１に送り返すことができる。

【0040】

上述したように、主ロボットアームコントローラ６３１とＴＡＣ７００との間のメッセージの通信に故障がある可能性がある。障害が発生すると、外科医は、ユーザコンソール１１０のユーザ入力デバイス６１２を用いてロボットアーム６２２を移動させることができなくなり、その結果、患者がロボットアーム６２２によって捕捉される可能性がある。この状況に対処するために、この実施形態は、主ロボットアームコントローラ６３１の故障に応答して、ロボットアーム６２２の動きの制御を主ロボットアームコントローラ６３１からＴＡＣ７００内の副ロボットアームコントローラ４００に移行することを可能にする。このようにして、副ロボットアームコントローラ４００は、ユーザコンソール１１０から遠隔にあるユーザ入力デバイス４２０（例えば、ロボットアーム６２２又は手術台の上又は付近のキーパッド）から受信される信号に応答して、ロボットアーム６２２を動かすことができる。

【0041】

より具体的には、図４に示すように、この実施形態では、主ロボットアームコントローラ６３１は、複数のプロセス４３０と、プロセススーパーバイザ４４０と、遠隔メディエータ４５０とを備える。ソフトウェア（例えば、プロセッサによって実行されるコンピュータ可読プログラムコード）及び／又はハードウェアで実行することができるプロセス４３０は、ユーザコンソール１１０内のユーザ入力デバイス６１２によって提供される信号を、ロボットアーム６２２の動きのためのコマンドに変換する。プロセス４３０は、限定するものではないが、ロボットアーム６２２からのフィードバック又は他の情報に反応することなどの他の機能も実行することができる。プロセッサスーパーバイザ４４０は、ＱＮＸ高可用性マネージャ（high availability manager、ＨＡＭ）として実装することができ、プロセス４３０の機能を監視するソフトウェア及び／又はハードウェアモジュールである。プロセッサスーパーバイザ４４０は、プロセス４３０の健全性（すなわち、プロセス４３０が機能状態にあるか否か）を遠隔メディエータ４５０に通知する。例えば、電源故障、ソフトウェア故障、ハードウェア故障、ドライバ故障、通信インターフェース／チャネル故障などがある場合、プロセスのうちの１つ以上は、機能状態にない可能性がある。

【0042】

図５のフローチャート５００に示すように、プロセッサスーパーバイザ４４０は、プロセス４３０を監視し（動作５１０）、それらが機能しているか否かを判定する（動作５３０）。プロセス４３０が機能している場合、プロセッサスーパーバイザ４４０は、遠隔メディエータ４５０に通知し（動作５３０）、遠隔メディエータ４５０は、メッセージ（本明細書では心拍メッセージと称される）を副ロボットアームコントローラ４００内の対応する独立型メディエータ４６３に（例えば、ＲｉｎｇＮｅｔ－Ｃを介して）一定速度で（例えば、所定の間隔で）送信する（動作５４０）。しかしながら、プロセス４３０が機能していない場合、プロセッサスーパーバイザ４４０は、遠隔メディエータ４５０に通知し（動作５５０）、遠隔メディエータ４５０は、心拍メッセージを副ロボットアームコントローラ４００内の独立型メディエータ４６３に送信しない（動作５６０）。

【0043】

図６のフローチャート６００に示されるように、独立型メディエータ４６３は、心拍メッセージを監視し（動作６１０）、心拍メッセージが受信されたか否かを判定する（動作６２０）。心拍メッセージが受信された場合、副ロボットアームコントローラ４００は、心拍メッセージの存在を監視し続ける。しかしながら、１つ以上の心拍メッセージ（例えば、連続する３つの心拍メッセージ）が受信されなかった場合、独立型メディエータ４６３は、主ロボットアームコントローラ６３１の故障を検出し、ロボットアーム６２２の移動に対する制御を主ロボットアームコントローラ６３１から副ロボットアームコントローラ４００に移行する（動作６３０）。

【0044】

この移行は、任意の適切な方法で実施することができる。一実施形態では、独立型メディエータ４０２に加えて、副ロボットアームコントローラ４００は、主ロボットアームコントローラ６３１内のプロセス４０６の休止状態にされたコピーを含む。両方の構成要素が同じプロセスを有することによって、主ロボットアームコントローラ６３１及び副ロボットアームコントローラ４００の両方は、ユーザ入力に応答してロボットアーム６２２を移動させる能力を有する。この実施形態では、ロボット手術システムの電源が投入されると、プロセス４０６、４３０の両方が初期化されるが、副ロボットアームコントローラ４００内のプロセス４０６は休止状態に置かれる。独立型メディエータ４０２が、遠隔メディエータ４５０から心拍を取得しないことによって故障を検出した場合、独立型メディエータ４０２は、休止状態にされたプロセス４０６をアクティブ化し、それによってそれらを休止状態から解除する。これにより、プロセス４０６が、遠隔ユーザ入力デバイス４２０から入力を受信して、ロボットアーム６２２を動かすことが可能になる。この場合も、この動きは、ユーザコンソール１１０又は制御タワー１３０内の主ロボットアームコントローラ６３１の関与なしに行われる。

【0045】

副ロボットアームコントローラ４００内のプロセス４０６に引き継がせることに加えて、制御を移行するために他の動作を行うことができる。例えば、通常動作では、リアルタイム情報は、ロボットアーム６２２からＲｉｎｇＮｅｔ－Ａを介してスイッチ４６０に移動し、次いで、スイッチ４６０からＲｉｎｇＮｅｔ－Ｃを介してロボットアームコントローラ６３１に移動する。この情報は、例えば、要求されたアームの動きに関するフィードバック情報及びエラー信号を含むことができる。主ロボットアームコントローラ６３１が故障状態にある場合、この情報に基づいて動作することができない場合がある。したがって、この状況では、ロボットアーム６２２から送信された情報は、代わりに副ロボットアームコントローラ４００に転送することができる。図４に示す実施形態では、ＴＡＣ７００は、ロボットアーム６２２からの情報を主ロボットアームコントローラ６３１又は副ロボットアームコントローラ４００のいずれかにルーティングするように構成されたスイッチ４６０（例えば、フィールドプログラマブルゲートアレイ又は他のプログラマブルロジック）を備える。副ロボットアームコントローラ４００が主ロボットアームコントローラ６３１の故障を検出すると、副ロボットアームコントローラ４００は、ロボットアーム６２２からの情報を副ロボットアームコントローラ４００にルーティングするようにスイッチ４６０をプログラムする。

【0046】

ここで別の特徴に目を向けると、副ロボットアームコントローラ４００のプロセス４０６に故障があり得る可能性があり、これは、主ロボットアームコントローラ６３１における故障と同様に、ロボットアーム６２２による患者の捕捉をもたらす可能性がある。この可能性に対処するために、ＴＡＣ７００は、バックアップメディエータ４１２と、プロセス４１４のそれ自体の休止状態のコピーとを有するバックアップロボットアームコントローラ４１０とを備えることができる。（主ロボットアームコントローラ６３１及びバックアップロボットアームコントローラ４１０は、モジュール（ＳＯＭ）上の２つの異なるシステム上に実装することができる。副ロボットアームコントローラ４００内のプロセススーパーバイザ４０４は、副ロボットアームコントローラ４００内のプロセス４０６の健全性を監視し、それらが機能しているかどうかを判定する。プロセス４０６が機能している場合、プロセッサスーパーバイザ４０４は、独立型メディエータ４０２に通知し、独立型メディエータ４０２は、バックアップロボットアームコントローラ４１０内のバックアップメディエータ４１２に心拍メッセージを送信する。バックアップメディエータ４１２は、心拍を受信しない場合、故障があることを知り、プロセス４１４のコピーをアクティブ化する。台の配電ボード（ＴＰＤ）７２０（図３参照）は、副ロボットアームコントローラ４００へのパワードメインをオフにするように命令することができる（副ロボットアームコントローラ４００からＴＰＤ７２０への心拍メッセージの欠如が、これを達成することができる）。スイッチ４６０は既にロボットアーム６２２からＴＡＣ７００に情報をルーティングしているため、スイッチ４６０に対する動作は必要なく、情報は副ロボットアームコントローラ４００を介してバックアップロボットアームコントローラ４１０に渡すことができる。追加のバックアップロボットアームコントローラを使用することができる。

【0047】

前述の説明は、説明の目的で、本発明の完全な理解を提供するために特定の用語体系を使用した。しかしながら、本発明を実施するためには、具体的な詳細の多くが必要とされないことは、当業者には明らかであろう。したがって、本発明の具体的な実施形態の前述の説明は、例示及び説明の目的で提示してきたものである。それらは、網羅的であること、及び開示した正確な形態に本発明を制限することを意図するものではない。明確に、上記の教示に照らして、多くの修正及び変形が可能である。実施形態は、本発明の原理及びその実用的な用途を最もよく説明するために選択され、説明された。それによって、他の当業者が、本発明及び様々な実施形態を、企図される特定の使用に適した様々な修正と共に最良に利用することが可能になる。以下の特許請求の範囲及びそれらの等価物が、本発明の範囲を定義することが意図される。

【0048】

上述の方法、デバイス、処理、及び論理は、多くの異なる方法で、並びにハードウェア及びソフトウェアの多くの異なる組み合わせで実装されてもよい。コントローラ及び推定器は、電子回路を備えてもよい。例えば、実装の全部又は一部は、中央処理装置（ＣＰＵ）、マイクロコントローラ、若しくはマイクロプロセッサなどの命令プロセッサを含む回路；特定用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）、若しくはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）；又は、アナログ回路構成要素、デジタル回路構成要素、若しくはその両方を含む、個別論理又は他の回路構成要素を含む回路；又はそれらの任意の組み合わせであってもよい。回路は、例として、個別の相互接続されたハードウェア構成要素を含んでもよく、及び／又は単一の集積回路ダイ上で組み合わされてもよく、複数の集積回路ダイの間で分散されてもよく、又は共通パッケージ内の複数の集積回路ダイのマルチチップモジュール（ＭＣＭ）内に実装されてもよい。

【0049】

回路は、回路による実行のための命令を更に含み得るか、又は命令にアクセスし得る。命令は、フラッシュメモリ、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読取り専用メモリ（ＥＰＲＯＭ）などの、一時的信号以外の有形記憶媒体内、又は、コンパクトディスク読み出し専用メモリ（ＣＤＲＯＭ）、ハードディスクドライブ（ＨＤＤ）、又は他の磁気若しくは光ディスクなどの磁気若しくは光ディスク上、又は、別の機械可読媒体内若しくは上に記憶され得る。コンピュータプログラム製品などの製品は、記憶媒体と、媒体内又は媒体上に記憶された命令とを含むことができ、命令は、デバイス内の回路によって実行されると、デバイスに、上記で説明した、又は図面に示した処理のいずれかを実行させることができる。

【0050】

実装形態は、任意選択で複数の分散処理システムを含む、複数のプロセッサ及びメモリの間など、複数のシステム構成要素の間の回路として分散され得る。パラメータ、データベース、及び他のデータ構造は、別々に記憶及び管理されてもよく、単一のメモリ又はデータベースに組み込まれてもよく、多くの異なる方法で論理的及び物理的に編成されてもよく、リンクされたリスト、ハッシュテーブル、アレイ、レコード、オブジェクト、又は暗黙的記憶機構などのデータ構造を含む多くの異なる方法で実装されてもよい。プログラムは、単一のプログラムの一部（例えば、サブルーチン）、いくつかのメモリ及びプロセッサにわたって分散された別個のプログラムであってもよく、又は共有ライブラリ（例えば、ダイナミックリンクライブラリ（Dynamic Link Library、ＤＬＬ））等のライブラリ等に多くの異なる方法で実装されてもよい。ＤＬＬは、例えば、回路によって実行されるときに、上述された又は図面に示された処理のいずれかを実行する命令を記憶してもよい。

【0051】

また、本明細書で説明される種々のコントローラは、処理回路、マイクロプロセッサ又はプロセッサ、並びに（マイクロ）プロセッサ、論理ゲート、スイッチ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理コントローラ、及び埋め込みマイクロコントローラによって実行可能なコンピュータ可読プログラムコード（例えば、ファームウェア）を記憶するコンピュータ可読媒体の形態をとることができる。コントローラは、以下で説明され、フロー図に示される様々な機能を実行するために、ハードウェア及び／又はファームウェアで構成することができる。また、コントローラの内部にあるものとして示されている構成要素のいくつかは、コントローラの外部に格納されてもよく、他の構成要素が使用されてもよい。

【0052】

〔実施の態様〕
（１） 外科用ロボットであって、
ユーザコンソールと、
前記ユーザコンソールからの第１の入力に応答して前記外科用ロボットを制御するように構成された主コントローラと、
前記ユーザコンソールから遠隔の第２の入力に応答して前記外科用ロボットを制御するように構成された副コントローラと、を備え、
前記副コントローラは、前記主コントローラから通信を受信するように構成されており、
前記外科用ロボットの制御が、前記主コントローラからの通信の失敗に応答して前記主コントローラから前記副コントローラに移行される、外科用ロボット。
（２） 前記主コントローラが第１のメディエータを含み、前記副コントローラが第２のメディエータを含む、実施態様１に記載の外科用ロボット。
（３） 前記主コントローラからの前記通信が、所定のレートで前記第１のメディエータによって送信される心拍メッセージを含む、実施態様２に記載の外科用ロボット。
（４） 前記主コントローラからの通信の前記失敗が、前記第２のメディエータが１つ以上の心拍メッセージを受信できないときに検出される、実施態様３に記載の外科用ロボット。
（５） 前記主コントローラが、前記主コントローラが機能状態にあるかどうかを前記第１のメディエータに通知するように構成されたスーパーバイザプロセスを更に備え、前記第１のメディエータが、前記主コントローラが前記機能状態にあるときのみ、前記心拍メッセージを前記第２のメディエータに送信するように構成されている、実施態様３に記載の外科用ロボット。

【0053】

（６） 前記主コントローラが、前記外科用ロボットを制御するための第１の複数のプロセスを備え、前記副コントローラが、前記第１の複数のプロセスの休止状態にされたコピーを備える、実施態様１に記載の外科用ロボット。
（７） 前記外科用ロボットの前記制御を前記副コントローラに移行することが、前記外科用ロボットを制御するための前記第１の複数のプロセスの前記休止状態にされたコピーをアクティブ化することを含む、実施態様６に記載の外科用ロボット。
（８） 前記主コントローラが、前記外科用ロボットを制御するとき、前記外科用ロボットから状態情報を受信するように更に構成されている、実施態様１に記載の外科用ロボット。
（９） 前記外科用ロボットの前記制御を前記副コントローラに移行することが、前記状態情報を前記外科用ロボットから前記副コントローラにルーティングすることを含む、実施態様８に記載の外科用ロボット。
（１０） 前記副コントローラが前記外科用ロボットを制御しているとき、前記副コントローラから所定のレートで心拍メッセージを受信するように構成されたバックアップコントローラを更に備え、
前記外科用ロボットの前記制御が、１つ以上の心拍メッセージの欠落に応答して、前記副コントローラから前記バックアップコントローラに移行される、実施態様１に記載の外科用ロボット。

【0054】

（１１） 前記副コントローラが、前記外科用ロボットを制御するための第２の複数のプロセスを含み、
前記バックアップコントローラが、前記第２の複数のプロセスの休止状態にされたコピーを含み、
前記外科用ロボットの前記制御を前記バックアップコントローラに移行することが、前記外科用ロボットを制御するための前記第２の複数のプロセスの前記休止状態にされたコピーをアクティブ化することを含む、実施態様１０に記載の外科用ロボット。
（１２） 前記副コントローラが、前記外科用ロボットを制御するとき、前記外科用ロボットから状態情報を受信するように構成されており、前記外科用ロボットの前記制御を前記バックアップコントローラに移行することが、前記外科用ロボットから前記バックアップコントローラに前記状態情報をルーティングすることを含む、実施態様１０に記載の外科用ロボット。
（１３） 前記バックアップコントローラが、前記副コントローラへの電力をオフにするように配電構成要素に命令するように更に構成されている、実施態様１０に記載の外科用ロボット。
（１４） ロボット方法であって、
第１の入力デバイスからの入力に基づいて主ロボットコントローラによって外科用ロボットの動きを制御することと、
前記主ロボットコントローラが前記外科用ロボットを制御している間、副ロボットコントローラによって前記主ロボットコントローラから心拍メッセージを受信することと、
１つ以上の心拍メッセージの受信に失敗したことに応答して、前記外科用ロボットの制御を前記副ロボットコントローラに移行することと、
前記第１の入力デバイスとは異なる第２の入力デバイスからの入力に基づいて、前記副ロボットコントローラによって前記外科用ロボットの動きを制御することと、を含む、ロボット方法。
（１５） 前記主ロボットコントローラからの前記心拍メッセージの受信に失敗することが、前記主ロボットコントローラにおける電源の故障、ハードウェアの故障、ソフトウェアの故障、及び通信の故障のうちの少なくとも１つによって引き起こされる、実施態様１４に記載のロボット方法。

【0055】

（１６） 前記外科用ロボットの制御を移行することが、前記副ロボットコントローラ内のプロセスを休止状態から解除することを含み、前記副ロボットコントローラ内の前記プロセスが、前記外科用ロボットを制御するための前記主ロボットコントローラ内のプロセスのコピーである、実施態様１４に記載のロボット方法。
（１７） 前記外科用ロボットの制御を移行することが、前記外科用ロボットからの通信を前記主ロボットコントローラではなく前記副ロボットコントローラにルーティングすることを含む、実施態様１４に記載のロボット方法。
（１８） 前記副ロボットコントローラが前記外科用ロボットの動きを制御することができないという判定に応答して、前記外科用ロボットの制御を、前記副入力デバイスに結合されたバックアップロボットコントローラに移行することを更に含む、実施態様１４に記載のロボット方法。
（１９） 前記外科用ロボットの制御をバックアップロボットコントローラに移行することが、前記バックアップロボットコントローラ内のプロセスを休止状態から解除することと、前記外科用ロボットからの前記通信を前記副ロボットコントローラの代わりに前記バックアップコントローラにルーティングすることとを含む、実施態様１８に記載のロボット方法。
（２０） 外科用ロボットシステムであって、
手術台に取り付けられた１つ以上のロボットアームと、
前記手術台の遠隔にある第１のユーザインターフェースデバイスを含むユーザコンソールと、
前記ユーザコンソールにおいて前記第１のユーザインターフェースデバイスから受信された入力に応答して前記１つ以上のロボットアームを制御するように構成された主コントローラと、
前記主コントローラの故障に応答して、前記主コントローラから前記手術台内に位置付けられた副コントローラに前記１つ以上のロボットアームの制御を移行するための手段であって、前記副コントローラが、前記１つ以上のロボットアーム及び前記副コントローラに結合された第２のユーザインターフェースデバイスから受信された入力に応答して前記１つ以上のロボットアームを操縦するように構成されている、手段と、を備える、外科用ロボットシステム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】