JPH06214614A

JPH06214614A - プラント運転シミュレーション用人工知能ソフトウェアシェル

Info

Publication number: JPH06214614A
Application number: JP5323469A
Authority: JP
Inventors: Roouenfuetsudo Saimon; ローウェンフェッドサイモン; Ei Bauman Dagurasu; エイバウマンダグラス; Ei Shiyurutsu Buraian; エイシュルツブライアン; Daburiyuu Tonpuson Jiyunia Robaato; ダブリュートンプソンジュニアロバート; Hatsuhiko Naito; 初彦内藤
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1993-01-05
Filing date: 1993-12-22
Publication date: 1994-08-05
Also published as: US5402526A

Abstract

(57)【要約】【目的】プラント運転シミュレーション用の人工知能
ソフトウェアシェルであって、当該シェルはプラントの
諸要素と諸概念を表すオブジェクトを持つデータベース
を備えた黒板モジュールを含むものであって、制御時間
を短縮することを目的とする。【構成】ルールベース知識源モジュールと格ベース知
識源モジュールが、前記黒板モジュールと交信しなが
ら、特定の予め定義された黒板オブジェクトに対して動
作する。入力データモジュールは、前記黒板モジュール
と交信しながら、ユーザーが前記シェルにデータを入力
できるようにする。制御モジュールが、前記知識源モジ
ュールおよび前記入力データモジュールと交信しなが
ら、全ての入力データを受信し、さらに予め定められた
知識源割り込み可能性／優先順位スキムに従って、前記
知識源モジュールの動作を制御する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、プラント運転シミュレ
ーションのための人工知能ソフトウェアシステムに関
し、より詳細にはその種のシステムのための割り込み可
能性／優先性順位制御スキムに関する。

【０００２】

【従来の技術】工場プラントおよび加工プラントの環境
はあまりに多様であるため、それらを特定条件の下で説
明することは難しい。この多様性のために、プラント運
転を総合的に理解しようとする際に多くの困難に遭遇す
る。ただし、各製造分野で、工場や加工プラントが効率
向上を目的として保有する共通の運転上の特色が幾つか
存在するはずである。特に、プラントにとり、原材料
源、人的資源や時間などに関し、それぞれ最適な方法で
運転されることがますます望ましくなってきている。

【０００３】この点で焦点となる分野には、堅固な技術
原則、経済プラン、および安全性の利点が含まれる。

【０００４】プラント運転の特定知識を組込んだプラン
ト運転シミュレーションモジュールは、そうした原則の
実際の実行を支援することができる。ただし、どのプラ
ント環境も複雑であるために、製造技術者などの専門家
は、各自の作業の場であるプラントがカバーする特定領
域に限った知識のみを有する。この知識は、分析モデル
から発見的モデルに至る範囲の異なる形態で存在する可
能性がある。こうした知識形態の不適合性により、知識
を完全に一つのプラントモデルへと組込むことは極めて
難しい。

【０００５】プラント環境におけるコンピュータ技術の
応用は一般的に行われており、あらゆる生産分野で、装
置の制御からデータロギング（入力・記録）に至る様々
な作業にコンピュータが使用されているのを目にするこ
とができる。中でも成長している特定分野の一つは、効
率的なプラント運転に向けて、各プラントがカバーする
それぞれの領域における知識ベースシステムやエキスパ
ートシステムの導入にコンピュータを利用することであ
る。知識ベースシステムはプラント運転の幾つかの側面
に関する知識の叙述を含んでおり、それは知識を処理す
るための論理的推論または、発見的推論の幾つかの形態
を用いることによる診断や推奨を提供する。このシステ
ムは、単なる数字ベースの応用を超え、コンピュータ独
自の用途を実現している。

【０００６】プラント運転用支援ツールを生産するため
にコンピュータの力をプラント運転の専門知識と統合す
ることができると共に、プラントとその資源のモニタリ
ングに利用できる診断情報をも得ることのできる知識ベ
ースシステムを構築する試みが行われてきた。一つのプ
ラントは、複数の異なる知識源やエキスパートシステム
を備えている可能性があることから、それを統合する方
法により、異なるシステム間の対話が可能になり、プラ
ント運転のより広範な問題をコンピュータ利用の枠組み
の中に組み入れることが可能になるであろう。知識源や
エキスパートシステムの形態が異なるために、そうした
統合方法は、完全な一つのプラント運転をモデル化する
ことには成功していない。さらに、各プラントが特定領
域において少しずつ異なっているから、一つの全体構造
の中に多様なプラント環境のすべてにおいて有益である
よう十分な範囲を備える機能的モジュールのシステムは
実現されていない。

【０００７】

【発明が解決しようとする課題】この種のシステムを達
成するためには、全プラントに共通する特徴をモデル化
することが重要である。全プラントに共通のそうした特
徴の一つは、何らかの複合的な方法で、アウトプット
（最終製品）を生産するためにインプット（原材料）を
処理することである。もう一つの共通な側面は、すべて
のプラントが時間をかけた処理を含むことである。残念
ながら全時間依存性を含むプラントの完全な分析描写
は、不可能ではないにしろ、実際的ではない。プラント
運転に関する情報は、通常は不完全で断片的である。た
だし、プラント運転関連の豊富な情報は存在するであろ
う。しかし、一つのシステムを構築するためには、それ
らの豊富な情報が集積され、且つその種のシステムへと
組織化されなければならない。知識ベースシステムの場
合、過去においてこの点の成功例はまだ出ていない。

【０００８】従って、本発明の一般的目的は、全体的構
造の中で、多様なプラント環境の下で役に立つ十分に広
範な機能的モジュールを有する知識ベースシステムを得
ることである。

【０００９】本発明のもう一つの目的は、診断情報を得
ることができると共にプラント運転を監視することので
きるツールを生産するために、コンピュータの力をプラ
ントオペレーターの専門知識と結び付けることができる
知識ベースシステムを得ることである。

【００１０】本発明のもう一つの目的は、知識ベースシ
ステムに対して、効果的且つ整然とした方法でシステム
運転の制御を行う制御プロセスを提供することである。

【００１１】

【課題を解決するための手段及び作用】本発明の前述お
よびその他の目的、特徴および利点を達成するために、
プラントの諸要素及びコンセプトを表現するオブジェク
トを有するデータベースから成る黒板モジュールを含む
プラント運転シミュレーション用人工知能ソフトウェア
が与えられている。人工知能動作スキムを含む少なくと
も一つの知識源モジュールは、黒板モジュールと交信し
ながら、予め定義された特定の黒板オブジェクト上で動
作する。入力データモジュールが黒板モジュールと交信
することによって、ユーザーはそのシステムにデータを
入力できるようになる。

【００１２】制御モジュールは、入力データモジュール
及び少なくとも一つの知識源モジュールと交信しなが
ら、入力データを受信し、また予め定められた知識源割
り込み可能性／優先順位スキムに従って、その少なくと
も一つの知識源の動作を制御する。

【００１３】制御モジュールは事象検知モジュール及び
活性化／アジェンダ管理部モジュールを含む。その事象
検知モジュールは入力データモジュールと交信しなが
ら、全入力データを受信し、その少なくとも一つの知識
源をいつ実行すべきかを判定する。

【００１４】活性化／アジェンダ管理モジュールは、最
少一つの知識源モジュールと事象検知モジュールとの通
信において、少なくとも一つの知識源モジュールを、あ
らかじめ定義された知識源優先方式に基づいて実行す
る。

【００１５】本発明の好適実施態様において、少なくと
も一つの知識源モジュールは、ルールベース知識源モジ
ュールとケースベース知識源モジュールを含んでいる。
ルールベース知識源モジュールは、連想づけられる信念
レベルを備えるｉｆ−ｔｈｅｎ−ｅｌｓｅ形のルールを
含む前向き連鎖信念伝播方式を備えている。ケースベー
スの知識源モジュールは、あらかじめ定義されたパター
ンや条件を含むデータ比較方式を備えている。そこで
は、ケースベース知識源の実行に際して、もし受信され
たデータとパターンの間に一定水準の近似度が見いださ
れた場合、その条件は真実であると推論される。

【００１６】本発明のもう一つの実施態様では、少なく
とも一つの知識源モジュールが、さらに、シミュレーシ
ョン関係とインタフェイス関係とに相互結合されたモジ
ュールを有するモデルベース知識源を含んでいる。

【００１７】当業者にとり、添付図に関する以下の詳細
説明をお読みいただければ本発明の他の多くの目的、特
長および利点が明らかになるであろう。以下が、それら
の説明である。

【００１８】

【実施例】序論本発明は、黒板データベースにプラント入力項目を表わ
すオブジェクトを備えた人工知能ソフトウェアシェルを
提供するものである。エキスパートシステムの知識源は
時間的優先スキームに基づいて特定オブジェクトを実行
し修正する。ユーザはプラントの運転を診断し監視する
ために、そのオブジェクトの状態を見ることができる。
アプリケーション開発者（特定アプリケーションのプラ
ントの専門家）がそのオブジェクトと知識ベースのルー
ルを開発しないことには、そのシステムは使えない。

【００１９】本発明による制御プロセスは、予め定めら
れた知識源割り込み可能性／優先順位スキムに従って全
入力データを受信し、各知識源をいつ実行すべきかを判
定する。知識源には優先順位が与えられ、制御プロセス
はその優先順位に従って知識源の動作を制御する。例え
ば、以下に詳述するように、制御プロセスは優先順位の
低い知識源の実行を中断させ、優先順位の高い知識源を
優先的に実行させることができる。

【００２０】ドメインシェルは二つの観点から説明でき
る。ドメインシェルの機構の一つの見方は、知識ベース
システムの機能面から見ることである。ドメインシェル
の場合、これは黒板アーキテクチャ、そのコンポーネン
ト及びそれらの相互作用についての説明である。これは
そのシステムを内から見たものである。もう一つの見方
は、ユーザの立場、すなわち、ユーザはそのシステムと
対話する或いはそれを利用するのであるから、そのシス
テムがユーザにとってどのように見えるか、という立場
である。発生するインタフェースと動作シーケンスにつ
いての詳細は、外部システムからの観点である。これら
は表現こそ異なっているが、それらは互いに強く関連し
あっている。

【００２１】システム環境全体のダイアグラムを図１に
示す。ドメインシェルは、特定アプリケーションプログ
ラムを開発できる環境で構成されるであろう。これはア
プリケーション開発環境として知られている。それはア
プリケーション開発者がそのアプリケーションの構造を
入力し、修正し、そして試験するのに用いる機能を有す
る。これらの構造は制御フレームワークを含む黒板アプ
ローチの実現の例を構成する。同時にこの段階で、知識
源が生成され、入力される。本文書で述べるドメインシ
ェルには、あらゆるプラント環境用アプリケーションを
作成しやすくするツールとフレームワークが含まれるで
あろう。アプリケーション開発者にとってはその特定の
プラントタイプに共通の構造があれば、有益であろう。
もし装置のタイプと関連アイコンを表現する構造がすで
にシェルの特徴だとすれば、開発者は自分でそれらを作
成する必要なしに、それらを利用できるであろう。その
ようなツールが存在すれば、又実行システムのグラフィ
カルな表現を標準化するのに有益であろう。プラントの
タイプに対して特定される一セットの構造（例えば、製
鋼所用ローラプレスのアイコン）が存在することで有益
になるようなタイプのプラント（例えば、製鋼所や食品
加工工場）は明らかに存在する。第１段階として、特定
の製鋼所のアプリケーション開発者にとって有用である
ような一セットの構造をドメインシェルに追加すること
によって、開発者は製鋼所のドメインシェルを作成する
ことができるであろう。そうすれば、どの製鋼所のアプ
リケーション開発者もその作成済みの構造を利用するこ
とができるので、開発の負担を軽減することができる。
プラントのタイプを指定するドメインシェルの価値を高
めるには、そのシェルの有用性が最大になるように、そ
のドメインシェルを特別にカスタマイズするレベルを慎
重に考慮すべきである。

【００２２】アプリケーション開発が完了し、試験した
後に、それはプラント環境でオンライン設定される。そ
うすれば、そのシステムは、アプリケーション実行環境
に入る。ここにユーザはそのシステムと対話する工場要
員となって、システムの推奨事項を受けて適切な行動を
とる。

【００２３】図２は、二つの環境のより詳細な図であ
る。これはその二つの環境の特徴を示している。両方の
環境に知識ベースのシステムフレームワークが存在する
ことに注目されたい。これら二つのシステム間の連結
は、入力情報を実時間動作に適したフォーマットに変換
するコンパイラである。開発環境における知識ベースの
システムは、開発者によって作成された、編集しやすく
操作しやすく試験しやすい形で表現されたシステムであ
り、他方、実行環境の知識ベースシステムは、簡便で実
行効率が上がるように修正されたシステムの実行時バー
ジョンを表現する。これらの二つの環境をテストするこ
とにより、ここで特定するドメインシェルを詳述でき
る。

【００２４】エンドユーザはリアルタイムプラント環境
のシステムを利用することになる工場要員である。この
図のシステムは、ユーザに対するインタフェースの詳細
を強調し、情報の表現をユーザが入力するかもしれない
入力のタイプの性質を含む諸特徴について説明してい
る。

【００２５】シェルのアーキテクチャは、主として情報
の表現方法においてエンドユーザの目に見えるものとな
ろう。これには、ユーザが様々なレベルと種類の情報を
呼び出せるウィンドウ環境の使用が含まれている。ある
特定のアプリケーションのすべての部分の間でも、ま
た、〔異なる〕アプリケーションの間でも、すべてのユ
ーザが操作メカニックに精通し続けられるように、その
ウィンドウ環境は一貫性が保たれねばならない。

【００２６】そのシステムにより、エンドユーザは推論
過程を見ることができ、そのシステムの動作目的及びそ
の理由の説明を受けることができる。プラントオペレー
タが時間ぎりぎりの決定の必要に迫られた時、多すぎる
情報で当惑しないように、その説明は単純なレベルに保
たれることが重要である。しかし、シェルの汎用性によ
り、アプリケーション開発者は実行時特性を変えて特定
アプリケーションの出現を最適化することができる。

【００２７】システムの外部からみた場合、もう一つの
重要な面は、ユーザがシステムに指示することによっ
て、プラント運転のある側面に注意を集中できることで
ある。その一例としては、監視システムがその動作を適
正に調整できるように、システムに計画状況を知らせる
ことであろう。こういうことが出来るのは、例えば、オ
ペレータがプラント運転の一部停止予定を知っていた場
合である。そのアプリケーションは、この情報を受け取
って適正に動作するための手段を得ることになる。留意
すべきことは、この種の動作は、そのアプリケーション
の開発段階で、システムに「プログラム済み」だという
ことである。

【００２８】外部からの見方の最後の一面は、システム
がもたらす結論と推奨事項の表現である。これらは時間
的に切迫しているので、適切な表現方法が用いられるで
あろう。もう一度言うが、ドメインシェルは表現方法の
選択を可能にするであろう。そして、適切な表現を選択
することは、アプリケーション開発者がなすべき仕事と
なろう。

【００２９】特別なプラント環境用アプリケーション作
成後は、適正なインタフェースを確定して、システムを
設定する。それから、そのシステムを実行時環境動作に
設定する。これには、貢献する知識源と共に動作する黒
板フレームワークが含まれるであろう。

【００３０】アプリケーションを作成しやすくするため
に、ドメインシェルはプログラマツールセットと考えら
れるものを提供するだろう。黒板構造を作成し修正する
ためのエディタが〔ツールとして〕インプリメントされ
るであろう。これらのエディタは、その構造が目で見え
ることを保証することにより、開発段階のユーザを指導
することになろう。コンパイラは開発者が入力した情報
をリアルタイムで実行するのに適した形式に変換するで
あろう。デバッガやテストデータ生成プログラムなどの
開発診断ツールは、開発者に実行前の作業の有効性をチ
ェックする手段を提供するであろう。

【００３１】ドメインシェルの一般的性格により、動作
の正確な逐次的性格を述べることはできない。これは開
発者が設計したアプリケーションの特性によって決定さ
れるであろう。

【００３２】内からの見方には黒板アプローチの説明が
含まれる。これはアプリケーション開発者のドメインで
あり、開発者が特定のアプリケーションを作成するため
にはドメインシェルにそのツールを適用しなければなら
ない。図３にその内部構造を示す。

【００３３】黒板構造には、一つ以上の知識源に関連し
たデータが含まれる。基本的に、それはシステムの状態
を表現する構造である。開発者は異なるレベルの情報ス
ロットの階層を編成することによって黒板構造を作成す
る。換言すれば、最高レベルはプラントの最も広い概観
を示し、その下の各レベルはプラントの一部をより詳細
にみごとに表現する。その開発環境で作成された構造
は、実行時中に測定された或いは派生した実際及び模擬
のデータによって増補されねばならないことに留意のさ
れたい。

【００３４】基本的には、黒板の階層は異なるレベルで
プラントを理解する区分である。プラント環境の場合、
最も明白な区分は、装置の空間的、構造的配列であり、
工場自体の処理面積である。人は非常に抽象的なレベル
でプラントを見ることができる。そこでは、原材料が一
端で建物に入り、完成品が他端に現われる。より低いレ
ベルでは、一連のステップや補助処理を伴う処理を見る
ことができる。その各々を黒板上に表わすことができ
る。黒板には、関心をもっているパラメータと変数が配
置されるであろう。これらは、一つ以上の知識源によっ
て利用されるパラメータとなるであろう。

【００３５】黒板はこの情報を保持する。ドメインシェ
ルは、黒板構造にコンポーネントを与え、アプリケーシ
ョン開発者にはそのプラントに特定の黒板のフレームワ
ークを作成する手段を与える。このフレームワークは、
システムがそれを理解しているようにプラントのモデル
を表現するものである。

【００３６】知識源とは、そのモデル中のある部分の情
報についてのある推論形式を含む特定のセグメントであ
る。各知識源はそれ自体のドメイン、すなわち知識をも
った黒板の一部を保持している。知識源は、それが黒板
上で関心のある何ものかを「見る」ということを最初に
認識することによって黒板と対話する。それから、知識
源はそれが到達した結論に基づいて、黒板の他のあるセ
クションを変更する許可を求め、その許可を得る。この
ようにして（黒板上で見える通りに）システムの状態が
更新され、システム全体が黒板の情報に関して適切に動
作する。

【００３７】黒板システムの各知識源は、それにとって
重要なものを認識する責任がある。換言すれば、各知識
源は関心のあるそれ自体のドメインについての合理的な
知識をもっていなければならない。ドメインシェルにお
いて、アプリケーション開発者は、その知識源をシステ
ムに組込むのに必要な情報をもっていなければならず、
その知識源が黒板と対話できるようにしなければならな
い。知識源は黒板システムにその情報の緊急性について
何らかの指示を与えねばならない。

【００３８】黒板アプローチの価値は、異なる知識源が
その推論を黒板の重複部分に適用することができるとい
うことである。知識源のドメインを重複しうるというこ
とは、繁雑になるということだが、知識源が故障しても
システム全体が不具合になるようなことはないので、そ
れ以上の価値がある。主要な工学システムはすべて安全
のためのマージンとバックアップを備えているものであ
り、黒板アプローチはそれが可能なだけでなく、情報が
それを必要とする知識源で利用できることを実に確実に
することによって、それを効果的に促進することができ
る。

【００３９】シミュレータはシステムによって利用可能
な数学的・機能的ツールの集合である。これらのツール
には、代数・差分・微分操作が含まれる。

【００４０】制御部は黒板アプローチの恐らく最も重要
な部分である。制御部はシステムの実際の動作を監視す
る。それはどの知識源で黒板をアクセスすべきかを決定
し、同様に知識源の動作に優先順位をつける責任があ
る。黒板構造のこの部分は最も深慮を要するであろう
が、みごとに設計された制御部が開発されれば、最も強
力な性能を発揮するであろう。

【００４１】アプリケーション開発過程の重要な部分
は、様々な知識源の適切な制御階層を決定することであ
ろう。知識源が相互作用しない（それらのドメインは相
互排他的である）場合でさえ、ドメインシェルのリアル
タイム性は、システムが最緊急の要求を最優先と認識す
るよう要求する。複雑なアプリケーションの場合、様々
な知識源が〔互いに〕矛盾する恐れのある関連情報を有
するかもしれない。このようにここで述べるドメインシ
ェルは、アプリケーション開発者にとって一般的なツー
ルセットを提供するであろうが、開発者は整合性のある
問題解決戦略を立てることが不可欠である。

【００４２】プラント環境向けのアプリケーションにも
様々なものが考えられるので、そのドメインシェルは特
定のアプリケーションに対する動作調整能力と併せて知
識上限の融通性を要する。黒板アーキテクチャを利用す
れば、拡張の基本となりうる標準化された基礎構造を維
持しながら、初期の融通性が達成される。

【００４３】ここに述べる機能仕様は、ＷＳＴＣと三菱
との交流の結果であり、従ってこの分野における両組織
の経験が反映されている。特に、システムの機構を決定
づけた三つの指示源が存在する。

【００４４】システム全体の設計の説明本節では、操作レベルでのシェルの設計について述べ
る。ここでは本システムの設計概念について簡述し、シ
ェルのモジュールへの分解を示す。本システム設計の基
本は、本機能仕様の所与条件を満たすことである。

【００４５】ドメインシェルのブロックタイアグラムを
図４に示す。本システムは下記のモジュールに分けられ
る：黒板，事象検知部，活性化／アジェンダマネージ
ャ，ルルベースの知識源，ケースベースの知識源，ユー
ザインタフェース。これら各々のモジュールは独特のＵ
ＮＩＸプロセスを表している。ある特定アプリケーショ
ンのコンテキスト内では、黒板プロセス１個，事象検知
器プロセス１個，活性化／アジェンダマネージャプロセ
ス１個，ユーザインタフェースプロセス１個が存在する
ことになろう。更に、少なくとも１個の知識源プロセス
が存在しなければならず、多重知識源プロセスでもかま
わない。図４では、特定黒板情報を表示するための人間
−機械インタフエースプロセスは示されていない。

【００４６】シェルを使用する前に、ユーザは必要なす
べての入力ファイルを作成する。必要なファイルとは、
黒板構造記述ファイル（ＢＳＤＦ），各ルールベースの
知識源用ルールベース記述ファイル（ＲＢＤＦ），各ケ
ースベースの知識源用ケース記述ファイル（ＣＤＦ）及
び少なくも一つのデータファイルである。

【００４７】統語上の正確さを得るために、シェルがフ
ァイルをチェックする一方、ユーザはテキストエディタ
を通じてエラーを修正できるが、もっとレベルの高いエ
ラーや不整合性を見つけるためにシェルがファイルを走
査することはしない。それ故、ユーザはファイルが整合
性のある情報を含むようにしなければならない。そうで
ないと、シェルは予期せぬ結果を生じるだろう。

【００４８】ＵＮＩＸシェルプロンプトでシステムファ
イル名を併せてプログラム名を打ち込むことにより、シ
ェルは実行される。システム（アプリケーション）ファ
イル名は、特定のアプリケーションの構造を定義する。
ファイルリストを含むファイルを識別する。ファイルセ
ットは黒板アプリケーションの構造を決定する。黒板に
関するＢＳＤＦ及びすべてのＲＢＤＦとＣＤＦはアプリ
ケーションに属する。ここには、例えば、多分一個の知
識源をはずしても同様のアプリケーションを作成するの
に十分な融通性がある。これにより、試験中のアプリケ
ーションに対する特定の知識源の有用性を評価すること
ができる。

【００４９】シェルにシステムファイルが与えられた後
でないと、シェルは情報のローディングを始めない。

【００５０】シェルは然るべきプロセスを起動させ、そ
れらに然るべきファイル名を提供する。これには黒板プ
ロセス，事象検知部，プロセス活性化／アジェンダマネ
ージャ，ルールベースの知識源プロセス及びケースベー
スの知識源プロセスが含まれるであろう。すべての入力
ファイルがロードされた後で、シェルはアプリケーショ
ンのセッション実行を開始する準備が整う。シェルはユ
ーザに実行パラメータを設定し、入力データファイル
（ＩＤＦ）を指定するよう求める。この時点でセッショ
ン実行が始まる。

【００５１】アプリケーションのセッション実行は、シ
ェルがＩＦＤから入力データを読み取り、そのデータに
基づく適切な行動を採ることで構成されている。適切な
行動の決定は事象検知部プロセスの責任である。データ
値は黒板上で更新され、知識源を発火すべきか否かを決
定するためのテスト条件が鑑定される。もし知識源を発
火すべきなら、その名称が先入れ先出し（ＦＩＦＯ）キ
ュー〔待ち行列〕に入力されて、実行待ちとなる。

【００５２】活性化／アジェンダマネージャは知識源の
実行順序を制御する。それは一度にたった一つの知識源
を実行するよう保証するためである。活性化マネージャ
とアジェンダマネージャは条件が制約されているので、
それらは結合されて単一プロセスになってしまってい
る。

【００５３】アプリケーションで利用される各知識源プ
ロセスはその専門知識のドメインに関連する然るべき構
造を有する。シェルの動作中は、各知識源は活性化／ア
ジェンダマネージャによって活性化されるまで休止して
いる。起動されている時、知識源は、診断〔機能〕を生
成しようとして、そのルーチンを実行する。知識源が診
断を行うと、それはログファイルに書き込まれる。

【００５４】知識源は実行中に直接黒板から情報を要求
する。このように、すべての知識源は黒板との直読特権
を有する。しかし、知識源によって生成された黒板への
データ更新は、事象検知部を通じて指示される。その時
に、事象検知部がデータを走査して、ある事象が起きた
か否かを判定できる。

【００５５】事象検知部を通じてデータ更新を指示する
ための設計決定は重大事である。代案としては、各知識
源が黒板に直接書き込めるようにすることである。直接
書き込みの利点は、黒板への書き込み効率である。その
欠点は、事象検知部がその後引き続き黒板を検索して、
更新されたデータが存在するか否かを判定しなければな
らないことである。知識源から間接的データ更新を伴う
シェルの設計により、センサからであろうと知識源から
であろうと、黒板への更新はすべて均等になる。概念的
に、これは、他にも遂行すべき様々な困難な任務を有す
る事象検知部を簡素化することである。もし事象検知部
が連続的に黒板を検索しなければならないとしたら、
（当初の予想通り）非同期なデータ駆動プロセスから、
非同期なプロセスと体系的な検索とが混合して結合した
プロセスへと、黒板動作における根本概念の変化を引き
起こすであろう。

【００５６】入力データの読み取り、知識源の発火、診
断の生成という順序は入力データファイルが終わるまで
続く。この時点で、命令された診断リスト、すなわち、
診断ファイル（ＦＤ）が生成される。これがシステムか
らの一次出力であり、それによってシステム評価部がシ
ステムの性能を判定できる。

【００５７】ユーザが別のセッションの遂次入力データ
で実験できるように、黒板の状態をファイルに格納する
ことができる。そうすれば、その時点から続くその後の
セッション実行で、いずれその黒板状態ファイル（ＢＳ
Ｆ）をロードできる。

【００５８】本シェルでは又、ユーザが同一システムに
新規のＩＤＦを提供することができる。それは異なった
動作状態（即ち、そのデータがそれ以前の入力データと
は独立しており、無関係であること）をテストするため
になされるだろう。この場合、システムは初期状態にリ
セットされて、別のセッション実行が始まる。或いは、
それ以前の実行データを継承するデータを含む新規ＩＤ
Ｆを提供することができる。この場合、システムはリセ
ットされない。

【００５９】諸プロセスの説明本節では、シェルの実行にかかわる諸プロセスの各々に
ついて、もっと詳細に説明する。各プロセスを、（１）
その目的の簡単な要約、（２）プロセス名、（３）デー
タ構造、及び（４）プログラムの論理フロー、の四つの
実体的な面に基づいて説明する。データ構造と論理の流
れの実体は、必要ならば、プログラミングの指針によっ
てその説明が増補される。入力／出力の関係については
以下に述べる。本節の説明は、全ソフトウェアを適切に
操作できる程度に詳細なものであることに注意すべきで
ある。このように、プログラマはここに含まれる情報に
よって制約される。本節で述べる内容の変更はすべてＷ
ＳＴＣの設計チームの承認を必要とする。他方、ここで
述べないすべてのインプリメントにおける決定はプログ
ラマに委ねられる。例えば、後続する節で述べるデータ
構造は、ここで述べる通りインプリメントされるが、モ
ジュールの適正操作に必要になるかもしれない他のいか
なる構造を用いようともプログラマの自由である。

【００６０】黒板黒板プロセスには、黒板のオブジェクト及びそのオブジ
ェクトを操作するのに必要な方法が含まれる。プロセス
名：黒板データ構造：黒板のオブジェクトを表わすデー
タ構造の基本的機構を図５で示す。左側の構造はハッシ
ュ表をインプリメントする配列である。右側の結合リス
トに属性／属性値を記憶させる。

【００６１】プログラミングの指針二重ハッシングアルゴリズムのオープンアドレス指定の
Ｂｒｅｎｔの変動値を用いてハッシュ表をインプリメン
トさせる。ハッシュ表の番号は、ある大きな数から始ま
るが、大きすぎてはいけない。例えば、５０３である。
もしオブジェクトの個数が多すぎることによって、表の
ローディング率（ハッシュテーブル内においてオブジェ
クトが占める割合、すなわち占有率）が約８５％を超え
ると、新しい、より大きな表が割当てられ、データがハ
ッシュし直される。最大ハッシュ表のサイズは４３、３
９１かそれ以上である。

【００６２】ハッシュ表のキーはオブジェクト名であ
り、表のエントリはあるオブジェクトの構造に対するポ
インタであり、その構造にもまたそのオブジェクト（あ
るストリングに対するポインタ）が含まれる。検索時
に、そのキーとその名称ストリングが常に比較される。
ハッシュ配列のオブジェクトの索引とリストの属性の索
引を利用することにより、オブジェクトを呼び出すこと
もできる。このことにより、もし呼び出すことを要求す
る実体がそのような索引を知っていれば実行している時
に高速アクセス機構がもたらされる。

【００６３】属性の構造には、オプションで、ある機能
を参照しやすくするデーモンスロットが含まれている。
もしスロットがあれば、その属性が新しい値を受け取る
ごとに、その機能が実行される。プロトタイプでは、Ｍ
ＭＩ−ＷＲＩＴＥと名づけられた唯一の機能があるが、
その動作はソケットをへて外部プロセス（マンーマシン
・インタフェース）に新しい値を送ることである。

【００６４】属性値の構造には「タイプ」のスロットが
含まれる。図６にそのタイプコードを示す。タイプのう
ち、「二重（ｄｏｕｂｌｅ）」のみが用いられる。

【００６５】属性値の構造には、秒単位の「時間スタン
プ」スロットが含まれる。リストへの挿入は、最新の値
が最優先の形で行われる。

【００６６】その値リストへの挿入は、常に１個＝現在
より古いたった１個の値＝時間スタンプ−ヒストリ長さ
の形で行われる。他のすべての古い値は捨てられる。

【００６７】ロジックの流れ黒板マネージャは幾つかの機能を遂行する。まず第一
に、黒板マネージャはそのプロセスを起動させた後で、
そこへ送られた名称のファイルに含まれる情報から黒板
構造を作成する。それから、それは黒板上でのデータの
出し入れを要求するメッセージを受け取る。各メッセー
ジは下記の一つによって確認される。

【００６８】「get （ゲット）」に成功すれば、データ
メッセージはACK メッセージ、「put（プット) 」に成
功すれば、又はエラーがあれば、KNACK メッセージであ
る。ユーザインタフェースからのSTOP( 停止) メッセー
ジはソフトウェアに黒板構造を書き尽くして退去するよ
う伝達する。RESET ( リセット) メッセージによって、
黒板はそのオブジェクト／属性の構造以外のすべてのデ
ータ内容をクリアしてしまう。このモジュールはANSI C
を用いて記述されている。

【００６９】事象検知部本プロセスは外部源、即ち、ユーザインタフェースから
のデータを受け取る。それはまた、知識源が黒板上に書
きたい情報を受け取る。入って来るデータはすべて黒板
プロセスへ送られる。入って来るデータのすべての断片
も事象の潜在的検知のためにチェックされる。データ値
によって、即ち、ある表式を満たすことによって、或い
は、その値とは無関係に、単にデータポイントの到着に
よって、ある事象が起動される場合がある。タイマベー
スの事象は活性化／アジェンダマネージャプロセスで処
理される。検知された事象で連想づけられた知識源のリ
ストが活性化／アジェンダマネージャプロセスに送られ
る。

【００７０】プロセス名：事象検知部データ構造：図７に本プロセスに必要なデータ構造を示
す。左側の配列でハッシュ表をインプリメントする。各
データ源は、それがセンサの（外部）データであれ、生
成された知識源であれ、ハッシュ表でデータポイント構
造を示す入力項目を有する。そのため、各データポイン
トは連想づけられた間接的表式リストを有する。このリ
ストの要素は、表式配列を順番に指すポインタを有する
表式リスト中の入力項目を示す。

【００７１】プログラミングの指針：そのハッシュ表は
簡単な二重ハッシングアルゴリズムを用いてインプリメ
ントされる。事象検知部はボトルネックとなり得るもの
であるから、可能な限り最高の性能を追求すべきであ
る。

【００７２】そのハッシュ表の番号は、黒板の表より小
さいと予想される。それも503 から始まるが、ローディ
ング率が90％を超えると、もっと大きなスペースが割当
てられる。

【００７３】そのハッシュ表のキーは、オブジェクト名
と属性名の結合である。表の入力項目は、再びオブジェ
クト名／属性名を含むデータ構造を指す。その名称は検
索中常に比較される。

【００７４】論理の流れ：図８では、単純化された表現
のプログラムの論理を示す。本プロセス起動時に初期化
部分が実行される。それはそこへ引数として送られる名
称の知識源記述ファイルから事象表現の定義をロード
し、解析することによって、図７で示す構造を作成す
る。プログラムの残部は、メッセージの受信によって駆
動される。

【００７５】プログラミングの指針：入って来るすべて
のデータメッセージは、構文エラーがある場合はKNACK
メッセージによって、或いは、黒板確認メッセージを元
の送り手に送り返すことによって確認される。

【００７６】表現評価については、ここで述べる。事象
を定義する表現は条件式と同様であるから、同一のソフ
トウェアが使用される。

【００７７】表現で用いられる演算子は本質的にシステ
ムの他の所で用いられる演算子と同一である。このよう
に、黒板から得られる新たに到着した値とそれ以前の値
を区別するためには、新演算子は新データ到着時にトリ
ガするオブジェクト／属性に先行するよう求められる。

【００７８】ある知識源で連想づけられる表現が全く無
い場合には、そのような知識源は、その前提条件の一つ
にあらゆる演算子が含まれていれば、単に発火するだけ
だろう。本モジュールはＣ＋＋で書かれている。

【００７９】活性化／アジェンダマネージャ本プロセスは知識源に実行を開始させる。事象検知部に
よって活性化された知識源は、それらの前提条件が真で
あると評価された場合に、しかもその場合にのみ直ちに
起動される。知識源に如何なる前提条件も定義されてい
ない場合は、それは次の機会に発火するであろう。FIFO
キュー（先入れ先出し待ち行列）が実行順序を決定す
る。周期的に実行する知識源のために、別途キューが備
わっている。

【００８０】プロセス名：マネージャデータ構造：本プロセスが必要とする基本的なデータ構
造には次の三種類がある：すなわち、事象によって駆動
される知識源を活性化させるためのFIFOキュー、周期的
知識源用の時間ベースのキュー、前提条件をチェックす
るための知識源／前提条件の表現構造である。

【００８１】後者は、図７で示す事象検知部のデータ構
造にとって概念的には理想的であるが、次のような違い
がある。すなわち、この時ハッシュ表が不要で番号100
の単純配列で十分である、各知識源用の表現リストはそ
の配列要素によって指示される。それ故、オブジェクト
／属性構造と間接的表現リストが不要である、表現リス
ト構造の「知識源」と「更新済み」のスロットも不要で
あるということである。

【００８２】論理の流れ：それは基本的に一個のプロセ
スだが、活性化／アジェンダマネージャーを実行するソ
フトウェアは二つの割込み駆動プログラムとして最もよ
く考えられたものである。一方は図９のトップに示す通
り、事象検知部からのメッセージの到着に反応する。他
方は図９の低部に示す通り、時間の経過に反応する。

【００８３】プログラミング上の注意：本プロセスは二
つの割込み駆動プログラムとして最もよく考えられては
いるが、実際のインプリメンテーションアプローチはイ
ンプリメンタ裁量にまかせられている。本モジュールに
ついては、Ｃ++で記されている。

【００８４】ルールベースの知識源本プロセスは、if〜then〜のルールの集合で動作する基
本的なデータ駆動（前向き連鎖）推論機構によって、
「信念」を伝搬させることによって、インプリメントが
行われる。

【００８５】プロセス名：ルールベースデータ構造：基本的なデータ構造はルールネットワーク（木）であ
る。一例を図10で示す。ネットワークノードは次の三つ
の基本層に依存する。すなわち、データノードから成る
入力層、仮説、変数、定数のノードから成る中間層、障
害ノードから成る出力層である。

【００８６】それらの構造を図11に示す。データと障害
のノードは黒板相当構造をもたねばならない。その他の
種類（仮説、変数、及び定数）のノードは黒板相当構造
を有してもよいが、その必要はない。支援ルールと被支
援ルールのスロットには、ノードを相互接続する方法を
記述する構造を示すポインタが含まれる。これらの構造
はルールであり、それらの基本的な機構を図12に示す。
この図では又、メタルールの構造も示す。

【００８７】これらの構造に加えて、図13では、機能仕
様で述べる諸機能をインプリメンテーションに必要な他
の幾つかの実体の機構を示す。これらの幾つかについて
は更に論述する。最後に、条件式を記憶するには、ある
構造が必要である。

【００８８】論理の流れ：本プログラムは最初にルール
ベース論述ファイルを読んで、上記の構造を作成する。
それから、それはメッセージを待つ。もしそれがSETPAR
AM型のメッセージなら、プログラムは追跡、記録、ステ
ップの実行パラメータをセット又はリセットし、或いは
それは大域的な十分性・必要性の係数の値を変更し、或
いはそれは大域的なα・β遮断の値を変更する。ブレー
クポイントを設定するには、ルールベースの知識源自体
のユーザインタフェースを呼び出す。もしそのメッセー
ジがRESET 型のメッセージならば、新たなセッション実
行に備えて、プログラム自体がリセットされる。もしそ
のメッセージがACTIV 型メッセージならば、プログラム
は一般に図14で示す手順に従う。この図で示す論理の流
れは大いに単純化されている。本ソフトウェアの決定的
な面については、次節で更に詳述する。

【００８９】条件式図14で示す通り、下記の一定の条件を満たさなければ、
ルールは発火できない。

【００９０】1.そのルールのコンテキストが真と評価さ
れねばならない。

【００９１】2.そのルールの条件が得られる。

【００９２】3.そのルールの仮説に対する条件の貢献値
は、α・β遮断値によって定義される範囲内でなければ
ならない。

【００９３】これらの条件は表現の評価に依存する。表
現処理の全般的戦略は下記の通りである。表現はプレフ
ィックス表記法又はインフィックス表記法を用いて、ル
ールベース記述ファイルで最初に指定される。２，３の
例は：「もし温度が過去１時間に500 度未満から500 度以上に
なったとしたら」： ((time-when(temp>500))<3600) 「もし直前２時間に亘る圧力変化が0.5 未満だった
ら」： (<(trend pres 7200)0.5) 「仮説#1が真で、しかも次の内の少なくとも一つが真：
〔即ち〕仮説#2が真、或いは仮説#3が真、或いは仮説#4
が偽ならば」： (hyp1 and(or hyp2 hyp3(not hyp4))) 簡単に表示するために、テキストはストリングとして、
ルールの条件−テキスト用スロットに記憶される。それ
は又、表式−配列で分析される。このアレイの構造は、
厳密なプレフィックスであり、表式の回帰的表現であ
る。そこでは、演算子はその対応トークン（或いは関数
を指すポインタ）によって置換済みであり、オペランド
は動的値を保持する構造を指すポインタによって、或い
はそれらが静的定数ならば、その値自体によって置換さ
れる。

【００９４】最後の例では、#2と#3はそのトークンに続
くオペランドの数を示す。このアレイを指すポインタは
そのルールの条件−表のスロットに入力される。その分
析部も又ポインタとしてのオペランドのみを含む別の条
件−リストを生成する。このリストは、条件が入手でき
るか否かを迅速にチェックするのに用いられる。

【００９５】かくて、表現の実行時の評価とは、実際の
計算を行う単純な評価関数を回帰的に呼び出すことであ
る。

【００９６】それから、ルールを発火する条件が次の通
りチェックされる。

【００９７】１．ルールのコンテキスト表現を評価す
る。真（即ち、値が１と評価）２．条件−リスト上の条件の構成要素がすべて更新済み
であるかどうかをチェックする。もしＹＥＳならば、３．ルールの条件式を評価する。

【００９８】こうすれば、ある信頼度のレベルであるＣ
Ｆ条件値が報告される。（次節で述べるような）ルール
の十分性又は必要性と結合したこの値が、ルールの仮説
の信念に対するルールの貢献度を決定する。もしその貢
献度が仮説ＭＢに影響し、その貢献量（値）がα遮断値
よりも大きければ、或いは、それが仮説ＭＤに影響し、
貢献量がβ遮断値より小さければ、そのルールは発火し
うる。

【００９９】オペランドには幾つかの種類がありうる：
値オペランドはある数を評価する。値オペランドは、実
際の数、ノード名、コンテキスト名或いはそれ自体が値
を評価する表現によって指定されうる。名称を利用する
場合は、計算に用いられる値はその構造の種類に依存す
る。

【０１００】仮説と機能障害のノードはそのＣＦスロッ
ト値を提供する。データ、変数、定数のノード及びコン
テキストは、その値スロットの内容を提供する。

【０１０１】ＤＦオペランドは、その値が−１．０と＋
１．０の間の数でなければならない点を除けば、値オペ
ランドと同様である。

【０１０２】区分線形オペランドは区分線形構造の名称
であり、それはデータ補間用Ｘ−Ｙ対のリストを提供す
る。

【０１０３】演算子にも様々な種類がある：代数演算子
は常に数値を報告し、それらのアーギュメントはすべて
値である。これらの演算子のリストを機能仕様書の別の
頁に示されている。更に現在時刻演算子が備わってお
り、それは現在のデータセットの時間スタンプを報告す
る。

【０１０４】ブール演算子は常にＣＦ値を報告する。し
かし、それらのオペランドの種類は異なる。ファジーブ
ール演算（ＡＮＤ，ＯＲ，ＮＯＴ）はＣＦ型オペランド
を必要とする。重み付きブール演算（重み付きＡＮＤ、
重み付きＯＲ）は（重み、ＣＦ）対を必要とし、ここで
いうウェイトとは一つの数である。比較ブール演算
（＝、＜、＞）は二つの値アーギュメントと、オプショ
ンで一つの区分線形をとる。もし後者を指定しなけれ
ば、演算子が＋１又は−１（真または偽）を報告する。
そうでなければ、区分線形関数のＸ線上で二つの数アー
ギュメントの差をマッピングすれば、曖昧な結果が算出
されて、その対応Ｙ軸値が報告される。

【０１０５】時間ベースの演算子は常に数値を報告す
る。それらのオペランドは一つのノード名と一つの値
（△Ｔ）である。第２アーギュメントは実際の数値でな
ければならない。時間ベースの演算子のリストを機能仕
様書の別の頁に示されている。更にもう二つの演算子が
加わる。ノードの履歴からの値を報告する時間値演算
子、及びデータノードの時間スタンプを報告する（必ず
しも現行時間と同一ではない）時間スタンプ演算子であ
る。

【０１０６】変化ベースの演算子は常に、ある値を報告
する。それは演算子が一つの表現をアーギュメントとし
て必要とする時間である。その表現の真理値が偽（マイ
ナス値）から真（プラス値）へ移ると、その遷移時間が
記録される。それ故、その表現はＣＦ型でなければなら
ない。それは演算子が二つのアーギュメント、ＣＦ表現
とノード名を取る時の値である。その表現が偽から真へ
移ると、ノード値が記録される。これら両方の演算子は
偽から真への遷移を定義するのに用いられる追加アーギ
ュメントを受け容れる。もしこのオプションのアーギュ
メントが欠けると、真と偽の境界が大域的なα遮断値と
なる。

【０１０７】他の諸注意：ルールの条件として表式を用
いる場合は、それらはＣＦ型を評価しなければならな
い。換言すれば、最上位の演算子はブール型でなければ
ならない。他のすべての場合（例えば、変数ノードに記
憶されたメタルールと計算）は、いかなる制約もない。

【０１０８】時間ベースの演算子を含む表式中のすべて
のノード基準は、実際の履歴が保持されている黒板中に
対応するオブジェクト属性の内容をもたねばならない。
その基準がルールの条件中にある時は、ノード名を使用
しなければならない。それが事象又は前提条件の定義中
にある時は、オブジェクト／属性名を用いなければなら
ない。

【０１０９】ルールに基づいて、たった一つの変化ベー
スの演算子が許容される。

【０１１０】すべての時間基準は秒単位である。すべて
の時間間隔は現在の時間スタンプから測定される（必ず
しも現在の実時間と同一ではない）。

【０１１１】幾つかの演算子は「偽信号〔別名〕」：ad
d 〔加える〕＋、and 〔と〕＆、diff〔引く〕−、div
〔割る〕／、equal 〔等しい〕＝、greater 〔大なり〕
＞、less〔小なり〕＜、not 〔でない〕！、or〔又は〕
？、times 〔掛ける、倍〕＊、を有する。インフィック
ス表記法又はプレフィクス表記法の両方でこれらの演算
子（それらの〔実〕名又はそれらの別名）を用いること
ができる。他のすべての演算子はプレフィックス表記法
でのみ用いることができる。

【０１１２】アーギュメントの数は、一般に演算子の性
質によって示唆される。しかし、幾つかの演算子：and
〔と〕、or〔又は〕、average 〔平均〕、diff〔引
く〕、div 〔割る〕、max 〔最大〕、min 〔最小〕、st
d-dev 〔標準偏差〕、times 〔掛ける、倍〕は、あらゆ
る数のオペランドを取ることができる。

【０１１３】推論機構「信念」の伝搬：これは三段階で行われる。

【０１１４】１．ルールの条件の評価：これについて
は、前節で論述済みである。又、ブール条件の公式を結
合するには、本機能使用のＰ40を参照のこと。

【０１１５】２．ルールの貢献度の計算：ルールは十分
性と必要性（ＳＦとＮＦ）と名付けられた事前に定義さ
れた確信レベルを有する。図15の表でその全アルゴリズ
ムを示す。（注：この貢献度はα−β遮断値の判定に用
いられる。）３．仮説の信念の更新：一つ以上のルールが仮説に影響
を与える場合には、次の論理的和確率ルールを用いる： Beliefi ＝Beliefi −１＋Beliefrule-i −Beliefi −１＊Beliefrule-i、ここで、Beliefi は図15で示すような仮説ＭＢ又はＭＤ
であり、Beliefrule-iは図15で示すような一括ルールの
貢献度である。

【０１１６】データノード：システムへの入力はデータ
ノードの値スロット内にある。これらの値は一般に比較
ブール演算を用いて信念に変換される。

【０１１７】メタルール：これらのルールは信念を伝搬
させるものではないが、コンテキストを変更して、ルー
ルの重要度を修正するのに用いられる。それ故、メタル
ールのターゲット−リスト用スロット（図12参照）がコ
ンテキスト又はルール構造を指す。第１の場合は、メタ
ルールのターゲット−スロット用スロットはコンテキス
ト構造の値スロットだと見なされる。第２の場合は、タ
ーゲットルールのＳＦ又はＮＦのスロットを指定しなけ
ればならない。メタルールの源スロットには表現が含ま
れる。その評価で得られた値は、アーギュメントとして
オプションの関数（区分線形関数）スロットへ送られ
て、その結果がターゲットコンテキスト又はルールのタ
ーゲット−スロットに入る。もし関数スロットが定義さ
れないならば、その表現の評価結果が直接宛先（ターゲ
ット−スロット）に入る。

【０１１８】メタルールでコンテキストを変更すると、
すでに発火済みでそのコンテキストが変更されたすべて
のルールが「未発火」（即ち、それらの結果が除去され
る）状態になる。そうすると、プログラムはコンテキス
ト変更前にルールが発火した可能性がなかったかを再チ
ェックして、それらが現在テキスト中にある可能性を再
チェックする。同様に、メタルールでルールのＳＦ又は
ＮＦを変更する場合は、このルールのすべての結果は未
完でなければならず、従ってそのルールは再発火しなけ
ればならない。

【０１１９】メタルールに関する二つの観察：まず第一
に、それらは未発火と再発火のプロセスにより、無限ル
ープを招く恐れがある。かくて、各メタルールは、ある
既定数しかそのメタルールを実行できない、オプション
の関連カウンタを有する。カウンタが定義されない場合
は、１と見なされる。観察の第二点としては、メタルー
ルは概念的に使用しにくいだけでなく、実行時性能を大
幅に低減させるので、注意して使用しなければならない
ことである。

【０１２０】評価部：ルールと同様であるが、評価部の
目的は信念を高めることではなくて、むしろ計算を行う
ことである。かくて、評価数構造（図13）は、ルールと
全く同様に、コンテキストの表式を有する。その表現ス
ロットは、ルールの条件と全く同様に評価される。それ
から、その評価結果は、その名が変数スロットにある値
スロットに入る。

【０１２１】デバッギング：８個のパラメータを設定で
きる。

【０１２２】追跡：設定すると、発火時に、各ルールに
よって記述メッセージが画面上に表示される。

【０１２３】記録：追跡とまさしく同様であるが、出力
が拡張「.log」付きのファイルへと進む。

【０１２４】ステップ：設定すると、各ルール発火後に
プログラムが停止し、ユーザが要求した時だけ続行す
る。

【０１２５】ブレークポイント：ルールで連想づけら
れ、標識の付いたルールがグローバルなＳＦとＮＦを発
火した直後に、プログラムを停止させる。ブレークポイ
ントは、これら二つのパラメータのデフォルト値を定義
する（即ち、ＳＦ及び／又はＮＦ値抜きでルールが定義
されると、グローバルなデフォルト値が用いられる）。

【０１２６】グローバルαとβ：それらはこれら二つの
パラメータのデフォルト値を定義する（即ち、α値及び
／またはβ値抜きでルールが定義されるとグローバルの
デフォルト値が用いられる）。グローバルなαはまた、
表現で指定されなければ、変化ベースの演算子のために
偽から真へのデフォルトの遷移を定義するのにも用いら
れる。

【０１２７】ブレークポイント以外のこれらのパラメー
タはすべて、ユーザインタフェースからのＳＥＴＰＡＲ
ＡＭメッセージによって、セットでき、クリアできる。
ブレークポイントは、ルールベースの知識源ソフトウェ
アによって、それ自体のユーザインタフェースを経て設
定できる。

【０１２８】ユーザインタフェース：プログラム自体の
ユーザインタフェースは、次の二つの情況下のいずれか
で呼び出される。ユーザがブレークポイントを設定した
い時、及び実行時中で、ステップパラメータが設定され
ている、或いはブレークポイントに遭遇した時である。

【０１２９】本プログラムのユーザインタフェースによ
り、ユーザはルールベースの最小量の走査が行える（例
えば、リスト構造）。この目的のために、図１３で示す
システム構造では、然るべき記帳情報を記憶する。

【０１３０】出力：本プログラムは、記録ファイルと併
せて、上位の機能障害が列記されている診断ファイルも
書く。この出力ファイルは、拡張「.out」を有する。

【０１３１】動作：ルールの実行部には幾つかの動作が
備わっている。

【０１３２】ｂｂへの値入力：この動作は、1 つのアー
ギュメント、ノード名を取る。この動作を有するルール
が発火すると、そのノードアーギュメントの値が黒板に
送られるだろう。機能障害の値は自動的に黒板に送られ
ることに注意されたい。

【０１３３】割当：この動作は二つのアーギュメント、
第１が変数名、第２がノード名を取る。第２のアーギュ
メントの値は変数ノードの値スロットに入る。

【０１３４】表示：この動作はアーギュメントを取らな
い。ルールが発火すると、追跡パラメータによって表示
されているのと同様の情報が画面上に表示される。この
動作は、ルールを監視する必要があれば有用だが、（ブ
レークポイントがそうであるように）その実行を停止し
ないし、ルールベースの他の部品に関する情報も表示し
ない。

【０１３５】性能：本プログラムは、発火済みと未発火
のルール数と併せて、その始動時間と停止時間を記録す
るだろう。黒板呼び出し時間も記録される。本モジュー
ルについては、Ｃ++に記されている。

【０１３６】ケースベースの知識源本プロセスでは、各ケースを現行データと比較すること
によって、そのケース表に記憶された各ケースの類似値
を計算する。

【０１３７】プロセス名：ケースベースデータ構造：図１３では、ケース表で表される情報を示
す。ケースベースのプロセスは、図１６で示すような時
間依存データのための二つの分離構造、静的データ配列
及び動的データ配列の表中のデータを表現する。静的デ
ータ配列は単に浮動小数点の数（二種）の配列である。
動的データ配列は、各セルが履歴配列を指すポインタの
配列である。その配列の各セルには値／時間対が順番に
含まれる。関数／ウェイト情報を記憶するには、そのデ
ータ配列に加えて、他に二つの構造が必要である。その
ような構造の一方は静的データ配列に対応し、それはそ
れ自体関数／ウェイトである。他方の構造は動的データ
配列に対応し、それはウェイト／ポインタ対から成る。
ウェイトは時間依存データとの整合という結果を得るた
めに用いられる。ポインタは、関数／ウェイト対から成
るもう一つの配列を指す。これらの構造に加えて、ケー
スが対応する黒板のオブジェクトの名称と属性及びその
ケースの記述と一緒に各ケースの最終スコアを保持する
には合計配列が用いられる。

【０１３８】論理の流れ：本プログラムには二つの部分
がある。最初に、ケース説明ファイルから上記の構造が
初期化（ロード）される。それから、本プロセスを動作
させる度に、現行データが構造中のデータと比較され、
公式に基づいてスコアがつけられる。

【０１３９】プログラミングの指針：スコアをつけるた
めに用いられる次の四つの関数ｆがある、equal 〔等し
い、ＥＱ〕、less than 〔小なり、ＬＴ〕、greater th
en〔大なり、ＧＴ〕、及び曲線上の整合点である。後者
の関数は、関数／ウェイト配列中でＥＱとウェイト１に
変換される。すべての値は浮動小数点の数（二重）であ
るから、その二つの値が互いに幾分小さいパーセンテー
ジ（例えば、１％）内にある時はいつでも、ＥＱ関数は
真と定義される。これはすべての同様のケースにおいて
真である。

【０１４０】関数適用結果の範囲は０から１までであ
る。ユーザ定義点間で補間される。

【０１４１】以上のすべてはさておき、黒板上に類似ス
コア点を戻すには基準が必要である。例えば、そのスコ
アが、あるケースで考えうる最大スコアの既定パーセン
テージより大きい場合は常にそうである。かくて、その
最大スコアは一旦計算されると、合計配列に記憶され
る。これがインプリメンテーションされる際に、そのス
コアが常に黒板に書き戻される。

【０１４２】このように、機能仕様書で述べられている
ように、各動作の終わりに出力ファイルが書かれるので
ある。

【０１４３】ユーザインタフェース本モジュールはソフトウェアの操作にとって本質的な二
つの機能を実行する。それはユーザがシステムと対話す
るための主要な手段である。それはまた、診断の実行中
にデータの「提供者」として働く。

【０１４４】プロセス名：ユーザインタデータ構造：図１７は、入力データを記憶するために用
いることができるデータ構造を示す。この結合リスト
は、一つのデータファイルのコンテキストから作成さ
れ、時間タグで決定された通りの然るべき時間に事象検
知部へデータを提供するのに用いられる。この時、デー
タ値は一種類のみ（二重）であり、他の種類のデータは
将来追加されなければならなくなるかもしれないことに
注意されたい。

【０１４５】論理の流れ：図１８は本プログラムを、作
成する操作手順を示す。本プロセスには三つの部分があ
る。

【０１４６】まず、黒板と知識源の説明を判定するファ
イル名である。これらのファイル名は、<system name>.
sys という名称のシステムファイルに保持される。この
ファイル名はアーギュメントとして本プログラムに送ら
れねばならない： user int <system name>.sys 次に、その他のプロセスが起動される。まず黒板プロセ
ス、それから、制御プロセス（事象検知部と活性化／ア
ジェンダマネージャ）、続いて知識源である。実際に診
断の実行が開始されるのは、システムがロードされた後
である。まず、ユーザには実行パラメータを設定する選
択権がある。追跡、記録、ステップ及びブレークポイン
トを設定する或いはＯＦＦにすることができる。ＳＦ、
ＮＦ、α、βの値を設定できる。すると、ユーザにデー
タファイル名が求められる。この時点でユーザは、時間
換算係数を指定してもよい。時間換算係数は、データセ
ットを実時間より早目に或いは遅目に実行するために時
間尺度を「縮小」したり「拡大」したりするのに用いら
れる。次いでデータセットは、残りのセットがなくなる
まで、一度に一つずつ事象検知部に提供される。その
後、ユーザが望むだけ、実行パラメータの設定と診断の
実行が繰返される。

【０１４７】プログラミング：指針プロセス起動後、ユーザインタフェースは、プロセスが
そのファイルの正確なローディングを確認するまで待機
する。エラーが生じた場合は、ＫＮＡＣＫメッセージが
出るだろう。このメッセージには、エラーメッセジが含
まれ、それは表示される。この場合、ユーザは、エラー
付きファルを別のＵＮＩＸシェルに固定後に、そのロー
ディングを繰返す選択権を有する。

【０１４８】ファイル中の構文上の問題によるエラーメ
ッセージの表示は、ローディングプロセスとユーザイン
タフェースの両方の責任である。追跡、記録、及びステ
ップの実行パラメータの設定は、ユーザインタフェース
から、メッセージを経て、知識源に対して行われる。し
かし、ブレークポイントの設定では、ルールベースの知
識源に対する通過制御が必要である。

【０１４９】ユーザに時間縮小係数を求める前に、プロ
グラムはデータファイル中の最後と最初の時間スタンプ
の差に基づいて、実時間で診断を実行するのに必要な時
間を表示する。データセット間の間隔が利用可能な時間
分解能より小さくなるので、データセットが重ならない
ように、時間縮小を行なわなければならない。

【０１５０】インタフェースの記述本節では、モジュール間のインタフェースについて詳述
する。それには又、シェルの入出力ファイルのためのメ
ッセージフォーマットの説明とファイルの構文構造が含
まれる。

【０１５１】図１９は本システムの構成の詳細図であ
る。それは本シェルに必要なソケット接続（４．１
節）、メッセージ経路（４．２節）、Ｉ／Ｏファイル
（４．３節）を示す。図１９では、マンーマシンインタ
フェース及びその接続は示されないが、そのインタフェ
ースの条件については、本節で述べる。

【０１５２】ソケットシェルのモジュール間のプロセス間通信は、Ｂｅｒｋｅ
ｌｅｙプロセス間通信（ＢＳＤＩＰＣ）ソケットの使用
に基づいている。これは二つのプロセス間でデータを転
送できるようにメッセージ通過手段をもたらす。

【０１５３】ソケット機構はネット間ドメインソケット
を通じて一連の関連動作を与える。機能対機能ベースで
二つのドメイン間には互換性が存在する。

【０１５４】流れソケットは信頼性のある双方向通信を
もたらすので、本シェルではそれらを採用する。そのチ
ャネルでの通信は、ＵＮＩＸパイプ（ファイルの流れ）
での通信に対してアナログ的である。本シェルではその
ソケットを用いて、メッセージシーケンスのメッセージ
を交換する。メッセージシーケンスは本質的に要求−応
答対である。その開始プロセスが動作を要求すると、レ
シーバがその動作の結果、成功の確認又は故障の通知の
いずれかに応答する。

【０１５５】本節の至る所で、要求メッセージはエラー
と無縁であると想定されている。しかし、応答が必要と
なる前にエラーを検知できれば、プロセスは故障通知
（ＫＮＡＣＫ）メッセージ中のエラーに応答するだろ
う。

【０１５６】本シェルの場合、セッション実行が始まる
前にすべての必要なソケットチャンネルが確定される。
シェルが起動されると、３節で述べる七つのプロセスの
各コピーが起動される（ユーザインタフェース、黒板、
事象検知部、活性化／アジェンダマネージャ、マンーマ
シンインタフェース、ルールベースの知識源、ケースベ
ースの知識源）。それから一連のソケット確定が始ま
る。

【０１５７】ユーザインタフェースプロセスは、それが
初期化される時、傍受キューと結合したソケットが確定
する。事象検知部、黒板、活性化／アジェンダマネージ
ャ、マンーマシンインタフェースの諸プロセスが起動さ
れると、それらは各々ユーザインタフェースとのソケッ
ト結合を要求する。この要領で、三つのソケットチャネ
ルが確定される。黒板、事象検知部、活性化／アジェン
ダマネージャは各々傍受キューと結合したそれ自体のソ
ケットを確定する。四つの追加ソケットチャネルは次の
ように確定される。事象検知部対黒板用チャネル，事象
検知部対活性化／アジェンダマネージャ用チャネル，活
性化／アジェンダマネージャ対黒板用チャネル及び黒板
対マンーマシンインタフェース用チャネルである。

【０１５８】アプリケーションの知識源は元の知識源プ
ロセスから派生するので、追加ソケットチャネルが確定
される。各知識源用にユーザインタフェース、事象検知
部、黒板及び活性化／アジェンダマネージャとの〔結
合〕ソケットが確定される。

【０１５９】シェル内でのソケット接続には二つの固有
の用法がある。第一の用法は、データ指向であり、モジ
ュール間の転送のためのアプリケーションデータの要求
と提供にかかわっている。第二の用法は、制御指向であ
る。これは当然諸プロセスの動作とプロセス動作モード
の変更を意味する。

【０１６０】しかし、確定されたソケットの種類はその
使用とは無関係である。いずれの種類の用法の動作も許
される。メッセージの内容がその用法を決定する。本文
書で用法を区別するのは、ここで示される設計情報を効
果的に類別するためである。一つのソケットチャネルだ
けで、通常はデータ指向と制御指向の両方のメッセージ
シーケンスを利用する。これが事象検知部対ユーザイン
ターフェイス用ソケットチャネルである。データ関連の
ソケットは五種類の固有のメッセージを伝達する。それ
らを図２０で示す。これら五種類のメッセージに対応す
るメッセージの流れの構文フォーマットについては以下
に述べる。

【０１６１】黒板へのデータと黒板からのデータの間で
ＤＡＴＡＳＵＰというメッセージの種類を更に区別する
ことができる。この区別（すなわち、どのプロセスがデ
ータを送信中であるか）は、構文情報で行える。しか
し、メッセージのコンテキストは両方のＤＡＴＡＳＵＰ
メッセージにとっては同様であるから、特定の指定メッ
セージフォーマットは不要である。このソケットチャネ
ルは、セッション実行前にシェルのプロセスの初期化の
一部として確定される。

【０１６２】ユーザインタフェースの任務の一つは、事
象検知部にデータ入力を提供することである。セッショ
ン実行の初めに、ユーザインタフェースは入力データフ
ァイル（ＩＤＦ）からのデータをそれ自体の内部のデー
タ構造へ読み込む責任がある。（正確に換算された）デ
ータの時間スタンプで指定された時間に、ユーザインタ
フェースはＤＡＴＡＳＵＰメッセージを事象検知部へ送
ることによって事象検知部にデータセットを提供するだ
ろう。事象検知部は双方向の一方でメッセージに応答す
る。もし構文エラーがあれば、事象検知部がＫＮＡＣＫ
メッセージを返す。そうでない場合は、事象検知部がＤ
ＡＴＡＳＵＰメッセージを黒板へ中継する。このチャネ
ルは又、制御指向メッセージを伝送する。これらのメッ
セージについては、ここで論述する。

【０１６３】このソケットチャネルは事象検知部と活性
化／アジェンダマネージャが初期化中に確定される。ア
プリケーションのセッション実行開始前に（入力データ
読み取り時に）接続が確定されねばならない。

【０１６４】そのチャネルは、活性化される知識源のリ
ストを事象検知部から活性化／アジェンダマネージャへ
送るのに用いられる。事象検知部は、知識源のリストを
含むＫＳＳＵＰメッセージを通す。活性化／アジェンダ
マネージャは、正確なメッセージが受け取られた事を示
すために、ＡＣＫメッセージで応答する。このソケット
チャネルは、事象検知部と黒板が初期化中に確定され
る。接続はアプリケーションセッション実行開始前に確
定されねばならない。

【０１６５】そのチャネルは黒板へデータ更新を伝達
し、又、事象検知部が黒板からのデータを要求し、黒板
がデータを伝達するための双方向チャネルをもたらす。
このソケットチャネルを通過する二つのメッセージシー
ケンスがある。一方のメッセージシーケンスは、ＤＡＴ
ＡＳＵＰメッセージで黒板上で更新されることになる事
象検知部提供データである。黒板は正確なＤＡＴＡＳＵ
Ｐメッセージを受け取ったことをＡＣＫで確認する。他
方のメッセージシーケンスは、事象検知部がＤＡＴＡＲ
ＥＱで黒板からのデータを要求し、黒板がＤＡＴＡＳＵ
Ｐでデータを提供するものである。

【０１６６】このチャネルは、たった一つのメッセージ
シーケンスを除いて、事象検知部対黒板接続と同一の要
領で機能する。これが前節で述べたＤＡＴＡＲＥＱ−Ｄ
ＡＴＡＳＵＰシーケンスである。このチャネルの実行条
件は、事象検知部対黒板の実行条件と同一である。詳細
については前節を参照のこと。

【０１６７】セッション実行の前に、マン−マシン対黒
板チャンネルが確定される。ＤＡＴＡＳＵＰメッセージ
で、データは黒板からマン−マシンプロセスへ送られ
る。選定された対象のみが、マン−マシンプロセスへそ
のデータを送信できる。これはデーモンの使用によって
黒板構造記述ファイルで指定される。

【０１６８】本アプリケーションの各知識源に一つのソ
ケットチャネルが確定される。アプリケーションファイ
ルがユーザインタフェースに対して指定されると、各チ
ャネルは確定される。この時点で、必要数の知識源プロ
セスがシェルによって承知される。各派生知識源プロセ
スが初期化中に、黒板とのソケット接続を要求する。知
識源対黒板用チャネルに、ある種類のメッセージシーケ
ンスが用いられる。これが事象検知部対黒板用チャネル
の場合で述べてＤＡＴＡＲＥＱ−ＤＡＴＡＳＵＰシーケ
ンスである。ここでは、知識源はデータの要求者であ
り、黒板はデータの提供者である。

【０１６９】各知識源は事象検知部とのソケット接続を
有する。その接続は、知識源が初期化中に確定される。

【０１７０】このチャネルのメッセージシーケンスが、
事象検知部対ユーザインタフェース用チャネルの場合で
述べたＤＡＴＡＳＵＰ−ＡＣＫシーケンスである。事象
検知部は、ＡＣＫメッセージをデータ提供知識源に送る
ことによって、知識源からのＤＡＴＡＳＵＰメッセージ
に応答する。

【０１７１】六種類の制御指向メッセージがある。それ
らを図２１で示す。

【０１７２】これらのメッセージの種類に対応するメッ
セージの流れの構文フォーマットについては、ここで述
べる。このソケットチャネルは、アプリケーションのセ
ッション実行前のシェルの諸プロセスの初期化中に確定
される。ユーザインタフェースは事象検知部プロセスを
制御する責任がある。ユーザインタフェースは然るべき
制御メッセージを事象検知部に送る。事象検知部は、そ
のメッセージが正確ならば、ＡＣＫメッセージで応答す
る。このソケットチャネルは、アプリケーションのセッ
ション実行前のシェルの諸プロセスの初期化中に確定さ
れる。前節の場合のように、このチャネルは、ユーザイ
ンタフェースが活性化／アジェンダマネージャへ然るべ
き制御メッセージを通信するのに用いられる。このソケ
ットチャネルは、アプリケーションのセッション実行前
のシェルの諸プロセスの初期化中に確定される。

【０１７３】再度述べるが、このチャネルは、ユーザイ
ンタフェース対事象検知部用チャネルの場合で述べた通
り、ユーザインタフェースが黒板を制御するのに用いら
れる。このソケットチャネルは、知識源派生後、知識源
の初期化中に確定される。希望時にはＳＴＯＰメッセー
ジで、ユーザインタフェイスが知識源プロセスを遮断で
きなければならない。これがそのチャネルの一つの用法
である。もう一つの用法は、ユーザが知識源用の動作パ
ラメータを設定したい場合である。その時、ユーザイン
タフェースが知識源へＳＥＴＰＡＲＡＭメッセージを送
って、所望の動作モードを通信する。

【０１７４】このソケットチャネルは、知識源が派生し
た後、知識源の初期化中に確定される。このチャネルの
目的は、知識源の推論開始時刻になると、活性化／アジ
ェンダマネージャが知識源を活性化させうるようにする
ことである。それは然るべき知識源にＡＣＴＩＶメッセ
ージを送って、診断機能を生成するための活性化動作を
開始すべきことを知らせることである。知識源の実行完
了時には又、制御メッセージが知識源から活性化／アジ
ェンダマネージャへ送られる。このことにより、アジェ
ンダマネージャは知識源のための状態記録を更新でき
る。

【０１７５】メッセージソケットを通るメッセージが９個、個別に存在する。全
てのメッセージは整数コードによりヘッドされ、そして
それは後続のメッセージのテープを識別する。図２２は
各メッセージの整数コードを示す。実際のインプリメン
テンションコードはソース及び行先プロセスに対する付
加情報を含む。

【０１７６】メッセージ形式に対し図示されている余白
記号は明瞭のためである。実際のデータメッセージ形式
はメッセージのサイズを含み、またそれは効率的に整列
しておかねばならない。

【０１７７】ＤＡＴＡＲＥＱこのメッセージには、値を求められる、ひと続きのオブ
ジェクトの属性が含まれる。図23には、メッセージ書式
を示す。メッセージは、DATAREQ 識別子から始まり、そ
の属性データを要求されるオブジェクトの個数がそれに
続く。次いで、各オブジェクト名称及び属性名称が、列
記される。

【０１７８】ＤＡＴＡＳＵＰこのメッセージには、ひと続きのオブジェクトの属性
が、その属性の値及び属性の時間スタンプと共に含まれ
る。図24には、メッセージ書式を示す。書式は、属性値
と時間も含まれること以外は、DATAREQ メッセージのも
のと同様である。ＫＳＳＵＰこのメッセージには、活性化させるべきひと続きの知識
源識別子が含まれる。その先頭には、KSSUP 識別子が付
けられる。図25には、メッセージ書式を示す。そのメッ
セージ先頭は、KSSUP 識別子が付けられ、その後にひと
続きの知識源識別子が続く。知識源識別子は、応用のた
めの独特のハンドルであって、当該システムファイル内
の、知識源ファイル名の出現順序により決定される。UN
IX処理番号は、ハンドルとして使わない方が良いことに
注意されたい。

【０１７９】ＡＣＫこのメッセージは、通信開始処理に返されるACK 識別子
コードのみからなる。ＮＡＣＫこのメッセージは、整数NACK識別子コードからなる。

【０１８０】ＳＴＡＲＴこのメッセージは、START 識別子からなり、その後に文
字列が続く。文字列は情報を他のプロセスへ渡す方法を
与える。もし、文字列を送る処理が、開始準備完了して
いるならば、これは、文字列"OK"を、ユーザインタフェ
ースに送る。さもなければ、これはエラーメッセージを
送り、ユーザインタフェースにより表示されるはずであ
る。

【０１８１】ＳＴＯＰこのメッセージは、STOP識別子からなる。

【０１８２】ＡＣＴＩＶこのメッセージは、ACTIV 識別子からなる。

【０１８３】ＳＥＴＰＡＲＡＭこのメッセージは、SETPARAM識別子からなり、その後に
引数（文字列）のリストが続く。引数は受信処理に対し
て、どんな特定パラメータ設定作業を行うべきかを指定
する。図23はメッセージの構成を示す。六種のパラメー
タコードがある。これらは、トレース、log 、ステッ
プ、ブレークポイント、α／β及びsf/nfである。メッ
セージ内では、トレース、log 及びステップに一個のス
テータスコードが付随する。α／β及びsf/nf の後には
第一及び第二パラメータ値である浮動点を示す二つの数
が続く。ブレークポイントについては、ユーザが受信処
理に働きかけてブレークポイントを設定しなければなら
ない。

【０１８４】入力／出力ファイルシェルに使用されるファイルはすべて、特定の接尾辞を
使用して、タイプ別に識別される。ファイル名はファイ
ル名．接尾辞であって、ファイル名は用途開発者が与え
る説明的名称であり、かつ接尾辞がファイルの種類を識
別する。接尾辞識別子は、下記の適切なセクションの中
で指定される。通常、接尾辞は小文字か大文字で表すこ
とができる。入力ファイルはシェル外で作られてから、
システムファイルの仕様によりシェルに適用される。下
記の取決めは、このセクションの入力ファイルの構文を
示す数字に使用される。イタリック書体の字句（FUNCTI
ON; 等）は、そのまま正確に示さねばならない。イタリ
ック書体の字句（オブジェクト名１等）はユーザが支給
すべき情報を意味する。草書体のテキストは説明情報で
あり、実際のファイルには現れない。ファイルの選択可
能なエレメントは<>の中に示す。一般に、エレメント
が、ファイル内で現れる順序が重要であり、かつ、ここ
に示すものと同一でなければならない。

【０１８５】すべての空白スペースキャラクタ（スペー
ス、タブ、行端末）は、明白にするために拡大すること
ができる。行端末スペースによるエントリエレメントの
分離は、ファイルをより読み易くするために推奨され
る。Ｃ++言語から援用する／／を用いた行端末注釈書式
を使用して、ファイルのどの点でも注釈を挿入すること
ができる。最後になるが、時間スタンプの参照には必
ず、下記の構文が必要である。

【０１８６】 “ｍｍ／ｄｄ／ｙｙｙｙｈｈ：ｍｍ：ｓｓ” ファイル名.sysとして識別されるこのファイルには、フ
ァイル名の一個のリストが含まれる。そのファイル名
（複数）によって、黒板構造記述ファイル（BSDF）、及
び特定の適用のためのルールベース定義ファイル（RBD
F）とケース記述ファイル（CDF ）の両方のすべての知
識源ファイルが識別される。知識源ファイルのために、
表示形式をも個々で定義することができる。もしファイ
ル名の後に“.NORMAL ”が続く場合には、その知識源は
標準サイズのウィンドウを割当てられる。もし、NORMAL
スイッチが省略されるか、またはもし、ICONスイッチが
使用される場合には、知識源は、画面の上左隅に、アイ
コンのみを割当てられる。図24は、ファイルの構文を示
す。ファイル仕様書内の経路名を使用するためには、す
べての正規MP-UX ルールが適用されることに注意された
い。有効なシステムファイルには、まず一つのBBファイ
ルが確実に含まれ、その次に最低一つの知識源ファイル
が来なければならない。すべてのルールベース知識源フ
ァイル名は、ケースベースファイル名の前に置かねばな
らない。

【０１８７】黒板構造記述ファイル黒板構造記述ファイル（BSDF）は、黒板プロセスにより
使用される内部構造を作成するために必要な情報を含
む。BSDF内の情報はこの中に述べる黒板構造内に直接書
き込まれる。BSDFはファイル名.bb として識別される。
BSDFの構文は図25に示す。

【０１８８】黒板内の各オブジェクトは、BSDF内に別個
のエントリを有する。オブジェクト毎に、そのオブジェ
クトのすべての属性は名称により識別される。各オブジ
ェクトは、独特の名称を有する。属性名は、必要に応じ
て繰返される。値のタイプの選択内容は、図３に示され
ている。しかしながら、この実行には、タイプが二回使
用されるだけである。

【０１８９】有効なBBファイルは、最低一つの属性を有
する。最低一つのオブジェクトを含まねばならない。

【０１９０】ルールベース記述ファイルルールベース定義ファイル（RBDF）はルールベース知識
源を作成するために必要な情報が含まれる。RBDFのデー
タは本書に述べるルールベースの構造内に直接書き込ま
れる。RBDFは、ファイル名.rb として識別される。構文
は、図26に示す。

【０１９１】RBDFに対しては三つの部分がある。RBDFの
EVENTS部分は、入ってくるデータが当該ルールベースと
直接関係がある事象を構成するか否かを判定するための
事象検知部により使用される、式のリストである。更に
知識源が活性化されるべきか否かを判定するために、活
性化／アジェンダマネージャが使用される。EVENTS及び
PRECONDITIONS の式のリストについては、リストは論理
和の性格を持つと了解される。即ち、評価結果が真にな
る式であればどれでも適切な処理（事象検知部または活
性化／アジェンダマネージャ）に対して、ある一定の条
件が満足されているということを示す。もし、事象に関
する式がない場合には、その知識源は、前提条件部分
が、一個の演算子を含む場合にのみ、実行する。もし、
前提条件の式がない場合には、知識源は、その事象の一
つが真であれば必ず活性化される。接頭辞“EXPRESSIO
N: ”には、式が続かねばならない（即ち、式が存在し
ないならばこれは存在してはならない）。

【０１９２】RBDFのルールベースの構造部分は、ルール
ベース知識源プロセスが必要とする構造情報を含む。ユ
ーザインタフェースは、これら三つのプロセス（即ち、
事象検出部、活性化／アジェンダマネージャー、及びル
ールベース知識源）のそれぞれに対して、RBDF名称を与
える。必要な情報を引き出すことはそれぞれの責任であ
る。RBDFの各セクションは一列に並べた'*' の文字によ
り分離される。RBDFのルールベース構造部分において使
用される式に加え、EVENTS及びPRECONDITIONSに使用さ
れる評価式は、本書の補遺B において更に議論される。

【０１９３】その他の解説：ルール、メタルール、及び
評価部におけるノード、コンテキスト、及び区分線形に
関する照会先はすべて、当該ファイルのRULE BASE STRU
CTURE の部分において、まず第一に定義されねばならな
い。

【０１９４】***** 及び------の文字列は、ファイルの
セクション間のセパレータとして、構文解析用ソフトウ
ェアにより使用されるので、必要な構文である。

【０１９５】区分線形のXY-LIST には、昇順のX 値がな
ければならない。

【０１９６】最低一つのコンテキストには、１の値がな
ければならない。即ち、ファイルがロードされた場合、
最低一つのコンテキストは、TRUEでなければならない。
メタルールは実行中にこれを変更することができる。

【０１９７】有効なルールベースは、最低一つのデータ
ノード、一つの誤作動ノード、一つのルール及び一つの
コンテキストを含まねばならない。

【０１９８】各記述ファイル（CDF ）は、ケースベース
知識源を作成するに必要な情報を含む。CDF 内のデータ
は、本書に説明するケース表の構造内に、直接書き込ま
れる。CDF は、ファイル名.cb として識別される。構文
は、図27に示す。

【０１９９】CDF が三部分に分割されることは、RBDFの
分割と同様である。事象及び前提条件部分はRBDFのもの
と同一である。CASE BASE STRUCTURE は、ケース表を作
成するに必要な構造を与える。CASE BASE STRUCTURE
は、二つの部分からなる。第一に、機能（同等、超過及
び未満）が定義される。各機能はパーセンテージポイン
トで表わされる。二つのマージンにより定義される。こ
れらの作用は下記の通りである。

【０２００】同等機能（FEQ ）：もし、二つの数が、互
いの（同等＿低マージン）％以内である場合には、スコ
アは1.0 である。もし二つの数が、（同等＿高＿マージ
ン）％以上異なる場合にはスコアは0.0 である。さもな
ければ二つのマージン間で線形補間法が行われる。

【０２０１】比較大機能（FGT ）：もし現在の数が、
（比較大＿高＿マージン）％を超えてケース履歴値より
大きい場合にはスコアは1.0 である。もし現在の数が、
（比較大＿低＿マージン）％を超えてケース履歴値より
小さい場合にはスコアは0.0 である。さもなければ、二
つのマージン間で線形補間法が行われる。

【０２０２】比較小機能（FLT ）：もし、現在の数が
（比較小＿高＿マージン）％を超えてケース履歴値より
小さい場合にはスコアは1.0 である。もし現在の数が、
（以下＿低マージン）％を超えてケース履歴値より大き
い場合にはスコアは0.0 である。さもなければ、二つの
マージン間で線形補間法が行われる。

【０２０３】第二にケース自体が定義される。各ケース
には名称を与えねばならない。ケース表内の各ケースは
黒板内の一個のオブジェクトの属性に書き込まれねばな
らない。その後に、各ケース毎に値や重みと共に、一組
のオブジェクトの属性が指定される。それらの値は、値
としてタイムペアズを与えられる。各ペアの後に選択可
能な機能名（FEQ 、FGT 、FLT ）、及び重みが続く。も
し後者が省略される場合には、FEQ 及びW1.0（1 の重
み）が仮定される。その結果、機能仕様及び第3.5 セク
ションに定義されるマッチポイントオンカーブ機能が、
機能名及び重みを省略することにより引き出される。

【０２０４】有効なケースベース知識源には、最低一つ
のケースポイントがなければならない。

【０２０５】入力データファイル入力データファイル（IDF ）には、システムへ入って来
るデータをシミュレートする数組のデータが含まれる。
ユーザインタフェースプロセスはこのファイルを読み取
ってそのデータを事象検知部プロセスへ供給する。IDF
は、ファイル名.dat、として識別される。構文は、図28
に示す。

【０２０６】出力ファイル出力ファイルはシェル使用の過程でシェルにより生成さ
れる。

【０２０７】“ＬＯＧ”ファイル LOG ファイルはログフラグが立てられているルールベー
ス知識源により生成される。これらファイル内の情報は
ルールベースの実行により比較的詳細なトレースを与え
る。

【０２０８】“ＯＵＴ”ファイル診断内容を生成する各知識源は、OUT ファイルに書き込
む。ルールベース知識源が生成するOUT ファイル内の各
エントリは、関連する優先度と重要度対策を含む診断メ
ッセージを示す。ケースベース知識源により生成された
OUT ファイル内の各エントリは、そのケースについて計
算されたスコアを含む。これらのファイルには、追加情
報が含まれることがある。

【０２０９】“ＤＩＡ”ファイル診断ファイル（DIAF）は、セッションの動作期間の結果
を含む。それはシェルがたった今完了したばかりのセッ
ションの動作期間中に作った診断内容とケース整合のリ
ストである。その診断内容は、個々のルールベース知識
源が作成した診断内容の整理された組合わせであり、そ
の後に個々のケースベース知識源により発見された、ケ
ースの整合の整理された組合わせが続く。基本的には、
OUT ファイル内に存在する結果は時間ごとに併合され、
分類される。

【０２１０】黒板状態ファイル黒板状態ファイル（BSF ）は、黒板を再現するために必
要な構造情報を含む点がBSDFと似ている。それはまた、
黒板に格納されたすべてのデータ値のスナップショット
をも含む。BSF ファイルを使用して、黒板をその後のセ
ッションの動作中に復元させることができる。BSDFと共
用可能であるので、それはまたファイル名.BB として識
別される。構文はBSDFと同一である。

【０２１１】ユーザとの対話シェルとのユーザの対話はすべて、ユーザインタフェー
スを通して生じる。シェルとの対話に関する一連の名称
は、本書の第２セクションに述べてある。ユーザインタ
フェースの詳細は、本書の第３、６セクションに述べて
ある。

【０２１２】ドメインシェルプログラムは、Hewlett-Pa
ckard 9000シリーズ700 系ワークステーションで使用さ
れるように設計されている。このワークステーション上
においては、HP-UX オペレーティングシステムパッケー
ジ8.05またはそれ以上、が動作するはずである。HP-VUE
のユーザ用視覚的環境もまた、存在するはずである。こ
の環境は、モチーフ（Ｍｏｔｉｆ）をベースとしたＸウ
ィンドウシステム上に階層上に設けられている。ドメイ
ンシェルは、このフレーム内で、Xterm ウィンドウを使
用する。シェルを使用するために、ユーザはシステムに
より使用される入力ファイルを新たに作成しなければな
らない。それ故、個々の入力ファイルの構文及び構造の
他、シェルの全体設計コンセプトに精通することは、有
用である。SDD の第２及び第３セクションは、全体シス
テム結成の記述を含み、ドメインシェルの構成要素の動
作について述べる。新たな入力ファイルの作成はシェル
の使用前に行わねばならない。シェルを使用するために
は、下記のファイルを新たに作成しなければならない：
システムファイル、黒板構造記述ファイル、各ルールベ
ースごとに一つのルールベース記述ファイル、各ケース
ベースごとに一つのケース記述ファイル、及び最低一つ
の入力データファイル。これらファイルの用法は本書に
説明してある。これらファイルの位置は、限定されな
い。けれども、もしそれらがシェルの実行可能ファイル
と同一のディレクトリにのっていない場合には、ファイ
ルの完全な経路名をシステムファイル内に示さねばなら
ない。

【０２１３】システムファイルシステムファイルは、黒板構造説明ファイルを識別する
ファイル名のリスト、及びシステム用のすべてのルール
ベースファイル及びケース記述ファイルを含む。システ
ムファイルは、接尾辞.sys. により、識別される。ファ
イル書式を図27に示す。

【０２１４】システムファイル内のファイル名の順序が
重要であることに注意されたい。黒板構造記述ファイル
の名称をまず指定し、次にすべてのルールベース記述フ
ァイル、最低に、すべてのケース記述ファイルを指定す
べきである。これが図24に示す順序である。一行に一つ
のファイルしか指定してはならない。システムファイル
内に指定されるすべてのファイルが存在しなければなら
ない。さもないと初期化のエラーが生じる。

【０２１５】シェルはシステムファイルに指定されるフ
ァイルが、完全な経路名をシステムファイル内に使用し
ていない場合、シェル実行可能ファイルと同一のディレ
クトリにあると仮定する。

【０２１６】知識源ウィンドウを完全に開くか、また
は、それをアイコン化するかを決定するために利用しう
るオプションがある。デフォールトシステムオペレーシ
ョンは、すべての知識源ウィンドウを、アイコン化する
ことである。けれども、もしNORMALが知識源ファイル指
定行の行末に置かれた場合には、その知識源のプロセス
に連想づけられたウィンドウは、完全に開かれる。この
特徴は、特定の知識源の動作を詳細に観察するのに有用
である。もし望むならば、すべての知識源指定行に同じ
NORMAL接尾辞を使用して、すべての知識源ウィンドウを
完全に開くことができる。デフォールト挙動（アイコン
化された知識源）は、知識源指定行の行末にICONを使用
して、明白に指定することができる。

【０２１７】黒板構造記述ファイル黒板構造記述ファイル（BSDF）は、すべてのオブジェク
トの定義及び各オブジェクトの属性すべてを含む。オブ
ジェクト及び属性は、ユーザが与える名称により識別さ
れる。黒板ファイルは、接尾辞.bb.により、そうである
と識別される。ファイル書式は図２８に示す。

【０２１８】オブジェクト及び連想づけられる属性の名
称は、知識源説明ファイル及び入力データファイル内で
使用される。名称はシェルが正確に作動するために、ス
ペリングとケースに正確に一致しなければならない。タ
イプダブルの黒板データ値しか許されない。特定の最大
履歴長さはない。黒板は、受信するデータポイントをこ
の履歴長さの範囲内に保有するので、過剰メモリーが使
用されることになるし、さらに、履歴長さが知識源が必
要とする長さより長い場合には、システムは不必要に遅
らされることになる。これに関する十分なチェックを行
うには、知識源により要求される履歴長さを再検討し
て、黒板履歴長さを適当に調節することである。

【０２１９】黒板が受信した重要なデータは、DEMON の
特徴を使用して、マン−マシンインタフェースウィンド
ウへ転送することができる。オブジェクトの属性の下に
は、DEMON:MMI ＿WRITE の行を含めよ。黒板がこのオブ
ジェクト属性の新しい値を受信する場合には、そのオブ
ジェクト名及び属性名、及び値はマン−マシンインタフ
ェースへ転送される。その値は、マン−マシンウィンド
ウ内に示される。それによって、システムを作動中に、
どんなオブジェクト属性でも追跡可能になるので、それ
はシェルを用いて仕事をするための強力なツールであ
る。けれども、もしDEMON を働かすオブジェクトが多過
ぎる場合には、システムは遅らされかつマン−マシンウ
ィンドウ内に書き出される値の個数が多くなる。アプリ
ケーションがテストされた後は、DEMON の使用は、障害
を示すような重要なオブジェクト属性のために残してお
くべきである。

【０２２０】ルールベース記述ファイル各ルールベースは、三つの部分からなる記述ファイルに
より定義される。第一の部分は、事象の式のリストであ
り、EVENTSと呼ばれる。これらの式は、事象検知部によ
って、次の目的、つまり、或る知識源を、アジェンダマ
ネジャに送られる発火予定の知識源のリストにのせるべ
きか否かを決定するために使用される。第二の部分は、
事象式のリストであり、PRECONDITIONS と呼ばれる。こ
れらの式は知識源を所定の時間に発火すべきか否かをチ
ェックするためにアジェンダマネジャにより使用され
る。

【０２２１】EVENTSの部分については、事象の式を書く
際に、それらが新しいデータの到着時点に左右されるこ
とに注意すべきである。各事象の式は、唯一発生源（ユ
ーザインターフェイスか、または、その他知識源の一つ
かのいずれか）から到着する新しいデータを、参照すべ
きである。すべてのデータは、事象検知部を通して送ら
れるけれども、データの各発生源（知識源またはユーザ
インターフェイス）は、データを発生源ごとのバッチに
分けて送る。それ故、たとえ他の発生源から到着するデ
ータが、同一の時間スタンプであったとしても事象検知
部は、特定のバッチのデータを、必ず新しいものとして
認めることができる。一般に、表現内に、二つ以上の
「新しい」データポイントを有する事象の式を書く際に
は、注意を払うべきである。

【０２２２】PRECONDITIONS の部分は、EVENTSの部分の
式と同様の式を含む。また、知識源を一定間隔で発火さ
せるように、周期的前提条件を設定することができる。
これは、前提条件として、文「"every n"(n 個毎) 」を
置くことによって行われる。但し、n は、秒単位の間隔
時間である。

【０２２３】第三の部分は、仮定、障害、ルール等、ル
ールベースのすべての構成要素を含み、ルールベース構
造を定義する。ルールベース説明ファイルは、接尾辞.r
b.によりそれとして識別される。ファイル書式の詳細は
図２９、図３０、図３１に示されている。

【０２２４】黒板構造記述ファイルは、必要に応じて参
照され、編集されるべきであるので、黒板要素としてル
ールベース内で名称を与えられているすべてのオブジェ
クト属性は、黒板内の名称と正確に一致する。不一致の
場合、ルールベースは正確に初期化しなくなる。ルール
ベース説明ファイルを構成する場合に利用可能な演算子
は多数ある。

【０２２５】ケース記述ファイル各ケースベースは、やはり、三つの部分を含む記述ファ
イルにより、定義される。初めの二つの部分は、上述の
通りEVENTSとPRECONDITIONS である。第三の部分はケー
スベース自体を含み、値を有する複数のケースの一組で
構成される。ケース記述ファイルは、接尾辞.cb.により
それとして識別される。ファイル書式の詳細は図３２、
図３３に示されている。

【０２２６】ルールベース記述ファイルについては、ケ
ースベースファイル内のオブジェクト属性が、黒板のオ
ブジェクト属性と正確に一致しなければならない。さも
ないと、ロードする際にエラーが生じる。

【０２２７】各ケースは、関連するケース値を有する複
数のオブジェクト属性の一組で構成されなければならな
い。ケース値として使用される時間スタンプは、比較の
ために必要な時間間隔を明らかにするべきである。絶対
時間は重要ではない。例えば、もし特定のケースにおい
て、オブジェクト属性が、10秒間にわたる特有の一組の
値を有する場合には、最近と最古の値間の時間スタンプ
の差は10秒とすべきである。

【０２２８】入力データファイルこのファイルはシェルが使用して実際のデータの到着を
シミュレートするデータからなる。入力データファイル
は、接尾辞.dat. によりそれとして識別される。ファイ
ル書式は図３４に示す。

【０２２９】入力データは一つの特定の時間スタンプを
有するすべてのデータが同一のデータセットの中でまと
められるように、構成されることを期待されている。オ
ブジェクト属性名は、黒板内の名称と正確に一致すべき
である。もし名称が不一致であった場合には、入力デー
タファイルを走査する際に、エラーを報告する。

【０２３０】入力データファイル内のデータは、最初の
データから最近のデータまで、時間的順序で現れるはず
である。

【０２３１】ログファイル診断内容を生成する各知識源は、連想づけられる優先度
及び重要度により、診断メッセージを表すエントリを用
いてログファイル（RLOGF またはCLOGF ）に書き込む。
構文は図３５に示す。

【０２３２】診断ファイル診断ファイル（DIAF）はセッションの実行結果を含む。
これは、関連する確信係数を含む診断のリストである。
構文は図３６に示す。

【０２３３】黒板ステータスファイル黒板ステータスファイル（BSF ）は、黒板を再現するた
めに必要な情報を含む点がBSDFと似ている。BSF ファイ
ルを使用して、黒板はその後のセッションの実行時に復
原可能である。構文は図３７に示す。

【０２３４】プログラムの使用ユーザはドメインシェル実行可能ファイルが存在するデ
ィレクトリ内になければならない。すべての入力ファイ
ルもまた、完全な経路名が、どこか他の場所に所在する
ファイルに使用されていない限り、このディレクトリ内
にあるべきである。また、出力ファイルも、このディレ
クトリ内に書き込まれる。プログラムは実行中最低五個
のウィンドウを開くので、現在開いている一個のウィン
ドウだけを表示させるようにした方がよい。このウィン
ドウは、表示のどこにあってもよいけれども下左隅に設
けることを推奨する。

【０２３５】プログラムは、プログラム名とそれに続け
てファイル名をタイプすることにより呼び出される。現
在内蔵されたままであれば、プログラム名は、user＿in
t.である。もし望むならば、これはユーザが変更するこ
とができる。けれども、その他の実行可能ファイルの名
称は変更してはならない。

【０２３６】ウィンドウは、ドメインシェルプロセス、
黒板、事象検知部、アジェンダマネージャ、マン−マシ
ンインターフェイス、及び、各知識源、のそれぞれに対
して開かれる。すべてのウィンドウは、X タームウィン
ドウであるので、大きさを変更し、移動しまたはアイコ
ン化される。各ウィンドウは、タイトルバー内で適当に
傾斜させられる。知識源ウィンドウは、それぞれの記述
ファイル名により識別される。

【０２３７】すべての知識源ファイルは、最初にアイコ
ン化される（NORMALウィンドウオプションがシステムフ
ァイル内に指定されていない限り）。ただし、ユーザが
望む時に開くことができる。ウィンドウ内では、ユーザ
はウィンドウ内にポインタを置き、Ctrlキーを押したま
ま左または中心のマウスボタンを打ち、かつ希望のオプ
ションを選ぶことにより、種々の観察及び追跡オプショ
ンを選択することができる。ウィンドウ用スクロールバ
ーは、Ctrl-Center-Mouse-Buttonを打ち、オプション"E
nable Scroll bar" を選択することにより使用可能とす
ることができる。

【０２３８】ウィンドウのタイトルバーは、その中で実
行中のプロセスを識別する（但し、ユーザインターフェ
イスウィンドウである）。知識源は、それに連想づけら
れる知識源記述ファイルの名称により識別される。ウィ
ンドウがアイコン化されている場合でも、知識源ウィン
ドウはやはり記述ファイル名によって識別される。その
他のプロセスは二文字略語、すなわち黒板はbb、事象検
知部はed、アジェンダマネージャはam、マン−マシンイ
ンターフェイスはmm、により識別される。

【０２３９】ユーザとの殆どの対話は、プログラムが始
まった第一ウィンドウ内で行われる。このウィンドウ
は、システムが作成された後にユーザに最上位オプショ
ンのメニューを示す。選択肢は四個ある。すなわち、デ
ータ開始、データ継続、オペレーティングパラメータ設
定、及びセッションの終了である。

【０２４０】データ開始オプション１このオプションはユーザが選択すると、ユーザに入力デ
ータファイル名を教える。それから、それは、すべての
知識源にリセットし、セッションの実行の準備をするよ
うに通知する。入力データファイルを走査後、プログラ
ムはデータを実行するに要する時間の長さを、秒で表し
て表示する。ユーザは、それより短いか、または長い時
間で、一つのデータセットの処理を完了するために、タ
イムスケールを圧縮するオプションを与えられる。圧縮
係数はデータファイルから引き出した時間間隔に分割さ
れて、圧縮された間隔を決定する。圧縮係数が設定され
た後、データは入力データファイルから読み取られ、適
正な時間事象検知部宛に送信され、そこから黒板へ転送
される。システムは適宜、知識源を起動しながら、入力
データがなくなるまで動作する。情報メッセージは、当
該データセットの処理が進むにつれて、シェルウィンド
ウ内に現れる。処理が完了すると、ユーザは、ユーザイ
ンターフェイスウィンドウ内に最上位メニューを与えら
れる。

【０２４１】黒板動作の条件は、黒板ウィンドウ内で文
字'>' 及び'<' を使用して示される。データが黒板内に
置かれると、'>' キャラクタが表示される。データが黒
板から検索されると、'<' キャラクタが表示される。

【０２４２】事象検知部は、事象の式の評価を継続しな
がら、'.' という三つの文字の組を表示する。アジェン
ダマネージャもまた、'.' という三つの文字の組を示し
て、活動の完了を表す。マン−マシンインターフェイス
は、黒板がデータを送信するにつれて、そのウィンドウ
内に受信したデータを表示する。送信された各データポ
イントは、オブジェクトと属性の名称と共に表示され
る。DEMON すなわちMMI-WRITE を有するオブジェクト属
性のみが、黒板が新しい値を一個受信した時に限って表
示される。もし、一組のデータが実行された後、「デー
タ開始」が再び選択された場合には、黒板内のすべての
データは廃棄されて、すべての知識源がリセットされ
る。これが、事実上、セッションの動作を再び開始す
る。その後のデータにより実行を継続するためには、
「データ継続」を使用する。

【０２４３】データ継続オプション２このオプションは、オプション１−データ開始と同一の
方法で一組のデータを、システムに実行させる。けれど
も、データ継続オプションの場合は、リセットするため
のメッセージが知識源へ送られないので、黒板データは
以前の実行のまま維持される。これにより、ルールベー
スは直前のデータの組の実行中に、動作結果としてセッ
トされた現在の値を用いて、動作を継続することが可能
になる。オプション１については、ユーザは入力データ
ファイルの名前を教えられる。このファイル内のデータ
は、このオプションが正しく作動するために直前のデー
タの組の中の最後のデータよりも、時間的に新しい時間
スタンプを持つものから始まらなければならない。も
し、その後のデータが直前の実行からのデータよりも早
い時間スタンプを持って、黒板に送られる場合には、黒
板はそのデータを、履歴のない属性の現行値として、黒
板内に置く。けれども、ゼロではない履歴長を有する属
性については、黒板は、その値を、最新の値としてでは
なく、履歴の中のどこかに挿入する。検出器は、「新し
い」データの到着に応じて知識源を発火することがある
ので、上述の処置は、不確定挙動を引き起こす。つま
り、知識源が、黒板からデータを取り出す時、そのデー
タが隠されるので、知識源は、恐らく間違ったデータポ
イントを使用して起動する。

【０２４４】データの組が実行中である時、シェルプロ
セスの外観はオプション１−データ開始の外観と同一で
ある。

【０２４５】オペレーティングパラメータ設定オプショ
ン３このオプションにより、ユーザはルールベース用パラメ
ータを設定することができる。もし、このオプションを
選択した場合には、ユーザはルールベースの名称を教え
られる。ルールベースのみが、動作用パラメータ設定に
関して選択可能である。ケースベース知識源は、パラメ
ータ設定に関する選択ができない。

【０２４６】パラメータを設定するために、六つの選択
肢がある。トレース、ログ、ステップ、ブレークポイン
ト、α／β、及び、SF/NF である。

【０２４７】もし、ユーザがオプション３を選択する場
合には、ユーザは知識源ファイルの名称を記入するよう
に、教えられる。その記入により、パラメータを設定す
べき知識源が指定される。現在では、ルールベースのみ
が、セット可能なパラメータを有する。知識源ファイル
が指定された後、ユーザは、設定すべきパラメータに対
応するコードを記入するよう教えられる。

【０２４８】トレース−パラメータオプション０：も
し、このオプションが選択されると、ユーザは追跡能力
を可能とするか、生かすか、いずれかを尋ねられる。生
かされた場合、ルールベース内の各ルールが発火された
時に、詳細記述が、ルールベースのウィンドウに表示さ
れることになる。

【０２４９】ログ−パラメータオプション１：もし、
このオプションが選択されると、ユーザはロッギング
（記録）能力を不能とするか、生かすか、いずれかを尋
ねられる。生かされた場合、トレースオプションに対し
て生成されたものと同一の記述が、ファイルへ送られる
ことになる。ファイルは、それを作ったルールのベース
記述ファイルと同一のルート名に..log extension を付
けて、命名される。

【０２５０】ステップ−パラメータオプション２：も
し、このオプションが選択されると、ユーザはステップ
機能を不能とするか、生かすか、いずれかを尋ねられ
る。生かされた場合、ステップオプションは、一つのル
ールが発火されると、その都度、ルールベースを停止さ
せる。すなわち、ルールベースは、ユーザが、ルールベ
ースウィンドウ内で応答することにより、ルール発火を
認めた場合にのみ、継続する。それ故、このオプション
が生かされると、ユーザは、彼の関心の焦点を、ルール
ベースウィンドウに移すことが必要である。ルールベー
スが起動すると、処理動作は停止し、かつ、ユーザはル
ールベース内に選択肢を持つことになる。データは、黒
板に送り続けられ、かつ、その他のすべてのシェルプロ
セスは続行する。けれども、それ以後の知識源発火は、
ユーザがルールベース内のルール全部について歩進を完
了するまで遅延される。それ故、シェルの残りの部分の
実行は、不能とされる。ステップオプションの目的は、
ユーザがルールベース内のルール発火の順序を項目ごと
に追うことを可能にすることである。その使用は通常、
プロセス実行のタイミングを狂わせるので、それは、デ
バッギングのために、ただ一つの知識源のみの構成とし
て使用するべきである。

【０２５１】ブレークポイント−パラメータオプショ
ン３：もし、このオプションが選択されると、ユーザは
ルールベースウィンドウ内のルールに対して、ブレーク
ポイントを設定または除去することができる。このオプ
ションを使用するためには、ユーザは適切なルールベー
スウィンドウへ移動して、ブレークポイントをセットし
なければならない。ルールベースウィンドウにおいて
は、ユーザは、ルールベース内の任意のルールのための
ブレークポイントを設定し、かつ除去することができ
る。完了時には、ユーザは第一ウィンドウに戻って、最
上位オプションを選択しなければならない。ステップオ
プションの場合と同様に、もし、ブレークポイントが設
定されると、ルールベースオペレーションは、発火中、
中止される。ブレークポイントを使用することは、全体
として、シェルの性能よりもむしろ、ルールベースの動
作を観察するためである。換言すれば、これは、デバッ
ギングのために、ただ一つの知識源の構成として使用す
べきである。

【０２５２】α／β−パラメータオプション４：も
し、このオプションが選択されると、特定のルールベー
スに対してα及びβ遮断用の大域的な値を設定すること
ができる。ユーザは、α及びβの値（-1.0ないし+1.0）
を記入するよう教えられる。次に、これらの値は、指定
されたルールベースに渡される。

【０２５３】ＳＦ／ＮＦ−パラメータオプション５：
もし、このオプションが選択されると、特定のルールベ
ースに対してルールごとの充分性係数と必要性係数（SF
及びNF）の全体的な値を設定することができる。ユーザ
は、SF及びNFの値（-1.0ないし+1.0）を記入するよう教
えられる。これらの値は、次に、指定されたルールベー
スに渡される。

【０２５４】セッションの終了−オプション６：もし、
このオプションが選択されると、セッションの動作が終
了して、プログラムが存在する。出力ファイルは、SDD
について本明細書中で述べる通りに、書き込まれる。各
知識源は、診断リストを含む一個のログファイルを生成
した。黒板は黒板入力ファイルからの構造の情報を含む
出力ファイル及び黒板内に現在記憶されているすべての
データ値のスナップショットを書き込む。

【０２５５】出力ファイルセッションの動作が終了すると、各知識源は、動作の結
果を含む最低一つの出力ファイルをプリントアウトす
る。一個のルールベースは、もし、そのパラメータが、
パラメータ設定オプションを通して設定されていた場合
には、一個のログファイルをプリントアウトすることが
可能である。

【０２５６】一組のデータが実行された後、セッション
の動作が終了する都度、当該システム用のすべてのルー
ルベースは、診断の結果を用いて、一個の新たな出力フ
ァイルを作る。このファイルは、ルールベース記述ファ
イルと同一のルートファイル名を持つけれども、接尾
辞.out. が付けられる。ルールベースが発火される都度
生成された診断結果は、このファイル内に書き込まれ
る。書き込まれたデータには、診断の結果、発火された
ルール数、及び、発火されたルール数／秒が含まれる。

【０２５７】もし、当該ルールベースに対して、LOG オ
プションが選択された場合には、一個の新たな出力ログ
ファイルが作成される。このファイルは、ルールベース
記述ファイルと同一のルートファイル名を持つけれど
も、接尾辞.log. が付けられる。これには、ルールベー
スの動作順序を示す、詳細なメッセージが含まれる。

【０２５８】ケースベースプロセスは、ケース説明ファ
イル名のルートと同一のルート名及び接尾辞.out. を有
するファイル内に、ケースをスコアした結果を全部書き
込む。ファイルには、完全なデータセットの実行内容に
対してスコアした結果の記録が含まれる。

【０２５９】黒板は、入力ファイルからのすべてのオブ
ジェクト及び属性に関する情報、及び、黒板内に現在格
納されているすべてのデータを含む、一個の出力ファイ
ルを生成する。このファイルは、その後のセッションず
つのいくつかの動作のための入力ファイルとして、使用
することができる。この場合には、入力データセット
は、黒板内の最新データよりも、時間的に新しい時間ス
タンプを含むべきであり、さもないと不確実な挙動が生
じる。

【０２６０】エラーシェルを使用する場合に生じるエラーは、一般に、二つ
の種類に分けることができる。すなわち、構文／ローデ
ィングエラー、及び論理エラーである。もし、或る特定
の知識源がエラーに出会った場合、それは、エラーが存
在するファイル内の行数を明らかにする、エラーメッセ
ージを表示する。エラーメッセージは、ユーザインター
フェイスヘ送られる。これは、ユーザインターフェイス
に、シェルプロセスを無効化して排除しようとさせる。

【０２６１】論理エラーは、知識源ファイルに含まれる
情報が、誤ったルール等により、所要の働きに対応しな
い場合に生じる。これらのエラーは、所在を突止めるの
が困難なことがある。シェルは、個々のシェルのプロセ
スの動作を理解するためにそれを見守るのに役立つ、数
種の手段を提供する。これには、ルールベース用のパラ
メータ設定オプションが含まれる。また、黒板にはられ
たオブジェクト属性の値は、DEMON の特徴を使用して、
マン−マシンウィンドウ内に表示させることができる。
すべての出力ファイルは、エラーを発見するのを助ける
ために使用することができる。

【０２６２】制御モジュール制御モジュールは責任をもってシェルの各部分の活性化
を調整する。それは、アプリケーション開発者が、下記
特性を示すアプリケーションをもたらしうる制御動作を
指定できるよう設計されている。

【０２６３】速度とは、短時間且つ最小の制御オーバヘ
ッドによってタスクを実行する能力である、応答性と
は、反応が要求される時、変化した条件に反応する能力
である、適時性とは、必要なときに結論（全面的または
部分的診断）に達することができる能力である、適応性
とは、条件の変化に応じて計画を変更する能力である。

【０２６４】これらの特性は制御モジュールソフトウェ
アに固有のものとして組み込まれるのではなく、むしろ
制御モジュールの機能を上手に利用し、それによって所
期結果を得ることが、アプリケーション開発者の責任と
なっていることに注意すること。

【０２６５】速度は各知識源の個々の性能特性に対する
依存度が高い。制御モジュールはオバーヘッドに寄与す
る。制御オバーヘッド時間と知識源実行時間の比率を小
さく維持することが明らかに望ましい。このための一つ
の方法は、オバーヘッドを最小にすることであるが、こ
れが可能なのはある点までである。知識源グレーンの大
きさを増大させるのも一つの方法である。しかし残念な
がら、グレーンの大きい知識源は応答しなくなる傾向が
あり、かくして知識源は割り込み可能となるのである。

【０２６６】割り込みできることは適合性においても役
に立つ。この黒板アーキテクチュアは基本的に事象によ
って駆動されるため、非同期事象は、目下実行中知識源
が無関係あるいは不適当になるぐらいにまで実行環境
（文脈）を変えさせることが可能である。かくて制御モ
ジュールは、現在の知識源を非常停止させて、別の知識
源を実行開始させることができる。

【０２６７】割り込み可能な状況が現れるのは、現在実
行中の知識源よりも別の知識源が優先されるように非同
期事象が、文脈を変える場合である。この状況は、各知
識源で連想づけられている優先レベルを用いて解決され
る。優先順位が高いタスクによって中断された知識源
は、再開可能なものとして定義されうる。

【０２６８】シェルの制御メカニズムの基本的な側面
は、それが厳密に条件によって駆動されることである。

【０２６９】これには２つの動作モードがある：１．データ駆動モード：知識源の実行を起動する条件
は、データの非同期的受信である。このデータは、シス
テムの外部（通常オンラインセンサ）から得られるもの
でもよいし、別の知識源を実行した結果得られるもので
もよい。起動条件を定義するデータを受信するのみなら
ず、むしろ受信されたデータによって、予め定義された
正常な範囲を逸脱するようなもっと特別の条件が満足さ
れるのが通例である。

【０２７０】２．エンドユーザー要求モード：特定の知
識源を実行するための条件はエンドユーザーの要求によ
る。通常このモードは高度な条件が未知のために知識源
が厳密にエンドユーザーの制御によって実行されるか、
あるいは条件の定義が不完全なため、特定の知識源が進
行中の診断プロセスに寄与するのではないかとエンドユ
ーザーが疑問を持つ場合に現われる。

【０２７１】制御メカニズムが機能するためには下記の
情報が必要である：１．プロセス（知識源または外部から）が実行させる一
組の条件。性能上の理由により、起動条件は二つのグル
ープ、即ち事象と前提条件に分けられる。これらの違い
は人為的であるから、機能が最適になるようにこれらの
条件を二つのグループに分けるのはアプリケーション開
発者の責任である。

【０２７２】２．各プロセス（知識源または外部から）
は、割り込み可能または不能として性格付けられなけれ
ばならない。割り込み可能な各プロセスは、ある優先レ
ベルを持たなければならない。

【０２７３】３．割り込み可能な各プロセス（知識源、
または外部から）は、一組の定義された再発火条件を有
する場合があり、その再発火条件は割り込み動作終了時
に、中断された知識源を再活性化させるか終了させるか
を制御メカニズムに判定させることができるものであ
る。

【０２７４】４．各プロセスは、時限式でも非時限式で
もよい。時限式のプロセスの場合は、実行時間を指定し
なければなず、時間が切れると、そのプロセスは中断、
終了または再開される。

【０２７５】条件のチェックは、ルールベースのパラダ
イムの点から考察することができる：ＩＦ条件が真ＴＨＥＮ実行制御ルールの条件部は、補遺Ａに記述する様に、データ
ポイント（黒板オブジェクト／属性として表される）か
ら成る演算数と演算子の式で表される。

【０２７６】知識源であっても外部プロセスであっても
よいが、プロセスを活性化させるものは実行部のみであ
る。

【０２７７】制御メカニズムは、連続的反復するいくつ
かのステップから成る：１．事象検知：黒板へ進むデータはすべて事象検知モジ
ュールを通過する。事象検知部は、一つのデータパケッ
トを受け取る毎に、そのパケット内に情報を含んでいる
事象前提条件の真を評価する。各条件が真の場合は、対
応プロセス活性化要求が次のステップに送られる。

【０２７８】２．活性化：ステップ１から受け取った要
求は、活性化管理モジュールによって処理される。各知
識源または外部プロセスの活性化要求の場合は、その前
提条件が評価される。真と分った前提条件も次のステッ
プに送られる。

【０２７９】３．スケージュール作成：ステップ２から
の要求はアジェンダ管理部が受け取る。このモジュール
は、現在実行中のモジュールを追跡し、優先レベルに従
って新しい要求を計画する。そのため現在の活性化を中
断する必要があるかもしれない。またこのモジュール
は、中断したタスクを再開（再発火）すべきかどうか及
び実行中のタスクを時限切れとするかどうかも判定す
る。

【０２８０】前述したように、制御メカニズムはアプリ
ケーションによって大きく左右される。上記アーキテク
チュアの性質はきわめて一般的であるが、種々のモジュ
ールによって実行されるタスクは、アプリケーションに
特有な多数の要素を含んでいる。通常この種の状況では
手続き（制御動作）と叙述（制御ルール）の方法を混合
使用するアプローチが将来インプリメントされるべきで
ある。

【０２８１】制御モジュールは、発生した、あるいは発
生しかけている機能障害を診断するためのシェルの活動
の調整に応答する。それはアプリケーションの最終目的
の達成に必要な問題解決ストラテジを保管する所であ
る。異なる問題には異なるストラテジが必要となるた
め、制御モジュールはアプリケーションによって大きく
特定化されるにもかかわらず、リアルタイムのプラント
診断領域の共通の特性が与えられれば、いくつかの機能
的要求事項を記述し、実現することができる。

【０２８２】一般的要件シェルのリアルタイムの性質は、下記の制御モジュール
の要件に反映されている：速度とは、短時間且つ最小の
制御オバーヘッドによってタスクを実行する能力であ
る、応答性とは、反応が要求される時、（変化した条
件）に反応する能力である、適時性とは、必要なときに
結論（全面的または部分的診断）に達することができる
能力である、適応性とは、条件変化に応じて計画を変更
する能力である。

【０２８３】一般的特性速度は、各知識源の個々の性能特性に強く依存する。制
御モジュールはオーバーヘッドに貢献する。制御オーバ
ーヘッドタイムと知識源実行時との比を小さく維持する
ことが好ましいことは明らかであるが、これはある点ま
でそのようなことが可能であるに過ぎない。知識源の粒
子サイズを増大することがもう一つの方法である。残念
ながら、大きな粒子状の知識源は応答性の良くないもの
となりがちである。これは、本システムにおける基本的
な要求特性の一つ、すなわち、大きな知識源は割り込み
可能であるという特性を導く。

【０２８４】割り込み可能性もまた、適応性の要件にと
って必要なものである。黒板のアーキテクチャは事象駆
動メカニズムを必須のものとして使用しているため、バ
ラバラに発生した事象が実行環境（コンテキスト）を、
現在実行中の知識源が無関係あるいは不適切になるまで
に変更することは可能である。制御モジュールは、現行
の知識源を緊急時に停止すること、および他の知識源に
制御を与えることができるようにすべきである。

【０２８５】割り込み可能性の一つの側面は、バラバラ
に発生した事象がコンテキストを変更して現在実行中の
知識源が重要性において他の知識源に取って代わられた
とき現れる。この状況は本システムの別の基本的な要求
特性、すなわち知識源を優先しなければならないという
特性を導く。最後に、より優先性の高いタスクのために
割り込まれた知識源は再開可能としてもよいし、しなく
てもよい。これらの特性は、注意の動的な集中という一
つの表現に要約できる。

【０２８６】事象制御メカニズムの基本的な態様は、それが厳格に事象駆
動型であるという点である。制御メカニズムは次の二つ
の動作モードをもっている。すなわち、１．正常な条件下では、制御メカニズムは、純粋にオン
ラインのセンサデータによって駆動される。知識源の実
行の起動となる事象は、単にセンサデータの受取りであ
る。本モードの主要な特性は、機能障害が検出されない
こと、すなわちすべての事物が“正常”であり、エンド
ユーザに対話が要求されないことである。制御モジュー
ルは、基本的に知識源に対し次の２項が始まるまで割り
込みなしに、逐次的な実行を可能とする。

【０２８７】２．即時の注意を要する非同期事象が発生
し、１項はここで終わる。このような事象は、あらかじ
め定義された正常範囲を逸脱するセンサ値によってオン
ラインで発生する可能性があり、あるいはそれらの事象
は知識源を実行した結果であることもあり、あるいはそ
れらの事象は、注意の焦点に対する特定の要求によって
エンドユーザにより発生させることができることもあ
る。事象を発生させるにはまだ他に種々の方法があろ
う。

【０２８８】特殊なタイプの事象に時間の満了がある。
システムロックの計時周期が周期的なデータポイントと
なる。

【０２８９】制御アーキテクチャ黒板の制御メカニズムは、概ね、４ステップのサイクル
の継続的な繰り返しからなる。すなわち、起動、前提条
件チェック、スケジュール、および実行である。図３８
のブロック図は、これらのステップに密接に沿ったアプ
ローチを示すが、若干の相違も示している。各モジュー
ルについて次に説明する。

【０２９０】通信マネージャ／事象検知部は、通常の黒
板に見られる起動メカニズムと、全く同一ではないが、
類似のものである。検知部は、データ源を用いて通信を
実行し、入力データが一つの事象を形成するかどうかを
判定するという二つの役割を行う。データはシステム外
部に由来する場合もあるが、その場合、通信マネージャ
はデータをＩ／Ｏインターフェイス（「インターフェイ
ス要求事項」の節で説明）から、あるいは、ドメイン
（知識源、ユーザインターフェイス、またはシステムク
ロック）から受け取る。いずれの場合も、データはいっ
たん受け取られると、黒板上に書き込まれ、それが適切
ならば、事象の発生がテストされる。この最後のステッ
プの結果は次のモジュール上に送られる。

【０２９１】活性化マネージャは、前提条件チェックの
役割を行う。黒板の多くのアプリケーションにおいて、
これらはどちらかというと時間のかかるタスクで、高い
オーバーヘッドを発生する。システム性能を改善するた
めには単純なアプローチが必要である。ある二ステップ
方式には、第一ステップで参照テーブルを使用して入力
事象に影響を受ける知識源（単数または複数）を発見
し、その自己選択による前提条件を抽出し、第二ステッ
プでその前提条件を実行する。該当する場合、そのタス
クの優先度を判定し、ＫＳＡＲ（Knowledge Source Act
ivation Request/Record：知識源活性化の要求／記録）
を次のモジュールのアジェンダに対して発する。

【０２９２】アジェンダマネージャは、基本的なスケジ
ューラであるが、それは次の知識源を実行するように予
定するのみにとどまらず、現在実行中の知識源に（割り
込み可能な場合に）割り込みが行われたかどうかを判定
し、それが再開可能であるかどうか、等を判定する。こ
の場合、その知識源は中断されるにすぎない（継続する
場合は再予定が行われる）。ただし、このモジュールは
全閉式のアジェンダに基づいたマルチタスキングコント
ローラではなく、むしろここに述べている通り、この傾
斜シェルにおける特定の要求特性を実現するに過ぎな
い。

【０２９３】インプリメンテーション前に説明したように、この制御メカニズムはアプリケー
ションによって特定される度合が大きい。前記のアーキ
テクチャは本来かなり一般的なものであるが、種々のモ
ジュールによって実行されるタスクには、アプリケーシ
ョンによって特定される非常に多くの要素が包括されう
る。通常の場合、この種の状況においては、ブロシージ
ャ法および叙述法を混合して使用するアプローチがもっ
とも適切である。

【０２９４】とくに、事象検知部は、各アプリケーショ
ンに対して大きく特定される。叙述シンタックス（ルー
ル）を使用すれば、アプリケーションの開発者が本モジ
ュールを各アプリケーションに適合するように作り変え
ることができる。叙述のための記述の代表的な例に
は、"whenever"や"every<time intereval>" ルールなど
がある。一方、プロシージャ構成要素は必然的に必要に
なり、考慮しなければならなくなる。他の二つのモジュ
ール、すなわち活性化マネージャとアジェンダマネージ
ャは、前節で説明したアプローチがここで検討している
領域におけるすべてのアプリケーションにわたって適用
されると思われるため、純粋に手続き上のものといえ
る。

【０２９５】インプリメンテーションのもう一つの側面
は、図３８に示すモジュールを実行可能なプロセスに分
割することに関連する。入力データは非同期で到来する
ため、通信マネージャ／事象検知部モジュールはそれ自
身で一つのプロセスを形成しなくてはならない。他の二
つのモジュールの場合、一つの事象の検出で活性化され
て、一つのプロセスを形成することができる。明白なが
ら、ある知識源の実行は一つの別個のプロセスを形成す
る。

【０２９６】制御モジュールの事象検知モジュールに
は、種々のソースから黒板に入力される全てのデータを
受信するデータ構造が含まれる。このデータ構造は、デ
ータを分析し、どの知識源に実行前提条件が適合してい
るかを判定するように調整されている。換言すれば、デ
ータ構造は、データに注目し、もし知識源があれば、ど
の知識源がそのデータに基づいて動作するかを判定す
る。データ構造によってインプリメントされるアルゴリ
ズムは、受信された特定のデータに基づいて動作する知
識源のみがそれを実行に使えるかどうかを調べるために
引続き点検されるように、受信されるがままにデータを
マッピングする。活性化／アジェンダ管理部は、予め定
められた知識源優先順位スキムに基づいてこの点検を行
う。従って、受信された特定のデータに基づいて動作す
る知識源のみが制御モジュールによって実行可能性を点
検されるため、かなりの時間が節減できる。この様にし
て、異なるデータポイントで動作する複数の知識源を持
つシステムにおいては、本発明のアルゴリズムにより時
間がかなり節減される。

【０２９７】ここで用いる「割り込み可能性／優先順位
スキム」は、知識源の実行に優先順位を与え、より優先
順位の低い知識源の実行を中断して、より優先順位の高
い知識源を割込み実行させる制御スキムが含まれる。

【０２９８】さらに、本発明の制御プロセス（事象検知
モジュールと活性化／アジェンダ管理モジュールを含
む）は、知識源割り込み可能性／優先順位スキムに基づ
いて知識源の動作を制御する。

【０２９９】実行前提条件を満たす優先順位のより高い
知識源を優先させるために、ある知識源の実行を中断す
ることができる。ある知識源の実行が中断され、優先順
位のより高い知識源が実行されると、その後に制御プロ
セスが中断された知識源の実行を再開するかどうかを判
定する。また、実行前提条件を満たす未実行の知識源は
優先順位に従って実行の待ち列に加わる。知識源割り込
み可能性／優先順位スキムはこの要領でインプリメント
される。

【０３００】さて本発明を限定された数の実施例につき
説明してきたが、当業者にとっては、付属の特許請求範
囲で定義するように、他の多数の実施例及び変更が本発
明の範囲に含まれることは明らかなはずである。

【０３０１】

【発明の効果】以上述べたように、本発明のソフトウェ
アシェルによれば、プラントの全体的構造の中で、かつ
多様なプラント環境の下で役に立つ十分に広範な機能的
モジュールを有する知識バースシステムを実現すること
ができる。

【０３０２】また、本発明によれば、診断情報を得るこ
とができると共にプラント運転を監視することのできる
ツールを生産するために、コンピュータのパワーとプラ
ントオペレーターの専門知識とを結合させることが可能
な知識ベースシステムが実現できる。

【図面の簡単な説明】

【図１】本発明の全システム環境のブロック線図であ
る。

【図２】図１の全システム環境のブロック線図の詳細を
示す図である。

【図３】黒板アーキテクチャのブロック線図である。

【図４】全システムのブロック線図である。

【図５】黒板データ構造のブロック線図である。

【図６】黒板用の値のタイプコードリストを示す説明図
である。

【図７】事象検知データ構造のブロック線図である。

【図８】事象検知ソフトウェアの論理表を表す説明図で
ある。

【図９】活性化／アジェンダマネージャ論理フローリス
トを表す説明図である。

【図１０】ルールネットワーク例の図である。

【図１１】ルールベースのノード構造図である。

【図１２】ルール構造図である。

【図１３】ルール構造図である。

【図１４】ルールベースの知識源論理フローリストを表
す説明図である。

【図１５】条件をルール信念と結合するための公式リス
トを表す説明図である。

【図１６】ケースベースの知識源データ構造図である。

【図１７】入力データ構造図である。

【図１８】ユーザインタフェイスソフトウェアの論理フ
ローリストを表わす説明図である。

【図１９】詳細システムのブロック線図である。

【図２０】データメッセージタイプコードリストを表す
説明図である。

【図２１】制御メッセージタイプコードリストを表す説
明図である。

【図２２】メッセージタイプコードリストを表す説明図
である。

【図２３】特定メッセージフォーマットリストを表す説
明図である。

【図２４】特定メッセージフォーマットリストを表す説
明図である。

【図２５】特定メッセージフォーマットリストを表す説
明図である。

【図２６】特定メッセージフォーマットリストを表す説
明図である。

【図２７】システムファイルフォーマットリストを表す
説明図である。

【図２８】黒板・構造記述子ファイルフォーマットリス
トを表す説明図である。

【図２９】ルールベースの記述子ファイルフォーマット
リストを表す説明図である。

【図３０】ルールベースの記述子ファイルフォーマット
リストを表す説明図である。

【図３１】ルールベースの記述子ファイルフォーマット
リストを表す説明図である。

【図３２】ケースベースの記述子ファイルフォーマット
リストを表す説明図である。

【図３３】ケースベースの記述子ファイルフォーマット
リストを表す説明図である。

【図３４】入力データファイルフォーマットリストを表
す説明図である。

【図３５】ログファイルフォーマットリストを表す説明
図である。

【図３６】診断ファイルフォーマットリストを表す説明
図である。

【図３７】黒板・ステータスファイルフォーマットリス
トを表す説明図である。

【図３８】黒板制御モジュールのブロック図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者ロバートダブリュートンプソンジュニアアメリカ合衆国ペンシルバニア州ピッツブルフ＃507 ペンセンターブールバード 800 (72)発明者内藤初彦神戸市兵庫区和田崎町１丁目１番２号三菱電機株式会社制御製作所内

Claims

【特許請求の範囲】

【請求項１】プラント運転シミュレーション用の人工
知能ソフトウェアシェルであって、プラントの構成要素
と概念を表すオブジェクトを有するデータベースを備え
た黒板モジュールと、人工知能動作スキムを含み、前記
黒板モジュールと交信しながら、予め定義済みの特定の
黒板オブジェクトに対して動作する少なくとも一つの知
識源モジュールと、前記黒板モジュールおよび少なくと
も一つの知識源モジュールと交信しながら、シェルに入
力されるデータをイネーブル化する入力データモジュー
ルと、前記黒板モジュールならびに少なくとも一つの前
記知識源モジュールと交信しながら、全ての入力データ
を受信し、予め定められた知識源の割り込み可能性／優
先順位スキムにしたがって、少なくとも一つの知識源の
動作を制御する制御モジュールと、を含むことを特徴と
する人工知能ソフトウェアシェル。
【請求項２】請求項１に記載のソフトウェアシェルで
あって、その中の前記制御モジュールが、前記入力デー
タモジュールと交信しながら、全ての入力データを受信
し、さらに少なくとも一つの知識源が実行を始めるべき
時点を判定する事象検知部モジュールと、少なくとも一
つの前記知識源モジュールならびに前記事象検知部モジ
ュールと交信しながら、予め定められた知識源の割り込
み可能性／優先順位スキムに従い、少なくとも一つの知
識源モジュール実行させる活性化／アジェンダ管理部モ
ジュールと、を含むことを特徴とするソフトウェアシェ
ル。
【請求項３】請求項１に記載のソフトウェアシェルで
あって、その中で少なくとも一つの前記知識源モジュー
ルが、信念のレベルを連想づけられている if-then-els
e 形式のルールを含む前向き連鎖信念伝播スキムを有す
るルールベース知識源モジュールと、予め定義されたパ
ターンと条件を含み、ただし格ベース知識源の実行後
に、受信したデータと前記パターンの間に或る一定のレ
ベルの近似度が見出される場合は、前記条件が真である
と推論されるデータ比較スキムを有する格ベース知識源
モジュールと、を含むことを特徴とするソフトウェアシ
ェル。
【請求項４】請求項２に記載のソフトウェアシェルで
あって、その中で少なくとも一つの前記知識源モジュー
ルが、信念のレベルが連想づけられている if-then-els
e 形式のルールを含む前向き連鎖信念伝播スキムを有す
るルールベース知識源モジュールと、予め定義されたパ
ターンと条件とを含み、格ベース知識源の実行後に、受
信したデータと前記パターンの間に或る一定レベルの類
似度が見出される場合は、前記条件が真であると推論さ
れるデータ比較スキムを有する格ベース知識源モジュー
ルと、を含むことを特徴とするソフトウェアシェル。
【請求項５】請求項４に記載のソフトウェアシェルで
あって、その中で少なくとも一つの知識源がさらに、シ
ミュレーション関係と推論関係を保ちながら相互に接続
されたモジュールを有するモデルベース知識源モジュー
ルを含むことを特徴とするソフトウェアシェル。
【請求項６】請求項４に記載のソフトウェアシェルで
あって、その中で前記モジュールの各々がソフトウェア
プロセスを含むことを特徴とするソフトウェアシェル。
【請求項７】請求項１に記載のソフトウェアシェルで
あって、その中で前記黒板モジュールのデータベースが
垂直階層接続と水平リンクを有するオブジェクトの階層
構造を含むことを特徴とするソフトウェアシェル。
【請求項８】請求項７に記載のソフトウェアシェルで
あって、その中で黒板のオブジェクトの各々が属性を有
し、しかも各属性が少なくとも１個の値と、一つのハッ
シュテーブルを含むデータベースと、前記オブジェクト
をそれらに対応する属性および値と結合するための複数
のポインターと、を有することを特徴とするソフトウェ
アシェル。
【請求項９】請求項４に記載のソフトウェアシェルで
あって、その中で前記黒板モジュールのデータベースが
垂直階層接続と水平リンクを有するオブジェクトの階層
構造を含むことを特徴とするソフトウェアシェル。
【請求項１０】請求項９に記載のソフトウェアシェル
であって、その中で黒板のオブジェクトの各々が属性を
有し、しかも各属性が少なくとも１個の値と、ハッシュ
テーブルを含むデータベースと、前記オブジェクトをそ
れらに対応する属性および値と結合するための複数のポ
インターと、を有することを特徴とするソフトウェアシ
ェル。
【請求項１１】請求項７に記載のソフトウェアシェル
であって、その中で前記垂直階層接続が IS-A 階層接続
と PART-OF 階層接続を含むことを特徴とするソフトウ
ェアシェル。
【請求項１２】請求項９に記載のソフトウェアシェル
であって、その中で前記垂直階層接続が IS-A 階層接続
と PART-OF 階層接続を含むことを特徴とするソフトウ
ェアシェル。
【請求項１３】請求項２に記載のソフトウェアシェル
であって、その中で前記活性化／アジェンダ管理部モジ
ュールが、前記知識源割り込み可能性／優先順位スキム
に従って、ある知識源の実行動作に割り込みを掛け、そ
の知識源より優先順位の高い知識源を実行させる機構、
を含むことを特徴とするソフトウェアシェル。
【請求項１４】請求項１３に記載のソフトウェアシェ
ルであって、その中で前記活性化／アジェンダ管理部モ
ジュールが、割り込みを掛けられた知識源の実行再開予
定を組むべきかどうかを判定するための機構を含むこと
を特徴とするソフトウェアシェル。
【請求項１５】請求項２に記載のソフトウェアシェル
であって、その中で前記事象検知器モジュールが、デー
タが受信された時、その受信されたデータに基づいて動
作する知識源だけが実行の機会の有無についての点検を
受けるように、一つのアルゴリズムをインプリメントさ
せるデータ構造、を含むことを特徴とするソフトウェア
シェル。
【請求項１６】請求項３に記載のソフトウェアシェル
であって、前記シェルがさらに、オブジェクト名称、お
よび各オブジェクトの属性と値の対を含む黒板構造記述
ファイルと、前記ルールベース知識源を形成するルール
ならびに前記ルールベース知識源実行のための前提条件
の記述を含むルールベース記述ファイルと、前記格ベー
ス知識源を形成する格ならびに前記格ベース知識源実行
のための前提条件の記述を含む格ベース記述ファイル
と、診断サイクル実行用の入力をシミュレートするデー
タの組とそれに対応する時間タグを持つ連鎖リストを有
する入力データファイルと、を含み、その中で前記黒板
構造記述ファイル、前記ルールベース記述ファイル、前
記格ベース記述ファイル、および前記入力ファイルがユ
ーザーによって作成されることを特徴とするソフトウェ
アシェル。
【請求項１７】請求項１６に記載のソフトウェアシェ
ルであって、前記シェルがさらに、各入力データファイ
ル作成サイクルが完了するたびに前記シェルによって作
成されると共に、前記ルールベース知識源によって作成
される診断内容と前記格ベース知識源によって見出され
た格整合とを有する診断内容ファイルと、前記シェルに
よって作成されると共に、各入力データファイル作成サ
イクルの完了後に何れかの知識源によって修正される黒
板情報を有する黒板状態ファイルと、を含むことを特徴
とするソフトウェアシェル。
【請求項１８】請求項１０に記載のソフトウェアシェ
ルであって、その中で前記事象検知器モジュールがさら
に、各入力データ源のエントリを有するハッシュテーブ
ルと、複数のオブジェクトのエントリ並びにそれらに対
応する属性と値のエントリ、および前記データポイント
構造内のエントリを指定する前記ハッシュテーブルのエ
ントリを有するデータポイント構造と、前記データポイ
ント構造によって指定される一つの間接表式リストと、
前記間接表式リストによって指定され、知識源の最近の
値と更新済みの値のエントリを含む前記間接表式リスト
によって指定される表式リストと、を含み、前記ハッシ
ュテーブルが連鎖アルゴリズムを用いながらインプリメ
ントされることを特徴とするソフトウェアシェル。
【請求項１９】請求項１８に記載のソフトウェアシェ
ルであって、その中で前記事象検知器モジュールがさら
に、入力データと関係があるメッセージを受信し、その
メッセージの構文エラーを点検し、構文エラーが見つか
らなければハッシュテーブルのアルゴリズムをインプリ
メントさせるメッセージ評価部、を含むことを特徴とす
るソフトウェアシェル。
【請求項２０】請求項１９に記載のソフトウェアシェ
ルであって、その中で前記活性化／アジェンダ管理部モ
ジュールがさらに、事象駆動型知識源活性化のための先
入れ先出し順列と、周期的知識源用の時間ベース順列
と、知識源の実行に関する前提条件を点検するための知
識源／前提条件表現構造と、を含むことを特徴とするソ
フトウェアシェル。
【請求項２１】請求項２０に記載のソフトウェアシェ
ルであって、その中で前記活性化／アジェンダ管理部モ
ジュールがさらに、複数のオブジェクトおよびそれらに
対応する属性と値を有する配列と、前記配列によって指
定される各知識源を有する表式リストと、を含むことを
特徴とするソフトウェアシェル。
【請求項２２】プラント運転シミュレーション用人工
知能ソフトウェアシェルであって、前記シェルが、プラ
ントの構成要素および概念を表すオブジェクトを記憶さ
せる手段と、人工知能動作スキムを含み、前記記憶手段
と交信しながら、予め定義済みの特定のオブジェクトに
対して動作する少なくとも一つの知識源モジュールと、
前記記憶手段および少なくとも一つの前記知識源モジュ
ールと交信しながら、前記シェルに入力されるデータを
イネーブル化するための手段と、前記イネーブル化手段
ならびに少なくとも一つの知識源モジュールと交信しな
がら、全ての入力データを受信し、予め定められた知識
源割り込み可能性／優先順位スキムに従って少なくとも
一つの知識源モジュールの動作を制御するための手段
と、を含むことを特徴とする人工知能ソフトウェアシェ
ル。
【請求項２３】請求項２２に記載のソフトウェアシェ
ルであって、その中で受信し、制御する手段が、前記イ
ネーブル化手段と交信し合いながら、少なくとも一つの
前記知識源モジュールを実行させるべき時点を判定する
ための手段と、少なくとも一つの知識源モジュールおよ
び前記判定手段と交信しながら、予め定められた知識源
割り込み可能性／優先順位スキムに従って少なくとも一
つの知識モジュールを実行させるための手段とを含むこ
とを特徴とするソフトウェアシェル。
【請求項２４】請求項２３に記載のソフトウェアシェ
ルであって、その中で少なくとも一つの知識源モジュー
ルが、信念のレベルが連想づけられているif then else
形式のルールを含む前向き連鎖信念伝播スキムを有す
るルールベース知識源モジュールと、予め定義されたパ
ターンと条件を含み、格ベース知識源の実行後に、受信
されたデータと前記パターンの間に或る一定のレベルの
近似度が見出される場合は、前記条件が真であると推論
するデータ比較スキムを有する格ベース知識源モジュー
ルと、を含むことを特徴とするソフトウェアシェル。
【請求項２５】請求項２４に記載のソフトウェアシェ
ルであって、その中で前記記憶手段が垂直階層接続と水
平リンク複数を持つオブジェクトの階層構造を有するデ
ータベースを含むことを特徴とするソフトウェアシェ
ル。
【請求項２６】請求項２５に記載のソフトウェアシェ
ルであって、その中で各オブジェクトが属性を有し、し
かも各属性が少なくとも１個の値と、ハッシュテーブル
を含むデータベースと、オブジェクトをそれに対応する
属性および値と結合するための複数のポイントと、を有
することを特徴とするソフトウェアシェル。
【請求項２７】請求項２６に記載のソフトウェアシェ
ルであって、その中で前記実行手段が、優先順位の低い
１個の知識源の実行動作に割り込みを掛けて、前記知識
源割り込み可能性／優先順位スキムに従ってその知識源
より優先順位の高い知識源を実行させる手段、を含むこ
とを特徴とするソフトウェアシェル。
【請求項２８】前記判定手段が入力データを受信する
手段と、知識源実行の前提条件が満たされた時点を判定
する手段と、実行の有効性に関する前記実行前提条件が
実行の有効性に満たされている知識源のみを点検する手
段と、を含んでいることを特徴とする請求項２７に記載
のソフトウェアシェル。
【請求項２９】請求項２８に記載のソフトウェアシェ
ルであって、前記シェルが更に、オブジェクト名称並び
に、各オブジェクトの属性／値の対を有する黒板構造記
述ファイルと、ルールベース知識源を形成するルールお
よびルールベース知識源用の実行前提条件の記述を含む
ルールベース記述ファイルと、格ベース知識源を形成す
る格並びに、格ベース知識源用の実行前提条件の記述を
含む格ベース記述ファイルと、診断サイクル実行用の入
力データをシミュレートするデータとそれに対応する時
間タグとの組が付いている連鎖リストを有する入力デー
タファイルと、を含み、その中で黒板構造記述ファイ
ル、ルールファイル、格ベース記述ファイル、および入
力データファイルがユーザーにより作成されることを特
徴とするソフトウェアシェル。
【請求項３０】ルールベース知識源により作成された
診断および格ベース知識源により検出された格整合を含
み、終了した各入力データファイルサイクル用にシェル
により作成された診断ファイルと、各入力データファイ
ルサイクルの終了後の知識源（種類を問わず）により修
正された黒板情報を含み、シェルにより作成された黒板
ステータスファイルと、を更に含むことを特徴とする請
求項２９に記載のソフトウェアシェル。
【請求項３１】相互交信用ストリームソケットをさら
に含み、前記ソケットが要求／応答の対の形式をとるメ
ッセージを交信することを特徴とする請求項３０に記載
のソフトウェアシェル。
【請求項３２】人工知能ソフトウェアシェルを用いて
プラント運転をシミュレートする方法であって、前記方
法が、データベースの中に、プラント構成要素と概念を
表すオブジェクトを格納するステップと、入力データ源
から入力データを読み取るステップと、読み取られた入
力データから、予め定められた知識源優先順位スキムに
基づいて人工知能知識源をいつ実行すべきかを判定する
ステップと、前記判定に基づき、特定のあらかじめ定義
されたオブジェクトに対し、知識源を実行するステップ
と、を含むことを特徴とする方法。
【請求項３３】知識源が実行するステップはオブジェ
クトの値の更新ステップを含んでいることを特徴とする
請求項３２に記載の方法。
【請求項３４】請求項３３に記載の方法であって、前
記の知識源を実行するステップが、信念レベルが連想づ
けられている if-then-else 形態のルールを含む前向き
連鎖信念伝播スキムを持つルールベース知識源を実行す
るステップと、あらかじめ定義されたパターンと条件を
含むデータ比較スキムを有する格ベース知識源を実行す
るステップと、を含むことを特徴とする方法。
【請求項３５】受信されたデータとパターンとの間に
一定レベルの類似度が見出される場合、格ベース知識源
の実行ステップが前記条件を真であると推論するステッ
プを含んでいることを特徴とする請求項３４に記載の方
法。
【請求項３６】前記格納ステップがオブジェクト、属
性及び値を格納するステップを含み、各オブジェクトが
属性を有し、且つ各属性が少なくも１個の値を有するこ
とを特徴とする請求項３５に記載の方法。
【請求項３７】知識源を実行する前記ステップが、知
識源の割込可能性／優先順位スキムに従って、優先度が
より低い知識源の実行動作に割込みをかけ、優先度がよ
り高い知識源を実行するステップを含んでいることを特
徴とする請求項３６に記載の方法。
【請求項３８】前記知識源実行ステップが、割込みス
テップ以後に、割込を受けた知識源の実行が再スケジュ
ールされるべきかどうかを判定するステップをさらに含
んでいることを特徴とする請求項３７に記載の方法。
【請求項３９】前記知識源実行ステップが、割込をう
けた知識源が実行のために再スケジュールされるべきか
どうかを判定した後、その判定に基づきその知識源のス
ケジュールを行うステップをさらに含んでいることを特
徴とする請求項３８に記載の方法。
【請求項４０】前記判定ステップが、知識源実行の前
提条件が満たされる時点を判定するステップと、実行可
能性に関する実行の前提条件が満たされている知識源の
みを点検するステップとを含んでいることを特徴とする
請求項３３に記載の方法。
【請求項４１】前記判定ステップが、知識源実行の前
提条件が満たされる時点を判定するステップと、実行可
能性に関する実行の前提条件が満たされている知識源の
みを点検するステップを含んでいることを特徴とする請
求項３９に記載の方法。
【請求項４２】請求項４０に記載の方法であって、各
オブジェクトのオブジェクト名称と属性／値の対を有す
る黒板構造記述ファイルを生成するステップと、ルール
ベース知識源と実行前提条件とを形成するルールを有す
るルールベース記述ファイルを生成するステップと、格
と実行前提条件の記述とを含む格ベース記述ファイルを
生成するステップと、診断サイクルを実行するための入
力データをシミュレートするデータと対応時間のタグの
セットを備える連鎖リストを有する入力データファイル
を生成するステップと、を含むことを特徴とする方法。
【請求項４３】請求項４２に記載の方法であって、ル
ールベース知識源により行われた診断および格ベース知
識源により見出された格整合を有する診断ファイルを生
成するステップと、実行中の知識源により修正された黒
板情報を有する黒板ステータスファイルを生成するステ
ップと、を含むことを特徴とする方法。
【請求項４４】要求／応答の対形式のモジュール間の
ソケットを通じたメッセージ伝達ステップをさらに含む
ことを特徴とする請求項33に記載の方法。
【請求項４５】知識源実行ステップが更に、シミュレ
ーション関係と推論関係とを備えた相互接続されたモジ
ュールを有するモデルベース知識源の実行ステップを含
んでいることを特徴とする請求項３３に記載の方法。
【請求項４６】プラント運転シミュレーション用の人
工知能ソフトウェアシェルのための制御モジュールであ
って、前記シェルがプラントの構成要素および概念を表
すオブジェクトを持つ黒板モジュールデータベースを含
み、および少くとも一つの知識源モジュールが黒板オブ
ジェクト実行用の人工知能動作スキムを含み、前記制御
モジュールが、黒板モジュールと交信しながら、全ての
入力データを受信し、少くとも一つの知識源モジュール
がいつ実行されるべきかを判定する事象検知モジュール
と、少くとも一つの知識源モジュールおよび事象検知モ
ジュールと交信しながら、あらかじめ定められた知識源
割込可能性／優先順位スキムに基づき少くとも一つの知
識源モジュールを実行する活性化／アジェンダ管理モジ
ュールと、を含むことを特徴とする制御モジュール。