(57)【要約】本発明は、血球を無菌的に処理するための、環境的に閉鎖された細胞処理装置に関する。装置は、連続フロー遠心分離機、流体リザーバ、および流体取扱いシステムを備える。血球は、それらの免疫優性抗原を取り除く目的で、本発明の装置によって処理される。血清変換細胞について、および被験者をこれら細胞で治療する方法についても説明する。【特許請求の範囲】
【請求項１】
以下を含む細胞処理装置：
a. 間隔の開いた複数の構造ディスクと複数の支持チューブとを有する構造フレームを有する連続フロー遠心分離機であって、
各端にベアリングおよび1つの端に駆動システムを有するローターであり、かつ、1つの端にポートをさらに含むハブとその中を通り各々が該ハブの壁表面を通るアパーチャで終端している複数のチャネルとを有する該ローターをさらに含む連続フロー遠心分離機；
b. 該ローターの軸に沿って配置された複数のチャンバーであって、
該ローターハブ上の該チャネルアパーチャのうち1つまたは複数と整列化したポートを有する実質的に可撓性の処理バッグと、該ローターハブ上の該チャネルアパーチャのうち1つまたは複数と整列化したポートを有する実質的に可撓性の絞り出し（expressor）バッグとを備えるチャンバー；
c. 経路と弁とのネットワークをさらに含む流体管理カセットを有する供給モジュールであって、
複数の流体および／または空気供給源にさらに接続され、かつ該弁がシステム制御モジュールに適合している供給モジュール；
d. 1つの端において該供給モジュールに接続されかつ他方の端において該遠心分離ローター上の該ハブに接続された多管腔チューブであって、
該遠心分離駆動システムに連動した支持チューブローラーおよび剛性アームによって支持されたチューブ；
e. 該供給モジュールと連絡している複数の供給リザーバ；ならびに
f. 該弁および該遠心分離駆動システムと電気通信しているシステム制御モジュールであって、
プロセッサ、命令セット、障害ハブシステム、およびユーザー定義の入力コントロールを有する制御モジュール。
【請求項２】
駆動システムが直接駆動モーターを使用する、請求項1記載の装置。
【請求項３】
遠心分離ローターが、該ローターより遠位の駆動プーリーおよびモーターに適合する、請求項1記載の装置。
【請求項４】
弁が、フロースルーウェルによって囲まれた突出形弁座を備える、請求項1記載の装置。
【請求項５】
供給リザーバのうち1つまたは複数が、緩衝溶液中のグリカン改変酵素分量を含む、請求項1記載の装置。
【請求項６】
グリカン改変酵素がα-N-アセチルガラクトサミニダーゼまたはα-ガラクトシダーゼである、請求項1記載の装置。
【請求項７】
緩衝溶液のpHが5.0〜8.0である、請求項5記載の装置。
【請求項８】
緩衝溶液のpHが6.0〜7.8である、請求項7記載の装置。
【請求項９】
緩衝溶液のpHが6.5〜7.5である、請求項7記載の装置。
【請求項１０】
緩衝溶液のpHが6.8〜7.5である、請求項7記載の装置。
【請求項１１】
緩衝溶液のpHが7.0〜7.3である、請求項7記載の装置。
【請求項１２】
以下の段階を含む、血球を改変する方法：
請求項1記載の装置の処理チャンバーに、単離された血球の調製物を導入する段階、ならびに、
該単離された血球を、α-N-アセチルガラクトサミニダーゼ酵素もしくはα-ガラクトシダーゼ酵素または両方の酵素の緩衝溶液と反応させ、これによって、該血球から免疫優性抗原を除去し、該酵素、緩衝溶液、および血球から除去された免疫優性抗原を遠心分離および洗浄の段階によって分離し、かつ該反応および洗浄された血球を単離する段階。
【請求項１３】
緩衝溶液のpHが5.0〜8.0である、請求項12記載の方法。
【請求項１４】
緩衝溶液のpHが6.0〜7.8である、請求項12記載の方法。
【請求項１５】
緩衝溶液のpHが6.5〜7.5である、請求項12記載の方法。
【請求項１６】
緩衝溶液のpHが6.8〜7.5である、請求項12記載の方法。
【請求項１７】
緩衝溶液のpHが7.0〜7.3である、請求項12記載の方法。
【請求項１８】
請求項12記載の細胞改変方法によって免疫優性抗原が除去された、血清変換血球。
【請求項１９】
標準的な血液型判定法によって決定されるような血清型A、B、またはABの細胞ではない、請求項18記載の血球。
【請求項２０】
請求項19に記載のパックされた血清変換血球の母集団。
【請求項２１】
以下の段階を含む、被験者を治療する方法：
輸血を必要とする被験者を同定する段階、ならびに、
請求項19の血清変換血球分量を該被験者に提供し、これによって該被験者の血液を回復させ、かつこれによって該被験者を治療する段階。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
以下の発明は、連続フロー遠心分離システムと、血液および血球の複数の別個の分量を独立して無菌処理するのに適した流体管理システムとを有する、血液処理システムの種々の局面に関する。
【背景技術】
【０００２】
背景
血液の型（またはタイプ）のシステムは30種を越えるシステムがあり、そのうち特に重要なもののひとつがABOシステムである。このシステムは、A抗原および／またはB抗原の有無に基づくものである。これら抗原は赤血球および血小板の表面に見られ、内皮細胞および大多数の上皮細胞の表面にも見られる。輸血に用いられる主要な血液製剤は、酸素の運搬を主たる機能とするヘモグロビンを含む赤血球である。A型の血液は赤血球上にA抗原を含む。同様に、B型の血液は赤血球上にB抗原を含む。AB型の血液は両方の抗原を含み、O型の血液はいずれの抗原も含まない。
【０００３】
血液型の構造は糖タンパク質または糖脂質であり、AおよびBの決定基または抗原を構成する特異的構造を同定するためかなりの研究が行われている。ABH式血液型の特異性は、炭水化物鎖の末端における単糖の性質および結合によって決定される。炭水化物鎖はペプチド（糖タンパク質）または脂質（スフィンゴ糖脂質）のバックボーンに付着し、このバックボーンが細胞の細胞膜に付着する。A型の特異性を決定する免疫優性単糖はα1-3結合した末端のN-アセチルガラクトサミン（GalNAc）であり、B型の特異性においてこれに相当する単糖はα1-3結合したガラクトース（Gal）である。O型の細胞はオリゴ糖鎖の末端にこれらいずれの単糖もなく、代わりに、α1-2結合したフコース（Fuc）の残基が末端にある。
【０００４】
ABH免疫優性糖類をもつオリゴ糖鎖に構造的変種があるため、血液型のABH炭水化物構造には広い多様性が見られる。本発明者らによる係属中の米国特許出願第11/049,271号（特許文献1）には、ヒトにおいて報告された構造、およびヒトの赤血球上または血液抽出物中で発見された構造が列挙されている。総説についてはClausenおよびHakomori, Vox Sang 56(1): 1-20, 1989（非特許文献1）を参照されたい。赤血球は、N-結合型の糖タンパク質およびスフィンゴ糖脂質上にABH抗原を含むが、グリコホリンを主とする赤血球糖タンパク質上のO-結合型グリカンは、ABH抗原ではなくシアル酸を末端とすると一般に考えられている。I型鎖のスフィンゴ糖脂質は赤血球の内因性産物ではなく、血漿から吸収される。
【０００５】
血液型AおよびBには複数の亜型がある。血液型Aの亜型は最も頻度が高く、A型の主な亜型として3つが認識されている。これらの亜型はA1型、A中間型（Aint）、A2型として公知である。これら3つの亜型を区別する、定量的および定性的な差異が存在する。定量的には、A1赤血球は、Aint赤血球より抗原性の高いA部位すなわち末端のN-アセチルガラクトサミン残基を有し、同様にこのAint赤血球は、A2赤血球より抗原性の高いA部を有する位が多い。定性的には、A1赤血球がスフィンゴ糖脂質のサブセット上に二重反復A構造をもつのに対し、A2赤血球は糖脂質の同様のサブセット上の内部A構造上にH構造をもつ（Clausen et al., Proc. Natl. Acad. Sci. USA 82(4): 1199-203, 1985（非特許文献2）, Clausen et al., J. Biol. Chem. 261(3): 1380-7, 1986（非特許文献3））。A1亜型と弱いA亜型との間のこれらの差異は、A抗原の形成を担う血液型Aのアイソザイム変種の動態特性の差異に関連すると考えられている（Clausen et al., J. Biol. Chem. 261(3): 1388-92, 1986（非特許文献4））。B型の亜型の差異は定量的な性質のみであると考えられている。
【０００６】
A型の血液はB抗原に対する抗体を含む。逆に、B型の血液はA抗原に対する抗体を含む。AB型の血液はいずれの抗体も含まず、O型は両方を含む。炭水化物により規定されるこれらおよびその他の血液型抗原に対する抗体は、関連する炭水化物構造をもつ微生物への継続的な曝露によって誘発されると考えられている。抗A抗体もしくは抗B抗体のいずれか（または両方）を含む血液の人は、対応する不適合抗原を含む血液の輸血を受けることができない。不適合型の血液の輸血を受けた場合は、輸血レシピエントの抗体が、輸血された不適合型の赤血球を覆って、輸血された赤血球を凝集させ、または膠着させる。その結果、輸血反応および／または溶血（赤血球の破壊）が生じることがある。
【０００７】
赤血球凝集、輸血反応、および溶血を回避するため、輸血の血液型は輸血レシピエントの血液型に対して交差試験が行われる。例えば、血液型A型のレシピエントには、適合する抗原を含むA型の血液を安全に輸血することができる。O型の血液はA抗原もB抗原も含まないため、任意の血液型のレシピエント、すなわち血液型がA型、B型、AB型、またはO型のレシピエントに安全に輸血することができる。そのためO型の血液は「万能」とされ、すべての輸血に用いることができる。したがって、血液バンクはO型の血液を大量に維持することが望ましい。しかしO型のドナーは少数である。したがって、万能な血液製剤を大量に維持するため、A型、B型、およびAB型の血液から免疫優性のA抗原およびB抗原を除去することは、望ましくかつ有用である。
【０００８】
病院は輸血のため恒常的な血液供給を必要とする。ドナーが血液を提供した後、地域の血液センターはABO式血液型判定、感染症検査、成分製造、および病院への赤血球分配の責任を負う。病院ではA型、B型、AB型、O型の血液型を再度検査し、使用できる血液単位を適切な患者に対して交差試験する。O型の血液は例外なく輸血できることから、一般的に、かつ特に血液型判定およびマッチングによる遅延が許容されない緊急の場面において、O型血液に対する高い需要がある。さらに、処理済血液は貯蔵寿命が42日と比較的短く、それ以後は輸血することができない。赤血球の在庫表のバランスを取ることは非常に複雑である。日常ベースにおいて、地域の血液センターは、異なる血液型に対する需要を、血液センターおよび周辺地域の顧客病院施設に保持されている利用可能な供給で満たさなければならない。供給と需要における毎日の変動に合わせるため、個々の血液単位はシステム内で恒常的に移動される。事実、個々の単位は、最終的に輸血されるまでにシステム内で3〜4回移動されることも多い。採取された各単位が確実に最終的に輸血されるよう関係者が最善の努力を払っても、採取された全単位の4％〜8%は輸血前に使用期限を超過し、廃棄を余儀なくされる。A型、B型、またはAB型の血液をO型の血液へと再生可能に変換するような処理システムは、この分野における非常に重要なニーズを満たすものと思われる。O型の血球の利用可能性は、赤血球の利用可能性を向上させ、42日間の使用期限（outdate window）内に単位をレシピエントと適合できないことによる赤血球の使用期限超過を実質的になくし、毎日の供給と需要に合わせるために血液単位を頻繁に再発送する必要性をなくし、かつ、血液型を再検査する必要性をなくすと思われる。
【０００９】
O型血液の供給を増やすための試みの中で、特定のA型、B型、およびAB型の血液をO型血液に変換するための方法が開発されている。B型の細胞からO型の細胞への変換は過去に達成されている。しかし、より豊富なA型の細胞の変換は、それほど豊富でない弱いA亜型の細胞で達成されたにすぎない。これまでのところ、酵素変換した万能O型細胞の開発および使用に対する主な障害としては、一部の酵素のコストおよび活性プロファイル、ならびに万能型のO型細胞を供給するための商用処理システムが不十分であることがある。当技術分野において、向上した血液処理システムに対するニーズが存続している。
【００１０】
【特許文献１】米国特許出願第11/049,271号
【非特許文献１】ClausenおよびHakomori, Vox Sang 56(1): 1-20, 1989
【非特許文献２】Clausen et al., Proc. Natl. Acad. Sci. USA 82(4): 1199-203, 1985
【非特許文献３】Clausen et al., J. Biol. Chem. 261(3): 1380-7, 1986
【非特許文献４】Clausen et al., J. Biol. Chem. 261(3): 1388-92, 1986
【発明の開示】
【００１１】
発明の概要
本発明は、細胞、特に血球、より特に赤血球を処理するための装置に関する。装置は、構造フレームを有し、かつ間隔の開いた複数の構造ディスクと複数の支持チューブとを有する連続フロー遠心分離機であって、各端にベアリングおよび1つの端に駆動システムを有するローターであり、かつ1つの端にポートをさらに備えるハブとその中を通り各々がハブの壁表面を通るアパーチャで終端している複数のチャネルとを有する該ローターをさらに備える連続フロー遠心分離機と；
ローターの軸に沿って配置された複数のチャンバーであって、ローターハブ上のチャネルアパーチャのうち1つまたは複数と整列化したポートを有する実質的に可撓性の処理バッグと、ローターハブ上のチャネルアパーチャのうち1つまたは複数と整列化したポートを有する実質的に可撓性の絞り出し（expressor）バッグとを備えるチャンバーと；
経路と弁とのネットワークをさらに含む流体管理カセットを有する供給モジュールであって、複数の流体および／または空気供給源にさらに接続され、かつ弁がシステム制御モジュールに適合している供給モジュールと；
1つの端において供給モジュールに接続されかつ他方の端において遠心分離ローター上のハブに接続された多管腔チューブであって、遠心分離駆動システムに連動した支持チューブローラーおよび剛性アームによって支持されたチューブと；
供給モジュールと連絡している複数の供給リザーバと；
弁および遠心分離駆動システムと電気通信しているシステム制御モジュールであって、プロセッサ、命令セット、障害ハブシステム、およびユーザー定義の入力コントロールを有する制御モジュールとを備える。1つの態様において、駆動システムは直接駆動モーターを使用する。別の態様において、遠心分離ローターはローターより遠位の駆動プーリーおよびモーターに適合する。さらに別の態様において、弁はフロースルーウェルによって囲まれた突出形弁座を備える。さらに別の態様において、供給リザーバのうち1つまたは複数は、緩衝溶液中のグリカン改変酵素分量を含む。またさらに別の態様において、グリカン改変酵素はα-N-アセチルガラクトサミニダーゼまたはα-ガラクトシダーゼであり、特に、中性またはその付近のpHにおいて実質的な生物活性を有するものである。種々の態様において、緩衝溶液はpH 5.0〜8.0であり、好ましくはpH 6.0〜7.8であり、より好ましくはpH 6.5〜7.5であり、さらにより好ましくはpH 6.8〜7.5であり、最も好ましくはpH 7.0〜7.3である。
【００１２】
別の局面において、本発明は、以下の段階を含む、血球を改変する方法を提供する：
請求項1記載の装置の処理チャンバーに、単離された血球の調製物を導入する段階、ならびに、
単離された血球を、α-N-アセチルガラクトサミニダーゼ酵素もしくはα-ガラクトシダーゼ酵素または両方の酵素の緩衝溶液と反応させ、これによって、血球から免疫優性抗原を除去し、抗原性改変した血球を遠心分離および洗浄の段階によって酵素、緩衝溶液、および酵素により切断された抗原フラグメントから分離し、かつ単離された血球を回収する段階。
特定の態様において、単離された改変細胞は次に、適切なヘマトクリットとなるよう緩衝生理食塩水または血漿（好ましくはO型）などの無菌血液保存緩衝液と混合され、かつ被験者（ヒトまたは動物）への最終的な輸血のため凍結または保存される。種々の態様において、緩衝溶液はpH 5.0〜8.0であり、好ましくはpH 6.0〜7.8であり、より好ましくはpH 6.5〜7.5であり、さらにより好ましくはpH 6.8〜7.5であり、最も好ましくはpH 7.0〜7.3である。
【００１３】
別の局面において、本発明は、前述の細胞改変方法によって免疫優性抗原が除去された、血清変換血球を提供する。1つの態様において、改変された血球は、標準的な血液型判定法によって決定されるような血清型A、B、またはABの細胞ではない。さらに別の局面において、本発明は、本明細書に説明する装置および方法を用いて調製された、パックされた血清変換血球の母集団を提供する。
【００１４】
別の局面において、本発明は、血液を必要とする被験者を治療する方法を提供する。被験者は哺乳動物であってもよく、好ましくは、一般的な血清型A、B、またはAB、さらにはOのうち任意のものを有するヒトである。被験者は、血清変換細胞、すなわち、輸血用に設計された細胞から免疫優性抗原を除去するよう処理された細胞分量を提供される。輸血された細胞は被験者の血液を回復させ、これによって疾患を治療する。
【００１５】
これらおよび他の特徴は当業者に明らかであると思われ、以下、添付の特許請求の範囲に関して、前述の内容を限定することなく本発明を説明する。
【００１６】
詳細な説明
本発明は、連続フロー遠心分離システムと流体管理システムとを有する血液処理システムであり、血液および血球の複数の個別の分量を独立無菌処理するのに適したシステムを提供する。本システムは、現時点での好ましい態様において、本発明者らによる係属中の米国特許出願第11/049,271号に記載の種々の酵素（例：グリカン改変ポリペプチド）および緩衝液とともに用いられて血球の免疫優性抗原を改変する、環境的に閉鎖された反応および処理機器を提供する。それにも関わらず、血液処理が現在の好ましい用途であり、その能力に関して本システムを言及するが、本システムは単に血液だけでなく広範の種々の流体および基質とともに用いてもよく、例えばポリペプチドの処理および消化、ポリヌクレオチドの処理および消化、組換え技術を含む微生物の培養に用いてもよい。このように本システムは、内蔵型のかつ自動式の遠心分離機および流体処理システムを必要とする使途に広範の用途を有する。そのような用途は、以下により詳細に示す本発明の種々の要素の説明から明らかになるものと思われる。
【００１７】
連続フロー遠心分離機
一般的に、細胞処理は、細胞または細胞要素が液相から分離される段階を必要とする。この分離は典型的に遠心分離によって実現される。したがって本発明は遠心分離機器を備え、より具体的には、カセット、ローター、または流体保持チャンバーと装置の軸に固定的に取り付けられた流体フローチューブ類（tubing）とを有するその他の装置と連動する遠心分離機を含む。
【００１８】
連続フロー遠心分離機として公知となった機構についての文脈において、ある長さのチューブ類が、遠心分離対象の流体材料を含む装置の回転軸に固定的に取り付けられている場合、チューブ類のねじれを回避するため、回転シールまたはその他何らかの手段を用いることによってチューブ類の全長が回転されなければならない。回転シールの使用を回避するための1つの周知の方法は、チューブ類の全長を軸から外方向へ、ならびにローターまたはカセットなどの周囲の外縁の周りへとカーブさせ、かつ、チューブ類をローター／カセット自体の回転速度の半分で軌道状の様式でローター／カセットの周りに回転させることである。そのような、チューブのねじれを排除するための方法およびそのための機器は、例えば米国特許第4,216,770号、同第4,419,089号、および同第4,389,206号に開示されている。
【００１９】
流体フローチューブ類を遠心分離回転の軸周囲に旋回させるそのような先行の機器に固有の問題は、回転軸が縦方向に配置されること、チューブ類が軸シャフトを通るように引き回されること、および機器が軸シャフトの駆動によって駆動されることである。このことは高い縦横比と長いシャフトとを必要とし、これは回転速度を制限し、機器を不安定にし、かつ機器のチャック構成部品の反対側に第二のカセットまたはローターなどを取り付けるユーザーのできることを制限する。
【００２０】
前述の内容に従い、米国特許第5,665,048号も参照する。同特許は、流体保持ハウジングの回転軸に固定的に接続された流体入出力チューブ類を有する流体保持ハウジングを回転させるための遠心分離機であって、
フレームと；回転軸を有する第一の回転機構であり、それと共回転するよう流体保持ハウジングがその上に同軸状に取り付けられた第一の回転機構と；回転軸を有する第二の回転機構とを含み、
第一および第二の回転機構はフレーム上に同軸状に取り付けられ；第二の回転機構は駆動機構と係合した外周表面を有し、駆動機構は第二の回転機構が選択された回転速度Xで回転するよう外周表面を駆動し；第一の回転機構は、2Xの回転速度で第二の回転機構と同時に回転するよう第二の回転機構に相互接続されている遠心分離機を提供する。
【００２１】
第二の回転機構は、流体保持ハウジングの軸から伸びる出力チューブ類の遠位の長さを保持するための座を備え、座によって保持される出力チューブ類の遠位の長さは第二の回転機構と同じ回転速度で回転軸周囲で回転される。このような配置に関連する問題の1つは、チューブ類と座との間に継続的な摩擦が生じることである。
【００２２】
したがって、本発明により、遠心分離機の改良、および流体チューブ類の支持による流体チューブ類に関する改良が提供される。本発明により、ハウジング内に保持された流体中に懸濁した1つまたは複数の選択された材料がハウジングの回転時に遠心分離されるよう、流体保持ハウジングを回転させるための遠心分離機が提供される。遠心分離機は、回転アクセスを有する第一の回転機構を備え、流体保持ハウジングは第一の回転機構と共回転するよう第一の回転機構に同軸状に取り付けられる。回転軸を有する第二の回転機構もまた提供され、第一および第二の回転機構は共通の軸の周囲で共回転するよう同軸状に相互接続される。流体保持ハウジングの軸に接続された流体チューブ類は、流体保持ハウジングから軸方向外向きに伸びる遠位の長さを有する。本発明の1つの態様により、改良は、第二の回転機構に取り付けられた支持アームと；流体チューブ類の遠位の長さの少なくとも一部を中に通して受けるための支持チューブと；支持アーム内で支持チューブを回転式に支持するためのベアリング部品であり、第一および第二の回転機構の回転時に、流体チューブ類とその支持との間の摩擦が最小となるよう、流体チューブ類が支持チューブとともにまたは支持チューブに対して自由に回転できるようなベアリング部品とを含む。
【００２３】
本発明の別の態様により、第一の流体収容機構と流体を受ける回転駆動ローターとの間で1つまたは複数の流体を送達するための複数の細長チューブを含む多管腔「スキップ」ロープが提供される。ロープの1つの端は駆動ローターの中心に取り付けられ、ロープの他方の端は第一の流体保持機構に取り付けられる。第一の流体保持機構は、ロープの他方の端の取り付け点がローターの軸と実質的に同軸になるように、ローターの反対側に取り付けられる。前述の細長チューブは、螺旋巻き状態に置かれた少なくとも1つのチューブを含んでいてもよい。この螺旋巻きは単ストランド巻きまたは複ストランド巻きのいずれかであってもよく、かつ、反時計周り方向または時計周り方向のいずれかであってもよい。かつまた、単ストランドまたは複ストランドにおいて、螺旋巻きが1つの端で時計回りでかつ他方の端で反時計回りであってもよく、かつ、任意でその間に直線状の部分を有していてもよい。スキップロープ流体送達システムの詳細は後述する。
【００２４】
図1A-1Bに、分割ドアに取り付けるための使い捨てシールを備えたバッグセットアセンブリの分解組立図を示す（分割ドアの各半分が離れて示された拡大図）。好適なバッグおよびバッグセット110については後述する。使い捨てシール105は片側でバッグセットと係合し、反対側で分割ドア115の片側と接触する。シール105はまた、各々がバッグセットの1つまたは複数のバッグに適合すなわち流体接触しているかまたは無菌空気の供給源に適合している複数の管腔122を含む多管腔スキップロープ120が通る中心部の開口部も備える（本発明者らの米国特許第7,008,366号を参照）。分割ドアはまた、多管腔ロープのための逃げ125も備えていてもよい。図1Bは分割ドアが閉位置になった状態の図1Aのアセンブリを示している。
【００２５】
図2A〜2Fは本発明の態様の1つに従う血液処理装置の遠心分離構成部品の概略図である。図に示すように、遠心分離機は、間隔の開いた複数の構造ディスク210と複数の支持チューブ215とを有するフレーム205を備える。この態様において、遠心分離機はまた、端に設けられモーターからの駆動ベルト（図には示していない）を受ける駆動プーリー220、および両端のベアリング225も備える。遠心分離機の中心には、1つまたは複数の可撓性処理チャンバーを収容するよう設計された（かつまた絞り出しチャンバーも備えていてもよい）バッグセットバケット230が提供される。
【００２６】
収集された細胞から除去された流体を絞り出す（すなわち排出を促す）手段を組み込んだ多数の装置が開発されている。絞り出しに関連した開示としては、KelloggおよびDrugerの米国特許第4,332,351号、KelloggおよびKrugerの米国特許第4,010,894号、JonesおよびKelloggの米国特許第4,007,871号、Jonesらの米国特許第3,737,097号、Polascheggの欧州特許第00265795/EP B1号、Cullisの米国特許第4,934,995号、Termanらの米国特許第4,223,672号、ならびにBayhamの米国特許第4,213,561号がある。本明細書における使途に好適な可撓性処理チャンバーの特に好ましい例としては、本発明者らの米国特許出願第20050143244号に記載のものがある。したがって本機器は、全体として、選択された体積の円形の遠心分離チャンバーを有し、制御可能な状態でモーター機構によって中心軸周囲に回転できる遠心分離ローターと；遠心分離チャンバー内に配置され中心回転軸に一致する回転軸と可撓性の壁とを有する円形の拡張可能式エンクロージャであり、流体容器は回転軸を有しかつ遠心分離チャンバー内で同軸状に受けることが可能であり、拡張可能式エンクロージャが流体容器内の選択された1つまたは複数の流体の各々の密度より大きくなるよう選択された密度を有する絞り出し流体の供給源に密閉可能式に接続されているような拡張可能式エンクロージャと；流体容器が遠心分離チャンバー内で受けることができるような状態で、選択された体積の絞り出し流体を拡張可能式エンクロージャに制御可能な状態で送出入させるためのポンプと；流体容器の可撓性の壁が拡張可能式エンクロージャの可撓性の壁と接触した状態で流体容器を遠心分離チャンバー内で同軸位置に保持するための保持機構とを備えるものとして説明できる。
【００２７】
拡張可能式エンクロージャは、好ましくは、遠心分離チャンバーが流体容器を受けるための第一のチャンバーと絞り出し流体を受けるための第二の流体シールチャンバーとに分割されるよう、ローターの表面に密閉可能式に取り付けられた可撓性の膜を含む。拡張可能式エンクロージャの可撓性の壁は典型的にエラストマーシート材料を含む。本機器は典型的に、絞り出し流体の温度を選択的に制御するための制御機構を有するヒーターまたは冷却機構をさらに備える。
【００２８】
拡張可能式エンクロージャに送入される絞り出し流体は、その高い密度のため、ローターが中心軸周囲で駆動式に回転された場合に流体容器内の1つまたは複数の選択された流体材料が移動する周辺位置より中心軸から放射方向にさらに外側の、拡張可能式エンクロージャ内の周辺位置まで移動する。
【００２９】
流体容器は典型的に第一の半径を有し、第二の流体シールチャンバーは典型的に、流体容器の第一の半径と少なくとも等しい第二の半径を有し、第二の流体シールチャンバーに送入される絞り出し流体は、ローターが中心軸周囲で駆動式に回転された場合に流体容器内の1つまたは複数の選択された流体材料が移動する周辺位置より中心軸から放射方向にさらに外側である、第二の流体シールチャンバー内の最も外側の周辺位置まで移動する。
【００３０】
図2Bにおいて、スキップロープ装填ドア235は開位置の状態で示されている。スキップロープ装填ドアは、スキップロープのための、第一の端部支持アーム240および第二の端部支持アーム245、ならびにそれらの間に位置する支持チューブ250を備える。さらに、遠心分離中に支持チューブが装置全体の回転に対して回転することを可能にする、4対の支持チューブローラー255も備えられる。
【００３１】
図2Cに、回転する支持チューブ260が端部ベアリングの中心を通って組み立てられた、バッグセット／スキップロープアセンブリを示す。図2Dに示すように、バッグセット110は、スキップロープアセンブリとともに、端部ベアリング225の中心を通って挿入されてもよい。図に示すように、バッグセットは端265を通って挿入され（図2C）、次にバッグセットバケット230の上を通ってこれを越えて、次に反対の端270からバッグセットバケット内に入る（図2D）。次に、（無論、装填ドアが開位置になっている間に）スキップロープアセンブリおよび支持チューブ260が、支持チューブローラーに隣接する適切な位置に位置決めされる（図2Eを参照）。次に装填ドアが閉じられ（図2F）、スキップロープの端がベアリング中心の開口部を通って突出する。
【００３２】
流体管理システム
本発明は、処理される細胞の種類または細胞の量に基づいて処理アルゴリズムを調整できる細胞処理システムを提供する。さらに本発明は、処理量または処理場所にかかわらず同種類の細胞に対して均一かつ再現性ある処理条件を保証できる、自動化された対話式の細胞処理システムを提供する。これらの目的は、部分的には、ソフトウェアからの命令セットまたはプログラマブルチップ上の命令セットなど永久的にプログラムされた命令セットの読み出しおよび実行を行うプロセッサにより実現される自動流体管理システムによって実現される。命令セットの詳細は後述する。
【００３３】
システムは、流体を異なる供給源から異なる移動先へと分配することを可能にする。これを実現する装置は、複数の異なる供給源から流体を受け取り、1つまたは複数のポートから移動先へと流体を分配する。装置はまた、移動先から流体を受け取り、流体を1つまたは複数の他のポートから他の移動先へと移動させる。装置は、複数の流体を受け取るための複数のポートを備える。装置は、複数のポートに連結されたチャネル、および同チャネルに連結された第一のポートを備える。第一のポートは、複数のポートから第一の移動先へと流体を移動させること、および第一の移動先から流体を受け取るように適合している。装置はまた、第一のポート上で第一の移動先から受け取った流体を第二の移動先へと移動させるように適合したチャネルに連結された第二のポートも備える。第一の流体供給源を受けるための第一のポートと、第二の流体供給源を受けるための第二のポートと、第一のポートと連絡している第一のアウトレットと、第二のポートと連絡している第二のアウトレットとを備えるコネクタが提供される。第一および第二のアウトレットは、第一および第二の流体を特定の移動先に分配するための装置の第一および第二の入力ポートに取り付けられるように適合している。第一の流体を貯蔵するための第一の区画と第二の流体を貯蔵するための第二の区画とを備える、流体を貯蔵するためのチャンバーが提供される。好ましい流体管理システムのさらなる例としては、複数の流体を受け取るための複数のポートと；複数のポートに連結された2つまたはそれ以上の弁を有するチャネルと；複数のポートから処理モジュールへと流体を移動させることおよび処理モジュールから流体を受け取るように適合している、チャネルに連結された第一のポートと；処理モジュールへの流体の移動を制御するためのポンプと；弁の開閉、ならびに処理モジュールへと移動される流体の温度、圧力、体積、および処理時間のうち1つまたは複数を制御する変数入力を有するアルゴリズムを備える制御モジュールとを含む、複数の流体を分配するための装置を説明した、本発明者らの米国特許第6,425,414号がある。
【００３４】
図3に示す態様は、種々の流体経路連絡を制御する複数のフロースルー弁を備える流体管理カセットに関する。こうして流体管理カセットは、システムの流体リザーバからの緩衝液、酵素、無菌の空気および水の供給を調節するための命令を実行する。図3Aに示すように、流体管理カセット305は、好ましくはプラスチックまたはその他化学的に抵抗性の軽量の剛性材料で作られたハウジングであり、1つまたは複数の弁310で終端する複数の流体および空気コンジットを備えたハウジングを含む。囲まれた領域は図3Bの拡大図に示されている。図3Bには、弁を通る流体経路が示されている。図3Cにおいて、弁は閉位置の状態で断面として示されている。弁は、弁座325を有する弁本体と、プランジャ315により係合および変形される実質的に可撓性の膜320とを備える。弁のオペレーションは、線形のプランジャ315を用いて可撓性の膜320を弁座325の上に位置させることによって行われ、これによって弁が開くかまたは閉じ、流体経路の連絡が可能となる。フロースルー弁は、フローを妨げることなく流体フローを突出形弁座325の周りに迂回させるウェルを特徴とする。このフロースルーウェルの設計は、流体がデッドエリアに捕捉されることを防ぎ、流体経路のフラッシングの向上を可能にする。図3Dにおいて、弁は開位置の状態で断面として示されている。可撓性の膜はもはや弁座につながっておらず、流体がウェルに流入する。
【００３５】
処理バッグおよび絞り出しバッグ
体積固定遠心分離機において生体細胞を処理するための可撓性処理チャンバー（バッグ）および例えば遠心分離などによるそのような処理バッグの使用方法は、種々の形態で公知である。例えば、PCT特許出願第PCT/US98/10406号には、処理中にチャンバーの内容物を無菌に保つための回転シールを有する可撓性の細胞処理チャンバーが説明されている（米国特許第5,665,048号も参照）。可撓性処理チャンバーは、使い捨てでありしたがって単回使用の無菌用途に好適であることが好都合である。
【００３６】
血液成分分離、血液型の酵素による変換、および血液成分の病原体不活化を含む血液処理など特定の用途に対しては、処理によって分離された物質の部分を、軽い物質および／または重い物質の両方について、除去することが望ましい。処理バッグから分離された複数の物質を同時処理することは、そのような用途の実施に必要な時間および費用を減少させる。米国特許第7,074,172号には例示的な処理バッグおよびその使用方法が説明されている。同特許は、混合物質の成分を分離するための成分分離システムとともに使用するための、以下を含む可撓性遠心分離処理バッグを説明している：中心軸を有するハブ；混合物を受け取るための第一のポートであり、処理バッグ内に位置しかつ中心軸から第一の距離だけ間隔の空いたアウトレットを備える第一のポート；処理バッグ内に位置しかつ中心軸から第一の距離と異なる第二の距離だけ間隔の空いた第二のポートインレットを有する第二のポートであり、第二のポートインレットから収集され分離された物質を処理バッグの外に誘導するための第二のポート；ならびに、第三のポートインレットとインレット部およびアウトレット部を有する第一のフィルタとを有する第三のポートであり、第二のポートインレットが第一のフィルタのインレット部に隣接して位置し、かつ第三のポートインレットが第一のフィルタのアウトレット部に隣接して位置する第三のポート。現在の好ましい態様において、処理バッグは、より大きな体積を処理する場合にバッグがより大きく拡張することを可能にする、複数のアコーディオン状パーティションを備える。
【００３７】
図4は遠心分離処理バッグに関する概略図面である。現在の好ましい態様において、処理バッグはPVCで作られ、かつ、好ましくはバッグと同じ（例えば）PVC材料で作られかつ密閉表面および機械的なひずみ逃がしとして作用する、1つまたは複数の隆起表面を含む。
【００３８】
図5Aは処理バッグ設計の修正に関する概略図面である。同図に示されているのは、好ましくは血液製剤を遠心分離する力に耐えられる剛性／高デュロメーターのプラスチック材料で作られたチューブ類を使用した、処理ハブに（または特定の態様において遠心分離ローターに）取り付けられるチューブ機器である。チューブはその側方に沿って複数のアパーチャを有し、チューブ機器はそれ自体が処理バッグに挿入されてこれに囲まれ、バッグ管腔内部のハブから放射方向に突出して処理バッグおよび／または絞り出しバッグの内周を回り、開経路を維持しかつバッグへの流体フローを向上させるように機能する。
【００３９】
図5Bは処理バッグ設計の修正に関する概略図面である。同図に示されているのは、バッグの管腔壁に適合した複数の幾何学的特徴を有するバッグ機器である。好ましくは、この幾何学的特徴は連続気泡発泡体を使用する。この幾何学的特徴は、バッグにより向上した弾力性を提供しかつバッグの側方のつぶれを防ぎ、これにより、バッグ管腔とバッグが固定されているハブ上のポートとの間の抵抗またはフロー制限がより少ない状態で流体がバッグを通過することを可能にする。
【００４０】
図5Cは処理バッグ設計の修正に関する概略図面である。同図に示されているのは、バッグの壁を強化し、かつバッグに遠心力が加えられた場合に処理バッグおよび／または絞り出しバッグの壁がつぶれることを防ぎ、これにより装置オペレーション中の流体フローを向上させるための、複数の一体化した隆起形体を有するバッグである。具体的には、この態様は、バッグの内部管腔表面に、一体化した幾何学的隆起形体を備える。この一体化した幾何学的隆起形体は、好ましくはバッグと同じかまたは同様の材料で作られる。この機器は、遠心分離処理バッグの外側に高圧空気が存在する状態において、バッグ内で開いた流体経路を保つことを可能にする。一体化した幾何学的隆起形体は、周辺から中心ハブまでバッグの任意の局部領域に設けられていてよく、かつ、好ましくは、バッグの回転時により大きな力がかかる領域に集中する。
【００４１】
多管腔ロープ
前述のように、遠心分離機器の基本構造はバッグセットを備える。これは、内部回転式チャックに取り付けられた内蔵型の流体保持遠心分離カセットまたはローターと呼ぶこともできる。バッグセットは、カセットの軸に同軸状かつ固定的に取り付けられた流体インプットおよびアウトプットを有する。示されているように、本発明者らの米国特許第7,008,366号において、カセットはその回転軸が共通軸と同軸となるようにチャックに取り付けられる。したがって、チャックが回転すると、固定的に取り付けられたチューブ類がそれとともに共回転する。固定された取り付けの領域から軸方向外側に伸びるある長さのチューブ類が存在する。このチューブ類の長さは、軸方向後ろ向きにカーブし、放射方向外側の別個に回転可能なプーリーに向かい、これを通って伸びる。このプーリーは、プーリーとチャックとを相互接続する歯車列によって、チャックが2X RPMの速度で回転する場合に1X RPMの速度で回転する。チャックのオペレーションおよびプーリーの配置に関して米国特許第5,665,048号を参照する。オペレーションにおいて、プーリーが回転すると、後ろ向きにカーブしたチューブ類の長さが1X RPMの速度で軸周囲に回転し、一方、固定的に取り付けられたチューブの端は実際に2X RPMの速度で回転する。この現象は、カセットおよびチャックがチューブ類を軸方向に回転させてもチューブ類が軸周囲にねじれることを回避できるものとして、当技術分野において一般に公知である。この現象のより詳細な説明は米国特許第5,665,048号および米国特許第RE29,738号（米国特許第3,586,413号）に記載されている。
【００４２】
図6は「スキップロープ」120（前述および図2A〜2Fに示したもの）に対応する多管腔チューブに関する概略図面である。多管腔122のチューブ類（へそ）は、システムの供給モジュールの出力、すなわち静止ソース連結管（satic source manifold）から、遠心分離機に含まれる1つまたは複数の処理バッグへと流体を運ぶために用いられる。具体的には、いくつかの態様により、へそは静止ソース連結管から遠心分離機のポートまで特定の軌道をたどり、かつ剛性アームによって支持される（図2A〜2F参照）。へそは好ましくは（例えばその構造剛性を高めるために）その長さの一部または全部に沿ってねじれを備えていてもよい。支持アームは前述のように遠心分離駆動システムに噛み合わされ、へそが遠心分離機と同方向に同様のまたは同様でない速度で回転することを可能にする。
【００４３】
多管腔ロープは、好ましくは個々のチューブのねじれたアセンブリであってもよく、より好ましくは複数の個々の一体式チャネルを含む単一の突出部品（すなわち多管腔ロープ）である。例示的な多管腔ロープは医療等級のポリウレタンで作製され、直線長さ1フィートごとに約2〜3個の時計回りまたは反時計回りの回転を有する。
【００４４】
ソフトウェア／電気
本明細書に説明するシステムは、種々の電気システム、処理装置およびハードウェア、ならびに例えばソフトウェアおよびファームウェアなどシステムを制御するための命令セットを備える。例示的かつ非限定的なシステムを実施例1〜3で説明する。
【００４５】
実施例
実施例1：電気仕様
以下に、血液の1つまたは複数の分量を処理するため、1つまたは複数の態様（前述）に従う遠心分離システムとともに用いてもよい、例示的な電気仕様の態様を説明する。図7Aおよび図7Bは、それぞれそのようなシステムの電気ブロック図およびホストロジックを示したものである。以下に、血液処理システムの各態様の電気およびオペレータインターフェース、電力消費、ならびに電気サブシステムを指定する。各サブシステムはそれ自体の詳細な電気仕様を有する。
【００４６】
電気ブロック図
電気ブロック図を図7Aに示す。電気システムは、電源、ホストロジックアセンブリ、オペレータコンソール、およびホストロジックアセンブリをマシンハードウェアにインターフェースするいくつかのサブシステムコントローラを含む。
【００４７】
電源はAC電力を取り込み、マシンの残りの部分にDC電力を分配する。マシン上の非常切断または「非常用」ボタンは、遠心分離機、蠕動ポンプ、またはエアコンプレッサなど危険なサブシステムへの電力をオペレータが直接切ることを可能にする。
【００４８】
ホストロジックアセンブリは、最大4つの同一のPC104拡張ボード（Zymequest, Inc., Beverly, MA）を備えた埋込み式PCを収容する。拡張ボードはホストPCとサブシステムコントローラとの間にUART直列通信を提供する。拡張ボードは相互接続され、ホストおよびすべてのコントローラが互いにシステム障害を通知または検出できるよう、これらを一緒に接続するシステム障害ハブを提供する。このことは後述の実施例3でより詳しく説明する。
【００４９】
サブシステムコントローラは、マシンハードウェアに対する分散ソフトウェア制御インターフェースをホストPCに提供する。分散制御アプローチはいくつかの利点を提供する。主な利点はマシン内のケーブル布線が単純化されることである。各コントローラは、それが制御するマシンハードウェアのできるだけ近くに置かれる。これにより、多数の周辺機器ワイヤが短く保たれ、管理も容易に保たれる。各コントローラに引き回される長いケーブルは電源ケーブルおよび通信ケーブルの2本のみであり、かつこれらはシステムのケーブル種類の全体的な数を減らすよう標準化される。長距離ケーブルは性能に影響を及ぼすことなくかなり長くすることができ、このことは、マシンが実際に任意のサイズであってよくかつコントローラが実際にどこに置かれていてもよいことを意味する。
【００５０】
コントローラをマシンハードウェアの近くに置くことによってEMC（electromagnetic compatibility）が向上する。大電流および高周波の信号線は、放射するEMI（electromagnetic interference）が最小となるよう、短く保たれる。極低電圧および高インピーダンスのトランスデューサ信号は、拾う雑音が最小となるよう、短く保たれる。長距離の電源ケーブルおよびホスト通信ケーブルは、放射されるEMIを減らすため、撚線対である。
【００５１】
別の利点は、インテリジェントな自律制御である。ホストPCがロックアップするかまたはその他機能障害を起こした場合、コントローラはホストのロックアップを検出するかまたは範囲外のホスト制御命令を拒否することができる。ホスト通信が失われた場合、コントローラはリセットの前にマシンオペレーションを停止するようアクションを取ることができる。
【００５２】
別の利点は、標準的な電力および制御のインターフェースである。これにより、製造環境の検査ステーションが単純化される。コントローラの検査に必要なRS232通信を任意の標準的なPCを用いて提供でき、かつ、任意のベンチトップデュアルDC電源で電力を供給できる。
【００５３】
障害ハブはマシンの電気的障害の検出および回復の基盤である。各サブシステムコントローラは障害ハブのポートに接続される。
【００５４】
コントローラは、その状態、すなわちアイドル（Idle）、OK、または障害（Fault）を障害ハブに通知する。障害ハブは、その状態、すなわちアイドル、OK、または障害をコントローラに通知する。障害ハブの任意のポートが障害信号を受け取ると、障害ハブはそのすべてのポートに障害を通知する。このことは、すべてのコントローラにハードウェアリセットを実行させる。
【００５５】
OK信号は反復型であり、時間的拘束を有する。障害ハブとコントローラとの間の通信ケーブルが抜かれるか、緩むか、または間欠的な接続を提供すると、OK信号の時間的拘束が破られ、これにより、障害ハブおよび取り付けられたすべてのコントローラに障害が通知される。OK信号の時間的拘束は、ホストまたは任意のコントローラのいずれかがみせかけでリセットした場合も破られる。
【００５６】
電気インターフェース
この項では細胞処理装置の電気インターフェースについて説明する。細胞処理装置へのAC電源入力は汎用電源ジャックである。これは、100〜240ボルトRMS、47〜63 Hzの世界的なAC電源を受容する。壁のコンセントを汎用電源ジャックに接続するため、現場に適したプラグを備えた地域用電源ケーブルが提供される。
【００５７】
AC電源スイッチ
このスイッチは、AC電力入力ジャックと配電サブシステムとの間に直列接続されている。OFF位置に切り替えるとAC電力が配電サブシステムから遮断される。ON位置に切り替えるとAC電力が配電サブシステムに接続される。
【００５８】
AC電源ライト
見やすい位置に配置されたAC電源ライトが、システムが通電しているか否かを示す。AC電源ライトは、AC電源入力が生きたAC電源に接続されかつAC電源スイッチがON位置にある場合に点灯する。AC電源ライトは、AC電源入力が切断されているかもしくはAC主電源が死んでいる場合、またはAC電源スイッチがOFF位置にある場合に消灯する。
【００５９】
イーサネット通信
細胞処理装置のネットワーク通信ポートは、自動検出10/100高速イーサネットインターフェースを提供する標準的なRJ45モジュラージャックである。このインターフェースによりサポートされる通信プロトコルは、実施例2で説明する000-0000 Zeke3 ソフトウェア仕様に指定されている。
【００６０】
タイミングポート
このインターフェースは、ホストソフトウェアが正しく作動していることを確認するため、システム開発時にロジックアナライザに接続できる。このポートは、血液処理ラン中のマシンの通常の使用中にオペレータがアクセスすることはできない。
【００６１】
実施例2：命令セット
以下に、前述の1つまたは複数の態様に基づいて細胞処理装置を制御および／または操作するために用いてもよい、ソフトウェアシステムの1例の概要を説明する。図8はホストソフトウェアアーキテクチャの図である。
【００６２】
1 概要
本明細書は、本発明による血液処理システムの態様のための、ホストハードウェアプラットフォーム上で作動するホストソフトウェアを明細に記載する。参照される他の仕様文書に、ソフトウェアコンポーネントの焦点を絞った詳細が提供されている。
【００６３】
1.1 序
本仕様は以下を提供するために書かれている。
・ソフトウェアのあらゆるレベルに障害検出を適用することによって安全上の懸念に対応する。
・各契約者によって同時にインプリメントされ得るよう、ソフトウェアピースを分ける。
・ソフトウェア、特にピースのインタラクションをできるだけ単純に保つ。
・マシンハードウェアまたはマシンRTOSがなくてもランできるようソフトウェアをインプリメントする。
・システムタイミングを保証する。
【００６４】
1.2 システムの説明
ホストソフトウェアはLCDタッチスクリーン用のグラフィカルユーザインターフェース（GUI）を提供する。これは、使い捨てセットを装填するための命令を提供し、かつ血液処理中に進行状態を表示する。これはまた、開発またはメンテナンス使用のための診断制御インターフェースも提供する。複数の異なる言語によるテキスト表示が利用可能である。
【００６５】
ホストソフトウェアはイーサネットおよびTCP/IPネットワーキングプロトコルを用いて中央モニタリングステーションとインターフェースしてもよい。これらのプロトコル上で、血液バンクの在庫表データベースとインターフェースするためLISデータベースが用いられる。
【００６６】
ホストソフトウェアは、ハードディスクドライブを用いて、完了または中断したすべての血液処理ランの記録を保存する。ハードドライブはまた、血液処理プロトコル定義をコンフィギュレーションおよびキャリブレーション情報とともに保存するのにも用いられる。
【００６７】
ホストソフトウェアは等時性パケット式直列通信プロトコルを用いて、センサー、モーター、および弁などのマシンハードウェアと直接インターフェースする埋込み式コントローラの状態を指令および問合せする。
【００６８】
ホストソフトウェアは、市販のリアルタイムオペレーティングシステム（RTOS）上でインプリメントされて、高い信頼度を提供し、かつマシンが安全な様式で作動することを保証する。
【００６９】
ホストソフトウェアはコンポーネントに分けられる。各コンポーネントは1つまたは複数のアプリケーションプログラミングインターフェース（API）を有する。APIは、コンポーネントをインプリメントするため複数の開発チームが作業できるよう、コンポーネントの同時インプリメンテーションを許容するように設計され、かつ、コンポーネント実現の詳細は、APIが変更されていない限り必要に応じて変更できる。
【００７０】
特にハードウェア開発時は、システム開発者がマシンハードウェアを常に使用できるとは限らないため、シミュレーションコンポーネントが提供される。これは構成可能な程度の忠実度をもってハードウェアオペレーションをエミュレートする。
【００７１】
さらに、システム開発者がRTOS環境を常に使用できるとは限らないため、すべてのコンポーネントを、複数種のオペレーティングシステム上で実行され得るような様式でインプリメントしてもよい。このことは、顧客フィードバックのため通常のWindowsコンピュータ上でプロトタイプソフトウェアを実行できるよう、特にGUI開発時に重要である。
【００７２】
1.3 システムアーキテクチャ
ホストソフトウェアの図を図1に示す。同図に示されているように、コンポーネントおよびAPIの名前は、コンポーネントの複数の複製が作動しており各々が個々のリソースの管理専用であることを示すため、末尾に [n:0] が付く。
【００７３】
ホストソフトウェアの図をざっと眺めるとコンポーネントの3つの柱がある。左側の柱は、容易に複数のオペレーティングシステムに移すことのできる基本的なサービスを提供する。これらは、システムの残りの部分をその上に構築するための基礎を提供する。中央の柱は自律的な血液処理を行うために必要なマシン制御を提供する。右側の柱はマシンに外部インターフェースを提供する。
【００７４】
どのコンポーネントが相互接続されておりどのコンポーネントが相互接続されていないかに注意することが重要である。各コンポーネントは、好ましくは、コンポーネント間の従属の数が最小となるように設計される。これによりコンポーネントが単純化されかつインプリメンテーションの焦点が合い、検査が容易かつ迅速になる。
【００７５】
2 基本サービス
基本サービスコンポーネントは、オペレーティングシステムに特異的なAPIを、より高層のコンポーネントから分離する。各基本サービスコンポーネントは、固定されたAPIをより高層のコンポーネントに提供する。各基本サービスコンポーネントは、複数のオペレーティングシステムをサポートするため複数のバージョンでインプリメントされてもよい。
【００７６】
2.1 オペレーティングシステム
これはホストソフトウェアの最下層である。これは、CPU、ROM、RAM、記憶装置、表示装置、ネットワーク装置、およびPC104ハードウェア拡張バスなどの低層ハードウェアリソースへのアクセスを提供する。
【００７７】
ホストソフトウェアのリリースバージョンは、RTOSとして（本明細書では名前を指定、すなわちVxWorks, QNX）使用する。これは、割込み優先権アルゴリズムを用いた、タスクの確定的スケジューリングを提供する。これにより、優先権の最も高いタスクが常にラン中であることが保証される。優先権が等しいタスクは、各タスクが同じラン機会をもつことを保証するラウンドロビンタイムスライスアルゴリズムを用いてスケジューリングされる。
【００７８】
ホストソフトウェアの開発バージョンでは、RTOSがMicrosoft Windowsで置き換えられる。
【００７９】
2.2 OSシェル
OSシェルは、根底にあるオペレーティングシステムAPIへのホストソフトウェア参照をすべて含み、かつ、各オペレーティングシステムについて再インプリメントされる。OSシェルAPIは、より高層のコンポーネントに、汎用オペレーティングシステムのビューを提供する。
【００８０】
汎用オペレーティングシステムは、以下のサービスのうち1つまたは複数を提供してもよい。
・キーボードおよびポインタ装置（マウスまたはタッチスクリーンなど）からのコンソール入力；
・コンソールテキスト出力；
・高分解能タイムスタンプ；
・エラーロギング；
・プリミティブ実行スレッド；
・プリミティブ実行クリティカルセクション；
・プリミティブヒープメモリ；
・カーネルサービス；
・アプリケーション管理；および
・障害検出および回復。
【００８１】
2.2.1 プリミティブ
コンソール入力／出力サービスは開発時の使用のために提供される。これらは、コンソールマネージャコンポーネントにより提供されるグラフィカルユーザインターフェースの基礎となるものではない。
【００８２】
高分解能タイムスタンプサービスは、システム始動時からの秒数を表す二倍精度浮動小数点数を返す。マイクロ秒またはナノ秒のオーダーで非常に精密な時間増分をカウントする、根底のオペレーティングシステムコールが、このタイムスタンプの基礎を提供する。
【００８３】
エラーロギングサービスは、より高層のコンポーネントがエラーコードのロギングによって問題を示すことを可能にする。エラーコードはタイムスタンプが押され、ハードドライブ上のログファイルに置かれる。さらに、エラーコードのコピーがコンソールテキスト出力として提供される。
【００８４】
汎用オペレーティングシステムは、スレッドプリミティブの形態で、柔軟かつ拡張可能なコード実行を提供する。このスレッドプリミティブは、生成時に、タスク優先権、タイマ期間、およびコールバック関数という3つの主なパラメータをとる。スレッドプリミティブは、タイマ期間ごとに、指定された優先権で実行されている根底のオペレーティングシステムタスクからコールバック関数を実行する。スレッドプリミティブのロジックおよびリソースを管理する方法として意図されているのは有限状態機械である。
【００８５】
スレッドプリミティブには、新しいタイマ期間が始まる前にコールバック関数が戻らなければならないという制限がある。このことは、コールバック関数が通信および制御のポーリング方法を採用していなければならないことを意味する。
【００８６】
コールバックタイミングの制限は、実際にはスレッドプリミティブの主要な利点である。開発者はシステムコンポーネントを、確定的な実行タイミングを保証する非ブロッキング様式でインプリメントすることを強いられる。スレッドプリミティブがコールバックの実行時間をモニタし、スレッドがタイミング期間に違反した場合にはエラーを生成する。
【００８７】
スレッドプリミティブは単なる周期的なコールバック関数であり根底のオペレーティングシステムタスクではないため、セマフォおよびミューテックスなど高度なオペレーティングシステムブロッキング機構が回避される。このことによりOSシェルコンポーネントのポータビリティが単純化される。
【００８８】
マルチスレッド型のアプリケーションは必然的にスレッド間のデータ構造共有を必要とする。2つのスレッドが同時に更新を行い同じデータ構造にアクセスすると、乱調状態が生じる。実行をブロッキングする制御された方法の必要性を生じさせるのがこの問題である。
【００８９】
汎用オペレーティングシステムにより提供される唯一のブロッキングプリミティブがクリティカルセクションである。一部の根底のオペレーティングシステムはこのプリミティブを直接インプリメントし、他の根底のオペレーティングシステムはセマフォまたはミューテックスを用いてブロッキングを提供する。
【００９０】
クリティカルセクションはロック関数を用いて、スレッドプリミティブがクリティカルコードのセクションを実行開始することを可能にする。ロック関数は、ロック関数内部で他のスレッドプリミティブを一時的にブロックすることによって、それらがそのセクションに同時に入ることを防ぐ。クリティカルコードセクションの実行が完了すると、アンロック関数が用いられて、ブロックされた任意のスレッドプリミティブが非ブロック化される。コードのクリティカルセクションは、ブロッキングが最少に保たれるよう、できる限り短くなるよう意図される。
【００９１】
メモリ断片化はヒープメモリによくある問題であり、アプリケーションのクラッシュにつながることがある。ヒープメモリはランタイム中に動的に割当てられ、いくらかの持続時間にわたって使用され、かつ最終的に再利用のため解放される。断片化は、ランダムに配置された解放後のメモリの小片を一緒に組み合わせてより大きな連続メモリ片への要求を満たす、ということができない場合に起きる。この場合、要求が失敗となり、かつこのことはアプリケーションのクラッシュにつながる可能性がある。
【００９２】
注意されるべき点として、ヒープメモリ断片化の問題は、ヒープメモリを使う代わりに静的なメモリ割当を使うことによって完全に回避できる場合が多い。静的割当て法は、ランタイムではなくアプリケーションのコンパイル時にメモリを予約する。この方法で起こりうる欠点は、アプリケーションが終了するまで、このメモリを再利用のためオペレーティングシステムに返すことができないことである。
【００９３】
OSシェルコンポーネントは、ヒープメモリ断片化の問題を、2段階ヒープメモリ割当法で解決する。プリミティブヒープ層は根底のOSを直接使用してメモリブロックを割当および解放する。より高次のヒープ層についてはカーネルサービスの項で説明する。
【００９４】
2.2.2 カーネル
OSシェルコンポーネントは、OSシェルプリミティブの上に構築されるカーネル層を提供する。カーネルサービスはプリミティブよりはるかに大きい柔軟性および有用性を提供する。カーネルサービスには以下のものがある：
・ヒープの管理；
・連結リストの管理；
・サーキュラーバッファの管理；
・タスクの管理；
・メッセージキューの管理；および
・テキストウィンドウの管理。
【００９５】
カーネルヒープ層はアプリケーション初期化中にプリミティブヒープ層を使用して一連の比較的大きなメモリプールを割当てる。各プールは、サイズが固定されたいくつかのフリーブロックに分割される。各メモリプールは、他のメモリプールと異なるフリーブロックサイズに分割される。メモリプールはアプリケーションのクリーンアップ時まで割当てられたままとなる。これにより、断片化の問題がフリーブロック管理に委ねられる。
【００９６】
アプリケーションメモリ割当は2つのステッププロセスによって満たされる。まず、少なくとも割当サイズと同じだけ大きい、最小のフリーブロックサイズを備えたプールが選択される。次に、そのプールから固定サイズフリーブロックの1つが割当てられ、アプリケーションに提供される。後に固定サイズブロックがアプリケーションにより解放されると、そのブロックは割当元であった同じプールにフリーブロックとして戻される。
【００９７】
メモリプールの固定サイズフリーブロックは決して細分されず、かつ再結合される必要もないため、メモリ断片化は決して起こらない。メモリプールのフリーブロックが割当および解放される順序が断片化につながることはない。
【００９８】
連結リストカーネルサービスは、オブジェクトのリストを管理するための単純かつ信頼できる方法をより高層のコンポーネントに提供する。このサービスは、オブジェクトをリストに挿入することまたはリストから削除することを可能にする。オブジェクトは、ソーティングアルゴリズムを提供することによって、リストの特定の位置に置くことができる。リストは、1つのオブジェクトからリストの次または前のオブジェクトに移動することによってトラバースできる。リストは2つのリストに分けることができ、2つのリストを1つにマージすることもできる。
【００９９】
サーキュラーバッファカーネルサービスは、必要時と異なる時に生成されたデータを一時的に保持するための単純かつ信頼できる方法を提供する。1つの好例は、入ってきた直列通信データを、後にアプリケーションが読めるようバッファに書き込む、割込みサービスルーチンであると思われる。サーキュラーバッファカーネルサービスは（制限を最大とする）任意のサイズのバッファを許容し、かつ、バッファ上で同時の読出し演算および書込み演算を許容する。バッファから読み出されたデータは、バッファの循環再利用によって上書きされない限り、再読出しが可能である。
【０１００】
カーネルタスク管理サービスはスレッドプリミティブよりはるかに柔軟でありかつ機能が充実している。同サービスは、イベント処理タスク、イベントタイマ、およびタスクスケジューラを提供する。
【０１０１】
任意の数のタスクスケジューラが生成可能である。各々は、それ専用のスレッドプリミティブを生成する。タスクは、生成されるとタスクスケジューラに割当てられる。
【０１０２】
カーネルタスクは、優先権、タイマ期間、およびコールバック関数を伴って生成されるため、スレッドプリミティブと非常によく似ている。相違点は、コールバック関数に処理すべきイベントが提供されることである。
【０１０３】
カーネルタスクイベントがもちうるソースは2つある。1つのソースはカーネルタスクである。カーネルタスクはイベントを他のタスクまたは自分自身に送信してもよい。もう1つのソースはカーネルタスクタイマである。カーネルタスクタイマは、満了になるとタスクにイベントを送信する。カーネルタスクタイマはシングルショット用に構成されていてもよく、または繰返し満了用に構成されていてもよい。
【０１０４】
カーネルタスクスケジューラはカーネルタスクタイマおよびカーネルタスクを管理する。スケジューラそれ自体はスレッドプリミティブであり、このことは、これが定期的スケジュールで作動するコールバックとしてランすることを意味する。スケジューラは、ラン時、そのすべてのタスクタイマを調べ、満了となった任意のタイマについてイベントを送信する。イベント送信により、タスクがスケジューラのアイドルリストからレディリストに移動される。レディリストは優先権によってソートされる。タイマの管理後、各タスクのコールバックをコールしてそのタスクの保留イベントを処理することによって、レディリストのタスクが処理される。レディリストのタスクがなくなった場合にスケジューラのジョブが完了する。
【０１０５】
メッセージキューカーネルサービスは、単純なタスクイベントよりも柔軟なタスク間通信を提供する。同サービスは、任意の数の送信側タスクが任意のフォーマットの任意の数のメッセージを処理のため受信側タスクに送信することを許容する。メッセージの送信により、イベントが受信側タスクに送信され、キューが空でないことが示される。
【０１０６】
テキストウィンドウカーネルサービスは、OSシェルのコンソール入力／出力サービスを使用して、はるかに柔軟でかつ機能の充実したコンソールインターフェースを提供する。同サービスは、そのすべての機能性を、構成可能なベースウィンドウオブジェクトと、コンソールテキスト出力の更新を自動化しかつコンソール入力をベースウィンドウに割当てるカーネルタスクとから得る。
【０１０７】
ベースウィンドウは、境界線および中心部という2つの長方形領域で構成される。境界線は、ブランク、1本線、または2本線であってもよい。中心部は境界線によって囲まれた領域である。各領域の前景色および背景色は独立して設定できる。ベースウィンドウはコンソール内の任意の場所に置かれていてよく、ベースウィンドウサイズはコンソール内にフィットする任意のサイズであってよい。ベースウィンドウはまたテキスト文字列も有する。テキスト文字列は、境界線がブランクであれば中心部に表示され、そうでない場合は境界線の中に表示される。ベースウィンドウの別の属性は、それが可視か否かである。
【０１０８】
ベースウィンドウはまた、その上に他のベースウィンドウのスタックを有していてもよい。このことは、コンソール出力が更新される階層的順序を提供する。まず、ルートウィンドウが更新され、次にスタックされた各ウィンドウが更新され、かつスタックされたそれらのウィンドウの各々は、再帰ロジックを用いて更新される任意の数のスタックを有していてよい。ベースウィンドウが不可視に設定されている場合は、そのスタック内の全ウィンドウも不可視となる。
【０１０９】
ベースウィンドウは、ベースウィンドウのさらなるカスタマイズに用いられる4つのコールバック関数を有する。1つのコールバックは、色、位置、サイズ、または可視性などのベースウィンドウパラメータを変更する機会を通知する。他の3つは、フォーカスをもつベースウィンドウにキーボードまたはポインタの情報を送るために用いられる。
【０１１０】
ベースウィンドウのフォーカスは、マウスボタンまたはタッチスクリーンの押下などのポインタイベントが生じた場合に選択される。イベントのコンソール位置がウィンドウのスタック階層に対して比較される。まずルートウィンドウがフォーカスを得る。次に、そのスタック内の各ウィンドウがチェックされ、ポインタ位置がそのウィンドウ領域内にあるか否かが調べられる。もしそうであればそのウィンドウがフォーカスを得る。この検索は更新ロジックと同様に再帰的に繰り返される。
【０１１１】
テキストウィンドウカーネルサービスは、他のより特殊化されたタイプのテキストウィンドウも提供する。これには、ポップアップウィンドウ、ボタンウィンドウ、データ表示ウィンドウ、進行バーウィンドウなどがある。ボタンウィンドウのリストおよび階層を管理するフレームタイプのウィンドウが提供される。各ボタンウィンドウは、ボタンの選択時にカスタマイズされた表示を行うため、コンソール出力領域の大部分を得る。
【０１１２】
2.2.3 アプリケーション管理
OSシェルは、初期化、ランタイム、およびクリーンアップというシステムオペレーションの3つのフェーズを管理する。性質の異なるこれらのフェーズは、常に指定の順序で生じる。
【０１１３】
OSシェルは、再帰を防ぐため常にチェックしながら、その各サブコンポーネントを秩序立てられた様式で初期化する。サブコンポーネントの初期化を複数回行うとエラーが生じ、これはシステムをクラッシュさせる。OSシェルコンポーネントは、初期化された後、固定名関数をコールしてアプリケーションを初期化する。これは、ANSI Cにおいてプログラムの実行開始位置として用いられるmain()関数とよく似ている。
【０１１４】
アプリケーション初期化関数がエラーなしで戻ると、OSシェルコンポーネントは正常なランタイムフェーズに入る。それは、システムがエラーを検出するかまたはサブコンポーネントがシャットダウンを通知するまで、このフェーズに留まる。
【０１１５】
次にクリーンアップフェーズに入る。まず、アプリケーションをクリーンアップするため固定名関数がコールされる。この関数は、継続中の任意のマシンオペレーションを安全に停止させ、かつ取得されたすべてのOSシェルコンポーネントリソースを解放するために用いられる。次に、各OSシェルサブコンポーネントが、初期化された場合と逆の順序で自分自身をクリーンアップする。
【０１１６】
OSシェルクリーンアップ関数は、すでにクリーンアップされているはずのリソースが見つかった場合はいつでも警告をロギングする。これらの警告は、より高層の1つまたは複数のコンポーネントが不完全なクリーンアップを実行したことを示す。
【０１１７】
2.2.4 障害検出および回復
OSシェルコンポーネントは、制御されないシステムクラッシュに対する最終防衛線として作用するための独特のポジションにある。このことは、それがシステムオペレーションの3つのフェーズを制御しており、かつ、システムをランさせるスレッドプリミティブおよびカーネルタスクを提供しているからである。
【０１１８】
OSシェルコンポーネントをインプリメントする各関数は、正常オペレーションに対してゼロでありエラーを示す場合にゼロ以外であるエラーコード値を返す。このことはOSシェルAPIのコールバック関数についても当てはまる。すなわち、OSシェルを使用するより高層のコンポーネントは、関数コールごとにエラーコードを提供することを強いられる。
【０１１９】
各エラーコードはユニークである。このことは、開発者にとって、エラーコードがロギングされた場合に、ソースコード内でエラーを生成しうる単一の場所を見つけることによって、何が悪かったのかを非常に迅速に診断することを容易にする。
【０１２０】
各関数コールの後、生じたエラーコードがゼロに対して検査される。もし非ゼロであれば、時としてユニークなエラーコードが、許容されかつ回復できる状態を表すこともある。この場合は対応策が実行され、システムはオペレーションを続ける。もしそうでなければ、より高層でトラップおよび対策されるまでまたはOSシェルによって検出されるまで、エラーコードが関数のチェーンを通って渡される。
【０１２１】
OSシェルはエラーコードを検出すると速やかにクリーンアップフェーズに移動し、クリーンアップフェーズは継続中の任意のマシンオペレーションを通常の方法で停止させることを試みる。エラーコードは、重要なデータ構造が破損したことを示している場合もあり、これは通常のクリーンアップに干渉する可能性がある。これが起こった場合はシステムがクラッシュすることもある。
【０１２２】
この場合、ハードウェアPC104障害ハブ回路がシステムアクションの欠損を検出し、マシンを自動的に停止させる。
【０１２３】
2.3 障害マネージャ
障害マネージャコンポーネントは、他のコンポーネントが障害状態情報の共有に使用するサービスを提供する。
【０１２４】
障害マネージャは、回復可能なエラーの場合にのみ反応するOSシェルの障害検出および回復とは異なる。障害マネージャは、遠心分離機の速度超過もしくは激しい振動、遠心分離機もしくは蠕動モーターの動きの普通でない遅れ、または空気系の過剰圧力などの危険な障害条件に反応するシステムを提供するように設計される。
【０１２５】
障害マネージャは、緊急停止ボタンの作用として期待されるような作用を行う。任意のコンポーネント信号が障害である場合、すべてのコンポーネントが障害信号を受け取り、かつ各コンポーネントは継続中のすべてのマシンオペレーションを停止させることによって反応する。
【０１２６】
障害マネージャのオペレーションはハードウェアPC104障害ハブのオペレーションをモデルとしている。障害ハブは基本的なウォッチドッグ回路を高度にしたものである。
【０１２７】
基本的なウォッチドッグ回路はハードウェア論理回路へのリセット入力を制御する。論理回路はウォッチドッグタイマが満了になることを防ぐため、ウォッチドッグ回路のタイマを定期的に再スタートさせなければならない。ウォッチドッグタイマが満了になると、ウォッチドッグ回路は論理回路にリセットを通知する。
【０１２８】
障害ハブは、任意のウォッチドッグタイマが満了になった場合にすべての論理回路にリセットが通知されるよう、多数のウォッチドッグ回路を一緒につなぐことによって、ウォッチドッグの概念を拡張する。
【０１２９】
コンポーネントは、それ自体をレジスタしかつデッドライン期間を提供することによって、障害マネージャとのインタラクションを開始する。レジスタ後、コンポーネントはその障害状態を定期的に報告しなければならない。これにより、障害マネージャがそのコンポーネントのために維持するデッドラインタイマが再スタートされる。デッドラインタイマが満了する前にコンポーネントの障害状態報告が受け取られなかった場合、障害マネージャは障害状態に入る。
【０１３０】
コンポーネントは、障害状態を報告するたびに、障害マネージャ状態の報告を受け取る。コンポーネントは、障害状態の報告を受け取った場合、継続中の任意のマシンオペレーションを停止させることによって反応し、かつ障害への対応が成功したことを障害マネージャに折り返し報告しなければならない。
【０１３１】
障害マネージャのオペレーションの重要な部分は、それ専用のOSシェルスレッドプリミティブにおいてすべてのマシン制御タスクのうち最高の優先権でランすること、および、カーネルタスクサービスを使用しないことである。このことは、デッドロックしたかまたは無限ループに陥った他のいかなるスレッドプリミティブまたはカーネルタスクも、障害マネージャがデッドラインタイマの維持を行うことを妨げられない、ということを保証する。
【０１３２】
障害マネージャは、障害状態に入ると、シャットダウンタイマをスタートさせる。障害マネージャは次に、レジスタされた各コンポーネントが障害に対応したことを報告するのを待つことを開始する。レジスタされたすべてのコンポーネントがシャットダウンタイマの満了前に障害に対応した場合、障害マネージャはシャットダウンタイマを停止させて障害状態を抜ける。
【０１３３】
シャットダウンタイマが満了になった場合、障害マネージャはスレッドプリミティブからエラーコードを返すことによって反応し、このことはOSシェルをクリーンアップフェーズに移動させる。
【０１３４】
2.4 タイミングモニタ
タイミングモニタコンポーネントは、オシロスコープに接続されていてもよいハードウェア出力ポートに他のコンポーネントが信号の連係セットを出力するために使用するサービスを提供する。
【０１３５】
ホストソフトウェアのための安全管理システムの核は、タイミング違反の検出に基づく。
【０１３６】
OSシェルのスレッドプリミティブは、コールバック関数が、割当てられた期間内に実行を完了したことを確認する。実行時間が長すぎる場合、スレッドプリミティブは、OSシェルをクリーンアップフェーズに移行させるエラーコードを返し、かつこれは、すべてのコンポーネントに、継続中のすべてのマシンオペレーションを停止させる。
【０１３７】
障害マネージャは、検出された不安全条件にシステムが反応することを可能にするサービスを提供する。システムの反応がタイミングデッドライン内に完了しなかった場合は、OSシェルをクリーンアップフェーズに移行させるエラーコードが生成される。
【０１３８】
直列通信プロトコルのタイミングに信頼性があることがそのオペレーションに非常に重要であるこということが、セクション3.2.2から理解されるものと思われる。これは、直列接続の末端にあるスレーブコントローラが、PC104障害ハブへの入力として通信ストリームを用いるからである。通信タイミング違反が生じると、スレーブコントローラは障害ハブに障害を通知し、これは継続中のすべてのマシンオペレーションを停止させる。
【０１３９】
タイミングモニタは、ホストソフトウェアシステム開発時に、システムのタイミングを見るために用いられる。タイミングモニタは、タイミングにどれだけのマージンがあるかを判断するのに用いてもよい。マージンが少なすぎる場合は、ソフトウェアのどの部分にパフォーマンス最適化が必要かを判断するためにタイミングモニタを用いてもよい。
【０１４０】
タイミングモニタは、CPU出力ポート上のビットに対する直接更新を可能にする複数の機能を提供する。オシロスコープはこの出力ポートと直接インターフェースする。出力ポート上に信号の連係セットを生成するため、タイミングモニタ関数コールがシステムソースコードの重要な位置に置かれる。
【０１４１】
2.5 イベントログ
イベントログコンポーネントは、システムイベントに関する情報をロギングするための一様な方法をより高層のコンポーネントに提供する。イベントはハードドライブ上のファイルにロギングされる。
【０１４２】
任意の数のイベントログファイルが同時に生成されてもよい。このことは、システムイベントログを多量の情報で散らかすことなく、コンポーネントが独自のイベントログを維持することを可能にする。
【０１４３】
イベントログコンポーネントは、重要でないイベントがログファイルに記録されることを防ぐことができるランタイム構成可能イベントフィルタを提供する。コンポーネントはコンパイル時間にインプリメントされて通常必要とされるよりはるかに多い情報を生成してもよく、かつ、ランタイムには重要なイベントのみがロギングされてもよい。コンポーネントに関する問題を調査する必要がある場合は、問題へのよりよい洞察を提供するため、それ以上のまたはすべてのイベント（all more or all of the event）をロギングしてもよい。
【０１４４】
2.6 データログ
データログコンポーネントは、システム変数情報をロギングするための標準的な拡張可能方法を提供する。データはハードドライブのファイルにロギングされる。
【０１４５】
任意の数のデータログファイルが同時に生成されてもよい。このことは、システムデータログを多量の情報で散らかすことなく、コンポーネントが独自のデータログを維持することを可能にする。
【０１４６】
データログコンポーネントは他のコンポーネントとインタラクトしてそれらのデータを任意のサンプルレートで受け取り、それを構成可能な定数の記録サンプルレートでハードドライブにロギングする。記録レートは入ってくるデータのレートより大幅に遅いことが意図されている。
【０１４７】
データログは各データファイルを2つのフェーズで管理する。第一のフェーズはレジストレーションフェーズである。このフェーズにおいて、他のコンポーネントは、ロギングしたいデータの構造をレジスタする。各構造は浮動小数点または整数などのプリミティブデータタイプのセットで構成される。レジストレーションは、コンポーネントがデータログにデータ記録の開始を命令するまで継続する。
【０１４８】
レジストレーションが終わりデータ記録が始まる前に、データログサービスは、データ記録フォーマットの翻訳が可能となるよう、レジスタされたフォーマット情報をデータログファイルに書き込む。この方法は、データログファイルがプリミティブデータタイプの任意の組合せまたは順列を含むことを可能にする。
【０１４９】
記録フェーズ中、各コンポーネントのデータストリームは、1度に1つのプリミティブデータタイプずつ取り扱われる。入ってくる各データは、各データログ記録期間中のデータの最小値、最大値、および平均値を判定するために検査される。データログ記録サンプルがディスクに書き込まれる場合、各データについてこれら3つの統計値が書き込まれる。これによりディスクファイルサイズが3倍になるが、各記録期間中のデータレンジが効果的に表される。
【０１５０】
2.7 コンフィギュレーションマネージャ
コンフィギュレーションマネージャコンポーネントは、他のコンポーネントがディスク上のファイルからコンフィギュレーションパラメータを読み込むのに用いてもよい標準的な方法を提供する。任意の数のコンフィギュレーションファイルを使用してよい。
【０１５１】
コンフィギュレーションマネージャは、各行にコメントまたはコンフィギュレーション値を有する定様式テキストファイルを読み込む。各コンフィギュレーション値は、名前、データタイプ、およびデータ値で構成される。コンポーネントは、値名を提供することによってコンフィギュレーションマネージャをクエリし、それに応じてデータタイプおよびデータ値を得る。
【０１５２】
2.8 シミュレーションマネージャ
シミュレーションマネージャは、マシンハードウェアを現実的なシステムタイミングでエミュレートできるフレームワークを提供する。シミュレーションマネージャは、シミュレーションコンポーネントが、リアルタイムとともにロックステップで進行する仮想時間を管理することを可能にする。
【０１５３】
例として、1バイトの情報の直列伝送を取り上げる。大まかな程度の忠実度において、これは1つのC変数から別のC変数にバイトをコピーすることによってシミュレートできる。これを行うのに必要な実計算機時間は非常に短く、バイトの直列伝送が9600ボーで要する時間すなわち1042マイクロ秒よりはるかに速い。
【０１５４】
シミュレーションマネージャは、バイトコピー後に1042マイクロ秒の仮想時間遅延を加えることによって開発者が基本的なバイトコピーモデルを拡張することを可能にする。
【０１５５】
3 マシン管理サービス
マシン管理サービスは、マシンハードウェアを直接制御またはシミュレートし、あらかじめ定義された血液処理プロトコルに基づいてハードウェア制御を自動化し、かつ、マシンのオペレータ制御を可能にするインターフェースを提供する、ソフトウェアコンポーネントの層化階層を提供する。
【０１５６】
マシン管理サービスの最下層は、マシンの埋込み式ハードウェアコントローラの直接制御またはシミュレートされた制御を提供する。これらの埋込み式コントローラの各々は、マシンのPC104 I/Oハードウェアに対する2つの専用接続を有する。1つの接続はPC104障害ハブ安全回路である。もう1つは全二重直列UART通信リンクである。
【０１５７】
マシン管理サービスの中間層は等時性の直列通信プロトコルを提供する。このプロトコルはホストソフトウェアと各埋込み式コントローラとの間で定様式メッセージを高い信頼性で伝送する。各埋込み式コントローラは、定様式のコマンドメッセージの送信を受け、それに対して定様式の状態メッセージをホストソフトウェアに送り返す。コマンドメッセージは埋込み式コントローラによりハードウェア制御に翻訳される。状態メッセージはコマンドの結果をホストソフトウェアに示す。
【０１５８】
マシン管理サービスの最上層は、自動または手動の2つの制御モードのうち1つで作動する。
【０１５９】
自動制御モードでは、あらかじめ定義された血液処理プロトコルが実行される。プロトコルは、順次に行われるマシン命令のリストで構成される。オペレータインターフェースは、開始、一時停止、再開、または中止というプロトコル制御オプションを可能にする。プロトコルが開始されたら、オペレータは手動制御モードを開始できるようになる前に、プロトコルを中止させるかまたはプロトコルが正常に完了するまで待つかのいずれかをしなければならない。
【０１６０】
手動制御モードでは、オペレータインターフェースは個々のハードウェア要素の制御を可能にする。例えば、流体管理経路弁を開閉させること、遠心分離機の速度を変更すること、またはバーコードを読ませることができる。手動制御モードは、検査または診断用に意図されており、マシンサービス担当者またはマシン製造担当者などの特別なオペレータに制限される。
【０１６１】
3.1 PC104マネージャ
PC104マネージャコンポーネントはマシン管理サービス階層の最下層である。それは、各埋込み式コントローラの直列リンクへのホストソフトウェアアクセスを提供し、かつ、障害ハブ回路状態の読取り専用ビューを与える。
【０１６２】
PC104マネージャコンポーネントは、PC104インターフェースと直接通信する唯一のものである。PC104ハードウェアがない場合は、そのオペレーションおよび埋込み式コントローラのオペレーションがシミュレートされる。
【０１６３】
3.1.1 直列リンクI/O
各コントローラの直列通信リンクは、不定様式バイトストリームのペアとして次の高層のマシン管理サービスに呈示される。これは、パケットまたはメッセージなどいかなるバイトパターンも認識することなくバイトが処理されることを意味する。
【０１６４】
埋込み式コントローラへの下流リンクは伝送キューによって呈示される。埋込み式コントローラからの上流リンクは受信キューによって呈示される。これらのキューへのアクセスを与えられるのは通信マネージャのみである。
【０１６５】
空でない伝送キューがある場合は必ず、PC104マネージャがバイトストリームデータをそのキューから適切なPC104レジスタにコピーする。
【０１６６】
空でないPC104ハードウェア受信バッファがある場合は必ず、割込みが生成される。ホストソフトウェアは、ハードウェアの受信バッファから（PC104レジスタを介して）適切な受信キューにバイトストリームデータをコピーすることによって割込みに反応する。このことは次に、新しいストリームデータの処理が必要であることをより高い層にアラートする。
【０１６７】
3.1.2 読取り専用の障害ハブ状態
障害ハブ状態は読取り専用の32ビット整数としてより高次のマシン管理サービスに呈示される。障害ハブ状態へのアクセスを与えられるのは障害マネージャコンポーネントのみである。
【０１６８】
32ビット整数の各ビットは、個々のコントローラの障害ハブ通知の状態を表す。1のビットは、障害ハブがすべての埋込み式コントローラをリセットさせていることを示すMFLT状態を表す。0のビットは、正常であるMOK状態を表す。
【０１６９】
障害ハブハードウェアの状態読出しロジックは、第一のポートがMFLT状態に入った場合にすべての障害ハブポートの状態を保存する同期回路である。これらの状態値はPC104レジスタを介して読み取られ、読取り専用の32ビット状態整数を生成する。
【０１７０】
3.1.3 シミュレーション
ハードウェアシミュレーションが3つの下層ソフトウェアコンポーネントによって提供される。これらは、各PC104 I/Oボード、各ケーブル、および各埋込み式コントローラをシミュレートする。
【０１７１】
PC104 I/OボードハードウェアはPCBレベルでシミュレートされ、UARTバッファ内で生じるタイミング遅延を模倣するとともにシリアルボーレートをエミュレートする。PC104レジスタのシミュレーションはより高い層へのインターフェースを提供する。直列リンクI/Oおよび障害ハブ信号のシミュレーションはケーブルシミュレータへのインターフェースを提供する。
【０１７２】
システムケーブルはそれぞれ個別にシミュレートされて、物理的なプラギングおよびアンプラギングを模倣するとともに、電気雑音によるビットエラーを調べることを可能にする。より高層のケーブルシミュレーションの修正バージョンは埋込み式コントローラシミュレータに受け渡される。
【０１７３】
各埋込み式コントローラは個別にシミュレートされて、メッセージ処理遅延を模倣するとともに、適切な状態メッセージを提供する。埋込み式コントローラのシミュレーションには、モーター慣性またはソレノイド切替遅延など、制御されたハードウェア反応のシミュレーションが含まれ得る。
【０１７４】
3.2 通信マネージャ
通信マネージャは各コントローラについて等時性の直列通信プロトコルをインプリメントする。プロトコルはホストソフトウェアと1つのコントローラとの間の通信を指定する。通信マネージャは各コントローラについてプロトコルを独立にインプリメントする。
【０１７５】
次の高層へのインターフェースは各コントローラに対するメッセージキューのペアである。1つはそのコントローラ向けの定様式のコマンドメッセージを保持する伝送キューである。もう1つは、元のコマンドメッセージの各々に対してコントローラが返した定様式の状態メッセージを保持する受信キューである。これらのキューへのアクセスを与えられるのはコントローラマネージャのみである。
【０１７６】
次の低層へのインターフェースはPC104マネージャである。各コントローラについて不定様式バイトストリームのペアが存在し：1つはコントローラへの下流であり、1つはコントローラからの上流である。
【０１７７】
ホストソフトウェアは通信のマスタである。ホストソフトウェアは、どのコマンドパケットに対しても、状態パケットの形態による即座の反応がスレーブ（コントローラ）からあることを期待する。ホストソフトウェアは、コマンドのパーズおよび作用が無秩序に行われないことを期待する。ホストソフトウェアは、スレーブがパケットを最高速度で同時に（全二重通信）かつ連続的に伝送および受信できることを期待する。ホストソフトウェアは、スレーブが請求されていないパケットを決してホストソフトウェアに送らないことを期待する。
【０１７８】
等時性の直列通信プロトコルは、マシンの安全に不可欠な2つのサービスを提供する。
1) 信頼性の高いデータ伝送
2) 障害検出および回復
【０１７９】
プロトコル仕様文書は、すべてのコントローラがサポートしなければならない基本的なコマンドメッセージのセットおよび反応して生成される状態メッセージについても詳しく示す。これらには、コントローラのハードウェア障害ハブ通知を開始させる初期化コマンドが含まれる。各コントローラにユニークなコマンドは基本プロトコル仕様の補遺において指定される。
【０１８０】
3.2.1 等時性の定義
等時性とは、データが特定の時間的拘束内に送達されなければならないプロセスを指す。例えば、マルチメディアストリームは、ビデオデータが表示と同じ速さで確実に送達され、かつ音声がビデオと確実に同期するように、等時性の伝送機構を必要とする。
【０１８１】
等時性は、データストリームをランダムなインターバルで分けることができるプロセスを指す非同期性、およびデータストリームを特定のインターバルでのみ送達できる同期プロセスと対比され得る。等時性サービスは同期サービスほど厳格ではないが、非同期サービスほど緩やかでもない。
【０１８２】
3.2.2 信頼性の高いデータ伝送
等時性の直列通信プロトコルにおけるデータ伝送の基本単位は情報の定様式パケットである。パケットフォーマットは、全体として、プリアンブル、ヘッダ、任意メッセージ、および巡回冗長符号（CRC）という4つの部分で構成される。
【０１８３】
プリアンブルはすべてのパケットに対する固定バイトパターンであり、新しいパケットの開始を通知するのに用いられる。ヘッダはパケットタイプ、メッセージ長、およびシーケンスナンバーを指定する。任意メッセージは指定された長さ（メッセージがない場合はゼロ）の任意のバイトパターンであってよい。CRCはヘッダおよびメッセージのバイト値に基づいて計算されたバイト値である。CRCは、受信されたパケットが伝送中に雑音によって破損したか否かを判定するのに用いられる。
【０１８４】
局所的に伝送された元のMSGタイプのパケットの各々について、プロトコルはそのパケットのECHOタイプバージョンを送り返すようリモートエンドに要求する。元のMSGパケットのメッセージは、ホストソフトウェアのコマンドメッセージまたはコントローラの状態メッセージであってもよい。ECHOパケットは同じシーケンスナンバー、メッセージ長、および任意メッセージを有するが、異なるパケットタイプフィールド（ECHO）およびCRCを含む。
【０１８５】
ECHOパケットを受け取ると、ローカルエンドは元のMSGパケットのメッセージ長および任意メッセージをエコーされたコピーと比較する。それらがマッチする場合、ローカルエンドは、正しいエコーが受信されたことを知らせるため特別なAACKタイプのパケットを送信する。これはリモートエンドに、元のMSGパケットのメッセージをさらにパーズしかつこれに基づいて作用してもよいことを示す。そうでない場合は、リモートエンドが元のMSGパケットを無視しなければならないことを示すため、NACKタイプのパケットが送信される。AACKパケットまたはNACKパケットは元のMSGパケットと同じシーケンスナンバーを有する。
【０１８６】
ホストソフトウェアと埋込み式コントローラとの間の通信を完了するのに必要なトランザクションとして、通常は6パケットのトランザクションが存在する。
1：ホストソフトウェアがコマンドMSGパケットを送信し、コントローラはAACKまたはNACKが受信されるまでこのMSGを保持する
2：コントローラがコマンドECHOパケットを送信する
3：ホストソフトウェアがAACKパケットを送信し、コントローラは保持されたコマンドMSGをパーズしかつこれに基づいて作用する
4：コントローラが、コマンドMSGのパージングおよびアクションの結果を含む状態MSGパケットを送信する
5：ホストソフトウェアが状態ECHOパケットを送信する
6：コントローラがAACKパケットを送信する
【０１８７】
NACKパケットまたはCRC失敗に関連する異常なトランザクションはプロトコル仕様文書に詳述されている。エラー回復は、元のコマンドMSGパケットまたは状態MSGパケットの再送を必然的に伴う。等時性のデッドラインタイムアウトを超えてエラー条件が存続する場合は、障害条件が通知される。
【０１８８】
パケットヘッダ中のシーケンスフィールドはホストソフトウェアによってのみ使用される。ホストソフトウェアは新しいコマンドを生成するたびにシーケンスフィールドに新しい値を生成する。これは、同一のコマンドおよびそれらによって生じる状態メッセージを互いに区別できるようにするためである。シーケンスフィールドはコントローラマネージャによって管理される。
【０１８９】
3.2.3 障害検出および回復
直列プロトコルの等時性の性質は、通信障害を検出するためホストソフトウェアおよびコントローラの両方によって用いられる。通信障害は、ソフトウェアのロックアップもしくはリモートエンドのリセット、またはハードウェアの接続の問題のいずれかによって生じる。接続の問題としては、電気雑音によるデータの破損、間欠的な接続、偶然または意図的な切り離し、および通信コンポーネントの破損または欠陥などがある。
【０１９０】
ホストソフトウェアは、6パケット交換が制限時間内に完了することを期待する。完了しない場合、ホストソフトウェアは、スレーブをもはや制御できないと想定する。ホストソフトウェアは障害マネージャに障害を報告し、これにより継続中のすべてのマシンオペレーションが停止する。
【０１９１】
コントローラは、ホストソフトウェアが通信を維持するためのコマンドを常に送信していると期待する。コントローラが制限時間内に新しいコマンドをパーズしない場合、コントローラはハードウェア障害ハブに障害を通知し、これにより継続中のすべてのマシンオペレーションが停止する。
【０１９２】
3.3 コントローラマネージャ
コントローラマネージャはホストソフトウェアに2つのサービスを提供する。
1) 埋込み式コントローラとの定期的な自動通信
2) マシンハードウェアの直接制御および状態クエリのすべてを提供する関数コールAPI
3) 各コントローラに対する冗長安全エンフォースメント
【０１９３】
コントローラマネージャはホストソフトウェアコンポーネントの4つとインターフェースする。低層のインターフェースは通信マネージャを用いて埋込み式コントローラに対して直接的にコマンドおよびクエリを行う。高層のインターフェースは装置マネージャ、プロトコルマネージャ、およびマシンマネージャによって共用される。
【０１９４】
より高層の3つのコンポーネントが矛盾するコマンドをハードウェアに提供することを防ぐため、いくつかのAPI関数へのアクセスは1度に1つのコンポーネントにのみ与えられる。これらの関数にアクセスするには、より高層のコンポーネントは、自分自身をオーナーとしてコントローラマネージャにレジスタすることに成功しなければならない。レジストレーションが失敗する場合は、別のコンポーネントがすでにオーナーになっている。コンポーネントはいつでもオーナーシップを放棄できる。
【０１９５】
3.3.1 自動通信
等時性の直列通信プロトコルは、各埋込み式コントローラが、そのタイミングデッドラインによってもたらされるレートより速い定期的なレートでコマンドメッセージをパーズしかつこれに基づいて作用することを要求する。ホストソフトウェアが各デッドラインの満了前に新しいコマンドを送信することに失敗すると、ハードウェア障害ハブによるすべてのコントローラのリセットが行われる。
【０１９６】
コントローラマネージャは、コントローラ状態クエリコマンドの連続ストリームを生成することによって、定期的な通信タイミングの要件を満たす。これらコマンドの結果は、システムハードウェア状態の包括キャッシュを維持するのに必要なデータを通信マネージャに提供する。この状態キャッシュはリアルタイムで更新される。
【０１９７】
3.3.2 関数コールAPI
コントローラマネージャは、通信マネージャに関数コールインターフェースを提供することによって、埋込み式コントローラとのより高層の通信を大幅に単純化する。
【０１９８】
各タイプのコントローラについて、コントローラマネージャは、そのコントローラのために通信マネージャから使用できるユニークなコマンドをインプリメントするAPI関数のカスタム化されたセットを提供する。API関数は一般的なコントローラコマンド用にも提供される。
【０１９９】
例えば、コントローラマネージャは、遠心分離機コントローラに対して、遠心分離速度を設定およびリードバックする、アクセスドアをロックおよびアンロックする、振動レベルを読み取るなどの関数のグループを提供すると考えられる。
【０２００】
別の例として、コントローラマネージャは、流体管理コントローラに対して、弁の状態を変更およびリードバックする、与えられた光学検出チャネルにおいてヘマトクリット値を読み取る、指定された体積の流体を蠕動ポンプから送達するなどの関数のグループを提供すると考えられる。
【０２０１】
コントローラマネージャがない場合、コントローラとのより高層の通信はパケット式になると考えられる。コントローラのハードウェア状態を変更またはクエリするためにより高い層が必要となるたびに、関連情報のパケットを構築し、それを通信マネージャに送信し、かつ通信マネージャがコントローラの状態パケットを受信および転送するまで待たなければならないことになる。
【０２０２】
パケット交換法は煩雑であり、かつ、有界ではあるものの確定的ではない比較的長い時間にわたって待つことを伴う。パケット交換法はまた、より高い層が直列プロトコルのタイミング要件と密接に関連することを要求する。
【０２０３】
コントローラマネージャはその代わりに、より高い層が単純なプログラム関数コールを作ることを可能にする。これらがより高い層を遅延させる時間はわずかである。通信マネージャの自動通信機能は、より高い層をあらゆるタイミング要件から完全に分離する。
【０２０４】
一般的に、コマンドおよびクエリという2つのタイプのAPI関数がある。コマンド関数はアクセスにオーナーシップを必要とする関数である。クエリ関数はオーナーシップなしでアクセスできる。
【０２０５】
クエリタイプの関数は、ハードウェア状態に関する通信マネージャのリアルタイムキャッシュから関連情報を返す。これは、コントローラと即時パケット交換する必要性を迂回し、その代わりに、自動通信機能によって作られた直近の同一クエリの結果を返す。
【０２０６】
コマンドタイプの関数は実行される頻度がクエリ関数よりはるかに少ない。ほとんどの場合、より高い層は、特定のハードウェア状態が生じるのを待つか、時間遅延が満了になるのを待つか、またはオペレータ入力を待ちながら、ハードウェアをモニタしている。したがってコマンド関数は、通常の自動通信に対する割込みに相当する。
【０２０７】
コマンド関数がコールされると、そのパラメータリストが一時記憶域にコピーされ、後の処理用にキューされる。コントローラマネージャは、次に自動通信機能のサービスを行う場合に、コマンドキューをチェックし、そのコマンドをコマンドパケットとして通信マネージャに発行する。複数のコマンドがキューされていてもよく、別の自動クエリが発行される前にすべてのコマンドが発行される。
【０２０８】
3.3.3 冗長安全エンフォースメント
コントローラマネージャは、各コントローラがエンフォースするものと同じセットの安全規則をエンフォースする。規則はコントローラの各タイプについて異なり、かつカスタム化される。
【０２０９】
コントローラマネージャは、受け取ったコマンド関数入力パラメータのすべてについて、コマンドをキューする前に安全規則に照らした妥当性確認を行う。例えば、より高い層がコマンド関数をコールして遠心分離速度を最大速度限界より高い値に設定しようとした場合、関数はより高い層にエラーコードを返し、コマンドはキューされない。それでもコマンドがキューされた場合は、コントローラが同じ理由で遠心分離速度コマンドを拒否し、状態パケットにエラーコードを返す。
【０２１０】
コントローラマネージャは、受け取ったハードウェア状態、クエリ、およびコマンド結果のすべてについて、安全規則に照らした妥当性確認を行う。例えば、遠心分離圧力の読取り値が最大圧力限界を上回っている場合は、障害マネージャにエラーが報告され、これにより継続中のすべてのマシンオペレーションが停止する。正常な状況下において、コントローラはすでにこのエラーを検出しかつハードウェア障害ハブに障害を通知しているはずである。
【０２１１】
3.4 装置マネージャ
装置マネージャはコントローラマネージャの上に構築され、複数のコントローラの状態に関連する安全規則を提供する。装置マネージャはまた、コントローラ間の調整も提供する。これには、1つの装置マネージャAPI関数コールによって開始される、段階化された一連のコントローラアクションおよび安全規則チェックをインプリメントする有限状態機械が含まれ得る。
【０２１２】
装置マネージャのより低層のインターフェースはコントローラマネージャである。その上層のインターフェースは関数コールAPIであり、これはプロトコルマネージャおよびマシンマネージャにより共用される。
【０２１３】
コントローラマネージャは通信マネージャの上に構築されたインテリジェントな自律シェルである。コントローラマネージャは各タイプのコントローラのユニークな機能を理解し、かつそれに基づいて各コントローラに対する安全規則をエンフォースする。コントローラマネージャのオーナーがロックアップするかまたはさもなければコントローラマネージャに関数コールを行うことを停止した場合、安全規則は、障害が生じた場合にすべてのマシンオペレーションを停止させるだけの十分なインテリジェンスを提供するように思われる。しかしこれらの規則は、すべての障害を検出できるわけではない。
【０２１４】
コントローラマネージャに欠けているのは個々のコントローラ間における調整されたあらゆるインタラクションであり、このことは、そうでなければ防げる問題につながる可能性がある。1つの例がこの点を示す。
【０２１５】
蠕動ポンプ制御が1つのコントローラ上にありかつ流体弁制御が別のコントローラ上にあるように流体管理ハードウェアがインプリメントされていると想像されたい。常識から、ポンプが駆動される前に、ポンプ入力部の弁が流体供給源に接続され、ポンプ出力部の弁が流体容器またはアウトレットに接続されることが要求される。
【０２１６】
コントローラマネージャのポンプコントローラ安全規則は、ポンプの過負荷または焼付きを検出するため、最大速度限界および速度エラー限界を含むものと思われる。コントローラマネージャの弁コントローラ安全規則は、弁の状態変化リクエストと弁の状態変化の確認との間に短い遅延を許容するものと思われる。
【０２１７】
さらに、ポンプ入力弁が流体供給源に対して開いており、ポンプ出力弁が閉じており、かつ次にポンプが回転するようコマンドされたと想像されたい。ポンプは回転し、流体経路コンポーネントが破裂するまで出力部に圧力が蓄積すると思われ、これにより、血液がマシンから噴出してオペレータの眼に入る可能性がある。
【０２１８】
コントローラマネージャの単純な規則はこのことを防げない。障害が生じる前にポンプの速度エラー限界が超過されれば、破裂を防げる時間内にポンプが停止され得るかもしれない。出力弁が圧力によって非自発的に開けば、これは安全規則に違反することになるが、しかし問題が生じた後にしか起こらない。
【０２１９】
この場合、装置マネージャは、ポンプ速度を設定するためのAPIコマンド関数を有していてもよい。装置マネージャ安全規則は、弁が正しく設定されていない場合にエラーを返す。装置マネージャは、まず弁の状態を判定するためコントローラマネージャをクエリし、次に、もし弁の状態がOKであればコントローラマネージャにポンプコマンドを発行する。これは複数コントローラ調整の単純な例である。
【０２２０】
あるいは、装置マネージャは、流体分配シーケンスを開始するAPIコマンド関数、およびそれに伴う、分配が完了したか否かを示す状態クエリ関数を有していてもよい。分配コマンド関数は、入出力弁設定、ポンプ速度、および分配体積に関するパラメータを有する。この関数は有限状態機械として以下の段階でインプリメントしてもよい。
【０２２１】
関数パラメータの弁設定が安全規則を満たすことを確認する。弁およびポンプ速度の現在の設定を取得するためコントローラマネージャをクエリする。ポンプ速度がゼロであることを確認する。弁が正しく設定されていない場合は、適切なコントローラマネージャコマンド関数を実行して設定を訂正する。設定を再度確認する。適切なコントローラマネージャ関数を実行してポンプを正しい回転数だけ回転させる。ポンプが停止したか否かを判定するためコントローラマネージャをクエリし、停止するまでこれを継続する。ポンプが正しくない位置で停止した場合は障害マネージャに通知する。適切なコントローラマネージャコマンド関数を実行して入出力弁を閉じる。変化を確認する。分配オペレーションが完了したことを示すように装置マネージャの状態フラグを設定する。
【０２２２】
コントローラマネージャは、その制御関数にアクセスするためにオーナーシップを必要とする。装置マネージャは、その制御関数のいくつかをインプリメントするためにこれらへのアクセスを必要とする。装置マネージャは、コントローラマネージャのオーナーシップを争う代わりに、プロトコルマネージャまたはマシンマネージャに対するプロキシとして作用する。プロトコルマネージャが装置マネージャ制御関数をコールする場合、そうであり、装置マネージャは、それがコントローラマネージャ制御関数をコールする場合にプロトコルマネージャとして作用する。
【０２２３】
インプリメンテーションの問題が生じる。コントローラマネージャ制御関数が装置マネージャによってのみコールされるべきであるならば、コントローラマネージャは、プロトコルマネージャおよびマシンマネージャが制御関数にアクセスできないようにすべきである。
【０２２４】
前述の例を用いると、コントローラマネージャのポンプ制御関数は、以下の2つの理由から、プロトコルマネージャおよびマシンマネージャからアクセス可能であるべきでない。1) コントローラマネージャのみでは安全規則の完全セットがインプリメントされない、2) 装置マネージャがプロトコルマネージャまたはマシンマネージャのためにポンプを制御しているのであれば、より高層のマネージャは、コントローラマネージャを直接コールすることによって矛盾する制御を提供することを許容されるべきではない。
【０２２５】
3.5 プロトコルマネージャ
プロトコルマネージャはホストソフトウェアに3つのサービスを提供する。
1) マシンハードウェアの自動制御
2) 自動化のオペレータ制御
3) 限られた持続時間の停電からの回復
【０２２６】
プロトコルマネージャのより低層のインターフェースは装置マネージャおよびコントローラマネージャであり、これらはマシン制御を提供する。より高層のインターフェースはオペレータインタラクションを提供するマシンマネージャである。
【０２２７】
3.5.1 自動マシン制御
プロトコルマネージャは、ハードドライブに保存されているプロトコルファイルからの命令を処理することによってマシンハードウェアの自動制御を提供する。
【０２２８】
プロトコル命令は、開始と終了とを有するバッチオペレーションに相当する。命令は開始から終了まで順次に処理され、各命令は次の命令に移る前に成功して完了する。プロトコル命令処理中に生じた、いかなる予期されない条件またはエラーも、プロトコルの中止をもたらす。
【０２２９】
プロトコルが中止されると、プロトコルマネージャは処理中の命令を停止し、その回復シーケンスにスキップする。正常な条件下において、中止は起こらず、プロトコルマネージャは最後のプロトコル命令を処理した直後に回復シーケンスをランする。
【０２３０】
回復シーケンスは、使い捨てセットを空にしかつマシンをオペレータが操作するうえで安全な状態にするのに必要なマシンオペレーションを行う。これにより、オペレータは使い捨てセットを取り出すことおよび新しいプロトコルの準備をすることが可能になる。回復シーケンスのオペレーションには、ウェットセットの使い捨て容器を空にして廃棄すること、遠心分離処理バッグを空にして廃棄すること、および遠心分離機を減圧することなどがある。
【０２３１】
プロトコル命令には、自動化一時停止およびマシン制御という2つのタイプがある。いくつかの命令は、流体体積、供給流体の選択、または移動先の流体経路などの属性を指定するパラメータを伴う。
【０２３２】
自動化一時停止命令は、オペレータが再開コマンドを表明するのをプロトコルマネージャに待たせることによって、マシン要求によるオペレータインタラクションの基礎を提供する。再開コマンドが与えられたら、プロトコルマネージャは残りのプロトコル命令の処理を続ける。一時停止命令は、特定のタイプのユーザーインタラクションが必要であることを指定するために用いられ得る整数パラメータを伴う。
【０２３３】
例えば、整数パラメータ値 3 を用いて、「オペレータは今バッグ1のバーコードをスキャンしなければならない」を意味してもよい。タッチスクリーンを制御するコンソールマネージャがマシンマネージャをクエリし、プロトコルマネージャが位置3で一時停止していることを示す状態を受け取る。コンソールマネージャは次に、オペレータにアラートするためのメッセージを表示し、かつ次に、バーコードリーダーのモニタリングを開始してもよい。バーコード情報の処理後、コンソールマネージャはマシンマネージャにプロトコル再開コマンドを送信する。マシンマネージャはプロトコル再開コマンドをプロトコルマネージャに転送する。
【０２３４】
マシン制御命令は、ハードウェア制御とタイミング制御という2つのクラスに分けられる。いくつかのマシン制御命令は、複数のオペレーションを並列で実行できるよう、マッチドペアでインプリメントされる。
【０２３５】
ハードウェア制御命令は、装置マネージャおよびコントローラマネージャによって利用可能にされた関数に直接マッピングする。例えば、「弁開放  生理食塩水」という命令は、生理食塩水をパラメータとするコントローラマネージャの弁開放関数へのコールとしてプロトコルマネージャによりインプリメントされる。プロトコルマネージャの命令は必ずしもテキストとしてプロトコルファイルに保存されていなくてもよく、バイナリフォーマットで保存されていてもよいことに注意されたい。
【０２３６】
タイミング制御命令には遅延および中止という2つのタイプがある。それぞれ、残り時間がゼロまで減った場合に満了となるカウントダウンタイマとしてインプリメントされる。相違点は、タイマの満了時に何が起こるかである。
【０２３７】
遅延タイマは、タイマが満了になった場合に次のプロトコル命令が処理されることを許容する。中止タイマは、タイマが満了になった場合にプロトコルを中止させる。通常は、中止タイマが満了になる前に中止タイマの停止命令が処理され、中止タイマの満了は何か予期されないことが起こった場合にのみ生じる。
【０２３８】
すべてのプロトコル命令は、次のものが実行される前に各々が完全に実行されるので、順次的である。このことは、プロトコルのランに要する時間を大幅に延長させる、性能の問題につながることがある。遠心分離速度に勾配をつける、遠心分離機に大きな体積を分配する、または遠心分離機を加圧するなど、いくつかのマシン制御オペレーションは完了に比較的長い時間を要する。これらのオペレーションの各々が単一のプロトコル命令でインプリメントされるならば、たとえそれらを同時に行う必要があっても、各々が直列に行われなければならないことになる。
【０２３９】
したがって、いくつかのオペレーションを命令のマッチドペアとしてインプリメントする必要性が生じる。各マッチドペアは開始命令を有する。各マッチドペアはまた、停止命令または待機命令のいずれかも有する。したがって可能なマッチドペアは開始‐停止または開始‐待機である。これらの命令は、停止命令または待機命令のいずれも実行されるより前に複数の開始命令を実行できるようにインプリメントされる。
【０２４０】
例として、開始‐停止命令ペアが、エアコンプレッサの電源を制御するかまたは中止タイマを制御してもよい。開始‐待機命令ペアの1例は、遠心分離機を始動させ、かつ後にそれが最高速度に達するまでプロトコルを待機させてもよい。その間、プロトコルは任意の数の他の命令を実行してもよい。
【０２４１】
3.5.2 オペレータ制御
プロトコルマネージャは、コンソールマネージャによって用いられて自動化のオペレータ制御を可能にしうる、マシンマネージャへのインターフェースを提供する。同インターフェースは、プロトコルファイルの選択、開始、一時停止、再開、および中止という、限られた制御オペレーションのセットを提供する。同インターフェースはまた、命令処理状態、現在の命令およびパラメータ、プロトコル開始後の時間、プロトコル終了までの推定残り時間という、限られた状態クエリオペレーションのセットも提供する。
【０２４２】
プロトコルファイル選択インターフェースは、利用可能なプロトコルファイル名のリストを生成することを可能にする。ファイルはすでにハードディスク上にあり、プロトコルマネージャはプロトコルファイルを追加または削除する能力を有さないことに注意されたい。ファイルリストはタッチスクリーン上に表示することができ、かつこれは、オペレータがそれらの1つを選択することを可能にする。プロトコルが選択された後、インターフェースは、オペレータがプロトコルを開始することを可能にする。
【０２４３】
プロトコルが開始された後でかつそれが終了する前の任意の時点において、インターフェースは、オペレータがプロトコル命令処理を一時停止または中止することを可能にする。一時停止は、現在の命令が実行を終了した後に認識され、かつインターフェースの再開コマンドが与えられるまで、プロトコルマネージャが次の命令を実行することを防ぐ。中止は、現在の命令が完了するのを待たない。中止は、プロトコルマネージャをただちにその回復シーケンスにスキップさせる。回復シーケンスは一時停止または中止できない。
【０２４４】
プロトコルマネージャが自動化一時停止命令を実行する場合、インターフェースは、オペレータが命令処理を再開することを可能にする。
【０２４５】
プロトコルマネージャの命令プロセッサは有限状態機械としてインプリメントされる。これは、よく定義された状態のセットにおいて命令プロセッサがオペレーションし、かつ、状態間の移行が命令処理イベントおよびオペレータインターフェースイベントに反応して生じることを意味する。命令プロセッサの状態は整数値として表現される。
【０２４６】
プロトコルマネージャインターフェースは、状態クエリに反応して命令プロセッサの状態整数へのアクセスを提供する。この値は主として、命令プロセッサが開始、ラン、一時停止、もしくは中止されたか、回復シーケンス内にあるか、または終了したか否かの判定に用いられる。
【０２４７】
同インターフェースはまた、プロセッサの現在の命令およびパラメータも提供する。自動化一時停止命令の場合、パラメータを用いて、必要なインタラクションを提供するようにオペレータをガイドすることができる。全体として、現在の命令の情報を用いて、マシンオペレーションのアニメーションをタッチスクリーン上に提供できる。
【０２４８】
マシンが配備される製造環境において、オペレータは複数のマシンを制御している可能性がある。プロトコルマネージャインターフェースは、どのマシンが次に終了するかを判定するためにリアルタイムで用いることのできる推定残り時間をオペレータに提供する。
【０２４９】
3.5.3 停電からの回復
プロトコルマネージャは、プロトコルが停電により一時的に中断され、かつ電力回復後に再開することを可能にするため、プロトコル命令の処理状態およびその結果としてのマシンハードウェア状態の変化に関する十分な情報とともに、ハードドライブ上にファイルを維持する。
【０２５０】
一時的停電からの回復のインプリメンテーションは、他をはるかに凌ぐ、プロトコルマネージャの最も複雑な機能である。関連情報の経過を追跡しかつそれをハードドライブに保存することは比較的容易である。電力回復後にそれを正しく解釈することは複雑になりうる。
【０２５１】
停電は、ハードドライブのファイルシステムを破損させるか、または電力が失われた時に書き込み中であった任意のファイルを消去させる可能性がある。このことは、電力回復後にプロトコルマネージャが再開した場合にファイルデータ破損またはファイル損失を検出できるよう、プロトコルマネージャが冗長な回復情報を別のファイルに維持するという必要性を生じさせる。
【０２５２】
中断後にプロトコルを再開するのに必要なすべての状態情報は、データ破損の検出に使用できるCRC値とともに、単一のファイル内にユニットとして保存される。同ファイルは回復ファイルと呼ばれる。状態情報には、タイムスタンプ、プロトコルファイル名、現在実行中の命令のプロトコルファイル内の位置、命令処理状態、制御可能なすべてのハードウェアの状態、およびすべてのフィードバックセンサーの読出し情報が含まれる。
【０２５３】
新しい回復ファイルが頻繁にハードディスクに書き込まれる。新しいファイルは、新しい命令の開始後10秒ごとに作成されて長い命令の間に進行中の状態変化を捕捉するとともに、プロトコル命令が完了するたびにも作成される。プロトコルマネージャは、最大3つの直近の回復ファイルを維持し、かつ新しいファイルが第三の回復ファイルならば、新しいファイルが書き込まれた直後に最も古い回復ファイルを削除する。
【０２５４】
電力が失われた後、プロトコルマネージャは各回復ファイルを開き、ファイルが破損しているか否かを確認するためファイルのデータをファイルのCRCに対してチェックする。もし破損していればそのファイルは削除される。最新の回復ファイルが、ハードウェア状態を回復しプロトコルを再開するための開始点として用いられる。
【０２５５】
最初は、回復は単純に、ハードウェアを回復ファイルに記録された状態に回復させ、プロトコル命令プロセッサを記録された状態に回復させ、かつプロトコル命令処理を再開することを伴うように見えると思われる。しかし、先に完了された命令をプロトコルマネージャが繰り返すことを必要とする状況が存在する。これは、プロトコルが、直近の回復ファイル内のものとは異なる命令から再開することを意味する。
【０２５６】
この場合は、必要なハードウェア状態および正しい命令状態を記録した、より古い回復ファイルを用いることが望ましいと思われるが、このファイルは停電前に旧式のファイルとして削除されている可能性がある。代わりに、プロトコルマネージャは、繰り返さなければならない命令の影響を巻き戻さなければならない。
【０２５７】
この問題の1つの好例は、遠心分離により血液が上清から分離された後、マシンが上清を捨てるために遠心分離処理バッグから絞り出している間に、電力が失われた場合である。回復ファイルは、遠心分離速度が絞り出し速度であることを示すと思われるが、この速度は血液を上清から再び迅速に分離するには低すぎる。したがってプロトコルマネージャは、遠心分離を開始した命令までさかのぼる必要があると思われる。
【０２５８】
この例をより複雑にしたものは、流体管理ハードウェアが上清‐血液間の界面を検出するところまで1つまたは複数の遠心分離処理バッグがすでに絞り出された後に、電力が失われた場合である。破損していない最新の回復ファイルは、このことが起こったことさえ示していない可能性がある。これは、遠心分離前に界面検出器チャネルをフラッシュする必要があることを意味すると思われる。
【０２５９】
3.6 マシンマネージャ
マシンマネージャはマシン管理サービスの最高層であり、ホストソフトウェアのより高層のコンポーネントが利用可能な唯一のマシン制御インターフェースを提供する。
【０２６０】
マシンマネージャのより低層のインターフェースは、プロトコルマネージャ、装置マネージャ、およびコントローラマネージャの組合せである。より高い層はこれらのより低層のインターフェースに直接アクセスすることができず、代わりにマシンマネージャインターフェースを用いなければならない。
【０２６１】
より高層のコンポーネントが矛盾するコマンドをハードウェアに提供することを防ぐため、マシンマネージャのいくつかのAPI関数へのアクセスは1度に1つのコンポーネントにのみ与えられる。これらの関数にアクセスするには、より高層のコンポーネントは、自分自身をオーナーとしてマシンマネージャにレジスタすることに成功しなければならない。レジストレーションが失敗する場合は、別のコンポーネントがすでにオーナーになっている。コンポーネントはいつでもオーナーシップを放棄できる。
【０２６２】
マシンマネージャは、以下のように、根底にあるマシン管理サービスのインターフェースをエクスポートする。
1) 状態クエリインターフェースへの無制限アクセス
2) 制御インターフェースへのオーナー限定アクセス
3) 制御インターフェースは自動モードまたは手動モードに制限される
【０２６３】
マシンマネージャは、根底のインターフェース関数のように見えかつ作用する類似のAPI関数を提供することによって、プロトコルマネージャ、装置マネージャ、およびコントローラマネージャの根底のインターフェースをエクスポートする。API制御関数のマシンマネージャバージョンは、根底の制御関数へのアクセスを許容する前に、オーナーシップおよびモードアクセス規則をインプリメントする。
【０２６４】
マシンマネージャは、オーナーに制御モードを自動から手動およびその逆へと変化させるAPI関数を提供する。制御モードは、根底の制御関数のどれがアクセス可能かを判定する。自動モードでは、プロトコルマネージャの制御関数がアクセス可能であり、装置マネージャおよびコントローラマネージャの制御関数がアクセス不可である。手動モードでは、装置マネージャおよびコントローラマネージャの制御関数がアクセス可能であり、プロトコルマネージャの制御関数がアクセス不可である。
【０２６５】
制御モードが自動か手動かにかかわらず、すべての状態クエリAPI関数が常にアクセス可能である。
【０２６６】
より高い層がマシンマネージャのモードを自動に設定しプロトコルを開始した場合、その高い層は、プロトコルが正常に完了するかまたはその高い層によって中止されるまで、マシンマネージャの制御モードを手動に変更できない。その高い層がプロトコルを開始し、次にマシンマネージャのオーナーシップを放棄し、かつそのプロトコルが終了する前に新しいオーナーがマシンマネージャのモードを変更しようとした場合も、失敗する。
【０２６７】
4 外部インターフェース
ホストソフトウェアの外部インターフェースは、オペレータ制御およびマシンのモニタリングを提供し、かつマシンを血液バンクデータベースに接続する。
【０２６８】
4.1 コンソールマネージャ
コンソールマネージャは、マシンのタッチスクリーンディスプレイ上のグラフィックおよびテキストの形態でマシンのオペレータインターフェースを提供する。テキスト言語はランタイムにおいて選択可能である。
【０２６９】
コンソールマネージャは、初心者、熟練者、および管理者という、オペレータの3段階のレベルをサポートする。
【０２７０】
初心者用オペレータインターフェースは言葉数で説明され、かつ血液処理プロトコル中により多くのインタラクションを必要とする。熟練者用のオペレータインターフェースは、必要なインタラクションのみを実施するよう簡素化されている。これら2つのオペレータレベルは、マシンの自動制御モードのみを使用できる。
【０２７１】
管理者用のオペレータインターフェースは、オペレータが初心者用または熟練者用のインターフェースを選択することを可能にする。管理者用インターフェースは、ユーザー管理およびマシン診断インターフェースを追加する。マシン診断インターフェースはマシンの手動制御モードをインプリメントする。
【０２７２】
コンソールマネージャの自動制御モードの1つの重要な局面は、オペレータが確実に供給源の血液バッグを正しく接続しかつ製剤用の血液バッグを正しくラベル付けするよう、同モードが用いるチェックおよびバランスである。
【０２７３】
4.2 在庫表マネージャ
在庫表マネージャは、血液バンクデータベースに対するマシンのインターフェースを提供する。在庫表マネージャは、一般的なデータベースインターフェースをマシンに提供し、かつこれを、各タイプの血液バンクデータベースで必要とされるカスタムインターフェースにリアルタイムで変換する。在庫表マネージャと血液バンクデータベースとのリンクは両方向性であり、かつ生きたオンライン接続である。
【０２７４】
コンソールマネージャが血液単位識別番号を提供する場合、在庫表マネージャは血液バンクデータベースをクエリし、かつコンソールマネージャに血液単位の血液型および感染症検査結果を返す。血液型が使い捨てセットの血液変換型と適合しない場合、または血液が感染している場合、マシンは血液単位を拒否できる。
【０２７５】
血液処理プロトコルの完了後、コンソールマネージャは在庫表マネージャとインターフェースして、供給源の血液単位の各々が酵素変換性O型（ECO）の血液に変換されたことを血液バンクデータベースに通知する。使い捨てセットのロット番号、オペレータの識別子、または変換時間など、変換に関するさらなる情報もデータベースにアップロードすることができる。データベースは、使い捨てセットの使用情報を用いて、使い捨てセットの在庫表および調達を維持してもよい。
【０２７６】
4.3 ネットワークマネージャ
ネットワークマネージャはローカルネットワークへのTCP/IP接続をマシンに提供する。ネットワークマネージャはコンソールマネージャおよび在庫表マネージャへのカスタムインターフェースを提供する。
【０２７７】
コンソールマネージャに対するネットワークマネージャのインターフェースは、マシンおよびその血液処理プロトコルの状態を遠隔モニタリングすることを可能にする。このことは、遠隔のモニタリングステーションが血液バンク内のすべての血液処理マシンの状態を表示することを可能にする。
【０２７８】
在庫表マネージャに対するネットワークマネージャのインターフェースは、血液バンクデータベースのネットワーク接続の詳細を在庫表マネージャが知る必要性を軽減する。在庫表マネージャは、血液単位の情報など必要とする情報の要求を単純に行い、ネットワークマネージャがそれを提供する。ネットワークマネージャは血液バンクデータベースのコンピュータをロケートし、かつマシンとデータベースとの間で透明な情報配達者として作用する。
【０２７９】
実施例3：障害ハブシステム
以下に、障害ハブシステムの実施例、および前述の1つまたは複数の態様とともに使用する方法を説明する。図9A、図9B、および図9Cに障害ハブシステムを示す。
【０２８０】
概要
障害ハブシステム（図9A〜9Cを参照）は、血液処理コントローラの接続先である障害ハブ装置の集合体である。障害ハブシステム仕様の有用性を一般化するため、以下の用語が定義される。マスタ（MASTER）は障害ハブ装置である。スレーブ（SLAVE）はZQコントローラである。システム（SYSTEM）はすべてのマスタの集合体である。各スレーブは専用のマスタに接続される。いくつかのマスタはどのスレーブにも接続されない。すべてのマスタはシステムに接続される。各スレーブは、スレーブ状態がアイドル（IDLE）であるか、ラン（RUN）であるか、または障害（FAULT）であるかを、接続されたマスタに独立に示す。各マスタは、これもアイドル、ラン、または障害であるマスタ状態を、接続されたスレーブに示す。
【０２８１】
各マスタは、マスタ状態がMFLT（マスタ障害）であるかまたはMOK（マスタOK）であるかをシステムに示す。システムは、システム状態がSYSFLT（システム障害）であるかまたはSYSOK（システムOK）であるかを接続されたすべてのマスタに示す。任意のマスタが障害のスレーブ状態を検出した場合、そのマスタはシステムにMFLTを示す。これにより、システムは接続されたすべてのマスタにSYSFLTを示す。これにより、システム内のすべてのマスタは、それに接続されたスレーブに障害を示す。したがって、任意のスレーブがシステムに障害を示すと、システムはすべてのスレーブに障害を示す。システム SYSFLT状態からの回復を含むシステムオペレーションの詳細を、開放型システム間相互接続の7層ISOモデルに対応した様式で説明する。
【０２８２】
物理層：マスタ‐スレーブ
マスタとスレーブとの間の物理層信号方式はRS485またはRS232のいずれかである。これは、正確に2つであるトランシーバ間に1対1通信を提供する。1つのトランシーバはマスタ上にあり、もう1つはスレーブ上にある。トランシーバは送信機‐受信機のペアで構成される。送信機は物理層ビットをRS485またはRS232の信号レベルに変換する。受信機はRS232またはRS485の信号レベルを検出し、それを物理層ビットに変換する。物理層ビットの値はHIまたはLOのいずれかに指定され、その持続時間は指定されない。トランシーバ間のケーブルが接続されていない場合、受信機はLOを示す。
【０２８３】
物理層: マスタ‐システム
システムの物理層信号はアンド（AND）論理ゲートによりモデル化される。アンド論理ゲートは任意の数の入力および1つのみの出力を有する。いずれかの入力がLOビットの場合、出力はLOビットである。すべての入力がHIビットの場合、出力はHIビットである。MFLT信号およびSYSFLT信号はLOビットにより表される。MOK信号およびSYSOK信号はHIビットにより表される。各マスタ出力はSYSTEM アンドゲート入力に接続される。SYSTEM アンドゲート出力はシステム状態信号であり、すべてのマスタの入力として接続される。システムは、共通のシステム状態信号によって一緒に接続された別々の物理回路の集合体として実現される。ローカルシステム（LOCAL SYSTEM）は物理回路の任意の1つであり、2つまたはそれ以上のマスタの集合体である。ローカルシステム回路において、ローカルシステムアンド（LOCAL SYSTEM AND）論理ゲートは、トランジスタ、離散的論理IC、またはプログラム可能論理ICを用いることによって直接的に実現される。ローカルシステムアンドゲートの出力は、共用システム状態信号に直接接続したドライバの3状態エネイブルを制御する。3状態ドライバは、ローカルシステムが、システム状態信号をLOにしてSYSFLTを示すか、またはシステム出力を影響されないまま残しそれによりSYSOKに寄与するかのいずれかを行うことを可能にする。すべてのローカルシステムがSYSOKに寄与する場合、プルアップ抵抗がシステム状態信号をHIに設定する。マスタ信号およびシステム信号の持続時間は指定されていない。
【０２８４】
データリンク層
マスタとスレーブとの間のデータリンク層信号は、3つの可能な状態のうち1つを示す。それらはアイドル、ラン、および障害である。ラン状態は物理層パルス列によって示される。パルス列はHIビットおよびLOビットの交代サイクルである。交代サイクルは通常、方形波である。HIビットおよびLOビットの各々は、1/16秒以上かつ1/4秒以下の持続時間を有することを許容される。これにより、公称周波数4 Hzである2 Hz〜8 Hzの周波数範囲が許容される。アイドル状態は、持続時間が1/4秒以下のLOビットにより示される。障害状態は2つの方法のうち1つで示される。1つの方法は、持続時間が1/4秒以下のHIビットである。もう1つの方法は、持続時間が1/16秒以上のHIビットまたはLOビットである。
【０２８５】
アプリケーション層
アプリケーション層は、受け取られた状態値の変化および非同期イベントに対するシステム、マスタ、およびスレーブの反応を定義する。非同期イベントは、システム状態、マスタ状態、またはスレーブ状態と独立して、任意の時に生じうる。システム、マスタ、およびスレーブのオペレーションを有限状態機械の面から説明する。
【０２８６】
スレーブ状態マシン
電源オン（POWERON）イベント：
電源オンイベントはオペレーションの開始点であり、リセット（RESET）イベントを生じさせる。
【０２８７】
リセットイベント：
リセットイベントは、スレーブに、マスタに対してアイドルを示させる。
【０２８８】
アイドル状態：
スレーブは外部のスタート（START）イベントが生じるのを待つ。マスタは、指定されない通信方法を用いてスタートイベントを生じさせる。待機中、マスタ状態は無視され、障害イベントも無視される。
【０２８９】
スタートイベント：
スタートイベントは、スレーブに、マスタに対してランを示させる。
【０２９０】
ラン状態：
マスタが障害を示した場合は、リセットイベントが生成される。マスタがアイドルを示した場合は、リセットイベントが生成される。障害イベントは、スレーブに、マスタに対して障害を示させる。
【０２９１】
障害状態：
マスタが障害を示した場合は、リセットイベントが生成される。マスタがアイドルを示した場合は、リセットイベントが生成される。この状態が1秒間のタイムアウトにわたって持続する場合は、リセットイベントが生成される。
【０２９２】
システム状態マシン
電源オンイベント：
電源オンイベントはオペレーションの開始点であり、システムおよびマスタの両方についてリセットイベントを生じさせる。
【０２９３】
リセットイベント：
リセットイベントがシステム状態に直接影響を及ぼすことはない。
【０２９４】
MFLTイベント：
任意のマスタがMFLTを示す場合は、システムがSYSFLTを示す。
【０２９５】
MOKイベント：
すべてのマスタがMOKを示す場合は、システムがSYSOKを示す。
【０２９６】
マスタ状態マシン
リセットイベント：
リセットイベントは、マスタに、スレーブに対してアイドルを示させかつシステムに対してMFLTを示させる。
【０２９７】
（アイドル, MFLT）状態：
マスタはスレーブがアイドルを示すまで待ち、次にマスタはシステムに対してMOKを示す。
【０２９８】
（アイドル, MOK）状態：
スレーブが障害を示す場合、マスタはスレーブに対してアイドルを示しかつシステムに対してMFLTを示す。スレーブがランを示す場合、マスタはスレーブに対して障害を示しかつシステムに対してMFLTを示す。システムがSYSOKを示す場合、マスタはスレーブに対してランを示しかつシステムに対してMOKを示す。
【０２９９】
（障害, MFLT）状態：
マスタはスレーブがアイドルまたは障害のいずれかを示すまで待ち、次にマスタはスレーブに対してアイドルを示しかつシステムに対してMFLTを示す。
【０３００】
同等物
以上の説明は、生物学的、薬学的、および工業的技術の多くの領域において用途を有する、閉鎖系の自動処理装置についてのものである。全体にわたって、血液処理のための特定の用途を説明および参照したが、これは限定を意図したものではない。当業者には、そのような装置をそのような種々の処理に適応できることが理解されると思われ、そのような任意の用途は本発明の範囲内に入ることが意図される。同様に、本発明には、本発明者らおよび他の特許、特許出願、および参考文献に説明されている種々の機械的および電気的処理が組み入れられている。それらは本明細書に引用されており、参照によりその全部が本明細書に組み入れられる。
【図面の簡単な説明】
【０３０１】
【図１】バッグセットシールおよびドアの分解組立図である。
【図２】血液処理装置の遠心分離構成部品の概略図である。
【図３】流体経路の連絡を制御する複数のフロースルー弁を備える流体管理カセットを示した図である。
【図４】遠心分離処理バッグに関する概略図面である。
【図５】バッグに出入りする材料（酵素、緩衝液、流体、および血球）の流れを向上させるよう設計された、処理バッグ設計の種々の修正に関する概略図面である。
【図６】多管腔チューブに関する概略図面である。
【図７】それぞれ、システムのための電気ブロック図およびホストロジックを示した図である。
【図８】ホストソフトウェアアーキテクチャの図である。
【図９】障害ハブシステムを示した図である。
【図１Ａ】
2009506801.tif 000002
【図１Ｂ】
2009506801.tif 000003
【図２Ａ】
2009506801.tif 000004
【図２Ｂ】
2009506801.tif 000005
【図２Ｃ】
2009506801.tif 000006
【図２Ｄ】
2009506801.tif 000007
【図２Ｅ】
2009506801.tif 000008
【図２Ｆ】
2009506801.tif 000009
【図３Ａ】
2009506801.tif 000010
【図３Ｂ】
2009506801.tif 000011
【図３Ｃ】
2009506801.tif 000012
【図３Ｄ】
2009506801.tif 000013
【図４】
2009506801.tif 000014
【図５Ａ】
2009506801.tif 000015
【図５Ｂ】
2009506801.tif 000016
【図５Ｃ】
2009506801.tif 000017
【図６】
2009506801.tif 000018
【図７Ａ】
2009506801.tif 000019
【図７Ｂ】
2009506801.tif 000020
【図８】
2009506801.tif 000021
【図９Ａ】
2009506801.tif 000022
【図９Ｂ】
2009506801.tif 000023
【図９Ｃ】
2009506801.tif 000024