JPH06214615A - 人工知能ソフトウェアシェルのためのケースベース知識源 - Google Patents

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 の特徴を使用して、
マン−マシンウィンドウ内に表示させることができる。
すべての出力ファイルは、エラーを発見するのを助ける
ために使用することができる。

【０２５８】知識源 知識源とは、黒板構造におけるドメイン知識の実際の保
管場所である。この節では、知識源の一般的な特性をい
くつか詳細に説明し、その後知識源の三つの異なるクラ
スをある程度詳細に検証する。最初のクラスにおいて
は、ルールベースの二つの異なる知識源使用法を説明す
るが、そこで本質的に二つのタイプのルールベース知識
源が提示される。それぞれルールベースとモデルベース
の他の二つのクラスにおいては、各々一つのタイプを説
明する。知識源が制御モジュールおよびブラックボード
それ自身を用いて相互作用の要求事項を満足する限り、
任意のクラスに対してさらに多くのクラスおよびさらに
多くのタイプを付加することができる。

【０２５９】一般的特性 最も一般的にいって、ある知識源はある非常に大きなル
ール、ＩＦ（前提条件（ＴＨＥＮ（知識源の本体を実行
する））とみなすことができる。

【０２６０】したがって、実行に際しては、先ずある知
識源が一組の前提条件を満たさなければならない。これ
らの前提条件は先験的に定義されなければならない。多
くの代表的な黒板アプリケーションにおいて、各制御サ
イクルは、各知識源の前提条件をチェックすることから
始まる。これは非常に非効率的なアプローチである。わ
れわれのドメインシェルは厳格に事象（イベント）駆動
型のそれであるため、さらにもう一つの前もって必要な
条件を先験的に定義しておかなければならない。すなわ
ち、前提条件のチェックを開始させる事象のリストであ
る。

【０２６１】知識源の規模は、強制されるものではな
い。本明細書のはじめに言及した通り、非常に小規模の
知識源は非常に高速で実行されるが、制御オーバーヘッ
ド対実行時比が低下してしまう。大規模の知識源ではこ
の比は改善されるが、応答特性の悪化を招く。大きな規
模を排除することはできないため、知識源はさらに割り
込み可能および再開可能と特徴づけられるものでなけれ
ばならない。割り込み可能な知識源は、割り込みが行わ
れるために発生していなければならない条件、および再
開されるための条件をアジェンダマネージャに分かるよ
うにするものでなければならない。いずれの作用も、し
たがって、タスク優先度あるいはコンテキスト変更で連
想づけることができる。

【０２６２】知識源は“世界”の状態を推論するもので
あり、その状態は黒板のグローバルなデータ構造によっ
て表される。したがって、あらゆる知識源は黒板上の任
意のデータへの直接アクセスを有している。すべての知
識源はまた、黒板への書き込みアクセスをも有してい
る。しかしながら書き込みアクセスは間接的なものであ
り、制御モジュールの通信マネージャ／事象検知部によ
って行われる。これは標準的な黒板アーキテクチャの必
要な改変であって、ドメインの性質によって生じる。す
なわち、一つの知識源は他の知識源に対して事象を引き
起こす前提を生じさせることがある。知識源はそれぞれ
独立したものであるため、これらの状況を仲介するため
には手形交換所が必要である。

【０２６３】さらに、知識源は拮抗する仮説を発生させ
るため、互いに打ち消し合うものとなってはならない。
したがって、仮説源が記録され、さらにそれらの仮説に
ついての推論をさらに他の知識源によって実行できるよ
うに黒板の開発には注意を払う必要がある。各知識源
は、逆に、次の繰り返しにおける継続性を与えるために
必要な“世界”の状態の一部のそれ自身のコピーを維持
しなければならないこともある。

【０２６４】一般的な基本的考え方として、知識源は、
単一レベルの抽出（すなわち、ＨＡＳ−ＰＡＲＴ階層に
おける垂直交差は存在しない）において、かつその階層
の推論可能なサイズの一片の水平構成階層において推論
しなければならないであろう。一方、それを他の方法で
行うことを排除する何物もあってはならないであろう。

【０２６５】ケースベース ケースベース推論は人間認識に関する理論によって立派
に一人立ちした人工知能（ＡＩ）の研究分野である。こ
れは、記憶，学習，計画及び問題解決に関する問題を扱
う。ケースベース推論の実用上の目的は、ケースベース
推論システム開発に当たって様々な試みから判るよう
に、事象の自動解釈と自動学習である。このアプローチ
は図３８のフローチャートに図示されている。極めて簡
単に言えば、次の全てのステップが必要である。

【０２６６】ケースベース推論のインプリメンテーショ
ン １ 新事象の特徴が特性インデックスとして割り当てら
れる。

【０２６７】２ 特性インデックスは、類似した過去の
ケースを検索するとき使用される。

【０２６８】３ 古いケースは新事象とより良く適合す
るように修正される。

【０２６９】４ 新しいケースがテストされる。

【０２７０】５ テストが成功の場合、特性インデック
スが割り当てられ、新しいケースはメモリに追加され
る。

【０２７１】６ テストが失敗の場合、失敗が宣言され
て、新しいケースが修復され、テストが再開される。

【０２７２】図３８に示すように、このようなインプリ
メンテーションには、次の５種類の知識が必要となる。
即ちインデックス規則、類似性測定値、修正規則、修復
規則、ケースメモリそれ自身である。

【０２７３】本発明において、自動修正（モディフィケ
イション）および修復（リペア）は設けられていない。
これは、これらについてまだ十分な開発が行われていな
いかその代わりとし、単純な直線（straightfoward）ア
プローチが使われるだろう。このアプローチでは、修正
と修復はシステムユーザの責任とされている。インデッ
クス付けもまた一部はシステムユーザの責任であり、イ
ンデックス付けでは、ケースの定義付けにケースを構成
する変数（特徴）の定義が必要となる。このようにし
て、本発明はユニークでより単純なケースベース理由付
け（リーズニング：ｒｅａｓｏｎｉｎｇ）手法を提供す
る。

【０２７４】ケースベース知識源の本体は、前もって蓄
積されたケース（知識ベース）の集合及び与えられた状
況（推論機構）において、“近似度”によってランク付
けすることができるアルゴリズムの集合である。

【０２７５】知識源のそれぞれのケースは、アプリケー
ション開発者によって定義された汎用ケースフレームの
インスタンシェイトである。ケースフレームは変数をい
くつでも持つことが出来る。インスタンス（ケース）は
変数に値を割り当てることによって得られる。一方、知
識源のなかでは、全てのケースは同一フレームのインス
タンスとして定義されるので、表形式の蓄積方法は、ケ
ースメモリを選択するとき有効となる。加えて、時間の
概念が表現されなければならない。表を使用する本発明
の手法は、図３９に示すように、表（ロー）の各行が１
つのケースフレームに対応している。列（カラム）はケ
ースを形成する値を持つ変数に対応している。すべての
変数は第３のディメンジョン、すなわち時間を持つ。ケ
ースの歴史的（ヒストリカル）値は、このディメンジョ
ンに沿って蓄積される。これらの値は、類似度計測アル
ゴリズムによって現在の歴史的値に合致（マッチ）され
る。もし、変数が第３のディメンジョンを持たない場合
は、変数の現在の値に対する類似度が計測され他と推測
され、歴史は保持されない。

【０２７６】この情報に加えて、それぞれの変数var
が、関数f とこれに付随した重みw を持つ事が図３９に
示されている。類似性測定（照合）アルゴリズムは、類
似値を次のように計算する。

【０２７７】 類似値（Simularity Value) ＝ F(wi,f(vari(t))) マッチング関数F 及びf は、原則として、様々に重み付
けられた“曖昧な”及び厳密な動作（即ち、比較）、ま
たは、これら療法の実行のために使用される。マッチン
グ方式の考えは、パターン認識、ファジー論理、また
は、特別な場合（ad-hoc）に見出すことが出来る。この
ような関数ライブラリは用意されているが、その他の関
数はユーザ自身が追加しなければならない。

【０２７８】通常、新しいケースの蓄積は自動的または
エンドユーザのコントロールによって行なわれている。
ある応用例では、もし新しいケースの重要性（interest
ingness ）、有効性（utility ）を測定するアルゴリズ
ムが簡単に定義できるならば、自動アプローチが出来る
と考えられている。ユーティリティはケースが使用され
た回数等を調べて、最も使用されなかったケース−この
ケースは、あらかじめ決められたメモリの制限を超えた
ら新しいケースに置き換えられる−を決めるのに使うこ
とができる。

【０２７９】ケースベース 一組のケースの関連パラメータ値の格納用表形式が開発
されるであろう。その形式によって、妥当な大きさのケ
ース用メモリをリアルタイムに動作させるために充分な
速度が得られるであろう。類似度は手続きに従って算出
されるであろう。個別データ用スロットは、リアルタイ
ム機能を表すために限定的な時間依存性を持つ。

【０２８０】図３９は知識源のケース用メモリの説明図
を示す。複数個の変数variで構成されるケース毎に、類
似度測定対策が算出される。プロトタイプでは四個の関
数ｆが与えられるが、それらは等値、比較小、比較大、
曲線上の対応点である。この最後の関数は、図４０に示
すように、時間曲線上の選択点を現在の履歴点とマッチ
させる機能を発揮する。

【０２８１】本発明のケースベースアプローチは、次の
考え方に基づくものである。すなわち、或る過去の格が
複数の時点に関する１個のパターンと、それらの過去の
時点を用いて得られた１個の最終結果を含む場合であっ
て、しかもそのパターン、または時間と大きさの点でそ
れと類似したパターンと再度遭遇することがあれば、そ
の同一の結果は真であると推論されるという考え方であ
る。先行技術では、大きさをスコアする方式だけが使用
されたが、その中で、類似度の比較結果は、大きさの尺
度だけで判定され、時間の尺度で判定されることはなか
った。本発明によって、類似度の比較結果を、大きさの
尺度だけではなく時間の尺度でも判定する方式が得られ
る。その方式を以下に説明する。

【０２８２】ケースベース内の一つのケースの部分とし
て具体的に示された数値データの各値は、それで連想づ
けられる追加情報を有する。その情報によって、前記ケ
ースをスコアする際に前記データ値がどのように使われ
るかが明らかにされる。各データ値は、それぞれ黒板内
の特定オブジェクト／属性で連想づけられる。それによ
って、前記ケースベーススコア部は、前記黒板のどこか
ら前記データを取り出すべきかを知らされる。１個のス
コア関数（ＦＥＱ、ＦＬＴ、またはＦＧＴ）が、前記ケ
ースベーススコア部に、どのようにしてライブデータを
前記データ値と比較すれば良いかを知らせる。ライブデ
ータとは、動作時に前記ケースベースがファイヤー（ｆ
ｉｒｅｄ）される際に、前記黒板から取り出されるデー
タのことである。デルタ−タイムズが指定されている場
合は、単一のオブジェクト／属性で２個以上のデータ値
が連想づけられる場合があることに留意されたい。デル
タ−タイムズは、前記数値データ値を黒板内に記憶させ
てある最新値と比較せず、一つの古い値と比較するよう
に指定する。単一のオブジェクト／属性で複数の数値デ
ータ値が連想づけられている場合は、最初の１個を除い
た各数値データがそれぞれ一つのデルタ−タイムを指定
しなければならない。それによって、前記スコア部は、
前記ライフデータのセット中の最新の値から何秒分遡っ
て探せば、その特定の数値データ値をスコアするための
使用値が見つかるか、ということを知らされる。

【０２８３】時間−大きさ型スコア法の特徴を説明する
前に、ドメインシェル内のタイムスタンプの使用につい
て説明しなければならないが、それはタイムスタンプの
使用がケースベーススコアに関連しているからである。
前記黒板内の各データポイントは、１個のタイムスタン
プを有し、前記データ値が測定された時間、または記録
された時間を示すものである。前記ケースベース知識源
は、このタイムスタンプを使用して、前記ケース内の所
定ポイントを比較するために、前記黒板から取り出され
た値のセット中の、どの値を用いるかを判定する。タイ
ムスタンプは、一つの特定オブジェクト／属性に対する
複数の値が前記ケースの部分である（デルタ−タイムズ
が指定されている）場合に限って、意味を持つ。一つの
特定オブジェクト／属性に対して数値データが１個だけ
しか指定されていない場合は、黒板内に記憶させてある
最新の値が、自動的にスコアに使用される。

【０２８４】ライブデータセットのいずれのポイントに
ついても、そのセットの最新値のタイムスタンプとその
ポイント自体のタイムスタンプとの間の経過時間の差
が、デルタータイムの決定に使用される。例えば、次の
ように想定して貰いたい、特定オブジェクト／属性に対
して、最新値のタイムスタンプが1992NOV1110:0030であ
り、それより古い一つのデータ値のタイムスタンプが19
92NOV1109:58:30 であるとする。この場合、対応するデ
ルタ−タイムは１２０秒である。

【０２８５】アプリケーション開発者は、一つの特定オ
ブジェクト／属性に対する値（複数）の履歴が黒板内に
保有されるように、指定することができる。１個のケー
スベースが一つの特定オブジェクト／属性に対して複数
のデルタ−タイムを使用する場合には、前記黒板は受け
取る値について、少なくともその長さに相当する履歴を
記憶していなければならない、そうしなければケースの
スコアを行うことができな。例えば、１個のケースベー
ス内の一つの特定値に対して最長デルタ−タイム１００
０秒が指定されている場合は、充分な量のデータを保有
するための黒板の履歴長は少なくとも１０００秒なけれ
ばならない。たとえその長さがあるとしても、スコアが
行えるのは次の場合に限られる、すなわち前記ケースベ
ースが始動された時、そのオブジェクト／属性に関し
て、前記黒板内に少なくとも１０００秒相当分のデータ
が記憶されている場合である。

【０２８６】大きさスコア法を使用する場合、一つのラ
イブデータオブジェクト／属性値は、その値のタイムス
タンプによって示される時間から、前記黒板に記憶され
ている、その次の新しい値のタイムスタンプによって示
される時間まで有効であると仮定される。それ故、ケー
スに対して大きさスコア法を使用する時、黒板で受信さ
れたデータであって、最新のタイムスタンプを起点とし
て比較的小さなデルタ−タイム期間に対応するタイムス
タンプを持つものは、たとえそのライブデータ値が時間
軸上で、実際に使用されたライブデータ値より、前記ケ
ースベース値にずっと近くても、スコアに使用されるこ
とはない。次に示すものは一つの数値例である。６０秒
というデルタ−タイムを持つケースデータポイントを考
えて貰いたい。黒板は、その最新値のタイムスタンプの
１０００秒前のタイムスタンプを持つデータポイント、
および最新タイムスタンプの５９秒前のタイムスタンプ
持つデータポイント含んでいると仮定する。最後に述べ
たポイントは、指定されたデルタ−タイムと１秒しか違
わないけれども、それよりずっと古い１０００秒前の値
がスコアに用いられる。

【０２８７】時間−大きさスコア法が使用されるとき
は、ケースベース内で一つのケースの内部の各数値デー
タ値ごとに、二つの時間間隔が指定される。それらの時
間間隔によって、各目的デルタ−タイムの前後の時間幅
が決まるが、その範囲内で前記ケースベーススコア部
が、黒板から取り出されたライブデータの中のデータ値
を探すことになる。換言すれば、各ポイントごとにデル
タ−タイム値の周りに１個のタイムウインドウが作られ
る。ライブデータが調べられる時、三つの可能性が存在
する。

【０２８８】１．タイムウインドウ内に値が見つからな
かった。この場合は、スコア部が、比較のために使用す
るライブデータ値を得るために、時間的にさらに遡るこ
とになる。換言すれば、その特定数値データ値に対する
スコアは、大きさスコア法の場合と同様に行われること
になる。

【０２８９】２．前記タイムウインドウ内部で１個の値
が見つかった。この場合は、その値が比較のために使用
される。

【０２９０】３．タイムウインドウの内部に複数の値が
ある。比較のために使用されるライブデータ値は、その
数値データで連想づけられるスコア法の種類によって決
まる。ＦＥＱスコア法の場合は、そのタイムウインドウ
内のライブデータ値であって、大きさが当該ケースの数
値データ値に最も近いものが使用される。ＦＬＴスコア
法の場合は、タイムウインドウ内で最小のライブデータ
値が使用される。ＦＧＴスコア法の場合は、タイムウイ
ンドウ内で最大のライブデータ値が使用される。それら
３種類のスコア法（ＦＥＱ、ＦＬＴ、およびＦＧＴ）の
各々に対して、これが楽観的または最良ケースのデータ
ポイント選択法になる。代案になる一つの選択モードを
使用することができる。それは、悲観的または最悪ケー
スの選択法である。ＦＥＱのスコア法の場合は、それ
は、タイムウインドウ内のライブデータ値であって、大
きさが当該ケースの数値データ値と最も大きく違うもの
が使用される。ＦＬＴスコア法の場合は、タイムウイン
ドウ内で最大のライブデータ値が使用される。ＦＧＴス
コア法の場合は、タイムウインドウ内で最小のライブデ
ータ値が使用される。

【０２９１】一旦ライブデータから適切なデータ値が選
ばれた後は、大きさスコア法の場合と同じ方法でスコア
が進められる。

【０２９２】時間−大きさスコア法は、データの到来時
間がはっきりしない場合に、ケースベースのスコアに役
立つ、なぜなら、それによって開発者が、スコア部に対
して名目的デルタータイムの周りの展望をどの程度に対
称的にするべきかを、教えることが可能になるからであ
る。大きさスコア法の場合は、その展望は固定され、非
対称的である、なぜなら開発者はそれを変えることがで
きないし、しかもその方法では、同じ時間かあるいは指
定されたデルタ−タイムより古い時間を持つデータだけ
を調べるからである。

【０２９３】時間−大きさスコア法は、ケースベースス
コア部が、ケースデータ値に近いライブデータ値のセッ
トの中から比較用の最良値を選べるようにするためにも
役立つ。それによって、大量のデータを用いるアプリケ
ーションのケース整合能力が高められる。大きさスコア
法の場合は、同じ時間か、あるいはデルタ−タイムより
僅かに古い時間を持ち、大きさが最も近い単一値だけが
使用される。しかし、各データポイントのタイムウイン
ドウを広くとり過ぎた場合は、動作時の性能が損なわれ
る、なぜならスコア部が各数値データ値を用いてスコア
するために、高い可能性を持つ候補として多数のポイン
トを検討しなければならなくなるからである。

【０２９４】時間−大きさスコア法のもう一つの特徴
は、各数値データポイントに、種々のタイムウインドウ
を連想づけることが可能な点である。それによって、特
定のドメイン内部の性能向上を達成するためのケース整
合アルゴリズムの微調整が可能になる。

【０２９５】ここでは、本発明の限られた数の実施例を
説明してきたが、ここに至れば、添付する特許請求範囲
によって定義される本発明の範囲に含まれるものが、本
発明の実施例または修正例として他にも数多く考えられ
ることは、当業者にとって明白なはずである。

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図３８】ケースベース推論・プロセスのフローチャー
トである。

【図３９】ケースベースの診断表を表す説明図である。

【図４０】モデルベース推論の単純例の図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ロバート ダブリュー トンプソン ジュ ニア アメリカ合衆国 ペンシルバニア州 ピッ ツブルフ ＃507 ペン センター ブー ルバード 800 (72)発明者 ダグラス エイ バウマン アメリカ合衆国 ペンシルバニア州 アポ ロ ズーバルロード 809

Claims (45)

【特許請求の範囲】
1. 【請求項１】 プラント運転シミュレーション用の人工
   知能ソフトウェアシェルであって、工場の構成要素と概
   念とを表すオブジェクトを持つデータベースを備えた黒
   板モジュールと、黒板モジュールとコミュニケーション
   して、予め特定された黒板対象上で動作する時間強度を
   計る人工知能動作スキムを含むケースベース知識モジュ
   ールと、黒板モジュールおよび少なくとも１つの知識源
   モジュールとコミュニケーションして、シェルにデータ
   のインプットを許可する入力データモジュールと、前記
   黒板モジュールならびに少なくとも一つの知識源と交信
   しながら、入力データを受信し、少なくとも一つの知識
   源の動作を制御する制御モジュールと、を含むことを特
   徴とするプラント運転のための人工知能ソフトウェアシ
   ェル。
2. 【請求項２】 請求項１に記載のソフトウェアシェルで
   あって、前記制御モジュールが、前記ユーザーインター
   フェイスモジュールと交信しながら、すべての入力デー
   タを受信すると共にケースベース知識源モジュールの動
   作時期を決定する事象検知部モジュールと、少なくとも
   一つの知識源モジュールならびに前記事象検知部モジュ
   ールと交信しながら、予め定められた知識源優先スキム
   に従い、知識源モジュールを実行させる活性化／アジェ
   ンダマネージャモジュールと、を含むことを特徴とする
   ソフトウェアシェル。
3. 【請求項３】 請求項２に記載のソフトウェアシェルで
   あって、信念のレベルについてのイフゼン形式のルール
   を含む前方連鎖信念伝搬スキムを持つルールベース知識
   源モジュールをさらに有することを特徴とするソフトウ
   ェアシェル。
4. 【請求項４】 請求項２に記載のソフトウェアシェルで
   あって、ケースベース知識源モジュールは、ケースベー
   ス知識源がその上で実行する予め定められたパターンお
   よび条件含むスキムであって、この条件は受信データお
   よびパターンに所定レベル以上の近似性がある場合に真
   と推定されるデータ比較スキムをさらに含むことを特徴
   とするソフトウェアシェル
5. 【請求項５】 請求項３に記載のソフトウェアシェルで
   あって、ケースベース知識源モジュールは、ケースベー
   ス知識源がその上で実行する予め定められたパターンお
   よび条件含むスキムであって、この条件は受信データお
   よびパターンに所定レベル以上の近似性がある場合に真
   と推定されるデータ比較スキムをさらに含むことを特徴
   とするスフトウェアシェル。
6. 【請求項６】 請求項２または３に記載のソフトウェア
   シェルであって、 上記データ比較スキムは、ケースベース知識源でのデー
   タの強度およびタイミングの両方を比較することを特徴
   とするソフトウェアシェル。
7. 【請求項７】 請求項６に記載のソフトウェアシェルで
   あって、その中で前記黒板モジュールのデータベース
   が、垂直階層間接続群と水平リンク群を持つオブジェク
   ト階層構造を一つ含むことを特徴とする前記ソフトウェ
   アシェル。
8. 【請求項８】 請求項７に記載のソフトウェアシェルで
   あって、その中で黒板のオブジェクトの各々が属性を持
   ち、しかも各属性が少なくとも一つの値と、ハッシュテ
   ーブルを含むデータベースと、前記オブジェクトをそれ
   らに対応する属性及び値と結合するための複数のポイン
   タと、を有することを特徴とする前記ソフトウェアシェ
   ル。
9. 【請求項９】 請求項４に記載のソフトウェアシェルで
   あって、その中で黒板モジュールのデータベースが、垂
   直階層間接続群と水平リンク群を持つオブジェクトの階
   層構造を含むことを特徴とする前記ソフトウェアシェ
   ル。
10. 【請求項１０】 請求項９に記載のソフトウェアシェル
    であって、その中で黒板オブジェクトの各々が属性を持
    ち、しかも各属性が、少なくとも一つの値と、ハッシュ
    テーブルを含むデータベースと、前記オブジェクトをそ
    れらに対応する属性、及び値と結合するための複数のポ
    インタと、を有することを特徴とする前記ソフトウェア
    シェル。
11. 【請求項１１】 請求項７に記載のソフトウェアシェル
    であって、その中で前記垂直階層間接続がIS-A階層間接
    続とPART-OF 階層間接続を含むことを特徴とする前記ソ
    フトウェアシェル。
12. 【請求項１２】 請求項９に記載のソフトウェアシェル
    であって、その中で前記垂直階層間接続がIS-A階層間接
    続とPART-OF 階層間接続を含むことを特徴とする前記ソ
    フトウェアシェル。
13. 【請求項１３】 請求項２に記載されたソフトウェアシ
    ェルであって、その中で前記活性化／アジェンダマネー
    ジャモジュールが知識源の実行動作に割り込みをかけ
    て、前記知識源優先スキムに従いその知識源より優先順
    位の高い知識源を実行させる機構を含むことを特徴とす
    る前記ソフトウェアシェル。
14. 【請求項１４】 請求項１３に記載のソフトウェアシェ
    ルであって、その中で前記活性化アジェンダマネージャ
    モジュールが割り込みをかけられた知識源の実行を再開
    させるべきかどうかを判定するための機構を含むことを
    特徴とする前記ソフトウェアシェル。
15. 【請求項１５】 請求項２に記載のソフトウェアシェル
    であって、その中で前記事象検知部モジュールがデータ
    が受信されたとき、受信データ上で動作する知識源が実
    行可能かどうかだけがチェックされるようなアルゴリズ
    ムを有するデータ構造を含むことを特徴とする前記ソフ
    トウェアシェル。
16. 【請求項１６】 請求項３に記載のソフトウェアシェル
    であって、さらに、オブジェクトの名称及びオブジェク
    トの属性／値の対を含む黒板構造記述ファイルと、前記
    ルールベース知識源を形成するルールならびに前記ルー
    ルベース知識源実行のための前提条件の記述を含むルー
    ルベース記述ファイル、前記ケースベース知識源を形成
    するケースならびに前記ケースベース知識源実行のため
    の前提条件の記述を含むケースベース記述ファイルと、
    連続的診断サイクルの入力データをシミュレートするデ
    ータの複数の組とそれに対応する時間の表示記号を持つ
    リンクされたリストを含む入力データファイルと、を含
    み、 その中で前記黒板構造記述ファイル、前記ルールベース
    記述ファイル、ケースベース記述ファイル及び前記入力
    データファイルはユーザによって作成されることを特徴
    とする前記ソフトウェアシェル。
17. 【請求項１７】 請求項１６に記載のソフトウェアシェ
    ルであって、さらに、各入力データファイルサイクルが
    完了するたびに前記シェルによって作成される診断ファ
    イルであって、前記ルールベース知識源によって作られ
    る診断内容と、前記ケースベース知識源によって見出さ
    れたケースの整合を含む診断ファイルと、前記シェルに
    よって作成される黒板状態ファイルであって、各入力デ
    ータファイルサイクルの完了後に、何らかの知識源によ
    って修正される黒板情報を含む黒板状態ファイルと、を
    有することを特徴とする前記ソフトウェアシェル。
18. 【請求項１８】 請求項４に記載のソフトウェアシェル
    であって、ケースベース知識源モジュールは、すでに出
    たデータを含む記憶ケースと、記憶ケース中のデータと
    の近似性によって現在のデータのランク付けを行う近似
    機能と、をさらに含むことを特徴とするソフトウェアシ
    ェル。
19. 【請求項１９】 請求項１８に記載のソフトウェアシェ
    ルであって、ケースベース知識源は、列および行を有す
    るテーブルと、テーブルの行中に記憶され、少なくとも
    １つの変数を含む複数のケースフレームと、テーブルの
    列中に記憶され、少なくとも１つの変数を含む複数のケ
    ースと、 をさらに含むことを特徴とするソフトウェアシェル。
20. 【請求項２０】 請求項１９に記載のソフトウェアシェ
    ルであって、ケースベース知識源モジュールは、各変数
    に関連付けられ、テーブル中に記憶された時間値をさら
    に含むことを特徴とするソフトウェアシェル。
21. 【請求項２１】 請求項２０に記載のソフトウェアシェ
    ルであって、時間−強度スコアリングスキムは、予め特
    定されたデータ比較が行われる時間のウィンドウを含む
    ことを特徴とする前記ソフトウェアシェル。
22. 【請求項２２】 プラント運転シミュレーション用の人
    工知能ソフトウェアのシェルであって、プラントの構成
    要素と概念を表すオブジェクトを記憶させる手段と、記
    憶手段と交信して、特定の予め定められたオブジェクト
    上で動作する時間強度スコアリング人工知能動作スキム
    と、記憶手段およびケースベース知識源モジュールと交
    信してデータをシェルに入力可能とするイネーブル手段
    と、上記イネーブル手段およびケースベース知識源モジ
    ュールと交信してすべての入力データを受信すると共に
    ケースベース知識源モジュールの動作を制御する手段
    と、を含むことを特徴とする人工知能ソフトウェアシェ
    ル。
23. 【請求項２３】 請求項２２に記載されたソフトウェア
    シェルであって、その中でデータを受信して制御する手
    段が、イネーブル手段と交信しながら、少なくとも一つ
    の知識源モジュールを実行させるべき時期を判定するた
    めの手段と、少なくとも一つの知識源モジュール及び前
    記判定手段と交信しながら、予め定められた知識源の優
    先スキムに従い、少なくとも一つの知識源を実行させる
    ための手段と、を有することを特徴とする前記ソフトウ
    ェアシェル。
24. 【請求項２４】 請求項２３に記載のソフトウェアシェ
    ルであって、その中で少なくとも一つの知識源モジュー
    ルが、連想づけられた信念のレベルを用いたif then el
    se形式のルールを含む前向き連鎖信念伝播スキムを持つ
    ルールベース知識源モジュールを含むことを特徴とする
    ソフトウェアシェル。
25. 【請求項２５】 請求項２４に記載のソフトウェアシェ
    ルであって、前記記憶手段が垂直階層間接続群と水平リ
    ンク群とを持つオブジェクトの階層構造を備えるデータ
    ベースを含むことを特徴とする前記ソフトウェアシェ
    ル。
26. 【請求項２６】 請求項２５に記載のソフトウェアシェ
    ルであって、各オブジェクトは属性を持ち、しかも各属
    性が少なくとも一つの値と、ハッシュテーブルを含むデ
    ータベースと、前記オブジェクトをそれらに対応する属
    性及び値と結合するための複数のポインタと、を有する
    ことを特徴とする前記ソフトウェアシェル。
27. 【請求項２７】 請求項２６に記載のソフトウェアシェ
    ルであって、知識源優先度スキムにしたがって、低い優
    先度の知識源の実行を中断し、高い優先度の知識源の実
    行する実行手段を含むことを特徴とするソフトウェアシ
    ェル。
28. 【請求項２８】 請求項２７に記載のソフトウェアシェ
    ルであって、 決定手段は、入力データを受信し、何時知識源実行プレ
    コンディションが合致するかを検出し、単に知識源の実
    行プリコンディションが実行可能性に合致するかをチェ
    ックする手段を含むことを特徴とするソフトウェアシェ
    ル。
29. 【請求項２９】 請求項２８に記載のソフトウェアシェ
    ルであって、さらに、オブジェクトの名称及びオブジェ
    クトの属性／値の対を含む、黒板構造記述ファイルと、
    前記ルールベース知識源を形成するルールならびに前記
    ルールベース知識源実行のための前提条件の記述を含む
    ルールベース記述用ファイルと、前記ケースベース知識
    源を形成するケースならびに前記ケースベース知識源実
    行のための前提条件の記述を含む、一つのケースベース
    記述用ファイルと、実行時診断サイクルの入力データを
    シミュレートするデータの複数の組とそれに対応する時
    間の常時記号を持つリンクされたリストを含む入力デー
    タファイルと、を含み、ただしその中で前記黒板構造記
    述ファイル、前記ルールベース記述ファイル及び前記入
    力データファイルはユーザーによって作成されることを
    特徴とする前記ソフトウェアシェル。
30. 【請求項３０】 請求項２９に記載のソフトウェアシェ
    ルであって、さらに、各入力データファイル作成サイク
    ルが完了するたびに前記シェルによって作成される診断
    ファイルであって、前記ルールベース知識源によって作
    られる診断と、前記ケースベース知識源によって見出さ
    れたケースの整合を含む診断ファイルと、前記シェルに
    よって作成される黒板状態ファイルであって、ケースの
    入力データファイル作成サイクルの完了後に何らかの知
    識源によって修正される黒板情報を含む黒板情報ファイ
    ルと、を有することを特徴とする前記ソフトウェアシェ
    ル。
31. 【請求項３１】 請求項３０に記載のソフトウェアシェ
    ルであって、さらに相互接続のためのストリームソケッ
    トを含み、そのソケットが一対の要求−応答の形式にな
    っているメッセージの通信を行うことを特徴とする前記
    ソフトウェアシェル。
32. 【請求項３２】 請求項２２に記載のソフトウェアシェ
    ルであって、ケースベース知識源モジュールは、ケース
    ベース知識源がその上で実行する予め定められたパター
    ンおよび条件含むスキムであって、この条件は受信デー
    タおよびパターンに所定レベル以上の近似性がある場合
    に真と推定されるデータ比較スキムをさらに含むことを
    特徴とするソフトウェアスキム。
33. 【請求項３３】 請求項３２に記載のソフトウェアシェ
    ルであって、 上記データ比較スキムは、ケースベース知識源でのデー
    タの強度およびタイミングの両方を比較することを特徴
    とするソフトウェアシェル。
34. 【請求項３４】 請求項３３に記載のソフトウェアのシ
    ェルであって、ケースベース知識源モジュールは、すで
    に出たデータを含む記憶ケースと、記憶ケース中のデー
    タとの近似性によって現在のデータのランク付けを行う
    近似機能と、 をさらに含むことを特徴とするソフトウェアシェル。
35. 【請求項３５】 請求項３４に記載のソフトウェアシェ
    ルであって、ケースベース知識源は、列および行を有す
    るテーブルと、テーブルの行中に記憶され、少なくとも
    １つの変数を含む複数のケースフレームと、テーブルの
    列中に記憶され、少なくとも１つの変数を含む複数のケ
    ースと、 をさらに含むことを特徴とするソフトウェアシェル。
36. 【請求項３６】 請求項３５に記載のソフトウェアシェ
    ルであって、ケースベース知識源モジュールは、書く変
    数に関連付けられ、テーブル中に記憶された時間値をさ
    らに含むことを特徴とするソフトウェアシェル。
37. 【請求項３７】 請求項３６に記載のソフトウェアシェ
    ルであって、時間−強度スコアリングスキムは、予め特
    定されたデータ比較が行われる時間のウィンドウを含む
    ことを特徴とする前記ソフトウェアシェル。
38. 【請求項３８】 人工知能のソフトウェアのシェルを用
    いてプラント運転のシミュレーションを行う方法であっ
    て、プラントの各種構成要素と概念とを表すオブジェク
    トをデータベースに格納するステップと、入力データ源
    から入力データを読み取るステップと、所定の知識源優
    先度スキムにしたがって、入力データから、何時少なく
    とも１つのケースベース人工知能知識源が実行すべきか
    を決定するステップと、決定結果にしたがって、少なく
    とも１つのケースベース知識源を所定のオブジェクトに
    対し実行させるステップと、を含むことを特徴とする方
    法。
39. 【請求項３９】 請求項３８に記載の方法であって、そ
    の中で知識源を実行させる前記ステップがオブジェクト
    の値を更新するステップを含むことを特徴とする方法。
40. 【請求項４０】 請求項３８に記載方法であって、その
    中で知識源を実行させる前記ステップがさらに次のステ
    ップ、すなわち、連想づけられた信念のレベルを用いて
    if-then-else形式のルールを含む前向き連鎖信念伝播ス
    キムを持つルールベースの知識源を実行させるステップ
    と、予め定義されたパターンと条件を含むデータ比較ス
    キムを持つケースベース知識源を実行するステップと、
    を含むことを特徴とする方法。
41. 【請求項４１】 請求項４０に記載の方法であって、そ
    の中でケースベース知識源を実行させる前記ステップ
    が、受け取られたデータと前記パターンとの間で所定の
    一定レベルの近似度性が見出される場合に、前記条件が
    真であると推論するステップを含むことを特徴とする方
    法。
42. 【請求項４２】 請求項３８または４１に記載の方法で
    あって、決定ステップは、受信データとケース内にすで
    に記憶されているデータについて時間および強度の両方
    における近似性を比較するステップを含むことを特徴と
    する方法。
43. 【請求項４３】 請求項４２に記載の方法であって、記
    憶ステップは、オブジェクト、属性および値を記憶する
    ステップを含み、各オブジェクトは属性を持ち、各属性
    は少なくとも１つの値を持つことを特徴とする方法。
44. 【請求項４４】 請求項４３に記載の方法であって、知
    識源を実行させるステップは、知識源優先度スキムにし
    たがって、低い優先度の知識源の実行を中断し、高い優
    先度の知識源を実行させるステップを含むことを特徴と
    する方法。
45. 【請求項４５】 請求項４４に記載の方法であって、 決定ステップは、何時知識源実行プレコンディションが
    合致するかを検出し、単に知識源の実行プリコンディシ
    ョンが実行可能性に合致するかをチェックするステップ
    を含むことを特徴とする方法。