JPH0855051A - 複数のノードの記憶手段に記憶されたデータベースの同期方法 - Google Patents

Abstract

(57)【要約】 【目的】 ネットワークで通信する複数のノードの記憶
手段に記憶されたデータベースの同期方法を提供する。 【構成】 ノードに記憶されたデータベースの最新の更
新時刻を示す時刻表示を各ノードの記憶手段に記憶する
ステップと、ノードに記憶された時刻表示を各ノードか
ら定期的に伝送するステップと、伝送された時刻表示を
各ノードで受容し、各受容時刻表示と記憶された時刻表
示とを比較するステップと、受容された時刻表示が記憶
された時刻表示よりも遅い場合には、時刻表示送出ノー
ドに対して、そのデータベースを時刻表示受容ノードに
送出するように要求するステップを含む。

Description

【発明の詳細な説明】

【産業上の利用分野】本発明は、独立して作動し得るか
又はネットワークを形成するように相互に接続され得る
自動処理システムに係る。特に本発明は、非限定的な例
として、ファシリティマネジメントシステム（ＦＭＳ）
で使用することができる。

【従来の技術及び発明が解決しようとする課題】プロセ
ッサ制御下で作動する従来技術の自動システムは、プロ
セッサ、作動ユニット（例えばセンサ及び他の物理的パ
ラメータ監視ユニット）、及びハードウェアで実現され
る他のデータ収集制御機器との間でデータを伝送させ
る。このような現代的システムとしては特に、自動産業
及び環境制御を行うファシリティマネジメントシステム
（ＦＭＳ）を挙げることができる。データ収集制御機器
の種々の型の間には一貫性がないので、自動システムは
複数の非標準作動ユニットに適合できなければならな
い。適合性を得るために、このようなシステムは個々の
インタフェース要件に合わせて注文設計されたソフトウ
ェアを使用することが多かった。このためには、ソフト
ウェア設計に多数の妥協が必要である。更に、新たな作
動ユニットを追加する場合、又は既存の作動ユニットを
変更する場合には、１個以上の完全なソフトウェアパッ
ケージを再書き込みすることがしばしば必要になる。こ
れは、新しい作動ユニットの要件が前のユニットに書き
込まれたソフトウェアに不適合な場合が多いためであ
る。ソフトウェアの種々の部分間及び作動ユニットとプ
ロセッサとの間のインタフェースは、ソフトウェアの肝
要部分であるので、ソフトウェアパッケージ全体を再書
き込みしなければならない。ソフトウェアが作動ユニッ
トの変更により影響される程度を減少させるための１つ
のアプローチは、論理点情報ノードの使用である。これ
は、高レベルソフトウェア機能を作動ユニットの個々の
特性から分離するしようとするモジュラーアプローチで
ある。しかしながら、このアプローチは依然として作動
ユニットの物理的又は論理的位置と、その個々の特性に
依存している。このようなモジュラーアプローチにより
高レベルソフトウェア機能をある程度まで分離すること
ができるが、入力及び出力に適応するように作動ユニッ
トに固有のソフトウェアを書き込むことは依然として必
要である。従って、既知の技術を使用すると、作動ユニ
ットハードウェアの相違により比較的影響されないよう
なソフトウェアを提供することは不可能であった。その
結果、新しい作動ユニットを追加する場合又は既存のデ
ータ収集ユニットを実質的に変更する場合に、大規模な
修正を必要としないソフトウェアを生成することも不可
能であった。特にデータ収集及び他の遠隔制御ハードウ
ェアを使用するシステムにおける関連技術の別の制約
は、使用可能なデータ構成体が制限されていることであ
る。データ収集及び他の遠隔制御ハードウェアは、典型
的には特別にフォーマットされたデータを備え且つ必要
とし、データの所望部分に適宜アクセスできないことが
多い。その結果、現状のシステムでは場合により、異な
る目的に使用すべきデータを複製したり、先に得られた
データに再びアクセスすることが必要である。また、こ
のようなシステムでは、データ収集装置により直接収集
されるデータでなく、処理装置により展開される中間デ
ータにアクセスすることは困難な場合がある。ファシリ
ティマネジメントに使用されるシステムを含む自動シス
テムは、集中又は分散処理技術を使用して作動し得る。
従って、ホストノードのデータは、ネットワークを通っ
てホストノードに接続された別のノード（参照ノード）
で処理するためにアクセスされ得る。実時間分散処理シ
ステムでは、比較的独立して作動するプロセッサノード
は情報を交換するために１つ以上のデータバスを介して
相互に通信する。参照ノードがホストノードのデータベ
ース内のデータエレメントにアクセスするためには、参
照ノードが必要なデータエレメントと、ホストノード内
の該データエレメントの固有ロケーションとを含むデー
タベースを有するホストノードを識別できるように規則
を設定しなければならない。このような規則は、適切な
ホストノードアドレス又はホストノード内のアドレスデ
ータへのアクセス要求を翻訳するために中央ノードを利
用しないようにすべきである。これは、この機能を実施
する中央ノードが故障すると、システム全体の作動が妨
げられるためである。更に、特定のデータエレメントの
ために実時間ネットワーク全体又は１つのノードのデー
タベースさえもサーチすることは許容し難い。これは、
このようなサーチにより費やされる時間が非常に長いた
めである。従って、ホストノード内から必要なデータを
得るための直接アクセスメカニズムが必要とされてい
る。更に、分散システムの各ノードのデータベースは、
システムの他のノードのデータベースから独立している
べきである。ホストデータベースが変化する毎に新しい
データを参照ノードにダウンロードすることにより、ノ
ードを同期させることも必要とすべきではない。先にホ
ストノードから入手可能であったデータがまだ存在して
いるとしても、ホストノードデータベースアドレスがど
のように変更されるかに関係なく、参照ノードで利用で
きるべきである。更に、データエレメントが１つのノー
ドから別のノードに移動する場合でさえも、データは参
照ノードで利用できるべきである。このような実時間分
散システム上のノード間でデータを参照するための従来
技術は、上記要件のすべてを同時に満足することができ
ない。１つの既知のアプローチは、ハードメモリアドレ
スの使用である。参照ノードは、そのデータベース内に
ホストデータベース内のデータの固定メモリアドレスを
維持する。参照データベースが通常はオフライン生成装
置で生成されるとき、アドレスは一般に名前付きのデー
タエレメントに結び付けられている。従って、結果はホ
ストノード内のデータに直接アクセスできるようにオン
ラインノードにダウンロードされる。この技術はデータ
への迅速なアクセスを提供し、アドレスを翻訳するため
に中央ノードを必要としないが、ホストノードデータベ
ースの変更に対する適応型を欠く。ホストノードデータ
ベースの変更の結果としてノード内のアドレスが変化す
ると、参照ノード内のデータエレメントに関連する固定
メモリアドレスは時代遅れになる。データエレメントが
１つのノードから別のノードに移動するときに同一の問
題が生じる。その結果、全参照ノードをデータエレメン
トの新しいアドレスに再同期しなければならない。特に
大型のシステムでは、これは時間消費的な作業であり、
更新が完了するまで参照ノードをオフラインとみなさな
ければならない。ファシリティマネジメントシステム
（ＦＭＳ）において参照ノードは、ノードがオフライン
のときにはもはや維持できないことが多い産業及び環境
制御機能を実施する。第２の技術は、データエレメント
をホストノード内で位置決めするために「ソフト」アド
レス又はレコード番号を使用する。この技術を使用する
と、論理データベース構造内の相対位置又は固有識別番
号がデータエレメントに割り当てられる。ハードメモリ
アドレス技術を使用する場合と同様に、高速且つ確実な
データアクセスが得られる。しかしながら、ホストノー
ドデータベースの変更によりデータベース内のエレメン
トの相対位置が変化した場合、参照ノードは再び時代遅
れになり、新しい情報を参照装置にダウンロードしなけ
ればならない。固有識別番号をデータ項目に割り当てよ
うとする場合には別の問題が生じる。更に処理しなけれ
ば、分散システムで同一認識番号が２つ以上のホストに
より使用されないように保証することは不可能である。
その結果、ネットワーク上に許容し難いコンフリクトを
生じる。最後に、参照ノードを更新後、古いデータベー
スをホストノードにダウンロードすると、参照ノード中
の情報が無効になってしまうので、このようなダウンロ
ードは不可能である。第３の従来のアプローチは、シス
テム内の各データエレメントに名称を割り当てることで
ある。名称はデータを位置決めするために使用される中
央ノードに記憶される。このアプローチはデータエレメ
ントが随意に移動できるので柔軟性が高いが、物理的ロ
ケーションへの名称のマッピングを含むこの中央ノード
は、信頼性の点で問題となる。これは、中央ノードが故
障すると、ネットワーク上の全通信が寸断されるためで
ある。第４の従来のアプローチは同様に、各データエレ
メントに名称を割り当てるものであるが、参照が行われ
る毎にネットワークをサーチすることにより中央探索ノ
ードの使用を省略する。しかしながら、ほとんどのシス
テムではデータエレメントが要求される毎にネットワー
ク全体をサーチするので、データ通信及び処理負担が許
容不能となる。複数のノードを有するネットワーク化シ
ステムは更に、一貫したオペレーションのために同期時
間及び大域データを必要とする。これは、ビルディング
の特定エリアの温度調節のようにスケジュールされた機
能が日時及び他の変数に基づいて規則的に作動し得るフ
ァシリティマネジメントシステムの場合に特に重要であ
る。即ち、システム上のノードの１つは時間を正確に追
跡し、他のノード間で時間情報を調整しなければならな
い。しかしながら、マスタノードを使用する現状のシス
テムは、マスタノードが故障した場合に時間調整できな
い危険がある。付加ノードをネットワーク化システムに
追加する場合、新しい各ノードのデータベースを大域変
数の最新データベースに同期させることも必要になる。
これらの機能を実施するためにマスタノードを使用する
従来のシステムは、マスタノードが故障した場合にこの
エリアで信頼性の問題の危険もある。また、個々のノー
ド又はノードと作動ユニットとの間の中間プロセッサと
通信する作動ユニットは、データバスネットワーク又は
類似構造を使用してノードに接続され得る。一貫性のた
めに、個々のノードに接続された作動及び処理ユニット
は、システム変数の最新値を受け取ることが必要であ
る。マスタノード制御下のネットワーク化システムは、
このレベルで同様の信頼性の危険がある。自動処理シス
テムでは、高レベルソフトウェア機能及びルーチンは、
同一レベルの他のプロセッサ又はシステム上のノードの
１つにより制御されるより低レベルのプロセッサで生じ
る事象によりトリガされ得る。しかしながら、ノードの
１つに新しい情報をダウンロードすることによりデータ
バスの変更が生じると、このような事象トリガにエラー
が生じ得る。これらの事象トリガ同期の問題を追跡しな
い現状のシステムは、新しい情報をノードの１つにダウ
ンロード後に重要なソフトウェア機能が実施されるよう
に保証することはできない。また、システム中で実施さ
れる処理により生じる結果又はシステムにより発生され
るコマンドのレポートは、適切な表示又は記憶装置にル
ーティングされなければならない。このような装置のロ
ケーションの変更に適応できない現状のシステムは、動
的環境では厳しく制限される。更に、ノードにダウンロ
ードされたこのような装置のロケーションデータの変更
を同期しない現状のシステムは、レポート又はメッセー
ジが適正な装置に到達するように保証することができな
い。実際に、システムによってはルーティングできない
メッセージは廃棄される。これは、このような設計をフ
ァシリティマネジメントシステムに適用するのに非常に
深刻な制限である。多くの場合、特にファシリティマネ
ジメントシステムでは、表示及びレポートはシステムデ
ータの標準化要約を含む。標準要約を生成する典型的な
アプローチによると、プロセッサはコマンドに応答して
又はデータ待機伝送用装置のルーチンポーリングの一部
として個々のレコードを検索する。次いでプロセッサ
は、アセンブルされているデータ要約への組み込みが適
切であるか否かを決定するために検索データを試験しな
ければならない。このような専用要約レポート生成試験
はプロセッサを占有し、データ通信の度合いを増し、そ
の結果、到達可能な処理速度が低下する。構成時にはネ
ットワークの一部でなかった装置にメッセージをルーテ
ィングすることによりレポートを得ることが望ましい場
合もある。例えば、パーソナルコンピュータ（ＰＣ）と
ネットワークノード上の非占有ポートとの接続を可能に
することにより、保守の容易さを強化することができ
る。場合により、ネットワーク上のノードにアクセスす
る他の非編成装置（例えばプリンタ）を備えることも望
ましい。従来のシステムは、例えばアドレスの割り当て
及び記憶によりネットワークにその存在を前以て知らせ
ていない装置と通信することができないので、このよう
な非編成装置の使用を制限する。上述のようにネットワ
ーク化システムは、システムに適切な処理機能を実施し
且つ通信リンクを通って相互に通信するためのコンポー
ネントを有する少なくとも２つのノードを有する。ファ
シリティマネジメントシステム（ＦＭＳ）において、こ
のようなノードはプロセッサ、Ａ／Ｄ及びＤ／Ａコンバ
ータ、並びにノードで実現される処理に必要なセンサデ
ータを得るため及び装置コマンドを発生するための他の
装置インタフェース回路を含み得る。通信リンクは、同
一バス、サブネットもしくはネットワーク上のノード間
又はゲートウェイを通る異なるネットワーク上のノード
間の通信を助長する種々の通信媒体を含む。ノードは１
つ以上の記憶装置でネットワークのメンバとして定義さ
れる場合にシステム上に構成される。ノードへの経路を
定義するデータを記憶することにより、ノード構成が発
生し得る。従って、システムはノードの存在を認識して
いる。システムに依存して、構成情報の記憶は集中又は
分散され得る。このような構成情報は、ノードの型、シ
ステム上のその位置、及びノードへの経路を規定する他
の情報を指示するデータを含み得る。ネットワーク化シ
ステム上で相互に接続されたノード間で通信するために
現在多数の技術が存在している。ブロードキャスト通信
方法では、ネットワーク上の全ノードはブロードキャス
トメッセージを受け取るか又は１つのノードから次のノ
ードへメッセージを順次転送する。ブロードキャストメ
ッセージを各ノードで処理する結果として、通信が無効
になる。従って、ネットワーク効率を改善するために他
のルーティングストラテジーが開発されている。ルーテ
ィングストラテジーは適応型又は非適応型であり得、シ
ステムは両方のストラテジーのエレメントを含み得る。
非適応型ルーティングストラテジーは、現在のトラフィ
ック又はトポロジーの測定値又は予想値と無関係にメッ
セージをルーティングする。これらのストラテジーは、
フラッディング（ｆｌｏｏｄｉｎｇ）又はブロードキャ
スト、選択的フラッディング、及び静的ルーティングを
含み得る。このような非適応型ルーティングストラテジ
ーの一例は、ネットワーク内の各ノード間及びゲートウ
ェイにより相互接続されたネットワーク間の通信経路の
グラフの作成を含む。ノード対間の最短経路を決定する
ためのグラフ分析技術が使用され、この情報はその後、
静的ルーティングテーブルにプログラミングされる。こ
のようなルーティングテーブルの１つにおいて、各ノー
ドは最終宛て先ノードに最終的に向けられるメッセージ
のための次の中間宛て先を識別する部分的経路データを
記憶する。各ノードはノード構成時に規定される静的ル
ーティングテーブルを有するので、一般にはネットワー
クの一部でない一時的又は外来ノードにより通信を助長
するようにルーティングテーブルを変更することは不適
切である。これは、データ通信経路ではルーティングテ
ーブルにリストされたノードしか使用できないためであ
る。動的又は適応型ルーティングストラテジーは、メッ
セージトラフィック及びトポロジーに応答して通信リン
クを通ってメッセージをルーティングする。適応型スト
ラテジーは、集中、孤立又は分散した動的ルーティング
を含む。集中ルーティングストラテジーは、通信リンク
を通って伝送されるメッセージの数及び長さを監視し且
つメッセージトラフィックパターンに基づいてルーティ
ングストラテジーを動的に発生する中央ノードを有す
る。これは通常、トラフィックパターンの変更に応答し
てルーティングテーブルを更新及び変更することにより
達せられる。分散ストラテジーは部分的ルーティングテ
ーブルをノード間に分配する。例えば、メッセージが最
終宛て先への経路に沿って中間ノードにルーティングさ
れるとき、中間ノードは宛て先ノードへの残りの代替経
路間のトラフィックパターンを試験し、所定の効率測定
値に従って幾つかの可能性の１つを動的に選択する。こ
うして、適応型ストラテジーは新しい装置の追加を含む
条件の変化に応答してルーティングテーブルを再構成す
ることができる。しかしながら、多くの場合は非編成装
置を組み込むことは不可能である。可能な場合であって
も、元々非編成の装置を一時的に組み込むにはしばし
ば、ルーティングテーブルを動的に調節するために必要
な処理を更に加える必要がある。このような処理はメッ
セージ伝送時間を増加させると共に、全体のシステム効
率を低下させる。保守、診断及び管理機能のような所定
の用途ではシステムの種々の部分により使用されるルー
ティングストラテジーに関係なく、システム中の通信リ
ンクの１つに存在するノードと一時的ノード又は処理装
置との間でデータ通信できることが望ましい。これは自
動ネットワーク化制御システムの場合に特に重要であ
る。このようなシステムは多くの場合、緊急保守及び診
断機能並びに一時負荷分析を必要とする。既存の技術
は、新しいノードをネットワーク上に構成する間にネッ
トワークの少なくとも一部を一時的に不能状態にする必
要があるので厄介である。新しいデータ通信経路ストラ
テジーを作成しなければならないので、ネットワーク上
に新しいノードを構成するのは困難である。更に、一時
的データ経路ストラテジーを開発する結果、一時的又は
非編成装置とネットワーク上に構成されたノードとの間
の通信ストラテジーが無効になる可能性がある。ネット
ワーク化自動処理又はコンピュータシステムでは、同一
データへのアクセスを必要とする複数のプロセッサが存
在し得る。多くの場合、このデータは、特定のセンサと
通信するプロセッサの１つにより収集される。同一デー
タを必要とする他のプロセッサは、データバスを通って
直接又は中間回路を介してデータを含むプロセッサと通
信する。既存の方法を使用すると、それ自体のセンサを
介して利用できないセンサデータを必要とするプロセッ
サは、センサとインタフェースするプロセッサにデータ
が必要であることを指示するために、データバスを通っ
て通信する。これに応答して、センサに接続されたプロ
セッサはセンサをポーリングし、データを検索する。次
にこのプロセッサは、このデータを遠隔処理ルーチンに
使用される要求プロセッサに伝送する。別の既知構成に
よると、遠隔プロセッサは、別のプロセッサにより制御
されるセンサからデータが要求されていることをマスタ
ノードに指示する。マスタノードは次に、データを検索
してマスタノードに伝送するようにセンサ制御プロセッ
サに指示する。マスタノードは次に、要求している遠隔
プロセッサにデータを供給する。こうしてプロセッサが
センサからデータを要求する毎に、センサ制御プロセッ
サはセンサにアクセスし、要求プロセッサ又はマスタノ
ードに情報を伝送しなければならない。多数のプロセッ
サがセンサ情報への高頻度アクセスを要求する場合、遠
隔プロセッサを相互に及び／又はマスタノードに接続す
るデータバスは、メッセージトラフィックですぐに動き
がとれなくなってしまう。別の既知の方法によると、バ
スを通ってマスタセンサに接続されたスレーブセンサは
フィルタリングインクリメントでセットアップされる。
フィルタリングインクリメントを使用する場合、センサ
を制御するスレーブプロセッサは、スレーブが新しい値
をマスタに報告する前にセンサが変更しなければならな
い所定のΔの値を定義する。マスタは、スレーブがデー
タを伝送するに従って、データのコピーを維持する。フ
ィルタリングインクリメントを使用する場合、スレーブ
プロセッサは、データがマスタに伝送される頻度を決定
する。従って、マスタプロセッサが更新されたセンサ情
報の要件をもたないとしても、スレーブプロセッサは情
報を伝送すべきであることをマスタに指示する。センサ
パラメータが高頻度で変化するパラメータである場合、
スレーブプロセッサは過度にデータバスを占有し、マス
タプロセッサへの情報は不必要に更新されかねない。別
の既知の方法によると、マスタはセンサ更新ののために
各プロセッサを規則的にポーリングする。この場合、更
新の必要がない場合にもデータは自動的に伝送されるの
で、同様に相互接続バス上のメッセージトラフィックが
過剰になる。更に、ポーリングシステムは、マスタが別
のセンサをポーリングしている間にセンサで発生し得る
重要な一時データ遷移を見逃す危険がある。上記場合の
各々において、データバス上の不必要なメッセージトラ
フィックは、ボトルネックを形成する傾向があり、デー
タバスがより優先権の高いメッセージトラフィックに迅
速に応答する能力を低下させる。現代の自動処理及びデ
ータ通信システムでは考慮されないことが多い別の因子
は、収集され且つシステムのエレメント間で通信される
データの信頼性及び完全性である。データの完全性及び
信頼性のレベルは、プロセスの測定パラメータに基づい
て操作変数を所望の状態に更新することにより環境又は
プロセスの確実な制御に達するように求めるファシリテ
ィマネジメントシステムにとって特に重要である。現在
のシステムは、測定データの品質に基づいてシステム性
能の制御された変数を生成するために、信頼性又はデー
タ完全性インジケータを開発及び有効に使用することが
できない。従来のシステムでは、ファシリティマネジメ
ントシステムで使用される比例及び積分及び微分コント
ローラの動作は、一度に１つのループしか制御すること
ができなかった。このようなＰＩＤループの複数の場合
は、このようなループ中の相違により単一のソフトウェ
アアプローチを使用して制御されなかった。ファシリテ
ィマネジメント及び他のシステムの設計における別の因
子は、システムコンポーネント故障に耐え得る制御シス
テムの設計であり、これは数十年来の懸案であった。耐
故障性のレベルを増加させる目的は、人体安全性、装置
安全性、及びシステム性能の制御の改善を含む。耐故障
性の最も基本的な形態は、故障安全システムコンポーネ
ントの適用を含む。従来の空気式ＨＶＡＣ制御産業で
は、しばしば暖房用として常時開弁の使用、混合エアダ
ンパ用として常時閉アクチュエータの使用を含む。これ
らの状況では、システム故障（例えば圧縮空気の損失、
温度伝達故障）は機械的システムを安全ではあるが、非
常に不快且つ不経済な状態に戻す。電子制御システムで
は、電気アクチュエータは同様の故障安全機能を提供す
るように自動的にばね復帰するように構成されている。
ディジタル制御システムの導入により、より高度の耐故
障性が可能である。ディジタルコントローラは、センサ
故障のような特定の入力信号故障条件をトラップする能
力を有しており、このような故障をソフトウェアで部分
的に補償することができる。柔軟なソフトウェア応答は
フェールソフト機能と呼称される。センサ故障の場合の
フェールソフト機能の例は、１）現在の制御信号を維持
し、２）制御装置を中間安全位置に指令し、又は３）代
替ストラテジーに基づいて適切な制御信号を計算する機
能を含む。冗長コンポーネントの適用以外に、代替又は
バックアップ制御ストラテジーを使用すると、機器故障
の場合に装置安全性、居住快適さ及びエネルギ効率を同
時に維持するための最適機会が得られる。フェールソフ
ト概念の拡張は、特定の制御されたプロセスに個々に適
応し且つ故障の場合に長時間にわたって公称システム性
能要件を満足し得るインテリジェントストラテジーの適
用を含む。数種のインテリジェントストラテジーが先進
軍事用航空機及び原子力発電所で現在適用されている。
以下に記載する方法及び装置は、ＨＶＡＣ産業で適用す
べきインテリジェントバックアップ制御ストラテジーで
ある。ファシリティマネジメントシステムは、エネルギ
最適化のために需要制限及び負荷ローリングを使用す
る。需要制限機能は、電力会社により使用される需要時
限に対応するスライド時限にわたって現在のエネルギ消
費を監視する。この機能は、平均エネルギ消費を設定限
界以下に維持するようにシステムを制御する。将来の需
要を予測するために履歴データを使用しない従来のシス
テムは、エネルギ消費の突然のピークに過剰反応する傾
向があり、その結果、過剰の負荷を遮断する。負荷ロー
リング機能は、周期的に負荷を短時間遮断することによ
り総エネルギ消費を減少させる。使用者は遮断しておく
べき目標負荷量を指定する。環境条件に適応しないシス
テムは、過度に長時間遮断される負荷により制御される
エリアで両極端を生じ得る。分散ファシリティマネジメ
ントシステムでは、負荷は複数の制御ノードに分配され
得る。一方、１つのノードは需要制限及び負荷ローリン
グ機能を実行し、それ自体及びシステム中の他のノード
に負荷を遮断する。負荷を遮断後、負荷コマンドを発生
するノードと負荷を含むノードとの間の通信が喪失され
得る場合に問題が生じ得る。このような状況で、負荷は
無制限に遮断されたままであり、負荷により制御される
エリアに環境両極端を生じる。負荷遮断を指令するノー
ドは、全負荷とその環境オーバーライドを監視するため
に時間遅延及び情報ボトルネックを受け得る。ファシリ
ティマネジメントシステムの高レベル性能を得る上での
別の重要な因子は、外部及び自己誘導雑音の影響を減ら
すことである。更に、外部電磁妨害（ＥＭＩ）に対する
免疫をシステムに与え、他のシステムに影響し得る望ま
しくないレベルのＥＭＩの発生を阻止することが必要で
ある。これは、例えば非常に低レベルのセンサ信号と著
しく高レベルのディジタル及びバイナリ信号とに適応す
るために広いダイナミックレンジが必要な場合に特に重
要である。単一電源及び他の既知の電源フィルタリング
技術を使用するシステムは、単一電源に依存しているた
め、スプリアス信号から十分に分離することができず、
又は十分な信頼性を提供することができない。また、多
くの今日のシステムは更に、環境に誘導されるスプリア
ス信号の両極端を受けるセンサからディジタル信号ライ
ンを十分に分離することができない。これは、バス構造
及びネットワークを使用するシステムで特に重要であ
る。信号が同一通信媒体に接続された他の装置と通信す
る場合、ネットワーク上の単一センサに予測できない変
化が生じると全体の問題となり得る。共通の通信媒体上
で相互に接続された装置の故障の影響から分離する必要
もある。このような分離を怠ると、単一ノードで故障が
生じた場合にネットワーク及びサブネットワークは完全
な故障に陥る。従って、相互接続されたシステムコンポ
ーネントを相互に分離するようにシステム相互接続の全
レベルで構成することが望ましい。また、故障の場合に
システムが徐々に性能低下するように構成することも望
ましい。ファシリティマネジメントシステムの他の制約
は、種々の装置と制御ノードとの接続にある。複数の装
置を特に同一バス上に接続する場合、伝送媒体上に雑音
が導入される。更に、伝送媒体は他の内外ソースから雑
音を受ける可能性がある。伝送媒体の２本のリード（例
えばツイストペア線）上に逆極性の電圧が出現する示差
雑音と、バスの２本のライン上に同一雑音が誘導される
共通モード雑音との両方が予想される。装置とバスとの
光学結合を使用する場合でさえも、雑音の影響を更に減
らすための処置をとることが必要であり得る。

【課題を解決するための手段及び作用】上記関連技術の
制約を解決するために、本発明は高レベルソフトウェア
機能と作動ユニットの間のインタフェースを提供するソ
フトウェアを実質的に分離し、高レベルソフトウェアを
大規模に変更する必要なしに作動ユニットに変更を加え
るための方法及び装置を提供する。中間レベルのソフト
ウェアは、作動ユニットの特性から独立して同様に全入
出力を処理する。別の中間レベルのソフトウェアは、高
レベルソフトウェアと作動ユニットハードウェアとの間
のインタフェースを制御する。前者の中間レベルのソフ
トウェアは、同様に作動ユニットからのデータの全高レ
ベルソフトウェア要求を処理する。後者の中間レベルの
ソフトウェアは、タイプの標準化アプローチに従って操
作され得るタイプにハードウェアユニットを分類する。
全中間レベルのソフトウェアは、属性のデータベース
と、属性を操作するための共通方法及びメッセージセッ
トとを有しており、遠隔制御される作動ユニットに適応
するように広いデータ構成体を提供する。このようなデ
ータ構成体は、複数の作動ユニットで同一データ又はデ
ータ属性を再生する必要を最小にする。データ構成体は
少なくとも１個の他のデータ構成体への経路を規定する
属性を有する。従って本発明は、関連するデータ構成体
の属性を含むデータ構成体を提供する。本発明は、中央
探索ノードを必要とすることなく且つデータへの参照毎
にネットワーク全体をサーチする必要なしに、分散シス
テムでデータをアクセスする方法を用いて、分散システ
ム中のノード間でデータをアクセスする柔軟で確実な方
法を提供する。分散システム内でデータをアクセスする
この方法は、最初に定義されるときに固有名称をデータ
エレメントに割り当てる。データエレメントの固有名称
は、データエレメントが最初にアクセスされるときにホ
ストノードに結び付けられる。こうして、使用者が定義
した名称及びネットワーク上のデータエレメントの物理
的ロケーションに基づいて多重レベルの命名規則を使用
して分散ネットワークでデータにアクセスすることがで
きる。この命名規則によると、使用者はデータエレメン
トがネットワーク上のどこに位置するかに関係なくデー
タエレメントに名称を割り当てる。命名規則によると、
実行ネットワーク中で最初に参照されるときに名称は固
有アドレス（例えば物理的ロケーション及びノード内の
データベースロケーション）に結び付けられる。その後
のデータエレメントの参照は、固有アドレスに結び付け
られた使用者割り当て名称を使用することにより行われ
る。システムノードの時間同期及びノード間の大域変数
の同期化データベースを有する分散システムを提供する
ことも有用である。ノードは、ノードの大域変数のデー
タベースが最後に更新された時点を指示するタイムスタ
ンプを使用するシステム上にその存在を周期的にブロー
ドキャストする。その結果、最新に更新された大域デー
タベースを有するノードの大域データベースを組み込む
ために、ネットワーク上の全ノードを調整することが可
能である。本発明は更に、夫々のデータベースにおける
データ構成体の不一致及び重複を検出及び報告する。こ
れは、システム上の他のロケーションで複数の定義を有
するノードのデータベースにおけるディレクトリエント
リを認識することにより、システム内で行われる。ルー
ティングテーブルを含まないノードは、ルーティングテ
ーブルを含まないノードからダウンロード情報を含む装
置へダウンロード要求をルーティングするための経路を
識別するために、ルーティングテーブルを有する他のノ
ードを識別する。システム内で、データ構成体はノード
中の高レベル機能に他のノード上の属性及びオブジェク
トの状態変化を通知し、又はこのような状態変化により
トリガさせる。更に、システム中のオブジェクト及び属
性のロケーションの変化は、オブジェクト又は属性によ
り起動又はトリガされる機能に通知するために検出され
得る。システムプロセスにより生成される結果は、適切
な表示及び記憶装置に報告される。従って本発明のシス
テムは、表示及び記憶装置の物理的ロケーションの変化
を検出し、適正な装置にレポートをルーティングする。
記憶又は表示のためのデータの標準又は予め定義された
要約を生成するのに必要なデータトラフィック量を減ら
すために、本発明のシステム又は方法は標準要約の生成
に使用されるデータをフィルタする。これは、検索すべ
きデータのディレクトリと同一のノードでタスクにルー
ティングされる高レベル機能ディレクトリでのデータ検
索のための基準を定義することにより得られる。システ
ムは、ディレクトリで識別されるノードに従って標準要
約データを検索することができ、ディレクトリを含むノ
ードにおけるデータを、要約を生成する機能に伝送する
ためのメッセージにアセンブルすることができる。本発
明の別の特徴によると、システムが元のネットワーク構
成に含まれない装置をネットワーク上の編成ノードと通
信できることも望ましい。従って、非編成装置はネット
ワーク上の編成ノードからメッセージを受け取ることが
できる。このような非編成装置は、既存のノードにおけ
る静的又は動的ルーティングテーブルのダウンローディ
ング又は更新を必要とすることなしに、適応又は非適応
型ルーティングストラテジーを使用するネットワークに
アクセスすることができる。本発明のこの特徴に従うシ
ステムによると、このような非編成装置は、適応又は非
適応型ルーティングストラテジーを使用するネットワー
ク上の第１の編成ノードに接続され、システムの遮断を
必要とすることなしに同一又は異なるルーティングスト
ラテジーを使用する他のネットワーク上の他のノードか
らメッセージを受け取ることができる。処理装置はシス
テム上のネットワークに帰属する必要なしに要求に応じ
ての通信システムにアクセスすることができる。このよ
うな処理装置は、システム中のどこからでも診断、保守
及び管理機能を実行するためにシステムにアクセスす
る。これらの処理装置は、大域変数又は静的もしくは動
的ルーティングテーブルもしくはディレクトリに変更を
必要とすることなく、要求に応じてデータ通信システム
にアクセスする。本発明は更に、不必要なメッセージト
ラフィックを生成することなしに要求プロセッサから離
れたデータにアクセスすることが可能なデータ通信アプ
ローチを提供する。本発明は更に、ファシリティマネジ
メントシステムにおけるセンサデータへの不必要なアク
セスを減らし、スレーブコントローラが情報を必要とし
ないマスタコントローラへこの不必要な情報を提供しな
いようにすることができる。センサ情報へのアクセス
は、センサにより測定されるパラメータの予想変化の割
合に基づいて制御される。マスタコントローラは、セン
サのバリディティ及びシステムのデータ転送の必要に従
って遠隔スレーブコントローラによりセンサ情報へのア
クセスを調節する。更に、ローカルバス上のデータ生成
プロセッサを調節するマスタコントローラにネットワー
クバスを通って接続された遠隔マスタコントローラによ
りデータへのアクセスを調節することが可能である。本
発明の別の特徴は、データエレメントの信頼性を試験
し、試験データの状態にその信頼性のインジケータをタ
グすることである。更に、システム全体でデータエレメ
ントに関連する信頼性インジケータを報告することも有
用である。システム全体で中間計算で使用されるデータ
に信頼性インジケータを関連付けることにより、１つ以
上の計算により得られる結果の信頼性指標を決定するこ
とができる。ソフトウェアの一部は、制御システムにお
ける高レベルソフトウェア機能からのコマンドを翻訳す
るため、並びに比例及び積分及び微分（ＰＩＤ）制御ル
ープを起動及び制御する（例えば閉鎖最上制御プロセス
の一部としての装置を起動及び制御する）適切な信号に
これらのコマンドを変換するために、一般化した比例及
び積分及び微分制御オブジェクトとして提供される。こ
のソフトウェアオブジェクトは更に、ＰＩＤループの外
部のスキーマによる制御からＰＩＤ自動制御手段による
制御への予想可能な制御下の転送を提供する。ソフトウ
ェアオブジェクトの他の機能は、プロセスを制御する出
力とプロセスからの感知されたフィードバックとの間で
コントローラが受け得るヒステリシス効果を除去し、Ｐ
ＩＤ制御に可調節デッドバンドを提供することである。
ＰＩＤ装置オブジェクトとしてのソフトウェアメカノズ
ムは更に、実際のＰＩＤハードウェアを他のソフトウェ
アオブジェクト及びＰＩＤループのスケジューリング手
段にインタフェースする能力を提供する。ＨＶＡＣ適用
では改善されたバックアップ制御ストラテジーを実現す
ることが望ましいので、本発明は、入力変数が不確実に
なるときにプロセス全体に制御を維持する能力をＨＶＡ
Ｃ制御システムに提供する。プロセスのオペレーション
は、プロセスからのフィードバックが失われるか又は不
確実な場合であっても、システム又はプロセスのモデル
及び他のシステムインプットに基づいて提供される。シ
ステム又はフィードバックが不確実になるときに１組の
パラメータがロックされる。従って操作変数は、システ
ム又はプロセスが不確実になる直前のプロセス変数の状
態及びプロセス変数の現状態に基づいて調節される。従
って、不確実な変数の存在下でのセットポイントの変化
に対するＨＶＡＣシステムの応答を制御することもでき
る。本発明の別の特徴によると、現需要及び履歴収集デ
ータに基づいて将来の需要期間におけるエネルギ需要を
予想することができる。この情報により、システムは予
想エネルギ需要に適応するように負荷のオンオフ時間を
自動的に変化させ、こうして平均需要をターゲット以下
に維持することができる。更に、エネルギ消費を高価な
高需要期間からより廉価な低需要期間にシフトさせるこ
とによりコストを最小にするようの負荷の動作時間を調
節し、負荷により影響されるエリアにおける環境条件に
適応するように負荷の動作時間を調節することが可能で
ある。別の特徴によると、１つのノードにおける需要制
限及び負荷ローリング機能と他のノードにおけるオブジ
ェクトとの間の通信は、過剰のトラフィックにより損な
われない。需要制限の結果として遮断される負荷は、需
要制限機能との通信が回復するまで遮断状態に維持され
る。負荷ローリング機能を含むノードが復元されないと
しても、負荷ローリングの結果として遮断される負荷は
復元される。遮断及び復元特性は、高レベルソフトウェ
ア機能の一部としてよりもむしろオブジェクトの一部と
しての属性として提供される。オブジェクトマネージャ
へのメッセージは、ノード内に局限された復元タスクを
使用してノードに固有の負荷の負荷関連特性を転送す
る。ノードに接続されたローカル装置間の雑音結合を減
らすために、ノードとローカルバスに接続されたローカ
ル装置との間の信号の光学結合が使用される。バス上に
誘導される示差モード雑音の影響は、バスのリードを予
め決定された電圧にバイアスすることにより改善され
る。光アイソレータは、このような高電圧を安全にアー
スに分岐するためにトランゾーブ（ｔｒａｎｚｏｒｂ）
及び金属酸化物バリスタを使用することにより共通モー
ド高電圧から保護される。ノードがデータを送信及び受
信している時点を示すインジケータが提供される。ロー
カルバスインタフェースの部分への別個のディジタル及
び通信電源が提供される。光学カプラはディジタル及び
通信電源を分離する。その結果、システムは通信電源上
にピークである２５００Ｖまでの雑音が存在しても悪影
響なしに作動することができる。本発明の１特徴による
と、ソフトウェアは多重レベルに編成される。最高又は
「機能」レベルは、ソフトウェアオブジェクトデータベ
ースマネージャ及びデータベースを含むソフトウェアオ
ブジェクトレベルと通信する。ソフトウェアオブジェク
トレベルは、同様に機能レベルへの全入力及び機能レベ
ルからの全出力を処理する。更に、ソフトウェアオブジ
ェクトレベルは、より低い中間レベルであるハードウェ
アオブジェクトレベルと通信する。ハードウェアオブジ
ェクトレベルは、ハードウェアオブジェクトデータベー
スマネージャ及びデータベースを含む。ハードウェアオ
ブジェクトレベルは、ソフトウェアオブジェクトレベル
への個々の作動ユニット間の相違をカバーするように作
動する。ハードウェアオブジェクトレベルは、データベ
ースを少しも変更させることなく既知の型の追加ユニッ
トを追加できるように、データ収集ユニットを分類す
る。ソフトウェア変更をハードウェアオブジェクトレベ
ルに限定させながら別の型の作動ユニットを追加するこ
とまできる。従って、全体のシステムソフトウェアに大
きな衝撃を与えることなしに新しいユニットを組み込む
ことができる。ソフトウェアは更に点及び疑似点を使用
する。１つ以上の属性は点をベクトル量として定義す
る。ベクトル量を特徴付ける属性の値は、センサのよう
な作動ユニットから得られる。各個々の点は、システム
中の他のいかなる点も参照することなく定義される独立
したベクトル量である。疑似点も同様に、属性により定
義されるベクトル量である。しかしながら、疑似点の属
性の少なくとも１つは、関連点又は点の属性を識別す
る。従って、点に関連する作動ユニットに繰り返しアク
セスする必要なしに中間計算を容易にするために、識別
点から疑似点の付加的属性が得られる。本発明の他の特
徴は多重レベル命名規則により得られる。まず最初に、
各データエレメントはデータのその部分のみに使用され
る固有の識別子となるように、システムに固有の名称を
割り当てられる。名称割り当ては、データエレメントが
ネットワーク生成プロセスで生成されるときに行われ
る。名称が実行ネットワーク中で最初に参照されると
き、名称はノードロケーション及びノード内のデータベ
ースロケーションの両方を識別する固有のアドレスに割
り当てられるか又は結び付けられる。これは、名称が最
初に参照されるときにネットワークでデータエレメント
を名称によりサーチすることにより行われる。その後、
この結合されたリファレンスを使用して、ランタイム中
にデータエレメントの次の参照毎に該データエレメント
を位置決めする。別の特徴によると、ノード中の大域変
数間の一貫性が維持される。一点間隔で各ノードはその
存在及び大域変数のデータベースの最新の更新を指示す
るタイムスタンプをブロードキャストする。ブロードキ
ャストを受信するノードは、そのタイムスタンプを最新
にブロードキャストされたタイムスタンプに比較する。
タイムスタンプが同一でない場合、受信ノードは最後の
データを有するブロードキャストノードにより新しい大
域変数データベースをダウンロードするように要求す
る。これは、全ノードが最新の大域変数を有するように
行われる。本発明の別の特徴によると、ファシリフィマ
ネジメントシステムは、複数のノードの各々がノード上
に定義されるシステム中の全名称のリストを有するよう
な複数の独立したシステムに分割される。１つ以上の相
互に接続されたネットワークにシステムを分散できるよ
うにするために、システム定義はシステム定義ノードに
記憶されたシステムのオブジェクトのディレクトリを含
む。ディレクトリは、システムの全オブジェクトが単一
ノードに存在する必要がないようにオブジェクトがどの
ノードに配置されるかを定義する。オブジェクトが１つ
のノードの制御から別のノードの制御に移動するとき、
ディレクトリは更新される。本発明の別の特徴による
と、システム内でタイミングを調整するために単一のノ
ードを使用する。タイムキーピングノードは、規則的に
スケジュールされた機能を必要に応じて実施できるよう
に、カレンダーの日付及び時刻を監視する。更に、カレ
ンダーの日時を監視するノードが不能になった場合に
は、第２のノードがこの機能を実行する。カレンダーの
日時の情報は更に、システム上に分配された全ノードで
維持され得る。ノードは正常動作条件下で毎日固定時刻
に日時情報を全ノードに再分配することにより時間同期
される。こうして複数のノードで一定してルーチン更新
及び同期を行うことができる。別の特徴によると、ノー
ドは他のノードを通ってダウンロード要求をカスケード
する能力を有する。ルーティングテーブルを含まないノ
ードは、ダウンロード要求をルーティングするための経
路を識別することが可能なルーティングテーブルを有す
る別のノードを識別する。従って、第１のノードがルー
ティングテーブルを含むならば、ルーティングテーブル
を含まない第２のノードは、ルーティングテーブルを含
むノードを介して外部装置からダウンロード情報を受け
取ることができる。本発明の別の特徴によると、状態変
化に応答してオブジェクトの属性のトリガが行われる。
オブジェクトマネージャ及び高レベルソフトウェア機能
は特定事象が生じたときに通知されるように「契約（ｓ
ｉｇｎ−ｕｐ）」している。例えば、センサが既知の閾
値を越えるとアラームがトリガされ得る。センサ情報及
び機能を処理するオブジェクトマネージャを同一ノード
に配置する必要はない。機能は適切なオブジェクトマネ
ージャにより通知されるように「契約」してさえいれば
よい。ただし、オブジェクトマネージャが変更した場合
には、契約は無効になる。これは検出され、機能に通知
される。別の特徴によると、レポートのルーティングは
分散される。ルーティング情報は、ネットワーク上の各
ノード内で大域データとして維持される。ノードから発
生されるレポートは、最終分配用レポートルータタスク
を介して宛て先装置にルーティングされる。レポートル
ーティングタスクは、ノードの入出力ルーチン間で媒介
として機能する。レポートルータは、入出力ルーチンが
レポートを宛て先装置にルーティングすることができる
か否かを決定する。もし否である場合には、レポートル
ータは第２又はデフォルト装置を使用可能であるか否か
を決定する。否である場合には、メッセージは廃棄さ
れ、レポートルータはこのことを通知される。デフォル
ト装置を使用可能な場合、レポートはデフォルト装置に
ルーティングされる。別の特徴によると、記憶又は表示
のためのデータの標準又は予め規定された要約を生成す
るために必要なデータトラフィック量が減少する。これ
は、特定の該当オブジェクトディレクトリが配置されて
いるノードにデータのフィルタリングを局限することに
より得られる。標準要約データは、第１のノードのディ
レクトリで識別されるノードから得られる。データは第
１のノードに接続された装置から得られる必要はなく、
ディレクトリ中で識別されるノードから得られる。デー
タが得られると、該データはディレクトリを含むノード
で、要約を生成する高レベルソフトウェア機能に伝送す
るためのメッセージにアセンブルされる。高レベルソフ
トウェア機能は任意のノードに配置することができる。
本発明の別の特徴によると、ネットワークの編成ノード
上のポートに非編成装置を接続することができる。それ
自体のプロセス識別子を含む非編成装置は、ポートを介
して編成ネットワークノードと通信する。編成ネットワ
ークノードは、非編成装置からそれらの宛て先にメッセ
ージをルーティングするために他の編成ネットワークノ
ードと通信する。宛て先ノードは、編成ネットワークノ
ードとして又は編成ノード上のポートから分岐された非
編成装置としてメッセージソースを認識する。従って宛
て先ノードでは、発生される応答は非編成装置としてソ
ースの状態に対して透過的である。最終宛て先ノードは
メッセージが編成ノードからであるかのように応答し、
応答メッセージは、非編成装置に接続されたポートを有
する編成ノードに復帰する同一又は別のデータ通信経路
に従う。非編成ノードと編成ノードとの間のドロップを
介する通信に基づいて、編成ノードは非編成装置にメッ
セージを提供し、非編成装置はこのメッセージをメッセ
ージ中で識別されるプロセスに送達する。こうして、任
意の編成ノードは非編成装置により行われるデータ要求
に応答することができる。本発明の別の特徴は、マスタ
コントローラがデータエージングテーブルに中センサ値
を記憶し、各センサ値を有効時間フレームに関連付ける
ような方法及び装置を提供する。有効時間フレーム中の
データの全要求は、マスタコントローラ中のデータエー
ジングテーブルからの値を伝送することにより提供され
る。こうして、別のデータ要求がスレーブコントローラ
に送られるのを阻止し、ローカルバス又はネットワーク
バス上のメッセージトラフィックを減少させることがで
きる。更に、エージングタイマ値をセンサデータの特性
に合致させることもできる。別の特徴によると、本発明
はデータ信頼性の状態を検出するためのインジケータを
提供する。各データエレメントは、データエレメントを
含む全計算を介して伝播される信頼性インジケータを割
り当てられる。その結果、各中間計算はデータエレメン
トの信頼性も考慮するので、計算の精度の全体の確実さ
を決定することができる。本発明の別の特徴によると、
一貫した時間間隔でフィードバック値のサンプリングに
基づく比例及び積分及び微分コントローラソフトウェア
オブジェクトが提供される。オブジェクトは、個々の項
目が除去され得るように比例、積分及び微分項目を別々
に組み込む。こうして、比例、積分及び微分制御の任意
の組み合わせを容易に有することができる。ＰＩＤソフ
トウェアオブジェクトは、入力調節が実施され、且つサ
ンプル周期、比例バンド及び他のパラメータに従って処
理される点及び疑似点を利用する。変数の完全変化域の
百分率を出力することにより、対応する出力ポートが駆
動され得る。更に、入力プロセス条件の変化が与えられ
ているとき、制御変数の定常状態変化を予測するための
耐故障性制御ストラテジーを使用することもできる。有
効性の測定値に基づく単純化モデルを適用すると、プロ
セス変数の変化による有効性の変化が得られる。更にプ
ロセスモデルは現作動点の周囲の制限された領域にのみ
有効であると仮定するならば、操作変数の前の値、他の
操作変数、一次及び二次プロセス変数、制御変数の初期
値、並びにセットポイントに基づいて操作変数値を計算
することができる。制御変数の初期値のみに依存するシ
ステムにセットポイント及び一次及び二次プロセス変数
を組み込むことにより、制御変数又はフィードバック信
号が現在不確実であるとしても、現入力及びシステム履
歴に基づいて変数を操作することができる。本発明の別
の特徴によると、以前のエネルギ消費のウィンドウに基
づいて将来の需要期間におけるエネルギ需要を予測する
ことができる。予測エネルギ需要に応答して、需要限界
を越えないように需要に寄与する負荷を遮断するように
コマンドを発生することができる。需要制限又は負荷ロ
ーリング機能により遮断される負荷は、定義可能な時間
経過により又は負荷により影響されるエリア中で検出さ
れる環境条件の極限の結果として復元される。負荷はシ
ステムの複数のノードに分配されるので、負荷を遮断す
る高レベル機能は、負荷との通信を失い得る。負荷ロー
リングコマンドの結果として遮断される負荷が該負荷に
規定される時間間隔後に復元されるように、復元タスク
は各ノードの内側に局限される。特定の遮断及び復元特
性は、需要制限／負荷ローリング高レベルソフトウェア
機能の一部としてではなく、負荷を有するノードにおけ
るオブジェクトの属性として記憶される。従って、１つ
のノード内の高レベルソフトウェア機能は、適正な時刻
で負荷を復元するために、負荷との通信を維持する必要
なしにシステム全体に分配される負荷を遮断することが
できる。局限された復元タスクは更に、負荷により影響
される環境条件を監視し、こうして需要制限／負荷ロー
リング機能を実行するノードから該タスクを除去するこ
とにより、ネットワーク上の余分なトラフィックを除去
する。本発明は更に、ＲＳ／４８５電子産業学会仕様に
適合可能なローカル光バスとの光インタフェースを提供
する。インタフェースは、バスのリード上の示差モード
雑音を「全廃（ｓｗａｍｐ ｏｕｔ）」するために使用
されるバイアス回路と、共通モード電圧及び過剰示差モ
ード雑音をアースに分岐するためのトランソーブ及びＭ
ＯＶ回路とを利用する。光アイソレータは、ディジタル
及び通信電源間の分離を確保し、ＬＥＤのような送受信
インジケータを起動するために再トリガ可能なワンショ
ットが使用される。

【実施例】図１は、プロセッサ１−３を持っているネッ
トワーク制御モジュール１−１、ダイナミックラム１−
５および電子的にプログラム可能なＲＯＭ１−７を概略
的に示す。ネットワーク制御モジュール１−１は高速バ
ス１−９、Ｎ１バス、と通信する、その結果、ネットワ
ーク制御モジュール１−１はローカル・エリア・ネット
ワーク構成の他のネットワーク制御モジュールに相互連
結させることができる。高速バス１−９上に接続された
複数のネットワーク制御モジュール１−１は、ゲートウ
ェイを通って、高速バスに相互に連結したネットワーク
制御モジュールの他のネットワークに相互連結させるこ
とができるネットワークを形成する。ネットワーク制御
モジュール１−１は、ポート１−１３上のモデムを介し
て通信を提供するための、複数のポートとつながる標準
ＲＳ−２３２１−１１、ポート１−１５をコンピュータ
上の専用ネットワークターミナルあるいはポート１−１
７上のプリンタをさらに有する。フィールド幹線コント
ローラ１−１９および１−２１は通信媒体１−２３と１
−２５で相互に連結したフィールド装置と通信すること
を、ネットワーク制御モジュール１−１に許可する。サ
ブネットコントローラ１−２７はＮ２バス１−３５上の
ネットワーク制御モジュール１−１と通信することを装
置１−２９、１−３１、１−３３に許可する。Ｎ２バス
１−３５に印加されるかもしれない為の信号および電圧
上昇からネットワーク制御モジュール１−１を分離する
ために、Ｎ２サブネットコントローラ１−２７は、図示
に如く、ｏｐｔｐ−２２インターフェースを組込む。発
明に従ったネットワーク制御モジュールは、以下に記述
するネットワークコントロールユニットの中央の一部と
して機能する。ネットワーク制御モジュールは、単独あ
るいはネットワークコントロールユニットの一部とし
て、高速のＮ１バス１−９によって相互に連結したノー
ド用のコントローラとして機能する。したがって、ネッ
トワーク制御モジュールの一次機能は、他のネットワー
ク制御モジュールあるいはネットワークコントロールユ
ニット、および高速バス１−９につながっているオペレ
ータワークステーションとの通信を監視することであ
る。ファシリティマネジメントシステム（ＦＭＳ）にお
いて、ネットワーク制御モジュールは、ビルディングの
エリアの監視制御を実行する。したがって、専用プログ
ラムに従って、ネットワーク制御モジュールはプログラ
ムパラメータに従った環境条件の維持、および、Ｎ２バ
ス１−３５を介してネットワーク制御モジュール１−１
に接続されたセンサーおよび他の装置のような運用上の
ユニットとの通信を監督する。ネットワーク制御モジュ
ール１−１は、様々なマンマシンインタフェース（ＰＭ
Ｉ）へのＲＳ−２３２インターフェース１−１１による
通信をさらに管理する。ファシリティマネジメントシス
テムの専用装置は、フィールド幹線コントローラ１−２
１、および１−１９、対応する通信媒体１−２５および
１−２３を介して接続することができる。発明に従った
ファシリティマネジメントシステム（ＦＭＳ）におい
て、ネットワーク制御モジュール１−１（それらはネッ
トワークコントローラと呼ばれることもある）は、バッ
クプレーンでコネクターと結ばれているモジュールのプ
ラグとして構成される。図２は、バックプレーンでコネ
クターとさらに接続するディジタルコントロールモジュ
ール２−１を示す。ディジタルコントロールモジュール
２−１はプロセッサ２−３およびメモリ２−５を含んで
いる。メモリ２−５はスタティックＲＡＭ部２−７、電
子的にプログラマブルなＲＯＭ（ＥＰＲＯＭ）部２−
９、および電子的に消去可能なＰＲＯＭ（ＥＥＰＲＯ
Ｍ）２−１１に分割される。さらに、ディジタルコント
ロールモジュール２−１は入出力部２−１３および２−
１５を持っている。以下に議論されるように、ディジタ
ルコントロールモジュール２−１は、さらに発明に従っ
たネットワークコントロールユニットに組入れられても
よい。ディジタルコントロールモジュールはセンサー入
力は、入出力部２−１３および２−１５を介して受信さ
れたセンサー入力を決定し、ネットワークコントローラ
あるいはネットワーク制御モジュール１−１へ変更を報
告する。さらに、ファシリティマネジメントシステム
（ＦＭＳ）において、ディジタルコントロールモジュー
ルは、複数のコントロールループのための閉ループ制御
を実行する。したがって、閉ループ制御はネットワーク
制御モジュールなしで遂行することができる。さらに、
ディジタル制御モジュール２−１は、ネットワーク制御
モジュール１−１から受信されたコマンドを実行する。
ディジタル制御モジュール２−１は、直接あるいはファ
ンクションモジュールを介して入力を受信することもで
きる。さらにファンクションモジュール（ＦＭ）は、入
出力信号の決定を行なう。発明に従ったディジタル制御
モジュールが、入力を直接（１００−１，０００オーム
のＲＴＤ、４−２０ｍＡ、０−１０ボルトのＤＣ（抵抗
性の温度装置））あるいは入力ファクションモジュール
を介して受信することができるのに対して、ディジタル
制御モジュール２−１からの出力はすべてファンクショ
ンモジュール選択によって特徴づけられる。ファンクシ
ョンモジュール（不図示）は信号を決定するが、非常に
複雑な処理は実行しない。そのようなファンクションモ
ジュールは発明に従って、リクエストされる特定のコン
ディショニングファンクションを提供するように適合作
成される。したがって、ファンクションモジュールは、
特定のタスクを実行するように適合作成された非常に複
雑なエレクトロニクスを含んでいてもよいし、あるいは
単一の抵抗器のような単純なものであってもよい。以下
に議論されるように、ネットワーク制御モジュール１−
１も、システムの各ノードが同じグローバル変数で作動
し、時間的に同期し、システム名の一貫したディレクト
リを持つことを保証するために、多数の背景タスクを実
行する。さらに、データ通信を圧縮し、データエージン
グを追跡し、かつ専用の操作可能ユニットからのハイレ
ベルソフトウェア特徴を分離する均一の手段を提供す
る、ネットワーク制御モジュール１−１内のソフトウェ
アが以下に議論される。ファシリティマネジメントシス
テムにおいて、典型的な入力ファンクションモジュール
は圧力／電気のトランスデューサ、バイナリ入力コンタ
クトあるいはＡＣ線間電圧コンディショナ、差動圧入力
およびバイナリ周波数入力を含んでいる。典型的な出力
ファンクションモジュールは、アナログ出力、絶縁グラ
ウンドを添えたアナログ出力、電気／圧力変換器、バイ
ナリ極性リバース、トライアックインクリメントのファ
ンクションモジュール、モータスタート／モータストッ
プファンクションモジュール、電気的に保持されたリレ
ー出力、磁気的にラッチされたリレー出力、およびソレ
ノイド空気弁ファンクションモジュールを含んでいる。
図３に示されるように、発明に従った展開モジュール
（ＸＭ）３−１はプロセッサ３−３およびメモリ３−５
を含んでいる。メモリは、スタティックラム（ＳＲＡ
Ｍ）３−７と電子的に消去可能なプログラム可能読取専
用メモリ（ＥＥＰＲＯＭ）３−９に典型的に分割され
る。ポイント多重モジュール３−１１は拡張モジュール
用の構成可能入出力を提供する。拡張モジュールも、フ
ァシリティマネジメントシステムのノードのバックプレ
インのコネクターにプログを差し込むモジュールのプラ
グである。拡張モジュールはバイナリ、アナログおよび
パルス入力を決定し、変更をネットワークコントローラ
あるいはネットワーク制御モジュール１−１に報告す
る。さらに、拡張モジュールは、ネットワークコントロ
ーラ１−１からのバイナリ出力コマンドを実行する。ポ
イント多重モジュール３−１１は、拡張モジュールの５
つの構成を提供する。これらは、３２個のバイナリ入力
を持つ第１構成、モメンタリーリレーを使用した８つの
バイナリ入力および８対の出力を持つ第２構成、８つの
バイナリ入力および８つの磁気的にラッチしたリレー出
力を持つ第３構成、８つのアナログ入力を持つ第４構
成、および８つのバイナリ入力と８つの電気的に保持さ
れたリレー出力を持つ第５構成を含んでいる。ネットワ
ーク制御モジュール、ディジタル制御モジュールおよび
拡張モジュールは、発明に従ったネットワーク制御ユニ
ットを形成するために、様々な構成で組合わせることが
できる。ファシリティマネジメントシステムのネットワ
ークコントロールユニット（ＮＣＵ）は、暖房および冷
房（ＨＶＡＣ）、照明、およびビルディング機能をモニ
ターし管理する。ネットワークコントロールユニットは
Ｎ１バス１−９によって相互に連結している。Ｎ１ネッ
トワークの一部として、ＮＣＵは、動的データ・アクセ
ス関係で他のすべてのＮＣＵとデータをすべて共有す
る。各ネットワークコントロールユニットが、他の任意
のネットワークコントロールユニットのコントロールの
下で得られたデータにアクセスしそれを使用することを
仲間通信が可能にするので、分散型システムが形成され
る。したがって、任意のレベルでの情報が、ビルディン
グ内の構成要素をすべて統合し最適化するために、すべ
てのＮＣＵにアクセスすることが可能である。さらにネ
ットワークコントロールユニットは、制御システムを含
む幅広い系列の工業用制御処理および他の処理のよう
な、種々の物理的センサーおよび機器の使用及びモニタ
リングを含む他の制御機能を実行するために相互に連結
することができる。図４は、５つのスロット４−３、４
−５、４−７、４−９および４−１１が利用可能なＮＣ
Ｕ４−１の１つの構成を示す。スロット４−３は図１に
関連して以前に議論されたようなネットワーク制御モジ
ュールを含んでいる。ネットワーク制御モジュールは、
通信ターミナルボード４−１３を介して高速Ｎ１バス４
−１５に沿って単一の通信手段を提供する。ネットワー
ク制御モジュールだけが高速Ｎ１バス４−１５で通信す
る可能であることが注意されるべきである。図示の如
く、ディジタル制御モジュール、拡張モジュールあるい
は追加ネットワーク制御モジュールは、スロット４−５
〜４−１１を占めることができる。これらの装置間、お
よびネットワーク制御モジュールを使った通信はＮ２バ
ス４−１６を介したものである。スロット４−５および
４−９もネットワーク制御モジュールを提供することが
できる。これらのネットワーク制御モジュールは、さら
に図４の点線４−１７で示されるようにＮ１バス４−１
５および４−１９を通じて通信してもよい。図１に示さ
れるように、ネットワークコントロールユニット４−１
は、ネットワーク制御モジュール１−１のＲＳ−２３２
インタフェース部分１−１１を通じてオペレータにイン
ターフェースを提供される。ダイアル呼出しモデム１−
１３、専用ネットワークターミナル１−１５あるいはパ
ーソナルコンピュータのようなオペレータワークステー
ションを使用して、オペレータはコマンドを生成するな
り、それに応答するなりして、ユーザ指定データベース
にプログラム変更および編成データを提供してもよい。
図４の５つのスロットＮＣＵ構成は、さらに複数の入力
ファンクションモジュール、対応する入力ファンクショ
ンモジュールターミナルボード４−２７および４−２５
用のコネクター４−２１および４−２３を示す。同様
に、コネクター４−２９および４−３１は複数の出力フ
ァンクションモジュールを接続し、対応する出力ファン
クションモジュールターミナルボード４−３３および４
−３５が提供される。各個々のスロット４−３に４−１
１が４−４５によって自身の電源４−３７を提供される
ことにも注意すべきである。拡張モジュール入力端子ボ
ードは４−４７と４−４９で提供される。また、拡張モ
ジュール入出力端子ボードは４−５１と４−５３で提供
される。線間電圧Ｖは電源ターミナルボード４−５５に
印加される。ネットワークコントロールユニットの代替
構成は図５に示される２つのスロット構成５−１であ
る。スロット５−３および５−５は各々拡張モジュール
に接続することができる。スロット５−５がさらにネッ
トワーク制御モジュールに接続することができるのに対
して、スロット５−３もディジタル制御モジュールに接
続することができる。ネットワークコントロールユニッ
トを構成するためには、少なくとも１つのネットワーク
制御モジュールがリクエストされることに注意すべきで
ある。これは、以前に注意したように、ｐｅｅｒ−ｔｏ
−ｐｅｅｒ関係でＮ１バス上の他のネットワークコント
ロールユニットと通信することができるのはネットワー
ク制御モジュールだけであるという理由のためである。
したがって、スロット５−５は、Ｎ１バス５−７と接続
している。スロット５−３および５−５にインストール
される装置は、Ｎ２バス５−９を通じて互いに交信す
る。Ｎ１およびにＮ２バスの両方は一層の通信にシステ
ムの残る部分を提供するために通信ターミナルボード５
−１１に接続される。図４で議論されたのと類似の方法
で、複数の入力ファンクションモジュールをコネクター
５−１３に設置することができる。また、複数出力ファ
ンクションモジュールはコネクター５−１５に設置する
ことができる。入力ファンクションモジュールターミナ
ルボード５−１７および対応する出力ファンクションモ
ジュールターミナルボード５−１９がさらに提供され
る。同様に、拡張モジュール入力端子ボード５−２１お
よび拡張モジュール入出力端子ボード５−２３は拡張モ
ジュールにアクセスすることができる。スロット５−３
および５−５の装置にも独立した電源５−２５および５
−２７があることにも注意すべきである。線間電圧Ｖは
電源ターミナルボード５−２９に提供される。図６は発
明に従った単一のスロット構成を示す。スロット６−３
は、この場合装置が、Ｎ１バス６−５を介して他の装置
とｐｅｅｒ−ｔｏ−ｐｅｅｒベースで通信する能力を持
つネットワークコントロールユニットとして作動するネ
ットワーク制御モジュールを含むことができる。ＮＣＵ
６−１に外部Ｎ２バスに接続した装置との通信は、Ｎ２
バス６−７で行なわれる。図６が示すように、線間電圧
Ｖは電源ターミナルボード６−９に接続される。また、
電源６−１１は、スロット６−３の装置を供給する。図
６は、さらにスロット６−３にこの装置が拡張モジュー
ルでありうることを示す。したがって、図６の単一のス
ロット構成も拡張モジュール入力端子に６−１３ボード
および拡張モジュール入出電源ターミナルボード６−１
５を有している。前述したように、ネットワークコント
ロールユニットはＮ１バスを通じてｐｅｅｒ−ｔｏ−ｐ
ｅｅｒ通信を遂行するために、ネットワーク制御モジュ
ールを持たなければならない。しかしながら、図６の単
一のスロット構成が示すように、装置がネットワーク制
御モジュールのつかない拡張モジュールを有して構築す
ることは可能である。拡張モジュールがＮ１バスを通じ
て通信することができなかったので、装置はネットワー
クコントロールユニットできなかったので、装置はネッ
トワークコントロールユニットではありえない。発明に
従って、図４に示される５つのスロットバックプレイ
ン、図５に示される２つのスロットバックプレイン、お
よび図６に示される１つのスロットバックプレインのい
ずれかに、Ｎ１バスを通じて通信する能力を持っていな
い装置を構築することは可能である。そのような装置は
ネットワーク遠隔ディスプレイ増設ユニット（ＮＥＵ）
と呼ばれる。ネットワーク遠隔ディスプレイ増設ユニッ
トは２つのファンクションに役立つ。まず第一に、それ
らは、ＮＣＵのポイントおよびコントロールループ容量
を増加させるために、Ｉ／Ｏポイント用の収集プラット
ホームとして役立つ。第２に、ネットワーク遠隔ディス
プレイ増設ユニットは、ポイントまでコントロールをモ
ニタし分散し、それからＮ２バスを通じてＮＣＵへこれ
らのポイントからのデータを転送するために、ＮＣＵか
ら遠隔地に設置することができる。ネットワークコント
ロールユニットあるいはネットワーク遠隔ディスプレイ
増設ユニットのいずれかを構築するために、バックプレ
インを使用することができるので、代替構成は可能であ
る。図７は、１つ、２つおよび５つのスロットバックプ
レインを持つネットワークコントロールユニット用に可
能な、完全にロードされた代替構成を示す。図８は、１
つ、２つおよび５つのスロットバックプレインを持つ、
ネットワーク遠隔ディスプレイ増設ユニットの完全にロ
ードされた可能な構成を示す。図９は、発明に従ったフ
ァシリティマネジメントシステムの可能な構成を例示す
る。５スロットＮＣＵ９−１は、ＡＲＣＮＥＴ９−５の
ようなＮ１バスを通じて１スロットＮＣＵ９−３と通信
する。Ｎ１バス９−５は、さらにパーソナルコンピュー
タ９−７に接続される。パーソナルコンピュータ９−７
は、新しい情報とデータベースを、ＮＣＵ９−１と９−
３、ならびにＮＣＵ９−１と９−３に接続される他の装
置へダウンロードするためのダウンロード装置として使
用することができる。Ｎ１バス９−５は、ＮＣＵ９−１
の通信ターミナルボード９−９、およびＮＣＵ９−３の
ターミナルの通信ボード９−１１に接続される。ＮＣＵ
９−１内では、Ｎ１バス９−１３はネットワーク制御モ
ジュール９−１５に接続される。これが５スロットＮＣ
Ｕ９−１に示される唯一のネットワーク制御モジュール
なので、５スロットＮＣＵ内ではＮ１バス９−１３への
接続はそれ以上ない。５スロットＮＣＵ９−１も拡張モ
ジュール９−１７、および９−１９、ディジタル制御モ
ジュール９−２１および９−２３を持つ。これらのモジ
ュールは、以前に議論された機能を実行し、Ｎ２バス９
−２５を介して５スロットＮＣＵを相互連結している。
インターフェースは、ラップトップＰＣ９−２７を介し
て、５スロットＮＣＵＮ１およびＮ２バスに接続した装
置と直接通信する。図９が示すように、ラップトップ９
−２７は、ネットワーク制御モジュール９−１５の一部
であるＲＳ−２３２インターフェース９−２９に接続さ
れる。専用ネットワークターミナル９−３１用のネット
ワーク端末装置は、さらにＲＪ−１１インタフェース９
−３３に接続される。ネットワーク制御モジュール９−
１５もサブモジュール９−３５と９−３７を持つ。その
ようなサブモジュールは、サブネットコントローラ１−
２７、フィールドトラックコントローラ１−２１および
ＲＳ−２３２インターフェース１−１１のような装置を
含んでいてもよい。例えば、ファンクションモジュール
９−４１ａから９−４１ｆも５スロットＮＣＵ９−１の
中で使用される。図９が示すように、５つのスロット中
の各装置は自身の電源（例えば９−４３からａ９−４３
ｆ）を持つ。電源はすべて電源ターミナルボード（例え
ば、９−４５ａから９−４５ｄ）によって線間電圧また
は交流電源を受信する。個々の電源の存在理由は、１つ
の装置の偽の信号および雑音が第２装置の中へ電源ライ
ン経由で入り込むことを防ぐためである。１スロットＮ
ＣＵ９−３は単一のネットワーク制御モジュール９−４
７から形成される。ネットワーク制御モジュール９−４
７内で、サブモジュール９−４９はパーソナルコンピュ
ータ９−５１にインターフェースを提供し、ＲＳ−２３
２インターフェース９−３０はプリンタ９−５３に提供
される。ＮＣＵもＲＪ１１インターフェース９−３２を
持ってもよい。ネットワーク制御モジュール９−４７
は、ネットワークコントロールユニット９−３からＮ２
バス９−５５を通じて火災報知システム９−５７および
アクセス管理システム９−５９に通信する。火災報知シ
ステム９−５７はビルディング内の危険な煙および火災
状況を検知するために使用される。また、アクセス管理
システム９−５９はセキュリティサービスを提供するた
めに使用される。そのようなシステムは当業者に周知さ
れており、発明に従ったファシリティマネジメントシス
テムの能力を例示するために示される。５スロットＮＣ
Ｕ９−１は、Ｎ２バス９−６１を通じて１スロット遠隔
ディスプレイ増設ユニット９−６３、２スロットネット
ワーク遠隔ディスプレイ増設ユニット９−６５、アプリ
ケーション特定コントローラ９−６７および照明コント
ローラ９−６９と通信する。１スロットネットワーク遠
隔ディスプレイ増設ユニット９−６３は、１スロットＮ
ＣＵ９−６３内の通信ターミナルボード９−７３を介し
てＮ２バス９−６１と通信する拡張モジュール９−７１
を持つ。拡張モジュール９−７１は自身の電源９−７５
を持つ。５スロットＮＣＵ９−１内の拡張モジュール９
−１９および９−３７に対する場合のように、拡張モジ
ュール９−７１は、以前に記述された５つの構成のうち
のいずれであってもよい。以前に注意したように、拡張
モジュールがバイナリ、アナログ、およびパルス入力を
決定し、ネットワークコントローラに変更を報告し、バ
イナリ出力コマンドを実行する。そしてこの出力コマン
ドは、ネットワークコントローラから、２つの安定状態
の１つに対して接続されている操作可能ユニットを命じ
る。２スロットネットワーク遠隔ディスプレイ増設ユニ
ット（ＮＥＵ）９−６５は、拡張モジュール９−７７お
よびディジタル制御モジュール９−７９を持ち、９−７
７、９−７９にはそれぞれ１つずつ自身の電源９−８１
および９−８３がついている。ファンクションモジュー
ル（例えば、９−８５ａから９−８５ｃ）はディジタル
制御モジュール９−７９とインターフェースをとる。拡
張モジュール９−７７およびディジタル制御モジュール
９−７９の両方は、２スロットネットワーク遠隔ディス
プレイ増設ユニット９−６５への通信ターミナルボード
９−８７内でＮ２バス９−６１に接続される。これは、
図９に示されているサンプルＦＭＳ構成の残りと通信す
るためのＮ２バス９−６１にアクセスする。専用照明コ
ントローラ９−６９は、さらにコマンドを受信し、５ス
ロットネットワークコントロールユニット９−１に照明
ステータス情報を提供するために、Ｎ２バス９−６１に
取り付けられる。発明に従って、既知のアプリケーショ
ン特定コントローラ（例えば、９−６７）をＮ２バス９
−６１に付けることができる。そのようなアプリケーシ
ョン特定コントローラは、Ｎ２バス９−６１を通じて通
信する時、専用タスクを実行する。様々なネットワーク
遠隔ディスプレイ増設ユニットおよび特定コントローラ
アプリケーションに接続する全体的ソフトウェア構造が
以下に議論される。図１０はこのシステムに対するオペ
レーションでの照明コントローラ９−６９の拡大図であ
る。図１０は、Ｎ１バス１０−９上のオペレータワーク
ステーション１０−７と通信するネットワークコントロ
ールユニット１０−５に接続される、Ｎ２ＯＰＴＯＭＵ
Ｘバス１０−３上の照明コントローラ１０−１を示す。
ＮＥＵ１０−１５もＮ２バスに接続されて示されてい
る。照明装置は３２個の指定変更スイッチ入力１０−１
１と４０個のリレー出力を持っている。４０個のラッチ
ング４０リレーが可能である。あるいは、低圧ケーブル
接続を介して２０のリモートリレー１０−１３も可能で
ある。図１１はさらに、図９に記述されたようなアクセ
スコントロールシステム９−５９を例示する。ここで、
カードアクセス・コントローラ１１−１はＮ２バス１１
−５（たとえばＯＰＴＯＭＵＸバス）を介してネットワ
ークコントロールユニット１１−３と通信する。セキュ
リティを提供するために、カードアクセス・コントロー
ラ１１−１はスマートターミナルのインターフェース１
１−６に、Ｗｅｉｇａｎｄ効果、バリウムフェライトの
ようなリーダ１１−７あるいは磁気ストリップリーダお
よび８つのアラーム入力と接続する。カードアクセス・
コントローラも８つの近辺リーダ１１−１１を提供し、
ＣＲＴディスプレイ１１−１３およびプリンタ１１−１
５に対してＲＳ−２３２インターフェースを通じて通信
する。典型的に述べれば、１つのアクセス・コントロー
ラは各ネットワークコントロールユニットとして使用さ
れるであろう。Ｎ２バスは、さらにＮＥＵ１１−１７の
ような他のユニットを提供してもよいのに対して、Ｎ１
バス１１−２１がワークステーション１１−１９のよう
な他のユニットに接続されていてもよい。図１２はファ
シリティマネジメントシステムで作動する９−５７のよ
うな火災報知システムを示す。ネットワークコントロー
ルユニット１２−１は、オペレータワークステーション
１２−３およびＮ１バス１２−５を通じて他のネットワ
ークコントロールユニットと通信する。Ｎ２バス１２−
７は、火災検知／信号発生ループ１２−１１からの入力
を受信するインテリジェントファイアコントローラ１２
−９に接続されている。すばやい検出器（例えば１２−
１３ａから１２−１３ｃ）が煙、熱状態およびプルステ
ーションで起動される警報を検出する。さらに、信号装
置を起動するコントロールモジュール１２−１５が火検
出信号ループ１２−１１に接続されている。モニタモジ
ュール１２−１７は、プルステーション１２−１９、熱
検出器１２−２１およびウォーターフローアラームスイ
ッチ１２−２３の状態をモニタする。インテリジェント
ファイアコントローラ１２−９は、さらにＲＳ−４８５
バス１２−２５を通じてアナンシエータ１２−２７に接
続される。同様に、インテリジェントファイアコントロ
ーラ１２−９はＣＲＴディスプレイ１２−２９およびプ
リンタ１２−３１に対してＲＳ−２３２インターフェー
スを通じて通信する。さらにＮ２バス１２−７は、それ
自体スイッチパネル１２−３５が接続されているバイナ
リ入力拡張モジュール１２−３３に接続することもでき
る。バイナリ拡張モジュール１２−３３およびスイッチ
パネル１２−３５は、ネットワークコントロールユニッ
ト１２−１およびＮ２バス１２−７を通じてインテリジ
ェントファイアコントローラ１２−９に情報を送信する
スモークロントロールステーションを形成するために、
協同して作動することができる。図１３−１６は、異な
るサイズのビルディングにおける、この発明に従った様
々な構成の使用を例示する。図１３は、小さなビルディ
ング用に構成されるファシリティマネジメントシステム
を示す。これはネットワークコントロールユニットが、
暖房、換気、冷房および他の電子／機械的なビルディン
グシステムを、直接接続されている入出力ポイントで自
動的に制御し最適化するスタンドアロン構成のものであ
る。ネットワークターミナルのようなローカルＩ／Ｏデ
バイス１３−１を使用すると、オペレータは、調整機能
と指定変更能力を備え、ファンクションとスケジュール
を持つネットワークコントロールユニット１３−３をセ
ットアップすることができる。Ｎ２バス１３−５は、１
３−７で概略的に示される、被制御システムにネットア
ークコントロールユニットからの通信を提供する。その
ようなシステムには温度センサー１３−９、フローコン
トローラ１３−１１およびチラー１３−１３がついてい
てもよい。図１４は、いくつかのネットワークコントロ
ールユニット（例えば１４−１、１４−３）が冷暖房お
よび様々な他の電子／機械的なシステムを同時に管理す
る、中規模ビルディング用の典型的な構成を示す。ＮＣ
Ｕ１４−１および１４−３は、高速Ｎ１バス１４−５通
じて、またオペレータワークステーション１４−７を使
って互いに交信することができる。ＮＣＵ１４−３は、
リモートネットワーク遠隔ディスプレイ増設ユニット１
４−９および１４−１１のインプリメントによって、容
量と範囲を拡張した。これは、ネットワークコントロー
ルユニット１４−３への個別の装置ための線間電圧を配
線する必要を除去する。ネットワークコントロールユニ
ット１４−１に対するローカル入出力はローカルＩ／Ｏ
デバイス１４−１３によって提供される。両方のネット
ワークコントロールユニット１４−１および１４−３
は、それらのそれぞれのコントローラ１４−１５、１４
−１７、１４−１９、１４−２１、１４−２３、および
Ｎ２バス１４−１５、１４−２７上のネットワーク遠隔
ディスプレイ増設ユニットと通信する。図１５は、大規
模ビルディング用に構成されたファシリティマネジメン
トシステムを示す。図１５において、複数のネットワー
クコントロールユニット１５−１、１５−３、１５−５
がＮ１バス１５−７を通じて相互に連結している。さら
に、１５−９と１５−１１のような複数のオペレータワ
ークステーションは、さらにＮ１バスに接続される。例
の目的のために、図１５は、そのＮ２バス１５−１３を
介して、プロクシミティリーダー３０および磁気ストリ
ップリーダ１５−３４に接続しているスマートターミナ
ルのインターフェース１５−３２でカードアクセス・コ
ントローラ１５−１５に接続しているネットワークコン
トロールユニット１５−３を示す。カードアクセス・コ
ントローラについては図１１に関連して議論された。図
１５はさらに、そのＮ２バス１５−１７を通じて、火災
検知／信号発生装置ループ１５−２８で火災報知コント
ローラ１５−１９に接続しているネットワークコントロ
ールユニット１５−５を示す。そのような火災報知コン
トローラは図１２に関連して議論された。ネットワーク
コントロールユニット１５−１は、様々なコントロール
システム（例えば１５−２３）へのそのＮ２バス１５−
２１および１５−２５を通じて接続される。さらに、ネ
ットワークコントロールユニット１５−１へのローカル
入出力はローカルＩ／Ｏターミナル１５−２７を介して
提供される。発明に従って、さらにファシリティマネジ
メントシステムはリモートビルディングために構成する
ことができる。図１６はそのようなシステムを示す。図
１６に示されるように、リモートリンクは、Ｎ１あるい
はＮ２バスのいずれかに存在することができる。オペレ
ータワークステーション１６−１は、Ｎ１バス１６−３
にネットワークコントロールユニット１６−５およびネ
ットワークコントロールユニット１６−７に直接接続さ
れている。しかしながら、ネットワークコントロールユ
ニット１６−９はリモートリンク１６−１１を介してＮ
１バス１６−３に接続される。ネットワークコントロー
ルユニット１６−７は、オペレータワークステーション
１６−１に直接接続されて、そのＮ２バス１６−１３に
コントローラ１６−１５および１６−１７を通じてさら
に接続される。同様に、ＮＣＵ１６−９は、そのＮ２バ
ス１６−１９にコントローラ１６−２１および１６−２
３を通じて直接接続される。ネットワークコントローラ
１６−９へのローカルＩ／ＯはローカルＩ／Ｏ２５ター
ミナル１６−２５によって提供される。対照的に、ネッ
トワークコントロールユニット１６−５は、Ｎ２バス１
６−２７にコントローラ１６−２９および１６−３１を
通じて直接接続されるが、リモートリンク１６−３５を
通じてコントローラ１６−３３に接続される。したがっ
て、発明に従って、リモートリンクは、Ｎ１バスを通じ
てｐｅｅｒ−ｔｏ−ｐｅｅｒ通信を遂行することができ
る。また、リモートリンクは、さらにＮ２バスを通じて
マスター／スレーブ通信を遂行することができる。図１
７に従って、プロセッサ１７−２を各々持つ複数のネッ
トワークコントローラ１７−１およびメモリ１７−４
は、高速バス１７−３によって、例えばネットワークさ
れたファシリティマネジメントシステム（ＦＭＳ）１７
−６を形成するために接続される。プロセッサ１７−２
がここに議論されるようなノードにソフトウェア層を接
続するために、集中化されるかもしれないし分散される
かもしれないことが注意すべき点である。各ネットワー
クコントローラ機能はマスターコントロールノードとし
て操作可能ユニット用にそれに付いており、ソフトウェ
アのいくつかの層を組込む。ソフトウェアレベルはソフ
トウェアレベルと操作可能ユニットの間の分離を増大さ
せるために組立てられる。最も高いソフトウェアレベル
は特徴レベル１７−５である。特徴レベル１７−５は、
ファシリティマネジメントシステムを操作する際に、ネ
ットワークコントローラによって実行される特定の機能
をインプリメントする。特定のファンクションの１つの
例は、ユーザ表示を作表することあるいはグラフ式に示
すある値であろう。特徴は、制御プログラムが作動する
データオブジェクトの制御プログラムおよびリストを含
んでいる。ハイレベルのソフトウェア特徴の任意の数
は、システムの要件およびマスターコントロールノード
の能力に依ってインプリメントすることができる。ファ
シリティマネジメントシステムで実行される特徴の他の
ある例は、傾向変動分析、トータリゼーション、および
ファシリティマネジメントシステム性能の測定値を提供
する、他の統計の特徴を含んでいるだろう。重要なファ
クターはハードウェアからの分離の増加レベルが、ソフ
トウェア特徴がファシリティマネジメントシステムハー
ドウェアの変更によって影響されないことを許すことで
ある。最も高いレベルでのソフトウェア特徴はソフトウ
ェアオブジェクトレベル１７−７と通信する。ソフトウ
ェアオブジェクトレベルは、特徴レベル１８−５で、特
徴１８−２１、１８−２３、１８−２５の１つによって
リクエストされるアクションを遂行する方法を決定する
中間レベルである。情報は、ソフトウェアオブジェクト
レベル１７−７と１８−７およびハードウェアのより低
いレベルでの特徴レベルの相違から独立した１７−５お
よび１８−９の間で渡される。同様に、ソフトウェアオ
ブジェクトレベルは、ハードウェアオブジェクトレベル
１７−９および１８−５と呼ばれるソフトウェアの別の
レベルとのインターフェースを構成する。センサーや他
のデータ取得およびコントロール装置のような、ネット
ワークコントローラに接続されている操作可能ユニット
の特色にもかかわらず、ハードウェアオブジェクトレベ
ルは、共通のインターフェースがソフトウェアオブジェ
クトとハードウェアオブジェクトレベル間で確立される
ことを許可する。ソフトウェアオブジェクトレベル１７
−７および１８−７における様々なエンティティに対す
る操作可能ユニット間の相違を覆うために、ハードウェ
アオブジェクトレベルを構成することによって、これは
遂行される。ローカル・バス通信インターフェース１７
−１１および１８−１１の要件に従って、ネットワーク
コントローラ１７−１はローカル・バス１７−１３を通
じてスレーブコントローラ（例えばタイプＡ１７−１
５、１７−１７およびタイプＢ１７−１９）と通信す
る。図１に示されるように、任意の番号のタイプのスレ
ーブコントローラでも可能である。スレーブコントロー
ラは操作可能ユニット（例えば、センサーＴ１、Ｔ２、
Ｔ３、Ｓ１、Ｓ２、Ｓ３）に接続される。そのようなセ
ンサーは現実の世界のデータ（たとえば戸外の空気温
度）の値を読むバイナリフィールドセンサーあるいはア
ナログセンサーである。図１８は図１７に記述される構
成のより詳細な実例を提供する。ソフトウェアオブジェ
クトレベルは複数のソフトウェアオブジェクトマネジャ
ー１８−２７、１８−３１、１８−３５を含んでいる。
ソフトウェアオブジェクトマネジャーは特別のタイプの
ソフトウェアオブジェクトに対するリクエストをすべて
処理するデータベースマネジャーである。オブジェクト
はネットワークコントローラに格納される名前付きデー
タ要素である。オブジェクトは、タイプで類別化されて
おり、オブジェクトの各々の実例は、オブジェクト名、
現在地、アラーム制限などのようなそれ自身のセットデ
ータを持つ。したがって、各ソフトウェアオブジェクト
マネジャーは対応するデータベース１８−２９、１８−
３３、１８−３６に関連している。ソフトウェアオブジ
ェクトマネジェーの１つの例はアナログインプットオブ
ジェクトマネジャー１８−２７である。これは、次例に
おける温度オブジェクトＴの例Ｔ１、Ｔ２、Ｔ３のよう
なアナログ入力オブジェクトのすべての例に対するデー
タベースマネジャーだろう。別のものはバイナリ入力オ
ブジェクトマネジャー１８−３１である。与えられたマ
ネジャーに対するデータベースのすべての要素は、同じ
タイプのオブジェクトである。次例において、ソフトウ
ェアオブジェクトはアナログ入力ポイントおよびバイナ
リ入力ポイントを含んでいる。各オブジェクトタイプに
はいくつかの実例（その各々に属性と呼ばれるデータ値
自身のセットがある）があってもよい。例えば、データ
ベース１８−２９に格納されたアナログ入力オブジェク
トは各々オブジェクトのタイプの実例である。これら３
つの例の各々には属性自身のセットがある。これらの属
性はオブジェクト名、現在地、アラーム制限などを含む
データである。ハードウェアオブジェクトレベルは、類
似の複数のハードウェアオブジェクトマネジャー１８−
３７、１８−４１、１８−４５を含んでいる。各ハード
ウェアオブジェクトマネジャーはスレーブハードウェア
装置１７−１５、１７−１７、１７−１９にネットワー
クコントローラを接続するローカル低速バス１７−１３
に接続した特別のタイプのハードウェア装置に対するリ
クエストをすべて処理するデータベースマネジャーであ
る。例えば、スレーブコントローラタイプＡハードウェ
アマネジャー１８−３７は、すべてのＡタイプ（以下に
示される例のＡ１、Ａ２）のスレーブコントローラオブ
ジェクトに対するデータベースマネジャーである。ソフ
トウェアオブジェクトマネジャーの場合と同じように、
各々のハードウェアオブジェクトマネジャーはそのタイ
プのオブジェクトをすべて含み、それに関連するデータ
ベース１８−３９、１８−４３、１８−４７を持ってい
る。例えば、タイプＡハードウェアオブジェクトに対す
るデータベース３９はＡ１データ１８−４９およびＡ２
データ１８−５１を含んでいる。各オブジェクトには、
その特定のオブジェクトに対するユニークな１セットの
属性がある。透過的オブジェクトは２つのレベルで達成
される。まず第１に、ソフトウェアオブジェクトは特徴
に対して透過的である。そして、第２に、ハードウェア
装置あるいは操作可能ユニットはソフトウェアオブジェ
クトに対して透過的である。これらの透過的オブジェク
トは、例によって最もよく例示される。第１の場合、特
徴へのソフトウェアオブジェクトの透過的オブジェクト
においては、特徴ｘを仮定すると、１８−２１は現在地
フィールドあるいはセンサーＴ２の属性を読む必要があ
る。これは、Ｔ２を制御しているソフトウェアオブジェ
クトマネジャーに対して特徴ｘからのリクエストを向け
ることによって遂行される。図１７に示されるように、
この場合、Ｔ２はタイプＡスレーブコントローラ１７−
１７によって制御される。アナログ入力オブジェクトマ
ネジャー１８−２７は、Ｔ２のデータ構造を識別し、特
徴（たとえば値属性）によって必要とされる属性を特徴
ｘに返すことに責任を持つ。その結果、特徴ｘは、単一
の値として返すことができる様々な可能なタイプのデー
タを理解する必要があるのみで、アナログ入力オブジェ
クトに対する全体のデータベース構造を知る必要がな
い。オブジェクトに現在地を要求する場合、特徴ｘは、
特定のオブジェクトタイプについて心配する必要がな
い。情報がすべて、特徴レベル１７−５と１８−５およ
びソフトウェアオブジェクトレベル１７−７と１８−７
の間で、同じ方法で転送されるので、特徴は、オブジェ
クトの現在地を求める必要があるだけである。したがっ
て、アナログ入力オブジェクトに現在地およびバイナリ
入力オブジェクトのような異なる型オブジェクト値を要
求する方法は変らない。特徴ｘは、適切なオブジェクト
マネジャーに現在地属性に対するリクエストを送信する
だけである。特徴はどのソフトウェアオブジェクトマネ
ジャーがデータを制御するか決めるだけのためにオブジ
ェクトタイプを使用する。値に対して特徴によって出さ
れる実際のリクエストは、どのタイプのオブジェクトが
尋ねられていても、同一である。これは各々異なるオブ
ジェクトタイプに対して現在地を異なって要求すること
をハイレベルのソフトウェア特徴に要求することを回避
する。このアプローチの付加的利点は、ハードウェアが
システムのどこで設置されているかにかかわらず、同じ
方法で、特徴が常に情報を得ることができることであ
る。特徴がネームによってオブジェクトを要求するだけ
なので、特徴は、指定されたオブジェクトを生産するハ
ードウェアのシステム内の物理的な位置に対して鈍感で
ある。したがって、ハードウェアの相違およびハードウ
ェアの物理的な位置はハードウェアおよびソフトウェア
オブジェクトマネジャーによって覆われる。ソフトウェ
アオブジェクトデータ・ベース管理プログラムおよびハ
ードウェアオブジェクトデータベースマネジャーは図１
７と１８で以前に記述され示されたように情報を転送す
る。これは例示目的だけのためであること、および、転
送情報の任意の構成は、ソフトウェアオブジェクトデー
タベースマネジャーおよびハードウェアオブジェクトデ
ータベースマネジャーによって提供されるデータによっ
て実行される機能に左右されて、可能であることに注意
すべきである。したがって、特徴は、実際のセンサーあ
るいはデータ取得あるいはコントロール装置が付けられ
るスレーブコントローラハードウェア装置のタイプに関
係がない。特徴がオブジェクトの属性に値を要求する場
合、それは、生データを生成するセンサーを管理するた
めに使用される、スレーブコントローラのタイプに鈍感
である。ソフトウェアおよびハードウェアオブジェクト
レベルは特徴を分離し、操作可能ユニットが付けられて
いる物理的なスレーブコントローラにもかかわらず与え
られたオブジェクトタイプ対するすべての特徴に同じデ
ータ値セットを同じ方法で贈る。したがって、特徴を各
タイプのスレーブコントローラ用に変更する必要がな
い。このことは、第２透過レベル、すなわちソフトウェ
アオブジェクトに対するハードウェア装置の透過性に通
じる。ソフトウェアオブジェクトマネジャーとスレーブ
コントローラ間にハードウェアオブジェクトマネジャー
を間に置くことによって、ソフトウェアマネジャーとの
ハードウェア相違を覆うことが可能である。これは、よ
り高いレベルのコントロールおよび前定義された条件の
報告を実行するための、ノード中のソフトウェアオブジ
ェクトマネジャーの処理能力を解放する。例えば、ソフ
トウェアオブジェクトマネジャーはアラームを報告し、
データを生成するために使用されるハードウェアから独
立のトリガメカニズムの役をするように変更をハイレベ
ルの特徴に通知する。 特徴ｘ−１８−２１がアナログ
タイプ温度ポイントＴ１、Ｔ２およびＴ３の値を読む場
合、図１８に基いて１つの例が発生する。以前に議論し
たように、特徴はハードウェアに関係がなく、したがっ
て、アナログ入力オブジェクトマネジャー１８−２７に
対して各温度にポイントを求める同じリクエストをす
る。これはリクエストされるオブジェクトがアナログタ
イプであるからである。アナログ入力オブジェクトマネ
ジャー１８−２７自身もまた、Ｔ１、Ｔ２およびＴ３が
設置されているスレーブに関係がない。特徴ｘおよびア
ナログ入力オブジェクトマネジャー１８−２７に関する
かぎり、様々なハードウェアマネジャーへの通信はすべ
てＴ１、Ｔ２およびＴ３に対して同一である。アナログ
入力オブジェクトマネジャー１８−２７は、ハードウェ
アオブジェクトレベル１７−９から７２．３°Ｆのよう
な明瞭な浮動小数点数（実数）を要求する。ストレート
タイプＡおよびＢも対応するハードウェアオブジェクト
マネジャー１８−３７および１８−４１はリクエストさ
れるタイプの値をアナログ入力オブジェクトマネジャー
１８−２７に供給するようにデータを決定する。値を決
定するために、ハードウェアオブジェクトマネジャーの
個々の計算の何らかの数がリクエストされるかもしれな
い。例えば、温度センサーの値が、アナログ／デジタル
変換器によって産み出されるディジタルカウントのよう
なカウント（このカウントは浮動小数点値を計算するた
めにあらかじめ定められた範囲に渡って展開されねばな
らない）としてスレーブコントローラに到着すると仮定
しなさい。センサーの最終温度値が得られる前に、一層
の修正が、スパン方程式、平方根方程式およびフィルタ
ーによってリクエストされるかもしれない。図１７に示
されるように、タイプＡスレーブコントローラ１７−１
５および１７−１７は、Ｔ１およびＴ２生データを受け
渡す。タイプＢスレーブコントローラはＴ３生データを
受け渡す。コントローラＡおよびＢが完全に異なるレベ
ルの能力を持つと仮定すると、コントローラの相違は既
存のコンピュータ化されたファシリティマネジメント管
理システムにおいて、重大な問題を引き起こすであろ
う。例えば、他方がインプリメントしていないかもしれ
ないのに対して、一方のコントローラは平方根方程式を
インプリメントするかもしれない。あるいは、コントロ
ーラ同士が異なる範囲方程式を持つかもしれない。従来
のファシリティマネジメントシステムにおいては、ハイ
レベルのソフトウェアはこれらの相違を補正する必要が
あるだろう。しかしながら、本発明においては、スレー
ブコントローラに対するハードウェアオブジェクトマネ
ジャーは、データを決定してアナログ入力オブジェクト
マネジャー１８−２７とこれらの相違を覆うために、ノ
ードプロセッサ（あるいは個別のプロセッサ）にアクセ
スする。タイプＡスレーブコントローラ１７−１５およ
び１７−１７は、ネットワークコントローラにアナログ
ディジタルカウントだけを提供する、高度に単純な装置
であると仮定しなさい。この場合、タイプＡスレーブコ
ントローラに対するハードウェアオブジェクトマネジャ
ー１８−３７は、アナログ入力オブジェクトマネジャー
１８−２７に提供するための最終温度値Ｔ１およびＴ２
を得るのに必要な別の計算を実行しなければならない。
対照的に、スレーブコントローラタイプＢが、ネットワ
ークコントローラ上へ情報を送る以前に、ほとんどのレ
インジング及びフィルタリングを実行する高度に精巧な
装置であると仮定しなさい。この場合、タイプＢコント
ローラに対するオブジェクトマネジャー１８−４１は比
較的に小さな処理を実行する。いずれの場合にも、ハー
ドウェアオブジェクトマネジャーによって実行される処
理は、データを操作し、ハイレベルの特徴にそれを送る
ソフトウェアオブジェクトマネジャー１８−２７に対し
て透過的である。これは、ハードウェアオブジェクトマ
ネジャー１８−３７と１８−４１ならびにアナログ入力
オブジェクトマネジャー１８−２７間に共通の情報イン
タフェースがあるからである。したがって、ハードウェ
アオブジェクトマネジャーはすべて、同じ規則に従った
ソフトウェアオブジェクトレベル−１７−７と通信す
る。したがって、アナログ入力オブジェクトマネジャー
１８−２７を総称オブジェクトタイプ（この場合、アナ
ログ入力オブジェクト）を処理するため書くことができ
る。それは、アナログ入力の各単一の可能なスレーブコ
ントローラ実行用代替コードを含んでいる必要がない。
さらに、図１８に示されるように、通信が、ソフトウェ
アオブジェクトレベル１８−７のすべての特徴とすべて
のオブジェクトマネジャー、およびソフトウェアオブジ
ェクトレベル１８−７およびハードウェアオブジェクト
レベル１８−９のすべてのオブジェクトマネジャー間で
可能であることに注意すべきである。使用される実際の
通信パスはリクエストされる特徴およびデータによって
実行されるファンクションだけからなるファンクション
である。したがって、特徴ｙもソフトウェアオブジェク
トＴ１をリクエストしてもよく、したがって、アナログ
入力オブジェクトマネジャー１８−２７にアクセスす
る。同様に、特徴ｎは、ハードウェアオブジェクトレベ
ル１８−９の１つ以上のオブジェクトマネジャーからデ
ータをさらに要求することもできる、ソフトウェアオブ
ジェクトレベル１８−７の１つ以上のオブジェクトマネ
ジャーからデータをリクエストしてもよい。ハードウェ
アオブジェクトとソフトウェアオブジェクトレベル間の
インタフェースの共有性は、新スレーブコントローラお
よびオブジェクト例の追加を単純化する。もし第４温度
センサーＴ４がシステムに加えられれば、オブジェクト
例は上記の例に加えられるだろう。第３タイプＡスレー
ブコントローラＡ３が加えられれば、同じタイプの新ス
レーブコントローラが加えられるだろう。いずれの場合
にも、ソフトウェアオブジェクトレベル１８−７とハー
ドウェアオブジェクトレベル１８−９間に情報のインタ
フェースにたいする変更がないので、必要なソフトウェ
アはすべてネットワークコントローラに存在する。ユー
ザはただ、１８−２９のアナロク入力オブジェクトＴ４
の新しい例を生成するためにデータベースを修正変更す
る必要があるだけである。あるいは、タイプＡコントロ
ーラオブジェクト（たとえば、Ａ３）の新しい例をネッ
トワークコントローラに生成するために、データベース
１８−３９を修正変更する必要があるだけである。既存
のファシリティマネジメントシステムソフトウェアに最
少のインパクトをそなえた新しいスレーブコントローラ
タイプを加えることも可能である。新しいコントローラ
タイプ、タイプＣがローカル・バス１７−１３に付けら
れると仮定しなさい。そのローカル・バスで操作可能な
ユニットに対するマスターコントロールノードの役をす
るネットワークコントローラにおいて、既存のソフトウ
ェアに新しいハードウェアオブジェクトマネジャーを加
えることで（ダウンロードあるいは他の手段によって）
をこのことは要求するだろう。このハードウェアオブジ
ェクトマネジヤーは、システムの中ですでに定義されて
いるソフトウェアオブジェクトに新コントローラの能力
をマップするだろう。例えば、新ハードウェアコントロ
ーラは新しいハードウェアオブジェクトマネジャーをリ
クエストして、略式な方法でアナログ温度データをモニ
タしてもよい。新コントローラがアナログ温度データを
産み出せば、新しいハードウェアブジェクトマネジャー
は、アナログ入力オブジェクトの新しい例Ｔ５にデータ
をマップすることができる。既存のソフトウェアオブジ
ェクトマネジャーおよびソフトウェアオブジェクトレベ
ル１７−７、およびネットワーク制御ソフトウェアの特
徴レベル１７−５のハイレベル特徴は、影響されないだ
ろう。なぜならそれらは従来と同じ様に作動するであろ
うから。唯一の例外は、既存のタイプのオブジェクトと
はオペレーションにおいて非常に異なるために、ソフト
ウェアオブジェクトレベル１７−７で既存のソフトウェ
アオブジェクトマネジャーの１つにマップすることがで
きなかった新しいデータタイプを、新しいハードウェア
がいつサポートするかであろう。その場合、新しいソフ
トウェアオブジェクトも作成されなければならないかも
しれない。したがって、ハードウェアオブジェクトマネ
ジャーは、ソフトウェアオブジェクトに対するハードウ
ェアの相違を覆うために、再び使用される。したがっ
て、ソフトウェアオブジェクトマネジャーは異なるハー
ドウェアに左右されるバージョンを持つ必要がない。ソ
フトウェアオブジェクトマネジャーは、データ要素がタ
イプＡコントロールのもとで操作されたセンサーから由
来するものであれ、タイプＢコントロールの下で操作さ
れた別のセンサーから由来するものであれ、データ要素
を同じ方法で処理する。ハードウェアオブジェクトマネ
ジャーは、ソフトウェアオブジェクトマネジャーの必要
によってリクエストされる形にデータをフォーマットす
るかマップする。これは、ソフトウェアオブジェクトマ
ネジャーがより高いレベルのソフトウェア特徴にハード
ウェアから独立したてインタフェースを提供することを
可能にする。この発明の別アスペクトに従って、図１９
は、ソフトウェアあるいはハードウェアマネジャーが、
センサーのような操作可能ユニットから直接得られたデ
ータが処理されるのとほとんど同じ方法で計算中に生成
されるデータを処理するための一つの構成体を提供する
ことを例示する。発明に従って、１つのポイントがオブ
ジェクトのタイプとして定義される。例えば、アナログ
入力ポイントはオブジェクトのタイプである。したがっ
て、ポイントにはその現在地、上限、下限、アラーム状
態、そのハードウェアアドレスなどのような属性があ
る。ポイントに対するこれらの複数次元はポイントをベ
クトル量として定義する。１ポイントは、フィールドの
センサーのような操作可能ユニットに常に関係してい
る。したがって、操作可能ユニット１９−１は、ソフト
ウェアオブジェクトマネジャー１９−７によってリクエ
ストされる形にハードウェアオブジェクトマネジャー１
９−５のデータを処理するネットワークコントローラ１
９−３にデータを提供する。ポイントに対応するデータ
は、プロセッサメモリ１７−４のような記憶手段に属性
１９−９として格納される。特徴レベル１９−１１での
中間計算は、ソフトウェアオブジェクトレベル１９−１
３が操作可能ユニットから直接集められないデータを供
給することを時として要求することができる。そのよう
なデータを処理する共通の方法を容易にするために、擬
ポイント１９−１５がソフトウェアオブジェクトレベル
１９−１３で作成される。擬ポイントは、ソフトウェア
オブジェクトマネジャー１９−７によってポイント１９
−９とまったく同じ方法で処理される。１ポイントと擬
ポイントの間の相違は擬ポイントが関連するオブジェク
トからその属性の１つ以上を得ているのに対して、１ポ
イントが操作可能ユニットからその値を得ることであ
る。擬ポイントは、その属性の１つとして関連するオブ
ジェクトの身元を格納する。したがって、擬ポイント１
９−１５は、ポイント１９−９としてその関連するオブ
ジェクトを認識することができよう。この場合、擬ポイ
ント１９−１５は、ポイント１９−９の属性からその属
性の１つ以上を得ることができよう。これは同じ方法で
特徴レベル１９−１１からのデータリクエストをすべて
処理することを、ソフトウェアオブジェクトマネジャー
１９−７に許可する。したがって、ポイントとして操作
可能ユニットから得られたデータ、および、そのような
操作可能ユニットから直接得られない、中間計算の中で
使用される他のデータを区別する必要がない。図２０
は、高速ネットワークバス２０−７で相互に連結したネ
ットワークコントローラ２０−１、２０−３、２０−５
を示す。高速ネットワークバス２０−７は、ノード間の
データをコンピュータ２０−９に伝送するために使用さ
れる。コンピュータ２０−９は、ネットワークコントロ
ーラ２０−１に対するアーカイブデータベース２０−１
３、およびネットワークコントローラ２０−３に対する
アーカイブデータベース２０−１５のようなアーカイブ
されたデータベースを含んでいる記憶要素２０−１１へ
情報を伝送する。コンピュータ２０−９は、データのレ
ベルが特定のアプリケーションに対して適切なものはど
んなレベルであれ、ユーザがデータ要素を生成すること
を可能にし、データ要素にネームを割当てることを可能
にする生成ソフトウェア２０−１０を含んでいる。２つ
の要素に同じネームがあってはならないので、生成ソフ
トウェアはアーカイブされたデータベースあるいはオン
ラインデータベースをチェックし、各データ要素が自身
に特有のネームを割当てられていることを確認する。ネ
ームが割当てられた場合、ネームおよびデータ要素は両
方とも高速バス２０−７を使用して、上位ノードにダウ
ンロードされる。これは、レファレンス番号２１−２０
および２１−２２として生成時刻で図２１に概略的に示
される。その結果、上位ノードは名前付きデータ要素を
含んでいる。図２１のファンクションブロック２１−２
４にさらに示されるように、ランタイム中、レファレン
スノードは、ネームによってデータ要素に対するリクエ
ストを送信する。これが指定されるデータ要素に対する
第１リクエストである場合、ファンクションブロック２
１−２６に示されるように、データ要素が見つけられる
まで、ネットワーク全体が探索される。これは、ファン
クションブロック２１−２８に概略的に示される。ネー
ムをネットワークのいかなる場所にも見つけることがで
きない場合、ファンクションブロック２１−３０に示さ
れるように、エラーメッセージ２１−３２が送信され
る。また、ネームの探索はブロック２１−３８で終了さ
れる。一方、ファンクションブロック２１−３４に示さ
れるように、ネームが見つけられた場合、ネームはバイ
ンド情報でタグを付けられる。このバインディング情報
ネットワーク上のノードアドレス、およびノードのデー
タベース内のデータ要素の内部アドレスである。ノード
アドレスおよびデータ要素の内部アドレスには任意の便
利なフォーマットがありうる。ファンクションブロック
２１−３６に従って、バインド情報およびデータ要素そ
れ自身は、バインド情報を格納するレファレンスノード
に返される。レファレンスノードがデータ要素に対する
第１リクエストを行っていない場合、ブロック２１−２
６に示されるように、バインド情報が読まれるコントロ
ールはファンクションブロック２１−４０にパスする。
バインド情報を使用して、ブロック２１−４２で、指定
位置（上位ノードおよびデータ要素位置）でのネーム
は、リクエストされたネームを持つブロック２１−４４
の中で読まれ比較される。指定位置で見つかったネーム
が、リクエストされたネームと一致した場合、データ
は、ステップ２１−４６に従ってリクエストノードに返
される。そして、データ取得ルーチンが終了される。し
かしながら、指定された位置で見つけられたネームがリ
クエストされたネームと一致しないこともありうる。こ
れは、バインド情報が無効になったことを示す。典型的
に、検証は上位ノードで行われる。ホストは、リクエス
トされたデータが、境界アドレスに格納された要素のネ
ームと渡されたネームを比較することによって同じアド
レスにまだあることを確認する。それらが同一である場
合、以前に注意したように、バインディングはまだ有効
である。また、リクエストされるように、データは返さ
れる。しかしながら、上位ノードのデータベース内に、
あるいは別のノードのいずれかに、データ要素が移動し
た場合、上位ノードは、そのデータベースでその位置に
今格納されるネームとリクエストで渡されたネームとの
間の不一致を検知する。レファレンスノードは、バイン
ド情報が無効であると通知される。ダウンロード、削除
あるいは他のデータベース生成が上位ノードを通じて実
行された場合、データ要素の削除、ノード内データのデ
ータベースの別の位置への移動、あるいは異なるノード
へのデータの移動によってバインド情報が無効になるこ
とはあり得る。これらの事象のうちのいかなるものでも
レファレンスノードが通知されないで起ることがある。
バインド情報が無効の場合、レファレンスノードは、デ
ータ要素名の第１リクエスストに対する前述のステップ
に再び従って、ステップ２１−２８に従う要素名を求め
てネットワークの探索を実行する。データ要素名が削除
された場合、エラーメッセージ２１−３２が返されるだ
ろう。しかしながら、ステップ２１−３４および２１−
３６に従って、データ要素名が、ノード内であるいは異
なるノードへ移動させられた場合、ネームは新しいバイ
ンド情報のついてタグを付けられるだろう。新しいバイ
ンド情報およびデータ要素はレファレンスノードに返さ
れるだろう。上記の結果、ネットワークは自己回復作用
を行う。アドレスの変更が生じた後、はじめてレファレ
ンスが行われたとき、無効になるレファレンスが修正さ
れる。さらに、それが参照するデータ要素がダウンロー
ドされる前に、レファレンスノードがダウンロードされ
る場合、ネームがダウンロードされ、次に、それを見つ
けることができるまで、エラーメッセージは返される。
したがって、上記の発明に従えば、はじめてデータ要素
がリクエストされたときか、あるいは、データ要素が移
動させられた後はじめてそれがリクエストされたときネ
ットワーク探索を行うだけでよい。図２２は、上記に記
述された方法のバリエーションを例示する。ネーム生成
２２−５０後、ネームは、レファレンスノードへステッ
プ２２−５２でダウンロードされることを、図２２−３
は例示する。ステップ２２−５４で、レファレンスノー
ドはネームテーブルを生成する。レファレンステーブル
は、データ要素のコピーを１つだけ保持することによっ
て、ノード内メモリの使用を最適化するように構築する
ことができる。その後、データ要素を要求するレファレ
ンスノードで、すべてのレファレンスおよびアプリケー
ションは、ＡＳＣＩＩ名より少ないデータ・バイトしか
典型的にリクエストしないレファレンステーブル指標と
取替えられる。したがって、図２２のステップ２２−５
４および２２−５６で示されるように、ネームは１つの
場所、レファレンステーブルエントリだけで保持され
る。この方法で各々のレファレンスノードが自身のネー
ムテーブルを保持することに注意すべきである。したが
って、ステップ２２−５８の後レファレンスノードがデ
ータ要素を要求する場合、ステップ２２−６０はこれが
レファレンスノードによる最初のリクエストがどうか決
めるように実行される。それがレファレンスノードによ
る最初のリクエストである場合、図２２のステップ２２
−６２から２２−７２が実行される。これはネームがバ
インド情報およびデータを返して発見された場合に要素
名を求めてネットワークを探索すること、および、ステ
ップ２２−７２で示されるようなレファレンスノードに
作成されるテーブルにそのネームを置くことを含んでい
る。以前に議論したように、エラーは処理されるだろ
う。ステップ２２−７４で、これがレファレンスノード
による最初のリクエストでない場合、データ要素の位置
は、ホストに送られたネームテーブルおよびリクエスト
から読まれる。その後、ネームはネームテーブルで指定
される位置に上位ノードによってネームと比較される。
ステップ２２−７８での比較の結果に基いて、データは
要求するノードに返されるだろう。あるいは、ネットワ
ークは要素名を求めて探索されるだろう。レファレンス
ノード内で、それが、データ要素を求めるリクエストが
起こす、いかなるアプリケーションあるいは特徴におい
て重要ではないことに注意することは重要である。一度
バインディングがその要素への１つのレファレンスに対
して生じれば、それは、その要素へのそのノード内のす
べてのレファレンスに対して発生する。これは、各々の
場所に対して一度ずつレファレンスがノードで発生する
代わりに、バインディングがノード内のすべてのレファ
レンスに対して一度だけ発生する必要があることを意味
する。これは、ノードによってすべてのレファレンスに
対応する初期バインディングを作るのに費やされる時間
を縮小する。個別のレファレンステーブルが各ノードに
対して構築されることも注意されるべきである。したが
って、データ要素の位置が上位ノードの範囲内であるい
は別の上位ノードに変更される場合、はじめて、そのノ
ードがデータ要素を要求するときに、レファレンステー
ブルを更新するプロセスが各レファレンスノードによっ
て繰り返されるだろう。図２３は図２２に示される配置
の一層の最適化を示す。ノードがデータ要素に対する第
１リクエストを行なったと仮定して、バインド情報によ
って識別される位置のネームが、現在リクエストされて
いるデータ要素のネームと比較される。この場合、一致
が生じなければ、ローカル探索は、バインド情報によっ
て識別されるホストの探索によって、ステップ２３−８
２でまず実行される。これはデータ要素が同じホスト内
に見つけられるからである。これが生じた場合、バイン
ド情報およびデータがレファレンスノードに返されるコ
ントロールはステップ２３−７０にパスする。しかしな
がら、これが生じなかった場合、ネットワークの残りは
ステップ２３−６２からスタートする探索が行なわれ
る。一層の実施例はデータ要素が、要求するノード（つ
まり、上位ノードおよびレファレンスノードは同じノー
ドである）と同じノードに格納される場合にデータ要素
へのレファレンスを求めてネットワークを探索すること
を回避する。前述したように、レファレンスネームテー
ブルは、レファレンスノードに各ネームに対するエント
リを含んでいなければならない。データがある場合には
このノードから別のノードに移動することもあるので、
レファレンスノードおよび上位ノードが同一でも、これ
は必要である。したがって、たとえレファレンスノード
がさらに指定される要素に対して上位ノードでも、レフ
ァレンスノードのネームテーブルからエントリを削除す
ることはできない。しかしながら、これらの状況になっ
たときだけ、はじめてレファレンスノードがレファレン
スノードがさらに上位ノードであるデータ項目をリクエ
ストしたときに、ネットワークの探索を削除すること
は、可能である。これは、要素がダウンロードされる場
合に、データベースソフトウェアおよび上位ノードにレ
ファレンステーブルエントリを加えることによって、達
成される。上位ノードがデータ要素を所有し、従って、
バインディングを知っているので、テーブルエントリは
正確なバインド情報を含んでいる。同じノードの他のど
こかから第１レファレンスが生じた場合、バインド情報
は、レファレンステーブル内にすでにあり、追加探索は
リクエストされない。したがって、レファレンスノード
によって頻繁に使用されるデータ要素をそのレファレン
スノードにホストすることは有利である。図２４はネー
ムの複数のレベルを使用して、一層の最適化テクニック
を示す。例示されるように、ネームの２つのレベルが示
される。しかしながら、テクニックは、指定する階層の
任意の深さまで延長することができる。したがって、ネ
ームの、小さなレベルおよびハイフンでつながれたレベ
ルは使用することができる。各々のレベルで、ディレク
トリは次のより高いレベルまでアクセスを可能にして、
構成される。２レベルの名前づけスキームにおいて、各
ネームは、２つの部分、すなわち、グループ内のグルー
プ名および要素名から成る。各グループは、ネットワー
クにおいて１つのノードに割当てられ、グループの範囲
内で多くの要素を持ってもよい。第１ディレクトリすな
わちグループディレクトリは、ネットワークのすべての
グループのディレクトリである。ディレクトリは、各グ
ループのネームをリストし、グループが駐在するノード
を定義する。ネットワークの各ノードにグループディレ
クトリを保持しなければならないので、グループディレ
クトリは、ネットワーク内のすべてのノードに同報通信
される。すべてのノードがグループディレクトリの最新
のコピーを保持するように、グループの付加あるいは削
除はネットワークのすべてのノードに同報通信されなけ
ればならない。ノードの各グループに対して、ノード
は、要素ディレクトリと呼ばれるディレクトリの第２レ
ベルを含んでいる。要素ディレクトリは、そのグループ
の要素をすべてリストし、グループの各要素のノードア
ドレスを識別する。グループの要素が、グループあるい
は要素ディレクトリを含んでいるノードに駐在する必要
がないこと、また、すべての要素およびそのグループが
ネットワークの同じノードにかならずしも駐在する必要
がないに注意することは重要である。もちろん、要素が
加えられたりかグループから削除されたり、１つのノー
ドから別のノードに移動した場合は常に要素ディレクト
リは更新される。図２４は、ディレクトリがどのように
使用されるか例示する。ステップ２４−１００で示され
るように、レファレンスノードがデータ要素にたいして
その第１リクエストを行なっているかどうかが最初に決
定される。ステップ２４−１０２において、これが第１
リクエストである場合、レファレンスノードはグループ
ディレクトリとグループ名を比較し、グループノードを
識別する。ステップ２４−１０４において、一致が生じ
ていない場合は、エラー２４−１０６が示される。そし
て、事象のシーケンスが終了する。ステップ２４−１０
４での適切なオペレーションを仮定した場合、一致が生
じ、ステップ２４−１０８でリクエストはグループディ
レクトリで身元確認されたグループノードに送られる。
グループノードのステップ２４−１１０において、要素
ディレクトリは要素がそのグループに現れるかどうかを
決めるために、探索される。要素ディレクトリがデータ
要素の位置を含んでいるので、一致がステップ２４−１
１４で生じた場合、ステップ２４−１１２でグループノ
ードは要素ディレクトリから上位ノードアドレスを読
み、ステップ２４−１１６で上位ノードへのリクエスト
を転送する。ステップ２４−１１８で、上位ノードはデ
ータを得て、レファレンスノードにバインド情報および
データを返す。したがって、要素のネームの初期探索
は、正しいグループに対する要素ディレクトリの探索が
後続するグループディレクトリの単作に探索される。ネ
ットワーク全体を探索する必要がない。しかしながら、
ディレクトリは最新にしておかなければならないし、グ
ループディレクトリのコピーをネットワークの各ノード
に保持しなければならないことに注意すべきである。グ
ループディレクトリが駐在するノード上にだけ、グルー
プの要素ディレクトリを保持する必要がある。グループ
あるいは要素が加えられたりか削除されたり、要素が移
動させられたりした場合のみ、追加簿記が要求されるだ
けである。これは、そのような変更が生じた場合、レフ
ァレンスノードをすべてダウンロードすることに比べれ
ば相当に少ない仕事量である。レファレンスノードのソ
フトウェアの実際のレファレンスが影響を受ける必要が
ない。以前に議論したように、これがデータに対する第
１リクエストでない場合、バインド情報が読まれ、その
ネームはバインド情報によって識別された位置に見つけ
られたネームと比較される。一致が生じない場合、バイ
ンド情報はもはや最新でなく、適切な情報を位置指定す
るにシーケンスを再び実行しなければならない。１つの
アプリケーションにおいて、ファシリティマネジメント
システムで上述の方法を遂行することができる。ファシ
リティマネジメントシステムに対するこのアプリケーシ
ョンは例を介したものであり、この発明に対して制限を
くわえることを意図したものではない。図２０で、数個
の実時間ネットワークコントローラおよびネットワーク
コントローラ・ダウンロードするためのデータベースを
生成するために使用されるパーソナルコンピュータは、
ネットワーク２０−７に相互に連結している。パーソナ
ルコンピュータ２０−９に付けられたディスクのような
記憶手段２０−１１は、ネットワークコントローラ２０
−１、２０−３および２０−５にダウンロードされるデ
ータベースを含んでいる。各ネットワークコントローラ
およびパーソナルコンピュータはノードと考えることが
できる。ＮＣ２を上位ノード３のネームであり、上位ノ
ードがＡＨＵ１／ＦＡＮと呼ばれるデータオブジェクト
あるいは要素を所有すると仮定しなさい。システム／オ
ブジェクト名はシステム名が上記の説明においてグルー
プ名と同一であり、オブジェクト名が特別のデータオブ
ジェクトあるいは要素のネームである場合にスキームを
指定する２レベルである。このオブジェクトは空気ハン
ドラ＃１に対するリターンファンである。２つの位置の
１つに対してそれを制御することができ、そのネームが
ネットワーク上でユニークなので、これはバイナリ出力
オブジェクトである。“グループ”あるいはシステム名
はＡＨＵ１および“要素”である。あるいは、オブジェ
クトはファンである。さらにそのＮＣ１がノード１のネ
ームであり、レファレンスノードであると仮定しなさ
い。これは、それがＦＡＮオブジェクトを参照する必要
のあるいくつかのソフトウェア特徴を持つことを意味す
る。図２０に示されるように、特徴ＡはＦＡＮオブジェ
クトの現在地を読む必要があり、特徴Ｂはファンを物理
的に開始させるためにＦＡＮオブジェクトにコマンドを
送る。図に示されるように、すべてのシステム名、グル
ープディレクトリ２０−２００、２０−２０２および２
０−２０４のリストは、各ノードに複写される。グルー
プディレクトリは、どのノードが特別のシステムのため
のオブジェクトのディレクトリ含んでいるかを識別す
る。ＡＨＵ１システムの場合、オブジェクトのディレク
トリはＮＣ２ノード２０−３によって保持される。した
がって、ＮＣ２、ノード２０−３もＡＨＵ１システムの
オブジェクトのディレクトリ、および、それらがデータ
ベースに位置指定されている場所とを含んでいる。同様
に、ＡＨＵ２システムに対するオブジェクトはＮＣ３あ
るいはノード２０−５に位置指定されている。以前に議
論したように、パーソナルコンピュータ２０−９を使用
して、ユーザは、記憶ディスク２０−１１上にアーカイ
ブされたファイル２０−１３、２０−１５に置くことが
でき、ネットワークコントローラ２０−１、２０−３お
よび２０−５にダウンロードすることができるデータベ
ースを生成する。特徴ＡおよびＢからオブジェクトＡＨ
Ｕ１／ＦＡＮへのレファレンスのようなレファレンス
は、ダウンロードされる時、ＡＳＣＩＩネーム形式で保
持される。これはそれらが、ネットワークコントローラ
に対応するデータベースがダウンロードされた時にまだ
バインドされていないからである。参照を付けるソフト
ウェア特徴は、データオブジェクトＡＨＵ１／ＦＡＮの
実際の物理的な位置に気がつかない。ダウンロードする
に際して、オブジェクトは、同じタイプのオブジェクト
をすべて管理するデータ・ベース管理プログラムに与え
られる。ＡＨＵ１／ＦＡＮの場合には、ＮＣ２のバイナ
リ出力マネジャーが使用される。オブジェクトデータ・
ベース管理プログラムソフトウェアは、レファレンスネ
ームテーブル中にネームを最初に入力する。例えば、バ
イナリ出力オブジエクマネジャーがダウンロード時にＦ
ＡＮオブシェクトを与えられる場合、それは自身のバイ
ナリ出力データベースにＦＡＮオブジェクトを入れて、
レファレンステーブル２０−３００にエントリを加え
る。このエントリは、ＡＨＵ１／ＦＡＮオブジェクトお
よびそのバインド情報のネーム、および、バイナリ出力
データベース（レコード３）における、オブジェクトタ
イプ（バイナリ出力）、上位ノードアドレス（ＮＣ２）
およびデータベース位置を含んでいる。この例におい
て、テーブルエントリは、図２０に示されるようにオフ
セット１６に位置指定されている。ＮＣ２以外の他のノ
ードがバインド情報をこの時知らないことに注意しなさ
い。これらのノードは、ＡＨＵ１／ＦＡＮに対するネー
ムレファレンスをまだ持っているだけである。後のネー
ム探索が適切な場所でそれを見つけるように、オブジェ
クトとＡＨＵ１のディレクトリは、さらに、ＦＡＮオブ
ジェクトに対するレファレンステーブルを指定する。レ
ファレンスノード２０−１、ＮＣ１に対するデータベー
スもダウンロードされる。これはＮＣ１に対するレファ
レンステーブル内にエントリを作らせる。特徴Ａに対す
るデータベースがダウンロードされると、エントリがＡ
ＨＵ１／ＦＡＮに対するレファレンステーブルに作られ
るが、これにはバインド情報がついていない。この“バ
インドされていない”レファレンスは、ＮＣ１のある特
徴がＦＡＮをレファレンスすることを単に示す。ハイレ
ベルのソフトウェア特徴Ｂに対するデータベースがダウ
ンロードされると、特徴Ｂも、テーブルにバインドされ
ていないレファレンスを加えようと努めるがそれがそこ
（レファレンステーブル２０−３０２のオフセット２
７）にすでにあることを知る。その後、両方の特徴は、
ＡＨＵ１／ＦＡＮに対する名前付きレファレンスを２７
のオフセットと取替え、テーブルの中へ入れる。この時
点でもバインド情報がＮＣ１のテーブルの中になおない
ことに注意しなさい。ハイレベルのソフトウェア特徴Ａ
の実行は、ＮＣ１にＦＡＮオブジェクトの値を読むこと
を要求する。バインディングが、ＡＨＵ１／ＦＡＮに対
するＮＣ１のレファレンステーブル中にはまだないの
で、ソフトウェアはネットワークにＡＨＵ１／ＦＮＡを
位置指定しなければならない。これはシステム名ＡＨＵ
１を求めてシステム名リストあるいはＮＣ１のグループ
ディレクトリを探索することを要求する。図２０に示さ
れるように、リストは、ＡＨＵ１がＮＣ２に位置指定さ
れていることを示す。したがって、ソフトウェアはＮＣ
２にリクエストを向ける。ＮＣ２は、要素ディレクトリ
を使用して、そのデータベースにオブジェクトを置く。
これは、ＡＨＵ１のオブジェクトのディレクトリ中のＦ
ＡＮを調べることによって遂行される。図２０に示され
る例において、これは、ＮＣ２中のレファレンステーブ
ルのオフセット６に位置指定されたバイナリ出力ポイン
トである。上述のように、この情報がダウンロード時に
そこに置かれたので、ＮＣ２のレファレンステーブル
は、ＦＡＮに対して加えられバインド情報をすでに持っ
ている。従って、ソフトウェアは、このノード上に正確
なデータ・ベース管理プログラム（バイナリ出力）オブ
ジェクトマネジャーにリクエストを送信し、正確なレコ
ード（それはレコード３である）を要求することができ
る。一度データが得られれば、情報はバインド情報と共
に特徴Ａ及びＮＣ１に渡される。その時、ＦＡＮに対す
るレファレンステーブルエントリは、正確なバインド情
報と共にノードＮＣ１に完成される。図２０は、さらに
ＮＣ２の特徴Ｃからのような、上位ノードのレフィレン
スに対して、データベースがダウンロードされた後、バ
インド情報がレファレンステーブル中にすでにあること
を例示する。したがって、はじめてレファレンスがアク
セスされたときでさえ、バインディング手続きはそれら
のレファレンスに対して要求されない。バインド情報が
ネットワークコントローラＮＣ１に提供されているの
で、ネットワークコントローラＮＣ１からのその後のレ
ファレンスは上記の手続きを繰り返す必要がない。特徴
ＢがＦＡＮを参照する必要があると仮定した場合、レフ
ァレンステーブルにＦＡＮファンを見つけるためには、
格納されている２７のオフセットを使用する。この時、
バインド情報は、テーブル中にすでにある。したがっ
て、ソフトウェアは、ノードＮＣ２のバイナリ出力デー
タベースマネジャーにリクエストを直接送信し、レコー
ド３を要求することができよう。上述の探索手続きはも
はやリクエストされない。引き続いてＦＡＮを参照する
ＮＣ１上の他の任意の特徴レファレンスファンはテーブ
ル中の同じバウンドレファレンスを使用する。したがっ
て、バインディングは、ＮＣ１からすべてのレファレン
スに対して一度リクエストされるだけである。以前に議
論したように、各ソフトウェア特徴で、より長いＡＳＣ
ＩＩ名が短いテーブルオフセットによって取替えられ、
ただ１つのテーブルエントリだけがその同じノードから
すべてのレファレンスに対してクリエストされるので、
レファレンステーブルはメモリ要求を縮小する。図２５
は、データ要素がノード内を移動する場合の事象のシー
ケンスを例示する。ＦＡＮがレコード３からレコード５
までＮＣ２のデータベース内を移動すると仮定しなさ
い。これは、たとえば、パーソナルコンピュータでのデ
ータベースの再生成の結果として発生する可能性があ
る。その結果、ＡＨＵ１／ＦＡＮがレコード５まで移動
したのに対して、レコード３がＡＨＵ１／ポンプと呼ば
れるオブジェクトに今度はなる。ネットワークコントロ
ーラ２５−２上のバイナリ出力データベースマネジャー
に直接行くべき、ネットワークコントローラ２５−１に
によって使用されるバインド情報は、レコード３に対す
るリクエストを引起すだろう。しかしながら、レコード
３で見つけられたネームと比較できるように、このリク
エストも、ＡＨＵ１／ＦＡＮのネームを送る。この場
合、レコードはもはや一致しない。前述の最適化の１つ
を使用して、バイナリ出力データベースマネジャーはそ
れがオブジェクトＡＨＵ１／ＦＡＮをなお持つかどうか
理解するために、自身のデータベースを探索する。この
場合、それはレコード５で見つけられ、したがって、要
求された情報は新しい正確なバインド情報と共に返され
る。ＮＣ１は、それが使用していたバインディングがＮ
Ｃ２によって修正されており、レコード３に対するレフ
ァレンスをレコード５と交換することによって、そのレ
ファレンステーブルを更新することを理解する。したが
って、オブジェクトはネットワークコントローラＮＣ２
内を移動した。しかし、ネットワークコントローラＮＣ
１は、ネットワークコントローラＮＣ１に対する何の変
更もなしでデータをなお見つけることができた。更に、
共通のレファレンステーブルエントリが更新されるの
で、ネットワークコントローラ２５−１のレファレンス
はすべて修正される。ダウンロードの結果、データオブ
ジェクトが異なるネットワークコントローラに移動させ
られた場合、図２６は状況を例示する。この場合、ユー
ザは、システムあるいは“グループ”ネームＡＨＵ１を
移動させるＮＣ２、およびＮＣ３に対するデータベー
ス、およびＮＣ３に対するそのオブジェクトを生成し
た。今、ＦＡＮはネットワークコントローラＮＣ３（ノ
ード５）上のバイナリ出力データベースのレコード７で
ある。ここで、それがすでに持っているバインド情報を
使用して、ＦＡＮを参照しようとするネットワークコン
トローラＮＣ１の試みは失敗する。これはネットワーク
コントローラＮＣ２でのネーム比較、レコード３が、Ａ
ＨＵ１／ＦＡＮデータオブジェクトがそのアドレスには
もはやないことを示すためである。さらに、ＮＣ２デー
タベースの残る要素のチェックは、ＦＡＮを見つけるこ
とができないことを示す。したがって、ネットワークコ
ントローラ１の特徴Ａは、エラーメッセージを受信す
る。ネットワークコントローラ２６−１は、そのテーブ
ルからのバインド情報を削除することによって、およ
び、ＡＨＵ１／ＦＡＮの新しい位置を見つけるために上
に議論された方法に従うことによって応答する。この場
合、それは、ネットワークコントローラ３のレコード７
で見つけられるだろう。共通のレファレンステーブルが
更新されるので、これを一度行うことは、ネットワーク
コントローラＮＣ１のレファレンスをすべて修正するこ
とになる。 もしデータ要素がネットワークから完全に
削除されていたとしたら、ネットワークコントローラＮ
Ｃ１は、忠告メッセージを介してＦＡＮを見つけること
ができないことをオペレータへ報告していたことだろう
ということは注意すべきである。ことことは、また、Ｆ
ＡＮが再びダウンロードされるまで、ＮＣ１からＦＡＮ
へのすべてのレファレンスに対して真実である。したが
って、ＡＨＵ１／ＦＡＮが再定義されるか、レファレン
スが削除されるまで、エラーは発生する。しかしなが
ら、ダウンロード後、レファレンスは、盤インドし適切
に作動し始めるだろう。従って、ノードダウンロードの
順序は重大ではない。Ｎ１バスで相互に連結したノード
間で適切な時間同期を提供するために、ノードの１つ
が、限定的システムマネジャーの役割を演ずる必要があ
る。図２７に示されるように、ノード２７−１は時間同
期装置（限定的システムマネジャー）として２７−２で
選択され、ノードは時間を定義し、Ｎ１バスで相互に連
結した他方のノードにこの情報を送信する。２７−３に
示されて、ノードは非更新間隔の間、時間をモニタす
る。決定ブロック２７−４は現在、再同期がセットされ
る時間かどうか決めるために、クロックをテストする。
そうでなければ、コントロールは２７−３に転送され、
時間モニタリングは係属する。ブロック２７−５におい
て、今ノード間で時間の同期を再設定する時であるとい
うことが決定ブロック２７−４において決定された場
合、ノードはそれがシステム時間マネジャーかどうか決
めるために、テストする。そうならば、コントロールは
２７−２を閉鎖するために転送される。また、システム
時間マネジャーは現在の時間を送信する。決定ブロック
２７−５において、それがシステムマネジャーではない
ことをノードが認識した場合、ブロック２７−６におい
て、ノードは、それが時間同期データを受信したかどう
か決める。そうならば、ノードはブロック２７−７にお
いてその時間をリセットし、ブロック２７−３でのよう
に、時間モニタリングは継続する。時間同期データがブ
ロック２７−６で受信されない場合、ブロック２７−８
のノードは、それがシステム時間マネジャーでありうる
かどうかを決め、そうならば、ブロック２７−２でのよ
うに時間を送信する。これは、オリジナルのシステム時
間マネジャーが障害を起こしたり、オフラインになった
場合、新しいノードが時間同期責任を引き受けることを
可能にする。ノード間で時間を同期させることに加え
て、グローバルなデータを同期させることも必要であ
る。図２８は、ダウンロードの基本ステップを示す。フ
ァンクションブロック２８−１において、グローバルな
データベースはネットワークの上に定義されロードされ
る。グローバルなデータベースは、パスワード、システ
ム名（オブジェクト名ではないが）のリスト、ノードの
リストおよびシステムにつながっているプリンタ、ユー
ザのある分類の忠告メッセージがどこに向けられている
かを示すリポートグループ、またすべてのノードに有用
な他の情報のような項目を含むことができる。ファンク
ションブロック２８−３は、各ノードがまた、アーカイ
ブ装置の中でそのノードに対して定義されるデータベー
スを持つことを示す。ノードデータベースは、ノードに
格納されるデータ、およびノードによって制御される他
の装置にＮ２バスを通じて送信される補足データを含ん
でいる。ファンクションブロック２８−５において、ノ
ードは、それにＮ１アドレスを与えることおよび不揮発
性メモリにそのアーカイブ装置の身元を格納することに
よって、ネットワークに構成される。ステップ２８−７
でのパワーアップに続いて、ノードはステップ２８−９
で他のノードと同期しなければならない。同期が完全か
どうかをステップ２８−１１はテストする。そうでなけ
れば、コントロールは同期プロセスを完成するためにフ
ァンクッションブロック２８−９に転送される。ノード
の同期の完成に際して、ノードが自身の特別のデータベ
ースをダウンロードするために、アーカイブ装置にアク
セスするファンクションブロック２８−１３に、コント
ロールは移る。各データ要素が受信されるので、情報が
Ｎ２バスで装置に送信されるかどうかを決定ブロック２
８−１５はテストする。送信されなければ、情報は、フ
ァンクションブロック２８−１７に示されるようなノー
ドに格納される。ファンクションブロック２８−１９に
示されるように、情報がＮ２ネットワークにつながる装
置に向けて予定されている場合、情報は装置までＮ２ネ
ットワークを通して渡される。図２９は、同期がどのよ
うに起るかをさらに例示する。パワーアップに際して、
ノードはＥＰＲＯＭ中のコードを実行し、ノードの不揮
発性メモリの中で定義されているノードのアーカイブ装
置を識別する。これはファンションブロック２９−１に
示されている。ファンクション２９−３に示されている
ように、ノードは、それから、そのＲＡＭの中へコード
をダウンロードするようにアーカイブ装置に要求する。
決定ブロック２９−５で、ネットワークに連結するノー
ドはそれがネットワークにつながる別のノードから同報
通信を受信したかどうか調べるテストをする。発明に従
って、ネットワークにつながるすべてのノードは、その
ノードのグローバルなデータベースの最新のバージョン
を示すタイムスタンプを周期的に同報通信する。したが
って、ネットワークに連結するノードがまだ決定ブロッ
ク２５−９に示されるような同報通信タイムスタンプを
受信してはない場合、それが１つを受信するまで、ノー
ドは待つ。最初の同報通信タイムスタンプの受信に際し
て、ネットワークに入るノードは、ファンクションブロ
ック２９−７に示されるようにタイムスタンプに関連し
たノードからグローバルなデータを要求する。さらに、
新しいノードは、そのタイムスタンプとしてのグローバ
ルなデータベース情報とともに、それが受信した時刻を
格納する。続いて、ファンクションブロック２９−９に
おいて、ノードは以前に議論したように、自身の特別の
データベースを得るために、アーカイブ装置にアクセス
する。そのデータベースを受信した後、新しいノード
は、ファンクションブロック２９−１１に示されるよう
に、そのタイムスタンプを同報通信するとき、ネットワ
ークの他のノードとつながる。データベースの同期は、
ファンクションブロック２９−１３に示されるように他
のノードからタイムスタンプを受信することによって保
持される。受信タイムスタンプがノードの現在タイムス
タンプより後である場合、ファンクションブロック２９
−１５および２９−１７に示されるように、ノードは、
あとのタイムスタンプを持つノードにグローバルなデー
タを要求する。利用できないグローバルなデータを待ち
ながら、ノードがハングアップ状態になることも有り得
るということも注意すべきである。したがって、待ちス
テップ２９−１９は時間終了決定ポイント２９−２１に
対してテストされる。ノードのオペレーションの保留を
回避するために、時間が終了した場合、ノードは、ステ
ップ２９−２３で示されるようなグローバルなデータを
求めてアーカイブ装置にアクセスする。代替アブローチ
は、その第１スタンプの受信を待つことを回避するため
に、上述のようにネットワークとつながるノードを許可
する。このような代替方法によれば、ネットワークにジ
ョインするノードは先ずアーカイブ装置にアクセスして
グローバルデータを得てこのグローバルデータのタイム
スタンプをそのノードのタイムスタンプとしてアーカイ
ブ装置に記録する。次いでノードはネットワークにジョ
インし、そのタイムスタンプを周期的に送出するととも
に先に述べたように他のノードのタイムスタンプを検査
する。スレーブ装置をＮ２ネットワークのノードによっ
て制御しつつ同様のアプローチが用いられる。Ｎ２ネッ
トワークは、オンラインされるごとに、そのデータベー
ス更新レベルを、タイムスタンプとしてそのネットワー
クコントローラに送る。ネットワークコントローラが固
有のタイムスタンプによって示される新しいデータを以
ている場合には、ネットワークコントローラはその情報
（これはデータベースの一部である）を、Ｎ２ネットワ
ークにオンラインしつつある装置にダウンロードする。
Ｎ２ネットワークにオンラインしている装置のタイムス
タンプによって示されるデータベース以外の最近データ
をネットワークコントローラが持っていない時には、ネ
ットワークコントローラはＮ２装置が正しいデータベー
スを持っているものと判断する。第３０図は、ルーティ
ングテーブルを持たない装置へのダウンロード情報にア
プローチする手法を示している。このアプローチは、複
数の装置をカスケード接続して行なわれるもので、ルー
ティングテーブルを持たない装置への経路がルーティン
グテーブルを持つ装置を経由して達成される。このよう
なアプローチ方法は、人が装置のおいてある場所まで行
って装置のダウンロード或いはアップロードを物理的に
行なってやる事が望ましくないときに有用である。この
発明においては、レクエストを行なうネットワークコン
トローラは、少なくともそのアーカイブ装置のアドレス
を、不揮発性メモリーの中に保持する。また、各ネット
ワークコントローラは、このネットワークコントローラ
のためのダウンロードを開始するネットワークコントロ
ーラのアドレスを、その不揮発性メモリーの中に保持す
る。このようにカスケード構造が用いられることによ
り、階層において上位のノードが、階層において下位に
あるノードよりも先に初期化される。二つのケースが可
能となる。第３０図において、ダウンロード装置３０−
１は、ルーティングテーブルを持たないノード３０−４
として示されるネットワークコントローラ３についてダ
ウンロードを開始する事ができる。第３１図のテーブル
１は、アーカイブ装置またはＰＣのネットワークコント
ロール層によって遂行されるステップのシーケンスを示
している。各ノードが、そのネットワークを定義するア
ドレス、ネットワーク上のローカルアドレス、およびノ
ードのポートを有していることに留意することが必要で
ある。ノード自身にはポート０が割り当てられる。従っ
て、ダウンロード装置３０−１は、アドレスとして１：
１：０を持つ。何故ならば、この場合、装置はネットワ
ーク上１にあり、ローカルアドレスが１であり、また、
装置自体がポート０としてテイギされているからであ
る。第３０図の表１からわかるように、メッセージのソ
ースは１：１：０であり、メッセージのあてさきは２：
４：０である。また、ネットワーク中を伝達されるメッ
セージの刻々のソース即ち仮ソースも表示される。オリ
ジナルのソースにおいては、メッセージソースと仮ソー
スとが同一のものとなる。即ち、最初の仮ソースは１：
１：０である。第３１図の表に示される他の仮ソースは
先のものと同じネットワークならびにローカルアドレス
を持つ。ノードの、ネットワーク層（これは、例えば、
国際標準機構（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎ
ｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎ）のオープンシ
ステムインターコネクションモデル）中に定義されたル
ーティングは、メッセージを、ネットワークが１、ロー
カルアドレスが２、ポートがＯのＮＣ１にルートする。
表中のステップをたどると、メッセージをＮＣ１次いで
ＮＣ２をとうしてルートすることによってダウンロード
情報がＮＣ３に到達するということが理解される。ＮＣ
３は、メッセージを受け取ったことを示す確認応答をソ
ースに対して行なう。この場合、メッセージを受ける装
置はルーティングテーブルを持っていないので、メッセ
ージをこの装置に対して送り込んだノードに対して返答
が行なわれる。確認応答は、このノードから、メッセー
ジの伝達経路を逆にたどるかあるいはルーティングテー
ブルを持つノードによって定義される適宜の経路を経て
ソースに送られる。第２のケースにおいては、ネットワ
ークコントローラ３がアーカイブＰＣ３０−１に対して
ダウンロードリクエストを開始する。この場合には、ア
ドレス２：４：０に位置するノードＮＣ３はそのダウン
ロードリクエストを送出するべきルーティングテーブル
を持たない。しかしながら、ＮＣ３は、前に述べたよう
に、このノードＮＣ３のためにダウンロードを開始する
べきネットワークコントローラのアドレスをその不揮発
性メモリーの中に保持している。したがって、ＮＣ３
は、そのリクエストをこのネットワークに送ることがで
きる。ＮＣ３は、アドレス１：１：０にあるデータダウ
ンロード装置（これは、ＮＣ３の中に、ＮＣ３のアーカ
イブ装置として特定されている。）に対してダウンロー
ドを要求する。このリクエストがたどるルートは、第３
２図の表２からわかるように、アドレス２：３：０にあ
るＮＣがＮＣ３に対するイニシエータであるということ
を認識する。ＮＣ２は、メッセージをアーカイブ装置に
送るために、すでにルーティングテーブルを持ってい
る。このことは、複数の装置をカスケード接続すること
によってメッセージをアーカイブＰＣに受け取らせるこ
とが出来るということを示している。これにより、上位
のノード、例えばＮＣ２が、下位のノード、例えばＮＣ
３がダウンロードされ得る前に完全に機能化されなけれ
ばならないというような階層化が達成されるということ
が理解されよう。同様に、ＮＣ３で現す別のノードへの
ダウンロードは、ＮＣ３からのダウンロードが、そのイ
ニシエータであるＮＣ２を通じて完全に終了するまでは
行なわれない。ダウンロードか行なわれるとき、目標が
存在するＮＣ以外のＮＣにシステムが定義されるような
他の複数の目標の存在によって問題が生じる。何故なら
ば、二つのＮＣの持つデータベースが相互に矛盾しない
ものであるものであるとは限らないからである。この矛
盾は、定義がインターレースされたいくつかのＮＣが影
響される際に自然に生じるものであるので、自動的に訂
正することは出来ない。これらのＮＣの更新すなわちダ
ウンローディングを行なうためにはある時間長が必要で
あり、その時間中に不可避的に矛盾が生じる。しかしな
がら、全ての問題は検出されユーザーに知らされる。ひ
とつのＮＣについてダウンロードが行なわれるとき、他
の複数のＮＣはダウンロードが行なわれているＮＣと矛
盾するかも知れない。もしそのような条件が存続するな
ら、あるいはまた、もし上記時間中にシステムがいずれ
かのＮＣにアクセスを行なうならば、エラーやあいまい
さが生じる。目標がひとつのＮＣから別のＮＣに移され
た時に生じる問題の例を以下に示す。しかし、結果的な
データベース不整合性は同じであろう。次の仮定がなさ
れる ａＮＣ１は、システムＳに対するディレクトリを含んで
いる。 ｂＮＣ２は、オブジェクト０のオリジナルのバージョン
を含んでいる。 ｃＮＣ３は、同じオブジェクト０の新しいバージョンを
含んでいる。 正常なケースは、ＮＣ３の代わりにデータベースにオブ
ジェクト０を加えて、ＮＣ２からそれを削除することで
ある。これは、テンプレート生成（単一のオブジェクト
変更）を通じて、あるいはＤＤＬ（データ定義言語）を
介してのいずれかで行うことができる。いずれの場合に
も不整合性は発生する可能性がある。ＤＤＬがこの変更
に使用されると仮定しなさい。その場合、３つのＮＤＤ
Ｌファイルをトランザクションを完成するために更新す
る必要がある（Ｎ１、２および３）。その後、各々のＮ
Ｃをダウンロードしなければならない。しかしながら、
ダウンロードの１つ以上はスキップすることができよ
う。あるいは、結果的にフィールドにおいて一貫しない
ＮＣになる、不正確にダウンロードされた古いデータベ
ースはスキップすることができよう。テンプレート生成
変更が失敗するか、何らかの理由のために途中で遮断さ
れる場合、類似した問題が発生することがある。次の場
合は、発生する可能性がある不整合性を実証する。上記
の変更が行なわれた後に、ＮＣ１が最初にダウンロード
されたと仮定しなさない。その場合、Ｓに対するシステ
ム・ディレクトリは、オブジェクト０がＮＣ３に駐在す
べきであることを示すだろう。ＮＣ３がダウンロードさ
れる（仮にそれがダウンロードされたとして！）まで、
ディレクトリが「それはＮＣ３にあるべきである。」と
言うのでオブジェクト０は見つけることができない。こ
れが第１の問題のケース、つまり、そこにないオブジェ
クトを指定しているディレクトリ、である。バインドさ
れたレファレンスは、ＮＣ２の中の古いオブジェクト０
を今のところ使用し続けるだろうということに注意しな
さい。ディレクトリが新しいバインディングに対して必
要であり、それが存在しないオブジェクトを指定するの
で、新しいバインディングを遂行することができない。
ＮＣ２が次にダウンロードされるとさらに仮定しなさ
い。オブジェクト０の古いバージョンが今度は削除され
るので、古いバインディングさえも失敗するという付随
的問題に関して上記の問題と同じ問題をこれは引き起こ
す。ＮＣ３がダウンロードされるまで、オブジェクトは
存在しない。ＮＣ２が最初にダウンロードされると今度
は仮定しなさい。Ｓに対する古いディレクトリがオブジ
ェクトをもはや含んでいないＮＣ２を依然として指定し
ているので、これは再び同じ問題である。現行のバイン
ディングは無効になり、新しいバインディングは作るこ
とができない。ＮＣ２がダウンロードされた後、次にＮ
Ｃ１がダウンロードされたとさらに仮定しなさい。同じ
問題は再び発生する、なぜならディレクトリが、新しい
オブジェクトでまだダウンロードされていないＮＣ３を
指定しており、古いオブジェクトはなくなっているから
である。特徴ｘ−１８−２１がアナログタイプ温度ポイ
ントＴ１、Ｔ２およびＴ３の値を読む場合、図１８に基
いて１つの例が発生する。以前に議論したように、特徴
はハードウェアに関係がなく、したがって、アナログ入
力オブジェクトマネジャー１８−２７に対して各温度に
ポイントを求める同じリクエストをする。これはリクエ
ストされるオブジェクトがアナログタイプであるからで
ある。アナログ入力オブジェクトマネジャー１８−２７
自身もまた、Ｔ１、Ｔ２およびＴ３が設置されているス
レーブに関係がない。特徴ｘおよびアナログ入力オブジ
ェクトマネジャー１８−２７に関するかぎり、様々なハ
ードウェアマネジャーへの通信はすべてＴ１、Ｔ２およ
びＴ３に対して同一である。アナログ入力オブジェクト
マネジャー１８−２７は、ハードウェアオブジェクトレ
ベル１７−９から７２．３°Ｆのような明瞭な浮動小数
点数（実数）を要求する。ストレートタイプＡおよびＢ
も対応するハードウェアオブジェクトマネジャー１８−
３７および１８−４１はリクエストされるタイプの値を
アナログ入力オブジェクトマネジャー１８−２７に供給
するようにデータを決定する。値を決定するために、ハ
ードウェアオブジェクトマネジャーの個々の計算の何ら
かの数がリクエストされるかもしれない。例えば、温度
センサーの値が、アナログ／デジタル変換器によって産
み出されるディジタルカウントのようなカウント（この
カウントは浮動小数点値を計算するためにあらかじめ定
められた範囲に渡って展開されねばならない）としてス
レーブコントローラに到着すると仮定しなさい。センサ
ーの最終温度値が得られる前に、一層の修正が、スパン
方程式、平方根方程式およびフィルターによってリクエ
ストされるかもしれない。図１７に示されるように、タ
イプＡスレーブコントローラ１７−１５および１７−１
７は、Ｔ１およびＴ２生データを受け渡す。タイプＢス
レーブコントローラはＴ３生データを受け渡す。コント
ローラＡおよびＢが完全に異なるレベルの能力を持つと
仮定すると、コントローラの相違は既存のコンピュータ
化されたファシリティマネジメント管理システムにおい
て、重大な問題を引き起こすであろう。例えば、他方が
インプリメントしていないかもしれないのに対して、一
方のコントローラは平方根方程式をインプリメントする
かもしれない。あるいは、コントローラ同士が異なる範
囲方程式を持つかもしれない。従来のファシリティマネ
ジメントシステムにおいては、ハイレベルのソフトウェ
アはこれらの相違を補正する必要があるだろう。しかし
ながら、本発明においては、スレーブコントローラに対
するハードウェアオブジェクトマネジャーは、データを
決定してアナログ入力オブジェクトマネジャー１８−２
７とこれらの相違を覆うために、ノードプロセッサ（あ
るいは個別のプロセッサ）にアクセスする。タイプＡス
レーブコントローラ１７−１５および１７−１７は、ネ
ットワークコントローラにアナログディジタルカウント
だけを提供する、高度に単純な装置であると仮定しなさ
い。この場合、タイプＡスレーブコントローラに対する
ハードウェアオブジェクトマネジャー１８−３７は、ア
ナログ入力オブジェクトマネジャー１８−２７に提供す
るための最終温度値Ｔ１およびＴ２を得るのに必要な別
の計算を実行しなければならない。対照的に、スレーブ
コントローラタイプＢが、ネットワークコントローラ上
へ情報を送る以前に、ほとんどのレインジング及びフィ
ルタリングを実行する高度に精巧な装置であると仮定し
なさい。この場合、タイプＢコントローラに対するオブ
ジェクトマネジャー１８−４１は比較的に小さな処理を
実行する。いずれの場合にも、ハードウェアオブジェク
トマネジャーによって実行される処理は、データを操作
し、ハイレベルの特徴にそれを送るソフトウェアオブジ
ェクトマネジャー１８−２７に対して透過的である。こ
れは、ハードウェアオブジェクトマネジャー１８−３７
と１８−４１ならびにアナログ入力オブジェクトマネジ
ャー１８−２７間に共通の情報インタフェースがあるか
らである。したがって、ハードウェアオブジェクトマネ
ジャーはすべて、同じ規則に従ったソフトウェアオブジ
ェクトレベル−１７−７と通信する。したがって、アナ
ログ入力オブジェクトマネジャー１８−２７を総称オブ
ジェクトタイプ（この場合、アナログ入力オブジェク
ト）を処理するため書くことができる。それは、アナロ
グ入力の各単一の可能なスレーブコントローラ実行用代
替コードを含んでいる必要がない。さらに、図１８に示
されるように、通信が、ソフトウェアオブジェクトレベ
ル１８−７のすべての特徴とすべてのオブジェクトマネ
ジャー、およびソフトウェアオブジェクトレベル１８−
７およびハードウェアオブジェクトレベル１８−９のす
べてのオブジェクトマネジャー間で可能であることに注
意すべきである。使用される実際の通信パスはリクエス
トされる特徴およびデータによって実行されるファンク
ションだけからなるファンクションである。したがっ
て、特徴ｙもソフトウェアオブジェクトＴ１をリクエス
トしてもよく、したがって、アナログ入力オブジェクト
マネジャー１８−２７にアクセスする。同様に、特徴ｎ
は、ハードウェアオブジェクトレベル１８−９の１つ以
上のオブジェクトマネジャーからデータをさらに要求す
ることもできる、ソフトウェアオブジェクトレベル１８
−７の１つ以上のオブジェクトマネジャーからデータを
リクエストしてもよい。ハードウェアオブジェクトとソ
フトウェアオブジェクトレベル間のインタフェースの共
有性は、新スレーブコントローラおよびオブジェクト例
の追加を単純化する。もし第４温度センサーＴ４がシス
テムに加えられれば、オブジェクト例は上記の例に加え
られるだろう。第３タイプＡスレーブコントローラＡ３
が加えられれば、同じタイプの新スレーブコントローラ
が加えられるだろう。いずれの場合にも、ソフトウェア
オブジェクトレベル１８−７とハードウェアオブジェク
トレベル１８−９間に情報のインタフェースにたいする
変更がないので、必要なソフトウェアはすべてネットワ
ークコントローラに存在する。ユーザはただ、１８−２
９のアナロク入力オブジェクトＴ４の新しい例を生成す
るためにデータベースを修正変更する必要があるだけで
ある。あるいは、タイプＡコントローラオブジェクト
（たとえば、Ａ３）の新しい例をネットワークコントロ
ーラに生成するために、データベース１８−３９を修正
変更する必要があるだけである。既存のファシリティマ
ネジメントシステムソフトウェアに最少のインパクトを
そなえた新しいスレーブコントローラタイプを加えるこ
とも可能である。新しいコントローラタイプ、タイプＣ
がローカル・バス１７−１３に付けられると仮定しなさ
い。そのローカル・バスで操作可能なユニットに対する
マスターコントロールノードの役をするネットワークコ
ントローラにおいて、既存のソフトウェアに新しいハー
ドウェアオブジェクトマネジャーを加えることで（ダウ
ンロードあるいは他の手段によって）をこのことは要求
するだろう。このハードウェアオブジェクトマネジャー
は、システムの中ですでに定義されているソフトウェア
オブジェクトに新コントローラの能力をマップするだろ
う。例えば、新ハードウェアコントローラは新しいハー
ドウェアオブジェクトマネジャーをリクエストして、略
式な方法でアナログ温度データをモニタしてもよい。新
コントローラがアナログ温度データを産み出せば、新し
いハードウェアブジェクトマネジャーは、アナログ入力
オブジェクトの新しい例Ｔ５にデータをマップすること
ができる。既存のソフトウェアオブジェクトマネジャー
およびソフトウェアオブジェクトレベル１７−７、およ
びネットワーク制御ソフトウェアの特徴レベル１７−５
のハイレベル特徴は、影響されないだろう。なぜならそ
れらは従来と同じ様に作動するであろうから。唯一の例
外は、既存のタイプのオブジェクトとはオペレーション
において非常に異なるために、ソフトウェアオブジェク
トレベル１７−７で既存のソフトウェアオブジェクトマ
ネジャーの１つにマップすることができなかった新しい
データタイプを、新しいハードウェアがいつサポートす
るかであろう。その場合、新しいソフトウェアオブジェ
クトも作成されなければならないかもしれない。したが
って、ハードウエアオブジェクトマネジャーは、ソフト
ウェアオブジェクトに対するハードウェアの相違を覆う
ために、再び使用される。したがって、ソフトウェアオ
ブジェクトマネジャーは異なるハードウェアに左右され
るバージョンを持つ必要がない。ソフトウェアオブジェ
クトマネジャーは、データ要素がタイプＡコントロール
のもとで操作されたセンサーから由来するものであれ、
タイプＢコントロールの下で操作された別のセンサーか
ら由来するものであれ、データ要素を同じ方法で処理す
る。ハードウェアオブジェクトマネジャーは、ソフトウ
ェアオブジェクトマネジャーの必要によってリクエスト
される形にデータをフォーマットするかマップする。こ
れは、ソフトウェアオブジェクトマネジャーがより高い
レベルのソフトウェア特徴にハードウェアから独立した
てインタフェースを提供することを可能にする。この発
明の別アスペクトに従って、図１９は、ソフトウェアあ
るいはハードウェアマネジャーが、センサーのような操
作可能ユニットから直接得られたデータが処理されるの
とほとんど同じ方法で計算中に生成されるデータを処理
するための一つの構成体を提供することを例示する。発
明に従って、１つのポイントがオブジェクトのタイプと
して定義される。例えば、アナログ入力ポイントはオブ
ジェクトのタイプである。したがって、ポイントにはそ
の現在地、上限、下限、アラーム状態、そのハードウェ
アアドレスなどのような属性がある。ポイントに対する
これらの複数次元はポイントをベクトル量として定義す
る。１ポイントは、フィールドのセンサーのような操作
可能ユニットに常に関係している。したがって、操作可
能ユニット１９−１は、ソフトウェアオブジェクトマネ
ジャー１９−７によってリクエストされる形にハードウ
ェアオブジェクトマネジャー１９−５のデータを処理す
るネットワークコントローラ１９−３にデータを提供す
る。ポイントに対応するデータは、プロセッサメモリ１
７−４のような記憶手段に属性１９−９として格納され
る。特徴レベル１９−１１での中間計算は、ソフトウェ
アオブジェクトレベル１９−１３が操作可能ユニットか
ら直接集められないデータを供給することを時として要
求することができる。そのようなデータを処理する共通
の方法を容易にするために、擬ポイント１９−１５がソ
フトウェアオブジェクトレベル１９−１３で作成され
る。擬ポイントは、ソフトウェアオブジェクトマネジャ
ー１９−７によってポイント１９−９とまったく同じ方
法で処理される。１ポイントと擬ポイントの間の相違は
擬ポイントが関連するオブジェクトからその属性の１つ
以上を得ているのに対して、１ポイントが操作可能ユニ
ットからその値を得ることである。擬ポイントは、その
属性の１つとして関連するオブジェクトの身元を格納す
る。したがって、擬ポイント１９−１５は、ポイント１
９−９としてその関連するオブジェクトを認識すること
ができよう。この場合、擬ポイント１９−１５は、ポイ
ント１９−９の属性からその属性の１つ以上を得ること
ができよう。これは同じ方法で特徴レベル１９−１１か
らのデータリクエストをすべて処理することを、ソフト
ウェアオブジェクトマネジャー１９−７に許可する。し
たがって、ポイントとして操作可能ユニットから得られ
たデータ、および、そのような操作可能ユニットから直
接得られない、中間計算の中で使用される他のデータを
区別する必要がない。図２０は、高速ネットワークバス
２０−７で相互に連結したネットワークコントローラ２
０−１、２０−３、２０−５を示す。高速ネットワーク
バス２０−７は、ノード間のデータをコンピュータ２０
−９に伝送するために使用される。コンピュータ２０−
９は、ネットワークコントローラ２０−１に対するアー
カイブデータベース２０−１３、およびネットワークコ
ントローラ２０−３に対するアーカイブデータベース２
０−１５のようなアーカイブされたデータベースを含ん
でいる記憶要素２０−１１へ情報を伝送する。コンピュ
ータ２０−９は、データのレベルが特定のアプリケーシ
ョンに対して適切なものはどんなレベルであれ、ユーザ
がデータ要素を生成することを可能にし、データ要素に
ネームを割当てることを可能にする生成ソフトウェア２
０−１０を含んでいる。２つの要素に同じネームがあっ
てはならないので、生成ソフトウェアはアーカイブされ
たデータベースあるいはオンラインデータベースをチェ
ックし、各データ要素が自身に特有のネームを割当てら
れていることを確認する。ネームが割当てられた場合、
ネームおよびデータ要素は両方とも高速バス２０−７を
使用して、上位ノードにダウンロードされる。これは、
レファレンス番号２１−２０および２１−２２として生
成時刻で図２１に概略的に示される。その結果、上位ノ
ードは名前付きデータ要素を含んでいる。図２１のファ
ンクションブロック２１−２４にさらに示されるよう
に、ランタイム中、レファレンスノードは、ネームによ
ってデータ要素に対するリクエストを送信する。これが
指定されるデータ要素に対する第１リクエストである場
合、ファンクションンロック２１−２６に示されるよう
に、データ要素が見つけられるまで、ネットワーク全体
が探索される。これは、ファンクションブロック２１−
２８に概略的に示される。ネームをネットワークのいか
なる場所にも見つけることができない場合、ファンクシ
ョンブロック２１−３０に示されるように、エラーメッ
セージ２１−３２が送信される。また、ネームの探索は
ブロック２１−３８で終了される。一方、ファンクショ
ンブロック２１−３４に示されるように、ネームが見つ
けられた場合、ネームはバインド情報でタグを付けられ
る。このバインディング情報ネットワーク上のノードア
ドレス、およびノードのデータベース内のデータ要素の
内部アドレスである。ノードアドレスおよびデータ要素
の内部アドレスには任意の便利なフォーマットがありう
る。ファンクションブロック２１−３６に従って、バイ
ンド情報およびデータ要素それ自身は、バインド情報を
格納するレファレンスノードに返される。レファレンス
ノードがデータ要素に対する第１リクエストを行ってい
ない場合、ブロック２１−２６に示されるように、バイ
ンド情報が読まれるコントロールはファンクションブロ
ック２１−４０にパスする。バインド情報を使用して、
ブロック２１−４２で、指定位置（上位ノードおよびデ
ータ要素位置）でのネームは、リクエストされたネーム
を持つブロック２１−４４の中で読まれ比較される。指
定位置で見つかったネームが、リクエストされたネーム
と一致した場合、データは、ステップ２１−４６に従っ
てリクエストノードに返される。そして、データ取得ル
ーチンが終了される。しかしながら、指定された位置で
見つけられたネームがリクエストされたネームと一致し
ないこともありうる。これは、バインド情報が無効にな
ったことを示す。典型的に、検証は上位ノードで行われ
る。ホストは、リクエストされたデータが、境界アドレ
スに格納された要素のネームと渡されたネームを比較す
ることによって同じアドレスにまだあることを確認す
る。それらが同一である場合、以前に注意したように、
バインディングはまだ有効である。また、リクエストさ
れるように、データは返される。しかしながら、上位ノ
ードのデータベース内に、あるいは別のノードのいずれ
かに、データ要素が移動した場合、上位ノードは、その
データベースでその位置に今格納されるネームとリクエ
ストで渡されたネームとの間の不一致を検知する。レフ
ァレンスノードは、バインド情報が無効であると通知さ
れる。ダウンロード、削除あるいは他のデータベース生
成が上位ノードを通じて実行された場合、データ要素の
削除、ノード内データのデータベースの別の位置への移
動、あるいは異なるノードへのデータの移動によってバ
インド情報が無効になることはあり得る。これらの事象
のうちのいかなるものでもレファレンスノードが通知さ
れないで起ることがある。バインド情報が無効の場合、
レファレンスノードは、データ要素名の第１リクエスス
トに対する前述のステップに再び従って、ステップ２１
−２８に従う要素名を求めてネットワークの探索を実行
する。データ要素名が削除された場合、エラーメッセー
ジ２１−３２が返されるだろう。しかしながら、ステッ
プ２１−３４および２１−３６に従って、データ要素名
が、ノード内であるいは異なるノードへ移動させられた
場合、ネームは新しいバインド情報のついてタグを付け
られるだろう。新しいバインド情報およびデータ要素は
レファレンスノードに返されるだろう。上記の結果、ネ
ットワークは自己回復作用を行う。アドレスの変更が生
じた後、はじめてレファレンスが行われたとき、無効に
なるレファレンスが修正される。さらに、それが参照す
るデータ要素がダウンロードされる前に、レファレンス
ノードがダウンロードされる場合、ネームがダウンロー
ドされ、次に、それを見つけることができるまで、エラ
ーメッセージは返される。したがって、上記の発明に従
えば、はじめてデータ要素がリクエストされたときか、
あるいは、データ要素が移動させられた後はじめてそれ
がリクエストされたときネットワーク探索を行うだけで
よい。図２２は、上記に記述された方法のバリエーショ
ンを例示する。ネーム生成２２−５０後、ネームは、レ
ファレンスノードへステップ２２−５２でダウンロード
されることを、図２２−３は例示する。ステップ２２−
５４で、レファレンスノードはネームテーブルを生成す
る。レファレンステーブルは、データ要素のコピーを１
つだけ保持することによって、ノード内メモリの使用を
最適化するように構築することができる。その後、デー
タ要素を要求するレファレンスノードで、すべてのレフ
ァレンスおよびアプリケーションは、ＡＳＣＩＩ名より
少ないデータ・バイトしか典型的にリクエストしないレ
ファレンステーブル指標と取替えられる。したがって、
図２２のステップ２２−５４および２２−５６で示され
るように、ネームは１つの場所、レファレンステーブル
エントリだけで保持される。この方法で各々のレファレ
ンスノードが自身のネームテーブルを保持することに注
意すべきである。したがって、ステップ２２−５８の後
レファレンスノードがデータ要素を要求する場合、ステ
ップ２２−６０はこれがレファレンスノードによる最初
のリクエストがどうか決めるように実行される。それが
レファレンスノードによる最初のリクエストである場
合、図２２のステップ２２−６２から２２−７２が実行
される。これはネームがバインド情報およびデータを返
して発見された場合に要素名を求めてネットワークを探
索すること、および、ステップ２２−７２で示されるよ
うなレファレンスノードに作成されるテーブルにそのネ
ームを置くことを含んでいる。以前に議論したように、
エラーは処理されるだろう。ステップ２２−７４で、こ
れがレファレンスノードによる最初のリクエストでない
場合、データ要素の位置は、ホストに送られたネームテ
ーブルおよびリクエストから読まれる。その後、ネーム
はネームテーブルで指定される位置に上位ノードによっ
てネームと比較される。ステップ２２−７８での比較の
結果に基いて、データは要求するノードに返されるだろ
う。あるいは、ネットワークは要素名を求めて探索され
るだろう。レファレンスノード内で、それが、データ要
素を求めるリクエストが起こす、いかなるアプリケーシ
ョンあるいは特徴において重要ではないことに注意する
ことは重要である。一度バインディングがその要素への
１つのレファレンスに対して生じれば、それは、その要
素へのそのノード内のすべてのレファレンスに対して発
生する。これは、各々の場所に対して一度ずつレファレ
ンスがノードで発生する代わりに、バインディングがノ
ード内のすべてのレファレンスに対して一度だけ発生す
る必要があることを意味する。これは、ノードによって
すべてのレファレンスに対応する初期バインディングを
作るのに費やされる時間を縮小する。個別のレファレン
ステーブルが各ノードに対して構築されることも注意さ
れるべきである。したがって、データ要素の位置が上位
ノードの範囲内であるいは別の上位ノードに変更される
場合、はじめて、そのノードがデータ要素を要求すると
きに、レファレンステーブルを更新するプロセスが各レ
ファレンスノードによって繰り返されるだろう。図２３
は図２２に示される配置の一層の最適化を示す。ノード
がデータ要素に対する第１リクエストを行なったと仮定
して、バインド情報によって識別される位置のネーム
が、現在リクエストされているデータ要素のネームと比
較される。この場合、一致が生じなければ、ローカル探
索は、バインド情報によって識別されるホストの探索に
よって、ステップ２３−８２でまず実行される。これは
データ要素が同じホスト内に見つけられるからである。
これが生じた場合、バインド情報およびデータがレファ
レンスノードに返されるコントロールはステップ２３−
７０にパスする。しかしながら、これが生じなかった場
合、ネットワークの残りはステップ２３−６２からスタ
ートする探索が行なわれる。一層の実施例はデータ要素
が、要求するノード（つまり、上位ノードおよびレファ
レンスノードは同じノードである）と同じノードに格納
される場合にデータ要素へのレファレンスを求めてネッ
トワークを探索することを回避する。前述したように、
レファレンスネームテーブルは、レファレンスノードに
各ネームに対するエントリを含んでいなければならな
い。データがある場合にはこのノードから別のノードに
移動することもあるので、レファレンスノードおよび上
位ノードが同一でも、これは必要である。したがって、
たとえレファレンスノードがさらに指定される要素に対
して上位ノードでも、レファレンスノードのネームテー
ブルからエントリを削除することはできない。しかしな
がら、これらの状況になったときだけ、はじめてレファ
レンスノードがレファレンスノードがさらに上位ノード
であるデータ項目をリクエストしたときに、ネットワー
クの探索を削除することは、可能である。これは、要素
がダウンロードされる場合に、データベースソフトウェ
アおよび上位ノードにレファレンステーブルエントリを
加えることによって、達成される。上位ノードがデータ
要素を所有し、従って、バインディングを知っているの
で、テーブルエントリは正確なバインド情報を含んでい
る。同じノードの他のどこかから第１レファレンスが生
じた場合、バインド情報は、レファレンステーブル内に
すでにあり、追加探索はリクエストされない。したがっ
て、レファレンスノードによって頻繁に使用されるデー
タ要素をそのレファレンスノードにホストすることは有
利である。図２４はネームの複数のレベルを使用して、
一層の最適化テクニックを示す。例示されるように、ネ
ームの２つのレベルが示される。しかしながら、テクニ
ックは、指定する階層の任意の深さまで延長することが
できる。したがって、ネームの、小さなレベルおよびハ
イフンでつながれたレベルは使用することができる。各
々のレベルで、ディレクトリは次のより高いレベルまで
アクセスを可能にして、構成される。２レベルの名前づ
けスキームにおいて、各ネームは、２つの部分、すなわ
ち、グループ内のグループ名および要素名から成る。各
グループは、ネットワークにおいて１つのノードに割当
てられ、グループの範囲内で多くの要素を持ってもよ
い。第１ディレクトリすなわちグループディレクトリ
は、ネットワークのすべてのグループのディレクトリで
ある。ディレクトリは、各グループのネームをリスト
し、グループが駐在するノードを定義する。ネットワー
クの各ノードにグループディレクトリを保持しなければ
ならないので、グループディレクトリは、ネットワーク
内のすべてのノードに同報通信される。すべてのノード
がグループディレクトリの最新のコピーを保持するよう
に、グループの付加あるいは削除はネットワークのすべ
てのノードに同報通信されなければならない。ノードの
各グループに対して、ノードは、要素ディレクトリと呼
ばれるディレクトリの第２レベルを含んでいる。要素デ
ィレクトリは、そのグループの要素をすべてリストし、
グループの各要素のノードアドレスを識別する。グルー
プの要素が、グループあるいは要素ディレクトリを含ん
でいるノードに駐在する必要がないこと、また、すべて
の要素およびそのグループがネットワークの同じノード
にかならずしも駐在する必要がないに注意することは重
要である。もちろん、要素が加えられたりかグループか
ら削除されたり、１つのノードから別のノードに移動し
た場合は常に要素ディレクトリは更新される。図２４
は、ディレクトリがどのように使用されるか例示する。
ステップ２４−１００で示されるように、レファレンス
ノードがデータ要素にたいしてその第１リクエストを行
なっているかどうかが最初に決定される。ステップ２４
−１０２において、これが第１リクエストである場合、
レファレンスノードはグループディレクトリとグループ
名を比較し、グループノードを識別する。ステップ２４
−１０４において、一致が生じていない場合は、エラー
２４−１０６が示される。そして、事象のシーケンスが
終了する。ステップ２４−１０４での適切なオペレーシ
ョンを仮定した場合、一致が生じ、ステップ２４−１０
８でリクエストはグループディレクトリで身元確認され
たグループノードに送られる。グループノードのステッ
プ２４−１１０において、要素ディレクトリは要素がそ
のグループに現れるかどうかを決めるために、探索され
る。要素ディレクトリがデータ要素の位置を含んでいる
ので、一致がステップ２４−１１４で生じた場合、ステ
ップ２４−１１２でグループノードは要素ディレクトリ
から上位ノードアドレスを読み、ステップ２４−１１６
で上位ノードへのリクエストを転送する。ステップ２４
−１１８で、上位ノードはデータを得て、レファレンス
ノードにバインド情報およびデータを返す。したがっ
て、要素のネームの初期探索は、正しいグループに対す
る要素ディレクトリの探索が後続するグループディレク
トリの単作に探索される。ネットワーク全体を探索する
必要がない。しかしながら、ディレクトリは最新にして
おかなければならないし、グループディレクトリのコピ
ーをネットワークの各ノードに保持しなければならない
ことに注意すべきである。グループディレクトリが駐在
するノード上にだけ、グループの要素ディレクトリを保
持する必要がある。グループあるいは要素が加えられた
りか削除されたり、要素が移動させられたりした場合の
み、追加簿記が要求されるだけである。これは、そのよ
うな変更が生じた場合、レファレンスノードをすべてダ
ウンロードすることに比べれば相当に少ない仕事量であ
る。レファレンスノードのソフトウェアの実際のレファ
レンスが影響を受ける必要がない。以前に議論したよう
に、これがデータに対する第１リクエストでない場合、
バインド情報が読まれ、そのネームはバインド情報によ
って識別された位置に見つけられたネームと比較され
る。一致が生じない場合、バインド情報はもはや最新で
なく、適切な情報を位置指定するにシーケンスを再び実
行しなければならない。１つのアプリケーションにおい
て、ファシリティマネジメントシステムで上述の方法を
遂行することができる。ファシリティマネジメントシス
テムに対するこのアプリケーションは例を介したもので
あり、この発明に対して制限をくわえることを意図した
ものではない。図２０で、数個の実時間ネットワークコ
ントローラおよびネットワークコントローラ・ダウンロ
ードするためのデータベースを生成するために使用され
るパーソナルコンピュータは、ネットワーク２０−７に
相互に連結している。パーソナルコンピュータ２０−９
に付けられたディスクのような記憶手段２０−１１は、
ネットワークコントローラ２０−１、２０−３および２
０−５にダウンロードされるデータベースを含んでい
る。各ネットワークコントローラおよびパーソナルコン
ピュータはノードと考えることができる。ＮＣ２を上位
ノード３のネームであり、上位ノードがＡＨＵ１／ＦＡ
Ｎと呼ばれるデータオブジェクトあるいは要素を所有す
ると仮定しなさい。システム／オブジェクト名はシステ
ム名が上記の説明においてグループ名と同一であり、オ
ブジェクト名が特別のデータオブジェクトあるいは要素
のネームである場合にスキームを指定する２レベルであ
る。このオブジェクトは空気ハンドラ＃１に対するリタ
ーンファンである。２つの位置の１つに対してそれを制
御することができ、そのネームがネットワーク上でユニ
ークなので、これはバイナリ出力オブジェクトである。
“グループ”あるいはシステム名はＡＨＵ１および“要
素”である。あるいは、オブジェクトはファンである。
さらにそのＮＣ１がノード１のネームであり、レファレ
ンスノードであると仮定しなさい。これは、それがＦＡ
Ｎオブジェクトを参照する必要のあるいくつかのソフト
ウェア特徴を持つことを意味する。図２０に示されるよ
うに、特徴ＡはＦＡＮオブジェクトの現在地を読む必要
があり、特徴Ｂはファンを物理的に開始させるためにＦ
ＡＮオブジェクトにコマンドを送る。図に示されるよう
に、すべてのシステム名、グループディレクトリ２０−
２００、２０−２０２および２０−２０４のリストは、
各ノードに複写される。グループディレクトリは、どの
ノードが特別のシステムのためのオブジェクトのディレ
クトリ含んでいるかを識別する。ＡＨＵ１システムの場
合、オブジェクトのディレクトリはＮＣ２ノード２０−
３によって保持される。したがって、ＮＣ２、ノード２
０−３もＡＨＵ１システムのオブジェクトのディレクト
リ、および、それらがデータベースに位置指定されてい
る場所とを含んでいる。同様に、ＡＨＵ２システムに対
するオブジェクトはＮＣ３あるいはノード２０−５に位
置指定されている。以前に議論したように、パーソナル
コンピュータ２０−９を使用して、ユーザは、記憶ディ
スク２０−１１上にアーカイブされたファイル２０−１
３、２０−１５に置くことができ、ネットワークコント
ローラ２０−１、２０−３および２０−５にダウンロー
ドすることができるデータベースを生成する。特徴Ａお
よびＢからオブジェクトＡＨＵ１／ＦＡＮへのレファレ
ンスのようなレファレンスは、ダウンロードされる時、
ＡＳＣＩＩネーム形式で保持される。これはそれらが、
ネットワークコントローラに対応するデータベースがダ
ウンロードされた時にまだバインドされていないからで
ある。参照を付けるソフトウェア特徴は、データオブジ
ェクトＡＨＵ１／ＦＡＮの実際の物理的な位置に気がつ
かない。ダウンロードするに際して、オブジェクトは、
同じタイプのオブジェクトをすべて管理するデータ・ベ
ース管理プログラムに与えられる。ＡＨＵ１／ＦＡＮの
場合には、ＮＣ２のバイナリ出力マネジャーが使用され
る。オブジェクトデータ・ベース管理プログラムソフト
ウェアは、レファレンスネームテーブル中にネームを最
初に入力する。例えば、バイナリ出力オブジェクマネジ
ャーがダウンロード時にＦＡＮオブジェクトを与えられ
る場合、それは自身のバイナリ出力データベースにＦＡ
Ｎオブジェクトを入れて、レファレンステーブル２０−
３００にエントリを加える。このエントリは、ＡＨＵ１
／ＦＡＮオブジェクトおよびそのバインド情報のネー
ム、および、バイナリ出力データベース（レコード３）
における、オブジェクトタイプ（バイナリ出力）、上位
ノードアドレス（ＮＣ２）およびデータベース位置を含
んでいる。この例において、テーブルエントリは、図２
０に示されるようにオフセット１６に位置指定されてい
る。ＮＣ２以外の他のノードがバインド情報をこの時知
らないことに注意しなさい。これらのノードは、ＡＨＵ
１／ＦＡＮに対するネームレファレンスをまだ持ってい
るだけである。後のネーム探索が適切な場所でそれを見
つけるように、オブジェクトとＡＨＵ１のディレクトリ
は、さらに、ＦＡＮオブジェクトに対するレファレンス
テーブルを指定する。レファレンスノード２０−１、Ｎ
Ｃ１に対するデータベースもダウンロードされる。これ
はＮＣ１に対するレファレンステーブル内にエントリを
作らせる。特徴Ａに対するデータベースがダウンロード
されると、エントリがＡＨＵ１／ＦＡＮに対するレファ
レンステーブルに作られるが、これにはバインド情報が
ついていない。この“バインドされていない”レファレ
ンスは、ＮＣ１のある特徴がＦＡＮをレファレンスする
ことを単に示す。ハイレベルのソフトウェア特徴Ｂに対
するデータベースがダウンロードされると、特徴Ｂも、
テーブルにバインドされていないレファレンスを加えよ
うと努めるがそれがそこ（レファレンステーブル２０−
３０２のオフセット２７）にすでにあることを知る。そ
の後、両方の特徴は、ＡＨＵ１／ＦＡＮに対する名前付
きレファレンスを２７のオフセットと取替え、テーブル
の中へ入れる。この時点でもバインド情報がＮＣ１のテ
ーブルの中になおないことに注意しなさい。ハイレベル
のソフトウェア特徴Ａの実行は、ＮＣ１にＦＡＮオブジ
ェクトの値を読むことを要求する。バインディングが、
ＡＨＵ１／ＦＡＮに対するＮＣ１のレファレンステーブ
ル中にはまだないので、ソフトウェアはネットワークに
ＡＨＵ１／ＦＮＡを位置指定しなければならない。これ
はシステム名ＡＨＵ１を求めてシステム名リストあるい
はＮＣ１のグループディレクトリを探索することを要求
する。図２０に示されるように、リストは、ＡＨＵ１が
ＮＣ２に位置指定されていることを示す。したがって、
ソフトウェアはＮＣ２にリクエストを向ける。ＮＣ２
は、要素ディレクトリを使用して、そのデータベースに
オブジェクトを置く。これは、ＡＨＵ１のオブジェクト
のディレクトリ中のＦＡＮを調べることによって遂行さ
れる。図２０に示される例において、これは、ＮＣ２中
のレファレンステーブルのオフセット６に位置指定され
たバイナリ出力ポイントである。上述のように、この情
報がダウンロード時にそこに置かれたので、ＮＣ２のレ
ファレンステーブルは、ＦＡＮに対して加えられバイン
ド情報をすでに持っている。従って、ソフトウェアは、
このノード上に正確なデータ・ベース管理プログラム
（バイナリ出力）オブジェクトマネジャーにリクエスト
を送信し、正確なレコード（それはレコード３である）
を要求することができる。一度データが得られれば、情
報はバインド情報と共に特徴Ａ及びＮＣ１に渡される。
その時、ＦＡＮに対するレファレンステーブルエントリ
は、正確なバインド情報と共にノードＮＣ１に完成され
る。図２０は、さらにＮＣ２の特徴Ｃからのような、上
位ノードのレフィレンスに対して、データベースがダウ
ンロードされた後、バインド情報がレファレンステーブ
ル中にすでにあることを例示する。したがって、はじめ
てレファレンスがアクセスされたときでさえ、バインデ
ィング手続きはそれらのレファレンスに対して要求され
ない。バインド情報がネットワークコントローラＮＣ１
に提供されているので、ネットワークコントローラＮＣ
１からのその後のレファレンスは上記の手続きを繰り返
す必要がない。特徴ＢがＦＡＮを参照する必要があると
仮定した場合、レファレンステーブルにＦＡＮファンを
見つけるためには、格納されている２７のオフセットを
使用する。この時、バインド情報は、テーブル中にすで
にある。したがって、ソフトウェアは、ノードＮＣ２の
バイナリ出力データベースマネジャーにリクエストを直
接送信し、レコード３を要求することができよう。上述
の探索手続きはもはやリクエストされない。引き続いて
ＦＡＮを参照するＮＣ１上の他の任意の特徴レファレン
スファンはテーブル中の同じバウンドレファレンスを使
用する。したがって、バインディングは、ＮＣ１からす
べてのレファレンスに対して一度リクエストされるだけ
である。以前に議論したように、各ソフトウェア特徴
で、より長いＡＳＣＩＩ名が短いテーブルオフセットに
よって取替えられ、ただ１つのテーブルエントリだけが
その同じノードからすべてのレファレンスに対してクリ
エストされるので、レファレンステーブルはメモリ要求
を縮小する。図２５は、データ要素がノード内を移動す
る場合の事象のシーケンスを例示する。ＦＡＮがレコー
ド３からレコード５までＮＣ２のデータベース内を移動
すると仮定しなさい。これは、たとえば、パーソナルコ
ンピュータでのデータベースの再生成の結果として発生
する可能性がある。その結果、ＡＨＵ１／ＦＡＮがレコ
ード５まで移動したのに対して、レコード３がＡＨＵ１
／ポンプと呼ばれるオブジェクトに今度はなる。ネット
ワークコントローラ２５−２上のバイナリ出力データベ
ースマネジャーに直接行くべき、ネットワークコントロ
ーラ２５−１にによって使用されるバインド情報は、レ
コード３に対するリクエストを引起すだろう。しかしな
がら、レコード３で見つけられたネームと比較できるよ
うに、このリクエストも、ＡＨＵ１／ＦＡＮのネームを
送る。この場合、レコードはもはや一致しない。前述の
最適化の１つを使用して、バイナリ出力データベースマ
ネジャーはそれがオブジェクトＡＨＵ１／ＦＡＮをなお
持つかどうか理解するために、自身のデータベースを探
索する。この場合、それはレコード５で見つけられ、し
たがって、要求された情報は新しい正確なバインド情報
と共に返される。ＮＣ１は、それが使用していたバイン
ディングがＮＣ２によって修正されており、レコード３
に対するレファレンスをレコード５と交換することによ
って、そのレファレンステーブルを更新することを理解
する。したがって、オブジェクトはネットワークコント
ローラＮＣ２内を移動した。しかし、ネットワークコン
トローラＮＣ１は、ネットワークコントローラＮＣ１に
対する何の変更もなしでデータをなお見つけることがで
きた。更に、共通のレファレンステーブルエントリが更
新されるので、ネットワークコントローラ２５−１のレ
ファレンスはすべて修正される。ダウンロードの結果、
データオブジェクトが異なるネットワークコントローラ
に移動させられた場合、図２６は状況を例示する。この
場合、ユーザは、システムあるいは“グループ”ネーム
ＡＨＵ１を移動させるＮＣ２、およびＮＣ３に対するデ
ータベース、およびＮＣ３に対するそのオブジェクトを
生成した。今、ＦＡＮはネットワークコントローラＮＣ
３（ノード５）上のバイナリ出力データベースのレコー
ド７である。ここで、それがすでに持っているバインド
情報を使用して、ＦＡＮを参照しようとするネットワー
クコントローラＮＣ１の試みは失敗する。これはネット
ワークコントローラＮＣ２でのネーム比較、レコード３
が、ＡＨＵ１／ＦＡＮデータオブジェクトがそのアドレ
スにはもはやないことを示すためである。さらに、ＮＣ
２データベースの残る要素のチェックは、ＦＡＮを見つ
けることができないことを示す。したがって、ネットワ
ークコントローラ１の特徴Ａは、エラーメッセージを受
信する。ネットワークコントローラ２６−１は、そのテ
ーブルからのバインド情報を削除することによって、お
よび、ＡＨＵ１／ＦＡＮの新しい位置を見つけるために
上に議論された方法に従うことによって応答する。この
場合、それは、ネットワークコントローラ３のレコード
７で見つけられるだろう。共通のレファレンステーブル
が更新されるので、これを一度行うことは、ネットワー
クコントローラＮＣ１のレファレンスをすべて修正する
ことになる。もしデータ要素がネットワークから完全に
削除されていたとしたら、ネットワークコントローラＮ
Ｃ１は、忠告メッセージを介してＦＡＮを見つけること
ができないことをオペレータへ報告していたことだろう
ということは注意すべきである。ことことは、また、Ｆ
ＡＮが再びダウンロードされるまで、ＮＣ１からＦＡＮ
へのすべてのレファレンスに対して真実である。したが
って、ＡＨＵ１／ＦＡＮが再定義されるか、レファレン
スが削除されるまで、エラーは発生する。しかしなが
ら、ダウンロード後、レファレンスは、盤インドし適切
に作動し始めるだろう。従って、ノードダウンロードの
順序は重大ではない。Ｎ１バスで相互に連結したノード
間で適切な時間同期を提供するために、ノードの１つ
が、限定的システムマネジャーの役割を演ずる必要があ
る。図２７に示されるように、ノード２７−１は時間同
期装置（限定的システムマネジャー）として２７−２で
選択され、ノードは時間を定義し、Ｎ１バスで相互に連
結した他方のノードにこの情報を送信する。２７−３に
示されて、ノードは非更新間隔の間、時間をモニタす
る。決定ブロック２７−４は現在、再同期がセットされ
る時間かどうか決めるために、クロックをテストする。
そうでなければ、コントロールは２７−３に転送され、
時間モニタリングは係属する。ブロック２７−５におい
て、今ノード間で時間の同期を再設定する時であるとい
うことが決定ブロック２７−４において決定された場
合、ノードはそれがシステム時間マネジャーかどうか決
めるために、テストする。そうならば、コントロールは
２７−２を閉鎖するために転送される。また、システム
時間マネジャーは現在の時間を送信する。決定ブロック
２７−５において、それがシステムマネジャーではない
ことをノードが認識した場合、ブロック２７−６におい
て、ノードは、それが時間同期データを受信したかどう
か決める。そうならば、ノードはブロック２７−７にお
いてその時間をリセットし、ブロック２７−３でのよう
に、時間モニタリングは継続する。時間同期データがブ
ロック２７−６で受信されない場合、ブロック２７−８
のノードは、それがシステム時間マネジャーでありうる
かどうかを決め、そうならば、ブロック２７−２でのよ
うに時間を送信する。これは、オリジナルのシステム時
間マネジャーが障害を起こしたり、オフラインになった
場合、新しいノードが時間同期責任を引き受けることを
可能にする。ノード間で時間を同期させることに加え
て、グローバルなデータを同期させることも必要であ
る。図２８は、ダウンロードの基本ステップを示す。フ
ァンクションブロック２８−１において、グローバルな
データベースはネットワークの上に定義されロードされ
る。グローバルなデータベースは、パスワード、システ
ム名（オブジェクト名ではないが）のリスト、ノードの
リストおよびシステムにつながっているプリンタ、ユー
ザのある分類の忠告メッセージがどこに向けられている
かを示すリポートグループ、またすべてのノードに有用
な他の情報のような項目を含むことができる。ファンク
ションブロック２８−３は、各ノードがまた、アーカイ
ブ装置の中でそのノードに対して定義されるデータベー
スを持つことを示す。ノードデータベースは、ノードに
格納されるデータ、およびノードによって制御される他
の装置にＮ２バスを通じて送信される補足データを含ん
でいる。ファンクションブロック２８−５において、ノ
ードは、それにＮ１アドレスを与えることおよび不揮発
性メモリにそのアーカイブ装置の身元を格納することに
よって、ネットワークに構成される。ステップ２８−７
でのパワーアップに続いて、ノードはステップ２８−９
で他のノードと同期しなければならない。同期が完全か
どうかをステップ２８−１１はテストする。そうでなけ
れば、コントロールは同期プロセスを完成するためにフ
ァンクッションブロック２８−９に転送される。ノード
の同期の完成に際して、ノードが自身の特別のデータベ
ースをダウンロードするために、アーカイブ装置にアク
セスするファンクションブロック２８−１３に、コント
ロールは移る。各データ要素が受信されるので、情報が
Ｎ２バスで装置に送信されるかどうかを決定ブロック２
８−１５はテストする。送信されなければ、情報は、フ
ァンクションブロック２８−１７に示されるようなノー
ドに格納される。ファンクションブロック２８−１９に
示されるように、情報がＮ２ネットワークにつながる装
置に向けて予定されている場合、情報は装置までＮ２ネ
ットワークを通して渡される。図２９は、同期がどのよ
うに起るかをさらに例示する。パワーアップに際して、
ノードはＥＰＲＯＭ中のコードを実行し、ノードの不揮
発性メモリの中で定義されているノードのアーカイブ装
置を識別する。これはファンションブロック２９−１に
示されている。ファンクション２９−３に示されている
ように、ノードは、それから、そのＲＡＭの中へコード
をダウンロードするようにアーカイブ装置に要求する。
決定ブロック２９−５で、ネットワークに連結するノー
ドはそれがネットワークにつながる別のノードから同報
通信を受信したかどうか調べるテストをする。発明に従
って、ネットワークにつながるすべてのノードは、その
ノードのグローバルなデータベースの最新のバージョン
を示すタイムスタンプを周期的に同報通信する。したが
って、ネットワークに連結するノードがまだ決定ブロッ
ク２５−９に示されるような同報通信タイムスタンプを
受信してはいない場合、それが１つを受信するまで、ノ
ードは待つ。最初の同報通信タイムスタンプの受信に際
して、ネットワークに入るノードは、ファンクションブ
ロック２９−７に示されるようにタイムスタンプに関連
したノードからグローバルなデータを要求する。さら
に、新しいノードは、そのタイムスタンプとしてのグロ
ーバルなデータベース情報とともに、それが受信した時
刻を格納する。続いて、ファンクションブロック２９−
９において、ノードは以前に議論したように、自身の特
別のデータベースを得るために、アーカイブ装置にアク
セスする。そのデータベースを受信した後、新しいノー
ドは、ファンクションブロック２９−１１に示されるよ
うに、そのタイムスタンプを同報通信するとき、ネット
ワークの他のノードとつながる。データベースの同期
は、ファンクションブロック２９−１３に示されるよう
に他のノードからタイムスタンプを受信することによっ
て保持される。受信タイムスタンプがノードの現在タイ
ムスタンプより後である場合、ファンクションブロック
２９−１５および２９−１７に示されるように、ノード
は、あとのタイムスタンプを持つノードにグローバルな
データを要求する。利用できないグローバルなデータを
待ちながら、ノードがハングアップ状態になることも有
り得るということも注意すべきである。したがって、待
ちステップ２９−１９は時間終了決定ポイント２９−２
１に対してテストされる。ノードのオペレーションの保
留を回避するために、時間が終了した場合、ノードは、
ステップ２９−２３で示されるようなグローバルなデー
タを求めてアーカイブ装置にアクセスする。代替アプロ
ーチは、その第１スタンプの受信を待つことを回避する
ために、上述のようにネットワークとつながるノードを
許可する。このような代替方法によれば、ネットワーク
にジョインするノードは先ずアーカイブ装置にアクセス
してグローバルデータを得てこのグローバルデータのタ
イムスタンプをそのノードのタイムスタンプとしてアー
カイブ装置に記録する。次いでノードはネットワークに
ジョインし、そのタイムスタンプを周期的に送出すると
ともに先に述べたように他のノードのタイムスタンプを
検査する。スレーブ装置をＮ２ネットワークのノードに
よって制御しつつ同様のアプローチが用いられる。Ｎ２
ネットワークは、オンラインされるごとに、そのデータ
ベース更新レベルを、タイムスタンプとしてそのネット
ワークコントローラに送る。ネットワークコントローラ
が固有のタイムスタンプによって示される新しいデータ
を以ている場合には、ネットワークコントローラはその
情報（これはデータベースの一部である）を、Ｎ２ネッ
トワークにオンラインしつつある装置にダウンロードす
る。Ｎ２ネットワークにオンラインしている装置のタイ
ムスタンプによって示されるデータベース以外の最近デ
ータをネットワークコントローラが持っていない時に
は、ネットワークコントローラはＮ２装置が正しいデー
タベースを持っているものと判断する。第３０図は、ル
ーティングテーブルを持たない装置へのダウンロード情
報にアプローチする手法を示している。このアプローチ
は、複数の装置をカスケード接続して行なわれるもの
で、ルーティングテーブルを持たない装置への経路がル
ーティングテーブルを持つ装置を経由して達成される。
このようなアプローチ方法は、人が装置のおいてある場
所まで行って装置のダウンロード或いはアッブロードを
物理的に行なってやる事が望ましくないときに有用であ
る。この発明においては、レクエストを行なうネットワ
ークコントローラは、少なくともそのアーカイブ装置の
アドレスを、不揮発性メモリーの中に保持する。また、
各ネットワークコントローラは、このネットワークコン
トローラのためのダウンロードを開始するネットワーク
コントローラのアドレスを、その不揮発性メモリーの中
に保持する。このようにカスケード構造が用いられるこ
とにより、階層において上位のノードが、階層において
下位にあるノードよりも先に初期化される。二つのケー
スが可能となる。第３０図において、ダウンロード装置
３０−１は、ルーティングテーブルを持たないノード３
０−４として示されるネットワークコントローラ３につ
いてダウンロードを開始する事ができる。第３１図のテ
ーブル１は、アーカイブ装置またはＰＣのネットワーク
コントロール層によって遂行されるステップのシーケン
スを示している。各ノードが、そのネットワークを定義
するアドレス、ネットワーク上のローカルアドレス、お
よびノードのポートを有していることに留意することが
必要である。ノード自身にはポート０が割り当てられ
る。従って、ダウンロード装置３０−１は、アドレスと
して１：１：０を持つ。何故ならば、この場合、装置は
ネットワーク上１にあり、ローカルアドレスが１であ
り、また、装置自体がポート０としてテイギされている
からである。第３０図の表１からわかるように、メッセ
ージのソースは１：１：０であり、メッセージのあてさ
きは２：４：０である。また、ネットワーク中を伝達さ
れるメッセージの刻々のソース即ち仮ソースも表示され
る。オリジナルのソースにおいては、メッセージソース
と仮ソースとが同一のものとなる。即ち、最初の仮ソー
スは１：１：０である。第３１図の表に示される他の仮
ソースは先のものと同じネットワークならびにローカル
アドレスを持つ。ノードの、ネットワーク層（これは、
例えば、国際標準機構（Ｉｎｔｅｒｎａｔｉｏｎａｌ
Ｓｔａｎｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎ）のオ
ープンシステムインターコネクションモデル）中に定義
されたルーティングは、メッセージを、ネットワークが
１、ローカルアドレスが２、ポートが０のＮＣ１にルー
トする。表中のステップをたどると、メッセージをＮＣ
１次いでＮＣ２をとうしてルートすることによってダウ
ンロード情報がＮＣ３に到達するということが理解され
る。ＮＣ３は、メッセージを受け取ったことを示す確認
応答をソースに対して行なう。この場合、メッセージを
受ける装置はルーティングテーブルを持っていないの
で、メッセージをこの装置に対して送り込んだノードに
対して返答が行なわれる。確認応答は、このノードか
ら、メッセージの伝達経路を逆にたどるかあるいはルー
ティングテーブルを持つノードによって定義される適宜
の経路を経てソースに送られる。第２のケースにおいて
は、ネットワークコントローラ３がアーカイブＰＣ３０
−１に対してダウンロードリクエストを開始する。この
場合には、アドレス２：４：０に位置するノードＮＣ３
はそのダウンロードリクエストを送出するべきルーティ
ングテーブルを持たない。しかしながら、ＮＣ３は、前
に述べたように、このノードＮＣ３のためにダウンロー
ドを開始するべきネットワークコントローラのアドレス
をその不揮発性メモリーの中に保持している。したがっ
て、ＮＣ３は、そのリクエストをこのネットワークに送
ることができる。ＮＣ３は、アドレス１：１：０にある
データダウンロード装置（これは、ＮＣ３の中に、ＮＣ
３のアーカイブ装置として特定されている。）に対して
ダウンロードを要求する。このリクエストがたどるルー
トは、第３２図の表２からわかるように、アドレス２：
３：０にあるＮＣがＮＣ３に対するイニシエータである
ということを認識する。ＮＣ２は、メッセージをアーカ
イブ装置に送るために、すでにルーティングテーブルを
持っている。このことは、複数の装置をカスケード接続
することによってメッセージをアーカイブＰＣに受け取
らせることが出来るということを示している。これによ
り、上位のノード、例えばＮＣ２が、下位のノード、例
えばＮＣ３がダウンロードされ得る前に完全に機能化さ
れなければならないというような階層化が達成されると
いうことが理解されよう。同様に、ＮＣ３で現す別のノ
ードへのダウンロードは、ＮＣ３からのダウンロード
が、そのイニシエータであるＮＣ２を通じて完全に終了
するまでは行なわれない。ダウンロードか行なわれると
き、目標が存在するＮＣ以外のＮＣにシステムが定義さ
れるような他の複数の目標の存在によって問題が生じ
る。何故ならば、二つのＮＣの持つデータベースが相互
に矛盾しないものであるものであるとは限らないからで
ある。この矛盾は、定義がインターレースされたいくつ
かのＮＣが影響される際に自然に生じるものであるの
で、自動的に訂正することは出来ない。これらのＮＣの
更新すなわちダウンローディングを行なうためにはある
時間長が必要であり、その時間中に不可避的に矛盾が生
じる。しかしながら、全ての問題は検出されユーザーに
知らされる。ひとつのＮＣについてダウンロードが行な
われるとき、他の複数のＮＣはダウンロードが行なわれ
ているＮＣと矛盾するかも知れない。もしそのような条
件が存続するなら、あるいはまた、もし上記時間中にシ
ステムがいずれかのＮＣにアクセスを行なうならば、エ
ラーやあいまいさが生じる。目標がひとつのＮＣから別
のＮＣに移された時に生じる問題の例を以下に示す。し
かし、結果的なデータベース不整合性は同じであろう。
次の仮定がなされる ａＮＣ１は、システムＳに対するディレクトリを含んで
いる。 ｂＮＣ２は、オブジェクト０のオリジナルのバージョン
を含んでいる。 ｃＮＣ３は、同じオブジェクト０の新しいバージョンを
含んでいる。 正常なケースは、ＮＣ３の代わりにデータベースにオブ
ジェクト０を加えて、ＮＣ２からそれを削除することで
ある。これは、テンプレート生成（単一のオブジェクト
変更）を通じて、あるいはＤＤＬ（データ定義言語）を
介してのいずれかで行うことができる。いずれの場合に
も不整合性は発生する可能性がある。ＤＤＬがこの変更
に使用されると仮定しなさい。その場合、３つのＮＤＤ
Ｌファイルをトランザクションを完成するために更新す
る必要がある（Ｎ１、２および３）。その後、各々のＮ
Ｃをダウンロードしなければならない。しかしながら、
ダウンロードの１つ以上はスキップすることができよ
う。あるいは、結果的にフィールドにおいて一貫しない
ＮＣになる、不正確にダウンロードされた古いデータベ
ースはスキップすることができよう。テンプレート生成
変更が失敗するか、何らかの理由のために途中で遮断さ
れる場合、類似した問題が発生することがある。次の場
合は、発生する可能性がある不整合性を実証する。上記
の変更が行なわれた後に、ＮＣ１が最初にダウンロード
されたと仮定しなさない。その場合、Ｓに対するシステ
ム・ディレクトリは、オブジェクト０がＮＣ３に駐在す
べきであることを示すだろう。ＮＣ３がダウンロードさ
れる（仮にそれがダウンロードされたとして！）まで、
ディレクトリが「それはＮＣ３にあるべきである。」と
言うのでオブジェクト０は見つけることができない。こ
れが第１の問題のケース、つまり、そこにないオブジェ
クトを指定しているディレクトリ、である。バインドさ
れたレファレンスは、ＮＣ２の中の古いオブジェクト０
を今のところ使用し続けるだろうということに注意しな
さい。ディレクトリが新しいバインディングに対して必
要であり、それが存在しないオブジェクトを指定するの
で、新しいバインディングを遂行することができない。
ＮＣ２が次にダウンロードされるとさらに仮定しなさ
い。オブジェクト０の古いバージョンが今度は削除され
るので、古いバインディングさえも失敗するという付随
的問題に関して上記の問題と同じ問題をこれは引き起こ
す。ＮＣ３がダウンロードされるまで、オブジェクトは
存在しない。ＮＣ２が最初にダウンロードされると今度
は仮定しなさい。Ｓに対する古いディレクトリがオブジ
ェクトをもはや含んでいないＮＣ２を依然として指定し
ているので、これは再び同じ問題である。現行のバイン
ディングは無効になり、新しいバインディングは作るこ
とができない。ＮＣ２がダウンロードされた後、次にＮ
Ｃ１がダウンロードされたとさらに仮定しなさい。同じ
問題は再び発生する、なぜならディレクトリが、新しい
オブジェクトでまだダウンロードされていないＮＣ３を
指定しており、古いオブジェクトはなくなっているから
である。今度は、ＮＣ３が最初にダウンロードされると
仮定しなさい。このダウンロードの結果、フィールドに
オブジェクト０の２つのコピーがある。これは、発生す
る可能性のある第２問題、すなわち複数のＮＣにおいて
同じネームをもつ重複オブジェクトを実証する。以前に
議論された古いネームバインディングは、ＮＣ２の中で
０の古いバージョンを使用し続けるだろう。ディレクト
リがなお更新されないので、新しいバイディングは、さ
らにＮＣ２に行くだろう。ＮＣ１がダウンロードされる
まで、０の新しいバージョンをアクセスすることはでき
ない。これは“孤児のオブジェクト”と呼ばれる。−そ
のネームがディレクトリにないので、これはアクセスす
ることができない。ユーザがオブジェクトのこのバージ
ョンを調べたり、変更したり、あるいは削除することさ
えする方法はない。これは、第３問題が発生することが
ありうることを実証する。ＮＣ３がダウンロードされた
後、ＮＣ１がダウンロードされるとさらに仮定しなさ
い。今、なお重複オブジェクト０があるが、０の両方の
コピーに特徴を結びつけることができる。ＮＣ２にオブ
ジェクトをなお見つけることができるので、０に対する
古いバインディングはなお有効である。しかし、新しい
オブジェクトがディレクトリにあるので、新しいバイン
ディングがＮＣ３に行くだろう。したがって、例えば、
以下に議論されるように、ハイレベルの特徴にあるタス
クを再集中させる事象トリガならば同時に両方のコピー
からサインアップし、受信することができよう。オブジ
ェクトタイプの０が変更されていない場合、両方のトリ
ガは、受信タスクによって有効であると考えられるだろ
う。これは問題２（重複オブジェクト）のバリエーショ
ンである。（今や、バインディングは両方のバージョン
に対して行うことができる。）他のシナリオも同じ問題
に帰着する。すなわち、ＮＣ２をダウンロードし、その
後でＮＣ３をダウンロードする、またはその逆は、ＮＣ
２に存在しないオブジェクト、また、ＮＣ３に孤児のオ
ブジェクトを指定するディレクトリをＮＣ１に作ること
に帰着する。要約すると、この場合、次の問題がダウン
ロード後に発生する可能性がある： ａノードのディレクトリが存在しないオブジェクトを指
定することがある。 ｂ孤児のオブジェクトはアクセスすることも削除するこ
ともできない。−オブジェクトを指定するディレクトリ
がない；また、 ｃ重複オブジェクトが発生することがあり、バインディ
ングがオブジェクトのいずれのコピーに対しても起こり
得る。 これらのダウンロード上の問題は自動的に修正すること
ができない。なぜなら、ソフトウェアには、ダウンロー
ドの順序で、ユーザがどこにいるか知ることができない
からである。つまり、ソフトウェアは、ＮＣデータベー
スが今どのように見えるか、すなわち、ダウンロードが
いつ完成されるか決めることができないからである。し
かしながら、この問題を検出することはできる。すなわ
ち、オペレータは以下のように警報を受けることができ
る。次の定義を仮定しなさい。すなわち、 ディレクトリＮＣ：システムＳに対するディレクトリを
含んでいるＮＣあるいはノード オブジェクトＮＣ：システムＳにディレクトリを含んで
いるＮＣあるいはノード 「ここに、私はいる」メッセージ：オブジェクトが存在
すること、オブジェクトがどこで見つけられるか、およ
びそのタイプを示す、オブジェクトによってそのディレ
クトリＮＣに送られるメッセージ。 「そこにあなたはいますか」メッセージ：オブジェクト
に応答するよう要求する、ディレクトリによってそのオ
ブジェクトの一つに送られるメッセージ。（オブジェク
トが正しいＮＣにあり、正しいタイプかどうか決めるた
めに）。不整合性はダウンロードから通常発生するの
で、上記エラーが入り込むと、次のシナリオが上記エラ
ーをキャッチする。オブジェクトＮＣはそのディレクト
リＮＣがオンラインになるのを見る。（この場合、２つ
のＮＣが同期していない可能性がある。なぜなら、他方
がオフラインであった間に一方のＮＣに変更が行なわれ
た可能性があるからである。したがって、ディレクトリ
を再同期することが必要である。「ここに、私はいる」
メッセージをそのディレクトリＮＣへ送る、オンライン
になったＮＣ上にあるディレクトリを持つ各オブジェク
トによってこれは行われる（グローバルなシステム・デ
ィレクトリデータベースによって定義されるように）。
これは、この問題の中の２つをキャッチする。第１に、
ディレクトリＮＣがそのディレクトリにオブジェクトを
見つけないので、それは孤児のオブジェクトをキヤッチ
する。それから、それはユーザにエラーを報告すること
ができる。第２に、重複オブジェクトが両方とも同じデ
ィレクトリに報告しようとするので、それは重複オブジ
ェクトをキャッチする。しかしながら、ディレクトリは
一度にオブジェクトの一方しか指定できないので、一つ
は孤児にならなければならない。再び、ディレクトリＮ
Ｃのディレクトリマネジャーはエラーをユーザに送るこ
とができる。内部で報告するオブジェクトがディレクト
リによって決定されるような適切なオブジェクトタイプ
であることを保証するために、さらに、チェックもオブ
ジェクトタイプに対して行なえるであろう。 第２の場
合、ディレクトリＮＣはオブジェクトＮＣがオンライン
になるのを見る。この場合、ディレクトリからそのオブ
ジェクトへ「そこにあなたはいますか」メッセージを送
ることによって、オブジェクトの存在を求めるチェック
を行なう。もしオブジェクトがそこにない場合、オブジ
ェクトが答えないので、ディレクトリは、存在しないオ
ブジェクトを指定するエラーをキャッチする。再び、オ
ブジェクトタイプをクロスチェックすることもできよ
う。第３場合、ディレクトリＮＣは、オブジェクトＮＣ
が（あるいはこの逆もまた同じだが）オフラインになる
のを見る。２つの間の通信が確率できるまで、ここでは
ほとんど何も行うことができない。第４場合、オブジェ
クトＮＣは、ディレクトリＮＣがダウンロードされるの
を見る。これはオンラインの場合と同じに処理される。
オブジェクトは、ダウンロードが何かを変更したかどう
か決めるために、「ここに、私はいる」メッセージを送
る。第５場合、ディレクトリＮＣは、オブジェクトＮＣ
がダウンロードされるのを見る。これは第２の場合と同
一である。「そこにあなたはいますか」メッセージがオ
ブジェクトがそこにまだいるかどうかを決めるために送
られる。要約すると、「ここに、私はいる」メッセージ
は、ディレクトリとオブジェクトＮＣ間の関係が使用さ
れるかもしれないし、されないかもしれない時に、重複
および孤児のオブジェクトをキャッチするために、使用
される。「そこにあなたはいますか」メッセージは存在
しないオブジェクトをキャッチする。なぜなら、存在し
ないオブジェクトはレファレンスが生じたとき、レファ
レンスによってキャッチされるから。ノードのディレク
トリマネジャータスクは解決の両半分の実行に責任を負
う。ディレクトリマネジャータスクはレファレンス識別
（ＲＩＤ）テーブルを保持する。したがって、このテー
ブルは、ＮＣ上で定義され、ディレクトリＮＣがオンラ
インになったときなどに、このリストによって走ること
ができるオブジェクトをすべて知っている。それは「こ
こに、私はいる」メッセージを、その一方のＮＣにある
システムを有するすべてのオブジェクトに対して送る。
必要な場合、それは、自分が所有しているディレクトリ
によって走り、「そこにあなたはいますか」メッセージ
を、一方のＮＣに駐在するように定義されているすべて
のオブジェクトに対して送ることができる。さらに、デ
ィレクトリマネジャーは、他端でこれらのメッセージ両
方を受信する。「ここに、私はいる」は、オブジェクト
が当然いるはずの場所にいるということを確認するため
にディレクトリをチェックするディレクトリマネジャー
に送られる。「そこにあなたはいますか」メッセージ
も、そのオブジェクトを求めてＲＩＤテーブルの中を調
査するオブジェクトＮＣのディレクトリマネジャーのと
ころまで行く。システムおよびオブジェクトが異なるＮ
Ｃにある場合、このリンクチェックを行う必要があるだ
けである。不整合性は単一のＮＣ内では可能ではない。
不整合性が存在するとすれば、それは中断されたテンプ
レート生成トランザクションのためである。その場合、
ユーザはトランザクションが中断された時にエラーを出
すことができるので、問題が存在していることを知らさ
れる。１つのＮＣが別のＮＣがオンラインにあるとか、
ダウンロードされているということを認識する方法は、
トリガ処理と同じに行なわれる。ノード状態メッセージ
は、上記の処理が生じることが可能なディレクトリマネ
ジャーにそのメッセージを配達するノードマネジャーに
送られる。一方のＮＣをもう一方のＮＣより前にダウン
ロードしなければならないので、１つのポイントおよび
そのシステムが異なるＮＣにある場合、エラーメッセー
ジは避けられない。たとえユーザが良心的にすべての影
響を受けたＮＣをダウンロードしたとしても、このこと
は発生するだろう。しかしながら、そのような場合（分
離オブジェクトおよびディレクトリ）の数は典型的にほ
とんどない。また、オブジェクトが１つのＮＣから別の
ＮＣに移動させられた場合に限り、これが発生する可能
性は最も大きい。ファシリティマネジメントシステムに
おいては、必要とされるデータ値が、ある間隔で繰返し
て読まれるポーリングタイプアプリケーションを値が変
るときアルゴリズムを実行するだけの事象に基いたスキ
ームと交換することが望ましい。これはいつデータが変
ったかということを認識すること、およびトリガできる
オブジェクトあるいは特徴にデータの変更を関連させる
ことを要求する。分散環境においては、データベースが
互いとは別個に変更されるかもしれないので、データの
所有者およびユーザが個別のノードあるいはプロセッサ
にいるかもしれないことは認識されなければならない。
サインアップメカニズムを取り入れることにより、特定
のデータあるいはデータ要素を含んでいるノードに、特
定のデータあるいはデータ要素が変る場合は常に、その
特徴を知らせるように要求することが、特定のデータを
必要とする特徴に可能になる。その結果、ポーリングは
もはやリクエストされない。しかしながら、分散環境に
おいては、指定されるデータを含んでいるノードは、結
果的にサインアップリクエストの損失になる新しいデー
タベースのダウンロードを経験するかもしれない。デー
タが１つのネットワーク・ノードから別のネットワーク
に移動する場合にも同じ問題が発生する。したがって、
ノードがデータベース生成あるいはダウンロードによっ
て更新される場合、サインアップする特徴を通知しなけ
ればならない。以前に議論したように、各ノードは、そ
の最も最近のデータを示すタイムスタンプを周期的に送
信する。したがって、ノードがオフラインであるかある
いは新しいデータでダウンロードされるかが検知される
場合、サインアップ特徴はそのサインアップを無効に
し、新しいデータベースで新しいサインアップを試みる
だろう。これが可能でない場合、以前に議論されたバイ
ンディングスキームが、データが今どこに位置している
かをサインアップ特徴に決めさせる。もちろん、データ
がもはや利用可能でない場合、サイン−アップは可能で
はない。その結果、ポーリングはもはやリクエストされ
ない。しかしながら、分散環境においては、指定される
データを含んでいるノードは、結果的にサインアップリ
クエストの損失になる新しいデータベースのダウンロー
ドを経験するかもしれない。データが１つのネットワー
ク・ノードから別のネットワークに移動する場合にも同
じ問題が発生する。したがって、ノードがデータベース
生成あるいはダウンロードによって更新される場合、サ
インアップする特徴を通知しなければならない。以前に
議論したように、各ノードは、その最も最近のデータを
示すタイムスタンプを周期的に送信する。したがって、
ノードがオフラインであるかあるいは新しいデータでダ
ウンロードされるかが検知される場合、サインアップ特
徴はそのサインアップを無効にし、新しいデータベース
で新しいサインアップを試みるだろう。これが可能でな
い場合、以前に議論されたバインディングスキームが、
データに今どこに位置しているかを決めるために、こと
を可能にする。もちろん、データがもはや利用可能でな
い場合、サインアップは可能ではない。事象トータリゼ
ーションを含むいくつかの特徴あるいはユーザによって
プログラムされ、カスタマイズされた特徴を働かせるた
めに、トリガサインアップを使用することができること
に注意すべきである。同様に、さらにサインアップはそ
のようなスクリーンの間隔的リフレッシュというよりは
むしろマンマシンインタフェーススクリーンのリフレッ
シュを行なうために、使用することができよう。これに
より、変数あるいはデータの状態の変更をユーザに対し
て即時に通告することが可能になるだろう。図３３はそ
のプロセスを例示する。ブロック３３−１に示されるよ
うに、特徴は、システムでデータ要素と命名されたオブ
ジェクトによるトリガのためのサインアップを行なう。
ブロック３３−２において、ノードのプロセッサは、オ
ブジェクトがネットワークに在るかどうかチェックす
る。ブロック３３−３においてそうでなければ示される
ように、特徴は新しいネットワークコントローラ（Ｎ
Ｃ）が加えられるようになるかどうか決めるために、ネ
ットワークをモニタし始める。ブロック３３−４に示さ
れるように、新しいＮＣが検知された場合、特徴はトリ
ガできるオブジェクトに対して新しいＮＣをチェック
し、ブロック３３−２において処理を繰り返す。オブジ
ェクトが在ることを特徴が決めた場合、特徴はブロック
３３−５に示されるように新しいデータがＮＣにおいて
オブジェクトとともにダウンロードされるかどうか決め
るテストをする。このケースの場合、特徴は、ブロック
３３−１においてそのサインアップを繰り返す。このケ
ースでない場合、ブロック３３−６に示されるように、
特徴は、オブジェクトのトリガできる属性をモニタす
る。ブロック３３−７は、属性の状態に対する変更が特
徴（ブロック３３−８）にトリガを送ることを示してい
る。特徴がトリガを受信しても受信しなくても、特徴
は、ブロック３３−５で始まる処理を繰り返す。これに
よって、特徴はオブジェクトを持つノードに対して新し
いデータのダウンロードを認識することが可能になり、
その結果それがトリガされるべく再びサインアップでき
るようになる。ステップ３３−２の繰り返しによって、
特徴は、ネットワークに再配置されるトリガできるオブ
ジェクトを拾い上げることができる。発明に従って、ネ
ットワークコントローラのグローバルなデータは、シス
テム処理の間作成される様々なリポートの宛先を識別す
る。システムは、ターゲットのユニークなリストととも
にいくつかのタイプのリポートを産み出す。例えば、リ
ポートは重大なタイプ（１−４）保守（再調査）および
状態よりなることもある。さらに、ポイント履歴リポー
ト、トータリゼーションリポート、傾向リポートおよび
取引ログあるいはトレースリポートが作成される。もう
一つの要求はファシリティマネジメントシステムの重大
なタイプリポートがすべて、リポートタイプに対して定
義されるターゲットの少なくとも１つに渡されるまで、
保持されることである。リポートルーティングを容易に
するために、与えられたノードから出されるリポートは
すべて、様々なハードコピー装置、コンピュータファイ
ルおよび他の記憶要素に対して最終的に分散されるよう
に特に設計されるリポートルータタスクに送られる。図
３４に示されるように、ポイント３４−１が変る場合、
メッセージは通信タスク３４−２３を通じてネットワー
クコントローラ３４−５のレポートルータ３４−３へ送
られる。リポートルータ３４−３は、メッセージがその
推奨宛先、ネットワークコントローラ３４−９のコント
ロールの下にあるプリンタ３４−７へ送られるべきであ
ることを決める。これは、Ｉ／Ｏタスク３４−１１に状
態情報の変更を送るリポートルータ３４−３によって推
敲される。リポートルータ３４−３は、さらにメッセー
ジのコピーを保持する。プリンタ３４−７がメッセージ
を印刷する場合、通告はリポートルータ３４−３に送ら
れる。また、コピーが削除される。他方では、プリンタ
３４−７がオフラインか、他のなんらかの理由のために
メッセージを印刷することができない場合、Ｉ／Ｏタス
ク３４−１１はリポートルータ３４−１３（それらは、
宛先プリンタと同じネットワークコントローラで利用可
能なリポートルータである）に通知する。リポートルー
タ３４−１３がディフォルト装置を位置指定できない場
合、メッセージは廃棄される。リポートルータ３４−３
はリポートルータ３４−１１あるいは３４−１３からメ
ッセージを受信しない。したがって、リポートルータ３
４−３は、状態の変更を示さないことによって情報が格
納されていないか印刷されていないことを示す。その
後、リポートルータ３４−３は、メッセージのそのコピ
ーを保持する。一方、リポートルータ３４−１３が、リ
ポートルータ３４−１９に対してネットワークコントロ
ーラ３４−１７に接続されるプリンタ３４−１５のよう
なディフォルト装置を位置指定する場合、レポートルー
タ３４−１３がプリンタ３４−１５へ伝送するのために
ＩＯタスク３４−２１へのメッセージのルートを定め
る。 ディフォルト装置が作動しない場合も、メッセー
ジは廃棄され、メッセージはまったく、リポートルータ
３４−３に返されず、リポートが印刷も格納のされなか
ったことが示される。その後、リポートルータ３４−３
は、そのセーブファイルにそのメッセージのコピーを保
持する。プリンターがオフラインになっている場合、す
べてのプリンタルータに通告される。セーブファイルが
あるメッセージを含んでいる場合、そのメッセージは再
び特定の装置にルートを定められる。万一セーブファイ
ルがいっぱいの場合、最も低い優先権および最も古いメ
ッセージはセーブファイルから取除かれ、エラーがシス
テムに記録される。図３５および３６は、リポート要約
を生成するための分散形フィルター処理を例示する。リ
ポート要約は、オブジェクト名およびある選択基準に基
いて生成される。１つのアプローチは、要約を受信すべ
きリモート装置に各オブジェクトディレクトリを検索さ
せ、それからディレクトリで識別される各オブジェクト
に対するレコードを検索させることである。その後、リ
モート装置は、その要約の基準を満たすレコードだけを
保持する。しかしながら、これはノード間での処理と通
信のためのかなりの量を要約するだろう。したがって、
特別興味のあるオブジェクトディレクトリが位置指定さ
れているノードでのデータの局所化されたフィルタリン
グ（たとえばフィルタータスク３５−１１）が望まし
い。図３５に示されるように、特徴３５−１およびノー
ド３５−３はＰＣ３５−５にデータ要約を送信すること
を要約するかもしれない。しかしながら要約を構築する
のに必要とされるオブジェクトはシステムの至る所に散
在しているかもしれない。オブジェクトディレクトリは
３５−９に示されるＮＣ２に位置指定されたディレクト
リ３５−７である。図３６に示されるように、特徴３５
−１は、オブジェクト名とファンクションブロック３６
−１での選択基準を指定する指令を生成する。ファンク
ションブロック３６−５において、オブジェクトディレ
クトリ３５−７は３５−９で示されるネットワークコン
トローラ２に位置指定されている。ステップ３６−３
で、オブジェクトディレクトリはノード位置から読まれ
る。そして、同じシステムとオブジェクト名を持つレコ
ードおよび属性の数が記録される。オブジェクトディレ
クトリ３５−７を使用して、オブジェクトは、ＮＣ１、
ＮＣ２、ＮＣ３およびＮＣ４のネットワーク制御ノード
から検索される。ステップ３６−９において、オブジェ
クトが検索される場合、ステップ３６−１で生成された
指令に含まれる選択基準が適用される。ステップ３６−
１１で示されるように、もし基準が満たされない場合、
要素は廃棄されるのにたいして、基準がファンクション
ブロック３６−１３において満たされた場合には、属性
はメッセージバッファｉｎ格納される。属性がすべて評
価されたかどうかは、決定ブロック３６−１５がテスト
する。もし評価されなければ、選択基準は次の属性に適
用される。属性がすべて評価された場合、要求された属
性を持つメッセージブロックの形で要求ノード３５−１
に単一のメッセージを送信するために、メッセージが生
成される。例示目的のために、図３７においてシステム
１はノード３７−３、３７−５、３７−９および３７−
１１を持つ、ファシリティマネジメントシステム（ＦＭ
Ｓ）でありうる。これらのノードは、ビルディングや、
工業上および環境上のセキュリティおよび他の自動シス
テムコントロールに関連するデータを処理するネットワ
ークコントローラとして機能する。例となるノード３７
−３が示すように、各々のそのようなノードすなわちネ
ットワークコントローラは少なくとも１つのプロセッサ
３７−２、メモリ３７−６および機器インタフェース回
路３７−８を持つ。そのような機器インタフェース回路
は、ノードへの直接的第２次的通信を使用するインタフ
ェースを含む（もっともこれに限定されるわけではない
が）、多数の機器相互接続配置を接続してもよい。オペ
レーションにおいては、ネットワークコントローラ３７
−３は、空気フローセンサー３７−１０および温度セン
サー３７−１２からの測定値を、また応答においては、
ダンパー３７−１４の開閉をモニタすることができよ
う。しかしながら、そのようなＦＭＳシステムにこの発
明のアプリケーションは少しも制限されず、多数のタイ
プのネットワークされたシステムが、この発明から利益
を得ることができることは、理解される。システム３７
−１において、ネットワークコントローラ３７−３およ
び３７−５は第１通信リンクによって接続される。第１
の通信リンク３７−４は、ゲートウェイ３７−７に吹け
られたネットワークコントローラ３７−９および３７−
１１を持つ第２通信リンク３７−１７を介して接続され
る。通信リンク３７−４および３７−１７に付けられた
ノードは個々ネットワークを形成するために考慮するこ
とができる。ネットワークにつながっているノードすな
わちネットワークコントローラの数とシステムにつなが
っているゲートウェイによって相互に連結しているネッ
トワークの数は、システムの要求と能力のファンクショ
ンである。本発明の原理が、任意の数の通信リンクにつ
ながっている任意の数のノードあるいは任意の数のネッ
トワークコントローラの適用され、この点では無制限で
あることが理解される。図３７のルーティング規定に従
って、各ノードはネットワーク・アドレスによって識別
される。ネットワーク・アドレスの要素は少なくとも３
つのフィールドを含んでいる。すなわち、第１に、サブ
ネットと呼ばれる通信リンクの識別子、第２に、通信リ
ンクあるいはサブネットにつながるノードの構内アドレ
ス。例えば、ノード３７−９はサブネット２にあり、構
内アドレス１である。ネットワーク・アドレスの第３フ
ィールドはドロップＩＤと呼ばれ、装置が落されるノー
ドのポート番号である。図３７において例示されるよう
に、各々の個々の構成ノードはそれ自身ドロップＩＤ０
である。ラップトップコンピュータのような非構成装置
あるいは他のデータ装置はノードの番号を付けられたポ
ートに接続することができるしあるいは落すことができ
る。ここに、本発明がノードポートの任意の数を提供
し、そのようなノードポート能力に限界を適用しないこ
とが、再び理解される。非構成ラップトップコンピュー
タ３７−１３のポートはノード３７−３のように、ノー
ドからポートに接続することができ、ネットワーク・ア
ドレスを割当てられている。例えば、非構成ラップトッ
プコンピュータ３７−１３のポート２がサブネット１構
内アドレス１であるノード３のポート３（ドロップＩＤ
３）に接続される場合、第３７図に示されるように、ラ
ップトップ３７−１３のネットワーク・アドレスは１：
１：３である。ラップトップコンピュータ３７−１３の
ポートがネットワーク・アドレスの一部ではないという
ことに注意すべきである。図３７はさらに、別のラップ
トップコンピュータ３７−１５は元来構成されるような
ネットワークの一部でありうることを例示する。ネーミ
ング規定に従って、そのような装置は追加サブネットに
つながる追加ノードと識別され、この場合、サブネット
３、構内アドレス１、ドロップＩＤ０である。最終的
に、便宜上、ネーミング規定は装置のプロセスの識別子
をさらに追加することを可能にする。もっともこれは要
求されるものではないが、唯一の要件はサブネット、構
内アドレスおよびドロップＩＤがネットワーク・アドレ
スのフィールドに含まれることである。そのようなプロ
セス識別子は、メッセージのソースであり、それは応答
を通常受信する装置のプロセス、およびメッセージの宛
先であり、それは応答を通常生成する装置のプロセスを
識別する。図３８において例示されるように国際標準化
機構のオープンシステム相互接続アーキテクチャあるい
は他の任意の便利なアーキテクチャからネットワークお
よびデータリンク層のような層を処理する、任意の組合
せにノードすなわちネットワークコントローラを組織す
ることができるということを理解すべきである。発明に
従って、非構成装置が構成ノードのポートへ付けられる
場合、非構成装置は、ポート上にその存在を確立する。
他の構成ノードからメッセージを受信する場合、それが
宛先ノードである場合、構成ノードは、サブネットおよ
び構内アドレス宛先からメッセージ部分を最初に決定す
る。宛先ノードでなければ、メッセージは、ルートによ
って定義され、次の固有の構成ノード上へ渡される。宛
先で、構成ノードは、メッセージが自身に対するもの
（ドロップＩＤ０）であるか、あるいは付けられた非構
成装置（ゼロでないドロツプＩＤ）に対するものである
かを決めるために、受信メッセージのドロップＩＤを評
価する。図３９は、ネットワークを通じて別の装置と通
信しようと努める非構成ラップトップ３７−１３上のプ
ロセスによる生成およびメッセージの伝送を例示する。
ブロック３９−３０１に示される通信リクエストを始め
るために、初期設定位相は、非構成装置がネットワーク
上でその位置を確立する場所を最初にとる。非構成装置
３７−１３は、それが取り付けられたノード（この場合
ノード３）、あるいはＦＭＳネットワークコントローラ
にアドレスを要求するメッセージを送信する。ノードあ
るいはＦＭＳネットワークコントローラは、サブネッ
ト、構内アドレスおよび非構成装置へドロップＩＤを含
むネットワーク・アドレスを送る、初期設定タスクの起
動によって、答える。その後、非構成装置は、そのネッ
トワーク・アドレスとしてのこの情報を格納する。ファ
ンクションブロック３９−３０３において、非構成装置
はこのアドレスにアクセスし、それが生成するメッセー
ジのソースアドレス・ポーションとしてそれを使用す
る。これらのメッセージはソースアドレスおよび宛先ア
ドレスの両方、および送信すべきデータまたはデータリ
クエストを含んでいる。例として、非構成ラップトップ
３７−１３が構成ラップトップ３７−１５に記録される
ダンパー３７−１６の状態に関するデータをリクエスト
したと仮定しなさい。ファンクションブロック３９−３
０５において、メッセージを送信するノードのプロセッ
サは、リクエストが、別のノードに遠隔に位置指定され
たプロセスに対するものか、あるいはこのノードのロー
カルプロセスに対するものであるかどうかを決める。そ
うでなければ、ファンクションブロック３９−３０７に
示されるように、リクエストはローカルプロセスに渡さ
れ、出口３９−３０９が得られる。リクエストが別のノ
ードのプロセスに対するものである場合、ブロック３９
−３１１は、ソースおよび宛先ネットワーク・アドレス
が有効かどうか決める。これは、ノードのネットワーク
処理層３８−２０１がサブネット、サブネット上のノー
ドすなわちネットワークコントローラの構内アドレス、
ドロップＩＤおよびプロセス識別子が、有効であること
を確認することを要求する。そうでなければ、エラー処
理３９−３１３が始まる。また、出口３９−３０９が得
られる。ネットワーク・アドレスが有効な場合、第１ノ
ードのネットワーク層３８−２０１は、メモリ３７−６
に格納されるルーティングテーブルを参照する。パスの
次のホップを決定するために、以前に議論したように、
そのようなルーティングテーブルは集中化されるか分散
化されて、静止的であるかもしれないしあるいは動的か
もしれない。ただ例示目的だけのためにそしてこれはこ
の発明の制限としてではなく、静的ルーティングテーブ
ルが仮定される。その後、ファンクションブロック３９
−３１７に示されるように、リクエストは、ノードのデ
ータリング層３８−２０３において次の中間の宛先によ
って、承認を得るために送信するノードのネットワーク
・アドレスでタグを付けられる。その後、リクエストの
伝送はファンクションブロック３９−３１９において起
る。上に議論されたように、図３９は、ネットワークを
通じて通信するための非構成装置からのリクエストに続
く、含まれている活動を例示する。ノードすなわちネッ
トワークコントローラが構成装置から応答を送信する場
合、同じ処理は起る。したがって、ネットワークコント
ローラあるいはノードが構成装置から応答を送信する場
合に起るのと同じ処理を使用することによって、ネット
ワークを通じて通信する非構成装置によるリクエストを
接続することができる。図３７および３８、ならびに図
４１においてテーブルは、非構成ラップトップソース３
７−１３から構成ラップトップ宛先３７−１５までリク
エストを送る際の、一層の詳細を示す。非構成ラップト
ップソース１：１：３：ＰＩＤＸは、サブネット１上の
プロセス、構内アドレス１、ＰＩＤＸとして識別された
ドロップＩＤ３を識別する。非構成ラップトップ３７−
１３からのメッセージもサブネット３、構内アドレス
１、ドロップＩＤ０、プロセスＰＩＤＹとして宛先を識
別する。したがって、構成時のルーティングテーブルに
おける第１ルーティング（それは定義されないだろう）
は１：１：３：ＰＩＤＸから１：１：０までである。こ
れは、非構成ラップトップ３７−１３間のパスおよびノ
ードすなわちネットワークコントローラ３７−３を表
す。構成時に定義された静的ルーティングテーブルは、
ノードすなわちネットワークコントローラ３７−３（ネ
ットワーク・アドレス１：１：０）から構成ラップトッ
プ３７−１５（ネットワーク・アドレス３：１：０）ま
でルーティングを提供する。図３７、３９および４１に
示されるように、静的ルーティングテーブルで識別され
るノード３７−３から次の絞りは、サブネット１、構内
アドレス位置４、ドロップＩＤ０として定義されるゲー
トウェイ３７−７のネットワーク１側にある。ゲートウ
ェイ３７−７のルーティングテーブルは、サブネット
２、構内アドレス４ドロップＩＤ０のゲートウェイの出
力にこのリクエストを剥ける。ゲートウェイのルーィン
グテーブルは、このリクエストに対する効率的なルート
が、サブネット２、構内アドレス２、ドロップＩＤ０と
定義されるノード１１に直接あることを決める。ノード
３７−１１は、サブネット３、構内アドレス１、ドロッ
プＩＤ０と定義されるアドレスへポートからメッセージ
を送る自身のルーティングテーブルをもつ。その後、メ
ッセージはＰＩＤＹと識別されるプロセスに送られる。
図３８は、プロセスの各中間段階でネットワークおよび
データリンク層に起る活動を例示する。以前に議論した
ように、メッセージの中間レシーバおよびセンダーは、
各ノードにおいて、メモリの静的あるいは動的ルーティ
ングテーブルのエントリによって決定される。中間段階
においては、メッセージは受信され、肯定応答信号が、
受信構成ノードであるデータリンク層３８−２０３によ
ってメッセージを進めた中間ノードへ送信される。ネー
ットワーク層３８−２０１は、メッセージの宛先がこの
構成ノードであるかあるいは他のなんらかの構成ノード
であるかを決め、ルーティングテーブルから適切な次の
中間の宛先を見つける。データリンク層３８−２０３
は、次の中間段階による承認を受けるためにメッセージ
に再びタグを付け、次に、ネットワーク層３８−２０１
によって識別される次の中間の宛先へメッセージを送信
する。図４０は非構成装置からリクエストを受信する際
に起る任意の与えられたノードの活動を例示する。これ
らの活動は構成装置からの応答を受信する際に起るもの
と同一である。したがって、構成装置からの応答の受信
を処理するための同じアプローチを非構成装置からのリ
クエストに応答するために使用することができる。以前
に議論したように、受信が肯定応答を受けることができ
るように、構成ノードからのメッセージは進行ノードに
よってタグを付けられる。ファンクションブロック４０
−４０３において、図４０に示されるように、メッセー
ジはタグを付けられたメッセージが、有効なソースから
有効な宛先へ向けられたものであり、図３９に関連して
以前に議論したようにメッセージが適切にタグを付けら
れるかどうか決めるために、最初に評価される。そうで
なければ、ファンクションブロック４０−４０５に示さ
れるように、メッセージは廃棄され、出口４０−４０７
が得られる。さらに、スライディングウィンドーのよう
な信頼性のための他の既知のタグ機能を実行することが
できる。有効なものとして、ファンクションブロック４
０−４０３におけるデータリンク層３８−２０３での処
理が、メッセージを識別する場合、ファンクションブロ
ック４０−４０９、さらにデータリンク層３８−２０の
一部は、進行ノードにメッセージの受信の肯定応答を送
信する。ネットワーク層３８−２０１で、メッセージは
宛先プロセスが受信であり構成ノードに位置指定されて
いるかどうか決めるために、ファンクションブロック４
０−４１１においてテストされる。そうならば、ファン
クションブロック４０−４１３は、受信ノードに対して
ローカルプロセスにリクエストを渡し、出口４０−４０
７をとる。宛先プロセスがこのノードネットワーク層に
位置しない場合、ブロック４０−４１５に示されるよう
に、３８−２０１の処理は継続する。その後、宛先プロ
セスはそれが非構成ノードに対するものであるかどうか
を決めるためにテストされる。もしそのケースの場合、
ネットワーク層は、非構成装置に対する応答を再びアド
レス指定し、データリンク層は応答に再びタグを付け
る。次に、ファンクションブロック４０−４１７、４０
−４１９および４０−４２１においてそれぞれ示されて
いるように、それは送信される。ブロック４０−４１５
において処理が宛先プロセスが非構成ノードでないよう
なものである場合、リクエストは、パスの次のホップに
対して再びアドレス指定され、再びタグを付けられ、ブ
ロック４０−４２３、４０−４２５および４０−４２７
においてそれぞれ示されるように、送信される。ファン
クションブロック４０−４０９−４２７での処理が、シ
ステムの任意のノードによって受信に対して同一である
ということに注意すべきである。図４１は、ネットワー
ク・アドレス１：１：３において非構成ラップトップ３
７−１３に構成ラップトップ３７−１５からの応答を、
非構成ラップトップ３７−１から構成ラップトップ３７
−１５まで行くに際して、以前に横断した、正確なメッ
セージパスを引返すことによって、送ることができるこ
とを示す。このアプローチを使用すれば、非構成装置に
よってリクエストされる情報を返すために、追加データ
通信パスを積極的に評価する必要はない。ダンパー３７
−１の状態を含んでいるラップトップ３７−１からの応
答は、ノード３７−３へノードを通って後ろに送られ
る。以前に議論したように、メッセージがノードそれ自
身に対して向けられているものか、あるいはノードにつ
ながっている非構成装置に対して向けられているかどう
かを決めるためにそれが受信するメッセージをテストす
る。この場合、ラップトップ３７−１５は、ネットワー
ク・アドレス１：１：３と識別される、リクエストのソ
ースに対する応答をアドレス指定する。サブネット１、
構内アドレス１のノード３７−３は非構成装置３７−１
３に付けられたノードポートとしてドロップＩＤ３を認
識するので、応答はラップトップ３７−１３まで送られ
る。最終的に、構成ノード３７−１５からの応答が非構
成装置３７−１３からのリクエストまで同じパスを横断
する必要がないことに注意すべきである。例えば、適応
経路選択システムにおいては、メッセージトラフィック
条件の変分は、リクエストよりネットワークを通って異
なるパスを横断する応答に結果的になってもよい。確か
に、通信リンク３７−１７につながるネットワークが適
応経路選択を使用しているのに対して、通信リンク３７
−４につながるネットワークが静的ルーティングスキー
ムを使用することは可能であり、またその逆も可能であ
る。まったく適応性のあるものであれ、まったく適応性
の無いものであれ、あるいは、ネットワークのどんな組
合せであれ、この発明を用いて使用することが可能であ
る。しかしながら、応答が構成ノードにどのように達す
るかにかかわらず、構成ノードは、メッセージの宛先と
して与えられたネットワーク・アドレスにドロップＩＤ
に基いた、非構成装置へのメッセージを送る。その結
果、ネットワークに正常に組入れられない機能は、シス
テムのネットワークの１つにつながるノードの１つから
便利なポートへ非構成装置を付けることによって、実行
することができる。これはネットワーク・アドレスのド
ロップＩＤが、構成ノードにつながるポートから落さ
れ、非構成装置に送られる、構成ノードから応答を許可
するからである。図４３２は、複数の管理水準を持つネ
ットワークアプローチを使用して、ファシリティマネジ
メントシステムの可能な１つの構成を示す。ネットワー
クコントローラ４２−１、４２−３および４２−５は第
１レベルで作動し、高速ネットワークバス４２−７を通
じて互いに交信する。相互に連結させることができるネ
ットワークコントローラの数は、ネットワークコントロ
ーラ自身および高速バス４２−の能力によってだけ制限
される。この第１のレベルで、コトントローラ４１−
１、４２−３および４２−５の各々は同類の仲間であ
る。なぜならそれらが同じ高速ネットワークバスに対し
てアクセスできて、他の下位のレベルファンクションを
制御するために作動するからである。図４２はネットワ
ークコントローラ４２−５でこの原理を例示する。ネッ
トワークローラ４２−５は、スレーブコントローラ４２
−１１、４２−１３および４２−１５に関連するマスタ
ーノードとして作動する。ネットワークコントローラ４
２−５は、ローカル・バス４２−９を通じてスレーブコ
ントローラ４２−１１、４２−１３および４２−１５
と、また高速バス４２−７を通じて他のネットワークコ
ントローラと通信する。マスターコントローラとして、
ネットワークコントローラ４２−５は、スレーブコント
ローラ４２−１１、４２−１３および４２−１間でロー
カル・バスの資源を割付ける。各スレーブコントローラ
はその個々のファンクションを実行し、データ取得ユニ
ット４２−１７、４２−１９および４２−２１とそれぞ
れ通信する。センサーに接続されるデータ取得ユニット
は、そのデータ処理ファンクションを実行するためにス
レーブノードにとって必要とされる情報を提供する。ス
レーブノード４２−１１、４２−１３および４２−１５
のあるファンクションは、特別のスレーブノードによっ
て制御されないデータ取得ユニットによって得られた情
報にたいするアクセスを要求してもよい。例えば、その
個別のファンクションを実行するにおいては、スレーブ
ノード４２−１１は、スレーブコントローラ４２−１３
によって制御されるデータ取得ユニット４２−１９に接
続されるセンサーによって提供される情報に対するアク
セスを要求してもよい。このデータを得るために、スレ
ーブコントローラ４２１１は、低速バス４２−９を通じ
てネットワークコントローラ４２−５を示す。その後、
従来のシステムにおいては、ネットワークコントローラ
４２−５は、データを要求するスレーブコントローラ４
２−１３に低速バス４２−９を通じてメッセージを送信
する。その後、スレーブコントローラ４２−１３は、低
速バス４２−９を通じてネットワークコントローラ４２
−５にデータを送信することによって答えるだろう。そ
の後、ネットワークコントローラ４２５は必要とするデ
ータをスレーブコントローラ４２−１１へ渡すだろう。
上記の例が例示するように、データ取得ユニット４２−
１から利用可能なデータに対するスレーブコントローラ
４２−１からのリクエストは、低速バスを通じて送信さ
れる一系列のメッセージに結果としてなる。スレーブコ
ントローラを通じるデータ・アクセスリクエスト数が増
加するにつれて、低速のバスを通じるメッセージトラフ
ィックが、データバスの混雑と処理効率の低下という結
果を高い割合で引き起こす。この状況は、高速バスを通
じての中間ネットワーク制御ノードで行なわれる追加リ
クエストによって合成される。例えば、データ取得ユニ
ット４２−１から利用可能なデータにアクセスするネッ
トワークコントローラ４２−３に対して、リクエスト
を、高速バス４２−７を通じてネットワークコントロー
ラ４２−５に最初に行なわなければならない。その後、
ネットワークコントローラ４２−５は上述の方法でロー
カル・バス４２−９を通じて通信する。したがって、追
加メッセージトラフィックは、ローカル低速バス４２−
９上、および高速バス４２−７上に発生する。さらに、
ルットワークコントローラ４２−３が、それ自身のより
低いレベルスレーブコントローラに基いたデータに対し
てリクエストに基いたデータを要求している場合、追加
遅延は、ネットワークコントローラ４２−３およびその
スレーブコントローラを接続するローカル・バスで招来
される。したがって、特別のセンサーを制御するデータ
取得ユニットから実際のデータが得られることに結果と
してなる一系列のメッセージを生成することは各データ
リクエストにとって非能率的である。ネットワークコン
トローラ４２−５がそれ自身、データ取得ユニット４２
−１７、４２−１９および４２−２１によって得られ
た、複数のデータ項目に対するアクセスを要求する場
合、付随的問題が発生する。システムの“特徴”は、シ
ステムによって実行されるファンクションとして定義さ
れ、システムの異なる位置にあるかもしれない１つ以上
のセンサーからデータを頻繁に要求する。ネットワーク
コントローラ４２−５においてプログラムの一部によっ
てインプリメントされる１つの特徴が、データ取得ユニ
ットから利用可能なデータに対するアクセスを要求する
場合、ネットワークコントローラは、ローカル・バスの
コントロールをとらえて、情報を得るために適切なスレ
ーブコントローラにメッセージを送信しなければならな
いし、マスターコントローラに情報を送信しなければな
らない。スレーブコントローラはリクエストされる情報
の送信によって、応答する。これもまた、通信ボルトネ
ックおよびデータ処理効率の低下という結果を引き起こ
す。その結果、火災報知機メッセージのようなより高い
優先権ファンクションが、待ちリスト遅延修正処置にス
タックされるようになる。図４３は、本発明１つの実施
例を示す。ネットワークコントローラ４３−２３は、高
速バス４３−２５、ローカル・バス４３−３５を通じ
て、スレーブコントローラ４３−２４３−２９、４３−
３１および４３−３３に接続される。以前に言及したよ
うに、任意の数のスレーブコントローラをネットワーク
コントローラ４３−２３に接続することができる。もっ
ともこれはネットワークコントローラの処理能力および
ローカル・バスの通信能力に対する要求に左右される。
図４３において、ネットワークコントローラ４３−２３
は、代表的な３つの特徴４３−３５、４３−３７および
４３−３９を持って示されている。これらの各々の特徴
がプロセッサ４３−４のコントロールの下で遂行される
と仮定される。示される特徴の数は例を介したものであ
り、制限として意図されるものではない。各々の特徴は
スレーブコントローラを通じて利用可能なデータに対す
るアクセスを要求する望ましいファンクションを表わ
し、ネットワークコントローラ４３−２３において遂行
されると仮定される。最終的に、図４３は記憶データテ
ーブル４３−４３を示す。記憶データテーブルはそれら
がマスターコントローラによってスレーブコントローラ
から受信されるときに、データ項目の値を保持するため
に使用されるキャッシュ・メモリである。エージングタ
イマー４３−４５は各受信データ項目に関連しており、
記憶データテーブル４３−４３において個々のデータ項
目が有効である先決の時間を表わしている。したがっ
て、記憶データテーブル４３−４３において各データ項
目は自身のエージングタイマ４３−４５と関連してい
る。オペレーションにおいては、ネットワークコントロ
ーラあるいは別のプロセッサや別のネットワークコント
ローラ内の特徴がファンクションを実行することをデー
タに要求する場合、ネットワークコントローラは、デー
タが記憶データテーブル４３−４３において利用可能か
どうか決める。その後、データが記憶データテーブルに
在る場合、ネットワークコントローラは、そのデータが
最後に得られてから、データに関連するエージングタイ
マが終了しているかどうかを決める。その後、エージン
グタイマが終了している場合、ネットワークコントロー
ラは適切なプロセッサおよびデータ取得ユニットから新
しいデータを得るのに必要とするメッセージを出す。エ
ージングタイマが終了していない場合、ネットワークコ
ントローラ２３は特徴あるいは他のプロセッサに記憶デ
ータテーブルの利用可能な最も最近の情報を提供する。
その結果、センサーの値に何ら重大な変更が生じていな
いことが仮定される。ｔ０で、参照番号４３−３５によ
って図４３に表される特徴１が、スレーブコントローラ
４３−２７によって制御されるセンサーにデータを要求
すると仮定しなさい。ネットワークコントローラ４３−
２３は、エントリが記憶データテーブル４３−４３にな
いことをプロセッサ４３−４のコントロールの下で決め
る。したがって、ネットワークコントローラ４３−２３
はスレーブコントローラ４３−２７に、データ取得ユニ
ットから情報を得て、ネットワークコントローラ４３−
２３に情報を提供するように指図するメッセージを、ロ
ーカル・バスを通じてスレーブコントローラ４３−２７
へ出す。ネットワークコントローラ４３−２３がスレー
ブコントローラ４３−２からデータを受信する場合、そ
れは記憶データテーブルの情報を格納し、格納されるデ
ータ項目に前もって定義したエージングタイマを関連さ
せる。当業者に既知の任意の数の方法でエージングタイ
マをインプリメントすることができることに注意すべき
である。例えば、クロックダウンカウントは、情報が格
納される時間からダウンしてセットし、カウントするこ
とができよう。これは既知の状態へレジスタをプリロー
ドし、第２論理状態（たとえばすべての論理的１あるい
は論理０）に達するまで、レジスタを上下にクロックす
ることによって達成することができよう。二者択一的に
述べれば、格納時間は次のデータ・アクセス時に時間と
共に記録することができ比較することができよう。この
場合、我々は、エージングタイマが、例えば、１００ミ
リ秒間セットされると仮定する。１００ミリ秒という選
択は、特にこのセンサーによって得られるデータが１０
０ミリ秒間で有効だろうということが、前もって定義し
たシステム特性に基いて知られているからである。５０
ミリ秒プラスｔ０で、特徴２は、同じデータに対するア
クセスを要求する。プロセッサ４３−４のコントロール
の下で、マスターコントローラ４３−２３は、リクエス
トされるデータ項目が記憶データテーブル４３−４３に
存在することを決める。その後、マスターコントローラ
は対応するエージングタイマをテストする。ｔ０で得ら
れたデータが１００ミリ秒間有効であり、データが得ら
れた後、データ・アクセスが５０ミリ秒だけしかこの場
合生じていないので、データエージングタイマはまだ終
了していない。したがって、ネットワークコントローラ
４３−２３は、記憶データテーブルから特徴２によって
処理されるデータを提供するだろう。スレーブ４３−２
７によって制御されるセンサーの値が変ったとしても、
これは真実である。この利点はそれ以上データ通信が、
必要とするパラメータの有効値をアクセスするように特
徴２に対してローカル・バスを通じて要求しないことで
ある。１００ミリ秒プラスｔ０で、特徴３は、スレーブ
コントローラ４３−２９によって制御されるセンサーか
ら利用可能なデータを要求する。このデータが記憶デー
タテーブル４３−４３に記録されていないので、ネット
ワークコントローラ４３−２３はデータを得るために適
切なデータ通信メッセージを出す。ネットワークコント
ローラ４３−２３がスレーブコントローラ４３−２から
データを受信する場合、データは記憶データテーブル４
３−４３に格納される。１５０ミリ秒プラスｔ０で、特
徴１は、ｔ０でスレーブコントローラ４３−２７によっ
て得られた、同じデータ要素に対するアクセスを再び要
求する。しかしながら、ネットワークコントローラのプ
ロセッサは、データエージングタイマが終了したことを
決める。したがって、ネットワークコントローラ４３−
２３はスレーブコントローラ４３−２７を通じて新鮮な
データを得るために、メッセージを出す。１ミリ秒のネ
ットワーク遅延を仮定すると、データは、１５１ミリ秒
プラスｔ０で記憶データテーブルに格納される。このデ
ータに対するデータエンジングタイマが１００ミリ秒な
ので、データは２５１ミリ秒プラスｔまで有効になる。
ｔ０で得られたデータに対してデータエージングタイマ
が終了した時、記憶データテーブルが１００ミリ秒で更
新されなかったことに注意すべきである。たとえスレー
ブ２７によって制御されるセンサーデータの値がこの時
間によって変ったかもしれなくても、要求される特徴あ
るいは他のプロセッサはこのデータにアクセスしない。
したがって、終了データに対するアクセスが要求される
まで、記憶データテーブルを更新することは、必要では
なかった。これは、ローカルデータバスおよび高速デー
タバスで非産的な通信をさらに減少する。発明の別の実
施例が図４４に示される。図４４は、高速ネットワーク
バス４４−５での通信ボトルネックの一層の減少を例示
する。ネットワークコントローラ４４−５２は、プロセ
ッサ４４−６のコントロールの下で、代表的な特徴４４
−５３、４４−５６および４４−５８を実行する。ネッ
トワークコントローラ４４−５２は、また、データ記憶
装置テーブル４４−６２とエージングタイマ４４−６４
を含み、ローカル・バス４４−６５を通じてコントロー
ラ４４−６６、４４−６４４−７０および４４−７２に
接続されている。そのようなスレーブコントローラは、
１つ以上のセンサー、Ｓあるいは他の装置に一般に接続
されてもよい。同様に、ネットワークコントローラ４４
−５４は、プロセッサ４４−７のコントロールの下で、
特徴４４−７４および４４−７６を実行する。ネットワ
ークコントローラ４４−５４はデータ記憶装置テーブル
４４−８０およびエージングタイマ４４−８２をさらに
含んでおり、ローカル・バス４４−８３を通じて、スレ
ーブコントローラ４４−８４、４４−８６および４４−
８８と通信する。例によって、時間ｔ０で特徴４４−７
４が、スレーブコントローラ４４−８４によって制御さ
れているセンサーから利用可能なデータを要求する。以
前に議論したように、ネットワークコントローラ４４−
５４はローカル・バス４４−８３を通じて適切なメッセ
ージを生成し、このローカル・バス４４−８３はスレー
ブコントローラ４４−８４にデータを得させ、ネットワ
ークコントローラ４４−５４にそれを送信させる。その
後、ネットワークコントローラ４４−５４は記憶データ
テーブル４４−８０に情報を格納し、前もって定義した
エージング時間値４４−８２を割当てる。３０ミリ秒プ
ラスｔ０で、ネットワークコントローラ４４−５２の特
徴（４４−５３、４４−５６、４４−５８）は、高速ネ
ットワークバス４４−５０を通じて同じデータを要求す
る。応答により、ネットワークコントローラ４４−５４
は、データ記憶装置テーブルの現在値が有効であり更新
される必要がないことを、データ記憶装置テーブル４４
−８０およびデータエージングタイマ４４−８から決め
る。したがって、ネットワークコントローラ４４−５４
はネットワークバス４４−５０を通じてデータ記憶装置
テーブルに見つけられるような要求されるデータを送信
する。さらに、ネットワークコントローラ４４−５４
は、データが読まれた（ｔの実効値）時間、およびエー
ジングタイマの値を送信する。応答により、ネットワー
ク４４−５２は、そのデータ記憶装置テーブル４４−６
２において受信されたデータを格納し、処理を要求する
特徴にそれを提供する。さらに、ネットワークコントロ
ーラ４４−５２はデータがそのデータ記憶装置テーブル
４４−６２に格納される時間および、ネットワークコン
トローラ４４−５４によって送信されるエージング時間
に基いて、どのくらいの時間そのデータが有効になるか
を決定する。データを送信する際に、およそ２ミリ病の
遅延を仮定して、データは、３２ミリ秒プラスｔ０でデ
ータテーブル４４−６２に格納される。このデータはｔ
０秒からｔ０プラス１０ミリ秒まで有効であろうから、
ネットワークコントローラ５２はこのデータは追加６８
ミリ秒の間有効であろうと決定する。したがって、ネッ
トワークコントローラ４４−５２は、エージングタイ
マ、ネットワークコントローラ４４−５から得られたデ
ータ要素に対応する４４−６４として６８ミリ秒のエー
ジング時間値を格納する。したがって、次の６８ミリ秒
の間、ネットワークコントローラ４４−５４がこのデー
タを得るためにスレーブコントローラ４４−８４に再び
アクセスしない時間、ネットワークコントローラ４４−
５２の特徴あるいはネットワークコントローラ４４−５
２に接続されるスレーブコントローラは、ローカル・バ
ス４４−６５を通じ、データ記憶装置テーブル４４−６
２から特にこのデータ要素を得るだろう。その結果、ネ
ットワークバス４４−５０を通じて非産的なデータリク
エストも削除される。したがって、この実施例において
は、ネットワークに接続されている中間ノード環でのデ
ータジングタイマ値のトランスファは、データ通信要件
に重大な減少を産み出すことができる。そのデータ記憶
装置テーブルに要求されるデータを含んでいる、ネット
ワークコントローラからデータエージングタイマの転送
へのもう一つの選択肢は、残るデータエージングタイマ
で利用可能な時間を転送することであるということに、
さらに注意すべきである。これは、受信ネットワークコ
ントローラが受信データが有効な残り時間を計算するた
めの要件を回避することを可能にするだろう。分散形フ
ァシリティマネジメントシステム（ＦＭＳ）においてエ
ージングタイマを使用することが、ユーザが個々のデー
タの片々に対する可変有効な期限を定義することをさら
に可能にすることに、さらに注意すべきである。例え
ば、外部の空気温度を感じるセンサーからデータにアク
セスするスレーブコントローラは、データに火炉の温度
をモニタするセンサーほど頻繁にアクセスする必要がな
い。これは外部の空気温度の変化率が火炉で期待される
変化率より遅いからである。したがって、データエージ
ングタイマはデータの特性のバリエーションに左右され
て異なるものになろう。ユーザ定義のエージングタイマ
の代わりに、一層のユーザ定義の情報がない時に自動的
にインプリメントされる省略値をプログラムすることも
できる。分散形ファシリティマネジメントシステム（Ｆ
ＭＳ）において、受信（非受信）データの信頼性はしば
しば問題になる点である。本発明に従って、一貫性と完
全性への援助として、ファシリティマネジメントシステ
ムの特徴間で渡される、各データ値は、信頼性のある／
信頼性のないインディケータでタグを付けられている。
データがファンクションブロック４５−１において要求
される場合、図４５に示されるように、受信データは、
受信データが期待される範囲内にあったかどうか決める
ために、決定ブロック４５−３でテストされる。そうで
なければ、決定ブロック４５−５において可能な１つの
選択肢はデータの交互のソースが利用可能かどうか決め
る処理を実行することである。そのような処理はデータ
が設置するネットワークで他の物理的位置を識別するた
めに、ディレクトリによるソートを含んでいてもよい。
例えば、ソースデータは、同一あるいは別のノードの別
の記憶場所に格納されるかもしれない。あるいは、同じ
データを別のセンサーから利用可能かもしれない。その
ような処理も、信頼性のないデータとの置換をネットワ
ークで利用可能な他のデータから引き出し得るかどうか
決めることを含むことができよう。ファンクションブロ
ック４５−７は代替ソースが消耗されたかどうか決める
テストする。そうでなければ、データは代替ソースから
得、決定ブロック４５−３で再テストすることができよ
う。代替ソースが利用可能でない場合、あるいは代替ソ
ースが消耗されている場合、別のオプションがデータの
前の値を使用することになる。したがって、ファンクシ
ョンブロック４５−９は前の値が利用可能かどうかをテ
ストする。そのあと、前の値が利用可能な場合、４５−
１１でこのプロセスにおいて前の値が有用かどうかが決
定されるだろう。そうならば、ファンクションブロック
４５−１３に示されるように、前の値が使用され、デー
タは、ファンクションブロック４５−１５においてその
ような古いデータに適切な信頼性インディケータでタグ
を付けられる。前の値が利用可能でないもしくは有用で
ない場合、ファンクションブロック４５−１７におい
て、代替コントローラが利用可能かどうかについて決定
が行なわれる。そうでなければ、すなわち代替コントロ
ールがファンクションブロック４５−１９に示されるよ
うに、有用でないと決められた場合、データはその非信
頼性を示す表示でタグをつけられ使用することができ
る。もちろん、代替コントローラが利用可能な場合、そ
のような代替コントロールテクニックを実行することが
できる。代替コントロールプロセスで受信される、新し
いデータもファンクションブロック４５−２３に示され
るような信頼性テストを経験するだろう。その後、一度
データが、ブロック４５−１５において信頼性インディ
ケータでタグを付けられれば、データは、ファンクショ
ンブロック４５−２５および４５−２７に示されるよう
な他の特徴へ渡すことができる。これは、最終計算の信
頼性の標識としての中間計算に含むことができるデータ
の信頼性の標識を提供する。信頼性インディケータの使
用は、比例、積分、および微分係数（ＰＩＤ）ループの
コントロールと関連して以下にさらに議論される。発明
図の別のアスペクトに従って、４６Ａと４６Ｂは、比例
＋積分＋微分係数（ＰＩＤ）オブジェクトを示す。以前
に議論したように、ＰＩＤループオブジェクトはソフト
ウェアオブジェクトレベルでソフトウェアにインプリメ
ントされる。したがって、ＰＩＤループオブシェクトに
は他のソフトウェアオブジェクトを行うように、ノード
すなわちネットワークコントローラの記憶手段に格納さ
れるプロセスおよび属性を管理するデータ・ベース管理
プログラムがある。ファシリティマネジメントシステム
の範囲内では、発明に従って、ＰＩＤループを処理する
タスクは、ＰＩＤデータ・ベース管理プログラムタスク
および１６のＰＩＤループ実行タスク間で分割される。
したがって、ＰＩＤコントローラは、ＰＩＤループの１
６の例まで制御することができる。図４７は、ＰＩＤ処
理に関するコントロールループを示す。ＰＩＤデータ・
ベース管理プログラムは、ＰＩＤループからデータ（た
とえば４７−５）を読み、ＰＩＤループに書き、あるい
はＰＩＤループに命じることのできる、ネットワークの
他のタスクにインタフェースを最初に提供する。第２の
ＰＩＤデータ・ベスー管理プログラムタスクは、ＰＩＤ
ループの各々１６の例の処理をスケジュールすることで
ある。ＰＩＤデータ・ベース管理プログラムの第３の責
任は補助信号スイッチ処理、出力フィルタ処理、高／低
信号選択処理、およびこれらの処理ファンクションへの
入力に従う信頼性スイッチ処理を実行することである。
図４６に示されるように、ＰＩＤループオブジェクトに
はＰＩＤループに対するフィールド・バック値を計算す
るために、入力コンディショニングプロセス４６−３に
よって使用される６つの入力４６−１がある。擬ポイン
トと関連して以前に議論したように、各々６つの入力４
６−１は他のオブジェクトの属性へのアナログパラメー
タあるいはレファレンスのような浮動小数ポイント値で
あってもよい。他のオブジェクトの属性へのレファレン
スはＰＩＤコントローラとして機能する同一の物理的な
ディジタル制御モジュール（ＤＣＭ）のオブジェクトで
なければならない。アナログ値として、入力値、あるい
は、アナログ値を提供する他のパーツの値は、ネットワ
ークコントローラからコマンドの結果変更されてもよ
い。ポートが別のオブジェクトの属性を参照する場合、
以前に議論したように、対応する処理が実行されるごと
に、属性の値が得られる。これは、Ｎ２バスを通じてで
はなくネットワークコントローラとして機能する、ディ
ジタル制御モジュール内のタスク間のメッセージを送信
する、指定されるオブジェクトに読取り属性メッセージ
を送信することによって、達成される。ポートが個々に
指定変更されることもあり得る。その場合、その指定変
更値は、その指定変更値を解除するコマンドが受信され
るまでポート値として使用される。ポートがアナログ値
である場合、解除コマンドが受信された時に、ネットワ
ークコントローラによって命じられた最後の値が記憶さ
れ行動に移される。ネットワークコントローラだけが指
定変更を開始し解除する。以前に議論したように、セッ
トポイントｔ入力４６−５も別のオブジェクトの属性に
対する、浮動小数ポイント値あるいはレファレンスであ
ってもよい。セットポイント値４６−５はフィールド・
バック値のセットポイントである。また、それはＰＩＤ
処理４６−７の中で使用される。オフセット値４６−９
は別のオブジェクトの属性に対する、浮動小数ポイント
値あるいはレファレンスであってもよい。オフセット値
４６−９は２つのファンクションを実行する。６つのス
ケーラ４６−１１がすべて０であることを、入力コンデ
ィショニング処理４６−３が決める場合、ＰＩＤ処理４
６−７は無効になる。また、オフセット値４６−９は、
ＰＩＤ処理４６−の出力として使用される。６つのスケ
ーラ４６−１１のうちのどれでも０でない場合、オフセ
ット値４６−９は、ＰＩＤ処理４６−７によって計算さ
れた出力値に加えられる。オフセットは、ＰＩＤ処理の
開始時に出す第１出力コマンドを示すために使用するこ
とができるＰＩＤ処理に他の制御動作を導入するために
使用されてもよい。高飽和度限界４６−１３は別のオブ
シェクトの属性に対する、浮動小数ポイント値あるいは
レファレンスであってもよい。高飽和度限界４６−１３
は、ＰＩＤ処理４６−７への直接入力である。ＰＩＤ処
理はこの高飽和度限界４６−１３以上にＰＩＤ出力コマ
ンドを出すことを妨げられる。低飽和度限界４６−１５
も別のオブジェクトの属性に対する浮動小数ポイント値
あるいはレファレンスであってもよい。飽和度限界４６
−１５は、ＰＩＤ処理４６−７に直接提供され、ＰＩＤ
処理４６−７がＰＩＤ出力へのコマンドを出さない下限
を確立する。補助信号入力４６−１７は別のオブジェク
トの属性に対する浮動小数ポイント値あるいはレファレ
ンスであってもよい。補助信号入力４６−１７は、以下
に議論される補助信号入力処理４６−１７の出力上へ渡
されてもよい代替入力である。高／低信号入力４６−２
１は浮動小数ポイント値あるいは、ＰＩＤコントローラ
として機能するディジタル制御モジュールの別のオブジ
ェクトの出力に対するレファレンスであってもよい。ま
たはこれは、先へ進むために高／低選択信号処理４６−
２３によって選択することもできる代替入力である。８
この出力４６−２５は操作変数（たとえば、希望の状態
へ制御されるプロセスの）を調節するために使用され
る。その結果セットポイントおよびフィード・バック変
数は等しい。出力は、同一の物理的なＰＩＤコントロー
ラの任意のオブジェクトの任意の属性を参照する。ＰＩ
Ｄループからコマンドは、これらのレファレンスの中で
定義される各々のオブジェクトに送られる。ＰＩＤ処理
もこのレファレンスによって指定されるオブジェクトが
他のあるタスクによって指定変更されるかどうか決める
ために、この情報を使用する。あるパラメータはアナロ
グ値であり指定変更することができない。６つのスケー
ラ４６−１１は、コンディショニング処理４６−３を入
力するための各々の対応する６つの入力４６−１に対す
る係数を表す各浮動小数ポイント値である。サンプル周
期４６−２７は、１−３２７６７秒の範囲を持ってお
り、ＰＩＤ処理４６−７がＰＩＤループに対してどれく
らい頻繁に実行されるか決める。比例帯４６−２９は、
フィード・バック値とセットポイント値（エラー）の間
の差にＰＩＤ処理４６−７の感度をセットする浮動小数
ポイント値である。エラーの大きさは、出力値に変動を
引起す。負の値が直接行動コントロールを示すのに対し
て、正の値は、逆の行動コントロールを示す。もちろ
ん、これらのコントロールは発明の精神を損なわずに、
逆にすることができよう。積分時間４６−３１はエラー
の積分にＰＩＤ処理感度を提供する浮動小数ポイント値
である。これはそれが一定のエラーを与えられた比例項
と等しい積分項をとる時間である。０．０にこの値をセ
ットすることはＰＩＤコントロール処理から積分動作を
取除く。微分係数４６−３３も浮動小数ポイント値であ
り、フィード・バック値の変化率にＰＩＤ処理感度を与
える。積分時間とともにこの項および比例帯は、提供さ
れる微分係数コントロールの量を決定する。０．０にこ
の値をセットすることはＰＩＤコントロール処理から微
分係数アクションを取除く。不感帯パラメータ４６−３
５は、セットポイントと入力を決定されたフィード・バ
ックの間の差の絶対値と比較される浮動小数ポイント値
である。この不感帯値を超過しない場合、エラー変更は
ＰＩＤ処理４６−７によって考慮されない。ヒステリシ
ス補正偏り４６−３７は、０．０から１００．０までに
渡り、出力ポイントとフィード・バックポイント間で出
会うヒステリシスの量を表す。この比例値はプロセスヒ
ステリシスを補正するために使用される。フィード・バ
ック値４６−３９は入力コンディショニング処理４６−
３によって計算され、浮動小数ポイント値である。ＰＩ
Ｄ処理４６−７は、フィード・バック値４６−３９をセ
ットポイント値４６−５と等しくさせようと試みる。ス
タートデータ４６−４１は以前のＰＩＤ処理４６−７の
反複からの情報を含んでいる。ＰＩＤ処理４６−７への
第１のパスにおいては、これらの値は、１．０まで初期
化される前の指示値を除いて、０．０にセットされる。
履歴上のデータは、微分係数コントロールに対して適用
される前のフィード・バック値、積分動作およびバンプ
レス転送に供給される前の積分項、ヒステリシス削除に
対する前のヒステリシス補正偏り、ヒステリシス削除に
対する前の出力値、およびヒステリシス削除に対する出
力値の前の指示を含んでいる。出力値の前の指示は、増
加値に対して１に等しく、減少値に対してマイナス１と
等しくなるようにセットされる。ＰＩＤループの処理
は、データ・ベース管理プログラムタスクおよび１６個
のＰＩＤループ実行タスク間で分割される。そういうも
のとして、ＰＩＤコントローラディジタル制御モジュー
ルは、ＰＩＤループの１６個の例まで制御できる。ＰＩ
Ｄデータ・ベース管理プログラムタスクには３つの主要
な責任がある。第１に、他のタスクあるいはＰＩＤコン
トローラあるいはノードのオブジェクトにＰＩＤループ
からデータを読むことを望むインターフェースを提供
し、ＰＩＤループにデータを書くかＰＩＤループに命じ
ること。ＰＩＤデータ・ベース管理プログラムの第２の
タスクは、ＰＩＤループの１６個の例の各々に対するス
ケジュール処理にある。第３の責任は補助信号スイッチ
処理４６−１９、フィルターウエイト４６−６１に従う
出力フィルタ処理４６−４３、Ｈ／Ｌ選択フラグ４６−
７５を生成するための高／低信号選択処理４６−２３を
選択する、および信頼性値４６−７３を生み出す信頼性
スイッチ処理４６−６７を含むこともある補助処理の実
行である。これらのタスクを実行するために、ＰＩＤデ
ータ・ベース管理プログラムは２つのタイプの書込みレ
コードメッセージに反応することができる。第１はデー
タベースにＰＩＤループを加えるＡＤＤループメッセー
ジである。それは、さらに一度力が停電後返されればル
ープが自動的に加えられるようにＥＥＰＲＯＭに書かれ
るそのループに対する構成情報を引起す。第２のタイプ
の書込みレコードメッセージは削除ループメッセージで
ある。これは、ＰＩＤループの実行を中止させ、ループ
の定義を無効にする。それは、さらに、ループの出力に
接続されているオブジェクトにループがもはや定義され
ないと通知させる。ＰＩＤデータ・ベース管理プログラ
ムは、さらに、２つのタイプの読取りレコードメッセー
ジを提供する。読み込まれたＲＥＡＤ ＣＯＮＦＩＧＵ
ＲＡＴＩＯＮ（構成読み込み）記録メッセージは、与え
られたＰＩＤループに対する現在の有効な定義を、フォ
ーマットし、Ｎ２バスを通じてネットワークコントロー
ラへ送り返させる。もう一方の読取りレコードメッセー
ジはＲＥＡＤ ＣＵＲＲＥＮＴ ＳＴＡＴＥ（現在状態
読込み）である。これは、ネットワークコントローラに
Ｎ２通信バスを介して送られる処理の最後の反復の間使
用される値と共にＰＩＤループの現在の状態についての
情報を引起す。ＳＴＡＲＴ ＵＰは、あたかもそれがち
ょうど加えられたかのように、ＰＩＤ処理４６−７を反
応させる。処理に対する履歴上のデータがすべて再び初
期化される。その後、ＰＩＤ処理から第１の出力は、現
在のオフセット４６−９および現在の比例制御による補
正に基くだろう。書込み属性によって、与えられたＰＩ
Ｄループの指定された属性にメッセージの値がセットさ
れる。これにより、結果として、ＰＩＤループの出力が
変更される。読取り属性によって、属性の現在地はリク
エスタに返される。属性が指定変更される場合、その指
定変更値は返される。属性が別のオブジェクトの属性へ
のレファレンスである場合、読取り属性メッセージは宛
先オブジェクトに転送される。有効な場合には、この指
定変更属性によって、解除属性メッセージがその属性に
対して受信されるまで入力が受信するであろう正常な値
に対して、メッセージ中の値の方が優先する。指定変更
解除属性によって、指定変更属性メッセージの効果は減
少する。ＰＩＤデータ・ベース管理プログラムは、ま
た、状態変更の報告を引き起こす。報告された状態のそ
のような変更は、ＰＩＤループ信頼性フラグ４６−４５
の変更、高飽和度の変更フラグ４６−４５の変更、高飽
和度の変更フラグ４６−４７、低飽和度の変更フラグ４
６−４９、およびＰＩＤ処理信頼性の変更フラグ４６−
５１を含んでいる。これらのフラグは以下に議論され
る。ＰＩＤループデータ・ベース管理プログラムの一次
ファクションはスケジューリングを提供することであ
る。ＰＩＤループデータ・ベース管理プログラムは、こ
の前、ＰＩＤループが処理されるときにその後経過した
時間の量を連続的にモニタする。時間４６−２のサンプ
ル周期量が経過した場合、ＰＩＤデータ・ベース管理プ
ログラムタスクは、ＰＩＤ処理４６−７によって使用さ
れるポートの現在の状態を集める。ＰＩＤ処理４６−７
によって使用されるポート現在の状態を集めるために、
ＰＩＤデータ・ベース管理プログラムは、ポートが指定
変更条件にあるか、あるいはアナログ値あるいはレファ
レンスとして定義されているどうかを決める。以前に議
論したように、指定変更がある場合、その指定変更値は
ポート値として使用される。ポートがアナログ値である
場合、その値が使用される、また、ポートがレファレン
スである場合、読取り属性メッセージは指定されたオブ
ジェクトへ送られ、返された値がポート値として使用さ
れる。ＰＩＤデータ・ベース管理プログラムは、データ
および応答の信頼性をチェックし、受信データがそのカ
テゴリーをセットすると決められた場合、確実なものと
して、ポートにフラグを立てる。ＰＩＤデータ・ベース
管理プログラムが、優先権スキームに対して、各ＰＩＤ
ループがそのサンプル周期１５％内のサンプル周期毎に
処理されるように実行させることに注意すべきである。
これは、異なる優先権を各々与えられる一系列ＰＩＤ実
行タスクを通じて行われる。ＰＩＤループに対する定義
がＰＩＤコントローラに加えられる場合、ＰＩＤデータ
・ベース管理プログラムは、どのＰＩＤ実行タスクが、
ＰＩＤループのサンプル周期に基いた、そのＰＩＤルー
プに実行を提供するか決める。より短いサンプル周期を
持つＰＩＤループはより高い優先権ＰＩＤ実行タスクを
割当てられる。より長いサンプル周期を持つＰＩＤルー
プは、低い優先権を持つタスクに割当てられる。ＰＩＤ
ループがＰＩＤコントローラから削除される場合、ＰＩ
Ｄデータ・ベース管理プログラムタスクは、サンプル周
期にしたがって、ＰＩＤループとＰＩＤ実行タスク間の
バインディングを再び整える。ループのサンプル周期が
変更される場合、ループの優先権が再び整えられる。現
在状態を集めた後、ＰＩＤ実行タスクも必要とされるい
かなる履歴上のデータをも提供する。その後、ＰＩＤデ
ータ・ベース管理プログラムは入力コンディショニング
処理４６−３を実行し始める。入力コンディショニング
処理４６−３は入力合計、差、平均、および様々な他の
累積関数、あるいは与えられた入力の瞬間最大値あるい
は最小値を提供する。累積ファクションとは、入力ファ
クション属性４６−１００に１をセットすることによっ
て選択される、以下のものである。 フィールド・バック値＝（＃スカラ（ｎ）＊入力値
（ｎ）） ｎ＝１ 入力が別の属性のオブジョクトへのレファレンスであっ
て、無効の場合、ポイントが指定されず、スケーラ０が
使用されることに注意すべきである。スカラが０である
場合、入力は無視される。２によって選択され、入力フ
ァンクション属性を２にセットする最小値ファンクショ
ンは以下のとおりである： スカラ（１）＊入力値（１） 又は、スカラ（２）＊入力値（２） 又は スカラ（３）＊入力値（３） 又は スカラ（４）＊入力値（４） 又は スカラ（５）＊入力値（５） 又は スカラ（６）＊入力値（６）の最小値 ３によって選択され、入力ファンクション属性を３にセ
ットする最大値ファンクションは以下のとおりである： スカラ（１）＊入力値（１） 又は、スカラ（２）＊入力値（２） 又は スカラ（３）＊入力値（３） 又は スカラ（４）＊入力値（４） 又は スカラ（５）＊入力値（５） 又は スカラ（６）＊入力値（６）の最大値 １６のＰＩＤ実行タスクは同一であり、上に議論された
ようなそれらの優先権においてのみ異なる。ＰＩＤ処理
４６−７の各反復に際して、ＰＩＤデータ・ベース管理
プログラムは、ＰＩＤ実行タスクの一つに、ＰＩＤルー
プの例１つに対して処理を実行するために必要とされる
データのすべてを送る。ＰＩＤ処理が完了したとき、Ｐ
ＩＤ実行タスクはＰＩＤデータ・ベース管理プログラム
タスクにすべての最新の中間結果と共に計算される出力
に４６−５３を送る。ＰＩＤループに関するデータが反
復間の格納されないことに注意すべきである。一般にＰ
ＩＤ処理は以下のとおりである： Ｅ（ｔ）＝（セットポイント（ｔ）−フィード・バック
−（ｔ）） Ｐｔｅｒｍ（ｔ）＝１００の＊Ｅ（ｔ）／Ｐｂａｎ Ｉｔｅｒｍ（ｔ）＝（Ｔ／Ｉｔｉｍｅ）（＊Ｐｔｅｒｍ
（ｔ））＋（１−Ｔ／Ｉｔｉｍｅ＋Ｉｔｅｒｍ（ｔ−
１） Ｄｔｅｒｍ（ｔ）＝Ｄｗｅｉｇｈｔ＊（Ｉｔｉｍｅ／４
Ｔ）＊（１００／Ｐｂａｎｄ）＊フィールド・バック
（ｔ−１）−（フィールド・バック（ｔ）） ＯＵＴ（ｔ）＝Ｐｔｅｒｍ（ｔ）＋Ｉｔｅｒｍ（ｔ−
１）＋Ｄｔｅｒｍ（ｔ）＋オフセット（ｔ）＋ヒステリ
シス補正（ｔ） ここで： Ｆ（ｔ）＝時刻ｔにおける値 Ｆ（ｔ−１）＝前回反復時における値 Ｅ（ｔ）＝時刻ｔにおけるエラー Ｐｔｅｒｍ（ｔ）＝時刻ｔにおける比例制御寄与 Ｉｔｅｒｍ（ｔ）＝時刻ｔにおける積分コントロール寄
与 Ｔ ＝サンプル周期 Ｄｔｅｒｍ（ｔ）＝時刻ｔにおける微分係数コントロー
ル寄与 Ｓｅｔｐｏｉｎｔ（ｔ）＝時刻ｔにおけるセットポイン
ト Ｆｅｅｄｂａｃｋ（ｔ）＝時刻ｔにおけるフィードバッ
ク値 Ｐｂａｎｄ＝比例項係数 Ｉｔｉｍｅ＝積分時間係数 Ｄｗｅｉｇｈｔ＝微分係数項係数 Ｏｆｆｓｅｔ（ｔ）＝外部的に制御される補正項 Ｈｙｓｔｅｒｅｓｉｓ ｃｏｍｐｅｎｓａｔｉｏｎ
（ｔ）＝システムのヒステリシスを補正するために必要
とされるアクション ＰＩＤ処理４６−７からの出力コマンドが、進行方向を
変更する（すなわちＰＩＤ処理出力４６−５３が符号を
変える）時はいつでも、ＰＩＤコントローラの出力と、
関連する入力間のプロセスで発生する任意のヒステリシ
スを補正するために、ＰＩＤ処理４６−７は構成されて
もよい。これは、進行方向が増加（あるいは減少）であ
るように、ＰＩＤ処理の出力４６−５３にヒステリシス
補正値４６−３５を加えること（あるいは減算するこ
と）によって行われる。コントロールが、人間のコント
ロールあるいは別のＰＩＤループのような１つのコント
ロール方法からこのループのＰＩＤ処理４６−７に転送
されるように、バンプレス転送は、ＰＩＤ処理４６−７
の反応について記述する。コントロール反応は予めわか
っており、フィード・バッグ間の相違に基く。また、ち
ょうどコントロールの前に出力に送られた前のコマンド
と同様にセットポイントもＰＩＤ処理４６−７に転送さ
れる。補助信号スイイッチイネーブル属性がセットされ
たり、あるいは、ＰＩＤ処理からコマンドを受信するこ
とができる出力がすべて指定変更された場合は常に、Ｐ
ＩＤ処理４６−７はトラッキングモードに入る。トラッ
キングモードにおいて、ＰＩＤ処理４６−７はＰｔｅｒ
ｍ（ｔ）を計算し続けることによって、バンプレス転送
を準備する。出力の１つが指定変更条件から解除された
り、あるいは、補助信号スイッチイネーブル属性がリセ
ットされた場合、ＰＩＤ実行タスクは、出力に得るよう
に命じた値を得させ、バンプレス転送を実行するために
前の半服から求められるＰｔｅｒｍ（ｔ）と共にそれを
使用する。Ｈａｎｄ／Ｏｆｆ／ＡｕｔｏスイッチがＨａ
ｎｄあるいはＯｆｆの位置にあることによる指定変更の
場合には、この最後の命じられた値は利用可能ではな
い。したがって、一度スイッチがＡｕｔｏ位置に返され
れば、バンプレス転送は提供されない。高低飽和限度界
入力４６−１２および４６−１５は、典型的には出力を
１００パーセントとしたスケールにおいて、パーセント
で表示されるように指定して、ＰＩＤ処理の出力へのコ
マンドが留まらなければならない境界を指定する。ＰＩ
Ｄ処理４６−７は、いつＰＩＤ処理が飽和したかを決定
し、知らせる機構を提供する。すなわち、ＰＩＤ処理は
出力に命令してセットポイントに届かせることはできな
い。ＰＩＤ処理は４０回の連続する反復のための出力コ
マンドが、高飽和度極限値４６−１３の１％以内にあっ
た場合、あるいは、４０回の連続する反復出力は、低飽
和度極限値４６−５の１％以内にあった場合に、飽和し
たと決められる。一度ＰＩＤ処理が飽和したと決められ
たならば、高飽和度フラグ４６−４７あるいは低飽和度
フラグ４６−４９のいずれかがその事実を告知するため
に適宜にセットされる。これは、ＰＩＤデータベースタ
スクに状態メッセージの変更を順番に出させ、その結
果、ネットワークコントローラ（ＮＣ）のファンクショ
ンがそれに応じて適宜に行動する。一度補助信号イネー
ブルフラグ４６−５５がセットされるか、あるいは、す
べての出力が指定変更条件に置かれると、これらのフラ
グはリセットされる。飽和度回復は、さらにＰＩＤ処理
４６−７によって提供される。一度処理が高飽和限度界
および下限に指定された値以上の出力を命じようとして
も、積分動作が“ワインドアップ”しないように、処理
は設計される。ＰＩＤ処理４６−７の実行後、ＰＩＤ実
行タスクは、このＰＩＤに対するＰＩＤ処理の次の反復
に必要とされるすべての最新の中間結果と共に、ＰＩＤ
出力値属性４６−５３に対する新しい値を含んでいるＰ
ＩＤデータ・ベース管理プログラムタスクにメッセージ
を送信する。その後、ＰＩＤＥＸＥＣタスクは他の専用
処理を呼び出してもよい。この呼出しは他方の進行中の
処理を保留するであってもよいし、あるいは、それは、
ＰＩＤ処理の現在の反復にデータを提供するであっても
よい。プロセスループが不安定であると決められた場
合、専用処理を保留する呼出しが送られる。あるいは、
それが決定された場合、ＰＩＤ処理４６−７は、故障許
容処理と関連して以下に議論されるようなＰＩＤループ
の出力のコントロールを持っていない。ＰＩＤループが
信頼性がないと決められた場合、次の条件が示される。
ＰＩＤ処理はトラッキングモードにあり、出力４６−５
７へ補助信号入力４６−１７を渡すために補助信号スイ
ッチ処理４６−１９が補助信号スイッチイネーブル属性
４６−５５に命令されているか、高／低信号選択処理４
６−２３が高／低信号入力４６−２１を選択している。
前記条件のどれも存在しない場合、ＰＩＤアルゴリズム
の現在の反復の適切なデータが、一層の処理を行なうた
めにコールで送られる。ＰＩＤ処理４６−７の出力から
正常に来る信号の４６−５３の代りに信号を挿入するた
めに、ＰＩＤ処理を迂回することも可能である。６つの
スケーラ４６−１１がすべて０である場合、ＰＩＤ処理
４６−７は迂回され、オフセット４６−９の値はＰＩＤ
出力値属性４６−５３として使用される。ＰＩＤループ
オブジェクト４６−２はさらに、補助信号スイッチ処理
４６−１９、出力フィルタ処理４６−４３、および高／
低信号選択処理４６−２３の状態に従ってＰＩＤループ
の出力を達成することができると規定する。ＰＩＤデー
タ・ベース管理プログラムタスクが、これらのアルゴリ
ズムの入力の１つを変更する書込み属性メッセージを受
信するか、ＰＩＤループに対するＰＩＤ実行タスクが実
行を終了しており、ＰＩＤループの構成に対してそれが
行なった変更のチェックするＰＩＤデータ・ベース管理
プログラムにメッセージを送信した場合、これは発生す
る。補助信号スイッチ処理４６−１９は、補助信号イネ
ーブルフラグ４６−５の状態を検査する。フラグがセッ
トされた場合、補助信号入力４６−１の値は補助スイッ
チ値属性４６−５７に渡される。補助信号入力４６−１
７が信頼性を持たない場合、最後の信頼性がある補助ス
イッチ値４６−１７はパスされる。補助スイッチイネー
ブルフラグ４６−５５がリセットされた場合、ＰＩＤ出
力値属性４６−５３の値は補助スイッチ値属性４６−５
７に渡される。出力フィルタ処理４６−４３は補助スイ
ッチ値属性４６−５７からその値を受信し、その値によ
り第１順序フィルタリングを実行する。出力は出力フィ
ルタ値属性４６−５９に置かれる。フィルターウエイト
属性４６−６１は、フィルターの有効性を定義するため
に使用され、１．０から＋１０２３をカバーすることが
できる。ここで１．０というフィルターウエイトはフィ
ルタリングを有効に不能にする。フィルタリングは次の
方程式に従って実行される： 出力フィルタ値＝前のフィルター値＋（（１／フィルタ
ーウエイト）＊ＰＩＤ出力値−前のフィルター値））。 前のフィルター値とは一番最近の反復時に計算された値
である。上記の方程式は、サンプル周期毎に、あるいは
補助信号入力４６−１７が変更されるごとに、あるいは
スケーラがすべて０になったとき、オフセット４６−９
が変更されるごとに計算される。前の反復のデータがた
よりにならなかったために、あるいはそれがこの例に対
する処理による第１パスであるために、前のフィルター
値が存在しない場合、補助スイッチ値４６−５７が、出
力フィルタ値属性４６−５９に直接渡される。フィルタ
ー出力を計算する間に数学的エラーがある場合、最後の
信頼性がある出力フィルタ値属性４６−５９が出力フィ
ルタ値に出される。高／低選択処理４６−２３は出力フ
ィルタ属性値４６−５９を高／低信号入力４６−２１の
値と比較する。高／低選択状態属性４６−６３がセット
されると、２つの入力値の大きいほうが高／低選択値属
性４６−６５に渡される。高／低選択状態属性４６−６
３がリセットされると、２つの入力値４６−２１と４６
−５９の小さいほうが渡される。高／低信号入力４６−
２１に信頼性がない場合、ＰＩＤループ無信頼性フラグ
が高／低選択値属性にセットされ、その最新の信頼値で
残るだろう。高／低信号入力４６−２１が選択される場
合、高／低選択フラグ属性がセットされる。このフラグ
の状態の変更により、リポートがＮ２バスを通じて送ら
れる。信頼性スイッチ処理４６−６７は、ＰＩＤループ
の出力４６−２５へ出されるコマンドの信頼性を反映し
ている。ＰＩＤループに対する処理を行なっている間、
万一ＰＩＤループのうちのどれかに対する入力データが
信頼性をもたなくなった場合、この処理の出力値が、ル
ープに対する最新の信頼性のある出力値で残る。さら
に、ＰＩＤループ信頼性フラグ４６−４５は、高／低信
号属性４６−６５によって供給されるデータが信頼性の
ない場合は常に、信頼性を持たなくなる。下記条件のう
ちのいかなるものでも発生した場合、このフラグは、さ
らに信頼性のない状態にセットされる： １．補助信号イネーブルフラグ４６−５５の条件が、Ｐ
ＩＤループの出力へ補助信号入力４６−１７を送るため
にセットされ、かつ、補助信号入力４６−１７が信頼性
を持たない場合。 ２．ＰＩＤ出力属性４６−５３が、補助信号スイッチ処
理４６−１９を通じて送られ、かつ、ＰＩＤ出力属性４
６−５３を生成するために使用される計算が、信頼性が
ないと決定される場合。ＰＩＤ処理４６−７によって使
用されるポートのうちのいかなるものでも信頼性のない
データを受信する場合、あるいは０による除算のような
数学的エラーが計算の間生じた場合、これらの計算は信
頼性がないものと考えられる。高／低信号の選択処理４
６−２の実行に続いて、ＰＩＤデータベースはＰＩＤル
ープ信頼性フラグ４６−４５をチェックする。このフラ
グが信頼性がある場合、ＰＩＤデータベースは、与えら
れたＰＩＤループ定義に対して指定される出力へ出力コ
マンドを出す。ＰＩＤループが信頼性がなく、信頼性の
ない応答セレクタフラグ４６−６９がリセットされる場
合、ＰＩＤデータベース管理プログラムは、高／低信号
の選択処理４６−２から出力まで最新の信頼性のある出
力コマンドを出す。そうでなければ、それは、出力へ信
頼性省略時属性４６−７１によって指定されるコマンド
を出す。ＰＩＤデータ・ベース管理プログラムタスク
は、出力値属性４６−７３によって指定される、適切な
オブジェクトデータ・ベース管理プログラムに書込み属
性コマンドを送る。次の値が、実行の完了時にＰＩＤ処
理４６−７によって供給される。ＰＩＤデータ・ベース
管理プログラムタスクは、現在のＰＩＤループデータベ
ースがこれらの変更を反映することを保証する。ＰＩＤ
出力値は、セットポイント値に向けて被制御変数を駆動
させる出力ポイントに出されるコマンドである。それ
は、０．０および１００％の偏向の間のフルスケールパ
ーセントと思われるものであってもよい。ＰＩＤ処理信
頼性フラグ４６−５１は０か１かのどちらかであり、計
算時にエラーが生じたかどうか、あるいは、ＰＩＤ処理
４６−７によって使用されるポートの１つが信頼性のな
いかどうかを示す。ＰＩＤループ信頼性フラグ４６−４
５は０か１かのどちらかであり、０を示す場合、ＰＩＤ
ループの出力に送られているコマンドが信頼性のあるデ
ータに基くことを示す。追加ループパラメータは、ＰＩ
Ｄ処理４６−７の次の実行に対して返される。これらの
パラメータは、微分係数コントロールに対するフィード
・バック値、積分動作およびバンプレス転送に対する積
分項、ヒステリシス削除に対するヒステリシス構成偏
り、ヒステリシス削除に対する出力値、および出力値
（ヒステリシス削除、セットポイントとフィード・バッ
ク値の間で計算された前回フィード・バック値とエラー
に対して増加＝１、減少＝−１）の指示を含んでいる。
言語はまたパイをプログラムされる比例積分計算によっ
てセットポイントをリセットするように設計されるＰＩ
機能を有する。それは、閉じたループシステムにおける
使用のために設計される。図４７において概略的に示さ
れるコントロールシステム４７−１は、４７−５ライン
経由で入力を受信し、４７−７ライン経由で制御変数を
生成するフィード・バック変数として頻繁に知られる入
力装置４７−３を持つ。制御変数は、ラインで４７−７
においてオブジェクト４７−７のための比例積分微分
（ＰＩＤ）装置への入力を生成し、オブジェクト４７−
１１へ故障許容コントロール戦略を提供する。この場合
に、典型的なオブジェクトは、コントロールループのた
めの望ましいファンクションを実行するハードウェアと
ソフトウェアとの組合せを含んでいる。そのようなオブ
ジェクトは、典型的にはソフトウェアによってインプリ
メントされ、ネットワークとして作動する１つ以上の自
動処理コントロールノード４７−２のメモリ部分に格納
される。本発明に従ったハードウェアおよびソフトウェ
アオブシェクトを持つシステムの構造についてはすでに
説明した。ＰＩＤループ４７−４は、典型的にはコント
ロールノード４７−２中の故障許容コントロール戦略オ
ブジェクト４７−１１からの援助なしに正常な環境下で
作動するように組立てられる。ＰＩＤオブジェクト４７
−９はＰＩＤループ変数４７−１３を生成し受信し、さ
らに入力をさらにまた故障許容コントロール戦略オブジ
ェクト４７−１１へ入力を行ない、かつ、これから出力
を受信する。ライン４７−１５上のＰＩＤ出力は、故障
許容コントロール戦略オブジェクト４７−１１とスイッ
チ４７−１７との双方に伝えられる。ライン１７−１９
上の出力デバイスコマンドは、コマンドに基いた故障許
容コントロール戦略オブジェクト４７−２の出力と、Ｐ
ＩＤ出力との間でこのように切替えることができる。こ
の切替えは故障許容出力コントロール戦略によって生成
されるライン４７−２３上のコマンドに従って行なわれ
る。オブジェクト４７−１の故障許容戦略はまた、ライ
ン４７−２５上のプロセス定数を受信するとともに、ラ
イン４７−２７上の別の出力を受信する。この出力は入
力信号４７−３１を受信する入力装置４７−２９によっ
て生成される。ライン４７−１９上の出力デバイス駆動
コマンドは、スイッチ４７−１から与えられ、ライン４
７−３５上に関連する操作量を生成する操作量駆動出力
装置４７−３３を編成する。ライン４７−３５上の関連
する操作量はプロセス４７−３７に入力されこのプロセ
スは、入力装置４７−３および４７−２９へのライン４
７−５およびライン４７−３１上の信号の生成によっ
て、コントロールループを完成する。コントロールルー
プの目的は出力デバイスを制御しかつ希望のプロセス４
７−３７を遂行するために、ライン４７−１９およびラ
イン４７−３５上の操作量を生成することである。正常
なオペレーションにおいては、ＰＩＤコントロールが遂
行され、スイッチ４７−１７は信号４７−２３を介して
ＰＩＤ出力４７−１５ラインにセットされる。したがっ
て、故障許容コントロール戦略オブジェクト４７−１１
は、単にライン４７−９上の制御変数の状態をモニター
するのみでループの実際のコントロールに参加しない。
ライン４７−７上の制御変数をモニタして制御変数が値
の信頼性がある範囲内にあることを確認する。ライン４
７−１１上の故障許容戦略オブジェクトが、ライン４７
−７上の制御変数すなわちフィード・バック変数が、信
頼性がある範囲内にもはや存在しないと判断すると、ラ
イン４７−１７上の故障許容コントロール戦略オブジェ
クトは、ライン４７−２１上の故障許容コントロール戦
略オブジェクト出力を、ライン４７−１９上の出力デバ
イスコマンド信号に送るようにスイッチ４７−１７に命
令する。これはスイッチコマンド４７−２３ラインを介
して行われる。この時点で、ライン４７−２５上のプロ
セス定数ならびに信号４７−２７に基いて故障許容コン
トロール戦略オブジェクト４７−１１は戦略を構成す
る。この戦略はフィードバックすなわちライン４７−７
上の制御変数がもはや信頼性を有していない場合にも関
連する操作量の調製を続行するものである。したがっ
て、ＰＩＤコントロールループにおけるフィード・バッ
クの損失は、出力デバイス４７−３３を通じてのコント
ロールあるいはライン４７−３５上の操作量のコントロ
ールのロスを生じない。プロセス４７−３７からの、ラ
イン４７−３１上の信号をモニタする入力装置４７−２
９を通じて、故障許容戦略オブジェクト４７−１１は、
プロセス定数４７−２５と共にプロセス４７−３７にお
ける動的偏光に応答する。それによりライン４７−１９
およびライン４７−３５上の操作量を制御するための信
号が生成される。したがって、失敗した条件下において
も、失敗の効果を最小値限にするプロセス４７−３７を
通じて管理水準を保持することは、可能である。１つの
例において、故障許容コントロール戦略は、暖房、冷却
および混合空気放出−温度コントロールを含む典型的な
ＨＶＡＣプロセスをアドレスする。図４８は、故障許容
コントロール戦略をインプリメントするフェースを示
す。これらはコミッショニング４８−１、初期設定４８
−３、プロセスモニタリング４８−５およびコントロー
ル４８−７を含んでいる。図４９は、故障許容コントロ
ール戦略をインプリメントする際のプロセス入力および
出力を略示する。コミションニング４９−３０１の期間
中、故障許容コントロール戦略オブジェクトはパラメー
タが故障許容コントロール戦略オブジェクト４７−１１
にアクセス可能なメモリのどこに格納され、いかなるパ
ラメータが制御されているプロセスにとって重要である
かについての情報を受ける。例えば、空気温度および流
量パラメータは冷水バルブを開くべきか閉じるべきかを
決定するために、使用されてもよい。したがって、初期
のコメッショニングにより、故障許容コントロール戦略
の中で使用される変数が決定される。ＨＶＡＣシステム
の中で使用される故障許容コントローラにおいては、３
つのクラスの情報あるいはパラメータがある。第１は各
ＰＩＤループにとって同一である変数４９−３０の静的
セットである。これらはセットポイント、比例帯および
制御変数を含んでいる。パラメータの第２セットは得ら
れた実際のアナログ入力であるプロセス変数４９−３０
５である。これらはＨＶＡＣプロセス４９−３０７に依
存して、異なる。例えば、他のものが水温度あるいは圧
力を要求しているのに対して、いくつかのＨＶＡＣプロ
セスは戸外の空気温度を要求する。最後のパラメータと
して、システム性能をモニタするために使用される物理
的な装置に依存するＰＩＤループであるプロセス定数４
９−３０９がある。故障許容コントロール戦略オブジェ
クトをインプリメントする場合においては、ＰＩＤルー
プの構成に関する情報を提供することも必要である。こ
れは、プログラミング言語で故障許容コントロール戦略
をプログラムすることによって、あるいはグラフ式のプ
ログラミングツール４７−３１のユーザブロックとして
のいずれかで、行うことができる。一方の場合、ルーチ
ンは、故障許容コントロール戦略オブジェクトによって
アクセスすることができ、コントロールノード中で実行
することができることができる、コントロールシステム
データベースに加えられる。初期設定フェース４９−３
１の間、故障許容コントロール戦略オブジェクト４９−
１１においてルーチンは、プロセス定数および静的ＰＩ
Ｄループに関するデータを集めて、安定チェック４９−
３１５を実行する。先に述べたように、定数はハードコ
ード化することができ、故障許容コントロール戦略オブ
ジェクト中に一度読まれる必要があるだけである。３つ
のクラスＰＩＤループパラメータは制御されるプロセス
の最も最近の状態を表す。以前に議論された、委任する
フェースは、これらのパラメータがメモリにどこで設置
するかについての情報を提供する。初期設定の間、パラ
メータは故障許容コントロール戦略ソフトウェアオブジ
ェクトによって読まれる。その後、初期設定は、プロセ
ス制御のために必要とされる一連の信頼しうる静的パラ
メータ４９−３１７を得ることができることを確認す
る。これは信頼性があるＰＩＤ空電データの十分なセッ
トが故障許容コントロール戦略の実行を許可するのに、
必要であるからである。初期設定、すなわちフェース４
９−３１３は、変数あるいはパラメータよりもＰＩＤル
ープ制御の安定を確認する。被制御変数がセットポイン
トに接近しているままであり、操作量のバリエーション
が小さな場合、ＰＩＤループは安定している。初期設定
フェース４９−３１の一部として、発振およびスラギッ
シュネス４９−３１の前もって定義した数の測定値が、
コントロールループの性能に対して評価される。モニタ
フェース４９−３２の間、故障許容コントロール戦略オ
ブジェクト４７−１１は安定したプロセス制御を推定
し、静的ＰＩＤ変数およびプロセス変数を更新する。モ
ニタフェースの間実行される主要なファンクションは制
御変数４７−の信頼性の評価あるいはＰＩＤループのフ
ィード・バックである。これは例えば、フィード・バッ
クが多次元なもので在る場合、ＰＩＤループそれ自身中
のいくつかの物理的なアナログ入力に基いたものであっ
てもよい。このフィード・バック、ライン４７−７上の
制御変数が信頼できないものになった場合、オペレーシ
ョンの制御モードが入力される。実際のフィード・バッ
クあるいは制御変数をモニタすることが絶対に必要では
ないことが注目される。制御変数４７−７は制御変数を
生成するソフトウェアオブジェクトの出力であってもよ
い。この場合、制御変数を生成するソフトウェアオブジ
ェクトへの入力のうちのいかなるものでも、信頼性を失
った場合に、制御変数は信頼性を失ったと判断される。
したがって、制御変数を生成するソフトウェアオブジェ
クトへのアナログ入力が開いたこと、あるいはショート
したことを検知される場合、あるいは正当でない値が、
ソフトウェアオブジェクト（たとえば、０による除算）
データ操作の間生成される場合、故障許容コントロール
戦略は、制御変数４７−７あるいはフィード・バックが
信頼性を失ったと仮定する。制御ファンクション４９−
３２３が入力される場合、故障許容コントロール戦略オ
ブジェクト４７−１１は、ＰＩＤアルゴリズムによって
生成される値の代りに使用される値を計算する。先に述
べたように、これは基本的に、システムおよび変数の現
在の状態のモデルに基いて開いたループ制御である。プ
ロセス変数と計算される出力コマンド間の直線性の要件
は必須のものではない。 システムが、プロセス４７−
３の現在の状態に応答するので、以下に与えられた方程
式に示されるように、セットポイントにおいて変更に応
答することもまた可能である。故障許容コントロール戦
略オブジェクト４７−１１が、ＰＩＤコントローラと同
じレートでコントロールを実行することを試みてもよい
ことに注意すべきである。しかしながら、ほとんどの場
合、コントロールは、ネットワーク性能の制限のために
より遅いだろう。前述したように、故障許容コントロー
ル戦略オブジェクト４７−１１コントロールは、通常、
ループの一部であるＰＩＤ装置においてではなくコント
ロールノードにおいて達成される。したがって、ＰＩＤ
ループとコントロールノード間のローカル・バスを通じ
ての、および恐らく複数のコントロールノード増加を相
互に連結させるネットワークバスを通じての複数の通信
は、故障許容コントロール戦略下においてループ応答時
間を増大する。以前に議論したように、故障許容コント
ロール戦略は、部分的にコントロールプロセスのモデル
に基くことができる。故障許容コントローラブロック
は、ＰＩＤコントローラ２０のサンプリング周期ごとに
一度実行される。プロセスモニタおよび出力スイッチフ
ァンクションはＰＩＤコントローラの各抽出間隔中一度
実行される。図５０に示される１つのシステム構成にお
いては、故障許容コントローラファンクションがネット
ワークコンローラ中にインプリメントされているのに対
して、プロセスモニタおよび出力スイッチのファンクシ
ョンはディジタル制御モジュール中に直接インプリメン
トすることができる。故障許容コントロール戦略をイン
プリメントするのに必要とされる様々な変数はテーブル
１においてリストされる。 テーブル１ 入力 １．ＳＰ：セットポイント変数（レファレンス変数） ２．ＣＶ：被制御変数（フィールド・バック変数） ３．ＭＶ１：主要な操作量（コントロール出力変数） ４．ＭＶ２：第２の操作量（対話するコントロール出力
変数） ５．ＰＶ１：主要なプロセス変数（フィールドフォワー
ド変数＃１） ６．ＰＶ２：第２のプロセス変数（フィールドフォワー
ド変数＃２） ７．ＰＢ：コントローラ比例帯 ８．ＡＴ：コントローラサンプリング周期 ９．ＯＵＴ：コントローラ高飽和限度 １０．ＯＵＴ：コントローラ低飽和限度 １１．ＢＡＮＤ：コントローラエラー許容差 出力 １．フラグ：故障許容イネーブルフラグ ２．バックアップ：故障許容出力 ローカル変数 １．ＣＶｏ：レファレンス被制御変数 ２．ＭＶ１ｏ：第１操作レファレンス ３．ＭＶ２ｏ：第２操作レファレンス 変数 ４．ＰＶ１ｏ：第１プロセス変数レファレンス ５．ＰＶ２ｏ：第２プロセス変数レファレンス ６．ＰＢｏ：レファレンスコントローラ比例帯 図５２は発明の故障許容コントロールのより詳細な例で
ある。ＰＩＤコントローラ５２−１、プロセスモニタ５
２−３および故障許容コントローラ２−５はすべて、セ
ットポイントＳＰおよび制御変数ＣＶを受信する。ＰＩ
Ｄコントローラ５２−１、プロセスモニタ５２−３およ
び故障許容コントローラ５２−５はすべて、以下により
詳細に議論される個々の処理を実行する。システム中の
条件に基いて、故障許容コントローラ５２−５は、出力
スイッチ５２−７へのルートである、フラグ出力を生成
する。さらに、誤りコントローラ５２−５は、出力スイ
ッチにさらに送られる、バックアップ出力を生成する。
バックアップ出力は次の方程式によって決定される：Ｍ
Ｖ１＝ＭＶ１＃＋ＥＦＦ＊（ＭＶ２−ＭＶ２＃）＋（１
００％ＰＢ＃）＊（ＳＰ−ＣＶ＃＋（ＥＦＦ−１）＊−
ＥＦＦ＊−（ＰＶ２−ＰＶ２＃）−（ＰＶＰＶ１
＃））；ＥＦＦを２０％−８０％の範囲に制限。出力ス
イッチへの他方の入力はＰＩＤコントローラ２−１にお
いて産み出される操作量ＭＶ１である。正常な環境下、
つまりシステムが誤りを犯していない場合、故障許容コ
ントローラ５２−５はスイッチ５２−７の出力がＰＩＤ
コントローラ５２−１から主要な操作量であるようなフ
ラグをスイッチ５２−７に出力される。一般に、操作量
は、図４７に示されるようなＰＩＤプロセス１の出力に
想到する。誤り条件がシステム中に存在する場合、フラ
グは故障許容コントローラ５２−５からその出力までバ
ックアップ信号を送るために、出力スイッチ５２−７を
作動させる。図４７に示されるように、スイッチの出力
は出力デバイスを駆動させるために使用することができ
る。したがって、プロセス制御ループ中の失敗は故障許
容コントローラによって収容される。したがって、出力
デバイスは不良状態でも使用可能のままである。図５３
Ａおよび５３Ｂは、プロセスモニタ５２−３において起
る処理を例示する。典型的に、プロセスモニタはディジ
タル制御モジュール中において作動する。ネットワーク
コントローラは３０のディジタル制御モジュールで可能
なモニタレートのより２０分の１のレートの遅いプロセ
スを典型的に実行する。したがって、プロセスモニター
中の処理は、実行がネットワークコントローラ中に起っ
たかどうかに左右されて、異なる。処理を始めるより以
前に、ここに議論されるように、制御変数が信頼性があ
る場合、それは、テストブロック５３−７３において最
初に決定される。そうでなければ、ブロック５３−７１
に示される変数はセットされ、コントロールはブロック
５３−７３をテストするために返される。テストブロッ
ク５３−１において、プロセスモニタは、間隔がディジ
タル制御モジュールの２０倍以上のプロセスレートかど
うか最初に決める。この条件が満たされない場合、操作
量がモニタプロセスによってすでに検知され格納される
最大値、および最小値の出力を超過するかどうか決める
ために、ブロック５３−３および５３−５に示されるよ
うに、操作量がテストされる。操作量が格納される値を
超える場合、適切な最大値および最小値の出力はファン
クションブロック５３−７および５３−９において操作
量と等しくされる。いずれの場合にも、ファンクション
ブロック５３−１１において、エラー値はセットポイン
トから制御変数を引いた値の絶対値として決められる。
このエラーがプロセスによって以前にモニタされたエラ
ーの最大値を超過する場合、ファンクションブロック５
３−１３および５３−１５に示されるように、エラーの
最大値はこのエラーと等しくされる。間隔がファンクシ
ョンブロック５３−１中でのディジタル制御モジュール
の処理時間の２０倍を超過すると決められるまで、上記
のプロセスは繰り返され続ける。この時点でコントロー
ルは、システムが飽和しているか否か、また、出力が安
定していかどうかを決める他のファンクションブロック
に移行する。以前に議論された処理期間中以前に決定さ
れたような最大値出力が、プロセスための高く定義され
た出力を１パーセント下回る値を超過する場合、高飽和
度変数がインクリメントされる。そうでなければ、完全
なファンクションブロック５３−１９および５３−２１
に示されるように、変数は０に等しくされる。同様に、
前述のような極小出力が、ブロック５３−２３に示され
るように、あらかじめ定められた出力低変数の限界を超
える場合、ファンクションブロック５３−２５と５３−
２９に示されるように、低飽和度フラグがインクリメン
トされるか、０に等しくセットされる。ファンクション
ブロック５３−３１で、飽和度変数のどちらかが１を超
過するか否かが決定される。１を超過する場合、ブロッ
ク５３−３３において示されるように、飽和度フラグは
“真である”にセットされる。そうでなければ、ファン
クションブロック５３−３５に示されるように、飽和度
フラグは“偽”にセットされる。その後、プロセスモニ
タ中の処理が進められ高い出力および低い出力の範囲の
特定のパーセンテージを超える偏差の数を識別される。
例えば、ファンクションブロック５３−３７は、最大値
出力とプロセスの最小値の出力の間の差が許可される高
い出力および低い出力の１５％を超過するか否かを決定
する。超過しなければ、偏差変数はファンクションブロ
ック５３−４１において０に等しくされる。しかしなが
ら、差が高低出力間の許される差の１５％を超過する場
合、ファンクションブロック５３−３９に示されるよう
に、偏差変数はインクリメントされる。同様に、５％を
超える偏差がどのように数えられるかを、ファンクショ
ンブロック５３−４９、５３−５１および５３−５３が
示し、ファンクションブロック５３−４３、５３−４５
および５３−４７は、９％から偏差の係数を示す。最大
値と最小値の出力の間の差が指定される範囲内にあるご
とに、偏差変数が０までリセットされるので、偏差のカ
ウントは特定の範囲を超える変化が連続して超える場合
にのみインクリメントされる。ファンクションブロック
５３−５５はプロセスが安定しているかどうか決めるた
めに使用される。５％を超える偏差の係数値が９より大
きいとき、９％超える偏差の計数値が５より大きいと
き、あるいは、１５％超える偏差の係数値が３より大き
いときには、ファンクションブロックは「ＳＴＡＢＬ
Ｅ」変数を“偽”状態にセットする。これは、システム
が安定していないことを示す。これらの偏差が受信可能
な範囲内にあり、その後、機能する場合、ブロック５３
−５９は、エラーの受信可能な範囲を定義する、帯変数
と最大値のエラーを比較する。最大値のエラーが帯変数
によって指定される範囲外である場合、プロセスは、不
安定であると考えられる。そうでなければ、ファンクシ
ョン５３−６１に示されるように、プロセスは安定して
いると考慮される。ファンクションブロック５３−６３
は、プロセスモニタ実行にコントロールを返す前に変数
をリセットする。出力極小および最大値が１００％およ
び０％にそれぞれ典型的にセットされることに注意すべ
きである。これは、操作量が、フルスケールに対する１
パーセント値の形で提供されると想定してのことであ
る。しかしながら、操作量を調節するために他の任意の
配置を行なうことが、発明の精神内で可能であろう。図
５４は、故障許容コントローラオブジェクト中における
処理を例示する。以前に議論された間隔が終了していな
い場合、ファンクションブロック５４−１に示されるよ
うに、ファンクションブロック５４−３は間隔を単に更
新し、それ以上、処理は起らない。しかしながら、間隔
が終了した場合、故障許容コントロール処理は発生す
る。最初に、ファンクションブロック５４−５に示され
るように、間隔は０までリセットされる。次に、制御変
数の信頼性状態はファンクションブロック５４−７にお
いてテストされる。その後、制御変数の状態が信頼性が
ある場合、故障許容コントロール処理はファンクション
ブロック５４−９に示されるように出力が飽和したかど
うか決めるために、チェックする。飽和した場合、出力
は、安定していると考えられる。また、それ以上、故障
許容処理は生じない。出力が飽和されない場合、ルーチ
ンは、ファンクションブロック５４−１１に移行する。
このブロックは、図５３と関連して議論されるようなプ
ロセスモニタによって以前に計算されたＳＴＡＢＬＥ変
数の状態をチェックするものである。ＳＴＡＢＬＥ変数
が“真でない”場合、それ以上処理は起らない。しかし
ながら、ＳＴＡＢＬＥ変数が“真である”場合、ファン
クションブロック５４−１３が、データが確実かどうか
決める。そうならば、ファンクションブロック５４−１
３は、制御変数、第１および第２操作量ＭＶ１およびＭ
Ｖのレファレンス変数、第１および第２プロセス変数Ｐ
Ｖ１およびＰＶ２、および、変数の現在を一致する値と
等しい比例帯ＰＢをセットする。したがって、故障許容
コントローラはこれらの変数の最も最新の値を受信す
る。フラグは、ファンクションブロック５４−２７に示
されるように、“偽”にセットされ、コントロールは間
隔をテストするためにファンクションブロック５４−１
に転送される。ファンクションブロック５４−７におい
て、制御変数状態が信頼性のないと決められる場合、そ
の後、故障許容コントロール処理はデータを検査する。
データが信頼性がある場合、セットポイント、主要なプ
ロセス変数、および第２の変数、ならびに第２の操作量
は、ファンクションブロック５４−１５において現在値
と等しくされる。ファンクションブロック５４−１７に
おいて、効率変数ＥＦＦはオブジェクトに格納されるレ
ファレンス第１操作量と等しい値にセットされる。この
操作量は０から１００％の全域に渡ってではなく２０か
ら８０％の範囲に制限される。その後、ファンクション
ブロック５４−２１は、スイッチ５２−７を出力するた
めに送信されるバックアップ値を計算する。バックアッ
プ変数を計算するための方程式がファンクションブロッ
ク５４−２１に示される。方程式が示すように、バック
アップ変数は、格納される比例帯のパーセンテージ中の
第２の操作量によって修正されるようなオブジェクト中
に格納される、主要な操作量の組合せである。ファンク
ションブロック５４−２３は、バックアップが、制御さ
れているプロセスのためのオブジェクト中に指定され
る、低出力と高出力の間の範囲にあるように、制限され
ることを示す。その後、ファンクションブロック５４−
２５において、フラグはその出力へのバックアップ信号
を送るように出力スイッチ５２−７に命令するのに、
“真である”とされる。その後、故障許容コントロール
処理はファンクションブロック５４−１に返る。図５５
は出力スイッチ処理を例示する。図５５において、フラ
グが真の場合、出力信号はスイッチ上のバックアップに
セットされる。しかしながら、フラグが故障許容コント
ローラ５２−５によって真にされていない場合、ファン
クションブロック５５−５は、制御変数の状態が信頼性
がないと認定する。その後、ファンクションブロック５
５−７に示されるように、スイッチで出力は、操作量の
前かまたは古い値に送られる。操作量の状態が信頼性が
あることがファンクションブロック５５−５に示されて
いる場合、古い操作量は新しい操作量と入れ替えられ
る。また、出力はファンクションブロック５５−９およ
び１１において新しい操作量と等しくされる。そうでな
ければ、操作量の古い値が使用される。これにより、ス
イッチの処理が終了する。上述の処理の結果、フィード
・バック変数が信頼性を失い出力が不安定化してエラー
が許容範囲から外れたとしても、プロセス制御ループが
下げられた状態のオペレーションを保持することが可能
である。全体的なエネルギー消費量を減少するために、
ファシリティマネジメントシステムのようなシステムは
ロードローリングおよびリクエストを制限すること（そ
れは時間を通じてロードに引起されるエネルギー消費量
の管理を試みる）を実行する。エネルギー消費量は、例
えば、プロセッサメーターで管理され、エネルギーを消
費するロード装置（すなわちロード）は選択的に停止さ
れるか、シェッドされる。発明１つのアスペクトに従え
ば、ロードシェディングはシステムの他の１つ以上のノ
ードによって制御されるロード、あるいはロードの要素
をシェッドするように作動する、第１ノードのハイレベ
ルの特徴でありうる。ノードが多重音源からエネルギー
消費量を管理することも可能である。例えば、１つの実
施例においては、特徴を流すロードをサポートするノー
ドは４個のエネルギーメーターをモニタする。ロードの
オペレーションをサポートし、要素をロードするノード
は、ロードシェディング機能をサポートするノードから
ロードシェディングコマンドを受信する。これに応答し
て、コマンドを受信したノードは負荷（ロード）を選択
的に停止する。ロードシェディング機能をサポートする
ノードとロードをサポートするノード間の通信への依存
は、ロード特定ノードの各々にリストアタスクを組入れ
ることによって解消される。例えば、図５１において、
第１ノード５１−１は、メータ−５１−５によってモニ
タされるシステムエネルギー消費量に応答するハイレベ
ルのロードローリング機能５１−３を含んでいる。モニ
タされるエネルギー消費量のレベルに基いて、ロードロ
ーリング機能５１−３は、エネルギー消費量の必要とす
る減少度を決定する。これは希望のエネルギー減少を達
成するため、ロードテーブル５１−７におけるエネルギ
ー消費量値と比較される。この結果現在作動中のロード
のうちどれを停止すれば所望のエネルギー消費が削減さ
れるかが決定される。ロードローリング機能５１−３は
ついでコマンドを高速Ｎ１バス５１−９に送出し、これ
を他のノード５１−１１および／若しくはノード５１−
１３によって読むことができる。ノード間の使用される
通信規約が発明のこのアスペクトに従ったファクターで
はないということに注意すべきである。例えば、第１ノ
ード５１−１からのコマンドは、特定の１つ以上のノー
ドに向けることができるしあるいは高速バス５１−９上
のすべてのノードに同報通信することもできる。ロード
ローリング機能５１−３からロードシェッドコマンドを
受けたノードは、ロードを処理し指定されたロードを停
止する。例えば、第２ノード５１−１１は、ロード５１
−１５と５１−１７の一方または双方を停止し、第３ノ
ード５１−１３はノード５１−１９と５１−２の一方又
は双方を停止する。第１ノード５１−１は、さらにそれ
が希望のエネルギー消費量を達成するために必要とさ
れ、停止されるべきロードの特定の組合せを禁止するよ
うにプログラムされる、他のいかなる規則も破らない場
合に２つ以上のノードからロードシェディングコマンド
を出すことができる。ロードを停止することに加えて、
第２と第３のノード５１−１１および５１−１３は適切
な時にオペレーションにロードを戻すために、ローカル
処理を実行する。そのような処理をローカルに実行する
ことは、ロードローリング機能を含んでいる第１ノード
５１−１からこの責任を解除する。これは、ノード５１
−１１に他のタスクを処理するための追加的な時間を割
当てて、ロードを停止したノードがロードローリング機
能を含んでいるノードとの通信を失っても、ロードが回
復したことを保証し、システム信頼性を改善する。ロー
ド回復処理がロードを制御するノードのローカライズさ
れるので、ロード回復はロードローリング機能から独立
して行なわれ、通信リンク５１−９あるいは、第１ノー
ド５１−１の失敗が生じたり、あるいは新しい情報をロ
ードが回復する以前に第１ノード５１−１にダウンロー
ドしたとしてもロードの回復の妨げにはならない。従前
のシステムにおけると同様に、ローカライズされた回復
はシェディング及び回復特性に従う属性を有するオブジ
ェクトを定義することによって行なわれる、これらの特
性をロードシェディングプロセスに組み込むことによっ
ては行なわれない。局限されるリストア処理は、特徴を
流すハイレベルのロードの処理をファンクションを分散
する。例えば、ノード５１−１１、５１−１３中のソフ
トウェアオブジェクト５１−２７、５１−２９の属性５
１−２３、５１−２５はそれぞれロード５１−１５、５
１−１７および５１−１９の回復特性を記述している。
典型的には、この特性はロードの作動後の最大オフタイ
ム、最小オンタイム、およびいくつかの安全機能を含
む。例えば、モニタされる温度が前もって定義したレベ
ルを超過する場合、ロードシェディングコマンドによっ
て切られていた冷却器を復活するようにしてもよい。し
たがって、シェディングを開始せしめたノードがシェド
されている他の特定のロードを制御していない限り、ロ
ードシェッド処理はネットワーク上に分散される。なぜ
ならば、ロードシェディングを開始したノードはシェッ
ドされたノードを作動状態に回復することを要求されな
いからである。発明の上記に関連する局面においては、
ノードにプログラムされる要求制限機能がピークリクエ
ストの既知の時間間隔の間前もって定義したターゲット
以下にエネルギー消費量レベルになるように機能する。
これは、ユーティリティが賞割合を装填する場合に、そ
のようなリクエスト周期の間エネルギー消費量を縮小す
ることによって、システム運転費を縮小する。例えば１
５分の間隔の間、制限が最後の１４分を通じてエネルギ
ー消費量を評価し、次の１分間の期間中、消費量が一定
のままだろうと想定するであってもよい。その後、機能
は、１５分の間隔の間のエネルギー消費量の合計を決定
する。そしてその後、ロードテーブル５１−７を使用し
て、上記の間隔の間あらかじめ定められ格納されるター
ゲット以下にエネルギー消費量レベルを保持するため
に、シェッドすることができるロードを特定する。本発
明によれば、要求制限機能は、前述したロードローリン
グと同様のソフトウェアオブジェクトアプローチを用い
て達成できる。これは、要求制限処理を分散し、ロード
を制御するノードに格納された、ローカル回復プロセス
によってロードの回復を行なうことを可能にする。要求
制限が行なわれる場合には、ソフトウェアオブジェクト
の属性がロードを回復するオペレータにより入力された
コマンドを示している場合には、ロードが回復されても
よい。例えば火災のような緊急の自体によって必要とな
った場合には、オブジェクトは早急な回復あるいはロー
ドシェディングを行なうことができる。図５６は、高速
バス５６−６を通じて互いに交信する複数のノード５６
−１、５６−３および５６−５を持つネットワーク構成
を示す。以前に議論したように、各々のノードは、スレ
ーブ・デバイス５６−９、５６−１１、５６−１３をロ
ーカルかあるいはスレーブバス５６−７を通じて作動さ
せてもよい。ローカル・バス５６−７上の雑音で開始さ
れるエラーを縮小するために、光バインディングを使用
することができる。そのような光バインディングは、ノ
ードに、バスリードに光学的に連結されなかったスレー
ブ・デバイスで開始される、信号雑音から実質的に分離
されたレベルを提供する。外部雑音ソースは、ＲＦＩ、
ＥＭＩおよび他のエラー要因を生じる。そのような光学
的分離の例が図５７に示される。図５７に示される一般
的な構成は、ＲＳ／４８５米国電子工業会社仕様と一致
している。追加雑音分離は図５７に示されるいくつかの
テクニックによって達成される。そのような１つのテク
ニックは、装置が高インピーダンス状態にある場合に、
直流バイアスをかけるため抵抗を引き上げ、あるいは引
き下げることである。このＤＣバイアスは、正の５ボル
トのソースに接続される、抵抗器Ｒ３８１、および、図
５７に示されるような通信地面に接続されるＲ３８２に
よって提供される。したがって、装置Ｕ４９におけるラ
イン駆動が高インピーダンスにあるとき、出力Ｊ１Ａ３
はＤＣレベルにバイアスをかけられる。その結果、信号
のラインに現れるローレベルの雑音は検知可能な入力を
生成しない。差のモード雑音は他方に、１つのワイヤか
ら極性でのような対の伝送／受信ワイヤｏｎ現れる雑音
である。ライン上に置かれたバイアス“スワンプアウ
ト”モード雑音の手段である。バイアスのない状態です
べてのノードで高いインピーダンスが生じているので、
ラインは実際に“浮動”状態にあるので上記のことが可
能になる。すなわち、雑音は、ラインの上に共通のモー
ドおよび差のモードの両方の形で容易に引起される。ラ
イン上に置かれたバイアスはこれらのライン上の差のモ
ード雑音を容易に“スワンプ”できる。コモンモードノ
イズは、アース土地に関しての等しい大きさのローカル
・バス（データ信号がそのワイヤ上に送られないので、
基準線はこの議論に含まれていない）の両方のライン上
に引起される雑音である。これらの雑音はアースのため
の経路を求めているので、オプトカプラによって分離さ
れる。回路はオプトカプラがブレークダウンするまでは
最大２５００ボルトまでの信号を処理し、ノイズを通過
させる。オプト分離器はトランスゾーブおよびＭＯＶ回
路によって保護される。したがって、６２．５ボルト
［５６Ｖ（ＭＯＶ）＋６．５Ｖ（ＴＲＡＮＳＺＯＲ
Ｂ）］を超えるコモンモードノイズは、ＭＯＶおよびト
ランスゾーブを経て直接アースに分流される。ノードの
光学分離部分にはいくつかの光アイソレータがある。光
アイソレータＵ５０は２つの一部を持つ。光アイソレー
タの第１部分は信号ＴＸＤＮを送信するのに反応する。
この信号は、Ｕ５０において対の光アイソレータ１つの
一部を駆動させる。この第１の一部の出力はＵ４９を駆
動させる。図８３に示すように、Ｕ４９はラインセンダ
ーおよびラインレシーバを含んでいる。さらに、リトリ
ガー可能なワンショットＵ５１は、ソースへの転送信号
ＴＸＤＮに応答して、電源をＬＥＤまたはノードガデー
タを送信していることを示す他のインディケータに送
る。転送モードにおいて、Ｕ４のラインセンダー部分
は、スレーブ・デバイスを駆動させるバスのプラス又は
マイナスラインに信号を提供する。図８３に示されるよ
うに、バスに接続されたプラス及びマイナスの信号線
は、Ｕ４９のレシーバ部分によって受けとられる信号を
送信し受信するのに用いられる。その後、ラインレシー
バ駆動光アイソレータＵ５３．Ｕ５の出力はノードに受
信信号ＲＸＤＮを提供する。受信信号は、さらにリトリ
ガーできるものに放たれたＵ５の別の一部を駆動させ
る。これはノードがデータを受信していることを示すた
めに発光ダイオードであるいは他のインディケータに連
続した駆動電流を提供する。リトリガーできる１つの発
射が転送に連続した現在を提供し、インディケータを受
信することに注意すべきである。そうすれば、データ遷
移が伝送あるいはデータの受け取りで生じている間、イ
ンディケータは絶えず点滅する。これは信号の送信受信
につれてインディケータが明滅する従来の手法とは異な
るものである。この点滅を行なうとノイズが生じるが、
本発明ではこのような問題は生じない。図が＋５Ｃおよ
び＋５Ｄ電源を示すことに注意すべきである。＋５Ｄ電
源がディジタル電源であるのに対して、＋５Ｃの電源は
通信機構用電源である。個別の電源が雑音の効果をさら
縮小するために使用される。電源１つの失敗を示す信号
は、光アイソレータＵ５２によって産み出される。この
光アイソレータは光を、ディジタル電源に接続される通
信機構用電源、および軽量受信部分に接続される部分を
放射するとする。＋５Ｃのソースが悪くなる場合、パワ
ーＬＥＤは、オプトカプラ“受信光”部分で信号の変更
故に消灯する。その信号は力ＬＥのｆ回転させるために
論理によってゲート制御される。＋５Ｄが悪くなる場
合、それが＋５Ｄ電源によって運転されるので、パワー
ＬＥＤは消灯する。オプトカプラは互いから両方の電源
を分離する。したがって、一方の電源の失敗は、ノード
中での失敗の標識を産み出すだろう。これは、通信機構
用電源の失敗が受信モードで認識されず、伝送の欠除か
ら転送モードにおいて認識されるだけの、従来のアプロ
ーチと区別されるさらに、光アイソレータＵ５の軽量受
信部分に＋５Ｄ電源を使用することによって、追加雑音
余裕度は達成される。これは通信電源がさらに信号を示
す失敗から絶縁であるからである。＋５Ｄ電源には、結
晶の使用および高速ＣＭＯＳゲートの速い論理スイッチ
ングのために高周波雑音が存在する場合もある。＋５Ｃ
の電源にはローカル・バスで外部からもたらされる雑音
がある。これらの雑音は最大２５００ボルトのピーク値
まで許容され、システムのオペレーションへ影響を及ぼ
すことはない。最終的に、本発明は、スレーブ・デバイ
スを駆動させるバスでデータの、伝送、および受け取り
の両方のための単一の１対の信号ラインのその使用によ
って従来のシステムと識別される。最後になるが、シス
テムを、ここに記述されるような態様で作動させる命令
を定義する指標は、プロセッサによって使用されるＥＰ
ＲＯＭあるいは他の適切な記憶媒体中に格納されるであ
ってもよい。作動命令は、例えば、作動命令をプロセッ
サをシーケンスするために揮発性メモリが使用されると
きにはその様なメモリーに送るための定義する標識を持
つ磁気記録媒体等に収容してもよい。磁気記録媒体は、
メモリーのパワーが喪失したときにも将来の使用に備え
て保持される。そのような記録媒体やプロセッサは当業
者によく知られているものであるので詳述しない。以上
に発明の実施例を説明したが、図示され、記述された特
定の実施例に対して、添付の請求の範囲に記載された発
明の精神や範囲から逸脱することなく種々の改変を行な
い得ることが当業者には明らかであろう。

【図面の簡単な説明】

【図１】発明に従ったネットワーク制御モジュールであ
る。

【図２】発明に従ったディジタルコントロールモジュー
ルを示す。

【図３】図３は発明に従った展開モジュールを示す。

【図４】５つのスロット構成のネットワークコントロー
ルユニットを示す。

【図５】２つのスロット構成のネットワークコントロー
ルユニットを示す。

【図６】単一のスロット構成のネットワークコントロー
ルユニットを示す。

【図７】ネットワークコントロールユニットの１，２お
よび５のスロット構成中で使用されるモジュールを作表
する。

【図８】ネットワーク遠隔ディスプレイ増設ユニットの
１，２および５のスロット構成中で使用されるモジュー
ルを作表する。

【図９Ａ】サンプルファシリティマネジメントシステム
構成を例示する。

【図９Ｂ】サンプルファシリティマネジメントシステム
構成を例示する。

【図１０】発明に従ったネットワークの中で使用される
ライティングコントローラを例示する。

【図１１】発明に従ったネットワークの中で使用される
カードアクセス・コントローラを例示する。

【図１２】発明に従ったネットワークの中で使用される
インテリジェント火災報知コントローラを例示する。

【図１３】小規模ビルディング用ファシリティマネジメ
ント構成を例示する。

【図１４】中規模サイズビルディング用ファシリティマ
ネジメント構成を例示する。

【図１５】大規模サイズビルディング用ファシリティマ
ネジメント構成を例示する。

【図１６】遠隔のビルディング用ファシリティマネジメ
ント構成を例示する。

【図１７】本発明に従った１つのシステム構成を示す。

【図１８】様々なソフトウェアレベルから見たより詳細
な図を示す。

【図１９】発明に従ったポイントおよび擬ポイントの使
用を例示する。

【図２０】本発明に従ったシステムの別の概観である。

【図２１】発明の方法の第１実施例を例示する流れ図で
ある。

【図２２】発明の方法の第２実施例を例示する流れ図で
ある。

【図２３】図２２の方法の一層の最適化を例示する。

【図２４】複数のレベルのネームを使用した発明の方法
の実施例を例示する。

【図２５】ネームがノード内でそのアドレスを変更する
場合の発明の例を例示する。

【図２６】ネームがノード間を移動する場合の発明の例
を例示する。

【図２７】発明に従った時間同期ノードの方法を例示す
る。

【図２８】発明に従ったネットワーク上のノードへのグ
ローバル変数のダウンロードを例示する。

【図２９】発明に従った変数のダウンロードより詳細な
実例である。

【図３０】発明に従ったダウンロード装置のカスケード
を例示する。

【図３１】ダウンロードリクエストがアーカイブユニッ
トから起る場合にメッセージの伝送を示すテーブルであ
る。

【図３２】ルーティングテーブル無しのノードがダウン
ロードリクエストを始める場合の一連のメッセージパス
を例示するテーブルである。

【図３３】オブジェクトの属性からの特徴の動作開始を
例示する。

【図３４】発明に従った機能分散リポートルーティング
を例示する。

【図３５】ローカルノードでの簡略なリポートデータの
フィルタリングを例示する。

【図３６】フィルタされた属性に選択基準を導入する際
に発生する事象のより詳細な説明を示す。

【図３７】通信リンク上に形成された１つ以上のノード
と通信するために構成ノードに付けられた非構成装置の
例を示す。

【図３８】様々なデータ通信層に加えて図１の非構成ノ
ードと構成ノード間のメッセージパスを例示する。

【図３９】非構成装置からのリクエストの伝送あるいは
構成装置からの応答の伝送を例示する。

【図４０】非構成装置からのリクエストの受信あるいは
構成装置からの応答の受信を例示する。

【図４１】非構成装置と構成ノード間のための可能なル
ーティング戦略を作表する。

【図４２】ファジリティマネジメントシステムの一般的
な構成を示す。

【図４３】マスターノードがローカル・バスを通じてス
レーブノードと通信する基礎的な構成を示す。

【図４４】複数のマスターノードがネットワークバスを
通じて通信する別の実施例を示す。

【図４５】信頼性インディケータでデータにタッギング
する方法を例示する。

【図４６Ａ】ＰＩＤループオブジェクトの処理を例示す
る。

【図４６Ｂ】ＰＩＤループオブジェクトの処理を例示す
る。

【図４７】故障許容コントロール戦略インプリメントに
よる典型的なＨＶＡＣコントロールシステムを示す。

【図４８】故障許容コントロール戦略インプリメントす
る位相を示す。

【図４９】入力および戦略の位相出力を例示する。

【図５０】システムの１つの構成をディジタルコントロ
ールモジュールおよびネットワークコントローラで例示
する。

【図５１】分散ロードシェディングおよび局限リストア
タスクを備えたシステムの構成を示す。

【図５２】故障許容コントロール構成を示す。

【図５３Ａ】プロセスモニタリングステップを示す。

【図５３Ｂ】プロセスモニタリングステップを示す。

【図５４】故障許容コントローラを操作するステップを
示す。

【図５５】操作変数およびバックアップ変数を切替える
ステップを示す。

【図５６】ローカルあるいはスレーブバス上のスレーブ
・デバイスを作動させるノードを例示する。

【図５７Ａ】スレーブ・デバイスを持っているノードと
バス間の光学的インターフェースを例示する。

【図５７Ｂ】スレーブ・デバイスを持っているノードと
バス間の光学的インターフェースを例示する。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 デイビツド・イー・ラスムセン アメリカ合衆国、ウイスコンシン・53183、 ウエールズ、スツアーブリツジ・プレイ ス・656 (72)発明者 ゲイロン・エム・デシオス アメリカ合衆国、ウイスコンシン・53211、 ミルウオーキー、ノース・オークランド・ アベニユー、ナンバー・108・2523 (72)発明者 ジエイムズ・アール・ガーベ アメリカ合衆国、ウイスコンシン・53228、 グリーンフイールド、サウス・ナインテイ サード・ストリート・4245 (72)発明者 スーザン・エム・ハイザー アメリカ合衆国、ウイスコンシン・53223、 ブラウン・デイアー、ウエスト・テリー・ アベニユー・4493 (72)発明者 カレン・エル・ウオースト アメリカ合衆国、ウイスコンシン・53226、 ウオーワトウサ、ノース・エイテイフイフ ス・ストリート・2050 (72)発明者 バイラバン・イー・バイラバン アメリカ合衆国、ウイスコンシン・53224、 ミルウオーキー、ノース・バーバンク・ア ベニユー・9373 (72)発明者 デイビツド・エル・コツチ アメリカ合衆国、ウイスコンシン・53217、 フオツクス・ポイント、ノース・ポート・ ワシントン・ロード・7450 (72)発明者 ドナルド・エイ・ゴツツシヤルク・ジユニ ア アメリカ合衆国、ウイスコンシン・53210、 ミルウオーキー、ノース・カールトン・プ レイス・2773 (72)発明者 デニス・イー・バークハード アメリカ合衆国、ウイスコンシン・53132、 フランクリン、サウス・セブンテイセブン ス・ストリート・8036 (72)発明者 ダーレル・イー・スタンデイツシユ アメリカ合衆国、ウイスコンシン・53146、 ニユー・ベーリン、ヒドウン・バレー・ド ライブ・21600 (72)発明者 ポール・ダブリユ・メイドウス アメリカ合衆国、ウイスコンシン・53154、 オーク・クリーク、サウス・アツシユ・ス トリート・6865 (72)発明者 ダン・ジエイ・スペイセツク アメリカ合衆国、ウイスコンシン・53110、 カダヒイ、イースト・ランハム・3255 (72)発明者 クレイ・ジー・ネスラー アメリカ合衆国、ウイスコンシン・53151、 ニユー・ベーリン、ウエスト・ヘザーリ イ・ドライブ・16225 (72)発明者 ジエイムズ・ケイ・スターク アメリカ合衆国、ウイスコンシン・53226、 ウオーワトウサ、ノース・ナインテイシツ クスス・ストリート・2431 (72)発明者 オツトー・エム・メイジエランド アメリカ合衆国、ウイスコンシン・53221、 グリーンフイールド、サウス・サーテイフ アースト・ストリート、ナンバー・９・ 6134 (72)発明者 ロバート・アール・シンジヤース アメリカ合衆国、ウイスコンシン・53223、 ブラウン・デイアー、ウエスト・ジヨレ ノ・コート・4916 (72)発明者 マイケル・イー・ワグナー アメリカ合衆国、ウイスコンシン・53018、 デラフイールド、クレイ・フオツクス・ラ ン・ダブリユ・318・エス・1161

Claims (3)

【特許請求の範囲】
1. 【請求項１】 ネットワークで通信する複数のノードの
   記憶手段に記憶されたデータベースの同期方法であっ
   て、 ノードに記憶されたデータベースの最新の更新時刻を示
   す時刻表示を各ノードの記憶手段に記憶するステップ
   と、 ノードに記憶された時刻表示を各ノードから定期的に伝
   送するステップと、 伝送された時刻表示を各ノードで受容し、各受容時刻表
   示と記憶された時刻表示とを比較するステップと、 受容された時刻表示が記憶された時刻表示よりも遅い場
   合には、時刻表示送出ノードに対して、そのデータベー
   スを時刻表示受容ノードに送出するように要求するステ
   ップを含むことを特徴とする方法。
2. 【請求項２】 少なくとも１つのノードが少なくとも１
   つのスレーブデバイスを制御し、更に、 オンラインのスレーブデバイスからの時刻表示を対応す
   るノードに報告し、 報告された時刻表示とノード内の時刻表示とをノード内
   で比較し、ノードが、報告された時刻表示よりも遅い時
   刻表示を有する場合には、ノード内のデータベースの少
   なくとも１部分をスレーブデバイスに伝送するステップ
   を含むことを特徴とする請求項１に記載の方法。
3. 【請求項３】 ネットワークが、少なくとも１つの制御
   プロセスを少なくともモニタする動作を含むファシリテ
   ィマネージメントシステムであることを特徴とする請求
   項１に記載の方法。