JP2010522907A - リアル・タイム・プロセス制御システム - Google Patents

Abstract

本発明によるリアル・タイム・プロセス制御システムにおいて、リアル・タイム・オペレーティング・システムまたは混成リアル・タイム／非リアル・タイム・オペレーティング・システム（２３１、２３２）のいずれかを走らせる処理ユニット（２０１）が、リアル・タイム計算サーバとして作用する。クライアント−サーバ通信用のオンボード通信インターフェース（２２１、２２２、２２３）を装備した作動／検知ユニット（２１１、２１２、２１３）が、クライアントとして作用する。作動／検知ユニット（２１１、２１２、２１３）は、処理ユニット（２０１）にメッセージを送って、計算タスクの適時評価を要求する。処理ユニット（２０１）は、計算タスクをリアル・タイムで評価し、要求元クライアントのオンボード通信インターフェース（２２１、２２２、２２３）に応答を返送する。
【選択図】図２

Description

本発明は、一般的には、リアル・タイム・プロセス自動化に関し、特に、パワー・エレクトロニクス用途を制御するための高信頼性システムのような、リアル・タイム・プロセス制御システムのアーキテクチャに関する。プロセス自動化は、製品、サービス、および活動(activities)に関係し、計算ハードウェア、センサ／アクチュエータ、およびその他のデバイス、ならびにその上のソフトウェアを用いて、１つ以上のプロセスの挙動および進展を自動的に監視し、操作し(steer)、制御する。プロセスとは、モータ、製粉機、タービン、製品製造機械のような物理的デバイス、または物理的デバイスの集合体の動作とすることができる。リアル・タイム・プロセス自動化は、所定の時間量内でタスクを完了しなければならないという余分な制約を賦課する。

"Power Section for Driving an Electric Drive, a Drive Control Based Thereon, and a Method for Networking a Control Unit with One or More Power Sections"（電気ドライブを駆動するためのパワー部、それに基づいたドライブ制御、および制御ユニットと１つ以上のパワー部とでネットワークを構築する方法）題する米国特許出願第２００２／００４９５０５号Ａ１に、従来技術の電気ドライブ・リアル・タイム制御システムが記載されている。この中では、マスタ−スレーブ・アーキテクチャが開示されており、電気ドライブを制御するためのそのインテリジェンスを、中央制御ユニット（図１におけるＲ）と電気ドライブの近くに位置するパワー部（図１におけるＬ１、Ｌ２、およびＬ３）との間で分配する。中央制御ユニットは、所望の出力値（例えば、電圧値）を決定し、初期化のときにパワー部をパラメータ化する。このようにする際に、中央マスタ制御ユニットが先導して、スレーブパワー部に命令する。更に、パワー部では、検出した温度値に基づくリアル・タイム安全性チェックが行われる。各パワー部は、リアル・タイム処理能力を有するディジタル・インターフェースと、リアル・タイム計算タスクの一部のためにマイクロプロセッサとを有する。言い換えると、パワー部自体が測定値を受信して処理し、ゲート・ドライバ信号をリアル・タイムで発生するインテリジェンスおよび複雑さを有する。米国特許出願第２００２／００４９５０５号Ａ１における中央制御ユニットとパワー部との間の通信は、ディジタル、同期マスタ−スレーブ送信プロトコルによって同期が取られている。

一般に、既知のプロセス自動化システムは、マスタ−スレーブ構成で動作する異なるプロセッサ・ハードウェアの混合体を内包する。本特許出願書類に含まれる(enclosed)図１に、これが示されており、３つのパワー弁(power valves)１１１、１１２、および１１３が示されている。これらは、パワー弁１１１、１１２、および１１３の近くにあるディジタル信号プロセッサ（ＤＳＰ）１２１、１２２、および１２３の混合体によって制御される。一方、これらのＤＳＰ１２１、１２２、および１２３は、ネットワーク１０４を通じてプログラマブル・ロジック・コントローラ（ＰＬＣ）１０３に接続されており、後者のＰＬＣ１０３は、ネットワーク１０２を通じて中央処理ユニット（ＣＰＵ）１０１に接続されている。機能的な観点からそして最も低いレベルでは、ドライブ制御のような、リアル・タイム制御用アルゴリズムは、通例、被制御デバイスと一体化されたまたはその近くに位置するディジタル信号プロセッサ（ＤＳＰ）１２１、１２２、および１２３上に実装する。その上、リアル・タイム・プロセス制御用アルゴリズムを、プログラマブル・ロジック・コントローラ・プロセッサ（ＰＬＣ）１０３上に実装することもあり得る。これらのアルゴリズムは、とりわけ、ＤＳＰ１２１、１２２、および１２３上で走る制御アルゴリズムに、設定値、例えば、所望の速度およびトルクを供給する。最後に、プロセスの視覚化、および製造実行システム（ＭＥＳ）や企業資源計画（ＥＲＰ）レイヤによって実装するような、更に上のレベルの非リアル・タイム・タスクが、図１におけるＣＰＵ１０１のようなパーソナル・コンピュータ（ＰＣ）またはＰＣ状ハードウェア上で行われるのが通例である。これらは、多くの場合、図１における非リアル・タイム・オペレーティング・システムに基づいて動作する。

従来技術のプロセス自動化システムの一部は、本来、多数のハードウェア・プラットフォームおよびマスタ−スレーブ・アーキテクチャによって形成されるため、様々な難点が生ずる。第１に、多数のハードウェア・プラットフォームでは、全てのハードウェア・プラットフォームが互いに適正に通信するために、相当なインターフェース・オーバーヘッドが発生する。更に、均一なプログラミング標準を用いることは、不可能ではないにしても、困難である。何故なら、各ハードウェア・プラットフォームにはそれ自体の特異性や限界があるからである。したがって、既知のプロセス自動化システムでは、ソフトウェアの保守が非常に困難となることが分かる。マスタ−スレーブ・アーキテクチャの別の欠点は、システムの信頼性がマスタの信頼性によって決定されることである。マスタが故障すると、全ての従属スレーブも故障する。

更に、例えば、ドライブ制御用の低レベル制御ループが、大抵の場合ＤＳＰプロセッサ上に実装されている。このため、ロバスト性の要件は、丁度動的応答に対する過酷な要件を満たすように達成される。例えば、１００ミリ秒未満のサイクル時間は、ＤＳＰに基づく駆動制御によって実現することができる。しかしながら、コストの理由のために、ＤＳＰは計算容量が制限されている場合が多い。これらＤＳＰの計算容量は、例えば、多数の制御ループの調和を伴う、複雑な高性能制御アルゴリズムには十分ではない。一方で、システムまたはアプリケーションが、非常に強力なプロセッサ、例えば、ＰＣプロセッサの利用可能な容量を使用しないまま残すことも多い。

強力な方のプロセッサを優先してＤＳＰやＰＬＣプロセッサを選択する主な理由の１つは、リアル・タイム自動プロセス制御に要求される信頼性にある。９９．９９％の稼動時間が要求されるのも例外ではない。この信頼性要件は、特に、最も低い制御レベル、即ち、ハードウェアと直接相互作用を行う制御ループに当てはまる。

本発明の目的は、前述した従来技術のシステムの欠点を克服する、リアル・タイム・プロセス制御システムを提供することである。即ち、本発明の目的は、制御インテリジェンスの多数のハードウェア・プラットフォームへの分散を回避し、このような多様なハードウェア・プラットフォーム間におけるインターフェース・オーバーヘッドを回避し、制御ハードウェアの多様性の結果である保守の困難性を回避する、リアル・タイム・プロセス制御システムを開示することである。加えて、リアル・タイム制御プロセスにおける信頼性を損なうことなく(trade)、ＰＣのような利用可能な強力な信号処理ハードウェアの処理能力を一層最適に使用することも目的の１つである。

前述の目的の達成、および先行技術の解決策の欠点の解消は、請求項１に規定するリアル・タイム・プロセス制御クライアント−サーバ・システムによって遂行する。このようなシステムは、処理ユニットと、処理ユニットと通信することができる少なくとも１つの作動／検知ユニットと、処理ユニットと少なくとも１つの作動／検知ユニットとを相互接続するネットワークとを有する。処理ユニットは、リアル・タイム計算サーバとして作用し、そのためにリアル・タイム・オペレーティング・システムまたは混成リアル・タイム／非リアル・タイム・オペレーティング・システムを走らせるように構成されている。作動／検知ユニットは、クライアントとして作用するように構成されており、計算タスクの適時評価を要求するメッセージを通じた処理ユニットとのクライアント−サーバ通信のために、オンボード通信インターフェースを有する。

本特許出願のこれまでの説明および残りの双方において、作動／検知ユニットは、とりわけ、ある種のプロセス特性を測定することができる検知ハードウェア、ある種の刺激をプロセスに加えることができる作動ハードウェア、または双方のいずれかを備えているユニットとして理解するとよい。

このように、クライアント−サーバ・アーキテクチャにしたがってシステムを構成することにより、作動／検知ユニットは計算タスクの要求を送るが計算自体をもはや実行しないクライアントとなり、ＰＣのような処理ユニットは計算サーバとして作用し、全ての処理機能性は１つのハードウェア・プラットフォーム上に集中する。その結果、インターフェース処理のオーバーヘッドは、作動／検知ユニットと処理ユニットとの間の１つの、好ましくは標準化されたインターフェースに減少する。更に、処理ユニット上で走るソフトウェアのみを保守すればよいので、ソフトウェアの保守が簡略化されている。

本発明によるシステムでは、主な計算タスクは、処理ユニットによって実行し、処理ユニットは、リアル・タイム・オペレーティング・システム、または１つの処理ユニット上でリアル・タイムおよび非リアル・タイム動作双方を管理することができる混成オペレーティング・システムのいずれかを走らせる。このような処理ユニットの例には、Ｉｎｔｅｌ社のプロセッサ、ＡＭＤ社のプロセッサ、ＰｏｗｅｒＰＣプロセッサ、Ｂｌａｃｋｆｉｎプロセッサ、ならびにＴＩ社のＣ２０００、Ｃ５０００、およびＣ６０００シリーズが含まれる。リアル・タイム・オペレーティング・システムの例には、Ｍｉｃｒｉｕｍ、Ｎｕｃｌｅｕｓ、ＶｘＷｏｒｋｓ、ＱＮＸ、Ｏｎ Ｔｉｍｅ ＲＴＯＳ−３２、およびＬｙｎｘＯＳがある。混成オペレーティング・システムは、例えば、ＲＴＬｉｎｕｘ、ＲＴＡＩ、またはＸｅｎｏｍａｉオペレーティング・システムとすればよいが、ＰｒｏＮｏＣｏｓ Ｗｉｎ ＲＴのような、リアル・タイム拡張を有するＷｉｎｄｏｗｓＣＥまたはＷｉｎｄｏｗｓＸＰでもよい。処理ユニットおよびオペレーティング・システムの組み合わせにより、ローカルおよびリモート・ユーザ・インターフェース、ならびにその他の非リアル・タイム・プロセスを走らせることができる一方で、同時にリアル・タイム計算サーバとして作用し、現場にあるクライアント作動／検知ユニットからの要求を受信し処理することができる。これらの要求は、通例、計算サーバにある種の計算タスク、例えば、要求元の作動／検知ユニットにその設定値を供給するため、またはセンサ情報を適正に格納し伝搬するための制御アルゴリズムの評価をリアル・タイムで実行することの要求を含む。リアル・タイム挙動を確保するために、要求は、当該要求を処理しなければならない時間スパンを指定するとよい。要求は、オプションとして、計算タスクを実行するために処理ユニットが必要とする測定値のような、追加情報を含むこともできる。要求される計算タスクは、制御アルゴリズムまたは多数の制御アルゴリズムの評価に対応することができるが、それに限定されないのは明らかである。

更に、本発明は、請求項１４に規定する対応のリアル・タイム・プロセス制御方法に関する。
本発明によるリアル・タイム・プロセス制御システムの特定的な実施形態は、パワー・エレクトロニクスを制御するために構成されている。請求項２に規定するこのような実施形態では、作動／検知ユニットは、それぞれのパワー部ユニットの一部を形成し、処理ユニットは、サーバとして作用するように構成され、パワー部ユニットは、サーバ上で計算タスクの評価をスケジューリングすることが可能である。

クライアントパワー部は、パワー変換弁、電流、電圧、および温度を測定するセンサ、測定値をディジタル・フォーマットに変換する信号処理ハードウェア、ならびに信号処理ハードウェアおよび通信インターフェースを備えている。信号処理ハードウェアおよび通信インターフェースは、測定値を処理し、サーバ処理ユニットに情報を送信しこれから情報を受信し、本特許出願において更に説明するような、冗長性を有するシステムにおいて複数のサーバ処理ユニットにアドレスする場合には、最終的に、着信する応答の中から選択を行う。最後に、応答は、パワー変換弁のゲート・ドライバに直接印加する、またはクライアント・ユニット上に位置しパワー変換器ゲート・ドライバ信号を生成するパルス幅変調（ＰＷＭ）発生器の入力に印加するのに適した信号を収容する。

更に請求項３において指定するように、パワー・エレクトロニクスの制御に提供可能な本発明によるシステムの実施形態は、電流、電圧、または温度を検知しディジタル化し、更に検知した電流、電圧、または温度を、要求メッセージの一部を形成する信号に変換する作動／検知ユニットを有することもできる。

つまり、要求は、サーバが制御アルゴリズムを評価するために必要となる、必要な測定情報の全てを含む。
請求項４に規定するように、作動／検知ユニットのオンボード通信インターフェースには、クロックを装備することができ、最終的には何らかの制限したローカル処理能力も装備することができる。

このように、作動／検知ユニットは、測定値のサンプリング、アクチュエータ出力設定値の調節、要求の送付、および着信応答の処理というような動作を自律的に実行することができる。制限したローカル処理能力は、例えば、ＤＳＰ、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、構造化ＦＰＧＡ、または専用の特定用途集積回路（ＡＳＩＣ）によって実装することができる。あるいは、数個の作動／検知クライアント間で１つのクロックを共有することもできる。

本発明によるリアル・タイム・プロセス制御システムの更に別のオプションの特徴は、請求項５に規定するように、異なる作動／検知ユニットにおけるクロックの同期を取ることができることである。

クロックの同期によって、クライアント作動／検知ユニットが互いに、例えば、１００ｍまたはそれ以上離れていても、作動／検知ユニットにおける異なる測定センサのサンプリング、および異なるアクチュエータ出力の調節を、時間内に確実に調整する。クライアント作動／検知ユニットは、ローカル・クロックに基づいてサンプリングし作動させるので、これらの動作の適時調整に対するジッタは、同期の精度(precision)によってのみ制限される。このため、異なるクライアント作動／検知ユニットにおけるクロックは、例えば、マスタ・クロックと同期を取るとよい。マスタ・クロックは、クライアントの１つ、サーバ、または外部デバイスによって発生することができる。同期は、専用リンクを通じて、またはクライアント−サーバ通信に用いられるリアル・タイム・ネットワークを通じて行われる。クライアント・クロック間の同期は、とりわけ、ＩＥＥＥ１５８８プロトコルによって実現することができる。

本発明によるリアル・タイム・プロセス制御システムの更に別のオプションの特性は、請求項６に規定するように、本システムが複数の処理ユニットを備えることができることである。複数の冗長処理ユニットに要求メッセージを送る、対応の方法を請求項１５に規定する。

このようにして、システムの信頼性を一層向上させる。
本発明による、冗長処理ユニットを有するシステムの更に別のオプションの形態では、請求項７に規定するように、作動／検知ユニットからのメッセージが、複数の処理ユニット上における計算タスクの評価をトリガすることができる。

実際、２つ以上の処理ユニットが利用可能な場合、クライアント作動／検知ユニットは、それらの要求を処理ユニットのいずれかまたは部分集合に送ることができる。これは、例えば、イーサネット（登録商標）・プロトコルおよび関連する切換ハードウェアのマルチキャスト能力を通じて、または仮想ローカル・エリア・ネットワーク（ＶＬＡＮ）能力を設けることによって達成することができる。要請されたサーバの各々は、要求された計算タスクを実行し、応答をクライアント作動／検知ユニットに返送する。

請求項８に指定するように、本発明による、冗長処理ユニットを有するシステムの更に別の選択肢が、冗長演算ユニットから適時受信した全ての応答から好ましい応答を選択するための、作動／検知ユニットにおける優先順位決定機能性の存在であってもよい。

つまり、クライアントは、何らかの優先順位方式に基づいて、適時に到達した全ての応答の間で選択を行う。適時に到達しなかった応答は、破棄する。本発明によるシステムのクライアント−サーバ・アーキテクチャのために、サーバは互いの障害を監視する必要はない。何らかの理由で、サーバが故障した場合、クライアント要求を受信した別のサーバが、他のサーバの障害について知ることなく、引き継ぐ。尚、これは、動作中のマスタ・ユニットが正常のままでいるか否か評価する冗長バックアップ・ユニットが継続的にマスタ・ユニットを監視する従前のマスタ−スレーブ・システムにおける冗長性とは対照的であることを記しておく。クライアントは、その優先順位メカニズムに基づいて、例えば、サーバ１が適時に計算を終了できないのでなければ、そのサーバからきた応答を選択する。サーバ１が適時に計算を終了できない場合、サーバ２からの応答を選択する。

更に、本発明によるシステムのオプションであるが有利な特徴は、請求項９に規定するように、冗長処理ユニットが、同じ計算タスクの評価に異なるアルゴリズムを備えることができることである。

請求項１０に規定する同様のオプションの特徴は、冗長処理ユニットが、異なるリアル・タイムまたは混成リアル・タイム／非リアル・タイム・オペレーティング・システムを走らせることができることである。

このため、ハードウェアおよびソフトウェアの冗長性の上に、機能的冗長性を設けることにより、信頼性が更に向上する。言い換えると、サーバは、ハードウェアが同様である必要がなく、必ずしも同じオペレーティング・システムを走らせることもなく、必ずしも同じアルゴリズムを適用して、クライアントから来る要求に応答することもない。

ハードウェアの問題を回避するために、サーバ・ハードウェアは、冗長サーバ間で異なるようにすることができる。重複するオペレーティング・システムの欠陥を回避するために、冗長サーバ上のオペレーティング・システムは互いに異なるようにすることができる。最後に、重複するソフトウェア・バグを回避するために、冗長サーバにおいて用いるアルゴリズム実現例を互いに異なるように作ることができる。唯一の要件は、クライアントからの１つの要求に応答して異なる処理ユニット上で走る全てのアルゴリズムが、同様の機能性を提供し、その結果同様の応答を提供することである。例えば、作動／検知クライアントからの要求に応答して、１つの処理ユニットが複雑なアルゴリズムを、ＰｏｗｅｒＰＣ上で走るＲＴＬｉｎｕｘオペレーティング・システム上で走らせることができ、一方第２処理ユニットは、そのアルゴリズムの簡略化バージョンを、ＷｉｎｄｏｗｓＣＥオペレーティング・システムおよびＩｎｔｅｌ社のプロセッサ上で用いることができる。異なるサーバ上の異なるアルゴリズムを同期して維持するために、クライアントは、既に選択した応答を異なるサーバに伝達するとよい。

請求項１１に規定するように、オプションとして、本発明によるリアル・タイム・プロセス制御システムは、冗長処理ユニット上で計算負荷の均衡を取る負荷均衡手段を備えている。複数の冗長処理ユニット間において負荷の均衡を取る、対応する方法が、請求項１６に規定されている。

負荷の均衡を取ることにより、処理容量使用の動的な最適化が可能となる。例えば、サーバが故障した場合、そのサーバ上で走っているプロセスの負荷は、実行時に残りのサーバに分散させることができる。クライアントにとっての違いは、異なるサーバから応答を受信することである。異なるサーバのＣＰＵ負荷に応じて、プロセスをサーバ間で移動させることができる。また、サーバの故障統計、即ち、その信頼性に応じて、プロセスをサーバ間で移動させることもできる。また、その他の判断基準に応じて、プロセスを移動させることもできる。あるいは、全ての要求をディスパッチ・サーバに回し、ディスパッチ・サーバがクライアント要求を発行することもできる。このようなディスパッチ・サーバは、例えば、ＣＰＵ負荷が最も低い処理ユニットに要求を発行するとよい。

請求項１２に規定するように、本発明によるリアル・タイム・プロセス制御システムは、好ましくは、リアル・タイム伝送能力を有するネットワークによって実行する。請求項１３に指定するように、その一例は有線または無線双方のイーサネット（登録商標）・ネットワークである。他の適したネットワーク・プロトコルには、Ｉｎｆｉｎｉｂａｎｄ、ＵＳＢ、ＦiｒｅＷｉｒｅ、およびＰＣＩ Ｅｘｐｒｅｓｓが含まれる。

図１は、先に詳細に説明した、先行技術のリアル・タイム・プロセス制御システムを示す。 図２は、１つの処理ユニットが複数の作動／検知ユニットに接続されており、クライアント・クロックをマスタ・クロックと同期させる、本発明によるシステムの第１実施形態を示す。 図３は、図２に示すシステムにおいて用いられる作動／検知ユニットの機能ブロック図である。 図４は、図２に示すシステムにおける処理ユニットおよび作動／検知ユニット間におけるクライアント−サーバ通信を示す。 図５は、２つの処理ユニットが複数の作動／検知ユニットと接続されており、クライアント・クロックをマスタ・クロックと同期させる、本発明によるシステムの第２実施形態を示す。 図６は、３つの冗長処理ユニットが設けられ、作動／検知ユニットが３つの処理ユニットの各々に要求を送り、３つの処理ユニットの各々からの応答を受信し、優先順位メカニズムに基づいて応答を選択する、本発明によるシステムの第３実施形態の機能的動作を示す。 図７は、作動／検知ユニットが３つの処理ユニットの各々に要求を送り、３つの処理ユニットの部分集合から応答を受信し、優先順位メカニズムに基づいて応答を選択する、本発明によるシステムの第３実施形態を示す。 図８は、負荷均衡メカニズムを用いる、本発明によるシステムの第４実施形態を示す。 図９は、パワー・エレクトロニクス制御分野における、本発明によるシステムの第５実施形態を示す。

図２は、１つの処理ユニット２０１を有する本発明によるリアル・タイム・プロセス制御システムを示す。処理ユニット２０１は、イーサネット（登録商標）・ネットワーク２０３を通じて、作動／検知ユニットに接続されている。作動／検知ユニットは、それぞれの作動／検知ハードウェア２１１、２１２、および２１３、ならびにそれぞれのオンボード・インターフェース２２１、２２２、および２２３を有する。作動／検知ユニットは、ネットワーク２０３上ではクライアントとして作用し、制御対象プロセスに入力を供給し、制御対象プロセスの出力を測定し、この処理ユニット２０１が実行すべき計算タスクまたはその他のタスクを要求するために、処理ユニット２０１と通信する。一方、処理ユニット２０１は、計算サーバとして作用し、クライアント作動／検知ユニットは、計算サーバ上における計算タスクまたはその他のタスク（例えば、構成設定値のような運営管理タスク）を、リアル・タイムおよび非リアル・タイムの双方でスケジューリングすることができる。処理ユニット２０１は、図２において参照番号２０４で示すような、協同ネットワーク、インターネット、またはその他の任意の外部ネットワークに接続することができる。外部ネットワークへの接続性２０４がない場合、システムは単体ユニットとして作用する。加えて、図２に描いた本発明の実施形態は、マスタ・クロック２０５を備えている。このクロック２０５は、図２に示すような単体ユニットとすることができる。あるいは、処理ユニット２０１に一体化したクロック、またはクライアント作動／検知ユニットに一体化したクロックを用いることもできる。

図２の実施形態では、処理ユニット２０１は、非リアル・タイム・カーネル２３１およびリアル・タイム・カーネル２３２を備えている混成オペレーティング・システムを走らせる。非リアル・タイム・カーネル２３１は、非リアル・タイム・プロセスを管理する。非リアル・タイム・プロセスは、視覚化、ネットワーク２０４を通じたリモート・アクセスの管理、ＭＥＳ機能性、およびＥＲＰ機能性を処理することを含むことができるが、これらに限定されるのではない。リアル・タイム・カーネル２３２は、所定の時間量以内にある種の行為を完了させなければならないプロセスである、リアル・タイム・プロセスを管理する。リアル・タイム・プロセスは、アルゴリズム、最適化タスク、ウオッチドッグ、および安全防御プロセスを制御することを含むことができるが、これらに限定されるのではない。非リアル・タイム・カーネル２３１およびリアル・タイム・カーネル２３２双方を備えているオペレーティング・システムの例には、ＲＴＬｉｎｕｘ、Ｘｅｎｏｍａｉ拡張によって増強されたあらゆるＬｉｎｕｘの実装、Ｓｏｌａｒｉｓ、またはＸｅｎｏｍａｉ拡張によって増強されたＯｐｅｎ Ｓｏｌａｒｉｓ、Ｗｉｎｄｏｗｓ ＣＥまたはリアル・タイム拡張によって増強されたＷｉｎｄｏｗｓ ＸＰがある。

図２に描いたシステムの異形実施形態では、処理ユニット２０１は、リアル・タイム・カーネルのみを有し、非リアル・タイム・カーネルを除外したオペレーティング・システムを走らせる。このようなオペレーティング・システムの例には、Ｍｉｃｒｉｕｍ、Ｎｕｃｌｅｕｓ、ＶｘＷｏｒｋｓ、ＱＮＸ、Ｏｎ Ｔｉｍｅ ＲＴＯ−３２、およびＬｙｎｘＯＳがある。このような実施形態では、リアル・タイム挙動を損なうことなく、プロセス視覚化のような非リアル・タイム・プロセスおよびリアル・タイム・プロセスを同じ処理ユニット上において統合することは遥かに難しくなる。

既に述べたように、サーバ処理ユニット２０１をクライアント作動／検知ユニットに接続するネットワーク２０３に適した選択肢の１つに、イーサネット（登録商標）接続に基づくネットワークがある。イーサネット（登録商標）、特に、高速イーサネット（登録商標）、Ｇビット・イーサネット（登録商標）、およびそれを超えるイーサネット（登録商標）は、クライアント−サーバ通信によって引き起こされる集中トラフィックをサポートするのに必要な帯域幅を提供する。更に、ネットワーク２０３は、星型トポロジ、環状トポロジ、またはその他の任意のトポロジを用いて実現することができることを記しておく。

図３は、図２に示したシステムから、作動／検知ユニット３０１の１つのトポロジを詳細に示す。作動／検知ユニット３０１は、クライアント・ユニットまたはクライアントとも呼ぶことにする。このクライアント３０１は、オンボード・インターフェース部２２１およびハードウェア部２１１を備えている。尚、ここで、図２および図３において、２２１のように、同じ参照番号が異なる図において用いられている場合、これらの参照番号はシステムの同じ構成要素または要素を示すことを記しておく。ハードウェア部２１１は、作動および／または検知ハードウェアを内蔵する。インターフェース部２１１は、ネットワーク・インターフェース３１１、処理ユニット３１２、ハードウェア・インターフェース３１３、およびクロック３１４を備えている。ネットワーク・インターフェース３１４は、クライアント３０１をイーサネット（登録商標）・ネットワーク２０３に接続し、イーサネット（登録商標）・ネットワーク２０３を通じて、クライアント３０１は図２の処理ユニット２０１と通信する。この処理ユニット２０１は、計算サーバまたはサーバとも呼ぶことにする。

インターフェース部２２１の内部にある処理ユニット３１２は、クライアント３０１に基本的な信号処理能力を提供する。これらは、ハードウェア部が供給する測定信号のディジタル化、信号のサンプリングおよびフィルタリング、システム監視および安全防御動作、計算サーバ２０１への要求の送付、ならびに計算サーバ２０１から受信する応答の処理を含むが、これらに限定されるのではない。処理ユニット３１２は、例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ディジタル信号プロセッサ（ＤＳＰ）、または特定用途集積回路（ＡＳＩＣ）によって実現することができる。ネットワーク・インターフェース３１１の一部またはネットワーク・インターフェース全体、そしてハードウェア・インターフェース３１３の一部またはハードウェア・インターフェース３１３全体をＦＰＧＡ、ＤＳＰ、またはＡＳＩＣ上に一体化することも可能である。インターフェース部２２１は、ハードウェア・インターエース３１３を通じて、作動／検知ハードウェア２１１に接続する。このハードウェア・インターフェース３１３を通じて、アナログおよびディジタル入力および出力信号をそれぞれ読み出して設定する。必要であれば、このハードウェア・インターフェース３１３は、安全性条件あるいは任意の種類の仕様または規制によって要求される電気絶縁またはその他の種類の絶縁を設ける。

クロック３１４は、クライアント・ユニット３０１が自律的に、測定値のサンプリング、アクチュエータ出力設定値の調節、ネットワーク２０３上における要求の計算サーバ２０１への送出、タイム・アウト、監視および安全プロトコルの実施のような動作を実行することを可能にする。一実現例では、ネットワーク上にある異なるクライアントのクロックが、同期が取れていないままになっていることもある。実現例の異形では、全てのクライアントまたはその部分集合のクロックは、図２におけるクロック２０５のようなマスタ・クロックとの同期が取られている。このようにクロックの同期を取ることにより、クライアントは、自律性を維持しつつ、時間に関してそれらの動作を調整することが可能となる。既に延べたように、マスタ・クロック２０５は、単体クロック、処理ユニット２０１に一体化したクロック、または３０１のようなクライアント作動／検知ユニットに一体化したクロックのいずれかとすることができる。クロック同期を実行するために用いることができるプロトコルの一例に、ＩＥＥＥ１５８８プロトコルがある。他の同期プロトコルも可能であり、本発明は特定のクロック同期メカニズムの選択による制約は受けないことは、当業者には認められよう。好適な実施形態では、クロック同期に必要なメッセージの交換は、ネットワーク２０３を通じて遂行する。しかしながら、代替実施形態では、専用の個別ネットワークを通じて、クロック同期を遂行することもできる。尚、クライアントの中にあるクロックをネットワークまたは中央処理ユニットの中にあるマスタ・クロックと同期させることは、従来技術において用いられているようなマスタ−スレーブ・アーキテクチャに、システムを変えてしまうことではないことを記しておく。マスタ・クロックに同期させても、本発明によるクライアントは、アクティブな通信相手であることには変わりがない。即ち、クライアントは先導してある種の計算タスクやある種の制御動作をサーバ処理ユニット２０１から要求する。これは、従来技術のマスタ−スレーブ・アーキテクチャとは対照的である。

図４は、図２におけるシステムの単一処理ユニット２０１と作動／検知ユニット３０１との間における通信プロトコルを示す。このプロトコルが実現するクライアント−サーバ・メカニズムによって、処理ユニット２０１はサーバとして作用し、作動／検知ユニット３０１はクライアントとして作用する。これは、マスタ−スレーブ通信アーキテクチャに基づき、これによって処理ユニットがマスタとして作用し、作動／検知ユニットがスレーブとして作用する従前のシステムとは対照的である。

クライアント３０１は、その内部クロック３１４によって駆動されて、要求４０１をサーバ２０１に送り、サーバ２０１にある種の計算タスクまたはその他のタスクを実行するように要求する。つまり、クライアント３０１は、サーバ２０１との通信を確立する際に先導する能動な相手である。これも、マスタまたは処理ユニットが先導する従前のマスタ−スレーブ・アーキテクチャとは対照的である。要求メッセージ４０１の内容は、ソース・クライアント３０１を特定する参照、宛先サーバ２０１を特定する参照、要求４０１を特定する参照、要求の種類を特定する機能コード、およびサーバ２０１が要求４０１に応対するために必要な全ての必要データを含むことができる。尚、これは全てを網羅したのではないことを注記しておく。用途に応じて、要求は、先に羅列した項目(field)の一部のみを含む場合もあり、あるいはここでは網羅されていない、その他の項目も含む場合もある。

ネットワーク２０３がイーサネット（登録商標）接続を用いている実現例では、クライアント３０１を特定する参照は、図３におけるクライアントのネットワーク・インターフェース３１１の媒体アクセス制御（ＭＡＣ）アドレスである。このような実現例におけるサーバ２０１に対する参照は、サーバのネットワーク・インターフェースと関連のある個別またはマルチキャストＭＡＣアドレスである。要求４０１を特定する参照は、例えば、クライアント３０１が発生する連番として実施することができる。

特定的な実現例では、要求メッセージ４０１は、クライアント３０１がサーバ２０１からの応答を予期する時間スパンも含む。これは、リアル・タイム要件のある用途の場合である。あるいは、この時間スパンは、機能コードによって暗示的に指定することができる。

３０１のようなクライアントが２０１のようなサーバから要求することができる機能または計算タスクの種類には、クライアント出力設定値を計算する制御アルゴリズムの評価要求、構成データのロードまたは保存要求、タイミング情報、ステータス通知、およびエラー通知の要求が含まれるが、これらに限定されるのではない。

クライアント３０１から来る要求４０１に応答して、サーバ２０１は要求された動作を実行して、応答４０２をクライアント３０１に返送する。要求された動作のスケジューリングを行う際、サーバ２０１は明示的または暗示的のいずれかで指定されるあらゆるタイミング制約を考慮に入れようとする。応答４０２は、ソース・サーバ２０１を特定する参照、宛先クライアント３０１を特定する参照、元の要求４０１を特定する参照、およびクライアントの元の要求に対するサーバの応答に関連のあるあらゆる必要なデータを含む。この場合も、これは、応答メッセージ４０２の一部をなすことができる項目であり、網羅的な羅列ではない。これらの全てがある必要がない場合もあり、追加の項目が付加される可能性もある。

クライアント３０１は、応答４０２を受信し、その結果を適した仕方で展開する。一例として、元の要求４０１がリアル・タイム制御アルゴリズムの評価を伴うという場面を考える。サーバ２０１によって返送された応答４０２がクライアント３０１によって適時に受信されると、応答４０２に収容されているアルゴリズムの出力が、図３におけるクライアントの作動ハードウェア２１１の状態を適正に調節することによって、展開される。展開が行われる時点は、クライアントの内部クロック３１４によって決定する。応答４０２が早めに到達した場合、システム全体において行われる全ての行為の適正な調整を確実に行うために、クライアント３０１によって展開を遅らせることもできる。応答４０２が適時に到達しない場合、クライアント３０１は、図３におけるそのローカル処理ユニット３１２によって発生した代替物を用いることを決定してもよいし、あるいは中断してエラー通知を送ることを決定してもよい。

ネットワーク２０３上にある他のいずれのクライアントも、図４に示す単一クライアント／単一サーバの場合について先に説明したのと同様に、処理ユニット２０１と相互作用を行う。つまり、処理ユニット２０１の計算資源は、ネットワークにおける全てのクライアント間で共有することができる。

図５は、本発明による第２実施形態のシステムの物理的セットアップを示す。このセットアップは主に図１のそれに対応するが、図１に描いたシステムと比較すると、サーバとして作用しネットワーク５０３に接続されている第２処理ユニット５０２によって増強されている。図５の実施形態では、第１処理ユニット５０１および第２処理ユニット５０２が、イーサネット（登録商標）に基づくネットワーク５０３によって、クライアント作動／検知ユニットに接続されている。図５では、クライアント作動／検知ユニットの内３つが描かれている。これら３つの作動／検知ユニットは、それぞれの作動／検知ハードウェア５２１、５２２、および５２３と、それぞれのオンボード・インターフェース５１１、５１２、および５１３とを有する。２つの処理ユニット５０１および５０２は、ここでも、クライアント作動／検知ユニットによって要求される計算タスクのための計算サーバとして作用する。リアル・タイム・タスクおよび非リアル・タイム・タスクの双方が、処理ユニット５０１および５０２によって実行され、これら双方は混成オペレーティング・システム（ＯＳ）を走らせる。混成オペレーティング・システムは、非リアル・タイム・コンポーネント、それぞれ、５３１および５４１、ならびにリアル・タイム・コンポーネント、それぞれ、５３２および５４２を収容する。図２に描いた第１実施形態と同様に、図５に示すシステムも、更に、マスタ・クロック５０５を内蔵し、冗長処理ユニット５０１および５０２は、外部ネットワーク５０４への接続性を有する。冗長な処理ユニット５０１および５０２を有する実施形態では、クライアント作動／検知ユニットは、要求を双方の処理ユニットに送ることができる。次いで、双方の処理ユニットは独立して要求されたタスクを実行し、要求に応答する。重複した応答を２つの処理ユニットから受信した場合、クライアント作動／検知ユニットは、制御プロセスにおける展開に用いるために１つの応答を選択する。処理ユニットの過負荷による障害の場合、クライアントは１つの応答のみを適時に受信し、明らかであろうが、この応答を制御プロセスにおいて用いる。各クライアント要求を２つの処理ユニット５０１および５０２に送る代わりに、それぞれの負荷に応じて、要求を処理ユニット５０１および５０２間で分散することができる。クライアント・ユニットまたは中央処理ユニットにおいて負荷均衡を行うこともでき、要求を受信し、処理ユニット５０１および５０２の実際の負荷の知識に基づいて、要求をこれらの処理ユニットに割り振る。図５に描くシステムは、更に、任意の数のサーバをネットワークに追加することによって増強することができる。その結果、マルチ・クライアント／マルチ・サーバ・アーキテクチャが得られ、余分なサーバがシステムの信頼性を高めようとする、および／または本来の処理ユニット５０１上の負荷を緩和しようとする。

図６は、第３実施形態の機能的動作を示し、更に特定すれば、クライアント−サーバ通信メカニズムが、３つのサーバ６０１、６０２、および６０３を有する本発明の第３実施形態においてどのように動作するかを示す。図５に示した第２実施形態では、処理ユニット５０１および５０２はハードウェアおよびオペレーティング・システム双方が同一であることを想定したが、図６に示す実施形態におけるサーバ６０１、６０２、および６０３は、ハードウェアおよびオペレーティング・システム双方が異なる。第１サーバ６０１は、第１混成オペレーティング・システムＯＳ１および第１計算アルゴリズムを第１ハードウェア上で走らせると想定する。第２サーバ６０２は、第２混成オペレーティング・システムＯＳ２および第２計算アルゴリズムを、第１サーバ６０１のハードウェアとは異なる第２ハードウェア上で走らせると想定する。最後に、第３サーバ６０３は、第３混成オペレーティング・システムＯＳ３および第３計算アルゴリズムを、第１および第２サーバ６０１および６０２のハードウェアとは異なる第３プロセッサ・ハードウェア上で走らせると想定する。このようにして、ハードウェアの欠陥やオペレーティング・システムにおける欠陥が重複せず、制御プロセスにおいて回復不可能な障害に至ることがないことを保証する。

クライアント作動／検知ユニット６０４は、その内部クロック６４２によって駆動されて、同じ要求６１１をネットワーク上にある全てのサーバ６０１、６０２、および６０３に送る。この際、クライアント６０４は各サーバ、即ち、６０１、６０２、および６０３に、同じまたは同様の計算タスクあるいはその他のタスクを実行するように要求する。要求メッセージ６１１は、全てを網羅したのではないが、以下に羅列する項目を含むことができる。ソース・クライアント６０４を特定する参照、宛先サーバ６０１、６０２、および６０３を特定する参照、図４を参照して先に説明した単一クライアント／単一サーバの場合と同一または同様のコンテンツ。この場合も、クライアントおよびサーバを相互接続するネットワークは、イーサネット（登録商標）接続を用いて実装し、クライアント６０４を特定する参照は、クライアントのネットワーク・インターフェース６４１のＭＡＣアドレスであると想定する。サーバ６０１、６０２、および６０３に対する参照は、個々のＭＡＣアドレスの集合または１つのマルチキャストＭＡＣアドレスのいずれかとする。

クライアント６０４から来る要求６１１に応答して、サーバ６０１、６０２、および６０３の各々は、要求された動作を実行し応答をクライアントに返送する。図６では、サーバ６０１、６０２、および６０３から来る応答は、それぞれ、参照番号６１２、６１３、および６１４で示されている。要求された動作のスケジューリングを行う際、サーバ６０１、６０２、および６０３は明示的または暗示的のいずれかで指定されるあらゆるタイミング制約を考慮に入れようとする。応答の内容は、恐らくはサーバ６０１、６０２、および６０３の各々がその応答６１２、６１３、または６１４に割り当てる優先順コードを除いて、図４を参照して先に説明した単一クライアント／単一サーバの場合のそれと同一または同様である。

所与の時間制約の中で到達した応答の中から、クライアント６０４は、優先順位メカニズムに基づいて、それが展開する応答を選択する。一例として、元の要求６１１がリアル・タイム制御アルゴリズムの評価を伴う場面を考えることができる。サーバ６０１、６０２、および６０３から返送された応答６１２、６１３、および６１４の中で、クライアント６０４におけるインターフェーシング６４１は、各応答に付随する優先順位に基づいて選択を行う。次いで、選択した応答は、クライアント６０４によって展開される。他の応答は全て破棄される。展開が行われる時点は、クライアントの内部クロック６４２によって決定される。したがって、応答６１２、６１３、および６１４が早く到達した場合、システム全体において行われる全ての行為の適正な調整を確保するために、クライアント６０４によって展開を遅らせることもできる。応答６１２、６１３、および６１４のいずれもが時間内に到達しない場合、クライアント６０４は、インターフェース６４１の一部をなすそのローカル処理ユニットが発生する代替物を用いることを決定することもでき、あるいは中断してエラー通知を送ることを決定することもできる。可能な一実現例では、応答を選択するために用いられる優先順位決定メカニズムは、応答が到達する連続順序に基づく。他の可能な実現例では、優先順位決定メカニズムは、サーバの応答に明示的に含まれる、または応答を発生したサーバを特定する参照と暗示的に関連付けられている優先順位コードに基づく。

図６に描かれていない、ネットワーク内にある他のいずれのクライアントも、単一クライアント／マルチ・サーバの場合について先に説明したのと同様に、処理ユニット６０１、６０２、および６０３の全てまたはその部分集合と相互作用を行う。その結果、プロセス自動化のマルチ・クライアント／マルチ・サーバ・アーキテクチャが得られ、サーバの計算資源はネットワークにおける全てのクライアント間で共有および／または分散することができる。

前述のマルチ・クライアント／マルチ・サーバ・アーキテクチャによって、従前の自動化ハードウェアの信頼性を必ずしも呈さないサーバのハードウェアおよびソフトウェアに基づいて、信頼性が高いシステムを作成することが可能となる。サーバの１つが応答できない場合、クライアントは、ネットワークの中にある他のサーバが生成した結果の中から応答を自動的に選択する。この場面を図７に示す。図７は、第１処理ユニット６０１がクライアント作動／検知ユニット６０４からの要求に適時に応答できない時点における、図６にも描いた本発明の実施形態を示す。クライアント６０４は、要求７１１、例えば、制御アルゴリズムの適時評価の要求をサーバ６０１、６０２、および６０３に送る。サーバ６０２および６０３のみが、図７においてそれぞれ７１３および７１４と命名した応答を返送する。例えば、この処理ユニット６０１が故障したり、ハードウェアまたはソフトウェアの障害が発生したり、要求されたタスクを時間内に完了することに成功しなかったり、他のタスクによって過負荷となったり、あるいは単にクライアント６０４が発行する要求に応答するように構成されていないといった事実のために、第１サーバ６０１からの応答は欠落した。第１処理ユニット６０１が要求７１１に応答できなくても、クライアント６０４には影響を及ぼさず、クライアント６０４は単に着信する応答７１３および７１４の中から優先順位が最も高い応答を選択する。

要約すると、図６および図７に関して説明したマルチ・クライアント／マルチ・サーバ・アーキテクチャは、非常に自然な仕方で冗長性を実現する。マスタ−スレーブ手法とは異なり、冗長サーバは互いに明示的に監視する必要がない。全てのサーバは、マスタもバックアップ・サーバもないという意味で同等である。どの応答を用いるかを決定するのは、クライアント次第である。サーバは、実行時に追加、構成変更、および除去することができる。

既に述べたように、マルチ・クライアント／マルチ・サーバ・アーキテクチャでは、異なるサーバは同じクライアント要求に応答して、異なるアルゴリズムを走らせることもできる。ソフトウェア・バグの重複を回避するために、アルゴリズムの実現例(algorithmic implementation)は、サーバ毎に異なるように作ることができる。唯一の要件は、同じクライアント要求に応答して実行される全てのアルゴリズムが、同様の機能性を提供することを目的としなければならないということである。これを、機能的冗長性と呼ぶ。例えば、作動／検知ユニットから来る要求に応答して、１つのサーバが非常に複雑なアルゴリズムを走らせることができ、その結果に高い優先順位を割り当て、一方第２サーバはそのアルゴリズムの簡略化バージョンを走らせ、その結果に低い優先順位を割り当てる。

同じクライアントから来る要求に応対する全ての異なる計算サーバ上のアルゴリズム同士を同期させたまま維持するために、クライアントは、実際に選択した応答に関する情報を、関与するサーバに伝達するとよい。特定的な実現例では、この情報は、別個のメッセージを通じて送信する。実現例の異形では、この情報は、計算サービスに対する次のクライアント要求に添付する。

マルチ・クライアント／マルチ・サーバ・アーキテクチャは、更に、負荷均衡メカニズムの実装によって強化することができる。ネットワーク上の異なるクライアントが発生する負荷を分散し、１つのプロセッサに対する過剰な計算負荷を回避するために、個々のサーバはクライアントの特定の部分集合からの要求のみに対して応答するように選択することもできる。言い方を変えると、サーバは、特定のクライアントから来る要求を故意に無視することを選択することもできる。可能な一実現例では、この挙動は静的構成によって指定される。別の可能な一実現例では、異なるサーバの瞬時的または平均的計算負荷、これらの障害統計、あるいはその他の任意の関連する判断基準に応じて動的に、この挙動を決定する。

図８は、負荷均衡機能性の異なる実現例を備えた、本発明の第４実施形態を示す。このトポロジ例では、負荷均衡はサーバ８０５および８０６によって実施され、これらは、クライアント作動／検知ユニット８０４から来る要求８２１を実際の計算サーバ８０１、８０２、および８０３に再導出する。例えば、負荷均衡サーバ８０５は、クライアント要求８２１を要求８２２として第２処理ユニット８０２に再導出し、一方負荷均衡サーバ８０６は、要求８２１を要求８２３として第３処理ユニット８０３に再導出する。第２サーバ８０２および第３サーバ８０３からのそれぞれの応答は、図８では８２４および８２５で示されている。要求８２１は、第１処理ユニット８０１には転送されない。これは、例えば、このサーバ８０１は、要求８２１が負荷均衡サーバ８０５および８０６に到達する時点において、既に過負荷となっていることが予期されるからである。クライアント８０４によって直接アドレスされたサーバ８０５および８０６は、クライアント要求を再導出するタスクを専門に扱うので、このために、処理ユニット８０１、８０２、および８０３上の実際の計算負荷を考慮する。クライアント８０４は、その内部クロック８４１によって誘起され、優先順位方式に基づいて制御プロセスにおける展開のために、適時に受信した応答８２４および８２５から１つの応答を選択する。

図６、図７、および図８に示したマルチ・クライアント／マルチ・サーバ・アーキテクチャの上に構築することができるその他のアプリケーションには、プラグ・アンド・プレー・ハードウェア交換が含まれ、サーバ上で走るプロセス制御アルゴリズムまたはその他のアルゴリズムを新たなバージョンと交換し、これを実行時に行う。

図９は、パワー・エレクトロニクス用途に適した、本発明の第５実施形態を示す。ここでは、クライアント作動／検知ユニットは、パワー部であり、それぞれのパワー変換弁、電流、電圧、および温度を測定するセンサ、全ての測定値をディジタル形態に変換する信号処理ハードウェア、および図９において９２１、９２２、および９２３で示した信号処理ハードウェア、ならびに通信インターフェース９１１、９１２、および９１３を備えている。通信インターフェース９１１、９１２、および９１３は、測定値を処理し、９０１および９０２のような１つ以上の計算サーバにメッセージを送信しこれらからメッセージを受信し、着信する応答間で選択を行い、着信応答を処理して、含まれる結果をパワー変換弁に印加するのに相応しくなるようにする。後者は、応答に含まれる出力弁に対して所望な設定値を想定して、必要なＰＷＭ信号を発生することも含むとよい。図９には示していないが、クライアントの中にあるローカル・クロックが、いつ要求を送り、いつ応答をパワー変換弁に印加するのかを決定する。パワー変換弁は、パワー部を変換器またはインバータとして構成する場合、トランジスタ・ブリッジまたは三相ブリッジ接続として構成することができる。

クライアントのパワー部は、例えば、駆動用アプリケーションおよびインテリジェント・ネット・インターフェースを構築するために用いることができる。ローカル・クロックが決定する規則的な時点に、パワー部は、ドライブまたはその他のアルゴリズムを評価する要求を、ネットワーク９０３を通じて、９０１および９０２のような１つ以上の計算サーバに送る。要求は、サーバがアルゴリズムを評価するために必要となる全ての必要な測定値を含む。計算サーバ９０１および９０２は、制御アルゴリズムを評価して、それらの応答をパワー部に返送する。パワー部は、優先順位が最も高い応答を選択する。計算サーバ９０１および９０２は、暗示的および明示的な時間制約を考慮に入れ、それに応じて、各非リアル・タイム・コンポーネント９３１および９４１、ならびに各リアル・タイム・コンポーネント９３２および９４２を有する混成オペレーティング・システムを走らせる。異なるパワー部にあるクロックをマスタ・クロック９０５と同期させて、これらの動作全体を調整することができる。更に、これらのパワー部を用いて実現するパワーアプリケーションは、高信頼性、負荷均衡などに関する全ての固有性(property)を、前述した、より一般的なプロセス制御システムから引き継ぐ。最後に、図９は、処理ユニット９０１および９０２の外部ネットワーク９０４へのオプションの接続も示す。

以上、特定的な実施形態を参照して本発明について例示したが、本発明は以上の例示的実施形態の詳細に限定されるのではなく、本発明は、その主旨や範囲から逸脱せずに、種々の変更や修正を含めて具体化してもよいことは、当業者には明らかであろう。したがって、本発明は、あらゆる観点において例示的であり限定的ではないと解釈することとし、発明の範囲は、以上の説明ではなく、添付した特許請求の範囲によって示されるものとする。特許請求の範囲の均等の意味および範囲に該当する全ての変更は、その中に包含されるものとする。言い換えると、基本的な基礎原理の主旨および範囲に該当し、その必須の属性が本特許出願において特許請求されている、いずれのそしてあらゆる修正、変形、または同等物も適用範囲に入ることを意図している。更に、本特許出願の読み手には、「備えている」(comprising)または「備える」(comprise)という単語は、他の要素またはステップを除外しないこと、「ａ」または「ａｎ」という単語は複数を除外しないこと、そしてコンピュータ・システム、プロセッサ、またはその他の集積回路のような単数の要素は、特許請求の範囲に明記する数個の手段の機能を実現してもよいことは言うまでもないであろう。請求項におけるいずれの符号も、それぞれの関係する請求項を限定するように解釈しないこととする。「第１」、「第２」、「第３」、「ａ」、「ｂ」、「ｃ」等の用語は、説明および請求項において用いられるときには、同様の要素またはステップ間で区別するために導入するのであり、必ずしも連続的または時間的順序を記述するのではない。同様に、「最上位」、「最下位」、「上」、「下」等は、記述の目的のために導入するのであり、必ずしも相対的な位置を表す訳ではない。尚、そのように用いられる用語は、しかるべき状況下では相互交換可能であり、本発明の実施形態は、先に記載または例示したのとは異なる別のシーケンスまたは方位で、本発明にしたがって動作可能であることは理解されてしかるべきである。

Claims (16)

1. リアル・タイム・プロセス制御システムであって、
   ａ．処理ユニット（２０１）と、
   ｂ．前記処理ユニット（２０１）と通信することができる少なくとも１つの作動／検知ユニット（２１１、２１２、２１３）と、
   ｃ．前記処理ユニット（２０１）と前記少なくとも１つの作動／検知ユニット（２１１、２１２、２１３）とを相互接続するネットワーク（２０３）と、
   を備えており、
   ｄ．前記処理ユニット（２０１）は、リアル・タイム計算サーバとして作用し、それに対しリアル・タイム・オペレーティング・システムまたは混成リアル・タイム／非リアル・タイム・オペレーティング・システム（２３１、２３２）を走らせるように構成されており、
   ｅ．前記少なくとも１つの作動／検知ユニット（２１１、２１２、２１３）は、少なくとも１つのクライアントとして作用するように構成されており、それに対し、計算タスクの適時評価を要求するメッセージを通じた前記処理ユニット（２０１）とのクライアント−サーバ通信のために、オンボード通信インターフェース（２２１、２２２、２２３）を有する、
   ことを特徴とする、リアル・タイム・プロセス制御システム。
2. 請求項１記載のリアル・タイム・プロセス制御システムにおいて、
   前記少なくとも１つの作動／検知ユニットは、それぞれのパワー部ユニット（９１１、９２１；９１２、９２２；９１３、９２３）の一部を形成し、
   前記処理ユニット（９０１）は、サーバとして作用するように構成され、前記パワー部ユニット（９１１、９２１；９１２、９２２；９１３、９２３）は、前記サーバ上で前記計算タスクの前記評価をスケジューリングすることが可能である、
   ことを特徴とする、リアル・タイム・プロセス制御システム。
3. 請求項２記載のリアル・タイム・プロセス制御システムにおいて、
   前記少なくとも１つの作動／検知ユニット（９１１、９２１；９１２、９２２；９１３、９２３）は、電流、電圧、または温度を検知しディジタル化し、更に前記電流、電圧、または温度を、前記計算タスクの適時評価を要求する前記メッセージの一部を形成するために供給する信号に変換するように構成されていることを特徴とする、リアル・タイム・プロセス制御システム。
4. 請求項１または請求項２記載のリアル・タイム・プロセス制御システムにおいて、
   前記オンボード通信インターフェース（２２１）は、前記作動／検知ユニット（３０１）が自律的にいつプロセス・パラメータをサンプリングすべきか、および／またはいつ作動／検知ユニットの設定値を修正すべきか、および／またはいつ前記メッセージを前記処理ユニット（２０１）に送るべきかを決定することを可能にするために供給するクロック（３１４）を備えていることを特徴とする、リアル・タイム・プロセス制御システム。
5. 請求項４記載のリアル・タイム・プロセス制御システムにおいて、
   異なる作動／検知ユニットにおけるクロックは、前記クロック（３１４）と同様であり、同期が取られていることを特徴とする、リアル・タイム・プロセス制御システム。
6. 請求項１または請求項２記載のリアル・タイム・プロセス制御システムにおいて、
   当該システムは、前記処理ユニットと同様の複数の処理ユニット（５０１、５０２）を備えており、該処理ユニット（５０１、５０２；６０１、６０２、６０３；８０１、８０２、８０３）は、冗長リアル・タイム計算サーバとして作用するように構成されていることを特徴とする、リアル・タイム・プロセス制御システム。
7. 請求項６記載のリアル・タイム・プロセス制御システムにおいて、
   前記メッセージ（６１１）は、前記複数の処理ユニット（６０１、６０２、６０３）上において前記計算タスクの評価をトリガすることができ、前記複数の処理ユニット（６０１、６０２、６０３）の各々は、前記計算タスクの評価を試行し適時に応答するように構成されていることを特徴とする、リアル・タイム・プロセス制御システム。
8. 請求項７記載のリアル・タイム・プロセス制御システムにおいて、
   前記少なくとも１つの作動／検知ユニット（６０４）は、更に、前記複数の処理ユニット（６０１、６０２、６０３）から適時に受信した応答（６１２，６１３，６１４；７１３，７１４）の中から１つの応答を選択するように構成されている優先順位決定手段（６４１）を備えている、リアル・タイム・プロセス制御システム。
9. 請求項７記載のリアル・タイム・プロセス制御システムにおいて、
   前記複数の処理ユニット（６０１、６０２、６０３；８０１、８０２、８０３）は、前記計算タスクの評価のために異なるアルゴリズムを備えていることを特徴とする、リアル・タイム・プロセス制御システム。
10. 請求項６記載のリアル・タイム・プロセス制御システムにおいて、
    前記複数の処理ユニット（６０１、６０２、６０３；８０１、８０２、８０３）は、異なるリアル・タイム・オペレーティング・システムまたは混成リアル・タイム／非リアル・タイム・オペレーティング・システムを走らせるように構成されていることを特徴とする、リアル・タイム・プロセス制御システム。
11. 請求項６記載のリアル・タイム・プロセス制御システムにおいて、
    当該システムは、前記少なくとも１つの作動／検知ユニット（８０４）によって前記複数の処理ユニット（８０１、８０２、８０３）上に生ずる計算負荷の均衡を取るように構成されている負荷均衡手段（８０５，８０６）を備えていることを特徴とする、リアル・タイム・プロセス制御システム。
12. 請求項１または請求項２記載のリアル・タイム・プロセス制御システムにおいて、
    前記ネットワーク（２０３）は、リアル・タイム伝送能力を有することを特徴とする、リアル・タイム・プロセス制御システム。
13. 請求項１２記載のリアル・タイム・プロセス制御システムにおいて、
    前記ネットワーク（２０３）はイーサネット・ネットワークであることを特徴とする、リアル・タイム・プロセス制御システム。
14. 処理ユニット（２０１）と、前記処理ユニット（２０１）と通信することができる少なくとも１つの作動／検知ユニット（２１１、２１２、２１３）と、前記処理ユニット（２０１）と前記少なくとも１つの作動／検知ユニット（２１１、２１２、２１３）とを相互接続するネットワーク（２０３）とを有するシステムにおけるリアル・タイム・プロセス制御方法であって、
    ａ．前記少なくとも１つの作動／検知ユニット（２１１、２１２、２１３）の中の１つの作動／検知ユニットのオンボード通信インターフェース（２２１、２２２、２２３）から、計算タスクの適時評価を要求するメッセージを送るステップと、
    ｂ．前記処理ユニット（２０１）において前記メッセージを受信するステップと、
    ｃ．前記計算タスクをリアル・タイムで前記処理ユニット（２０１）において実行し、それに対し、リアル・タイム・オペレーティング・システムまたは混成リアル・タイム／非リアル・タイム・オペレーティング・システム（２３１、２３２）を走らせるステップと、
    ｄ．サーバとして作用する前記処理ユニット（２０１）から、クライアントとして作用する前記作動／検知ユニットに応答メッセージを送るステップと、
    を備えていることを特徴とする方法。
15. 請求項１４記載のリアル・タイム・プロセス制御方法において、
    当該方法は、前記処理ユニットと同様の複数の処理ユニット（５０１、５０２；６０１、６０２、６０３；８０１、８０２、８０３）に前記メッセージを送るステップを備えており、前記処理ユニット（５０１、５０２；６０１、６０２、６０３；８０１、８０２、８０３）は、冗長リアル・タイム計算サーバとして作用することを特徴とする、リアル・タイム・プロセス制御方法。
16. 請求項１５記載のリアル・タイム・プロセス制御方法において、
    当該方法は、前記少なくとも１つの作動／検知ユニット（８０４）によって前記複数の処理ユニット（８０１、８０２、８０３）上に生ずる計算負荷の均衡を取るステップを備えている、リアル・タイム・プロセス制御方法。

Images