(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-04
(45)【発行日】2024-10-15
(54)【発明の名称】起動及びシャットダウン中の医療デバイスの動作
(51)【国際特許分類】
G16H 40/60 20180101AFI20241007BHJP
A61M 1/16 20060101ALI20241007BHJP
【ＦＩ】
G16H40/60
A61M1/16 110
【請求項の数】
21
(21)【出願番号】P 2021512396
(86)(22)【出願日】2019-10-10
(65)【公表番号】
(43)【公表日】2022-01-11
(86)【国際出願番号】 EP2019077428
(87)【国際公開番号】W WO2020074618
(87)【国際公開日】2020-04-16
【審査請求日】2022-09-14
(31)【優先権主張番号】18199665.3
(32)【優先日】2018-10-10
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】501473877
【氏名又は名称】ガンブロ・ルンディア・エービー
【氏名又は名称原語表記】ＧＡＭＢＲＯ ＬＵＮＤＩＡ ＡＢ
(74)【代理人】
【識別番号】110003281
【氏名又は名称】弁理士法人大塚国際特許事務所
(72)【発明者】
【氏名】ヨハネソン， カミラ
(72)【発明者】
【氏名】リンドハルト， ミカエル
(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】
医療処置を実行するための医療デバイスであって、一組のプロセッサと、
前記一組のプロセッサによって実行されるソフトウェアシステムを格納する一組のメモリユニットと、を備え、
前記ソフトウェアシステムは、前記一組のプロセッサによって実行されるときに、前記医療デバイスを動作させて前記医療処置を実行し、
前記ソフトウェアシステムは、プライマリサブシステム及び一組のセカンダリサブシステムを含む複数のサブシステムを定義し、各サブシステムは、前記医療処置中に前記医療デバイスの前記動作に関与するソフトウェアアプリケーションを含み、
前記ソフトウェアシステムは、前記一組のプロセッサによって実行されるときに、請求項１～１９のいずれか１項に記載の前記方法を実行する、医療デバイス。
【請求項21】
医療処置を実行するために医療デバイスを動作させるためのソフトウェアシステムを含むコンピュータ読取可能な記憶媒体であって、前記ソフトウェアシステムは、プライマリサブシステム及び一組のセカンダリサブシステムを含む複数のサブシステムを定義し、各サブシステムは、前記医療処置中に前記医療デバイスの前記動作に関与するソフトウェアアプリケーションを含み、前記ソフトウェアシステムは、前記医療デバイスの一組のプロセッサによって実行されると、請求項１～１９のいずれか１項に記載の方法を実行する、コンピュータ読取可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、医療デバイスの分野、より具体的には、起動およびシャットダウン中に自動医療デバイスを動作させるための技術に関する。
【背景技術】
【0002】
自動医療デバイスは、単体で使用されるにしても組み合わせて使用されるにしても、製造業者が医療目的のためにヒトまたは動物に使用することを意図した機械である。このような目的は、疾患、損傷、又はハンディキャップの診断、予防、モニタリング、処理又は緩和を含み得る。
【0003】
自動医療デバイスは、ヘルスケア分野で頻繁に使用され、安全かつ効率的であることを保証するために厳格な規制の枠組みの対象になる。
【0004】
一般に、自動医療デバイスは、健康に影響を及ぼす可能性がある誤動作のリスクを軽減すべく慎重に設計される必要がある複雑なシステムであるソフトウェアシステムによって動作される。
【0005】
２つ以上の独立したサブシステムまたはモジュールから構成されるようにソフトウェアシステムを設計することが望ましい場合がある。一連の独立したサブシステムを構築することにより、医療デバイスの製品設計者および製造者は完全な医療デバイスの機能のサブセットである特定の機能を実行するサブシステムを作成し、配備する能力を得ることができる。ソフトウェアのこのようなモジュール化は、例えば１つ以上の集積回路またはチップ上に配置された異なるプロセッサ上で実行される異なるサブシステムによって、ハードウェアのモジュール化と対にされてもよい。
【0006】
医療目的を実行しながら、医療デバイスが制御され、安全で、信頼性のある方法で動作することを保証するために、ソフトウェアシステムを設計するのに多くの努力が一般に払われるが、医療デバイスの起動及びシャットダウンは個々のプロセスのための公称起動時間を推定し、対応するタイマを使用することによって、しばしば無視され、実行される。これは、何らかの理由で、プロセスの起動を公称起動時間を超えて遅延させなければならない場合、長い起動時間及び誤動作の傾向を招くことがある。起動又はシャットダウン中に発生する誤動作は、ソフトウェアシステムに組み込まれた安全対策にかかわらず、医療デバイスによって実行されるその後の医療処置に深刻な影響を及ぼす可能性がある。起動及びシャットダウンは、２つ以上のサブシステムにモジュール化されたソフトウェアシステムにおいて、誤動作に対して特に脆弱であり得る。
【0007】
医療デバイスの確定的で、安全で、信頼性のある起動及びシャットダウンを保証する医療デバイスのためのソフトウェアシステムを提供することが一般的に必要とされている。
【0008】
従来技術は、Ｓｔａｎｃｚｙｋらによる論文「Ｌｏｇｉｃａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ ｏｆ Ｍｅｄｉｃａｌ Ｔｅｌｅｄｉａｇｎｏｓｔｉｃ Ｒｏｂｏｔｉｃ Ｓｙｓｔｅｍ」（第２１回自動化およびロボット工学における方法およびモデルに関する国際会議（ＭＭＡＲ）、２００～２０５頁（２０１６年））を含む。その論文は、リモート身体検査を可能にする多機能ロボットシステムを提示した。患者側制御システムはロボット集中制御システム（ＲＣＣＳ）を備え、これはロボット頭部、例えばロボットアームおよび移動ロボットベースのための下位制御装置等の下位コンポーネントにそれぞれ接続される。センサ信号、アシスタント又は医師の論理的要求、およびすべての下位のコンポーネントからの状態信号に基づいて、ＲＣＣＳは、下位のコンポーネントを動作させることができるかどうかを決定する。すべての通信はＲＣＣＳを介して行われる。電源オンが有効化されると、ＲＣＣＳは起動状態になり、起動手順を開始する。すべての下位コンポーネントがアクティブであると認識されると、ＲＣＣＳはアクティブ状態になる。逆に、電源オフボタンが押されると、ＲＣＣＳはシャットダウン状態になり、シャットダウン手順を開始する。すべての下位コンポーネントがシャットダウン手順を終了すると、ＲＣＣＳはオフ状態になる。
【0009】
このような従来技術の制御システムはロボットシステムのハードウェアコンポーネントの安全かつ信頼性のある高レベルでの起動を可能にすることができるが、制御システムのすべてのプロセスの確定的な起動を保証するわけではない。
【0010】
従来技術はまた、米国特許出願公開第２０１４／０１２１５０９号明細書を含み、これは、マルチモダリティ医療処理システムにおける依存性ベースの起動方法を開示する。システムコントローラは、処理システムに結合されたそれぞれの医療デバイスと通信するためのモダリティ固有のコンポーネントである複数の実行可能コンポーネントの起動およびシャットダウンを調整するように構成される。実行可能コンポーネントごとに、システムコントローラは、実行可能コンポーネントが依存する他の実行可能コンポーネントのリストを含む依存関係情報を取得する。システムコントローラは依存関係情報に基づいて複数の実行可能コンポーネントの開始順序を動的に導出し、開始順序に従って実行可能コンポーネントを開始する。システムコントローラはそれぞれのコンポーネントがそのすべてのインタフェースをパブリッシュし、オプションでプロセスレディメッセージをブロードキャストするまで待機してから、開始順序で次のコンポーネントを開始する。
【0011】
この起動方法では、実行可能コンポーネントのレベルでの起動のみが考慮される。これによって、システム内のすべてのプロセス、例えば、１つまたは複数の実行可能コンポーネント内のソフトウェアアプリケーションによって実行されるプロセスの確定的起動を保証しない。さらに、提案された起動方法は、依存性情報の交換と、システムコントローラによる起動順序の集中決定とを必要とする点で複雑である。
【発明の概要】
【0012】
本発明の目的は、従来技術の１つ以上の制限を少なくとも部分的に克服することである。
【0013】
さらなる目的は、医療デバイスを動作させるためのソフトウェアシステムのすべての関連するプロセスの確定的起動を可能にすることである。
【0014】
別の目的は、医療デバイスを動作させるためのソフトウェアシステムの全ての関連するプロセスの確定的シャットダウンを可能にすることである。
【0015】
これらの目的のうちの１つまたは複数、ならびに以下の説明から明らかになり得るさらなる目的は、医療デバイスを動作させる方法、医療デバイス、およびコンピュータ可読媒体少なくとも部分的に達成され、それら実施形態は従属請求項によって定義される。
【0016】
本発明の第１の態様は、医療デバイスを動作させる方法である。医療デバイスは、医療処置を実行するように構成され、一組のプロセッサと、一組のプロセッサによる実行のためのソフトウェアシステムを記憶する一組のメモリユニットとを備える。ソフトウェアシステムは、プライマリサブシステムおよび一組のセカンダリサブシステムを含む複数のサブシステムを規定する。各サブシステムは、医療処置中の医療デバイスの操作に関与するソフトウェアアプリケーションを含む。この方法は、医療デバイスの起動時に、各ソフトウェアアプリケーションを開始することと、起動の準備ができたときに、各セカンダリサブシステム内の各ソフトウェアアプリケーションによって、アプリケーション準備完了通知を提供することと、すべてのソフトウェアアプリケーションがアプリケーション準備完了通知を提供したときに、各セカンダリサブシステムによって、サブシステム準備完了通知を提供することと、サブシステム準備完了通知を受信したことに基づいて、プライマリサブシステムによって、一組のセカンダリサブシステムの起動を調整することと、を含む。
【0017】
本発明の第２の態様は、医療処置を実行するための医療デバイスである。医療デバイスは、一組のプロセッサと、一組のプロセッサによる実行のためのソフトウェアシステムを記憶する一組のメモリユニットとで構成される。ソフトウェアシステムは、一組のプロセッサによって実行されると、医療デバイスを動作させて医療処置を実行する。ソフトウェアシステムは、プライマリサブシステムおよび一組のセカンダリサブシステムを含む複数のサブシステムを規定する。各サブシステムは、医療処置中の医療デバイスの操作に関与するソフトウェアアプリケーションを含む。ソフトウェアシステムは、プロセッサの設定によって実行されると、第１の態様またはその実施形態のいずれかによる方法を実行する。
【0018】
第３の態様は、医療処置を実行するために医療デバイスを動作させるためのソフトウェアシステムを備えるコンピュータ読取可能な記憶媒体である。ソフトウェアシステムは、プライマリサブシステムおよび一組のセカンダリサブシステムを含む複数のサブシステムを規定する。各サブシステムは、医療処置中の医療デバイスの動作に関与するソフトウェアアプリケーションを含む。ソフトウェアシステムは、医療デバイスの一組のプロセッサによって実行されると、第１の態様またはその実施形態のいずれかに従って方法を実行する。
【0019】
これらの態様は、医療デバイスにおけるソフトウェアシステムのすべての関連ソフトウェアアプリケーションの確定的起動を可能にする。確定的起動は、起動プロシージャを、アプリケーション準備完了及びサブシステム準備完了通知を使用することによるサブシステムレベルでの起動の準備と、プライマリサブシステムが個々のサブシステムの起動を調整するシステムレベルでの起動の準備と、に分離することによって可能になる。さらに、前述の態様は、ソフトウェアアプリケーションがそれぞれのサブシステムに委任される起動の準備ができていることを保証する責任を可能にする。これにより、ソフトウェアシステムに対応して起動手順をモジュール化することができるので、各サブシステムは、他のサブシステムとは独立して起動に備えるように動作可能である。そのようなモジュール化は起動手順がサブシステム上で別々に実施されることを可能にし、サブシステムの起動は、開発および展開中に別々に試験され得るという点で有利である。
【0020】
さらに、通知の使用は、医療デバイスの安全かつ信頼性のある起動を可能にする。例えば、通知の提供を妨げる誤動作が発生した場合に、ソフトウェアシステムが起動されることを防止することができる。通知の使用はまた、医療デバイスの起動中のソフトウェアシステムにおける誤動作の単純かつ効率的な検出および位置特定を可能にする。さらに、上述のようなタイマの使用および公称起動時間と比較して、通知の使用はまた、医療デバイスの起動に必要とされる時間を短縮し得る。
【0021】
対応するモジュール化は確定的で、安全で、信頼できる方法で、電源喪失のために医療デバイス内のすべての関連する実行ソフトウェアアプリケーションを準備するために、通知を使用することによって、シャットダウン手順で実施されてもよい。
【0022】
第１の態様のいくつかの実施形態は、以下で定義され、医療デバイスを動作させるためのソフトウェアシステムのすべての関連するプロセスの確定的起動および／またはシャットダウンを可能にする、達成する、または改善する目的、あるいは当業者によって理解されるような別の目的を果たすことができる。
【0023】
一実施形態では、本方法がそれぞれのサブシステムにおいて、サブシステム準備完了通知を取得することに基づいて、それぞれのセカンダリサブシステムのソフトウェアアプリケーションによって、それぞれのセカンダリサブシステムのソフトウェアアプリケーション間の通信を可能にすることをさらに含む。
【0024】
一実施形態では、調整することは、プライマリサブシステムによって、一組のセカンダリサブシステムによる受信のためのシステム準備完了通知を生成することを含む。
【0025】
一実施形態では、調整することは、システム準備完了通知を取得したことに基づいて、それぞれのセカンダリサブシステムによって、複数のサブシステム間の異なるサブシステムのソフトウェアアプリケーションの少なくともサブセット間の通信を可能にすることをさらに含み、それによって、医療デバイスは医療処置の少なくとも一部を実行する準備が整う。
【0026】
一実施形態では、本方法がさらに、起動の準備ができたときに、プライマリサブシステム内のそれぞれのソフトウェアアプリケーションによって、アプリケーション準備完了通知を提供することを含み、ここで、調整することは、それぞれのセカンダリサブシステムからのサブシステム準備完了通知と、プライマリサブシステム内のそれぞれのソフトウェアアプリケーションからのアプリケーション準備完了通知とを受信したことに基づいてプライマリサブシステムによって実行される。
【0027】
一実施形態では、プライマリサブシステム内のマネージャは、それぞれのセカンダリサブシステムからのサブシステム準備完了通知と、プライマリサブシステム内のそれぞれのソフトウェアアプリケーションからのアプリケーション準備完了通知とを受信し、調整することを実行する。
【0028】
一実施形態ではそれぞれのセカンダリサブシステムがマネージャをさらに含み、それぞれのセカンダリサブシステムのマネージャは、そのソフトウェアアプリケーションのすべてからアプリケーション準備完了通知を取得したことに基づいて、サブシステム準備完了通知を提供する。
【0029】
一実施形態では、調整することは、プライマリサブシステムのソフトウェアアプリケーションのそれぞれからアプリケーション準備完了通知を、それぞれのセカンダリサブシステムからサブシステム準備完了通知を、取得したことに基づいて、プライマリサブシステムのマネージャによって、それぞれのセカンダリサブシステムのシステム準備完了通知を提供することを含む。
【0030】
一実施形態では、本方法は、システム準備完了通知を取得したことに基づいてそれぞれのセカンダリサブシステムのマネージャによって、および、プライマリサブシステムのマネージャによって、複数のサブシステム間の異なるサブシステムのソフトウェアアプリケーションの少なくともサブセット間の通信を可能にすることをさらに含み、それによって、医療デバイスは医療処置の少なくとも一部を実行する準備が整う。
【0031】
一実施形態では、ソフトウェアシステムが少なくとも２つのセカンダリサブシステムを定義し、異なるサブシステムのソフトウェアアプリケーションの少なくともサブセット間の通信を可能にすることは、少なくとも２つのセカンダリサブシステムのソフトウェアアプリケーションの少なくともサブセット間の直接通信を可能にすることを含む。
【0032】
一実施形態では、サブシステムが一組のプロセッサ内の別々のプロセッサ上で実行される。
【0033】
一実施形態では、２つ以上のサブシステムは、医療デバイスによって実行される医療処置にとっては重要であり、それぞれのマネージャを備え、方法は上記起動中に外部心拍信号を送信するために上記２つ以上のサブシステムのマネージャのそれぞれを動作させることと、動作不良の検出のために、上記２つ以上のサブシステムのマネージャの間で相互に外部心拍信号をモニタし始めることとをさらに含む。
【0034】
一実施形態では、本方法はさらに、上記起動中に、プライマリサブシステムのマネージャによって、第１の所定の時間内にプライマリサブシステムの各ソフトウェアアプリケーションからアプリケーション準備完了通知を受信しなかったときに第１のエラーを報告することと、プライマリサブシステムのマネージャによって、第２の所定の時間内にサブシステム準備完了通知を各セカンダリサブシステムから受信しなかったときに、第２のエラーを報告することと、を含む。
【0035】
一実施形態では、本方法は、医療デバイスのシャットダウン中に、プライマリサブシステムのマネージャによって、一組のセカンダリサブシステムに対するシャットダウン通知を提供することと、プライマリサブシステムのマネージャによって、プライマリサブシステムのソフトウェアアプリケーションの終了を要求することと、シャットダウン通知を取得した後に、それぞれのセカンダリサブシステムのマネージャによって、それぞれのセカンダリサブシステムのソフトウェアアプリケーションの終了を要求することとを含む。
【0036】
一実施形態では、それぞれのセカンダリサブシステムのソフトウェアアプリケーションの終了を要求することは、少なくとも１つのセカンダリサブシステムについて、マネージャによって、セカンダリサブシステムのソフトウェアアプリケーションのためのサブシステム準備未完了通知を提供することと、セカンダリサブシステムのソフトウェアアプリケーションの少なくとも１つのサブセットによって、サブシステム準備未完了通知を取得したことに基づいて、終了の準備をすることと、終了のために準備されたときにソフトウェアアプリケーションの上記少なくとも１つのサブセットによって、アプリケーションのシャットダウン準備完了通知を提供することと、セカンダリサブシステムのマネージャによって、ソフトウェアアプリケーションの上記少なくとも１つのサブセットからアプリケーションのシャットダウン準備完了通知を取得したことに基づいて、プライマリサブシステムのマネージャのためのサブシステムのシャットダウン準備完了通知を提供することとを含む。
【0037】
一実施形態では、プライマリサブシステムのソフトウェアアプリケーションの終了を要求することは、プライマリサブシステムのマネージャによって、プライマリサブシステムのソフトウェアアプリケーションに対するサブシステム準備未完了通知を提供することと、サブシステム準備未完了通知を取得したことに基づいて、プライマリサブシステムのソフトウェアアプリケーションの少なくともサブセットによって、終了の準備をすることと、終了の準備をしたときに、プライマリサブシステムのソフトウェアアプリケーションの少なくともサブセットによって、アプリケーションのシャットダウン準備完了通知を提供することとを含む。
【0038】
一実施形態では、本方法は、上記少なくとも１つのセカンダリサブシステムからのサブシステムのシャットダウン準備完了通知と、プライマリサブシステムのソフトウェアアプリケーションの上記少なくとも１つのサブセットからのアプリケーションのシャットダウン準備完了通知を取得したことに基づいて、プライマリサブシステムのマネージャによって、医療デバイスの電源喪失を開始することをさらに含む。
【0039】
一実施形態では、本方法は、上記シャットダウン中にエラーが無い場合にマネージャのうちの少なくとも１つによって、通常のシャットダウンを示すシャットダウン理由パラメータを設定して一組のメモリユニットにシャットダウン理由パラメータを格納することと、上記起動中にマネージャのうちの上記少なくとも１つによって、シャットダウンエラーを示すシャットダウン理由パラメータを設定して一組のメモリユニットにシャットダウン理由パラメータを格納することと、を含む。
【0040】
一実施形態ではソフトウェアアプリケーションは、医療デバイスによって実行される医療処置にクリティカルな１つ以上のクリティカルソフトウェアアプリケーションを備え、方法はさらに、医療デバイスのシャットダウン中であって一組のセカンダリサブシステムに対するシャットダウン通知を提供する前に、プライマリサブシステムのマネージャによって、１つ以上のクリティカルソフトウェアアプリケーションのシャットダウン要求を提供することと、１つ以上のクリティカルソフトウェアアプリケーションによって、前記医療デバイスの前記動作を考慮して前記シャットダウン要求を検証することと、１つ以上のクリティカルソフトウェアアプリケーションのうちの少なくとも１つによって、およびシャットダウンが受け入れ可能である場合に、アプリケーションのシャットダウン準備完了通知を提供することと、を含み、プライマリサブシステムのマネージャは、上記１つ以上のクリティカルソフトウェアアプリケーションの少なくとも１つからアプリケーションのシャットダウン準備完了通知を取得したことに基づいて、一組のセカンダリサブシステムに対してシャットダウン通知を提供すること、をさらに含む。
【0041】
一実施形態では複数のサブシステムは、医療処置を実行するために医療デバイスを制御するためのソフトウェアアプリケーションを有する第１のサブシステムと、医療デバイスのアクチュエータおよび／またはセンサと通信するためのソフトウェアアプリケーションを有する第２のサブシステムとを備え、調整することは、医療デバイスを制御するためのソフトウェアアプリケーション及び通信するためのソフトウェアアプリケーションとの間の通信を可能にする。
【0042】
一実施形態では複数のサブシステムはさらに、偏差を検出するための医療処置を監視するためのソフトウェアアプリケーションを有する第３のサブシステムと、医療デバイスの補助センサと通信するためのソフトウェアアプリケーションを有する第４のサブシステムと、を備え、調整することはさらに、医療処置を監視するためのソフトウェアアプリケーションと補助センサと通信するためのソフトウェアアプリケーションとの間、及び、医療デバイスを制御するためのソフトウェアアプリケーションと医療処置を監視するためのソフトウェアアプリケーションとの間の通信を可能にする。
【0043】
本発明のさらなる態様は、医療デバイスを操作する方法である。医療デバイスは、医療処置を実行するように構成され、プロセッサの設定と、プロセッサの設定による実行のためのソフトウェアシステムを記憶するメモリユニットの設定とを備える。ソフトウェアシステムは、プライマリサブシステムおよび一組のセカンダリサブシステムを含む複数のサブシステムを規定する。各サブシステムは、医療処置中の医療デバイスの動作に関与するソフトウェアアプリケーションを含む。この方法は医療デバイスの起動中に、各ソフトウェアアプリケーションを開始することと、起動の準備ができたときに各ソフトウェアアプリケーションによってアプリケーション準備完了通知を提供することと、すべてのソフトウェアアプリケーションがアプリケーション準備完了通知を提供したときに各サブシステムによってサブシステム準備完了通知を提供することと、サブシステム準備完了通知を受信したことに基づいて、プライマリサブシステムによってサブシステムの起動を調整することとを含む。この方法は、第２の態様に対応する医療デバイス上に展開され、第３の態様に対応するコンピュータ読取可能な記憶媒体上に実装され得る。前述の実施形態は、さらなる態様の方法に等しく適用可能である。
【0044】
本発明のさらに他の目的および態様、ならびに実施形態、特徴、技術的効果、および利点は、以下の詳細な説明、添付の特許請求の範囲、ならびに図面から明らかになるのであろう。
【図面の簡単な説明】
【0045】
以下、本発明の実施の形態について、添付図面を参照してより詳細に説明する。
【発明を実施するための形態】
【0046】
ここで、本発明のいくつかの、しかし全てではない実施形態が示されている添付の図面を参照して、本発明の実施形態を以下により完全に説明する。実際、本発明の解決策は多くの異なる形態で具現化することができ、本明細書に記載の実施形態に限定されるものと解釈すべきではなく、むしろ、これらの実施形態は、本開示が適用可能な法的要件を満たすことができるように提供される。同じ参照符号は全体を通して同じ要素を指す。
【0047】
また、可能であれば、本明細書に記載および／または企図される本発明の実施形態のいずれかの利点、特徴、機能、デバイス、および／または動作態様のいずれかが、本明細書に記載および／または企図される本発明の他の実施形態のいずれかに含まれてもよく、および／またはその逆であってもよいことが理解されるのであろう。さらに、可能であれば、本明細書で単数形で表される任意の用語は特に明記しない限り、複数形も含むこと、および／またはその逆も意味する。本明細書で使用される場合、「少なくとも１つの」は「１つ以上の」を意味し、これらの語句は交換可能であることが意図される。したがって、「１つの」および／または「１つの」または「１つ以上の」という語句は本明細書で使用される場合でも、本明細書で使用される場合、コンテキストが言語または必要な含意を表すために、そわないことを必要とする場合を除いて、「備える」または「備える」などの語句は包括的な意味で使用され、すなわち、記載された特徴の存在を指定するが、本発明の様々な実施形態におけるさらなる特徴の存在または追加を排除しない。本明細書で使用される場合、項目の「セット」は１つ以上の項目の提供を暗示することが意図される。
【0048】
さらに、第１、第２などの用語は様々な要素を説明するために本明細書で使用され得るが、これらの要素はこれらの用語によって限定されるべきではないことが理解されるのであろう。これらの用語は、１つの要素を別の要素から区別するためにのみ使用される。例えば、本発明の範囲を逸脱することなく、第１の要素を第２の要素と呼ぶことができ、同様に、第２の要素を第１の要素と呼ぶことができる。本明細書で使用されるように、用語「および／または」は、関連する列挙された項目のうちの１つまたは複数の任意の組合せおよびすべての組合せを含む。
【0049】
周知の機能または構成は、簡潔さおよび／または明確さのために詳細に説明されないことがある。別段の定義がない限り、本明細書で使用されるすべての用語（技術用語および科学用語を含む）は、本発明が属する技術分野の当業者によって一般に理解されるものと同じ意味を有する。
【0050】
本発明の実施形態は、医療デバイスを動作させるための医療ソフトウェアシステムの全ての関連するプロセスの確定的起動及び／又はシャットダウンを可能にする技術を対象とする。医療デバイスは、任意選択で１つまたは複数の他の医療デバイスと組み合わせて、人間または動物の被験者に関連して医療処置を実行するように構成された自動化された装置または機械である。ここで使用される場合、医療処置は、疾患、損傷、またはハンディキャップの診断、予防、モニタリング、処理もしくは緩和、またはそれらの検出のためのモニタリングのうちの１つ以上に関係する。以下では、医療ソフトウェアシステムが医療処置を実行するように医療デバイスを制御するために１つまたは複数のプロセッサ上で実行される２つまたは複数のサブシステムを備えることを前提とする。サブシステムは、医療処置を実行するときに医療デバイスの操作に関連して特定の機能を提供するために独立して開発され、試験され得るコンピュータ実行可能な命令のソフトウェアモジュールとして見られ得る。各サブシステムは一組のソフトウェアアプリケーションを含み、各ソフトウェアアプリケーションは、それぞれのサブシステムのコンテキスト内で実行されるプロセスまたはタスクに対応する。したがって、サブシステム内のソフトウェアアプリケーションはサブシステムの特定の機能を提供するために、調整されたプロセスのグループを実行するように設計されてもよい。しかしながら、サブシステムは、医療デバイスの操作に関与しない１つ以上のソフトウェアアプリケーションを含むことが考えられる。さらに、サブシステムは、他のサブシステムとの通信を管理するための通信スタック、技術的エラーを管理するためのエラーマネージャ、通知を管理するための通知マネージャなど、ソフトウェアシステムにおける基本機能またはサービスを実行するミドルウェアおよび／または低レベルソフトウェアコンポーネントなどの、さらなるソフトウェアコンポーネントを含んでもよい。サブシステムのうちの１つまたは複数はハードウェアおよびソフトウェア資源に関連してオペレーティングシステムによって提供されるサービスを利用するために、１つまたは複数のオペレーティングシステムの上で動作させることができる。実装に応じて、オペレーティングシステムは例えば、リアルタイムオペレーティングシステム、組み込みオペレーティングシステム、シングルタスクオペレーティングシステム、またはマルチタスクオペレーティングシステム、あるいはそれらの任意の組合せを含むことができる。また、１つ以上のサブシステムがオペレーティングシステムなしで動作し、医療デバイスのハードウェア資源を直接インタフェースするように構成されていることも考えられる。
【0051】
図１Ａ～１Ｃは、被写体と流体連通して直接的または間接的に接続される医療デバイスの例の模式図である。図示された例は極めて模式的であり、本発明の実施形態のための異なる実施状況を例示することのみを目的として与えられていることに留意されたい。
【0052】
図１Ａは、矢印によって示されるように、制御された方法で、例えば、被写体１００の循環系中に、被写体１００の身体中に医療用流体を送達するように操作可能な医療デバイス１０を図示する。医療用流体は医薬および／または栄養物を含むが、これらに限定されない、任意の適切な液体であってもよい。このタイプの医療デバイス１０は、一般的に「注入ポンプ」として知られている。図示の簡略化された例では、医療デバイス１０が被験者１００に接続するための流体ライン１１と、ディスプレイ１２と、制御ボタン１３（１つが示されている）と、インジケータランプ１４と、スピーカ１５と、制御システム１６と、流体ライン１１を介して被験者１００に医療用流体を制御送達するための１つまたは複数のアクチュエータ１７と、注入ポンプによって実行される注入プロセスを示すセンサデータを提供するための１つまたは複数のセンサ１８とを備える。アクチュエータ１７およびセンサ１８は、医療デバイス１０の内部コンポーネント（点線で示す）または外部コンポーネント、あるいはその両方を含むことができる。制御システム１６は注入ポンプの意図された医療処置を実行するためにアクチュエータ１７およびセンサ１８の操作を調整し、医療処置に関連して必要に応じてディスプレイ１２、インジケータランプ１４、およびスピーカ１５を操作させ、制御ボタン１３を介してユーザ入力を取得するように構成される。例えば、ディスプレイ１２は医療デバイス１０のユーザに命令を提示するように操作されてもよく、インジケータランプ１４はデバイス状態を示すように操作されてもよく、スピーカ１５は警告信号などを発生するように操作されてもよい。
【0053】
図１Ｂは制御された方式で、対象者１００の腹腔に透析流体を送り、続いて、両矢印によって示されるように、そこから透析流体を除去するように動作可能である医療デバイス１０を図示する。この医療処置は一般的に自動化腹膜透析として知られており、医療デバイス１０はしばしば「ＰＤサイクラー」と表記される。図１Ｂの医療デバイス１０は図１Ａの医療デバイス１０と同様のコンポーネントのセットを、図示された詳細度で有することができ、さらなる説明は行わない。
【0054】
図１Ｃは例えば、血液透析、血液透析濾過、血液濾過または限外濾過のような腎代替療法の一部として、体外血液処理を行う医療処置に関与し得る２つの医療デバイス１０、１０’を図示する。１０で示される医療デバイスは血液処理装置であり、これは、例えば、血管アクセスにおいて、対象者１００の循環系に接続するための血液抜き取りライン１１Ａおよび血液戻りライン１１Ｂを備える。矢印で示すように、医療デバイス１０は対象者１００から血液を抜き取り、血液を処理し、処理された血液を制御された方法で対象者１００に戻すように動作可能である。１０’で示される医療デバイスは血液処理装置１０によって使用される流体を準備するように動作可能であり、流体を血液処理装置１０に供給するための流体ライン１１を備える。一例では、医療デバイス１０’は水調製装置であり、流体は精製水である。例えば、水処理装置１０’は当技術分野で知られているように、逆浸透によって入ってくる水を濾過することができる。図１Ｃの医療デバイス１０、１０’の各々は図１Ａの医療デバイス１０と同様の組のコンポーネントを、図示された詳細度で有することができ、さらなる説明しは行わない。
【0055】
図２は例えば、図１Ａ～１Ｃに示されるような医療デバイスの操作中にアクティブであり得るハードウェアコンポーネントの例、およびそのようなハードウェアコンポーネントの相互接続を示す。図示の例では、ハードウェアコンポーネントが任意の形態のバス構造またはスイッチファブリック構造および／または個別配線を含み得る信号通信構造２０をに渡る信号交換のために接続される。１つ以上のコンポーネントが、例えば集積回路（ＩＣ）等の共通基板上に位置され、共通基板上の信号導電トラックによって相互接続され、信号通信構造２０によって順次他のコンポーネントに接続されることもまた、考えられる。図２の例では、医療デバイスがディスプレイ１２、制御ボタン１３、インジケータランプ１４、スピーカ１５、アクチュエータ１７およびセンサ１８に加えて、４つの別個のプロセッサＰ１～Ｐ４、２つの別個のメモリユニットＭ１～Ｍ２を備えている。プロセッサＰ１～Ｐ４およびメモリユニットＭ１～Ｍ２はそれらが別個に動作可能なユニットであるという意味で「別個」であるが、一方でそれらは共通の基板上、例えばＩＣ内に任意の組合せで位置してもよいし、しなくてもよい。それぞれのプロセッサＰ１～Ｐ４は、ＣＰＵ、ＤＳＰ、マイクロプロセッサー、ＦＰＧＡ、ＡＳＩＣ、または任意の他の電子プログラマブルロジックデバイス、またはそれらの組合せなど、任意の商業上利用可能な処理デバイスであってもよい。各メモリユニットＭ１～Ｍ２は、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、リムーバブルメモリ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、キャッシュメモリ、ハードドライブ、記憶媒体などを含むがこれらに限定されない、不揮発性メモリ又は揮発性メモリ、又はそれらの組み合わせを含むことができる。
【0056】
図２の例では、上記のソフトウェアシステムが、１つ以上のプロセッサＰ１～Ｐ４による実行のために、１つ以上のメモリユニットＭ１～Ｍ２に格納されてもよい。それにより、図１Ａ～１Ｃの制御システム１６は、プロセッサＰ１～Ｐ４のうちの１つまたは複数によって実行されるときに、ソフトウェアシステムによって実施され得る。
【0057】
ソフトウェアシステムは、任意の適切なコンピュータ可読媒体（ＣＲＭ）上の医療デバイス上にインストールするために提供されてもよい。ＣＲＭは、揮発性であろうと不揮発性であろうと、電子的、磁気的または光学的媒体のような、非一時的記憶媒体またはメモリ媒体を含むことができる。代替として、または追加として、ＣＲＭは、ネットワークおよび／または無線リンクなどの通信媒体を介して搬送され得る、電力、電磁気、またはデジタルにかかわらず、伝搬信号などの一時的媒体を備えることができる。
【0058】
図２のハードウェアコンポーネントは、単に一例として与えられているに過ぎない。医療デバイス１０、１０’は任意の数の各タイプのコンポーネントを含むことができ、図２のコンポーネントのいくつかは、医療デバイスの所望の機能性に応じて省略または交換することができる。例えば、ディスプレイ１２がタッチセンシティブである場合、制御ボタン１３は、ディスプレイ１２上の仮想ボタンに置き換えられてもよい。図２の例は非網羅的であり、医療デバイスはキーボード、コンピュータマウス、電源などのような、その動作中にアクティブである他のタイプのコンポーネントを含むことができることもまた理解される。
【0059】
一般に、医療デバイス１０、１０’は、少なくとも１つのプロセッサ、少なくとも１つのメモリユニット、ならびにアクチュエータおよびセンサのうちの少なくとも１つを備える。図１Ａ～１Ｃの医療デバイス１０、１０’は一般に、少なくとも１つのアクチュエータ１７を含み、少なくとも１つのセンサ１８もまた含むことができる。モニタリング用に設計された医療デバイスは主として少なくとも１つのセンサ１８を含むことができるが、アクチュエータ１７を含む必要はない。図１Ａ～１Ｃの例ではアクチュエータ１７が流体ポンプ、バルブ、ヒータ、洗浄システムなどのうちの１つまたは複数を含むことができ、センサ１８は温度、導電性、濃度、圧力、流量などのうちの１つまたは複数を表すセンサデータを生成するように構成することができる。
【0060】
図３は非限定的な例に従った、医療デバイス、例えば、前述の医療デバイスのいずれかにおいて実行するためのソフトウェアシステムのブロック図である。図に示すように、ソフトウェアシステムは、４つのサブシステムＳＳ１－ＳＳ４から構成される。以下では、サブシステムＳＳ１～ＳＳ４が１つ以上の別個のプロセッサ上で実行されるものとする。図２の例では、サブシステムＳＳ１～ＳＳ４がそれぞれのプロセッサＰ１～Ｐ４上で実行可能である。言い換えると、いくつかの実施形態ではサブシステムＳＳ１はプロセッサＰ１上で実行可能であり、サブシステムＳＳ２はプロセッサＰ２上で実行可能であり、サブシステムＳＳ３はプロセッサＰ３上で実行可能であり、および／またはサブシステムＳＳ４はプロセッサＰ４上で実行可能である。各サブシステムＳＳ１～ＳＳ４は、医療処置を実行する間に医療デバイスの操作に関与する一組のソフトウェアアプリケーションを含む。サブシステムＳＳ１、ＳＳ２、ＳＳ３、ＳＳ４におけるソフトウェアアプリケーションの設定はそれぞれＳＷ１、ＳＷ２、ＳＷ３、ＳＷ４によってまとめて示される。サブシステムＳＳ１、ＳＳ２、ＳＳ３、ＳＳ４における個々のソフトウェアアプリケーションは、それぞれソフトウェアアプリケーションＳＷ１ｘ、ＳＷ２ｘ、ＳＷ３ｘ、ＳＷ４ｘによって指定される。さらに、各サブシステムＳＳ１～ＳＳ４はＩＳＣ１～ＩＳＣ４と表記されるそれぞれの通信モジュールを含み、これは、上記の通信スタックを含み、他の１つ以上のサブシステムとの通信の管理を担う。図示の例では、ＩＳＣ１－ＩＳＣ４がサブシステムＳＳ１とＳＳ３との間、サブシステムＳＳ１とＳＳ２との間、およびサブシステムＳＳ３とＳＳ４との間の通信を確立するように構成されている。一実施形態によれば、各サブシステムＳＳ１～ＳＳ４は、ＳＨＭ１～ＳＨＭ４によって示され、以下で「マネージャ」と示されるマネージャモジュールをさらに備える。それぞれのマネージャＳＨＭ１～ＳＨＭ４は、起動およびシャットダウン中にそのサブシステムＳＳ１～ＳＳ４の操作の管理を担う。それぞれのマネージャＳＨＭ１～ＳＨＭ４は、管理されるソフトウェアアプリケーションのリストへのアクセスを有する。また、マネージャＳＨＭ１～ＳＨＭ４は例えば、それぞれのマネージャＳＨＭ１～ＳＨＭ４が、そのソフトウェアアプリケーションＳＷ１～ＳＷ４が期待通りに実行されていることをモニタリングすることによって、動作中のソフトウェアシステムの健全性をモニタリングすること担うこともできる。また、マネージャＳＨＭ１～ＳＨＭ４のうちの１つまたは複数は、起動時に実行されて、プロセッサＰ１～Ｐ４のうちの１つまたは複数上でオペレーティングシステムをロードし、実行するためのシステムを準備するブートコードも含むことができる。
【0061】
図３の例ではサブシステムＳＳ１がＳＷ１ｃによって指定されたソフトウェアアプリケーションを含み、サブシステムＳＳ３はＳＷ３ｃによって指定されたソフトウェアアプリケーションを含む。ソフトウェアアプリケーションＳＷ１ｃおよびＳＷ３ｃは、医療処置を実行するときに医療デバイスの操作にクリティカルであることによって、他のソフトウェアアプリケーションと区別される。このコンテキストにおいて、「クリティカル」はそれぞれのソフトウェアアプリケーションＳＷ１ｃ、ＳＷ３ｃの正しい動作が例えば、対象者１００の健康リスクを軽減することを考慮して、製造者および／または規制の権限によって設定され得る要件仕様に従って医療処置が実行されるために必要であることを意味する（少なくとも１つのクリティカルソフトウェアアプリケーションを含むサブシステムはここではまた「クリティカルサブシステム」と表記される）。一例では、クリティカルソフトウェアアプリケーションが例えば、１つまたは複数のアクチュエータ１７、および任意選択で１つまたは複数のセンサ１８を動作させるための順序づけされた制御シーケンスコマンドまたは信号を生成することによって、医療デバイスによって実行される医療処置を制御するように構成されてもよい。別の例では、クリティカルソフトウェアアプリケーションが例えば、１つまたは複数のセンサ１８を動作させるための制御コマンドまたは信号の順序づけされたシーケンスを生成することによって、医療デバイスによって実行される医療処置の動作を監視するように構成されてもよい。
【0062】
１つの具体例ではＳＷ１ｃが医療処置を制御するように構成され、ＳＷ３ｃは医療処置の操作を監視するように構成される。医療処置を制御するメインシステム、またはそのようなメインシステムによって使用されるハードウェアコンポーネントのいずれかにおける動作不良の場合に、対象者に健康リスクをもたらす医療処置を実行する多くの医療デバイスは、並列に動作し、メインシステムから独立している保護システムを含むことが必要とされる。保護システムが潜在的な動作不良を検出したときはいつでも、医療デバイスは安全な動作条件に切り替えられる。従って、図３に戻ると、サブシステムＳＳ１はメインシステムに対応し、サブシステムＳＳ３は保護システムに対応する。サブシステムＳＳ２およびＳＳ４は、それぞれ、サブシステムＳＳ１およびサブシステムＳＳ３により生成されたコマンド／信号に基づいて、アクチュエータおよび／またはセンサの異なる設定と通信するように構成されてもよい。この目的のために、サブシステムＳＳ２、ＳＳ４の各々はそれぞれのサブシステムＳＳ２、ＳＳ４に接続された周辺機器（例えば、アクチュエータおよび／またはセンサ）へのアクセスを提供するためのソフトウェアアプリケーションを備えることができる。メインシステムと保護システムとの間の独立性を達成するために、ＳＳ２は一組のメインセンサに接続され、ＳＳ４は別個のセットの補助センサに接続されてもよい。サブシステムＳＳ１～ＳＳ４はまた、独立性を達成するために、別個のプロセッサ（例えば、図２のＰ１～Ｐ４）上に実装されてもよい。変形例では、サブシステムＳＳ２および／またはサブシステムＳＳ４がそれぞれ、サブシステムＳＳ１およびサブシステムＳＳ３内に含まれてもよい。
【0063】
したがって、１つの実施形態では、ソフトウェアシステムが少なくともメインシステム（サブシステムＳＳ１）および保護システム（サブシステムＳＳ３）を含むことができ、これはモニタリングおよびフェールセーフコンポーネントとすることができ、常に患者の安全を保証するのを助けるためにサブシステムＳＳ１に完全に冗長である。サブシステムＳＳ３は、患者に危険をもたらすサブシステムＳＳ１の任意の単一の不良点がサブシステムＳＳ３によって検出され、回避され得るように設計され得る。正常状態では、サブシステムＳＳ１がＨＷおよび／またはＳＷコンポーネントの現在の状態を読み取り、選択された動作モードに従って次の状態を決定し、必要に応じてＨＷおよび／またはＳＷコンポーネントに新しい状態を書き込む。これら３つの動作フェーズの各々に固有のエラーの危険性のために、サブシステムＳＳ３は、システムを停止してオペレータに不良状態を通知することによって、不良の場合に患者を保護するように実施される。可能性のある不良には、データの喪失または誤表示、ソフトウェアの誤計算または障害、または例えば、トランスデューサ、スイッチ、またはプロセッサのハードウェア不良が含まれ得る。サブシステムＳＳ３は、システムで送信されるコマンドとステータス情報をモニタリングすることで、このようなリスクから保護する。サブシステムＳＳ３はまた、冗長な測定を提供するために、１つ以上の専用センサに接続されてもよい。サブシステム間のリンクは、単一の接続である必要はなく、集積回路、デジタル論理、Ｉ／Ｏバス、およびソフトウェアのうちの１つまたは複数などの一連のリンクを備えることができることに留意されたい。
【0064】
以下に、サブシステムＳＳ３に含まれ得るソフトウェアアプリケーションの例を示す。これは、理解を向上させ、追加のコンテキストを提供するために与えられた単なる例であることを理解されるべきである。したがって、サブシステムＳＳ３は、さらなる、より少ない、または他のソフトウェアアプリケーションを含むことができる。また、以下の例示的な構造、またはその部分は、システムの他のサブシステム内、例えばサブシステムＳＳ１内に実装されてもよいことも明らかであろう。１つの具体例では、サブシステムＳＳ３がシリアル通信を除いて、下位ＳＷをＨＷに実装することを担うＩ／Ｏアプリケーション（「Ｉ／Ｏ」）を備える。したがって、Ｉ／Ｏ は、クライアントにＩ／Ｏ データを提供し、Ｉ／Ｏ データのＣＲＣ もまた実行できる。アラーム処理アプリケーションはアラームを管理し、アラームがアクティブな場合にＩ／Ｏ を通じてリセットを要求することを担う。医療デバイスの動作中、アラーム処理アプリケーションは、モード管理アプリケーション（以下）およびＩ／Ｏと対話する。構成処理アプリケーションは、サブシステムＳＳ３内のクライアントに治療設定を提供することを担う。医療デバイスの動作中、構成処理アプリケーションは、システム間処理（以下）を介してサブシステムＳＳ１と対話する。データロガーアプリケーションは、サブシステムＳＳ３内の他のソフトウェアアプリケーションからテキストベースのログデータを受信することを担い、そのログデータをクライアントに提供する。医療デバイスの動作中、データロガーアプリケーションはまた、時間処理アプリケーション（以下）と対話する。モード管理アプリケーションは、現在のシステム状態および治療状態をクライアントに提供することを担う。その状態は、サブシステムＳＳ１ からInter System Handling(下記） およびＩ／Ｏ を介して受信される。時間処理アプリケーションは、クライアントに現在のシステム時間を提供する。デバイス監視アプリケーションは、Ｉ／Ｏから取り出された値を使用して、進行中の治療をモニタリングすることを担う。サブシステムＳＳ１が時間内に予防措置をとらない場合、デバイス監視アプリケーションは、アラーム処理アプリケーションにアラームを報告することを担う。医療デバイスの動作中、デバイス監視アプリケーションはまた、構成処理アプリケーション、モード管理アプリケーション、時間処理アプリケーション、およびソフトウェアヘルスモニタリングソフトウェアモジュール（以下）と対話する。デバイス監視アプリケーションは、サブシステムＳＳ１の状態と状態変化をモニタリングすることがある。例えば、図１Ａ～１Ｃを参照して例示されるような医療デバイスのコンテキストにおいて、デバイス監視アプリケーションはまた、１つ以上の血液リーク検出器、１つ以上の重量計、１つ以上のクランプ、１つ以上の気泡検出器、１つ以上のポンプ（シリンジポンプ、血液ポンプ、透析流体ポンプ、排出液ポンプ、交換ポンプなど）、１つ以上のピンチ弁、１つ以上の制御パネル、１つ以上の液体リーク検出器、１つ以上の圧力センサなどの操作（値、コマンド、ステータス、タイミングなど）をモニタしてもよい。サブシステムＳＳ３は図３のＳＨＭ３に対応するソフトウェア健全性モニタリングソフトウェアモジュールをさらに含み、これはサブシステムＳＳ３内のソフトウェアの健全性を監視し、サブシステムＳＳ１が生きていて実行中であることを監視する役割を担う。例示では、ソフトウェアの整合性のチェック、ＲＡＭ のチェック、サブシステムＳＳ３ 内のすべてのソフトウェアアプリケーションが期待どおりに実行されていることのモニタリング、サブシステムＳＳ１ をモニタして実行していることを確認すること、ハードウェア（ＨＷ） ウォッチドッグのキックを含む。サブシステムＳＳ３はまた、サブシステムＳＳ１を含む他のサブシステムとのシリアル通信の管理を担う図３のＩＳＣ３に対応するシステム間通信ソフトウェアモジュールを含む。システム間通信は、上位通信のためのシステム間ハンドリングと、下位通信のためのシステム間トランスポートとに細分されてもよい。１つの実施例ではアラーム処理、構成処理、データロガー、モード管理、および時間処理はクライアントのコンテキストで実行されるスレッドセーフライブラリであり、ソフトウェア健全性モニタリングはタスクとして実行され、入ってくるイベントに作用するようにイベントドリブンされる。ソフトウェア健全性モニタリングタスクはまた、タイムアウトを処理するために、所定の期間（例えば５０ミリ秒）の周期的イベントを有する
ソフトウェア健全性モニタリングタスクは他のタスクがタスク監視をブロックすることを防ぐために、最高の優先順位を持つ。デバイス監視は、タスクとして実行され、例えば５０ｍｓのサイクル実行と、要求されたタイミングで実行するための高優先度とを有する。Ｉ／Ｏは、タスクとして実行され、Ｉ／Ｏイベントをサービスするためにイベント駆動され、独立した信号読取りおよびバスバッファ空にするために、例えば５ｍｓの周期的な実行を有する。Ｉ／Ｏタスクは短時間フレームでイベントをサービスすることができる一方で、同時に、デバイス監視タスクをブロックすることを回避するために、中間の優先度を有する。システム間通信はタスクとして実行され、イベント駆動型であるが、これはシステム間通信の担当が入ってくるおよび出ていく通信イベントを処理することであるからである。システム間通信タスクはまた、システム状態メッセージの監視のために、例えば１００ｍｓのサイクル実行を有する。このタスクのリアルタイム要件が最低のため、システム間通信タスクは低優先度である。タスク間の通信は非ブロッキングである。高優先度のタスクは、低優先度の低いタスクとの通信によってブロックされない場合がある。
ソフトウェア健全性モニタリングタスクは他のタスクがタスク監視をブロックすることを防ぐために、最高の優先順位を持つ。デバイス監視は、タスクとして実行され、例えば５０ｍｓのサイクル実行と、要求されたタイミングで実行するための高優先度とを有する。Ｉ／Ｏは、タスクとして実行され、Ｉ／Ｏイベントをサービスするためにイベント駆動され、独立した信号読取りおよびバスバッファ空にするために、例えば５ｍｓの周期的な実行を有する。Ｉ／Ｏタスクは短時間フレームでイベントをサービスすることができる一方で、同時に、デバイス監視タスクをブロックすることを回避するために、中間の優先度を有する。システム間通信はタスクとして実行され、イベント駆動型であるが、これはシステム間通信の担当が入ってくるおよび出ていく通信イベントを処理することであるからである。システム間通信タスクはまた、システム状態メッセージの監視のために、例えば１００ｍｓのサイクル実行を有する。このタスクのリアルタイム要件が最低のため、システム間通信タスクは低優先度である。タスク間の通信は非ブロッキングである。高優先度のタスクは、低優先度の低いタスクとの通信によってブロックされない場合がある。
【0065】
図４Ａは、図３のソフトウェアシステムを含む医療デバイスの起動のための方法４００の実施形態のフローチャートである。方法４００は、サブシステムの１つが、サブシステムの起動を調整する「プライマリサブシステム」であることを前提とするが、一方残りのサブシステムは「セカンダリサブシステム」と表記される。この方法は一般に、１つのプライマリサブシステムと少なくとも１つのセカンダリサブシステムを含む任意のソフトウェアシステムに適用可能である。以下の例では、ＳＳ１ がプライマリサブシステムで、ＳＳ２－ＳＳ４ がセカンダリサブシステムである。以下の例ではまた、マネージャＳＨＭ１～ＳＨＭ４が以下に説明するように、システムの起動のためのコントローラであると仮定する。
【0066】
方法４００は、すべてのサブシステムＳＳ１～ＳＳ４内の個々のソフトウェアアプリケーションＳＷ１ｘ～ＳＷ４ｘを開始するステップ４０１を含む。ステップ４０１はサブシステムＳＳ１～ＳＳ４のマネージャＳＨＭ１～ＳＨＭ４および通信モジュールＩＳＣ１～ＩＳＣ４を起動することを含む、ソフトウェアシステム内のシステム機能およびシステム通信を開始させる従来のブート手順の後に、またはその一部として実行されてもよい。ステップ４０１は、医療デバイスの電源投入時に自動的に実行されてもよい。ステップ４０１の一実施形態では、それぞれのサブシステム内のソフトウェアアプリケーションＳＷ１～ＳＷ４がそれぞれのサブシステムＳＳ１～ＳＳ４のマネージャＳＨＭ１～ＳＨＭ４またはソフトウェアシステム内の他の場所によって生成され得る起動コマンド／信号を受信すると開始する。ステップ４０１の開始中に、それぞれのソフトウェアアプリケーションＳＷ１～ＳＷ４はメモリ（図２のメモリユニットＭ１、Ｍ２参照）からの読出し、１つまたは複数のパラメータの開始、通信インターフェースの開始など、それぞれの所定の開始動作シーケンスを完了することができる。本開示は図３に示されるソフトウェアアプリケーションＳＷ１～ＳＷ４のすべてが、起動方法４００によって開始されることを前提とすることに留意されたい。しかしながら、サブシステムＳＳ１～ＳＳ４のうちの１つ以上が医療処置を実行するための医療デバイスの操作に関与するが、別の時間に、すなわち、起動方法４００とは別個に起動される１つ以上のソフトウェアアプリケーションを含むことが考えられる。
【0067】
ステップ４０２において、各ソフトウェアアプリケーションＳＷ１ｘ－ＳＷ４ｘがステップ４０１に従って開始されたとき、ソフトウェアアプリケーションはそのソフトウェアアプリケーションが起動準備完了であることを示す、そのそれぞれのサブシステムＳＳ１－ＳＳ４内に「アプリケーション準備完了」通知を提供する。このコンテキストにおいて、ソフトウェアアプリケーションはその指定されたタスクまたはプロセスを実行し、他のソフトウェアアプリケーションと対話する準備ができたとき、「起動準備完了」である。一実施形態において、「アプリケーション準備完了」通知は他のソフトウェアアプリケーションから入ってくる通信信号を受信する準備ができている範囲で動作しているときはいつでも、ソフトウェアアプリケーションにより提供される。いくつかの実施形態において、ソフトウェアアプリケーションは例えば、要求－応答メッセージ交換パターンによって、他のソフトウェアアプリケーションに通信信号を送信する準備ができている。したがって、ソフトウェアアプリケーションは「アプリケーション準備完了」通知を提供するとき、完全に動作する必要はない。
【0068】
ステップ４０３は、各サブシステムＳＳ１～ＳＳ４によって別々に実行される。それぞれのサブシステムＳＳ１～ＳＳ４のマネージャＳＨＭ１～ＳＨＭ４がそれぞれのサブシステムＳＳ１～ＳＳ４内のソフトウェアアプリケーションＳＷ１～ＳＷ４のすべてから「アプリケーション準備完了」通知を取得すると、マネージャＳＨＭ１～ＳＨＭ４は、それぞれのサブシステムＳＳ１ＳＳ４内の内部およびプライマリサブシステムＳＳ１による受信のための外部の両方で、ソフトウェアシステム内に「準備完了」通知を提供する（以下のステップ４０５）。
【0069】
ステップ４０４はまた、各サブシステムＳＳ１～ＳＳ４によって別々に実行される。サブシステムＳＳ１～ＳＳ４におけるのソフトウェアアプリケーションＳＷ１～ＳＷ４のそれぞれが、サブシステムＳＳ１～ＳＳ４のマネージャＳＨＭ１～ＳＨＭ４によって提供される「準備完了」通知を取得すると、ソフトウェアアプリケーションＳＷ１～ＳＷ４は自身らの間で、すなわち、それぞれのサブシステムＳＳ１～ＳＳ４内での通信を可能にする。これにより、ステップ４０４はそれぞれのサブシステムＳＳ１～ＳＳ４内でのアプリケーションレベルの「内部通信」を可能にする。ステップ４０４が完了すると、サブシステム内のすべてのソフトウェアアプリケーションが起動され、サブシステムはこれによってソフトウェアシステム内の他のサブシステムと対話する準備ができる。
【0070】
ステップ４０５は、プライマリサブシステムＳＳ１のみによって実行される。マネージャＳＨＭ１は全てのセカンダリサブシステムの「準備完了」通知を取得すると、マネージャＳＨＭ１はサブシステムＳＳ１～ＳＳ４の起動を調整する。
【0071】
方法４００は、起動をサブシステムレベルとシステムレベルに分離し、最初にすべてのソフトウェアアプリケーションがサブシステムレベルで起動の準備ができていることを確認し、次に起動に進む前にすべてのサブシステムがシステムレベルで起動の準備ができていることを確認することによって、医療デバイスのソフトウェアシステムの確定的な起動を可能にする。この原理は図６にさらに示されており、これは、起動及びシャットダウンの間のサブシステムレベル（トップ）及びシステムレベル（ボトム）におけるソフトウェアシステムの状態を示す。図６は、ソフトウェアシステムが必ずしもステートマシンとして実施されることを意味するものではなく、ソフトウェア・システムの起動およびシャットダウン中の全体的な制御メカニズムを説明するにすぎないことを意図していることに留意することが重要である。医療デバイスがスイッチオンされ、電源オンされると（図６の遷移ＩａおよびＩｂ）、ソフトウェアシステムは状態「システム準備未完了」にあり、サブシステムＳＳ１～ＳＳ４の各々は状態「サブシステム準備未完了」にある。図６の遷移ＩＩに対応するステップ４０１～４０４の結果として、それぞれのサブシステムＳＳ１～ＳＳ４は状態「準備完了」に入る（そのソフトウェアアプリケーションから「アプリケーション準備完了」通知を受信した後）。システムレベルでは、ソフトウェアシステムはまだ状態「システム準備未完了」にある。図６の遷移ＩＩＩに対応するステップ４０５の結果として、ソフトウェアシステムは状態「システム準備完了」に入り（セカンダリサブシステムから「準備完了」通知を受信した後）、ソフトウェアシステムは、医療処置を実行するために医療デバイスを操作する準備が進められている。「アプリケーション準備完了」通知および「準備完了」通知の使用は、医療デバイスの安全で信頼性のある起動を保証することを理解されるべきである。例えば、その通知は、通知が提供されることを妨げる誤動作が発生するたびに、ソフトウェアシステムが起動されることを妨げる。通知の使用は、ソフトウェアシステムにおける誤動作の簡単かつ効率的な検出および位置特定を可能にする。さらに、背景技術のセクションで述べたタイマの使用および公称起動時間と比較して、公称起動時間は一般に実際の起動時間に対して大幅な余裕をもって設定されるので、通知の使用はまた、医療デバイスの起動に必要となる時間を短縮することもできる。
【0072】
また、一般的な「準備完了」通知は、ステップ４０４においてサブシステム内のすべてのソフトウェアアプリケーションによって受信され、このサブシステム内のアプリケーションレベルの内部通信を可能にするために個々のソフトウェアアプリケーションを起動させることに留意する価値がある。ステップ４０１～４０４により、起動方法４００はそれぞれのサブシステムの分散型であるが確定的な起動を提供する。この手段、この方法４００はそれぞれのサブシステム内の個々のソフトウェアアプリケーションの起動順序を集中的に制御する必要がなくなり、代わりに、これらのすべてのソフトウェアアプリケーションは、「準備完了」通知を受信するたびに起動することが許可される。当業者は、ソフトウェアアプリケーションのこの分散された起動が起動手順の制御およびトラブルシューティングを容易にするだけでなく、ソフトウェアアプリケーションの追加および除去を容易にすることによって、ソフトウェアシステムの保守および更新もまた容易にすることを理解する。
【0073】
通知は当技術分野で周知のように、プッシュメカニズムまたはプルメカニズムによってソフトウェアシステム内で配布することができる。プッシュメカニズム、通知、または通知が利用可能であることを示すメッセージが、受信者による受信または傍受のために発信者から送信される。ポーリングメカニズムを用いて、受信者は、発信者からの通知を要求する。
【0074】
図４Ａに戻ると、「アプリケーション準備完了」通知は、それぞれのサブシステムＳＳ１～ＳＳ４内で、それぞれのソフトウェアアプリケーションからマネージャＳＨＭ１～ＳＨＭ４に直接提供される必要はないことに留意されたい。代わりに、サブシステム内のソフトウェアアプリケーションは、１つのソフトウェアアプリケーションから次のものに所定のシーケンスで「アプリケーション準備完了」通知を提供することができる。シーケンスにおけるの最終ソフトウェアアプリケーションが「アプリケーション準備完了」通知をマネージャに提供すると、マネージャはすべての「アプリケーション準備完了」通知がサブシステムに提供されたと結論付ける。
【0075】
図３の分散マネージャＳＨＭ１～ＳＨＭ４を、上述のように「アプリケーション準備完了」通知および「サブシステム準備完了通知」を取得する中央マネージャに置き換えることもまた考えられる。しかし、分散型マネージャＳＨＭ１～ＳＨＭ４は、サブシステムＳＳ１～ＳＳ４の厳密なモジュール化という利点を提供し、次に、サブシステムＳＳ１～ＳＳ４を独立して開発され、および／または試験され、および／または配備されることが可能になる。
【0076】
さらなる変形例では、マネージャＳＨＭ１～ＳＨＭ４の機能が代わりに、それぞれのサブシステムＳＳ１～ＳＳ４内のソフトウェアアプリケーションのうちの１つによって実行される。
【0077】
また、図４Ａのステップ４０４は、サブシステムが「準備完了」状態に入ったときに、サブシステム内のソフトウェアアプリケーションが互いに通信可能になり、サブシステムが真に起動準備完了となることを確実にするという利点を提供する一方で、サブシステムのこの内部通信が後の段階、例えば、ソフトウェアシステムが「システム準備完了」状態に入ったとき（例えば、以下のステップ４０８で）に可能になると考えられることも留意されたい。
【0078】
さらなる変形例では、セカンダリサブシステムＳＳ２～ＳＳ４内のソフトウェアアプリケーションのみが、「アプリケーション準備完了」通知を提供し、それらのそれぞれのマネージャＳＨＭ２～ＳＨＭ４から「準備完了」通知を受信するように構成されているが、一方でプライマリサブシステムＳＳ１内のソフトウェアアプリケーションはそうではない。
【0079】
図４ＢはサブシステムＳＳ１～ＳＳ４の起動を調整するための方法４０５’の一実施形態のフローチャートであり、図４Ａのステップ４０５の一部として実行されてもよい。ステップ４０６で、プライマリサブシステムＳＳ１はそれぞれのセカンダリサブシステムＳＳ２～ＳＳ４に「システム準備完了」通知を提供する。図４Ａに戻ると、プライマリサブシステムＳＳ１がそのソフトウェアアプリケーションＳＷ１のすべてから「アプリケーション準備完了」通知を取得したとき（ステップ４０３）、およびセカンダリサブシステムＳＳ２～ＳＳ４のすべてから「準備完了」通知を取得したとき（ステップ４０５）、「システム準備完了」通知が生成されることを理解されたい。ステップ４０７で、それぞれのセカンダリサブシステムＳＳ２～ＳＳ４は「システム準備完了」通知を取得する。「システム準備完了」通知を取得することによって、マネージャＳＨＭ２～ＳＨＭ４はすべてのサブシステムＳＳ１～ＳＳ４が起動の準備ができていることを認識する。同様に、マネージャＳＨＭ１は、すべてのサブシステムが起動の準備ができていることを認識する。上記から理解されるように、サブシステムは、そのソフトウェアアプリケーションが起動され、互いに通信することが許可されると、起動の準備が完了する。
【0080】
後続のステップ４０８において、すべてのサブシステムＳＳ１～ＳＳ４のマネージャＳＨＭ１～ＳＨＭ４はサブシステム間のアプリケーションレベルの通信を可能にし、したがって、１つのサブシステム内のソフトウェアアプリケーションは、別のサブシステム内のソフトウェアアプリケーションと通信可能である。これにより、ステップ４０８は、サブシステムＳＳ１～ＳＳ４間の「相互通信」を可能にする。図３の例では、ＳＳ１とＳＳ２、ＳＳ１とＳＳ３、およびＳＳ３とＳＳ４の間で通信が可能である。したがって、ステップ４０８は、集中型通信、すなわち、プライマリサブシステムと１つ以上のセカンダリサブシステムとの間だけでなく、セカンダリサブシステム間の直接通信もまた可能にすることができる。ステップ４０８が完了すると、ソフトウェアシステムが開始され、医療デバイスは例えば、オペレータに命令を提供すること、オペレータが医療処置のための制御パラメータ値を入力することを可能にすることなどによって、医療処置の少なくとも一部を実行する準備ができる。
【0081】
方法４０５’ は、すべてのサブシステムＳＳ１ ～ＳＳ４の確定的な起動を保証する。「システム準備完了」通知を提供する利点は上述したとおりの「アプリケーション準備完了」および「準備完了」通知を提供する利点と同様である。例えば、ステップ４０７において、共通の「システム準備完了」通知がソフトウェアシステム内の全てのセカンダリサブシステムによって受信され、そして個々のセカンダリサブシステムを起動させて、ソフトウェアシステム内のサブシステム間通信を可能にすることに留意されたい。ステップ４０６～４０８により、起動方法４００はソフトウェアシステムの分散型であるが確定的な起動を提供する。これは、次に、この方法４００がソフトウェアシステム内の個々のサブシステムの起動順序の集中制御のいかなる必要性をなしで済まし、そして代わりに、「システム準備完了」通知を受信すると、全てのサブシステムがスタートすることを許されることを意味する。当業者は、サブシステムのこの分散型起動が起動手順の制御およびトラブルシューティングを容易にするだけでなく、サブシステムの追加および除去を容易にすることによって、ソフトウェアシステムの保守および更新を容易にすることもまた理解する。
【0082】
図５Ａは、図３のソフトウェアシステムによって操作される医療デバイスのシャットダウンのための方法５００の実施形態のフローチャートである。シャットダウンは例えば、制御ボタン（図１Ａ～１Ｃの１３参照）を押すときに、オペレータによって生成されるシャットダウンコマンドによって、または医療デバイス内の処理によってトリガされてもよい。
【0083】
ステップ５０１において、プライマリサブシステムＳＳ１のマネージャＳＨＭ１は、シャットダウンコマンドについて通知され、すべてのセカンダリサブシステムＳＳ２～ＳＳ４に「シャットダウン」通知を提供することによってシャットダウンを開始するように進む。ステップ５０２において、マネージャＳＨＭ１は、プライマリサブシステムＳＳ１内のソフトウェアアプリケーションＳＷ１の終了を要求する。このコンテキストにおいて、「終了」は各ソフトウェアアプリケーションが電源喪失の準備ができている範囲でそのアクティビティを停止することを意味する。ステップ５０３が各セカンダリサブシステムＳＳ２～ＳＳ４によって別々に実行される。マネージャＳＨＭ２～ＳＨＭ４が「シャットダウン」通知を取得し、その後、セカンダリサブシステムＳＳ２～ＳＳ４のソフトウェアアプリケーションＳＷ２～ＳＷ４の終了を要求する。次に、ステップ５０４において、プライマリサブシステムＳＳ１のマネージャＳＨＭ１は例えば、医療デバイス内の電力マネージャに電力を切断するように通知することによって、医療デバイスの電源喪失を開始させる。
【0084】
ステップ５０１～５０３の組合せは、シャットダウンをシステムレベルとサブシステムレベルとに分離することによって、医療デバイスの確定的シャットダウンを保証する。この原理を図６にさらに示す。医療デバイスがシャットダウンされるべきとき、ソフトウェアシステムは状態「システム準備完了」にあり、サブシステムＳＳ１～ＳＳ４の各々は状態「準備完了」にある。図６の遷移ＩＶに対応するステップ５０１の結果として、システムは状態「システム準備未完了」に入ることが分かる。サブシステムレベルではサブシステムＳＳ１～ＳＳ４がステップ５０１の後、依然として状態「準備完了」にある。ステップ５０２～５０３の結果として、それぞれのサブシステムＳＳ１～ＳＳ４は図６の遷移Ｖに対応する状態「サブシステム準備未完了」に入ることが分かる。これにより、ソフトウェアシステムは電源喪失のためにシステムレベルとサブシステムレベルの両方で準備され、この電源喪失はステップ５０４によって開始され、図６の遷移ＶＩに対応する。
【0085】
図５ＢはプライマリサブシステムＳＳ１のソフトウェアアプリケーションＳＷ１の終了を要求するための方法５０２’の一実施形態のフローチャートであり、図５Ａのステップ５０２の一部として実行されてもよい。ステップ５０５において、マネージャＳＨＭ１はプライマリサブシステムＳＳ１のソフトウェアアプリケーションＳＷ１に「サブシステム準備未完了」通知を提供する。ステップ５０６において、ソフトウェアアプリケーションは「サブシステム準備未完了」通知を取得する。ステップ５０７において、「サブシステム準備未完了」通知を取得した後に、それぞれのソフトウェアアプリケーションＳＷ１ｘは、例えば、即座に停止した場合に、シャットダウン後に再起動されたときに医療デバイスの性能に影響を及ぼす結果となる、すなわち、破損データを生成する、または対象者の健康を危うくするすべての進行中の必然的な活動を完了することによって、終了を準備する。このような結果的な活動は、データをメモリに書き込むこと、演算を完了すること、アクチュエータ（図１Ａ～１Ｃの１７）のための制御信号を生成することなどを含むことができる。結果的な活動は例えば、スピーカ（図１Ａ～１Ｃの１５）によるオーディオ信号の再生を完了すること、ディスプレイ（図１Ａ～１Ｃの１２）上にシャットダウンメッセージを提示することなど、ユーザ体験にもまた関係し得る。したがって、ステップ５０７において、それぞれのソフトウェアアプリケーションは、非結果的なものとみなされる他の活動が後の終了のために進むことを可能にすることができる。ステップ５０８において、それぞれのソフトウェアアプリケーションＳＷ１ｘは終了の準備ができたときに、「アプリケーションのシャットダウン準備完了」通知を提供する。ステップ５０９において、マネージャＳＨＭ１はソフトウェアアプリケーションＳＷ１から「アプリケーションのシャットダウン準備完了」通知を取得する。マネージャＳＨＭ１がすべてのソフトウェアアプリケーションＳＷ１から「アプリケーションのシャットダウン準備完了」通知を取得したときに、プライマリサブシステムＳＳ１は状態「サブシステム準備未完了」（図６）にあると見ることができる。
【0086】
図５Ｃは、図５Ａのステップ５０３の一部として実行されてもよい、セカンダリサブシステムＳＳ２～ＳＳ４のソフトウェアアプリケーションＳＷ２～ＳＷ４の終了を要求するための方法５０３’の一実施形態のフローチャートである。方法５０３’ は、各セカンダリサブシステムＳＳ２－ＳＳ４ によって個別に実行される。ステップ５０５～５０９は図５Ｂの方法５０２’のステップ５０５～５０９に対応し、さらなる説明をしない。ステップ５０５および５０９はマネージャＳＨＭ２～ＳＨＭ４によって実行され、ステップ５０６～５０８はセカンダリサブシステムＳＳ２～ＳＳ４のそれぞれのソフトウェアアプリケーションによって実行されることを理解されたい。ステップ５０９の後、それぞれのセカンダリサブシステムＳＳ２～ＳＳ４は状態「サブシステム準備未完了」（図６）にあると見ることができ、ステップ５１０において、マネージャＳＨＭ２～ＳＨＭ４がステップ５０９においてそれぞれのセカンダリサブシステムＳＳ２～ＳＳ４のすべてのソフトウェアアプリケーションから「アプリケーションのシャットダウン準備完了」通知を取得した場合、それぞれのマネージャＳＨＭ２～ＳＨＭ４は、プライマリサブシステムＳＳ１に「サブシステムのシャットダウン準備完了」通知をする。
【0087】
図５Ａに戻ると、ステップ５０４において、マネージャＳＨＭ１は（方法５０３’によって生成された）すべてのセカンダリサブシステムＳＳ２～ＳＳ４から「サブシステムのシャットダウン準備完了」通知を取得した後、および（方法５０２’によって生成された）プライマリサブシステムＳＳ１内のすべてのソフトウェアアプリケーションＳＷ１から「アプリケーションのシャットダウン準備完了」通知を取得した後にのみ、電源喪失を開始することができる。
【0088】
ステップ５０４の変形例では、マネージャＳＨＭ１がステップ５０１から所定の時間が経過した場合に、セカンダリサブシステムＳＳ２～ＳＳ４のうちの１つ以上からの「サブシステムのシャットダウン準備完了」通知が無い場合にも、電源喪失を開始することに進むことが考えられる。したがって、マネージャＳＨＭ１は電源喪失が開始されるまでの最大時間遅れを定義するタイマを設定することができる。これはソフトウェアアプリケーションまたはハードウェアコンポーネントがシャットダウン中に誤動作した場合に、ソフトウェアフリーズのリスクを軽減する。同様に、マネージャＳＨＭ１～ＳＨＭ４は「アプリケーションのシャットダウン準備完了」通知を取得するために、ステップ５０９において、対応するタイマを設定することが考えられる。
【0089】
また、ステップ５０９において、マネージャＳＨＭ１～ＳＨＭ４のうちの１つ以上は１つ以上のソフトウェアアプリケーション、例えば、すべてのアクティビティが即座に停止された場合に本質的に非必然的なソフトウェアアプリケーションからの「アプリケーションのシャットダウン準備完了」通知を完全に無視すること、またはそのようなソフトウェアアプリケーションが「アプリケーションのシャットダウン準備完了」通知を提供しないことも考えられる。同じ理由から、マネージャＳＨＭ１はステップ５０４において、サブシステムからの「サブシステムのシャットダウン準備完了」通知を完全に無視すること、またはそのようなサブシステムが「サブシステムのシャットダウン準備完了」通知を提供しないことも考えられる。
【0090】
方法５０２’および５０３’のそれぞれは、それぞれのサブシステムＳＳ１～ＳＳ４の確定的シャットダウンを確実にし、電力が切断されたときに進行中の必然的なアクティビティを有するリスクを軽減する。
【0091】
さらなる変形例ではセカンダリサブシステムＳＳ２～ＳＳ４内のソフトウェアアプリケーションのみが、それぞれのマネージャＳＨＭ２～ＳＨＭ４から「サブシステム準備未完了」通知を受信し、「アプリケーションのシャットダウン準備完了」通知を提供するように構成されるのに対し、プライマリサブシステムＳＳ１内のソフトウェアアプリケーションはそうではない。
【0092】
方法５０２’および／または５０３’は対象者の健康リスクを低減する役割を果たすことができる一方、医療デバイスのシャットダウン中に患者の安全性をさらに改善する必要がある場合がある。図５Ｄに例示される一実施形態では、ゲートキーピング方法５２０は、プライマリサブシステムＳＳ１がステップ５０１でシャットダウンを開始することを許可される前に、ソフトウェアシステムによって実行される。ゲートキーピング方法５２０において、各クリティカルソフトウェアアプリケーションはそのようなシャットダウンが患者の安全性を損なうとみなされる場合、ソフトウェアシステムのシャットダウンをブロックする「拒否電力」を与えられる。ステップ５２１において、プライマリサブシステムＳＳ１のマネージャＳＨＭ１はシャットダウンコマンドについて通知された後、クリティカルソフトウェアアプリケーション、例えば、図３の例におけるＳＷ１ｃおよびＳＷ３ｃに「シャットダウン要求」を提供することに進む。ステップ５２２において、各クリティカルソフトウェアアプリケーションＳＷ１ｃ、ＳＷ３ｃは「シャットダウン要求」を検証する。この検証ではそれぞれのクリティカルソフトウェアアプリケーションＳＷ１ｃ、ＳＷ３ｃはシャットダウンが受け入れ可能であるかどうかを、所定のシャットダウン基準以上に基づいて評価することができる。そのようなシャットダウン基準の１つは、患者の安全性であり得る。一例では、シャットダウンが医療処置またはそれらのサブ処置が完了するまで、受け入れられないとみなされてもよい。別の例では、較正手順が完了するまで、シャットダウンは受け入れられないとみなされてもよい。別の例では、重要なソフトウェアアプリケーションが安全な動作状態、例えば、サービスモード、アイドルモードなどにない限り、シャットダウンは受け入れられないとみなされてもよい。ステップ５２３において、それぞれのソフトウェアアプリケーションＳＷ１ｃ、ＳＷ３ｃはステップ５２２においてシャットダウンが受け入れ可能であるとみなされる場合にのみ、「アプリケーションのシャットダウン準備完了」通知を提供する。任意選択で、ステップ５２４において、それぞれのクリティカルソフトウェアアプリケーションＳＷ１ｃ、ＳＷ３ｃは次に、制御された状態に入ることができる。このコンテキストにおいて、「制御された状態」はクリティカルソフトウェアアプリケーションＳＷ１ｃ、ＳＷ３ｃが例えば、ポンプ速度を低下させること、ポンプを停止させること、弁を開閉すること、ヒータをオフにすることなどによって、患者の安全性を考慮して設定された制御パラメータ値に従って動作することを意味する。ゲートキーピング方法５２０は次に、ステップ５０１に進み、マネージャＳＨＭ１はクリティカルソフトウェアアプリケーションＳＷ１ｃ、ＳＷ３ｃのすべてから「アプリケーションのシャットダウン準備完了」通知を取得した場合にのみ、「シャットダウン」通知を提供することに進む。
【0093】
ゲートキーピング方法５２０は例えば、オペレータがオン／オフボタンを押すことによって、進行中の医療処置中に医療デバイスが意図せずにシャットダウンされることを防止する。上述のタイマはゲートキーピング方法５２０には実装されず、この手段、各々のクリティカルソフトウェアアプリケーションはシャットダウンプロセスに対して真の拒否権を有し、これは、クリティカルソフトウェアアプリケーションが「アプリケーションのシャットダウン準備完了」通知を提供しない限り、ステップ５０１で停止されることに留意されたい。このような状況では、ステップ５０１が、オーバーライドシャットダウン手順が開始されるべきであることの確認をオペレータに問うことをさらに伴うことが考えられる。確認されると、クリティカルソフトウェアアプリケーションは、制御された状態に設定され、そこで、図５Ａの方法５００に従ってシャットダウンが進行する。
【0094】
以下では、上述の実施形態およびさらなる実施形態を、図７Ａ～７Ｅおよび図８Ａ～８Ｃのシーケンス図を参照して例示する。図７Ａ～７Ｅは、図６の遷移Ｉａ、Ｉｂ、ＩＩ、およびＩＩＩのそれぞれについての方法に分割された、医療デバイスの起動中に実行されるステップのシーケンスを示す。図８Ａ～８Ｃは、図６の遷移ＩＶ、Ｖ、およびＶＩのそれぞれについての方法に分割された、医療デバイスのシャットダウン中に実行されるステップのシーケンスを示す。以下の説明ではエラー処理について簡単に説明するが、図示された一連のステップは起動およびシャットダウンがエラーなしに行われることを前提としている。
【0095】
図７Ａはサブシステム開始中に実行される方法を示し、図６の遷移Ｉａに対応する。図７Ａのサブシステム開始は、セキュアブートがＳＳ１で実行され、ＳＨＭ１がＳＳ１についてプログラムバイナリをチェックしたと仮定する。ステップ７０１ではブート中に、ＳＨＭ２、ＳＨＭ３、およびＳＨＭ４はそれぞれＳＳ２、ＳＳ３、およびＳＳ４のためのそれぞれのプログラムバイナリを確認する。ステップ７０１におけるチェックがＳＳ２～ＳＳ４のいずれかについて失敗した場合、これは、後続のステップ７１２（図７Ｂ参照）においてＳＳ１によって検出される。ステップ７０２において、ＳＨＭ１～ＳＨＭ４の各々はそれぞれのハードウェアウォッチドッグのキックを開始し、これは、当業者に周知のように、それぞれのウォッチドッグタイマが再開されることを手段する。ステップ７０３において、ＳＨＭ１～ＳＨＭ４は、ＳＳ１～ＳＳ４のソフトウェア及びハードウェアバージョンをそれぞれ識別する。ステップ７０４ではＳＨＭ１及びＳＨＭ３のそれぞれがシャットダウン理由パラメータを「エラー」に設定し、不揮発性メモリ（図２のＭ１～Ｍ２参照）に格納する。その後のシャットダウンがエラーなく行われた場合、シャットダウン理由パラメータは代わりに「正常」に設定され、格納される（図８Ｃのステップ８２６参照）。「エラー」をデフォルトとして格納する理由は、起動中に検出された誤ったシャットダウンを保証するためである。これにより、例えば電源喪失により引き起こされる意図しない急激なシャットダウンの事象であっても、シャットダウン理由パラメータは「エラー」として格納される。ステップ７０４は、ＳＨＭ１及びＳＨＭ３がシャットダウン理由パラメータの格納値の初期チェックを行うことを伴うことがある。ＳＨＭ１（又はＳＨＭ３）によるチェックが値「エラー」という結果になった場合、ＳＨＭ１（又はＳＨＭ３、又はその両方）は、ＳＨＭ１（又はＳＨＭ３、又はその両方）がシャットダウン前に残された場所から復旧することを可能にする復旧モードに入ってもよい。図示の例では、ステップ７０４がクリティカル・サブシステムＳＳ１およびＳＳ３によってのみ実行される。しかしながら、ステップ７０４は、ＳＳ２及び／又はＳＳ４の回復が必要とされるか又は望ましい程度まで、クリティカルソフトウェアアプリケーションを含まないＳＳ２及び／又はＳＳ４に対しても実行されることが考えられる。
【0096】
ステップ７０４の後、ＳＳ１～ＳＳ４は遷移Ｉｂに進む。図７Ａに示すように、ＳＳ１の遷移ＩＩは、遷移Ｉｂと並行して実行されてもよい
【0097】
図７Ｂはシステム開始中に実行される方法を示し、図６の遷移Ｉｂに対応する。ステップ７１０において、ＳＨＭ１～ＳＨＭ４はそれぞれの通信モジュールＩＳＣ１～ＩＳＣ４（図３参照）を開始し、ＳＨＭ１は、ステップ７１１～７１２を繰り返し実行して、接続要求を提供し（ステップ７１１）、確立された接続の確認を受信する（ステップ７１２）ことによって、ＳＳ２、ＳＳ３およびＳＳ４の各々への接続を確立する。接続が確立できない場合、ＩＳＣ１は、システムにエラーを報告することができる。接続が確立されると、ＳＨＭ１は、ステップ７１３～７１４を繰り返し実行して、バージョン要求を提供し（ステップ７１３）、バージョンデータを受信することによって、ＳＨＭ２、ＳＨＭ３、およびＳＨＭ ４からソフトウェアおよびハードウェアバージョンを取得する。バージョンデータは、それぞれのソフトウェアおよびハードウェアバージョンの識別情報を含むことができる。バージョンデータが受信されない場合、ＳＨＭ１は、システムにおけるエラーを報告し得る。バージョンデータを受信すると、ＳＨＭ１はソフトウェアバージョンの互換性を互いにチェックし（ステップ７１５）、ソフトウェアバージョンとハードウェアバージョンとの互換性をチェックする（ステップ７１６）。たとえば、ＳＨＭ１ は、ＳＳ１ のソフトウェアバージョンとの互換性のために、ＳＳ２、ＳＳ３、ＳＳ４ のソフトウェアバージョンをチェックする。ステップ７１５またはステップ７１６が失敗した場合、またはその両方が失敗した場合、ＳＨＭ１は、システム内のエラーを報告することができる。
【0098】
ステップ７１６の後、ＳＳ１～ＳＳ４の各々は遷移ＩＩに続く。上述のように、ＳＳ１は、遷移Ｉｂと並行して遷移ＩＩを実行することができる。
【0099】
図７Ａ～７Ｂの方法は例えば、異なるサブシステム内のソフトウェアバージョンが互換性がない、および／またはハードウェアとソフトウェアが一致しない、および／またはプログラムバイナリがＳＳ２～ＳＳ４のいずれか１つで破損し、そのすべてが医療デバイスの未定義の挙動をもたらす可能性があるというリスクを軽減するのに役立つ。
【0100】
図７Ａ～７Ｂのシーケンス図は、医療デバイスの起動のための方法がサブシステムのそれぞれにおいてマネージャを起動するステップと、マネージャによって、サブシステム（ＳＳ１～ＳＳ４）のそれぞれにおける通信モジュールを起動するステップと、プライマリサブシステムの通信モジュールによって、それぞれのセカンダリサブシステムにおける通信モジュールとの接続を確立するステップとを含む実施形態を例示することが分かる。
【0101】
図７Ａ～７Ｂのシーケンス図はまた、医療デバイスの起動のための方法が、プライマリサブシステムのマネージャによって、サブシステムに含まれるソフトウェアのソフトウェア識別情報を取得することと、プライマリサブシステムのマネージャによって、ソフトウェア識別情報に基づいてソフトウェアの互換性を検証することとを含む実施形態を例示することが分かる。
【0102】
図７Ａから図７Ｂのシーケンス図はまた、医療デバイスの起動方法が、プライマリサブシステムのマネージャによって、サブシステムによって使用されるハードウェアのハードウェア識別情報を取得することと、プライマリサブシステムのマネージャによって、ハードウェア識別情報とソフトウェア識別情報に基づいて、ハードウェアとソフトウェアとの間の互換性を検証することとを含む実施形態を例示するために見られることができる。
【0103】
図７Ｃはサブシステム起動中にＳＳ１によって実行される方法を示し、図６の遷移ＩＩに対応する。図７Ｃでは、ＳＳ１の個々のソフトウェアアプリケーションが一般にＳＷ１ｘとして表される。説明の目的のためだけに、図７Ｃはまた、ＧＵＩを明示的に示しており、これはディスプレイ上のグラフィカルな視覚化を担い、ユーザ入力を管理するソフトウェアアプリケーションである。ＧＵＩはユーザインタラクションの迅速な開始を保証するために、ＳＳ１内に配置されることが好ましい。ステップ７２０において、ＳＨＭ１は、ＧＵＩおよび各ＳＷ１ｘに起動要求を与える（ステップ４０１参照）。ステップ７２１では、起動要求を取得した後、ＧＵＩと各ＳＷ１ｘが内部起動を行う。いくつかの実施形態では、内部起動が同じサブシステムの他の部分、すなわち、同じサブシステム内のソフトウェアアプリケーションまたはプロセス間の通信のために、通信のためのソフトウェアアプリケーションを準備することを含む。ステップ７２２において、ＧＵＩ及び各ＳＷ１ｘは起動の準備ができたとき、それぞれの「アプリケーション準備完了」通知、Ｎ１（ステップ４０２参照）を提供する。この通知はソフトウェアアプリケーションが同じサブシステムの他の部分と通信する準備ができていることを示すことができる。ステップ７２３において、ＳＨＭ１はＧＵＩからのＮ１及び各ＳＷ１ｘを待つ。ＳＨＭ１がタイムアウト期間内にＮ１を受信しない場合、ＳＨＭ１はシステム内のエラーを報告することができる。ステップ７２４において、ＳＨＭ１はＧＵＩ及び各ＳＷ１ｘが起動の準備ができていることを決定する。すなわち、それらが「アプリケーション準備完了」通知を提供したときステップ７２５において、ＳＨＭ１は「準備完了」通知、Ｎ２を、ＧＵＩ及び各ＳＷ１ｘに提供する（ステップ４０３参照）。ステップ７２６において、Ｎ２を受信した後、ＧＵＩおよび各ＳＷ１ｘは、ＳＳ１内で互いに通信を可能にする（ステップ４０４参照）。これは、ＳＳ１ 内の別のソフトウェアアプリケーションとデータをやり取りするように構成されている任意のソフトウェアアプリケーションがＮ２ を待ってからデータ交換を開始することを意味する。しかしながら、それぞれのソフトウェアアプリケーションの他の機能は、ステップ７２６の前におよび／または後に起動されてもよい。例えば、ＧＵＩは、ステップ７２６で可能な限り早くユーザインタラクションを可能にするように構成されてもよい。しかしながら、いくつかの実施形態では、ソフトウェアアプリケーションの１つ以上（またはすべて）がＮ１を提供した後、それらの内部起動を一時停止し、Ｎ２を待ってから、それらの内部起動を継続するように構成される。さらに、ＧＵＩおよび各ＳＷ１ｘは、ステップ７２６の前後どちらか一方で、ステップ７２７の前の任意のイベントで、ＳＳ１内で内部心拍を送信するために起動される。ステップ７２７において、ＳＨＭ１はＧＵＩおよび各ＳＷ１ｘが動作可能であることを保証するために、ＳＳ１内の内部心拍のモニタリングを開始する。ステップ７２７の後、ＳＳ１は状態「準備完了」にあり、遷移ＩＩＩに進む。
【0104】
図７Ｄはサブシステム起動中にＳＳ２～ＳＳ４によって実行される方法を示し、図６の遷移ＩＩに対応する。図７Ｄでは、ＳＳ２～ＳＳ４の個々のソフトウェアアプリケーションが一般に、それぞれＳＷ２ｘ～ＳＷ４ｘとして表される。図７Ｄのステップ７２０～７２７は、ＳＳ１に代えてＳＳ２～ＳＳ４内で実行されるという違いはあるが、図７Ｃのステップ７２０～７２７に対応する。さらに、いくつかの実施形態では図７Ｃの方法とは対照的に、ＳＨＭ２～ＳＨＭ４はＮ１がタイムアウト期間内に受信されない場合、システム内でエラーを報告することを控えることができる。その代わりに、Ｎ１の非存在はＮ２が生成されないことを意味するので、このエラーはシステム起動中にＳＨＭ１によって検出することができ、具体的にはステップ７３０（図７Ｅ参照）である。図７Ｃの説明を考慮すると、図７Ｄによるサブシステム起動は自明であるべきであり、本明細書ではこれ以上説明しない。ステップ７２７の後、ＳＳ２～ＳＳ４は状態「準備完了」にあり、遷移ＩＩＩに進む。
【0105】
図７Ｃ～７Ｄの方法は例えば、他のソフトウェアアプリケーションが通信の準備ができていないときに、ソフトウェアアプリケーションがサブシステム内の別のソフトウェアアプリケーションと通信を開始するリスクを軽減するのに役立つ。この状況では他のソフトウェアアプリケーションは受信要求を受信または処理できないが、要求を通信するソフトウェアアプリケーションはこの不能を認識できない。
【0106】
図７Ｃ～７Ｄのシーケンス図は、起動中および各サブシステムについて、医療デバイスの起動のための方法がソフトウェアアプリケーションを動作させて内部心拍信号を送信するステップと、マネージャによって、ソフトウェアアプリケーションのうちの１つまたは複数の動作不良を検出するために内部心拍信号をモニタし始めるステップとを含む実施形態を例示するものと見ることができる。
【0107】
図７Ｅはシステム起動中に実行される方法を示し、図６の遷移ＩＩＩに対応する。図７ＥではＳＨＭ１～ＳＨＭ４およびクリティカルソフトウェアアプリケーションＳＷ１ｃおよびＳＷ３ｃのみが示されている一方、ＳＳ１～ＳＳ４の任意の他のソフトウェアアプリケーションは省略されている。ステップ７３０において、ＳＳ２～ＳＳ４がレディであるとき、ＳＨＭ１～ＳＨＭ３は、「準備完了」通知Ｎ２を提供することによって、それをＳＨＭ１に報告する。実際には、ステップ７３０は図７Ｄのステップ７２５に置き換えることができ、したがって、それぞれのサブシステムＳＳ１～ＳＳ４の内部および外部の両方にＮ２を提供する。ステップ７３１において、ＳＨＭ１は、ＳＨＭ２～ＳＨＭ４の全てからのＮ２を待つ。ＳＨＭ１がタイムアウト期間内にＮ２を受信しない場合、ＳＨＭ１は、システム内にエラーを報告することができる。ステップ７３２において、ＳＨＭ１は、全てのＳＳ１～ＳＳ４が起動の準備ができていると決定する（図４Ａのステップ４０５参照）。ＳＨＭ１は、この段階で、ＳＳ１が図７Ｃの遷移ＩＩを完了しているので、起動の準備ができていることをデフォルトで分かっていることに留意されたい。ステップ７３３において、ＳＨＭ１は、システムが起動の準備ができていることをＳＳ１内の全てのソフトウェアアプリケーションに通知する。ステップ７３４において、ＳＨＭ１は、システム内で外部心拍の送信を開始する。ステップ７３５において、ＳＨＭ１はＳＨＭ２～ＳＨＭ４による受信のために「システム準備完了」通知Ｎ３を提供する（図４Ｂのステップ４０６参照）ステップ７３６において、Ｎ３を取得した後（図４Ｂのステップ４０７参照）、ＳＨＭ２～ＳＨＭ４の各々はそのソフトウェアアプリケーションの全てに状態「システム準備完了」を通知する。ステップ７３７において、ＳＨＭ２～ＳＨＭ４の各々は、システム内で外部心拍の送信を開始する。ステップ７３８において、ＳＨＭ２～ＳＨＭ４の各々は、ＳＨＭ１による受信のための確認通知を提供する。ＳＨＭ１がタイムアウト期間内に確認通知を受信しない場合、ＳＨＭ１は、システム内にエラーを報告することができる。ステップ７３９において、ＳＨＭ２～ＳＨＭ４の全てから確認通知を受信した後、ＳＨＭ１は、システム内の外部心拍のモニタリングを開始する。ステップ７３７の後、いつでも、ＳＳ１～ＳＳ４の各々におけるソフトウェアアプリケーションは、ＳＳ１～ＳＳ４間の確立された通信経路上で、一つ以上の他のサブシステム（図４Ｂのステップ４０８を参照）におけるソフトウェアアプリケーションとのアプリケーションレベル通信を開始することが許容されている（図３を参照）。
【0108】
図７Ｅの例は、クリティカルソフトウェアアプリケーションＳＷ１ｃおよびＳＷ３ｃに関連してのみ実行され、ＳＷ１ｃおよびＳＷ３ｃのそれぞれが他のサブシステム内のソフトウェアアプリケーションと通信することを許可される前に完了される必要があるステップ７４０～７４１をさらに含む。ステップ７４０において、ＳＷ１ｃ／ＳＷ３ｃは、ＳＨＭ１／ＳＨＭ３に「システム準備完了」状態の確認を要求する。ステップ７４１において、ＳＨＭ１／ＳＨＭ３は、状態をＳＷｃ１／ＳＷ３ｃに確認する。これは、患者の安全性を損なう可能性がある誤動作に対するさらなるレベルのロバスト性を提供する。
【0109】
さらなるレベルのロバスト性を提供するために、クリティカルサブシステムＳＳ３のステップ７３７は、他のクリティカルサブシステムＳＨＭ１によって生成された外部心拍をモニタし始めるＳＨＭ３もまた伴うことが考えられる。これにより、クリティカルサブシステムＳＳ１、ＳＳ３間で心拍の相互モニタリングが確立され、サブシステムが他のクリティカルサブシステムの動作不良を迅速に検出し、適切な処置を取ることが可能になる。
【0110】
図７Ｅの方法は例えば、１つのサブシステム内の第１のソフトウェアアプリケーションが、別のサブシステム内の第２のソフトウェアアプリケーションが通信の準備ができていないときにそれと通信し始めるリスクを軽減する役割を果たす。この状況では、第２のソフトウェアアプリケーションは入ってくる要求を受信または対処できず、第１のソフトウェアアプリケーションは受信側で問題を認識できない。
【0111】
図７Ｅのシーケンス図は、医療デバイスの起動のための方法が外部心拍信号を送信するためにそれぞれのセカンダリサブシステムのマネージャを動作させることと、プライマリサブシステムのマネージャによって、１つまたは複数のセカンダリシステムの動作不良を検出するための外部心拍信号をモニタすることを開始することとを含む実施形態を例示するように見ることができる。
【0112】
図７Ｅのシーケンス図はまた、医療デバイスの起動のための方法が外部心拍信号を送信するために２つ以上のクリティカルサブシステムのマネージャのそれぞれを動作させることと、動作不良の検出のために、クリティカルサブシステムのマネージャ間で外部心拍信号を相互にモニタし始めることとを含む実施形態を例示することが分かる。
【0113】
さらに、図７Ｃ～７Ｅのシーケンス図は医療デバイスの起動のための方法が起動中に、「アプリケーション準備完了」通知Ｎ１が第１の所定の期間内にプライマリサブシステムのソフトウェアアプリケーションから受信されないときに、プライマリサブシステム内のマネージャによって第１のエラーを報告することと、「サブシステム準備完了」通知Ｎ２が第２の所定の期間内にセカンダリサブシステムから受信されないときに、プライマリサブシステム内のマネージャによって第２のエラーを報告することとを含む実施形態を例示するように見ることができる。
【0114】
図８Ａはシステムシャットダウン中に実行される方法を示し、図６の遷移ＩＶに対応する。この方法の開始時に、ソフトウェアシステムが立ち上がり、実行中であり、したがって図６のステータス「システム準備完了」にあると仮定するが、図示の例はＳＷ３ｃがＳＨＭ１に「シャットダウンゲートキーパ」として登録されており、これにより「シャットダウン」要求の加入者であるとも仮定する。ステップ８０１において、オペレータは、例えば制御ボタンを押すことによって、医療装置をシャットダウンするコマンドを入力する。コマンドは、ＳＨＭ１ による受信のシャットダウン要求を提供するＧＵＩ によって検出される。ステップ８０２において、ＳＨＭ１は、ＳＷ１ｃによる受信のためにシャットダウン要求Ｒ１を転送する。ステップ８０３において、ＳＷ１ｃはＲ１を検証する。ステップ８０４において、検証が成功した後、ＳＷ１ｃはＲ１をＳＷ３ｃに提供する。ステップ８０５において、ＳＷ３ｃはＲ１を検証する。検証が成功した後、ＳＷ３ｃは、制御状態に入り（ステップ８０６）、ＳＷ１ｃによる受信のために、「アプリケーションのシャットダウン準備完了」通知Ｎ７を提供する（ステップ８０７）。Ｎ７を受信した後、ＳＷ１ｃは、制御状態に入り（ステップ８０８）、Ｎ７をＳＨＭ１に転送する（ステップ８０９）。Ｎ７を受信した後、ＳＨＭ１は、システムシャットダウンを進める。ステップ８０３で検証が失敗した場合、および／またはステップ８０９でＳＨＭ１がタイムアウト期間内にＮ７を受信しない場合、ＳＨＭ１は、「シャットダウン未承認」通知をＧＵＩに返し、ＧＵＩはそれに応じてオペレータに報知することができる。
【0115】
ステップ８０２～８０９の組合せは、図５Ｄのゲートキーピング方法５２０に対応し、Ｒ１もＮ７も、ＳＨＭ１とそれぞれのクリティカルソフトウェアアプリケーションＳＷ１ｃ、ＳＷ３ｃとの間の直接通信で提供される必要はなく、送信のチェーンで中継され得ることを示す。したがって、図５Ｄと図８Ａを比較すると、ステップ５２１はステップ８０２および８０４に対応し、ステップ５２２はステップ８０３および８０５に対応し、ステップ５２３はステップ８０７および８０９に対応し、ステップ５２４はステップ８０６および８０８に対応する。変形例では、Ｎ７が送信チェーンで中継されず、ＳＷ３ｃからＳＨＭ１に直接提供される。
【0116】
ステップ８１０において、ＳＨＭ１は、ＳＳ２～ＳＳ４とのアプリケーションレベル通信を停止することによって、そのステータスを「システム準備未完了」に更新する。ステップ８１１において、ＳＨＭ１は外部心拍、すなわちＳＳ２～ＳＳ４により生成された心拍のモニタリングを停止する。ステップ８１２において、ＳＨＭ１は、ＳＨＭ２～ＳＨＭ４による受信のために、「シャットダウン」通知Ｎ４を提供する（図５Ａのステップ５０１参照）。ステップ８１３において、Ｎ４を受信した後、ＳＨＭ２～ＳＨＭ４の各々は、他のサブシステムとのアプリケーションレベル通信を停止することによって、そのステータスを「システム準備未完了」に更新する。ステップ８１４において、ＳＨＭ２～ＳＨＭ４の各々は、外部心拍の送信を停止する。ソフトウェアシステムがクリティカルサブシステム間で上記の相互心拍モニタリングを実施する場合、ＳＳ３におけるステップ８１４はまた、ＳＨＭ３にＳＨＭ１によって生成される外部心拍のモニタリングを停止させることもできる。ステップ８１５において、ステップ８１３～８１４の完了後、ＳＨＭ２～ＳＨＭ４の各々はＳＨＭ１による受信のための「確認」通知Ｎ５を提供する。Ｎ５は、それぞれのサブシステムＳＳ２～ＳＳ４がＮ４を受信したことをＳＨＭ１に知らせる。ステップ８１６において、Ｎ５を受信した後、ＳＨＭ１は外部心拍の送信を停止する。ＳＨＭ１がタイムアウト期間内にすべてのＳＳ２～ＳＳ４からＮ５を受信しない場合、ＳＨＭ１は、システム内にエラーを報告することができる。
【0117】
図８Ａの方法は、例えば、医療デバイスが医療処置を実行している間に、特に医療処置の中断が患者の安全性を損なう可能性がある場合に、医療デバイスがオペレータ主導でシャットダウンされるリスク、並びに１つのクリティカルサブシステムまたはソフトウェアアプリケーションが終了の準備をし、別のクリティカルサブシステムまたはソフトウェアアプリケーションが行わないリスクを軽減する役割を果たす。例えば、患者の安全性は、医療処置が継続されている間に上述の保護システムが停止する場合に危うくされる。
【0118】
図８Ａのシーケンス図は医療デバイスのシャットダウンのための方法が「シャットダウン」通知Ｎ４をセカンダリサブシステムに提供する前に、プライマリサブシステムのマネージャによって、クリティカルソフトウェアアプリケーションのチェーン内の第１のクリティカルソフトウェアアプリケーションのためのシャットダウン要求Ｒ１を提供し、それによって、チェーン内のクリティカルソフトウェアアプリケーションのそれぞれに、医療デバイスの操作を考慮してシャットダウン要求Ｒ１を検証させ、シャットダウンが受け入れ可能である場合にはチェーン内の最終クリティカルソフトウェアアプリケーションによってシャットダウン要求Ｒ１が受信されるまで、チェーン内の後続のクリティカルソフトウェアアプリケーションのためのシャットダウン要求Ｒ１を提供させ、チェーン内の最終クリティカルソフトウェアアプリケーションは医療デバイスの操作を考慮してシャットダウン要求Ｒ１を検証し、シャットダウンが受け入れ可能である場合には「アプリケーションのシャットダウン準備完了」通知Ｎ７をプライマリサブシステムのマネージャに提供させる、実施形態を例示することが分かる。シャットダウン要求Ｒ１のそのような条件付きおよび順次検証は、ゲートキーピング方法のロバスト性を改善する役割を果たすことができる。
【0119】
図８Ａのシーケンス図はまた、医療デバイスのシャットダウンのための方法であって、「アプリケーションのシャットダウン準備完了」通知Ｎ７が、クリティカルソフトウェアアプリケーションのチェーンに沿ってプライマリサブシステムのマネージャに中継される実施形態を例示することが分かる。
【0120】
また、図８Ａのシーケンス図は、チェーン内のクリティカルソフトウェアアプリケーションの各々が「アプリケーションのシャットダウン準備完了」通知Ｎ７を受信すると、医療デバイスが所定のパラメータ値のセットに従って動作する制御状態に入る実施形態を例示することが分かる。
【0121】
図８Ｂはサブシステムシャットダウン中に実行される方法を示し、図６の遷移Ｖに対応する。図８Ｂの方法は、「シャットダウン」通知Ｎ４を受信した後に（図８Ａのステップ８１２）いつでもＳＳ１～ＳＳ４の各々によって実行されてもよい。ステップ８２０において、ＳＨＭ１～ＳＨＭ４の各々は内部心拍のモニタリングを停止する。ステップ８２１において、ＳＨＭ１～ＳＨＭ４の各々はそのソフトウェアアプリケーションのために「サブシステム準備未完了」通知Ｎ６を提供する（図５Ｂ～５Ｃのステップ５０５参照）。ステップ８２２において、Ｎ６を受信した後に、ソフトウェアアプリケーションはそれぞれのサブシステム内で、終了の準備をし、通信を停止する（図５Ｂ～５Ｃのステップ５０６～５０７参照）。ステップ８２４において、それぞれのソフトウェアアプリケーションＳＷ１ｘ～ＳＷ４ｘは終了のために準備されると、そのマネージャＳＨＭ１～ＳＨＭ４のために「アプリケーションのシャットダウン準備完了」通知Ｎ７を提供する（図５Ｂ～５Ｃのステップ５０８参照）。選択的に図８Ｂのステップ８２３によって示されるように、Ｎ７はマネージャＳＨＭ１～ＳＨＭ４からの確認要求に応答して送信することができる。ステップ８２５において、ＳＨＭ１～ＳＨＭ４の各々は、そのソフトウェアアプリケーションの全てからのＮ７を待つ。ＳＨＭ１～ＳＨＭ４のいずれか１つが、タイムアウト期間内にそのソフトウェアアプリケーションのすべてからＮ７を受信しない場合、システム内にエラーを報告することができる。ステップ８２６において、ステップ８２５の完了後、クリティカルサブシステムＳＳ１、ＳＳ３内のＳＨＭ１およびＳＨＭ３はシャットダウン理由パラメータを「通常」に設定し、それを不揮発性メモリに格納し、ステップ８２７において、ＳＨＭ２～ＳＨＭ４の各々は、ＳＨＭ１に対して「サブシステムのシャットダウン準備完了」Ｎ８を提供する（図５Ｃのステップ５１０参照）。ソフトウェアシステムは、システム・レベルおよびサブシステム・レベルの両方で、電源喪失のために準備される。
【0122】
【0123】
図７Ａおよび図８Ｂのシーケンス図は、医療デバイスを動作させる方法がシャットダウン中にエラーがない場合に、マネージャのうちの少なくとも１つによって、通常のシャットダウンを示すシャットダウン理由パラメータを設定し、シャットダウン理由パラメータをメモリユニットのセットに記憶することを含む実施形態を例示することが分かる。さらに、本方法は起動中に、マネージャのうちの少なくとも１つによって、シャットダウン理由パラメータをシャットダウンエラーを示すように設定するステップと、シャットダウン理由パラメータをメモリユニットのセットに記憶するステップとを含むことができる。
【0124】
図８Ｃはソフトウェアシステムの実行終了時に実行される方法を示し、図６の遷移ＶＩに対応する。図８Ｃの方法は、ステップ８２７の完了後にＳＳ１～ＳＳ４の各々によって実行される。ステップ８３０において、ＳＨＭ１～ＳＨＭ４の各々はそれぞれのハードウェアウォッチドッグをキックし続けながら、電源喪失を待つ。ＳＳ１～ＳＳ４のいずれも、電源喪失なしにこの状態を離れることは不可能である。この段階で、システムを安全にシャットダウンすることができる。例えば、ＳＨＭ１はステップ８３０において、例えば、医療デバイスの電力マネージャのための「電力切断」通知を生成することによって、医療デバイスに電力を切断させることができる。
【0125】
本発明は現在最も実用的で好ましい実施形態であると考えられるものに関連して説明されてきたが、本発明は開示された実施形態に限定されるべきではなく、反対に、添付の特許請求の範囲の精神および範囲内に含まれる種々の変形および同等の構成を包含することが意図されることを理解されたい。
【図1A】
【図1B】
【図1C】
【図2】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図5C】
【図5D】
【図6】
【図7A】
【図7B】
【図7C】
【図7D】
【図7E】
【図8A】
【図8B】
【図8C】