JPH06301546A - プラント運転シミュレーション用人工知能ソフトウェアシェル - 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 は、ファイル名.da
t、として識別される。構文は、図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 の特徴を使用して、
マン−マシンウィンドウ内に表示させることができる。
すべての出力ファイルは、エラーを発見するのを助ける
ために使用することができる。

【０２５８】システムの機能の仕様 このセクションでは、実時間工場診断、ドメインシェル
の機能の仕様について述べる。ソフトウェア開発プロセ
スが長期にわたる性格を持つことを考えれば、このセク
ションは、必然的にとりあえず役に立つという性質のも
のである。その目的は、シェルの機能性のあるべき姿に
ついて、長期の見通しを明確にすることである。その後
の開発段階が進展しているので、このセクションは、こ
のプロジェクトに関して次々に現れる要求事項に、より
正確に適合するように、改訂されるであろう。

【０２５９】四つのサブセクションがある。ここに述べ
る機能性の十分な達成は、この作業の成功にとって重要
であり、かつこの意味ですべてのサブセクションは極め
て重要である。一方、ユーザが受容してくれることは、
どんな製品でも、最終的には成功の決定的要素である。
それ故、ユーザに見られるオペレーティングコンセプト
を、まず検討する。シェルの外界とインターフェイスす
るシェルの能力もまた、シェルの有用性にとって重要で
あり、この故に、その成功にとっても重要である。イン
ターフェイスの必要条件が次の話題になる。知識利用技
術に関するサブセクションがそれに続く。最後に、ハー
ドウェア／ソフトウェアの必要条件で、このセクション
を終了しよう。

【０２６０】オペレーティングコンセプト このサブセクションでは、ユーザに見られる、システム
機能性について述べる。ユーザには二つの種類がある。
当該アプリケーションを診断と監視のために使用する工
場要員（エンドユーザ）、及び、シェルのアプリケーシ
ョンを開発する要員（アプリケーション開発者）であ
る。それぞれの種類のユーザは、更に細分できる。つま
り、エンドユーザの場合には、情報アクセスレベルによ
り、かつ、アプリケーション開発者の場合には、アプリ
ケーション開発のレベルにより、更に細分化することが
できる。それにもかかわらず、エンドユーザとアプリケ
ーション開発者は、同一の個人でありうる。それ故、オ
ペレーティングコンセプトは、すべての種類のユーザに
対して同一の直観的理解を与える性格を持たねばならな
い。これは、すべてのユーザインターフェイスが同一の
「外観と感触」を持つことという必要条件であるという
意味になる。

【０２６１】実行環境（エンドユーザの意見） 一般 実行環境を形成するプロセスは、アプリケーション開発
環境プロセスとは、全く別個のものである。後者は、進
行中の、かつ現在実行中の実行時情報を利用する手段を
有するのに対して、その逆は真ではない。これは、エン
ドユーザによる知識ベースの不完全または間違った変更
に起因する、実行時の誤った働きを防ぐために必要であ
る。

【０２６２】パスワードを利用する安全手続規定によ
り、エンドユーザは、種々の詳細レベルでの実行時情報
を利用することができる。これは、宣言方式を用いて、
アプリケーション開発者が定義する。

【０２６３】当該実行環境は、数人の同時ユーザを可能
とする。各ユーザは、彼のパスワードに対応するすべて
の情報を観察し、かつ、彼のアクセスレベルに指定され
たすべての能力を有する。シェルへのアクセスは、X-端
末機経由か、または、その他のワークステーション経由
かの、いずれかである。第一の場合には、システム性能
低下を防止するために、端末機数を制限しなければなら
ない。この制限は、アプリケーションに変化するので、
ここでは指定しない。

【０２６４】一般に、エンドユーザインターフェイス
は、ウィンドウの階層構造で構成される。すべてのユー
ザは、標準ウィンドウオペレーション（縮小、トラッキ
ング、拡大等）を許可されている。けれども、ウィンド
ウの階層構造及び内容の両方共、エンドユーザインター
フェイスの基本的機能のライブラリから、アプリケーシ
ョン開発者により、宣言方式で、定義される。これらの
機能には、下記のものが含まれるが、それらに限定され
るわけではない。

【０２６５】データ表示（グラフ、表） システム表示（モデル、ルール等） メッセージ 選択メニュー（ポップアップ、プルダウン） 対話ウィンドウ ノートブック 初めの三つは、ユーザへの情報である。後の三つは、ユ
ーザからシステムへの情報を含む。

【０２６６】すべてのグラフィック表示は、アプリケー
ション開発者が作成したグラフィック形式の複製であ
る。

【０２６７】すべてのユーザインターフェイス機能性
は、常に、ユーザに利用可能である。それにもかかわら
ず、行動は、障害の有無に関連して、情況によりある程
度変化するはずであると予想される。

【０２６８】障害がない場合 障害が発生していない通常の環境下では、全ての診断は
バックグラウンドで行われていてユーザとの対話は要求
されない。そのため、この状態における診断プロセスを
観察するのはあまり面白くない（観察するのが可能とし
ても）し、ユーザインターフェイスは基本的にシステム
を通したブラウザ（斜め読み）となっている。アクセス
レベルに従って、ユーザはシステムの任意の部分を選択
することが出来る。すなわち、モデル、ルール、現行の
１次データ（測定値）と２次データ（計算値）、履歴デ
ータ、過去のケースのデータベース等を表示及びブラウ
ジング（斜め読み）の手段によって。これらの環境下で
は、システムへの通常のユーザ入力だけが、ノートへの
記入になる〔システムへの入力は実際には発生しな
い〕。

【０２６９】障害が発生している場合または発生が予測できる場合 診断プロセスが異常状態を検知した場合、アプリケーシ
ョン開発者によって定義されたアラーム／警告のメッセ
ージが表示され、エンドユーザの注意点が、ブラウジン
グしている場所からモデル階層の適切な場所まで自動的
に変更される。適切な色コードが使用されなければなら
ない（たとえば、点滅する赤は新しいアラーム、点滅し
ない赤は認識済のアラーム等）。

【０２７０】診断プロセスが異常状態を検知しない場合
でも、もしユーザが障害の発生に気付いたがシステムは
発見できなかった場合、ユーザは注意を集中するように
要求することが出来る。

【０２７１】集中状態の場合、適切なアクセスレベルを
持っているユーザは、ある程度のシステムコントロール
を行うことが出来る。たとえば、診断プロセスを障害に
集中させる（すなわち、後向き連鎖を実行する） ケースベース推論知識源を使用する モデルベース推論知識源を使用する 説明機能を実施するその他の対話 通常の環境と、障害が発生している環境のどちらでも、
ユーザにはシステムから追加入力が要求される。これは
手続きウィンドウ−対話ウィンドウの特別な場合−を使
って行うことが出来る：ユーザは手続き（動作の順序）
を実行すること及び手続きの結果（効果）を返答するこ
とが要求される。手続きは、普通、オンライン情報を使
っているルールによって生成された仮設を確認・反駁す
るのに使用される。ユーザはアラームを認識することが
要求される。通常、その結果、画面のある部分の表示色
が変化する。

【０２７２】アプリケーション開発環境 （アプリケーション開発者の観点）総論 アプリケーションの知識源部分の開発は、常に、極めて
困難なプロセスである。大部分のアプリケーションで
は、これが開発上のボトルネックとなっている。困難さ
は、プロセスの三つのフエーズのそれぞれに示されてい
る。すなわち、専門家からの知識の抽出、シェルで使用
されている凡例を使った知識の体系化、及びコンピュー
タへの知識の入力である。知識の体系化は、知識凡例の
いくつかを使うことによって支援されるが、これは、知
識源に関するセクションで論じた。それは、コンピュー
タへの知識の入力であり、ここの主題である。

【０２７３】コンピュータへの知識の入力の前に発生す
る、すでに困難な二つのタスクに過度の負担を加えない
ことが、アプリケーション開発環境の極めて重要な点で
ある。インターフェイスの背後にある基本原則は従っ
て、使い易さにある。実際の言い方では、これは二つの
要求：すなわち、ユーザ入力のグラフイック化及び利用
ツールの豊富さと解釈出来る。さらに、ツールは事実
上、極めて直観的でなければならない。最上級レベルで
は、開発者のインターフェイスは、ユーザ（開発者）が
現在の開発ステップで使うのに最も適したツールを選択
する。オプションのメニュー駆動列（a menu driven se
ries of options ）から構成されている。次のセクショ
ンで多数のツールの機能について簡単に述べる。一方、
認識に基づく要求については別途述べられるが、これら
のツールは、別々の実体または数少くないコンテキスト
の検知ツールとして実行することが出来る。

【０２７４】アプリケーション開発は、二つのステップ
で行われる。最初、ドメイン特性化コンテキストが生成
され、次にアプリケーション特性化知識が入力される。
各ステップは、異なる開発者または同じ開発者によって
実行される。ステップ間には明確な境界はない、そし
て、いくつかの基本実体が定義されてから各ステップは
並列に進む。これらのステップに支援可能なツールが完
備していることは、知識ベース管理を容易にするもので
ある。

【０２７５】ドメイン特性化コンテキストの生成 ドメイン特性化コンテキストには、ドメイン中の推論過
程で連想づけられたコントロールメカニズム（推論規
則）と同じく、ドメインに対する語彙（抽象）特性が含
まれる。このように、このレベルでの主なツールは、ア
イコンエディタと連想づけられた基本オブジェクトのエ
ディタである。これらのツールはアプリケーションドメ
インの基本実体を定義するのに使用される。アイコン
（図形）エディタは、それぞれの基本オブジェクトのグ
ラフィック表現を生成するのに使用される。一方、基本
オブジェクトエディタはこれらのオブジェクトの属性を
記述するのに使用される。

【０２７６】例えばIS-A及びPART-OF 階層エディタがあ
る。これらのツールは、基本オブジェクトエディタの機
能を拡張する（これらは実行に関しては、一緒であり、
同じものである）。

【０２７７】グラフィックアプローチを使ってこれらの
ツールは次のために使用される。

【０２７８】１．IS-A及びPART-OF 階層に基本オブジェ
クトを結合する。

【０２７９】２．オブジェクトが継承した属性の編集ま
たは削除、および属性の追加。 構成要素を通常モード・失敗モードに変換する機能を定
義する行動ルールエディタである。このツールは、シミ
ュレーション（モデル）ベース推論のため、構成要素の
行動を記述する体系を定義するのに使用される。

【０２８０】コントロールエディタのツールは、黒板制
御モジュールの中で、推論プロセスのうち、アプリケー
ションドメイン特性化の宣言部を生成するのに使用され
る。黒板制御モジュールの中で、推論プロセスの手続き
部はＣ／Ｃ++で書かれる。このプロセスはこの文書の要
求の範囲外である。

【０２８１】アプリケーション特性化知識の生成 アプリケーション特性化知識の入力プロセスではつぎの
ツールを使用する：前のサブセクションで述べた、IS-A
及びPART-OF 階層エディタは黒板構造を定義するのに使
用される。グラフィックアプローチを使って、基本オブ
ジェクトのインスタンスが生成され、記述され、そして
実際のアプリケーションの記述モデルへ結合される。こ
のモデルが黒板である。

【０２８２】ルールベース知識源の型のそれぞれのルー
ルエディタである。再びグラフィックアプローチを使っ
て、さまざまなルールベース知識源を形成するルールが
生成される。ルールによって連想づけられる全てのパラ
メータは、これらのツールを使って定義される。

【０２８３】ケース構造エディタのツールはケースの一
部として蓄積される変数、属性、特徴等を定義するのに
使用される。

【０２８４】ケースベース推論のため類似性規則（測定
−metrics −）を定義するルールエディタは、ケース間
の類似性や有用性を測定するのに使われるアプリケーシ
ョン特性化体系を定義する宣言的アプローチである。

【０２８５】平易なテキストエディタは、メッセージ、
記述、機能説明文、開発者の覚え書き等のフリーフォー
ム文章を生成する要求を満たすだろう。

【０２８６】知識システムのユーティリティ これらはアプリケーション開発者の効率向上のために、
種々の黒板や知識源の実体の取り扱いが容易に出来るよ
うに設計された、便利なユーティリティである。

【０２８７】複写・移動ユーティリティは、一つまたは
それ以上の構造の集まりに対して、基本的な切り貼りの
機能を提供する。

【０２８８】リストユーティリティは、構造−利用可能
な任意のレベルの詳細までの−の型のリストを作成する
ために使うことが出来る。

【０２８９】マージ／分割ユーティリティは、その名称
が意味するように、二つのルールベースを一つに結合し
たり、一つのルールベースをいくつかに分割するために
使うことが出来る。このユーティリティは、開発者を二
人から一人へ交代すること、あるいは、逆への交代を容
易にすることが出来る。

【０２９０】展開前のユーティリティ これらのツールは、ルールが開発されてから、アプリケ
ーション開発者が、効率的、コンパクト、強固、展開可
能な知識システムを生成するのを支援するために設計さ
れた。システム開発の後半のフェーズで重要であるとは
いえ、これらのツールはいつでも使うことが出来る。

【０２９１】テストデータジェネレータとして、ルール
ベースの正確さを確認するのに必要なテスト用入力デー
タの生成のために、いくつかのメカニズムが用意され
る。

【０２９２】手動入力は最も簡単で、最も分かりやす
い。開発者は対話ウィンドウに入力値を与える責任があ
る。これはルール実行の簡単なテストに適している。

【０２９３】後戻りアプローチ：開発者は、（手動入力
で）“良い”データ群及び入力データの時間変化を記述
するテスト計画を作成する。それから、このユーティリ
ティは、テストデータ系列−それぞれの系列はテスト計
画で定義した、一つまたはそれ以上の入力に対する混乱
原因の列で構成されている−を生成するために、後ほど
このセクションで述べられるシミュレータ機能を使う。
それから、それぞれの系列は実行され、その結果は後半
の解析のため保存される。

【０２９４】“実際の”データ源には二つある： １．集められた（データベース）入力データは、調査と
変更のために使われ、その後、テストされるべきルール
ベースに返すことが出来る。

【０２９５】２．現在実行中のシステムのウィンドウ
は、実際のオンライン入力データを用意することが出来
る。

【０２９６】無矛盾チェッカーは黒板と知識源から未解
決のもの、不完全情報等を捜す。このツールのいくつか
の機能は、アプリケーションに依存している。無矛盾チ
ェッカーは、配備している（実用になっている）アプリ
ケーションを改良して、新しいバージョンの知識システ
ムにするとき特に役立つ。新しいバージョンに切り替え
る前に無矛盾をチェックすることは、“衝突のない交
代”に影響するかもしれない矛盾を指摘することが出来
る。

【０２９７】コンパイラは、アプリケーションの重要な
オンライン部分をできるだけコンパクトで効率的にする
手段を提供する。これらのツールは、重要な黒板及び知
識源の構造をメモリ常駐型構造に変換する。メモリの利
用効率を最大にするため、早い実行が要求される黒板及
び知識源構造のみがコンパイルされる。コンパイラはま
たメモリ使用状況の詳細な情報を生成する。

【０２９８】実行とデバッギングユーティリティによ
り、開発者は開発以前に十分にシステムを練習すること
ができる。これらのユーティリティは明白な機能、すな
わち性能測定の他に更に追跡、ブレークポイントの設
定、知識源を通るステップを与えるものである。

【０２９９】配列ユーティリティ 編成ツールによって、開発者はアプリケーションの要求
に合わせてシステムを組み立てることができる。

【０３００】開発者は１セットのツールにより、オンラ
インデータの入出力をシステムに出し入れできる。これ
には次のものが含まれる。即ち、入力センサの配列、長
期にわたる記憶のためのデータベースへの出力および入
出力のための外部処理インターフェイスである。

【０３０１】別のセットのツールでは、開発者はエンド
ユーザのために各種のアクセスレベルを配備することが
できる。開発者は、各アクセスレベルで見ることができ
る情報の階層を作成し、エンドユーザの一覧の項で説明
するように、各アクセスレベルが持つことになる制御レ
ベルを定義する。

【０３０２】インターフェイス要件 センサ入力（データ収集および前処理） 図３８は、代表的なデータ収集と前処理システムのブロ
ック概念図であり、またデータ取得システムにも関す
る。センサ、信号の条件付けおよびＡ／Ｄ変換モジュー
ルについては説明の必要は無いと思われる。データ前処
理モジュールは、それぞれのアプリケーションにより様
々に異なる、各種の機能を実行できる。このモジュール
は、通常最低でも、工学単位の変換、デジタル信号処理
（例えば、デジタルフィルタリング、ＦＦＴ）、データ
の記録・保存、特徴抽出および表示機能を行う。データ
取得システムは、独立したシステムとすることも、組み
込み式とすることもできる。特に大規模プラントでは、
データ取得システムは、データハイウェイに接続し、プ
ロセス制御システムの中に組み込まれている。データ取
得システムによって得られるセンサ情報にアクセスする
ことは、ドメインシェルにとって無くてはならない必要
条件である。ドメインシェルの観点から見ると、この必
要条件は、センサデータが、本稿に説明される制御モジ
ュールの通信マネージャ／事象検知部プロセスを通して
何らかの方法で黒板に書き込まれることである。大切な
ことはいかにしてこれを行うかである。

【０３０３】この問題は、既存のデータ取得システム
が、この種の組み込まれた能力では確実には開発されな
かったことである。そのかわり、データはせいぜいデー
タハイウェイから入手できる程度で、悪くするとシステ
ムの深部のどこかに埋め隠されてしまう。さらに、一部
のデータ取得システムは、そのデータを広く他の世界
（自発的データ取得システム）に開放させることがで
き、他のものでは外部のプロセス（非自発的）によって
問い合わせをされなければならない。

【０３０４】どの様にしてデータにアクセスするかとい
う問題を解決するについては一様な包括的あるいはユニ
バーサルな方法は存在しない。最も信頼性の高いアプロ
ーチは、図３９に示す通りで、ここではドメインシェル
とデータ取得システムとの間の明確な境界が定義されて
いる。この境界には、二つの部分からなるインターフェ
イスがあり、その一つはそれぞれのタイプのデータ取得
システムに固有なものであり、他方はシェルとの通信を
処理するものである。インターフェイスの固有部分は、
データ取得システムの特徴にしたがって有用なデータを
引き出すのに必要なものである（例えば、それはハイウ
ェイドロップまたは、データが保管される場所を知って
いるソフトウェアの小さな一部、あるいはデータ取得シ
ステム内部の通信径路のどれかをモニターするソフトウ
ェアの一部である）。非自発的なタイプのデータ取得シ
ステムでは、特定のインターフェイスが必要なデータの
要求も行われなければならない。このインターフェイス
の通信部分は、このデータを、シェルの一部であり、プ
ロトコルを使ってデータを再フォーマットするようにプ
ログラムされた一般的な遠隔通信プロセスに送るために
ソケットメカニズムを使い、次にそれを通信マネージャ
／事象検知部プロセスに通信する。

【０３０５】このようにして、この問題は最小の特定イ
ンターフェイスを各タイプのデータ取得システムに展開
する点に絞られた。

【０３０６】外部プロセス 外部プロセスは、シェルに直属する範囲の外にあるもの
である。これらは、診断アプリケーションに有用と認識
されたタスクあるいは診断アプリケーションに無関係な
目的で将来開発されるプログラムを実行するが、有用な
追加の機能を用意することができる既存のアプリケーシ
ョンを含むことができる。このような外部プロセスとイ
ンターフェイスする能力はシェルに対する基本的な要求
条件である。

【０３０７】この条件を達成するには二つの問題を解決
しなければならない。その一つはトランスポートレベ
ル、即ち、メッセージ交換のための低レベルプロトコル
に付加される物理的接続の必要性に関係するものであ
り、もう一つはアプリケーションレベル、即ち交換が行
われた後でメッセージを理解する能力に関係する。外部
プロセスは、二つのタイプに区分できる。つまりシェル
アプリケーションと同じ装置でランするものと、別の装
置でランするものとである。

【０３０８】同じ装置のプロセスとのインターフェイス
は、トランスポートレベルでは何も問題にならない。Ｕ
ＮＩＸパイプとストリームで十分な接続が得られる。他
の装置のプロセスとのインターフェイスでは、ＴＣＰ／
ＩＰのようなプロトコルが十分であるため、これより多
少複雑になるが、今後しばらくすればＴＣＰ／ＩＰを利
用するＯＳＦ分散計算環境のような現在生まれつつある
規格の利用を考えるようになるかも知れない。

【０３０９】メッセージの理解の問題は、決して些細な
ものではない。ＯＳＦ規格は、通信チャネルの両側でそ
の規格に従うことを要求する、遠隔操作呼び出しのメカ
ニズムを提供する。これは将来外部プロセスに適用でき
るかもしれないが、既存のプロセスの問題は解決されな
いままである。データ取得システムとインターフェイス
する図３９に示すものと同様なアプローチがインプリメ
ントされるのではないかと見られる。シェルの不可分な
部分としての遠隔通信プロセスはいかにしてシェルと交
信するかを知っており、必要に応じて、各外部プロセス
に対して開発された特定のインターフェイスとメッセー
ジを交換することになる。

【０３１０】従って、実行可能な展開径路は、ＨＰがＯ
ＳＦ標準に関連しており、また既存のインターフェイス
メカニズムに対する支援を続けると見られるため、ＨＰ
／Ａｐｏｌｌｏプラットフォーム上の利用できるリソー
スの使用を含むことになる。もっとも詳細で、実際的な
要求が発生するまでは、シェルの初めのいくつかの実際
のアプリケーションが、外部プロセス問題に対する手動
で調整する解決を必要とする事になると見られる。

【０３１１】外部プロセスインターフェイスの特別なケ
ースの一つは、外部プロセスが知識源としての有効性を
持つ場合である。その場合、上記に説明した通信問題の
解決の他に、アプリケーション開発者は、本稿に説明す
るように事象、前提条件及び優先情報を定義しなければ
ならない。

【０３１２】制御出力 このシェルからの制御出力は存在しないであろう。しか
し、この問題は、今後必要が生じたときに再考すればよ
い。

【０３１３】知識システムのアーキテクチュア 全体的知識システムのアーキテクチュアは図３に示され
ている。これは基本的に、様々な知識モジュール（源）
が解決に寄与する黒板アーキテクチュアである。問題解
決戦略は、どの知識源が、どの順序で寄与するかを決定
する制御モジュールに含まれている。「世界」（プラン
ト）の状況は、グローバルな構造であり、知識システム
のすべての構成要素にアクセス可能な黒板に保管されて
いる。下記のセクションは、リアルタイムのプラント診
断ドメインの性質を満足させるであろう機能的な必要条
件を主体とするやり方で各構成ブロックの詳細を説明す
る。黒板 黒板は、ある特定のアプリケーションの物理的リアリテ
ィのシンボル表現を形成するオブジェクトのグローバル
データベースである。したがって、黒板におけるオブジ
ェクトは一般に物理的オブジェクトに対応し、物理的オ
ブジェクト間における空間的・機能的関係を記述してい
る。

【０３１４】黒板のオブジェクト間における相互関係
は、３つの異なるレベル、すなわち二つの垂直階層（Ｉ
Ｓ−ＡおよびＰＡＲＴ−ＯＦ）と一つの連結性（ＬＩＮ
ＫＳ）の水平記述から構築されている。さらに、各オブ
ジェクトは対応する物理的オブジェクトの行動を表して
いる。行動の表現を含めたこれらの関係の全体により、
抽出レベルへの分解を通じて実世界のモデルを構築する
ことが可能となる。そのモデルは、複雑さの程度におい
ては任意であり、利用可能な知識の量、モデル開発に費
やす時間の量、そして当然ながら利用できるコンピュー
タ資源によってのみ制限される。

【０３１５】各黒板オブジェクトは属性を有し、各属性
は一つもしくはそれ以上の値を有する。一部の属性は単
一の値で定義され、他の属性は多値で定義される。すべ
てのオブジェクトは大略図４０に示す構造で開始され
る。

【０３１６】ＩＳ−Ａ階層 この関係は、オブジェクトをクラス、タイプ等に分類す
る。ＩＳ−Ａ属性は多値である。すなわち、１つのオブ
ジェクトは２つ以上のクラス（または２つ以上のタイ
プ）に属する。逆の関係はＨＡＳ−ＩＮＳＴＡＮＣＥで
ある。この属性ももちろん多値であり、そのオブジェク
トの例となるすべてのオブジェクトをリストアップす
る。したがって、 オブジェクトＡ HAS-INSTANCE オブジェクトＢ ＜＝
＞ オブジェクトＢIS−A オブジェクトＡ ＩＳ−Ａ階層の有用性はモデルの開発プロセスにある。
各アプリケーションにおいて、基本的なオブジェクトの
一組が開発され、この一組がそのアプリケーションに対
する基本的な語彙を構成する。各々の新しいオブジェク
トはその後その親の属性を引き継ぐ。その親の属性の値
も引き継がれる。これにより、開発者の効率を向上させ
て開発プロセスが簡素化さる。

【０３１７】この引き継ぎメカニズムは、しかしなが
ら、元来スピードの遅い工程であるため、実行時中には
保存されない。その代わり、各々の実行時のオブジェク
トは、実行中に必要なすべての属性と値を“備え”られ
る。

【０３１８】ＰＡＲＴ−ＯＦ階層 この関係は、物理構造のきわめて簡単な記述である。Ｐ
ＡＲＴ−ＯＦ階層は、オブジェクトの構成を取り扱うだ
けであるが、複雑な構造を適切に分解するためにはそれ
で十分（かつ必要）である。ＰＡＲＴ−ＯＦ階層の属性
は単一値であるが、その逆すなわちＨＡＳ−ＰＡＲＴＳ
はもちろん多値である。ＰＡＲＴ−ＯＦ階層もまた多値
にしなければならないであろうと考えることもできる。
ＰＡＲＴ−ＯＦ階層は、エンドユーザに対し、１回にレ
ベルずつ可視となる。

【０３１９】行動およびＬＩＮＫＳ モデルは、オブジェクトの行動およびオブジェクトがリ
ンクされる方法を定義することによって完成される。各
オブジェクトは入力と出力を有している。行動は、出力
が入力によっていかに定義されるかを表す機能を指定す
ることによって定義される。その機能の要素は、シミュ
レータモジュールツールボックス上の部分に記載され
る。ただし、黒板におけるすべての単一のオブジェクト
に対して一つの機能属性を定義する必要はない。その定
義は全面的に省略することができるが、この場合、その
オブジェクトはモデルに基づく知識源による使用ができ
なくなるか、あるいは分解レベルの低下を遅らせること
ができる。すなわち、そのオブジェクトの行動はＨＡＳ
−ＰＡＲＴ階層におけるその構成要素の行動によって記
述される。

【０３２０】オブジェクトのリンクは、一つのオブジェ
クトの出力を他のオブジェクトの入力に連結することに
よって行われる。連結はＬＩＮＫＳを使って行うが、Ｌ
ＩＮＫＳそれ自身は、図４１に示すように、黒板のオブ
ジェクトになっている。明らかな例外は、システムの物
理境界におけるオブジェクト、すなわち、入力が外部世
界（例えば、センサ）の端末点（例えば、出荷室）から
本システムに入力される入力地点でのオブジェクトであ
る。

【０３２１】その他の属性 アプリケーションの開発者は、任意のオブジェクトに対
して他の属性や関連した値を付け加える能力を有するで
あろう。これらの属性のうち、一部は知識源によって必
要とされるものであり、他は単に“世界”モデルを完成
させるために望まれるものであろう。ただし、新しい属
性は実行時においては付け加えることができない（次節
を参照）。

【０３２２】インプリメンテーション アプリケーションの開発中、および実行時中には異なる
黒板のインプリメーションが存在する。

【０３２３】開発プロセスは、本質的に相当程度の実
験、したがって多くの変更を必要とする。また、そのプ
ロセスは、大部分時間や資源が決定的な需要性をもたな
いプロセスである。この期間において、黒板はフレキシ
ブル構造（リンクされたリスト、Ｃ＋＋オブジェクト、
等−システム設計中に決定すべきもの）として表され
る。

【０３２４】実行時に対して、黒板は２つの部分に分割
される。その一つは、実行に必要なデータを含むもの
で、可能な限りコンパクトかつ効率的なメモリ常駐構造
にコンパイルされる。もう一つは、性能に関係のない情
報を含みディスク収容状態に維持される。これにより、
実行時および資源節約の両面において最高の性能が提供
される一方、エンドユーザが黒板構造に動的な変更を行
わないように制御される（属性値は当然ながら変更する
ことができる）。

【０３２５】実行時黒板は、一つのマシンにしか存在し
ない。すなわち、実行時黒板は異なるプロセッサのメモ
リに分散して存在することはない。性能を最高にするた
めに、他のＣＰＵ（すなわち、黒板のメモリ常駐部分を
含むＣＰＵでないもの）において実行する知識源に、黒
板の一部のそれぞれのコピーを必ず備えさせておくこと
が可能である。将来においては、莫大なアプリケーショ
ンがグローバルな黒板をいくつかのマシン間に分散する
ことをついには要求するようになる可能性がきわめて高
い。これを達成する困難さを考慮しても、必要とあらば
そのような要求に向けて展開していくことが望ましい。

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

【０３２７】一般的要求事項 シェルのリアルタイム性は以下の制御モジュール要求事
項に反映される。すなわち、速度は、短時間のうちに、
かつ最少の制御オーバーヘッドでタスクを実行する能力
であり、応答性は、反応することが必要な場合に、変更
された条件に反応する能力であり、適時性は、必要とさ
れる時までに結論（診断、または部分的診断）に到達す
る能力であり、適応性は、条件が変化したとき、ストラ
テジを変更する能力である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０３４８】ルールベース ルールベース型知識源はＩＦ．．．ＴＨＥＮ．．．型の
ルールをインプリメントする。ほとんどのルールベース
システムにおいて、ルールは人のヒューリスティックな
知識を映し出すように設計されている。本方法も同様で
あるが、特に限定事項はない。つまり、ＩＦ．．．ＴＨ
ＥＮ文として表現できる全ての「シャンク」の知識に関
して可能である。

【０３４９】ルールベースシステムはプロダクションシ
ステムとして構成することができる。このシステムにお
いて、それぞれのルールは明確な開始ポイントと終端ポ
イントのある知識の一つの独立したシャンク（例：ＯＰ
Ｓ５）であるか、または、ルールは木として体系化され
ているかである。後者のアプローチを本方法では用いる
ことにする。多数の開始ポイントはデータがシステムに
入ってくる場所である。そして、終端ポイントは全ての
ルールが発火されてしまった後に到達した結論である。
通常、終端は実世界の障害に相当している。

【０３５０】ルールベースシステムは前向き連鎖（デー
タ駆動）または、後ろ向き連鎖（仮設駆動）を行うこと
ができる。両パラダイムともに、インプリメンテーショ
ンの章で述べる様に、異なるコンテキストに対して、イ
ンプリメンテーションすることになる。

【０３５１】ここから続くルールベース知識源に関する
記述は、ほとんど、Ｗｅｓｔｉｎｇｈｏｕｓｅ内で広く
用いられている既存のシステムに基づいている。完全な
記述というよりは、主な要求のアウトラインである。さ
らに加えるならば少なくとも部分的には既存のシステム
の「ａｓ−ｉｓ」の利用は除外されている。なぜなら、
ルールベース知識源が適合して行かなければならない黒
板フレームワークを利用しているからである。

【０３５２】ルールベース木構造 ルールベースの基本要素は、もちろん、ルールである。
最も単純な形の一つのルールは以下の様に定義される。

【０３５３】ＩＦ（条件式）ＴＨＥＮ（仮設、実行） 条件式の部分と仮設部分は木の構造の中のノードに相当
している。複数のルールそれ自身は、複数のフレームと
して実行される。このフレームは条件部の一つ、または
多くのノードから、実行部の一つ、または多くのノード
への方向性を持ったリンクとして記述する。実行部は、
その木の中の実際のノードに対応していない行動をやは
り組み込むことができる。

【０３５４】ノードの第一層はデータノードである。つ
まり、外部情報がルールベース部分へ入る入口である
（通常センサより）。同様に、最終層は終端点に相当し
ている。つまり、部分的または最終的診断である。ノー
ドの全ての中間層は仮設を表現する。つまり、推論過程
の中間段階として表現されている。第一層と最終層は黒
板オブジェクトの中の属性がマッチングしていなければ
ならない。中間層もやはり黒板オブジェクトの中へマッ
プされることとなるが、必ずというわけではない。

【０３５５】以上の様に記述されたノードに加えて、変
数の数値を保存するための他のノードが必要であろう。
これらの数値はデータノード中の数値と同様に、時間ス
タンプされ有効時間も推定できる。

【０３５６】木の中のそれぞれのノードは信頼のレベル
値であるＣＦ値と、信念の基準であるＭＢとおよび不信
念の基準であるＭＤと連想づけられている。これらの間
の関係は、以下のようになる。

【０３５７】ＣＦ ＝ ＭＢ − ＭＤ もし、ＭＢとＭＤが０（それぞれ、全く信念が欠如して
いる。または、全く不信念がない場合）から１（完全な
信念または完全な不信念）の範囲とすると、この場合Ｃ
Ｆは−１（そのノードの偽が絶対的に信頼できる）から
＋１（そのノードの真が絶対的に信頼できる）範囲とな
る。ノードは全てのＣＦ、ＭＢ、ＭＤを０にセットした
ところから始まる。それぞれの値は、推論機構により更
新される。これについては、この章の後半で説明する。

【０３５８】ルールは同様の信念基準を持っている。十
分性係数と必要性係数（ＳＦとＮＦ）と称する。十分性
係数は条件の真の度合い（条件部）が仮設（実行部）に
影響する度合いを表現している。つまり、十分性係数は
ルール自身の真の信念の基準である。必要性係数は仮説
が偽になった場合の偽の条件の影響を映し出す。つまり
仮説が真になる為には、条件が真になる必要性がどの程
度になるか示す。信念の基準がノードに連想づけられて
いるのと異なり、十分性係数と必要性係数とは先験的な
基準である。つまり、アプリケーション開発者やエキス
パートにより定義される。

【０３５９】推論機構 基本推論過程は信念の計算により成り立っている。基本
的に、一つのルールは、あらかじめ決定された度合いに
対して、条件部が真の場合に発火される。そして、条件
の真理値はルールそれ自身の信念（十分性ＳＦまたは、
必要性ＮＦ）に結合される、そしてそのルールの仮説の
真理値として用いられる。結合アルゴリズムは以下の通
りである。

【０３６０】 ｉｆ ＣＦ（条件） ＞０ ｔｈｅｎ ＭＢ（仮設） ＝ ＳＦ ＊ ＣＦ（仮設）、ａｎｄ ＭＤ（仮設） ＝ 変化せず ｉｆ ＣＦ（条件） ＜０ ｔｈｅｎ ＭＤ（仮設） ＝ ＮＦ ＊ −ＣＦ（条件）、ａｎｄ ＭＢ（仮設） ＝ 変化せず 一つ以上のルールが同じ仮設を持っているときは、その
真理値は、確率の結合更新ルールを用いて増加的に更新
される（個々の寄与を加算する。そして積の部分を減じ
る）。

【０３６１】前向き連鎖は演算の通常モードである。そ
れは対応する黒板オブジェクト（通常センサの読み）か
らデータノードに対する値を抜き取ることにより開始さ
れる。これらの値は読みをハイ、ローなどの信念にマッ
プされる。次に信念は、ルールネットッワーク（木）に
伝達される。発火するためのルールがなくなるまで繰り
返す。条件の真の度合いにより発火する多くのルール
は、そのルールを活性化する。微妙なマージン（例えば
「ＣＦが０．８以上のルールのみ発火される」）は発火
の数を減少し速度を改善する。一方、増加的更新のため
の比較的小さな寄与は無視され、診断がミスする場合が
ある。マージンの増加は発火されるルールの増加をもた
らす。このマージンは、それぞれのルールで個別にセッ
トすることができ、修正αβサーチ法により完全にアプ
リケーション開発者の統制下におかれている。

【０３６２】後ろ向き連鎖は可能であるが、有効ではな
い。オペレータはシステムを特定の問題に対して焦点を
当てる様に要求することができる。全ての必要な入力を
見つけるまでルールベースは後ろ向き連鎖を行い、次に
前向き連鎖を実行し、オペレータに結果を与える。この
モードでは、発火するルールに対する条件の真の度合い
が重要性を増す。特に、データがオペレータより入力さ
れる場合には重要である。この方法はエンドユーザから
要求される情報量を減少する。

【０３６３】推論機構の特筆すべき視点は、ルールは実
行時にルールベースそれ自身が動的に書き記すことがで
きる。この特徴の典型的利用は入力データ、それ自身の
信頼性を診断することである（つまりセンサの劣化や、
故障を検出することである）。もし、入力データの信念
度が十分な値から低下しているのが見つけられた場合に
は、信念レベルを適宜、減少する。この様にして破壊的
でなく徐々に性能を低下する。この特徴の他の利用は値
が消滅した場合や新しいデータが有効でない場合の実行
手順であるといえる。

【０３６４】条件式 信念を向上させるために、ルールは条件式のレベルが必
要である。条件部の表現は以下の様に定義される。

【０３６５】（条件式） ＝ （＜演算子＞＜引数１＞
・・・＜引数Ｎ＞） 式は括弧を用いたプリフィックスまたは挿入辞（インフ
ィックス）の記号表現によって記述される。全ての式は
真理値（信頼レベル）として評価する。条件式はいかな
る複雑な表現も可能である。要求される引数の型に整合
するネストされた演算子による型に帰着するデータであ
るかぎり可能である。演算子にはいくつかの型がある。

【０３６６】代数型：edd,diff,times,divide,minus,ab
s,sin,cos,tan,asin,acos,atan,exp，iog,sqrt,avg,mi
n,max,std-dev プール代数型：fuzzy and,fuzzy or,weighted and,weig
hted or,not comparativbooleans(less,eqal,greater) タイムベース型 : trend,average-trend,time-average,
time-min,time-max,time-min-t,time-max-t,time-sbd-d
ev,antebrate 変化ベース型：time-when,vaiue-when 引数にもいくつかの型がある。

【０３６７】内容 （変数の）値 （ノードの）確信レベル 前述の一つを返す関数 他の式（再帰的） プール演算子は実際に信念性の伝搬過程に対して用いる
ものである。それは、引数の信頼レベルを新しい信頼レ
ベルに結合するかまたは比較型のプル演算子に結合す
る。それらは、比較の真のレベルより信頼レベルを計算
する。結合式を以下に示す。

【０３６８】 fuzzy and: CF(A and B) = min ( CF(A),CF(B)) fussy or : CF(A OR B) = MAX ( CF(A),CF(B)) weighted and : CF(A AND B) = ( CF(A)*W(A)+CF(B)*W
(B))/(W(A)+W(B)) weighted or :CF(A OR B) = max(CF(A)*W(A),CF(B)*W
(B)) not : CF(not A) = - CF(A) 比較ブール演算子は厳密な比較である。つまり、＋１ま
たは−１の信念を返す。または、比較のあいまい性の程
度を与えるマッピング関数として用いられる。

【０３６９】代数演算子は数を評価したり、数を返した
りする引数を持っている。タイムベース演算子は、時間
の概念をルールベースへ組み込む。それらの関数の一つ
の引数は常に時間に対する変数である。つまり、通常、
時間感覚として指定する。例として、ＴＩＭＥ−ＭＩＮ
演算子は、指定の時間感覚全体にわたってノードの最小
値を見つける。同様に、ｔｉｍｅ−ｍｉ，ｎ−ｔ演算子
はノードの値の最小値が生じた時にその時間を返す。ル
ールの中でタイムベース演算子を用いる効果は十分な長
さの履歴が自動的に確保されることである。限界は強固
に存在しているものの、ルールベースからデータベース
へ転送する非常に古いデータ（例えば、週、月）に対し
ての参照を予防する。自動記憶の容量は、アプリケーシ
ョン開発者が定義することができる。時間に対するター
ム（例：三日以前のデータはセイブしない）または、記
憶要求（例：１００Ｋバイト以上は蓄積しない）のいず
れかである。データベースの長期記憶は適切な情報とし
て備えることにより用いられる。

【０３７０】変化ベース演算子は、タイムベース演算子
とデータ蓄積をトリガしないことを除けば同様である。
最新の時間を記録していること、または、指定の変化が
生じた最新の値を記録していることについては例外であ
る。変化はいくつかの式の真理値の変化、つまり真から
偽、またはその逆の遷移として定義される。

【０３７１】より多くの演算子を定義するために、ある
メカニズムがアプリケーション開発者に与えられてい
る。いくつかの制限の範囲の中で、宣言型として行われ
るか、または、プログラミングを必要として行われる。

【０３７２】その他の要求 コンテキストは、アプリケーション開発者に、ルールの
実行をある程度コントロールする権利を与える事が出来
る。特に、コンテキストを伴うルール群を連想づけるこ
とによって、アプリケーション開発者はこのようなルー
ル群を逐次実行する。これは推論プロセスの効率を向上
させるものである。典型例は、マシーンが異なったルー
ル集合によってそれぞれ特性化された、いくつかの動作
モードを有する場合である。次いで、コンテキストメカ
ニズムは現在のモードと一致するルールのみが発火する
のを確認する。黒板アーキテクチャではこの特長はあま
り重要ではない。なぜなら、モード（コンテキスト）は
異なった知識源で連想づけることが可能だからである。
一方、コンテキストが有効な所には少なくとも２つの状
態がある、それはセンサが診断されるとき、及び満期回
数値（value expiration times）が残りのルールを実行
する前にチェックされるときである。すなわち、この
時、異なったデフォルト値の３つのコンテキストが与え
られるが、それは“診断センサ”、“満期回数チェッ
ク”、“通常”である。

【０３７３】手続きは、必要な全ての情報がオンライン
で入手できない状態で与えられる。多くの場合、厳格な
オンラインセンサ情報を使用するルールでは、競合仮説
を識別することが不可能である。実行の手続きはエンド
ユーザによって、手動で一連の動作をすることが要求さ
れている。その手続きの結果はその後ルールベースが仮
説を反駁あるいは増強するときに自動的に使用される。

【０３７４】汎用ルールは、“for all ... if ... the
n ”の形をしたルールである。多くのシステムでは、こ
れらの形のルールが実行時に動的にインスタンシェイト
される。しかし、オーバーヘッドが含まれているため、
これは必ずしも良い考えとはいえない。特に、リアルタ
イムシステムでは、これらのルールはルールベースの開
発時にインスタンシェイトされる必要がある。このこと
はまた、インスタンシェイト後、そのインスタンスの間
の相違が要求通りのわずかな相違であるように、アプリ
ケーション開発者がインスタンスを編集することが出来
るという、本質的な利点を与えるものである。さらに、
静的な実現の例では、一般的ではあるが採用しているシ
ステムが少ない“for all ... exept ... ”型のインス
タンスを削除することが可能である。

【０３７５】ルールマクロは汎用ルールと類似した概念
であるが、一つのマクロはいくつかの関係づけられたル
ールの集合であり、一方、一つの汎用ルールはたった一
つのルールしか含んでいない点が異なっている。他の相
違点は、ルールマクロはアプリケーション開発者が明白
に要求する特別な状況でインスタンシェイトされること
である。このように、ルールマクロは“for all ...
（rules ）”の形の汎用ルールとは論理的に等価ではな
い。ルールマクロは、ルールベースの一部がコピーを必
要とする状況で有効となる。この意味では、ルールマク
ロはコピーコマンドと同じ機能を持つ。その違いは、ル
ールマクロを編集するとき、編集による変化が自動的に
インスタンスに伝達されることである。

【０３７６】優先度と重要度は診断によって連想づけら
れるパラメータである。これらは、信頼度のレベルが高
い機能障害（malfunction ）を区別するのに必要であ
る。確信度＝１のこわれた熱電対と確信度＝０９のこわ
れた軸受は注意を要する点から見て、明らかに優先度が
違う。厳密な測定はまた、最大信頼レベルは、機能障害
がクリティカルになるずっと前にそのレベルに到達でき
るという事実を説明するのに必要とされる。上の例で
は、軸受はシャフトがこわれるずっと前にこわれるかも
知れないが、一方、数時間前にこわれた軸受には、数分
前にこわれた軸受よりも重大な機能障害があるかも知れ
ない。重要度はまた観測値が変化しつづけるとき、その
役割を果たす。たとえば、高温度が機能障害を確信度＝
１に導くかも知れない。温度上昇に伴って、機能障害の
重要度もまた増加するが、その確信度が１を超えること
はない。

【０３７７】行動（action）はルールの実行部（RHS ）
によって連想づけられる。既に論じたように、共通する
行動は、まだ名前はついていないが、更新仮説信念（up
date-hypothesis-belief）である。特に、他の行動の変
化はルールが発火されたとき実行される。それらの大部
分は、エンドユーザに対する表示の更新に関係する。た
とえば、新しい表示が始まったときなど色や数字が変化
する。大変有効な行動はメッセージ表示である。これは
ある事象が発生したとき、エンドユーザに対して表示さ
れるフリーフォーマット文である。一般的には、これら
は節点の確信水準が前もって定義された範囲内に入った
とき連想づけられる。

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

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

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

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

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

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

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

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

【０３８６】この研究が研究機関で続けられているうち
に、この概念の部分的なインプリメンテーションがここ
で試みられている。しかし（In particular ）、自動修
正及び自動修復はインプリメンテーションされない。な
ぜなら、これらの概念の自動化にはさらなる研究が必要
だからである（つまり、自動修正及び自動修復はうまく
動作しなかった）。そのかわりとして、以前成功（応用
例は補遺Ａを参照のこと）した単純な直線（straightfo
ward）アプローチが使われるだろう。このアプローチで
は、修正と修復はシステムユーザの責任とされている。
インデックス付けもまた一部はシステムユーザの責任で
あり、インデックス付けでは、ケースの定義付けに、ケ
ースを構成する変数（特徴）の定義が必要となる。この
アプローチは、ケースベース推論の完全な応用例とは考
えられていないため、ケースベース診断と称される。

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

【０３８８】知識源のそれぞれのケースは、アプリケー
ション開発者によって定義された汎用ケースフレームの
インスタンシェイトである。ケースフレームは変数をい
くつでも持つことが出来る。インスタンス（ケース）は
変数に値を割り当てることによって得られる。一方、知
識源のなかでは、全てのケースは同一フレームのインス
タンスとして定義されるので、表形式の蓄積方法は、ケ
ースメモリを選択するとき有効となる。加えて、時間の
概念が表現されなければならない。表を使用してこれを
実現した一例が図４４に示されている。表のそれぞれの
行は一つのケースフレームに該当する。列は、ケースを
形成する値を持つ変数に該当する。どの変数にも第三の
次元、時間がある。ケースの履歴値はこの次元にストア
される。この値は類似性測定アルゴリズムによって、現
在の履歴値と照合される。もし、変数に第三の次元がな
い場合、類似性は現在の変数と対照して測定されると仮
定されて、履歴は保存されない。

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

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

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

【０３９２】モデルベース モデルベース診断（MBD ）は、観測値（センサの測定
値）とシミュレーションモデルから予想される行動とを
比較するのに利用される。MBD の知識源に織り込まれた
知識は、モデル化されつつあるそれぞれのシステムのモ
ジュール部の入力／出力に関して関数関係となってい
る。センサなどからの観測値は知識源に対する入力デー
タの集合となる。探知された機能障害（malfunction ）
のため活性化されたとき、MBD の知識源は機能障害の原
因の可能性のあるリストを作るためシミュレーションツ
ールを使用する。

【０３９３】ドメインシェルのためにインプリメントさ
れるべきMBD フレームワークの型は、制限付き中断（co
nstraint suspension ）を伴なうシミュレーションであ
る。

【０３９４】制限付き中断は、工学的法則又は科学的法
則が適用されるシステムや、変数間に関数関係があるこ
とが知られているシステムのみに有効となるプラントド
メイン中の装置やプロセスは工学的法則が使えるように
設計されているので、この要求はプラントのいくつかの
システムに見ることが出来る。黒板アプローチの範囲で
はプラント全体の完全なモデルは必要でなく、アプリケ
ーションに組み込まれたどんなモデルでも利用すること
が出来る。もし、MBD フレームワークの中で診断が完全
に実行されないときでも、少なくとも部分的診断は実行
されて黒板に配置することが出来る。

【０３９５】ドメインシェルのために開発される、制限
付き中断を使用したMBD フレームワークについては、本
節で説明している。制限付き中断のWestinghouseでの詳
細例は、補遺B に図示されている。

【０３９６】制限付き中断法は相互連結モジュールやサ
ブシステムから構成されているシステムに応用される。
図４５に基本となる３つのモジュールシステムが図示さ
れている。それぞれのモジュールは関数関係で定義され
ている。これらのモジュールは、関数の入力（シミュレ
ーション関係）としてモジュール出力、及び残りの入力
／出力（推論関係）の機能として少なくとも１つのモジ
ュールの入力を与える。

【０３９７】推論関係の存在は、制限付き中断法に、内
部モジュールのＩ／Ｏ値を決定するための充分な手段を
与えるために重要である。与えらえたモジュールに適用
出来る関係の全集合は、モジュールの拘束として知られ
ている。

【０３９８】制限付き中断を使う必要性は、システムの
過大仕様（over-specification）による。つまり、シス
テム変数よりも自由な関係でなければならない。さもな
ければ、中断の制限は、システムの過小仕様（under-sp
ecification ）の原因となって、矛盾を見つけることは
決して出来ないであろう。この場合、どのモジュールも
矛盾の原因として除外することはできない。

【０３９９】ドメインシェルの範囲内で、開発者は黒板
の断片であるモジュラ−ブロックダイアグラムを生成す
るため及び拘束を定義するために黒板ツールを使用す
る。MBD 知識源を構成する事象や前提条件の一部分とし
て、開発者は、どの事象がモデルベース診断（MBD ）を
開発させるトリガとなるかを指示する。

【０４００】制限付き中断法は、特別なモジュールに対
して全ての拘束を中断することによって、失敗モードを
生成することが出来る。その他のモジュールに対する残
りの拘束は、出来るだけ多くの内部パラメータ値を決定
するために、測定されたＩ／Ｏ値と共に使用される。シ
ミュレーターとそのツールボックスは数学的処理を容易
にするために使用される。もし、シミュレーションの結
果生成された値に矛盾があった場合、拘束が緩和された
モジュールは失敗の候補とはならない。さもなければ、
そのモジュールは故障している可能性がある。

【０４０１】図４５で、もし、モジュールＡの拘束が中
断された場合、矛盾をさがすため、残りの拘束は測定さ
れたセンサ値と共に使用される。もし矛盾が見つかった
場合、モジュールＡは故障があるものとして除外され
る。この場合は、モジュールＡの故障は測定値からは説
明できない。続いて、もし、モジュールＢがテストされ
て無矛盾が完全に継承されていたならば、モジュールＢ
の故障は、測定されたセンサ値で説明することが可能で
ある。この方法で、故障している可能性のある関数のリ
ストを作成することが出来る。

【０４０２】ＭＢＤシステムでは失敗の発生が予想され
るモジュールをテストするには、テストの順番が必要と
なる。ドメインシェルの黒板アプローチではここに最大
の柔軟性が与えられているのに対して、他の知識源で
は、ＭＢＤ知識源がテストを受けるモジュールの順番を
決定する必要がある。このような指示がない場合、ＭＢ
Ｄ知識源はそれぞれのモジュールを系統的にテストする
（すなわち、徹底的な探索をする）。

【０４０３】診断の結果は、ユーザインターフェイスや
黒板に対して適切な指示を与えることが出来る。このこ
とは、ユーザまたは他の知識源が情報に従わなければな
らないことを示している。

【０４０４】インプリメンテーション 実行中に使用されている知識源の行動は、コントロール
モジュールに厳格に依存している。それにもかかわら
ず、次の実用上の仮定をおくことは妥当である、即ち、
ある知識源は真にリアルタイムで実行可能だが、その他
の知識源では不可能であるということである。これは、
診断プロセスを同レベルの２つに分解することにつなが
る。一方は完全にオンラインリアルタイムであり、一方
は本質的にオフラインである。このことは、ある種のエ
ンドユーザの相互干渉を意味する。オンライン知識源は
一般に、データ駆動型であり、そのデータはセンサから
入力されてエンドユーザとの対話はない。上で論じた様
々なタイプの中で、ルールベース型前向き連鎖と、いく
つかのケースベース知識源がこのカテゴリーに入る。こ
れらの知識源のリアルタイム（スピード）の効率向上に
多くの注意を払う必要がある。たとえば、コンパイラは
ルールネットワークとケーステーブルを、コンパクトで
効率的なメモリ常駐型データ構造に変換する。

【０４０５】オフライン知識源、特に、モデルベース知
識源は、他の知識源が停止した所まで継承する。知識源
はもっと詳細なレベルまで問題を調べることができる
が、巨大なプログラム空間を通常、詳細に探索するため
に、これには本質的に時間がかかる。このカテゴリーに
は、また、非常に多くのケースメモリを持つケースベー
ス知識源−本質的に検索時間が長い−、及びエンドユー
ザにコントロールされた後向き連鎖ルールベースモジュ
ールが含まれる。

【０４０６】シミュレータとシミュレーションツールボックス 前述した次の要求を考える； Ａ．テスト計画の初期データ集合に変動要因を記述する
ことによって、テストデータ集合を生成するための後戻
りアプローチの使用について。

【０４０７】Ｂ．黒板上のオブジェクトの入力／出力を
接続する特別な関数によって、オブジェクトの行動を記
述する方法を論じた。

【０４０８】Ｃ．ルールの条件部への代数演算子の適用
を論じた。

【０４０９】Ｄ．正常なオブジェクトの行動を記述する
関数が中断されて、オブジェクトの失敗したモード関数
と置き換えられた状態の、モデルベース推論アプローチ
について論じる。

【０４１０】これらには、全てに共通なある物がある。
すなわち、これらには複雑さの度合いの表現を評価でき
る手段が必要である。基本的な代数方程式、差分方程式
及び微分方程式が実行できる素関数を含むライブラリへ
のアプローチはそれ自身を連想づける。汎用手段ゆえに
他のモジュールにも使用可能なこのライブラリはシミュ
レーション用ツールボックスである。

【０４１１】ツールボックスのそれぞれの素関数は、処
理しようとする数字（または、ポインタ）を引数として
受け取って処理結果を返す、呼出し可能な手続きであ
る。関数の追加層は、違う種類の手続きの集合、すなわ
ち、引数が数字でなく、黒板領域を定義するオブジェク
ト／入力、オブジェクト／出力の集合、によって用意さ
れる。これらの手続きは、次いで適切な素関数をセット
アップし、呼び出すことによって、この黒板領域の行動
を、シミュレートする。黒板領域の一つのオブジェクト
と同じ大きさにもPART-O階層そのものの大きさにもなる
ことが出来る。この手順は事実上シミュレータとなる。

【０４１２】ハードウェア／ソフトウェア仕様 ドメインシェルの基礎となった技術的発展は、真のリア
ルタイム環境下での黒板アプローチの応用によるもので
ある。

【０４１３】ソフトウェア工学の観点から見ると、この
システムは、理解と認知のプログラミング言語と工学的
概念を広く使った、工業的標準マシン上の開発と操作に
関するエキスパートシステム技術を継承している。

【０４１４】コンピュータ ハードウェアの環境に関しては、Herlett-Packard/Apol
loワークステーション、HP9000、Series 700がソフトウ
ェアシステムのホストとして使われるであろう。アプリ
ケーション開発環境と実行環境は共にこのプラットフォ
ーム上で行われるであろう。しかし、ソフトウェアシス
テムの範囲には外部プロセスとの通信能力も含まれる。
その上、これらのプロセスにはドメインシェルとの通信
維持が可能なプラットフォームが接続される。これは、
現在と将来のプラットフォームの広範囲な両立性を確実
なものにする。

【０４１５】プログラミング言語の問題 序論で述べたように、エキスパートシステムの使用はプ
ラント環境で増えつつある。歴史的には、エキスパート
システムは知識表現に有利なLISPのような言語を使って
開発されてきた。だが、LISPは実行速度の点で効率が良
くない言語である。そのため、初期のエキスパートシス
テムではユーザの対話による質問・回答型環境は制限さ
れていて、そこには決定的な速度拘束は存在しなかっ
た。効率を改善するために特別なLISP専用マシンが開発
された。このようなLISP専用マシンをリアルタイムシス
テムに使うことは、一般には実行不可能である。環境の
本質的な時間依存性により、もっと高速なシステムを作
ることは必要である。従って、ここで述べたドメインシ
ェルはＣ及びＣ++またはそのどちらかを使ってインプリ
メントされるであろう。この改良によってのみ、エキス
パートシステムはリアルタイム環境で充分に早い動作が
可能となる。

【０４１６】移植性は、ＡＮＳＩ標準に準拠した言語
（ＡＮＳＩ−Ｃ）を使うことによって最大になる。

【０４１７】ソフトウェア開発の問題 Hewlett-Packard 社はUNIX-based（TM）オペレーティン
グシステムに組み込まれたソフトベンチ（SoftBendh ）
と呼ばれるソフトウェア開発環境を所持している。これ
はエディター、ビルダー、デバッガー、スタティックア
ナライザー、マネージャやその他のプログラマ用のツー
ルを備えた拡張性のある開発環境である。また、これに
はバージョンコントロールがあり、開発環境の標準とな
るであろう。

【０４１８】概念 図４６に全体のシステム動作についての詳細な概念図が
図示されている。さらに詳細な概念図は図４７に図示さ
れている。

【０４１９】入力／出力ファイル ３種類の入力ファイルがある。

【０４２０】黒板構造記述ファイル。

【０４２１】このファイルには黒板構造を構成するのに
必要な情報が含まれている。情報は基本的にオブジェク
ト名称と、それぞれオブジェクトの属性／値のペアで構
成されている。

【０４２２】ルールベース記述ファイル このファイルはルールベース知識源の体を形成するルー
ルの数を数え上げる。それぞれのルールベース知識源に
対して一つのファイルが存在する。それぞれのファイル
には知識源が起動される事象と前提条件の記述子が含ま
れている。

【０４２３】ケース記述ファイル このファイルは、ケースベース知識源の体を形成するケ
ースの数を数え上げる点を除いて、ルールベース記述フ
ァイルと同じである。それぞれのケースベース知識源に
対して一つのファイルが存在する。それぞれのファイル
には知識源が起動される事象と前提条件の記述子が含ま
れている。

【０４２４】入力データファイル このファイルは、シミュレートされたデータ集合を入れ
るのに使用する。それぞれの集合は、時間スタンプとセ
ンサ名称／センサ値のペアで構成されている。データ
は、ファイルの終了で停止するまで、診断サイクルを続
ける。

【０４２５】それぞれの入力データによって、システム
は二つの出力ファイルを作成する。診断ファイル このファイルには、さまざまなルールベース知識源によ
って生成された診断の分類リストが含まれている。それ
ぞれのリストの要素には、次のものが含まれている。

【０４２６】ランク番号（１、２、３、．．．．） ランク値（確信度の積、優先度と重要度） 診断の名称／テキスト 診断を引き起こす知識源の名称である。

【０４２７】さらに、このファイルには、ケースの分類
リストが含まれている。

【０４２８】それぞれのリストの要素には、次のものが
含まれている。

【０４２９】ケースのランク番号 類似性測定値 ケース名称 診断を引き起こす知識源の名称 黒板状態ファイル このファイルには、知識源の実行によって修正された値
が含まれているのを除いて、黒板構造記述ファイルと同
じ情報が含まれている。このファイルは次の実行サイク
ルでは黒板構造記述ファイルとして使われる。

【０４３０】入力／出力ファイルの正確な構文規則はシ
ステム設計タスクの一部分として決定される。

【０４３１】ユーザインターフェイス きわめて単純なユーザインターフェイスが与えられる。
システムがスタートしたあと、次のステップが発生す
る。

【０４３２】１．黒板構造記述ファイルの名称を得る；
ファイルの有無をチェックする。

【０４３３】２．知識源ファイルの名称を得る。

【０４３４】３．知識源がもう存在しないとユーザが言
うまでステップ２を繰り返す。

【０４３５】４．ファイルのローディングを開始する；
構文をチェックして、もしエラーがあったならメッセー
ジを表示してストップする。

【０４３６】５．ユーザに実行パラメータ（ステップ、
トレース、ブレークポイント等）をセットするよう要求
する。

【０４３７】６．データファイル名称を得る。

【０４３８】７．データをロードする；構文をチェック
して、もしエラーがあったならメッセージを表示してス
トップする。

【０４３９】８．ａ．ステップ５のパラメータセットに
従って診断を実行する。

【０４４０】ｂ．出力する ９．出力ファイル（入力ファイルと同じ名称を使うが、
拡張子OUT を付ける）に書き込む。

【０４４１】10．パラメータを変えるため、オプション
を表示して、システムをリセットする。

【０４４２】11．ユーザが止めるまで、ステップ６から
ステップ１０まで繰り返す。

【０４４３】ステップ８のｂはシステムの能力をよりよ
くデモンストレーションするのに必要である。他の出力
を受け取るソフトウェアは三菱が開発するであろう。情
報の正確な性質と様式は、通信手段と同様に、後ほど決
定される。

【０４４４】黒板 黒板は図４０に示すようにオブジェクト（フレーム）か
ら構成されている。図４０に示されている属性／値のペ
アに加えて、黒板オブジェクトは他の属性／値のペアを
持つことが出来る。プロトタイプにとって、ＩＳ−Ａと
ＰＡＲＴ−ＯＦの階層及びＬＩＮＫの接続性に関する記
述は、知識源によって使用されたという属性を持つオブ
ジェクトに関する要求ほどには重要でない。たとえば、
もし、ケースやルール内で、ある物理的オブジェクトの
温度に対して照合が行われるならば、物理的オブジェク
トのシンボル表現であるフレームは、温度に関する属性
を持つ必要がある。この属性は温度値−もし必要ならば
その履歴も含めて−をストアするときに使用される。

【０４４５】コントロールモジュール コントロールモジュールは、三つの主要部分から構成さ
れている（図４２参照）。

【０４４６】 コミニュケーション マネージャー／事象検知部 アクティベーション マネージャー アジェンダ マネージャー これらは開発環境のシステム動作が許される範囲内でイ
ンプリメントされる。事象検知部は、範囲外検知セン
サ、事象によって生成された知識源などの、小さな手続
きライブラリから取り出した事象フォームを使って事象
を生成する。バラバラに発生した（asynchronous）事象
は、ルールベースケースベース記述ファイルからの、類
似事象定義を満足する入力データファイルのデータ値を
使ってシミュレートされる。バラバラに発生した事象
は、また、ルールの実行部に定義されている行動（ジェ
ネレートイベント）を使ったルールベース知識源によっ
てシミュレートされる。

【０４４７】活性化マネージャーとアジェンダマネージ
ャーは、共同で待ち行列（FIFO）−知識源の前提条件が
一致したとき、システムオペレーションによって許可さ
れる−のように振る舞う。

【０４４８】知識源 本文の始めに述べたように、ある限定されたタイプのト
リガ知識源のみがインプリメントされる。さらに、二つ
のタイプ（ルールベース、ケースベース）がインプリメ
ントされる。この二つのタイプについては以下でさらに
論議される。

【０４４９】ルールベース ルールベース知識源フレームワークは、ここで述べるよ
うに、必ずインプリメントされる。このように、ルール
ベース知識源には、次に示す機能がある。

【０４５０】ルールベース木構造は、正確にはここで述
べられるようにノードは確信係数を、ルールは前回の十
分性係数及び必要性係数を持っている。

【０４５１】推論メカニズムは、ここで述べるように、
αβ遮断値を用いて探索木の枝刈りをふくむ前向き連鎖
動作モードを完全にインプリメントしている。自己修正
特性（メタルール）は、コンテキストや、ルールＳＦ’
ｓ及びＮＦ’ｓを変化させるためにインプリメントされ
る。

【０４５２】条件式（evidence expression ）も、ここ
で述べるように、インプリメントされる。リファレンス
章で述べたオペレータに加えて、もし、三菱によるシェ
ルの最初の応用によって要求されるならば、新しいオペ
レータが少数追加される。ユーザが定義したオペレータ
はプロトタイプではインプリメントされないだろう。区
分の必要条件として２種類のコンテキスト、すなわち
「診断センサ」と「正常」を設けよう。処理手続きはユ
ーザによるインターフェイスを必要とするから、それが
インプリメントされることはない。しかし、診断情報を
表示するための方法は、後で決められる。ジェネリック
ルールは、プロトタイプに対してインプリメントされな
い。優先度と重要度は完全にインプリメントされるであ
ろう。ルールの実行部に関する行動は、三菱が開発した
ユーザ用インターフェイスに対する情報出力の主要メカ
ニズムになるであろう。その情報の性質とフォーマッ
ト、ならびに交信手段は後に決められる。さらに非同期
事象をシミュレートするために、事象発生行動を行わせ
る。

【０４５３】ルールマクロ（rule macros ）はプロトタ
イプの場合はインプリメントされない。

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

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

【０４５６】性能測定 構成要素のフレームワークを形成する構造がコンパイル
されないという事実は特に重要な意味を持つ。性能なら
びにリソースの利用は、このコンテキストとだけ関係が
ある。実行時環境の場合は、性能ならびにリソースの利
用が大幅に改善されると予想される。

【０４５７】シェルの応用の可能性 応用を意図する分野はプラント環境である。その種の環
境の主要な二つの特性は、シェルの設計によって次のよ
うに具体的に配慮されている。

【０４５８】プラント環境の複雑さによって、包括的な
工場のモデルを開発する能力が限定される。コンピュー
タ技術の利用は、細分するやり方であれば可能であっ
て、プラントの特定分野に関する知識が何処まで利用で
きるかと関わりがある。その知識は、分析モデルからヒ
ューリスティックなモデルに至る範囲の様々な形式で存
在する。その複雑な問題と取り組む意図の下に、シェル
に様々な知識の規範を統合する能力が与えられる。

【０４５９】リアルタイムの操作は、プラント運転の刻
々変動する性格に基づいて生じた一面である。シェルが
時間の概念を取り込む能力を持ち、その性能が高けれ
ば、良く作成されたアプリケーションがエンドユーザに
時間と関連する情報を与えることができるようになる。

【０４６０】シェルの適用可能な特定分野を識別するこ
とはかなり難しい。それは、様々な複合工場に、しかも
リアルタイムで容易に適合できるような柔軟性をシェル
に持たせることを意図して、シェルの設計が行われるか
らである。適用可能度の問題は、次のように、異なる二
つの道筋から検討することができる。すなわち、シェル
が厳密に（as-is ベース）で作られていると見なされる
場合は、適用可能性は実際に存在する機能性によって制
限される。アプリケーション開発者は、シェルの適用可
能性を、当該問題の要求事項に合わせなければならない
し、さらに、当該シェルが持ち合わせない機能を必要と
する問題は決して扱わせないようにする必要がある。こ
のやり方は、シェルの使用に関する本来の方法ではな
い。

【０４６１】それに対して、現実の世界で、全てのアプ
リケーションがそれを特定化するために或る程度の開発
作業を必要とするという点が認識されている場合には、
シェルの応用可能度は大幅に拡大される。ソフトウェア
は拡張性を一つの目標として設計される。シェルが外部
のプログラムを使用できるようにすることと、新しい規
範を追加できるようにすることの両方が、比較的容易に
行えるようになれば、様々な規範を統合するシェルの能
力は一層強化される。それと同様に、エンドユーザ用イ
ンターフェイスをユーザの使用条件に合わせて修正する
能力を与えれば、ここで論議されている融通性が増加す
る。

【０４６２】以上を要約すれば、シェルの応用可能度を
限定する要素は、アプリケーションに注ぐ努力の多寡だ
けである。既存のシェルが、目前の問題を扱うには、不
適当であるが、基本のソフトウェアを変更しなくても新
しい機能性を追加できる場合には、そのシェルに新たな
規範を追加することは、設計だけで可能になる。

【０４６３】各種機能 シェルの主要な機能は監視と診断である。監視機能は、
情報を受取り、それをユーザに役立つやり方で表示する
能力である。

【０４６４】診断機能は、現存する不具合、または差し
迫った不具合の原因を識別する能力である。アプリケー
ション開発者の立場から見れば、シェルはアプリケーシ
ョン開発機能を持っている。その機能によって、開発者
は、前述の他の二機能をエンドユーザに対してどのよう
に働かせるかを決めるために使用する必要手段を与えら
れる。

【０４６５】エンドユーザの立場から見れば、シェルの
主要な機能は情報表示の一つである。表示されるデータ
は１次データ（シェルの外側から受け取ったもの）であ
っても良いし、２次データ（１次データの数値処理の結
果）であっても良いし、診断処理の結果（２次データの
特殊なもの）であっても良い。データも示し方が重視さ
れる場合は、シェルが、監視の網に掛かった情報と診断
結果の両方の表示を整備するための様々な方法をアプリ
ケーション開発者に与える。

【０４６６】シェルはデータ取得機能を持つように意図
されてはいない。もっと正確にいえば、シェルの外側の
システムによって収集されたデータを利用するために、
接続に役立つ各種手段を使用されることが期待されてい
る。本セクションが意図した読者はアプリケーション開
発者である。本セクションの内容は、アプリケーション
開発者の業務遂行を支援する方向に沿って作られてい
る。

【０４６７】それは、実行期間中のシェルの各種動作原
則について、それらが必要とされる条件を示してくれ
る。本セクションで説明した考え方を理解することは、
あらゆる開発作業の絶対必要条件である。開発開始前に
も本セクションを読むことが必要である。本セクション
の情報は、用語、基本的資源、開始手続き、各種の注意
事項と指針に基づいて、アプリケーション開発過程の概
観の与えるものであるから、一般的背景資料である。

【０４６８】本セクションは、アプリケーションの主要
構成要素、すなわち、黒板、制御、ルールベースの知識
源、ケースベース知識源、及びエンドユーザ用インター
フェイスの、新規作成と守勢に利用できる各種編集ツー
ルも扱う。

【０４６９】さらに、本セクションは、ソフトウェア開
発者がアプリケーション使用前に、それを部分的または
全体的に試験するために利用可能な手段についても説明
する。多くの補遺には、手続き上の各種機能、例えば、
シェル全体にわたって利用可能であり、使用される演算
子や処置が記述されている。それらは、別々にグループ
化されているが、その理由は、それによって、開発者が
もっと多くの機能を追加することができるし、あるいは
もっと追加しなければならない場合があるからである。
新たな機能が追加された時は、マニュアルの他の部分の
構成を乱すことなく、それらの補遺にその説明を織り込
むことができる。

【０４７０】動作原理 本セクションでのシェルの動作原理を説明する。もっと
正確にいえば、本セクションは、シェルのソフトウェア
によって明確化される考え方を示す。本セクションの内
容を理解することはアプリケーション開発者の必要条件
である。その一方、エンドユーザがそれらの考え方を完
全に理解することは不用である。ただし、拾い読みをす
ることは有益な場合がある。特に、診断機能については
それが当てはまる。

【０４７１】本セクションには、二つの部分がある。第
一は、シェルの基本構造の非常に広範な概観である。次
は、主要な構成要素の説明であって、アプリケーション
開発者の業務遂行を可能にするために充分な程度の詳し
さで述べられている。

【０４７２】基本アーキテクチュア シェルの基本設計によって黒板アーキテクチュアが実現
されるが、その中では全てのサブシステムが情報に関す
る共通のデータベース、つまり黒板の周囲を回転する。
その構造は、二種類のバージョン、すなわち実行時ソフ
トウェアと開発環境の形でインプリメントされる。実行
時ソフトウェアは、次に示す幾つかのモジュールで構成
される。

【０４７３】エンドユーザ用インターフェイスは、シェ
ルの監視機能を実行する。それは、様々なやり方、画
像、例えば図面またはディジタル化された絵画、グラフ
類、データの表等の形でエンドユーザに情報を見る能力
を与える。その情報は階層状に整備される。すなわち、
当該インターフェイスによって、エンドユーザは、選択
用メニュー（ポップアップ及びポップダウン）及び、一
つの画像表示の部分であって、他の表示内容とつながっ
ているホットスポットを経由して、目当ての情報に到達
することができる。それに加え、エンドユーザは、対話
用ウィンドウ経由で当該システムの他の部分に情報を送
り込むことができるし、あるいはメッセージ用ウィンド
ウ経由でメッセージを受け取ることもできる。

【０４７４】制御用ソフトウェアは実行中に行われる各
種活動を判断するが、それ故にあの主要な役割は診断機
能のために問題解決策をインプリメントすることであ
る。

【０４７５】知識源は、診断用知識をインプリメントす
るか、診断プロセスに全般的に役立つか、あるいはその
両方を行う。次の二種類の知識源がインプリメントされ
る。ルールベース知識源は、「従来方式」の前向き連鎖
信念伝播型エキスパートシステムの規範を与える。アプ
リケーション開発者は、連想づけられた信念レベルを用
いて、標準の「if-then 」形式でルールを書く。ルール
が発火すると、信念はルールの網を経由しながら伝播、
最後には、様々な診断内容に関する計算された信念度に
辿り着く。

【０４７６】ケースベースの知識源は、基本的な比較機
構の規範を与える。多くのアプリケーションでは、デー
タ中に或るパターンが発生することにより、特定の状態
が識別される。アプリケーション開発者はその状態とパ
ターンを具体的に決める。入って来るデータは、そのパ
ターンと比較され、データが、近似度について決められ
た基準の範囲内でパターンと適合する場合は、そのパタ
ーンで定義される状態が真であると判断される。

【０４７７】外部インターフェイスは、シェル自体の外
側のソフトウェアとの接続手段である。その種の外部ソ
フトウェアは、もしそれらを利用すれば、様々な機能、
例えばデータ源、専門化されたデータ表示、データの事
前処理等を行うことができるものである。さらに、外部
ソフトウェアは、全ての適切な約束事が守られるならば
知識源にもなり得る。

【０４７８】最後になるが、黒板は共通のデータベース
であって、それによって他の全構成要素が一つに結合さ
れる。黒板はシェルの外側から受け取ったデータ、なら
びに診断手続きの結果を含めて、シェルで生成された全
データの中央集積場所である。

【０４７９】開発環境は数系列のツールで構成される
が、それらによってアプリケーション開発者は、実行時
ソフトウェアを構成するモジュールの各々を作成し、試
験することが可能になる。それらのツールについては、
本マニュアルの後出のセクションで説明する。本セクシ
ョンの残りの部分で、運転時モジュールの基本動作を説
明する。

【０４８０】システムの動作 黒板 黒板はオブジェクトに関する総合的データベースであ
る。黒板のオブジェクトは大きく分けて二種類ある。特
定のアプリケーションの物理的実体の象徴的表現内容で
あるものと、抽象的概念を表すものである。前者は、一
般的に物理的オブジェクトに対応し、物理的オブジェク
ト間の空間的関係と機能的関係を記述することができ
る。後者は、一般的に抽象的情報であって、それは当該
システムのモジュール間で受け渡しされる必要がある。

【０４８１】黒板のオジェクトは属性を持ち、各属性は
一つの値を持つこともあれば、複数値を持つこともあ
る。すなわち、属性の一部は単値性と定義され、それ以
外の属性は多値性（リスト）と定義される。特別な属性
が二つあり、いずれのオブジェクトもそれらの属性を持
ち得るが（ただし、両方とも選択可能）、その特別属性
はIS-A属性とPART-OF 属性である。それらの属性によっ
て、黒板のオブジェクト相互間の関係が明確になる。す
なわち、特別属性は黒板のオブジェクトの階層組織を定
義するために使用することができる。

【０４８２】IS-A属性は、オブジェクトをクラスやタイ
プに区分する。IS-A属性は多値性、つまり、一つのオブ
ジェクトは一つ、または複数のクラス（またはタイプ）
に属することができる。IS-A属性の各値ごとに、逆の関
係であるHAS-INSTANCEが自動的に作成される。IS-A階層
の有益性は、黒板作成の過程で認められる。すなわち、
アプリケーションの一つのクラスに対して、いったん、
一組の基本的なオブジェクトが開発されると、それら
は、他の多くのアプリケーションの基本的な誤謬を形成
することが可能であり、従って、何度でも再使用でき
る。新たなオブジェクトの各々は、その際、自分の親
（単数または複数）の属性を継承する。親の属性の値も
継承される。それによって、開発手続きが大幅に簡略化
され、開発の能率が向上する。

【０４８３】PART-OF 関係は、物理的構造の非常に単純
な記述である。それはオブジェクトの合成を担当するだ
けであるが、複雑な構造を適切に分解するためには、そ
れで十分（しかも必要）である。PART-OF 属性は、単値
性であるが、それから自動的に作成される逆のHAS-PART
はもちろん多値性である。PART-OF 階層の第一の目的
は、エンドユーザが行く先を目指してシステムモデル内
を進む際に、そのユーザを一レベルずつ案内することで
ある。

【０４８４】IS-A及びPART-OF 属性に加えて、アプリケ
ーション開発は、他のあらゆる属性ならびにオブジェク
トに連想づけられた値を追加することができる。それら
の属性の一部のものは、知識源が必要とするものである
が、それ以外のものは、単に、「ワールド」モデルを完
成させるためにあった方が良いとされるものである。し
かし、新たな属性を動作時に追加することはできないこ
とに留意されたい。

【０４８５】刻々の変化に応じて値を受け取る属性は、
連想づけられた二種の実体を持つことができる。ヒスト
リーレングスはデータ量を、時間または値の個数の形で
特定するが、それは当該属性内に保持されるべきもので
ある。ディーモンスロットは、当該属性が新しい値を受
け取るたびごとに、実行されることになっている一つの
機能の名称を特定する。

【０４８６】実行時用黒板は、１台のマシーンだけに存
在することが許される。つまり、異なる数個のプロセッ
サのメモリ内に分散して存在することはできない。

【０４８７】制御機構 制御モジュールは、シェルの様々な部分の行動の調整を
担当する。その設計内容は、アプリケーション開発が、
次に示す特性を発揮するアプリケーションの生成に導く
制御動作を規定できるようになることを意図したもので
ある。

【０４８８】速度とは、或る任務を、全体に関係する制
御の応答必要度を最小限度に抑えながら、短時間に実行
する能力であり、適切な時点での反応が必要とされる
時、状況変化に反応する能力であり、必要とされる時点
までに結論（診断または部分的診断）に達する能力であ
る。適時力とは、状況変化に伴って対策を変更する能力
である。

【０４８９】上述の特性は、制御モジュールのソフトウ
ェアに初めから内蔵されているものではないことに留意
されたい。もっと正確にいえば、制御モジュールの特徴
を上手に生かすこと、さらに、それによって所要の結果
を達成することはアプリケーション開発者の責任であ
る。

【０４９０】速度は各知識源の個別的性能特性に強く左
右される。制御モジュールの寄与は全体的である。明白
なことだが、知識源実行に費やす時間に対する全体的制
御に費やす時間の比率を小さい値に保つ事が望ましい。
それを実現する一つのやり方は、全体的な関与を最小限
に抑えることであるが、それはある限度までしかできな
い。べつの方法は、知識源の情報単位の大きさを増やす
ことである。残念ながら、情報単位の大きい知識源は反
応しなくなる傾向がある。従って、知識源は割り込み可
能である。

【０４９１】割り込み可能性は、適応性に対しても役に
立つ。このアーキテクチュアは、本質的には事象駆動型
であるから、非同期的事象によって実行環境（コンテキ
スト）が、その時点で実行中の知識源が無関係である
か、または不適切であるという条件の範囲内で、変えら
れるようにすることは可能である。そうすれば、制御モ
ジュールは異常動作として、その時点の知識源を停止
し、他の知識源の実行を開始することができる。

【０４９２】割り込み可能性が働く場面は、非同期的事
象によってコンテキストが変えられた時、例えばその時
点で実行中の知識源の重要度が、別の知識源より低くな
ってしまった時に現れる。この事態は、各知識源に連想
づけられる優先順位の使用によって解消する。優先度が
上位のタスクであるという理由で割り込みをかけられた
知識源は、再開可能であると決められる。

【０４９３】シェルの制御機構の基礎的な面は、それが
厳密に条件駆動型であることである。それは次の二種の
動作モードを持つ。

【０４９４】１．データ駆動：知識源の実行を指導する
条件は、データの非同期的受信である。その場合のデー
タは、当該システムの外部から（通常はオンラインのセ
ンサーから）来る場合もあるし、別の知識源の実行結果
である場合もある。通常、指導条件を決めるのは単なる
データの受信ではなくて、もっと正確にいえば、受信し
たデータがいっそう具体的な条件、例えば、予め定めた
正常範囲からの逸脱という条件を満たすことである。

【０４９５】２．エンドユーザの要求あり：ある特定の
知識源の実行をもたらす条件は、エンドユーザの要求に
よって生じる。それが発生するのは、通常、質の高い起
動条件が判っておらず、従って、必ずエンドユーザの制
御に基づいて知識源を実行させなければならない場合、
または、条件の定義が不完全であって、エンドユーザ
が、その時点で進行中の診断プロセスに対して、或る特
定の知識源が役立ち得るということに疑念を抱く場合で
ある。

【０４９６】制御機構が動作するためには、次の情報が
必要である。

【０４９７】１．一つのプロセス（知識源または外部の
プロセス）を実行させる諸条件一式が必要である。働き
方についての説明上、それらの起動条件は二つのグルー
プに分けれる。つまり、事象及び前提条件である。その
二者の間の違いは人為的なものであるから、働き方が最
適になるように、起動条件を二グループに振り分けるこ
とは、アプリケーション開発者の責任である。

【０４９８】２．各プロセス（知識源または外部のプロ
セス）は、割り込み可能なものと、そうでないものと、
そのいずれかの性格を与えられなければならない。割り
込み可能な各プロセスは優先順位を持たなければならな
い。

【０４９９】３．割り込み可能な各プロセス（知識源ま
たは外部のプロセス）には、定義された再起動条件一式
を持たせても良いが、制御機構はそれらの条件によっ
て、割り込みをかけられた知識源を再活性化させるべき
か、それとも、当該割り込みの動作の完了にともないそ
れを打ち切るべきかの判断を下すことが可能になる。

【０５００】４．各プロセスは、時間がくれば止めるこ
とも、止めずにおくこともできる。時間がくれば止めら
れるプロセスの場合は、実行時を特定しなければならな
い。そして、その期限が来た時、そのプロセスを一時停
止するか、打ち切るか、または継続する。

【０５０１】諸条件の点検の仕方は、ルールベースの規
範に基づいて次のように考えることができる。

【０５０２】IF条件が真ならばTHEN実行せよ 制御ルールの左側の条件部は、複数のオペランドで構成
された式の形で表されるが、そのオペランドは、補遺Ａ
に記述されたデータポイント（黒板のオブジェクト／属
性として表される）及び演算子である。

【０５０３】右側の実行部だけがプロセスを活性化状態
に入らせることになるが、そのプロセスは一つの知識源
であっても良いし、外部のプロセスであっても良い。

【０５０４】制御機構は、次の数ステップの連続的反復
で構成される。

【０５０５】１．事象検知：黒板に向かって行くデータ
は全て、事象検知部モジュールを経由して進む。事象検
知部は、データバケットを一個受け取るたびに、当該バ
ケットの情報が関係する事象の前提条件の真否を検討す
る。真条件の各々に対して、それに対応するプロセス活
性化要求が次のステップに渡される。

【０５０６】２．活性化：ステップ１から受け取った要
求は、活性化マネージャモジュールによって処理され
る。真であると判定されたものは、さらに次のステップ
に渡される。

【０５０７】３．予定計画作成：ステップ２から来る要
求は、アジェンダマネージャが受け取る。このモジュー
ルは、その時点で実行中のモジュールの記録を保持して
おり、さらに優先順位に従って、新たに起こす要求の予
定計画を作成する。それによって、その時点の行動の一
時停止が必要になる場合がある。このモジュールは、一
時停止されたタスクを再開（再起動）するべきかどう
か、及び、進行中のタスクについて時間切れにするかど
うかの判断も下す。

【０５０８】始めの方法で述べたように、制御機構はそ
の大部分がアプリケーションごとに特定される。上に説
明した構造は、かなり一般的な性格を持っているけれど
も、各種のモジュールによって実行されるタスクは、ア
プリケーションごとに特定された多数の要素を含む場合
がある。その種の状況は常にあることだが、手続き的
（制御動作）方法と断定的（制御ルール）方法の混成を
使用するやり方が、将来、インプリメントされるであろ
う。

【０５０９】ルールベースの知識源 ルールベースの知識源は、IF...THEN...形式のルールを
インプリメントする。一般に、ルールは人間の体験獲得
型知識（経験則）を反映するように意図されている。実
際には、制限事項は全くない。IF...THEN...叙述で表現
できる知識であれば、どのような知識の「シャンク」で
も許される。

【０５１０】ここで論議されるルールベースの定形は、
標準的な生産システムではなく、OPS5スタイルに限られ
るものであることに留意されたい。そうではなくて、そ
れは信念型ルールベースの伝播であり、そこでは、推論
プロセスの第一の目的は、そのルールベースの結論中の
不確定要素を算定することである。それは、一つの分類
型プログラムでもあって、その中で起こり得る全ての結
果の優先順位を決めなければならない。さらに、ルール
記述のプロセスは、一つのルール網を作ることに等し
い。従って、ルールが先にネットワークを定義するので
あるから、ネットワークにルールを編入する必要はな
い。

【０５１１】ルール網は複数の入口（始端）と複数の終
了（終端）点を持つ。始点はデータがシステムに進入す
る点であり、終点は全てのルールが動作状態に置かれた
後に到達する結論である。通常、終点は現実の世界にお
ける障害に対応する。

【０５１２】シェルのこのバージョンに属するルールベ
ースの知識源は必ず前向き連鎖型（データ駆動）であ
る。後向き連鎖型（仮説駆動）バージョンは将来、追加
される可能性がある。

【０５１３】ルールベースの木状構造 ルールベースの基本構造は、もちろんルールである。そ
の最も単純な形式において、ルールは次のように定義さ
れる。

【０５１４】IF（条件式）THEN（仮説／実行） 条件式と仮説内容の各要素は、木状構造のノードに対応
する。ルール自体が、条件部における一個以上のノード
から実行部における一個以上のノードに向かう指定リン
ク（複数）を記述するフレームとしてインプリメントさ
れる。実行部は、当該木状構造の実際のノードに対応し
ない行動を取り組むことも可能である。

【０５１５】ノードの第一層はデータノード、つまり、
外部情報の当該ルールベースへの進入点である（通常は
センサーからのデータであるが、必ずそうとは限らな
い）。それと同様に、最後の層は終点、つまり部分的ま
たは最終的診断内容に対応する。それ故、最後の層のノ
ードの名称は障害である。

【０５１６】中間にあるノードの層は全て仮説、つま
り、示されている推論プロセスの中間ステップを表す。
最初と最後の層は、黒板のオブジェクトに関して、それ
と対等な属性を持たなければならない。中間層も、黒板
のオブジェクト中に書き込まれる可能性はあるが、オブ
ジェクトと対等の属性を持つ必要はない。上述のノード
に加え、他のノードも、変数と定数の値を保持する必要
のある可能性がある。様々な種類のノードの下位の基本
的な違いは、推論中に使用されるノードの数値に認めら
れる。データノード、変数、及び定数は無制限の浮動点
値を持つが、その値は、その値の起源によって異なる。
つまり、データノードは黒板からその値を受取り、変数
はルールベースにおける数値計算の結果としてそれを受
け取るが、定数は、アプリケーション開発者から与えら
れた値を持つ。実行中に定数の値を変える事はできな
い。その上、データノードは、他のデータノードのスト
リング値、または予め決められたストリングと比較する
目的でストリング値を持つことを許される。

【０５１７】仮説ノードと障害ノードは、確信レベルCF
という値を持っている。CFは実際には合成数で、信念の
尺度MB及び不信念の尺度MDと関わりがある。それらの関
係は次の通りである。

【０５１８】CF = MB - MD MBとMDは０（信念の完全な欠如、または不信念の完全な
不在）から１（完全な信念、または完全な不信念）まで
の範囲の値を取る。従って、CFは、−１（当該ノードは
誤りであるという絶対的確信）から＋１（当該ノードは
真であるという絶対的確信）までの範囲の値を取る。仮
説と障害は、CF、MB、MDが全て０に設定された状態から
出発する。それらの値は、その後、推論機構によって更
新されるが、それについてはこのセクションで後ほど説
明する。

【０５１９】ルールは同様の信念尺度を持つが、それら
は、充分性係数（SF）及び必要性係数（NF）と呼ばれ
る。充分性は、条件の真否（条件部）が仮説（実行部）
を左右する度合いを表す。つまり、充分性は、ルール自
体の真否に関する信念の尺度である。必要性は、誤った
条件が仮説の誤りに及ぼす影響、すなわち、仮説が真で
あるために、条件がどの程度、真でなければならないか
を表す。ノードと連想づれられる信念の尺度と異なっ
て、充分性係数と必要性係数は優先度の尺度であり、そ
れらはアプリケーション開発者及びドメインの専門家に
よって決められる。

【０５２０】アプリケーション開発者に、ルールの実行
に関する或る程度の管理権を与えるために、コンテキス
トが用意される。具体的にいえば、ルールのグループを
コンテキストと連想づけることによって、開発者は、そ
のようなルールのグループにシーケンス形式の実行を強
制することが可能になる。それによって或る一定の状況
における推論プロセスの能率が向上する。典型的な例と
して、一台のマシーンが数種類の動作モードを持ち、そ
れらのモードの各々が異なるルールの一組によって特徴
付けられている場合がある。その場合は、コンテキスト
構造によって確実に、その時点のモードの対応するルー
ルだけが発火されるようになる。或る黒板構造によって
確実に、その時点のモードに対応するルールだけが発火
されるようになる。或る黒板構造においては上述の特徴
はそれ程重要でないことに留意されたい。なぜなら、モ
ード（コンテキスト）が様々な知識源で連想づけられて
いることがあり得るからである。その一方、コンテキス
トが有用であり得る状況が、少なくとも二つある。すな
わち、センサを診断する必要がある時、または、ルール
（複数）の残りを実行する前に、値の有効期限の点検を
必要とする時である。それ故、必ずなければならない
「正常」コンテキストの他に、別の二つのコンテキス
ト、「センサ診断」と「有効期限点検」を定義すること
ができる。

【０５２１】推論機構 基本的な推論プロセスは、信念の計算と伝播で構成され
る。ルール発火は次のステップで構成される。

【０５２２】１．規則のコンテキストの検討結果が真で
あるかどうか調べよ。イエスの場合は先に進め。イエス
でなければ、本ルールを放棄し、コンテキストが変わる
場合は、後に試みよ。

【０５２３】２．ルールの条件が全部利用可能かどうか
（つまり、条件式に使われるノードが全部、それぞれの
信念を更新されていること）を調べよ。イエスの場合
は、先に進め。イエスでなければ、本ルールを放棄し、
もっと多くの条件が利用可能になった場合は、後に試み
よ（換言すれば、本ステップでは更新されていなかった
ノードが更新された時は、ルールが再度試みられる）。

【０５２４】３．ルールの条件CFを計算せよ（下の「条
件式」を参照されたい）。

【０５２５】４．仮説の確信レベルに対するルールの貢
献度を計算せよ（下の「ルールの貢献度の計算」を参照
されたい）。

【０５２６】５．ルールの貢献度が、α限界値とβ限界
値（マージン）で定義されるような、予め定めた或る幅
の中に収まっているかどうかを調べよ。イエスの場合は
先に進め。イエスでなければルールを放棄せよ。ルール
が、当該知識源の当該動作期間中に発火されることはな
い。

【０５２７】６．仮説の確信レベルを更新せよ（下の
「仮説の更新」を参照されたい）。

【０５２８】７．ルールで連想づけられる行動を全て発
火せよ（下の「各種行動」を参照されたい）。

【０５２９】以上を要約すれば、上述の必ず前向き連鎖
させる動作モードでは、データノードの値をそれに対応
する黒板のオブジェクト（通常はセンサの読みである
が、それに限定されるわけではない）から、抽出するこ
とによってプロセスが始まる。ルールの第一層は通常、
それらの値を、読みがハイ、ロー等である信念の所要位
置に記入する。信念はその時から、発火されていないル
ールが全部なくなるまで、上述のステップに従いなが
ら、ルールネットワーク（木）全体で伝播する。発火す
るルールの数は、当該ルールを活性化するために必要な
条件が真である程度に左右される。非常に幅が狭ければ
（例えば、「貢献度が０．８大きい規則だけを発火せ
よ」）発火数が減り、速度が向上する。その反面、診断
の見逃しが生じる可能性がある。なぜなら、一定の刻み
幅で行われる更新に対して、貢献度が相対的に小さけれ
ば、それは無視されるからである。幅を大きくすれば、
発火されるルール数が増加する。幅はルールごとに個別
に設定することができるが、そうする場合は、完全にア
プリケーション開発者の管理の下に、αβ型サーチ方法
を部分修正する必要が生じる。

【０５３０】条件式 信念伝播プロセスの一部として、推論プログラムは、当
該ルールの条件式の真理レベルを計算する。式の使用は
シェル全体に行き渡る。もっと詳細な内容は補遺Ａに示
されている。本セクションでは或る特定の情報だけを示
すが、それらはルールベース知識源での使用と特に関係
がある情報である。

【０５３１】一つのルールの条件部の式は次のように定
義される： （条件式）＝（＜演算子＞＜引数１＞．．．＜引数Ｎ
＞） 式は、括弧を用いながら接頭表記法または挿入表記法で
書くことができる。ルールによって使用される全ての式
については、検討結果として一個の真理値（確信レベ
ル）が求められなければならない。条件式はネストされ
た演算子から返されるデータの種類が所要の引数の種類
と適合する限り、どのように複雑であっても構わない。
演算子には次のような数種類がある。

【０５３２】代数型（例えば、加算、減算、乗算、除
算、負、絶対値、sin 、cos 、tan 、asin、acos等） ブール型（例えば、ファジーアンド、ファジーオア、加
重アンド、加重オア、ノット等）及び比較ブール型（よ
り小さい、等しい、より大きい） 時間ベース（例えば、トレンド、平均トレンド、時間に
よる平均、時間内最小値、時間内最大値等） 変化ベース；time-when 、value-when 引数も次のように数種類あり得る： 定数値（入力ノードの値、変数ノードの値、及び定数ノ
ードの値） 確信レベル（仮説ノードの確信レベル及び障害ノードの
確信レベル） 上記の一つをもたらす関数 その他の式（帰納的） 代数的演算子は検討結果として数を算出する引数を引き
取り、その数を返す。ブール演算子は、実際の信念伝播
プロセスにおいて使用されるものである。それらは自身
の引数の確信レベルを新たな確信レベルに結び付ける
か、または比較ブール型の場合は、比較の真理に関する
確信レベルを計算する。結合式は次の通りである。

【０５３３】 ファジーアンド：CF(A and B)=min ｛ CF(A),CF(B)｝ ファジーオア： CF(A or B)= max ｛ CF(A),CF(B)｝ 加重アンド： CF(A and B)=｛CF(A)*W(A)+CF(B)* W
(B)｝/ ｛W(A) +W(B)｝ 加重オア： CF(A or B)= max ｛CF(A)*W(A)+CF(B)
* W(B)｝ ノット： CF(not A)= -CF(A) 比較ブール型は、+1または -1 の信念を返す厳密な比較
であっても良いし、あるいは、その比較に或る程度のあ
いまいさを与えるために、マッピング（不連続線形）関
数を使用しても良い。

【０５３４】時間ベースの演算子は時間の観念をルール
ベースに組み入れる。それらの関数に対する引数の一つ
は必ず時間の変数であって、通常は時間間隔を特定され
る。例えばtime-min演算子は特定の時間間隔に対するノ
ードの最小値を見出す。それと同様に、time-mi-演算子
は最小ノード値が発生した時間を返す。ルール中で時間
ベースの演算子を使用することの派生的効果は次の通り
である。すなわち黒板の履歴長が或る時間間隔で特定さ
れている場合は（つまり、時間ベース演算子は、記録の
件数として黒板内で特定されている履歴長に対しては働
かない）、黒板内に充分な長さの履歴が保有されること
を、当該システムが自動的に保証する。しかし、非常に
古いデータ（例えば数週間、数年間）を参照するルール
が黒板を巨大なデータベースの変えてしまうことを防ぐ
ために、制限を課さなけれなならない。アプリケーショ
ン開発者は、自動的記憶量制限を考慮しなければならな
いが、それは時間に基づくもの（例えば、三日より古い
データを退避させるな）であっても良いし、格納条件に
基づくもの（例えば100Kバイトを越える記憶内容を使う
な) であっても良い。

【０５３５】変化ベースの演算子は、データ格納部を起
動しないことを除けば、時間ベース演算子と同様であ
る。変化ベース演算子は、その代わりに或る特定の変化
の最も近い発生時間、または最も近い発生時間における
値を記録する。変化とは或る式の真理値が真から誤の変
わること、またはその逆であると定義される。

【０５３６】ルールの貢献度の計算 条件部の条件式が、いったん結合確信レベルのCF条件を
もたらすと、その値は当該ルール自体の信念( 充分、S
F、または必要、NF）と結合され、その結果が当該ルー
ルの仮説の真理値を更新するために使われる。その結合
用アルゴリズムは次の通りである。

【０５３７】CF条件＞０（すなわち、条件が真）の場合
は、ルールの貢献度はルールのSFとCFの条件の積であ
る。SF＞０の場合は仮説MBが更新され、SF＜０の場合は
仮説MDが更新される。ルールの貢献度は必ず正である。

【０５３８】CF条件＜０（すなわち、条件は誤り）であ
る場合は、ルールの貢献度はルールのNFとCF条件の積で
ある。NF＞０の場合は仮説MDが更新され、NF＜０の場合
は仮説MBが更新される。ルールの貢献度は必ず正であ
る。

【０５３９】仮説の更新 或る仮説が唯一のルールによって支持される場合は、そ
の仮説の信念レベルは更新されるが、その更新は先ほど
のセクションで説明したように、当該ルールの貢献度の
値をその仮説のMBまたはMDに指定することによって行わ
れる。

【０５４０】二つ以上のルールが同一の仮説を持つ（一
定の刻み幅に基づいて得られた条件）時は、その仮説の
真理値は一定の刻み幅に基づいて更新されるが、その更
新は確率に由来するユニオン更新ルールを用いて、つま
り、次のように個別の貢献度を加えて、それからそれら
の積を引くことによって行う。

【０５４１】 信念i=信念i-1+信念ルール-i-(信念i-1*信念ルール-i) ただし、信念は先ほどのセクションで説明したように、
仮説MBまたはMDである。信念ｉは当該仮説の新たに算出
されたMBまたはMDの値である。信念i-1 は当該仮説のそ
の直前のMBまたはMDの値であって、当該仮説を支持し、
しかも既に発火している他のルールに由来するものであ
る。

【０５４２】信念-0は0.0 であり、信念i は、i 番目の
ルールの貢献度であって、先ほどのセクションで説明し
た通りに算出したものである。

【０５４３】メタルール 本推論機構の注目すべき点は、実行期間中に刻々の変化
に応じてルールベース自体を修正するルールを書くこと
が可能なことである。この特徴の代表的な使い方は、入
力データ自体の信用性を診断する（つまり、センサが劣
化または障害を起こしていないかどうかを判断する）こ
とである。当該入力データが満足するに足らないと判定
された場合には、それに応じて信念レベルが減らされる
ので、それによってシステム崩壊を避けるために適切な
性能格下げが行われる。

【０５４４】構造的には、メタルールは正規のルールに
類似している。すなわち、それは条件部の式と実行部の
部分を持つ。実行部はソースと呼ばれるが、評価を受け
る一つの式を含んでいる。その評価結果は、一つの選択
的不連続線形関数に渡される。その種の関数が存在しな
い場合は、その式の評価結果が直接使われる。関数が存
在すれば、その関数の適用結果が使われる。その結果
は、それから、当該ルールの実行部において特定された
実体内に入れられる。その実体は、ルールまたはコンテ
キストの名称を記載したターゲットリストによって記述
される。そのターゲットがルールである場合は、当該ル
ールのNFまたはSFを修正すべきかどうかが推論機構に判
るように、ターゲットスロットも特定されなければなら
ない。ターゲットがコンテキストである場合は、当該コ
ンテキスト値が変更される。当該ターゲットがルールで
ある場合は、SFスロットまたはNFスロットに入れられる
値の評価結果が -1.0 ないし+1.0の範囲内になければな
らないことに留意されたい。ターゲットがコンテキスト
である場合は、その評価結果は１または０でなければな
らない。

【０５４５】メタルールは或る一定の状況では有用であ
るが、注意して使用しなければならない。なぜならば、
それは強い派生的作用を持ち、それがルールベースの働
きに影響を及ぼすからである。メタルールがコンテキス
トを変更する時は、既に発火していてもそのコンテキス
トがその時点で真ではなくなったルール全部が「発火」
にされる（つまり、その効果が除かれる）からである。
当該プログラムは、その時、コンテキストが変更される
前に発火できなかったルールの再点検を、それらがその
時点でコンテキスト中にある可能性に関して行う。それ
と同様に、メタルールが或るルールのSFまたはNFを変更
する時は、そのルールの全ての効果が無効にされ、その
ルールは再度発火される。無限ルーブが取り込まれるこ
とを防ぐために、各メタルールは付属のカウンタを持
ち、それが当該メタルールが使われる回数を制限する。

【０５４６】評価部 ルール発火機構と類似しているが、ただし、信念伝播を
実際に行うことはない機構が単純な計算を行うために利
用可能である。この種類の「ルール」は評価部と呼ば
れ、これも条件部と実行部を持っている。条件部の式は
どのような式でも良い。すなわち、それはどのような値
でも評価可能である。その評価結果は、実行部に含まれ
るノード名称のバリュースロットに入れられるが、それ
は可変型ノードでなければならない。評価部が実行させ
られた後、その可変ノードは更新されたものとしてマー
クを付けられ、その結果後続のルール、メタルールまた
は他の評価部の条件部でそれの使用が可能になる。評価
部は本質的にはセット動作を行う。つまり、可変値を評
価式にはめ込む。

【０５４７】各種動作 行動は、ルール、メタルール、および評価部の実行部に
対応する。行動は、本来、手続きであり、従ってアプリ
ケーション開発者が特定の需要に合わせてアプリケーシ
ョンを作成するのに使われる。行動によって与えられる
機能は、それらがインプリメントされるソフトウェア上
にハードコーティングされる。行動は、アプリケーショ
ン開発者によって付加されることはなく、ソフトウェア
の開発者によって付加される。

【０５４８】ルールが発火すると、多様な行動が副作用
として走行する。現在の行動については、補遺Ｂで述べ
る。

【０５４９】優先度と重要度 優先度と重要度は、診断で連想づけられたパラメーター
であり、確信度レベルの高い障害を区別するのに必要で
ある。ＣＦが１の故障した熱電対とＣＦが０．９の故障
した軸受とは、注意を喚起する意味では同一の優先度を
持っていない。障害が深刻になるずっと前の時点に、確
信度レベルが最も高くなりうるという事実を記述するた
めに、重要度が必要となる。上記の例では、軸受は、軸
が故障するずっと前の時点に故障していたかもしれな
い。従って数時間の間軸受が故障していたことは、数分
間故障していたことよりも、ずっと深刻な障害なのであ
る。重要度も、やはり、数値が変化を続けた場合に活用
される。例えば、高温は、ＣＦ１の障害につながる恐れ
がある。温度が上昇を続けると、その状況の重要度も高
くなる。但し、ＣＦは１を上回ることはない。

【０５５０】ケースベース知識源 ケースベース知識源には、ケースベース推論の全概念が
部分的にインプリメンテーションされている。ケースの
自動修正および修復はインプリメントされていない。

【０５５１】ケースベース知識源の本体は、先に格納し
たケースの集合と、所定の状況に対する「近似度」によ
ってケースを分類する一連のアルゴリズムとで構成され
る。動作時、推論機構は、現在の「生」データと先に格
納したケースとを比較する。生データが、所定の「近似
度」基準内でケースデータと一致した場合には、そのケ
ースが示す状態は真であると推論される。

【０５５２】ケースの定義 各ケースは、アプリケーション開発者によって定義され
る一般的なケースフレームを裏付けるインスタンシエー
ションである。フレームは、任意の数の変数から成る。
変数に数値を代入することによって、インスタンス（ケ
ース）が求められる。知識源内では、ケースは全部、同
一のフレームを持つインスタンス例と定義される。ケー
スメモリを三次元的な表として考えることもできる。表
内の横列は、ケースフレーム一つに対応する。縦列は、
ケースを形成する数値を持つ変数に対応する。いかなる
変数も三次元すなわち時間を持つ。ケースの履歴値は、
この三次元方向に格納される。これらの数値は、類似性
測定アルゴリズムによって現在の履歴値にマッチされ
る。変数が三次元を持たない場合、類似性は、当該変数
の現在値に対して測定される。

【０５５３】各ケースのスコアの回数の測定値が生成さ
れ、各ケースのスコアの近似度は内部的に保持される。
これらの測定値を使用して、ケースが、有用かどうか、
修正を必要とするかどうか、もしくは除去されるべきか
どうかが判断される。

【０５５４】ケースの追加 理論的には、新規のケースの格納は、完全に自動化でき
る、あるいは、エンドーザーの管理に任される。本シェ
ルバージョンでは、新規のケースの格納は、部分的に自
動化される。知識源や外部プログラムは、ケースベース
知識源に対して、現在の数値をケースとして追加するよ
うに指示する。この時点から、ケースベース知識源は、
自動的にデータを検索し、ケースを構成し、ケースベー
スを修正する。

【０５５５】ケースベース知識源は、次の行動を実行し
てケースを追加する。まず、ケースフレームを検査し
て、当該ケースに含まれるオブジェクト属性は何かを判
断する。次に、知識源は、黒板から当該データを検索
し、検索したデータを使用して新規のケースを作成す
る。ケース数が最大数に達したら、予め定義したユーテ
ィリティ機能を呼出し、破棄すべきケースを固定する。
そのケースは消去され、新規のケースがケースベースに
追加される。

【０５５６】ケースのスコアリング 利用できるスコアの機構は数種類ある。次の四つの機構
について以下に更に詳細に考察する。

【０５５７】１．規模ベース ２．時間及び規模ベース ３．正確なマッチ ４．記号対記号規模ベーススコアリング このタイプのスコアリングでは、重み付け平均式を使用
する。数式では、標識１が、ケースを形成する変数を示
し、指標ｔが三次元、すなわち、時間を示す。比較関数
ｆは三種類ある。すなわち、equal-to（等しい）、ｇre
ater-than （より大きい）、及びless-than （より小さ
い）である。各関数には定数が付随している。これらの
定数は、スコアを判断する際に使用する区分的線形曲線
を規定する。また、定数をケース毎に設定してもよい。

【０５５８】時間−規模スコアリング 上記の規模ベーススコアリングでは、生データとケース
データとの完全な一致は、実用上ありえないとしてい
る。データの大きさを比較する場合には、ある程度の
「曖昧さ」が許容される。しかし、規模ベーススコアリ
ングは、同様なある程度の「曖昧さ」を時間の次元につ
いては許容しない。

【０５５９】状況によっては、時間軸方向にも柔軟性を
持たせることが望ましいこともある。ここで、センサＳ
が、Ｔ１時刻にＸ値を、Ｔ２時刻にＹ値を各々示し、Ｔ
１からＴ２までには、６０秒の間隔があるという事例を
考える。生データでは、６２秒後に、センサーＳは、Ｘ
値に達したがＹ値には達していないことになる。多くの
場合、２秒の差には大きな意味はない。従って、この事
例は、一致した事例と見なされる。

【０５６０】時間 規模スコアリングでは、ユーザは、
比較用に時間のウィンドウを指定できる。このウィンド
ウは、所定の時刻の前後の所定の秒数に対して設定され
る。データ源が、この時間のウィンドウに格納された一
つ以上の数値を持つ場合、比較に使われる数値は、次の
ように選択される。すなわち、 equal-to演算子の場合、ケース値に最も近い数値 less-than 演算子の場合、最小値 ｇreater-than 演算子の場合、最大値 演算予定数と同様、時間のウィンドウもケース毎に設定
することができる。

【０５６１】正確なマッチスコアリング 規模スコアリングと同様、このタイプのスコアリングも
equal-toとｇreater-than とless-than の演算子を使用
する。但し、「曖昧さ」は使用しない。演算子は全て、
別個のスコア０もしくは１を提供する。

【０５６２】記号対記号スコアリング このタイプのスコアリングによって、ストリングデータ
を比較することができる。ケースベースを開発する場合
に、アプリケーションの開発者はストリング対の表を定
義する。ストリングの一つはケースデータの可能な値を
表わし、もう一つのストリングはライブデータの可能な
値を表わす。このようなストリング対に対して、スコア
が定義される。あるケースを定義する場合に、記号対記
号の比較を表わすため、演算子記号が用いられる。実行
時中に特定のケースを評価する場合には、現在のストリ
ングの値とケースストリングの値を表中で探索する。対
が見つかった場合に、既に定義されているスコアが原ス
コアとして用いられる。求める対が表中に無い場合に
は、スコアはゼロとなる。

【０５６３】動作 特定の条件が真であることを単に検知するだけでは、そ
れは典型的に有用とはいえない。通常、ある条件が検知
された場合に、何らかの動作を遂行することが望まれ
る。したがって、データがケースに充分密接に適合して
いる場合に、ある特定の動作を遂行するためのメカニズ
ムが準備されている。

【０５６４】各ケースに対して、ユーザは一連の動作を
特定することができる。その各動作は、連想づけられた
最小スコアを持っている。あるケースに対して新しいス
コアが生じる場合には、その動作リストがテストされ
る。各動作について、各スコアが動作スコアよりも大き
い場合に、その動作が行なわれる。

【０５６５】外部インターフェイス シェルは組み込み式のデータ取得能力を全く持っていな
いので、全てのアプリケーションは外部ソフトウェアと
インターフェイスしなければならない。更には、シェル
そのものに対して外部にある他のソフトウェアを使用す
れば、シェルのパワーと機能性を著しく高めることがで
きる。

【０５６６】一般に、外部ソフトウェアのインターフェ
イスは、シェルを備えた呼び出しサブルーチンとアプリ
ケーション開発者が提供したソフトウェアとを連係させ
ることによって、作り出される。呼び出しサブルーチン
はコミュニケーションチャネルを初期設定し、データの
伝送および要求（受信）を行なう。外部ソフトウェアを
どのように取り扱うかを知らせるソフトウェアを提供す
ることは、アプリケーション開発者の責任事項である。
例えば、ここで、シェルがデータハイウエイを持つプラ
ントに配備され、またシェルを働かせるコンピュータが
ハイウエイドロップであると仮定しておこう。ハイウエ
イ上の情報にアクセスするためには、アプリケーション
の開発者は、ハイウエイドロップソフトウェアからデー
タを取り出すことのできる小さなソフトウェアを書き、
それを再フォーマット化し、シェルが提供した呼び出し
ルーチンによって黒板に送る必要がある。シェルからの
結果をデータハイウエイ上に戻す場合には、カスタムソ
フトウェアが、幾つかの装備済みの呼び出しサブルーチ
ンのうちの一つを使って、シェルからそれを要求し、そ
れを再フォーマット化し、ハイウエイドロップに渡す必
要がある。

【０５６７】もう一つの別の問題点は、外部ソフトウェ
アを知識源として使用したい場合である。知識源が、定
義によれば、シェルの制御モジュールの厳格な制御下に
あるという事実によって、状況は複雑化している。特
に、シェルは知識源の開始、中断、再開および停止を行
なわなければならない。シェルのソフトウェアは、この
場合、シェルの制御モジュールとインターフェイスする
ことのできるソフトウェアを、データ交換ソフトウェア
に追加して、装備する。これに関する補足的な要求条件
は、外部ソフトウェアが、シェルソフトウェアと連係し
ている場合には、それに従属するということである。

【０５６８】エンドユーザインターフェイス エンドユーザインターフェイスについては、アプリケー
ション開発者が全面的に特定する。入手可能なリソース
には、グラフィックス、グラフ、表、メニューおよび対
話／メッセージウィンドウズが含まれる。これらのリソ
ースは、手持ちのアプリケーションに適していれば、ほ
とんどどのようにも組み合わせることができる。さまざ
まなリソースによって表示されるデータは黒板データを
基礎とするものである。

【０５６９】アプリケーションの開発者には、一覧の階
層を確定することが要求される。各一覧には、黒板デー
タにマッピングされたリソースのある組み合わせが含ま
れる。エンドユーザは、その階層をたどることによっ
て、その時点で関心の有る如何なる情報にもアクセスす
ることができる。

【０５７０】アプリケーション開発者による概観 このセクションには、「アプリケーション開発環境」の
概観が含まれる。その目的は、ある一つのアプリケーシ
ョンを作成するのに開発環境がどのように利用されるか
について、読者に基礎的な理解を与えることにある。こ
こでは、シェル開発環境の若干部分に共通している特徴
について説明する。また、開発環境をスタートさせた
り、「最上位開発者ウィンドウ」を開いたりするのに用
いるコマンドについてもここで説明している。開発環境
中の特定のエディタの使用に関する詳細な情報について
は、本文書の後続の各セクションで示されている。

【０５７１】開発過程 「ドメインシェル」に対するアプリケーション開発の過
程には、エディタを通してシステムに情報を入力するこ
とも含まれる。この情報は、幾つかの形態で、即ち、ル
ールベースの知識源記述、ケースベースの知識源記述、
黒板の仕様書、エンドユーザインターフェイスの構成お
よびアプリケーション広域システム設定に含まれてい
る。開発者は、適当なシェルエディタを使って、この情
報を入手する。実際の開発過程は反復するものであるこ
とに留意すべきである。アプリケーションの個々の部分
のテストや修正の結果から学び取ることは、連続的に行
なわれる。アプリケーションが実際に使用された後で
も、その結果が分析され、そのアプリケーションが調整
されることがある。成功裡のアプリケーションを作成す
るためのこのような反復過程にとって、実際に開発者が
合理的な規模のステップインプリメンテーションを実行
することが重要である。開発者が、テストすることな
く、あまり多くの情報をアプリケーションに入れるなら
ば、テストの結果が理解できないほどに複雑になり、そ
のため、補修に困難をきたすことになる。

【０５７２】Ｘウインドウシステム 「ドメインシェル」（「開発環境」と「実行時環境」の
両者）のユーザインターフェイスはＸウィンドウシステ
ムの範囲内で動作する「モチーフウィンドウマネージ
ャ」に基づくものである。モチーフウィンドウマネジャ
ーは、シェルの様相や感じに責任を持つ。アプリケーシ
ョン開発者は、「モチーフ環境」内のサイジング、移
動、アイコン化およびウィンドウの閉止に関する標準オ
ペレーションに精通しているべきである。シェルと対話
するエンドユーザも、「モチーフ」スタイルのウィンド
ウについて幾らかの経験を持つべきである。

【０５７３】ドメインシェルウィンドウの基礎と用語 アプリケーションの開発過程においてディスプレイに現
われるウィンドウにはさまざまな多くのものがある。そ
れぞれのウィンドウは、開発者が特定のタイプの情報を
シェルに入力できるように設計されている。各ウィンド
ウの詳細については、本文書の残りの部分に記述されて
いる。全ての「ドメインシェルウィンドウ」に適用され
る一般定義（用語）は下記の通りである。

【０５７４】用語「ウィンドウ」は、コンピュータのデ
ィスプレイに現われる四角いボックスを指すのに用いら
れる。このボックスは、ユーザのための情報（テキス
ト、グラフ、表またはその他のグラフィックス）を含
み、ユーザに対しシェルの部分を記述するためのデータ
の入力（エントリフィールドあるいは選択ボックスを介
しての入力）を要求し、またはユーザに選択すべきオプ
ションを提供する（実行ボタン）ものである。

【０５７５】ユーザ（アプリケーションの開発者または
エンドユーザ）に、実行可能な行動項目リストを示すメ
ニューが表示される。アプリケーション開発環境におい
ては、開発者は、メニュー選択を通して次にどの部分の
環境を活性化させるかについてシェルに告げる。

【０５７６】用語「最上位ウィンドウ」は、シェル環境
の主要部分と関連した基本ウィンドウを指す。この最上
位ウィンドウは次に述べる目的に用いられる。即ち、こ
れらのウィンドウは、編集中あるいはテスト中の実体
（構成要素）の現状に関する情報を表示するものであ
る。例えば、アプリケーション開発環境において、最上
位ウィンドウは、目下編集中あるいはテスト中のアプリ
ケーションの名称、ならびに現在のディレクトリを示
す。また、最上位ウィンドウは、実行可能な全ての主要
な機能へのアクセスを開発者に与えるものである。この
アクセスは、ウィンドウの上側部分にリストアップされ
たプルダウンメニューの形で示される。全ての最上位ウ
ィンドウのレイアウトは、開発環境のオペレーション部
分の全てに対して同様になっている。このレイアウトお
よび関連のメニュー選択については、次のセクションで
説明する。

【０５７７】シェルに入力された情報は、開発者が作成
した実体の形で存在する。実体はアプリケーションの一
部として存在する特定のタイプの項目またはオブジェク
トである。実体の例としては、ルールベースにおけるル
ール、ケースベースにおけるケース、黒板におけるオブ
ジェクトおよび実行時環境における一覧が挙げられる。
実体はまた、ルールベースまたはケースベース、あるい
は全面的アプリケーションでもありうる。実体として定
義される内容は、現在活性化されているウィンドウ（ま
たはＵＮＩＸプロセス）に依存する。

【０５７８】「シェル開発環境」は、実体の作成と編集
が全てのタイプの実体にとって同様に行なわれるよう
に、設計されている。これは、エディタウィンドウと呼
ばれる特別なタイプのウィンドウを通して行なわれる。
エディタウィンドウは、実際には、対話式ウィンドウの
一型式である。これらの用語については、以下に定義す
る。

【０５７９】対話式ウィンドウは、ユーザが情報を入力
できるセクションあるいはフィールドを含むウィンドウ
である。但し、対話式ウィンドウは、ユーザに情報の入
力を要求しなくともよいものである点に留意する必要が
ある。対話式ウィンドウの範囲内で定義される全ての主
要な動作は押しボタンによって実行される。

【０５８０】各対話式ウィンドウには、採るべき動作を
特定するボタンが下側に配備されている。一般に、ウィ
ンドウに表示されている情報を開発者が受け取りたい場
合に、ポインタによって「オーケー」ボタンがクリック
される。ウィンドウに表示されている情報を開発者が利
用したくない場合には、「取消し」ボタンを使用する。
「ヘルプ」ボタンは、ウィンドウの目的に関する情報を
与えるテキストメッセージを提供する。

【０５８１】アプリケーション開発環境においては、開
発者が実体を作成し、編集することのできる対話式ウィ
ンドウが現われる。このような対話式ウィンドウはエデ
ィタウィンドウと呼ばれる。各エディタウィンドウは、
一連のデータフィールドを持つ形で存在する。これらの
データフィールドには、特定の実体を規定する仕様デー
タが詰まっている。開発者は実体を作成するために、こ
れらのデータフィールドを入力し、編集する。

【０５８２】エディタウィンドウについては、本文書の
後続の諸セクションで、多くの例が示されている。

【０５８３】一般に、開発者がエディタを使って行なわ
せることのできる動作は次のとおりである。実体の新し
いインスタンスの作成、現存する実体の編集、現存する
実体の削除および現在の実体の保存。これらの動作は、
特定のエディタウィンドウに現われるメニューを介し
て、開発者が選択する。

【０５８４】選択用リストはウィンドウの一型式であ
り、これは開発環境中に共通して現われる。この選択用
リストは項目リストを表示するために用いられる。リス
トアップされている項目は、シェル内に範囲を限定され
ている実体か、あるいはファイルでありうる。選択用リ
ストの目的は、実体の正確な名称を記憶することを必要
とせずに、開発者が特定の実体に迅速にアクセスするこ
とを可能にすることにある。この選択用リストと結びつ
いているものに、選択された実体により遂行できる一連
の動作がある。これらの動作はコンテキスト依存型であ
るが、一般には「削除」または「修正」といった編集動
作、あるいは一般的な選択動作（ＯＫまたはキャンセ
ル）である。

【０５８５】典型的な選択用リストの概観を図４９に示
す。一般に、前回入力された実体に上書きする結果とな
るような実体が作成された場合に、シェルの対話式ウィ
ンドウが開発者に注意を促す。これは、「警告ウィンド
ウ」と呼ばれる対話式ウィンドウの一型式である。開発
者は、その動作の認識を求められる。これは、不注意に
よる情報の喪失を防止するものである。これは対話式ウ
ィンドウとして現われる。更に先に進むには、「オーケ
ー」ボタンあるいは「取消し」ボタンを押さなければな
らない。警告ウィンドウの一例を図５０に示す。

【０５８６】編集ノート アプリケーション開発環境の範囲内に現われるエディタ
ウィンドウおよび対話式ウィンドウは多数存在する。起
こりうるオペレーションが多様性に富むにも拘わらず、
オペレーションを活性化するポインタの使用は一貫して
いる。

【０５８７】ポインタを用いたメニュー選択では、ダブ
ルクリッキングによって選択が活性化される。メニュー
選択はまた、ポインタを用いたシングルクリッキングに
よって強調することによっても活性化することができ
る。それから、ウィンドウに在る「オーケー」ボタンを
押すか、あるいは、キーボード上の入力キーを打つ。

【０５８８】開発者は、ポインタを移動させて、ウィン
ドウのいかなるデータ入力エリアにもテキストを入力す
ることができる。このテキストは、開発者の要望に従っ
て編集あるいは削除することができる。

【０５８９】ウィンドウでは、開発者が迅速に特定の項
目を選択できるように、押しボタン選択方式が用いられ
る。開発者は、ポインタを用いて適合するボタンをクリ
ックすることにより押しボタンのオプションを選択する
ことができる。

【０５９０】ウィンドウでは、開発者が選択用リストか
ら特定の項目を迅速に選び出せるように、ピックボタン
選択方式が用いられる。ピックボタンはデータ入力フィ
ールドと連係しており、ピックボタンを押すと、選択用
リストのウィンドウが開くようになっている。この選択
用リストには、データフィールド用の全ての現在許容さ
れる値のリストが含まれている。このリストは更新され
るもので、コンテキスト依存型である。即ち、このリス
トは動的に作成されることを意味している。例えば、開
発者がオブジェクト−属性を選択するためには、ピック
ボタンが尤も頻繁に使用される。黒板に現在確定されて
いるオブジェクト−属性のみがピック選択リストに表示
される。

【０５９１】開発者がある値をセット内のただ一つの値
に迅速に設定することができるようにするため、ウィン
ドウには無線ボタン選択方式が用いられる。ウィンドウ
には、ボタンと一緒に可能性のある各値が表示される。
ボタンがセットされると、オプションの値が適正にセッ
トされ、その他の値が排除される。

【０５９２】コマンドを実行するために提供された情報
が不十分なものであるという状況、あるいはデータに上
書きする可能性のある動作が要求されているという状況
を開発環境が検知した場合に、対話式ウィンドウが現わ
れる。この対話式ウィンドウは、シェルが所望の動作を
成功裡に実行することに失敗した場合に報告を行なうも
のであり、アプリケーション開発者はその失敗の原因を
矯正し、再び動作を試みなければならない。

【０５９３】クイックボタンは、開発者が開発環境のそ
の他の部分に迅速にアクセスするために用いられる。例
えば、黒板エディタを迅速に開くために、あるいは特定
の知識源エディタウィンドウからテストウィンドウに移
るために、クイックボタンが使用される。

【０５９４】実行開始 「ドメインシェル」のアプリケーション開発環境は、Ｕ
ＮＩＸコマンドラインがプロンプト状態のもとで、ａｐ
ｐｄｅｖと入力することによってスタートする。

【０５９５】プログラムがスタートした直後に、「最上
位の開発者ウィンドウ」により開発者が表示される。こ
のウィンドウには、開発者にとって利用可能な全てのオ
プションが含まれる。最上位の開発者ウィンドウの一つ
の代表例を図５１に示す。

【０５９６】アプリケーションメニュー アプリケーションメニューによって、開発者は新しいア
プリケーションを作成したり、古いアプリケーションを
開いたり、現在のアプリケーションを保存したり、ある
いは開発環境を退去させたりすることができる。

【０５９７】アプリケーション−新 新しいアプリケーションの作成を開始するために、新メ
ニュ選択が選択される。このメニューが選択された場合
に、対話式ウィンドウ（図５２）が開かれる。この対話
式ウィンドウには、アプリケーションのために特定され
るべきフィールドが含まれる。アプリケーションの識別
には、名称フィールドが用いられる。開発者は、ディレ
クトリ−そこでは、全てのアプリケーションシステムの
ファイルが「ディレクトリフィールド」に保存されるこ
とになっている−を特定する。「記述フィールド」は、
開発者がアプリケーションに関する簡単な記述を入力す
るためのものである。アプリケーションについての簡単
な説明とか開発者の名称といった情報はここに入れるべ
きである。

【０５９８】「オーケー」ボタンを押せば、シェルが、
特定されたディレクトリの有無をチェックして、初期の
アプリケーションシステムの情報をここに格納する。最
上位のアプリケーション開発ウィンドウの現在のアプリ
ケーション及び記述フィールドは更新される。

【０５９９】アプリケーション−開き オープンメニュ選択を閉じることによって、ウィンドウ
が開かれるが、そこには現在のディレクトリ内に存在す
る現在のアプリケーションの選択リストが含まれてい
る。これらのアプリケーションの一つは、開発者が所望
のアプリケーションの名称にダブルクリッキングするこ
とにより、あるいはアプリケーションの名称をデータ入
力ウィンドウに入力することによって、ディレクトリを
変更することができる。

【０６００】アプリケーション−保存 保存メニュー選択を選択すれば、シェルがアプリケーシ
ョンのための現在の仕様を保存する。この情報はファイ
ルに保存されるが、そのファイルは特定されたアプリケ
ーションディレクトリ内に格納される。

【０６０１】アプリケーション−閉じ クローズメニューを選択すると現行のアプリケーション
で連想づけられたすべてのファイルが閉じ、最上位の開
発者ウィンドウのフィールドからアプリケーション情報
を除去する。

【０６０２】アプリケーション退去 このオプションを選択すると、開発環境がクローズす
る。この選択は開発過程を終了させる。

【０６０３】構成要素メニュー この構成要素メニューにより、アプリケーション開発者
に現在のアプリケーションの特定部分の編集が可能にな
る。

【０６０４】構成要素−黒板 このメニュー選択を決めると、黒板のエディタが開始さ
れ、最上位のウィンドウが開く。黒板エディタは、オブ
ジェクト、属性及びアプリケーションの黒板を定義する
ことになる履歴長さを入力するために使用される。この
情報は読出し専用ベースで他の開発エディタに常時利用
可能である。開発環境の他の部分は黒板エディタを活性
化させるためのクイックボタンを持っていることに注意
されたい。

【０６０５】構成要素−ルールベース このメニュー選択をきめると、ルールベースエディタが
起動され、最上位のウィンドウが開く。ルールベースの
エディタはルールベースによる知識源を作成し修正する
ために使用される。

【０６０６】構成要素−ケースベース このメニュー選択をきめると、ケースベースエディタが
起動され、最上位のウィンドウが開く。ケースベースの
エディタはケースベースによる知識源を作成し修正する
ために使用される。

【０６０７】構成要素−制御 このメニュー選択をきめると、制御のエディタが起動さ
れ、最上位のウィンドウが開く。制御エディタはシステ
ムの構成要素（知識源及び外部過程）を定義し、優先順
位、事象、前提条件及び再発火ルールなどの制御要素を
作成し修正するために使用される。

【０６０８】構成要素−一覧 このメニュー選択をきめると、実行時環境のエディタが
起動され、最上位のウィンドウが開く。実行時環境のエ
ディタは、シェルのエンドユーザ（例えばプラントの操
作員）が見ることになる一セットのグラフ表示を作成す
るのに使用される。それはウィンドウエンドユーザが見
ることになる一覧、ウィンドウ及び一セットの可能な動
作を定義する。

【０６０９】試験メニュー 試験メニューにより、アプリケーション開発者は正しい
動作であることを証明するために、アプリケーションの
部分又はアプリケーション全体について試験が行えるよ
うになる。

【０６１０】試験−知識源 このメニュー選択をきめると、開発環境の知識源試験部
分が活性化される。知識源レベルでの試験により、開発
者は制御された条件下で知識源の動作を観測することが
できるようになる。

【０６１１】試験−システム このメニュー選択をきめると、開発環境のシステム試験
部分が活性化される。システムレベルでの試験は、制御
された条件下でアプリケーションの全体の動作を観測す
るために開発によって使用される。

【０６１２】試験−一覧 このメニュー選択をきめると、開発環境の実行時一覧試
験部分が活性化される。実行時一覧の試験は、一覧構成
情報を再調査し、特定のエンドユーザの一覧の外観を観
測することよりなる。

【０６１３】使用のための指針 ドメインシェルは利用できる多くの特徴及び選択肢を有
する。アプリケーション開発者の環境は種々のウィンド
ウを提示する。開発の多くの局面は直観的な動作を有し
ているが、開発が効率的に進行するためにアプリケーシ
ョン開発者が開発及び試験過程を理解することがなお必
要である。

【０６１４】複合的なアプリケーションを作成するため
に、開発者は予め計画され調整された方式で仕事をしな
ければならないであろう。適切に予備計画したタスクに
は、アプリケーションを開発する各個人に割り当てられ
るタスクを注意深く分割することが含まれている。特に
全ての開発者は、どのようにそのアプリケーションの部
分が残りの部分に適合し、かつ組み立てなければならな
い所要のエンドユーザインターフェイスが、いかに効果
的にエンドユーザと対話するかを理解すべきである。

【０６１５】何人かの開発者が同じアプリケーションに
ついて仕事をすることもあると思われる。バージョン１
はマルチユーザシステムでないことに注意されたい。従
って、開発努力の整合が成功を保証するために決定的に
重要である。特別に重要な二つの領域は黒板とアプリケ
ーション制御部である。黒板は基本的に共通のデータベ
ースであり、そこですべての開発者はたとえ読出し専用
ベースのみについても黒板エディタと相互に対話しなけ
ればならない。同様に制御目的のための知識源の優先順
位は制御エディタからすべての知識源へのアクセスを必
要とする。

【０６１６】開発環境は、実行可能な多重コピーの同時
実行を許可することによって、その構成要素の同時開発
を可能にする。

【０６１７】それはマルチユーザ環境ではないので、不
一致を防ぐための必要なロックアウト機構を含んでいな
い。従って黒板オブジェクトを削除しまたは再指名する
ために、開発者は他の開発者に対する黒板アクセスを
“凍結”すべきである。このことがおこる時には、黒板
エディタが解放されるまで黒板のデータ要素のチェック
は起こらないようにすべきである。エディタが知識源の
不一致をもたらすならば、この不一致は最終的にソフト
ウエアによって表示され、それは解消されなければなら
ない。

【０６１８】不一致の表示によっても、黒板削除はシェ
ルの多くの部分を無効にしうることがあるのは明らかで
ある。そのため開発者は黒板エディタに用心して取りか
かるべきである。

【０６１９】多重の開発者が存在することは、オブジェ
クト及び属性のための指名の取り決めを標準化すべきで
あることを意味する。もし知識源の開発者が新しい黒板
オブジェクト属性を作成することを試みて、それが既に
存在することを見出しただけであるならば、現オブジェ
クト属性が望ましいものであるか、それとも新しいもの
が必要であるかどうかを注意深く検討すべきである。厳
格な指名ルールを支援することは問題発生の可能性を減
らすものとすべきである。

【０６２０】複合的なアプリケーション開発は性能を最
高にするための試験及び調整を必要とする。試験及び進
行中の動作の結果についての討論及び分析は、インプリ
メントされる性能の向上を可能にする入力を提供するで
あろう。

【０６２１】黒板の開発 黒板は黒板エディタを使用することによって作成されま
たは修正される。黒板エディタは黒板データ構造体を作
成するために必要なすべての情報を特定するのに必要な
ツールを与えるものである。

【０６２２】実行開始 黒板の開発はアプリケーション開発過程の重要部分の一
つである。黒板エディタを使用する前に、アプリケーシ
ョン開発者は他のシェルモジュールによって必要とされ
るデータ（例えば知識源、制御、ユーザインターフェイ
ス）の良い概念をもつべきである。総合すると、このデ
ータは黒板の構造体をあらわす。黒板エディタはアプリ
ケーション開発者が必要な情報の入力を支援するために
設計され、開発者がまた黒板の機能自体を理解するなら
ば、その過程はより効率的に進行するであろう。

【０６２３】黒板エディタは、アプリケーション開発環
境の最上位のウィンドウから（図５１）、またはクイッ
クボタンにより、黒板オブジェクトへの参照がなされる
種々の他のエディタから呼出される。黒板エディタは、
編集プロセスが完了した時に開発者によってクローズさ
れる。黒板エディタを含む個々のウィンドウはまた既に
作成された黒板の部分を検査するためのブラウザとして
使用される。

【０６２４】黒板エディタの表示 オブジェクトメニューの表示 黒板エディタがメモリ内の黒板ファイルの読取りを完了
すると、黒板に機能ボタン「対象物」「コンパイル」及
び「退去」にそって含まれるオブジェクト名のメニュー
を含むウィンドウが表示される（図５３を見よ）。

【０６２５】オブジェクト名をクリックすると、オブジ
ェクトを選択する。「オブジェクト」をクリックする
と、「オブジェクトの修整」、「オブジェクトの削除」
及び「オブジェクトの付加」の行動メニューを呼び出
す。これらの行動の一つをクリックすると、選択された
オブジェクトについての行動を行う。デフォールト（二
重クリック）行動は「オブジェクトの修整」である。こ
れらの行動は下記に更に詳述される。「コンパイル」を
クリックすると、黒板をコンパイルする。「退去」をク
リックすると、黒板エディタをクローズする。

【０６２６】オブジェクト／属性／価値のウィンドウ オブジェクトが修正のために選択されるかまたは新しい
オブジェクトが入力されると、以下の項目を含むウィン
ドウが作成される（図５４参照）。

【０６２７】１．オブジェクト名のフィールド ２．オブジェクト及び機能ボタン「属性の追加」、「属
性の削除」及び「属性の修整」で連想づけられる属性済
名リスト ３．属性名及び経歴の長さのためのフィールドつきの属
性エントリ領域及び機能ボタン「属性ＯＫ」と「属性取
り消し］ ４．選択された属性及び機能ボタン「値の追加］、「値
の削除」及び「値の修正」で連想づけられる値のリスト
（もしあれば） ５．機能ボタン「オブジェクトＯＫ」、「オブジェクト
の取消し」及び「ヘルプ」。

【０６２８】オブジェクト名のフィールドはオブジェク
ト名の表示及びエントリのために使用される。属性リス
トは現在のオブジェクト用に定義されたすべての属性名
を含む。名称をクリックすると、その属性を「選択す
る」。ボタンの一つをクリックすると、選択された属性
について所定の行動を行う。「属性の追加」または「属
性の修正」を選択すると、属性エントリ領域を使用して
属性の作成又はその修正が可能になる。「属性の削除」
をクリックすると確認を要求する対話ボックスを表示す
る。

【０６２９】属性エントリ領域は属性名、履歴長及びデ
ーモンを表示し、または入力するのに使用する。領域に
含まれる属性情報が正しければ「属性ＯＫ」をクリック
すると、その属性が保存される。「属性取消し」のクリ
ックはエントリを中断する。値のリストは選択された属
性のために定義されたすべての値を含む。値をクリック
すると、その値を「選択する」。ボタンの一つをクリッ
クすると、選択された価値について所定の行動を行う。
「値の追加」または「値の修整」を選択すると、値の形
式（下記する）を使用して値の作成またはその修正が可
能になる。「値の削除」をクリックすると確認を要求す
る対話ボックスを表示する。

【０６３０】すべてのオブジェクト／属性／値の情報が
完全である時、「対象文ＯＫ」をクリックすると、オブ
ジェクトが保存される。「オブジェクト取消し」のクリ
ックは変更を中断する。

【０６３１】値のウィンドウ 値が追加または修整される時、値、タイプ及び時間表示
及び機能ボタン「ピック」、「ＯＫ」、「取消し」及び
「ヘルプ」を含むウィンドウを介して値が入力されまた
は表示される（図５５参照）。

【０６３２】値を追加しまたは修整する時、値、タイプ
及び時間表示は所定のフィールドに入力される。「ピッ
ク」ボタンはサポートされたタイプの選択リストを表示
する。「ＯＫ」のクリックは、値を保存してオブジェク
ト／属性／値の形式に戻す。「取消し」のクリックは、
値を保存することなしにオブジェクト／属性／値の形式
に戻す。

【０６３３】黒板エディタの機能 オブジェクトの修正 現行の黒板オブジェクトを修正するには、オブジェクト
メニュー中のオブジェクト名称をクリックしてオブジェ
クトを選択する。その後、“0bject (オブジェクト) ”
ボタンをクリックして、メニューから“Modify Objec
(オブジェクト修正) ”機能を選択する。これによっ
て、選択したオブジェクトのobject/attribute/value
(オブジェクト/ 属性/ 属性値) ウィンドウが表示され
る。属性リストは、選択されたオブジェクトに対して現
在定義されている全ての属性を表示する。属性入力エリ
アと属性値リストはまだ空(enpty) である。

【０６３４】オブジェクト名称は、黒板中の他のオブジ
ェクトで現在まだ使用されていないどんな名称にでも変
更することが出来る。もし、すでに使われている名称が
選択された場合、その名称は拒否される。属性と属性値
の処理手順については後述する。

【０６３５】修正の完了後、“Object OK(オブジェクト
ＯＫ) ”ボタンをクリックすることによって、修正内容
は黒板に保存される。“Object Cancel(オブジェクト取
消し) ”をクリックすることによって、これまでの修正
内容は全て取消される。

【０６３６】オブジェクトの削除 現行の黒板オブジェクトを削除するには、オブジェクト
メニュー中のオブジェクト名称をクリックしてオブジェ
クトを選択する。その後、“object (オブジェクト) ”
ボタンをクリックして、メニューから“Delete Object
(オブジェクト削除) ”機能を選択する。この機能は、
開発者の確認を要求する対話ボックスを表示する。“O
K”をクリックすると、オブジェクトは削除されて、オ
ブジェクトメニューに戻る。“Cancel (取消し) ”ボタ
ンをクリックすると、これまでの操作は全て取消され
る。

【０６３７】オブジェクトの追加 黒板にオブジェクトを追加するには、オブジェクトメニ
ュー中の“object (オブジェクト) ”ボタンをクリック
し、その後、“Add Object (オブジェクト追加) 機能を
選択する。空のobject/attribute/value (オブジェクト
/ 属性/ 属性値) ウィンドウが表示されるオブジェクト
名称フィールドにオブジェクト名称を入力する。もし、
その名称が他のオブジェクトに既に使用されている場
合、その名称は拒否されるであろう。属性と属性値の追
加については後述する。

【０６３８】オブジェクトの追加が完了したら、“Obje
ct OK(オブジェクト追加完了) ”ボタンをクリックする
ことによって、追加内容は黒板に保存され、オブジェク
トメニューにもどる。“Object Cancel(オブジェクト取
消し) ”ボタンをクリックすると、これまでの操作は全
て取消される。

【０６３９】属性の修正 選択したオブジェクトの属性を修正するには、まず、属
性リスト中の属性をクリックして希望する属性を選択す
る。その後、“Attribute Modify (属性修正)”ボタン
をクリックする。これは、属性入力エリア中の属性のデ
ータ及び属性値リストで定義された任意の属性値を表示
する。属性名称と履歴の期間は変更することが出来る。
もし、既に使われている名称が入力された場合、その名
称は拒否される。属性値の処理手順については後述す
る。

【０６４０】属性の修正が完了したら、“Attribute OK
(属性OK) ”ボタンをクリックすることによって、属性
は保存される。“Attribute Cancel (属性取消し) ”ボ
タンをクリックすると、これまでの操作は全て取消され
る。

【０６４１】属性の削除 選択したオブジェクトから属性を削除するには、まず、
属性リスト中の属性をクリックして希望する属性を選択
する。その後、“Attribute Delete (属性削除) ”ボタ
ンをクリックする。これは、開発者の確認を要求する対
話ボックスを表示する。“OK”をクリックすると、属性
は削除されて、オブジェクトフォームに戻る。“Cancel
(取消し) ”ボタンをクリックすると、これまでの操作
は全て取り消される。

【０６４２】属性の追加 選択したオブジェクトに属性を追加するには、“Attrib
ute Add(属性追加) ”ボタンをクリックする。開発者は
属性入力エリアに属性名称と履歴の期間を入力すること
が出来る。もし、その名称が現行のオブジェクト中の他
の属性で既に使われている場合、その名称は拒否され
る。履歴の期間を入力する時、履歴の型を選択するには
属性値か、セカンドラジオ(seconds radio) ボタンを使
用する。属性値の追加については後述する。

【０６４３】“Attribute OK (属性ＯＫ) ”をクリック
することによって、その属性は黒板に保存され、新しく
定義された属性が属性メニューに追加される。“Attrib
uteCancel (属性取消し) ”をクリックすると、入力は
取り消される。

【０６４４】属性値の修正 選択した属性中の現行の属性値を修正するには、まず、
属性値リスト中の属性値をクリックして、修正しようと
する属性値を選択する。その後、“Value Modify (属性
値修正) ”をクリックする。選択された属性値は、属性
値ウィンドウに表示される。任意のフィールドが修正可
能である。型のフィールドを修正する場合、“Pick (ピ
ック) ボタンをクリックすることによって、使用可能な
全ての型の選択用リストが表示される。“ＯＫ”をクリ
ックすることによって、修正した属性値は属性値リスト
に保存され、object/attribute/value (オブジェクト/
属性/ 属性値) ウィンドウに戻る。

【０６４５】属性値リストは、最も新しい属性値が最初
になるように年代順に常に保たれていることに注意して
ください。時間スタンプを修正することは、属性値リス
ト中の属性値を整理し直す原因となる。

【０６４６】属性値の削除 選択した属性から現行の属性値を削除するには、まず、
属性値リスト中の属性値をクリックして削除したい属性
値を選択し、次に、“Value Delete( 属性値削除) ”を
クリックする。開発者の確認を要求する対話ボックスが
表示される。“Confirm(確認) ”をクリックすることに
よって、属性値は削除されて、object/attribute/value
(オブジェクト/ 属性/ 属性値) ウィンドウに戻る。
“Abort(中断) ”をクリックすると、属性値を削除せず
に戻る。

【０６４７】属性値の追加 選択した属性に属性値を追加するには、“Value Add(属
性値追加) ”ボタンをクリックする。空の属性値ウィン
ドウが表示される。開発者はそれから、フィールドを埋
めることが出来る。“OK”をクリックすると属性値は保
存され、“Cancel (取消) ”をクリックすると動作は中
断される。

【０６４８】黒板のコンパイル 黒板の開発が完了したら、“Compile(翻訳）”機能を選
択することによって、開発時の表現から実行時の表現
に、黒板の変換が行われる。実行時の表現は、よりコン
パクトであり、他のシェル部品による、より早い蓄積と
検索が可能となる。

【０６４９】コントロールモジュールの開発 シェルの制御メカニズムの特定化は、コントロールエデ
ィタを使って行われる。コントロールエディタはシェル
の制御情報を特定化するのに必要なツールを備えてい
る。

【０６５０】実行開始 一旦、システムの構成部品（黒板、知識源、外部プロセ
ス）が定義されると、これらの行動の制御はアプリケー
ション開発で最も重要な局面となる。コントロールエデ
ィタを使う前に、アプリケーション開発者は、コントロ
ールプロセス及び知識源の対話について充分理解してお
く必要がある。コントロールエディタは、アプリケーシ
ョン開発環境(FIG.48)の最上位のウィンドウ、または知
識源エディタのどちらかからクイックボタンを通して呼
び出される。コントロールエディタはコントロールルー
ルを調べるためのブラウザ（拾い読み）用としても使用
される。

【０６５１】コントロールデイスプレイ コントロールデイスプレイは、プロセス（知識源、外部
プロセス）のリスト及びファンクションボタン＾System
( システム)", ＾Contorol rule ( コントロールルー
ル)", ＾Save (保存) , ＾Exit (退去)"から構成されて
いる（図５６参照）。プロセス名称をクリックしてプロ
セスを“選択”する。＾System( システム)"をクリック
して、“修正”、“削除”及び“追加”の機能メニュー
を呼び出す。これらの項目の一つをクリックすることに
よって、選択されたプロセスの機能が実行される。デフ
ォルト（ダブルクリック）機能は“修正”である。“保
存”のクリックは、システムプロセス表示の範囲内で保
存されなかったコントロール仕様をファイルに書き込む
効果がある。これらの機能のより詳細については、次に
与えられる。“退去”をクリックすることによって、元
の呼ばれた場所に戻る。

【０６５２】システムプロセスディスプレイ システムプロセスディスプレイは、プロセス（知識源ま
たは外部プロセス）のコントロール特性の追加、削除、
修正に使用される。ディスプレイは次から構成されてい
る（図５７参照）。

【０６５３】 １．プロセス名称、型及び記述の入力／表示エリア もし、新しいプロセスが追加された場合、フィールドは
空であり、ユーザが適当な情報をタイプすることが要求
される。プロセス名称は、制御情報（及びその他の情
報）がストアされる場所のファイル名称に使用される。
型（ルールベース、ケースベース、外部）は、ファイル
名称の拡張子(rb,cb,ep)を決めるのに使用される。

【０６５４】２．割込情報 もし、プロセスが割込状態になった場合、優先度レベル
を入力することが要求される。

【０６５５】３．中断情報 もし、プロセスがある時間間隔(some time interval)の
後、中断した場合、中断期間と、中断時（終了、中止
等）にとるべき行動がここで特定される必要がある。

【０６５６】４．起動制御情報は、"Event（事象）","P
reconditio（前提条件）",＾Refire（再発火）" 表現す
る三つのボタンのうち一つを押す( ＾Push")ことによっ
て入力される。これらのボタンのうち任意の一つを選択
することによって、表現エディタ画面が現れる（図示さ
れていない。セクション６、ルールベース開発、表現編
集を参照のこと）。前提条件と再発火条件はオプション
である（実行時には要求されない）。プロセスが定期的
に実行するために定義されるのを除いては、事象は定義
される必要がある。

【０６５７】５．機能ボタン“「保有」”、“「取
消」”及び“「ヘルプ」”コントロールルール開発上の注意 正しいコントロールルールの開発が、アプリケーション
が正しく機能するのを確実にするための、最も重要な行
動であることを、アプリケーション開発者は知っている
必要がある。次に述べる事柄は、コントロール戦略の開
発に当たって、開発者が知っているべき、より重要な見
方の一部である。

【０６５８】アプリケーション開発者は、これらの知識
源を活性化するため優先度を割り当てようとする前に、
知識源の動作を理解しなければならない。もし、完了ま
でに長時間かかるかも知れない知識源が高い優先度で特
性化されるならば、その知識源は他の全ての低い優先度
の知識源の実行を効果的に邪魔することができる。この
ような場合、中断(time-out)の特徴−他のプロセスに実
行のチャンスを与える−を使うことが大変望ましい。

【０６５９】また、トリガ表現を事象と前提条件に分割
することも重要である。これは、実行効率を大幅に改善
できる可能性がある。

【０６６０】ルールベースの開発 ルールベース知識源は、ルールベースエディタを使って
生成・修正される。ルールベースエディタは、ルールベ
ース知識源を生成するのに必要な全ての情報を特性化す
るために要求されるツールを備えている。

【０６６１】実行開始 知識源の開発は、アプリケーションの開発プロセスにお
いて重要な部分である。ルールベースエディタを使う前
に、アプリケーション開発者は、ルールベースを構成す
るルールについての概念をもつ必要がある。ルールベー
スエディタは、アプリケーション開発者が情報を入力す
るのを支援するために設計される。

【０６６２】もし、開発者がルールベースの機能自体を
理解しているならば、編集プロセスは、もっと早く進む
であろう。

【０６６３】ルールベースエディタは、アプリケーショ
ン開発環境の最上位の開発者のウィンドウからスタート
する（図５１）。ルールベースエディタは、編集プロセ
スの完了後、アプリケーション開発者によってクローズ
される。また、ルールベースエディタを構成する個々の
エディタウィンドウは、すでに生成されたルールベース
の一部を調べるためのブラウザ（拾い読み）としても使
用される。

【０６６４】ルールベースの開発 ルールベースの編集セッションを開始するために、開発
者は最上位の開発者のメニューから、選択肢＾COMPONEN
T-Rule Base" を選択する。これが選択されると、この
選択肢は、開発者のディスプレイ上の最上位ルールベー
スエディタウィンドウにオープンされる。これは図５８
に示されている。このウィンドウには、すべてのルール
ベース編集セッション用管理オプションが含まれてい
る。これらのオプションは、FILE（種々のルールベース
を使うための機能）、COMPONENT （特定のルールベース
の特定の部品を編集する）及びHELPである。また、TEST
及びCONTROL と呼ばれるクイックボタンある。前者は、
テストされるべきルールベースとテスト機能とを結合す
る。詳細はセクション９を参照のこと。後者は、コント
ロール編集機能に対する直接結合であり、セクション５
で述べられる。

【０６６５】ファイルメニュー もし、FILEを選択すると、次の選択肢が示されたドロッ
プダウンメニューが現れる、（新）（開），（削除），
（保存），（閉），（退去）。

【０６６６】ＦＩＬＥ−Ｎｅｗ（ファイル−新） New メニュー選択肢は、新しいルールベースの生成を始
める時選択される。このメニュー選択肢が選択される
と、対話ウィンドウが開かれる。この対話ウィンドウに
は二つのフィールドが含まれる。第一のフィールドは
“「名称」”、ルールベースを固定するために使われる
名称で満たされるべきフィールドである。第二のフィー
ルドは“記述”、ルールベースの趣旨の簡潔な記述で満
たされるべきフィールドである。もし、「ＯＫ」機能ボ
タンが押されたなら、新しいルールベースが生成され
る。このルールベースは、ルールベースエディタの最上
位ウィンドウにとって、現行のルールベースとなる。ル
ールベースの名称と記述は、このウィンドウの適切なフ
ィールドに表示される。

【０６６７】ＦＩＬＥ−Ｏｐｅｎ（ファイルオープン） Openメニュー選択肢を選択すると、現行のアプリケーシ
ョンの範囲内で定義された現行のルールベースの選択リ
ストを含んでいるウィンドウが開かれる。希望するルー
ルベースの名称をダブルクリックするか、あるいはデー
タ入力ウィンドウにルールベースの名称を入力すること
によって、これらのルールベースの一つを、編集するた
めに開くことができる。他のディレクトリ名称をダブル
クリックすることによって、ディレクトリを変更するこ
とができる。

【０６６８】ファイル−保存 保存メニューセレクションを選択することより、シェル
が現行のルールベースをルールベース記述ファイルに保
存する。

【０６６９】ファイル−クローズ クローズニューセレクションにより、現在のルールベー
スを閉じ、最上位のルールベースエディタのウィンドウ
の各フィールドからルールベースの特定データを削除す
る。

【０６７０】ファイル−終了 Ｅｘｉｔ（退去）を選択すると、ルールベースエディタ
が閉じる。

【０６７１】コンポーネントメニュー コンポーネントメニューから、開発者が現行のルールベ
ースのエディット特定部分にアクセスすることができ
る。

【０６７２】コンポーネント−定数 定数を作成するには、定数メニューセレクションを選択
する。定数メニューが選択されると、名称、オブジェク
ト、値、および記述の各フィールドを含む定数エディタ
ウィンドウがオープンする。オブジェクトフィールドに
は入力する必要はない。（オブジェクト属性と定数を連
想づけることにより、定数を黒板に記録することができ
る）。

【０６７３】コンポーネント−コンテキスト コンテキストを作成するには、コンテキストメニューセ
レクションを選択する。コンテキストメニューが選択さ
れると、名称、値、および記述の各フィールドを含むコ
ンテキストエディタウィンドウがオープンする。値フィ
ールドは二進数で選択するため、無線ボタンが一対表示
される（０か１の値で入力）。ウィンドウがオープンす
る際は、ディフォルト値として１が選択される。図６０
に、コンテキストエディタウィンドウを示す。

【０６７４】コンポーネント−データノード データノードを作成するには、データノードメニューセ
レクションを選択する。データノードメニューが選択さ
れると、名称、オブジェクト、および記述の各フィール
ドを含むデータノードエディタウィンドウがオープンす
る。図６１に、データノードエディタウィンドウを示
す。

【０６７５】コンポーネント−評価部 評価部を作成するには、評価部メニューセレクションを
選択する。評価部メニューが選択されると、名称、変
数、式、コンテキストおよび記述の各フィールドを含む
評価部エディタウィドウがオープンする。変数およびコ
ンテキストフィールドは、ピックボタンを使って入力で
きる。ピックボタンを押すと、使用可能な名称の選択リ
ストが表示される。式の場合は、式フィールドに直接に
式を入力するか、または、エディットボタンを押して、
式エディタにアクセスすることができる。図６２に、評
価部エディタウィンドウを示す。

【０６７６】コンポーネント−仮説 仮説を作成するには、仮説メニューセレクションを選択
する。仮説メシューが選択されると、名称、オブジェク
トおよび記述の各フィールドを含む仮説エディウィンド
ウがオープンする。オブジェクトフィールドを、入力す
る必要はない。図６３に、仮説ウィンドウを示す。

【０６７７】コンポーネント−障害 障害を作成するには、障害メニューセレクションを選択
する。障害メニューが選択されると、名称、オブジェク
ト、優先度および重要度の各フィールドを含む障害エデ
ィタウィンドウがオープンする。優先度および重要度の
フィールドは、必ず、０．０から１．０までの値を入力
する。図６４に、障害エディタウィンドウを示す。

【０６７８】コンポーネント−メタルール メタルールを作成するには、メタルールメニューセレク
ションを選択する。メタルールメニューが選択される
と、名称、ソース、目的リスト、目的スロット、目的関
数、コンテキスト、カウンタおよび記述の各フィールド
を含むメタルールエディタウィンドウがオープンする。
図６５に、メタルールエデイタウィンドウを示す。

【０６７９】目的リストの各入力には、関連するスロッ
トおよび関数がある。スロットに入力できる値は、Ｓ
Ｆ、ＮＦ、もしくは値である。ＳＦとＮＦは目的ルー
ル、また、値は目的コンテキストにしか、許されていな
い。

【０６８０】コンポーネント−P,ＷＬ（区分線形関数） 区分線形関数を作成するには、ＰＷＬメニューセレクシ
ョンを選択する。ＰＷＬメニューが選択されると、名
称、Ｘ−Ｙリスト、および記述の各フィールドをを含む
区分線形関数エディタウィンドウがオープンする。アプ
リケーション開発者は、区分線形関数のブレークポイン
トを示す一対の並べられた実数をＸ−Ｙリストに入力す
る。図６６にＰＷＬエディタウィンドウを示す。

【０６８１】コンポーネント−ルール ルールを作成するには、ルールメニューセレクションを
選択する。ルールメニューが選択されると、名称、動作
リスト、α、β、ＳＦ、ＮＦ、コンテキスト、および記
述の各フィールドを含むルールエディタウィンドウがオ
ープンする。条件式フィールドには、必ず、有効な式を
構文的に入力する。式エディタにアクセスするには、条
件式フィールドの次のＥＤＩＴボタンを使用する。仮説
リストには、ルールベースのすべての有効な仮設が含ま
れていなければならない。これらの仮説の追加や削除
は、リストの次の所定の動作ボタンにより可能である。
ルールエディタウィンドウを図６７に示す。図６８に
は、ルールエディタウィンドウに表示される各関連メニ
ューを示す。可能な動作に関しては、補遺Ｂに説明して
ある。

【０６８２】コンポーネント−変数 変数を作成するには、変数メニューセレクションを選択
する。変数メニューが選択されると、名称、オブジェク
トおよび記述の各フィールドを含むエディタウィンドウ
がオープンする。オブジェクトフィールドを入力する必
要はない。図６９に、変数エディタウィンドウを示す。

【０６８３】ツール 黒板チェッカ ルールベースの開発にあたって、入力ノード、中間ノー
ドおよび出力ノードとして使用するオブジェクト属性を
仕様化する必要がある。エディット中のルールベース
が、黒板の現在の状態に合致するように、ルールベース
エディタは、オブジェクト属性が入力された際に、それ
らが存在するか否かをチェックする。

【０６８４】黒板がエディットされている最中は、開発
者は、ルールベースで現在使用されているオブジェクト
属性を削除または再名称付けすることができる。ルール
ベースがエディット中でない場合は、不一致であっても
無視される。ルールベースがいったん起動すると、不一
致があると、エディタを介するか、あるいは、実行時の
環境に規定されるかして記録される。

【０６８５】ルールベーステスト ルールベールはその作成後、開発環境のＴＥＳＴ部分を
活性化させることにより、テストすることができる。操
作がしやすいように、最上位のルールベースエディタウ
ィンドウに、テスト環境の知識源部分を活性化するクイ
ックボタンが設けてある。このテストボタンを押すと、
現在のルールベースが「プリロードされた」状態でテス
ト環境を活性化させることができる。これにより、アプ
リケーション開発者は、作成したばかりのルールベース
を早速テストすることができる。知識源テスト環境の詳
細については本文に説明されている。

【０６８６】ケースベースの開発 ケースベース知識源は、ケースベースエディタを使って
作成または修正できる。ケースベースエディタは、ケー
スベース知識源を作成するために必要な全ての情報を指
定するのに必要なツールを提供する。

【０６８７】実行開始 知識源の開発はアプリケーション開発のプロセスの重要
な部分である。ケースベースエディタを使う前に、アプ
リケーション開発者は、ケースベースを構成するケース
の概念を持たなければならない。ケースベースエディタ
は、アプリケーション開発者が情報を入力するのを支援
するように設計されており、開発者がケースベースの機
能自体も理解していれば、編集のプロセスをよりスピー
ディーに進めることが可能となる。

【０６８８】ケースベースエディタはアプリケーション
開発環境の最上位のウィンドウから呼び出すことができ
る。ケースベースエディタは、編集プロセス終了後アプ
リケーション開発者によって閉じることができる。ケー
スベースエディタを構成する個々のウィンドウは、すで
に作成されているケースベースの各部を点検するブラウ
ザとして使うことができる。

【０６８９】アプリケーション開発環境の他の表示に比
較すると、ケースエディタ表示は幾らか複雑である。あ
るインスタンスでは、非常によく似た二つの表示があ
り、どちらの表示を使うかはどのスコア方法を選択して
いるかによって決まる。以後の説明において、「（規
模）」と記述される表示は規模と時間の長さのスコアの
ために使われる画面を指し、「（記号）」と記述される
ものは記号対記号スコアのために用いられる画面を指
す。ケースベース開発に含まれる２組のデータがある。
ケースフレームライブラリは、シェルの中の各ケースベ
ースの定義（フレーム）、特にオブジェ外属性を使って
ケースを表わすものに用いられるファイルである。この
シェルの中にはケースフレームライブラリは一つしか存
在しない。各フレームにおいては、対応するケースベー
スはそのケースフレームのインスタンシエイションを含
み、各インスタンシエイションが一つのケースを含む。
現在のデータはこれらのインスタンシエイションと比較
される。各ケースベースはそれ自身のファイル内に含ま
れている。

【０６９０】ケースベースエディタ表示 フレームライブラリ表示 ケースベースエディタが開始されると、そのフレームラ
イブラリの中の全てのケースフレームと、「枠」と「終
了」の機能ボタンを表示する領域を含む表示部が開かれ
る（図７０）。あるフレームをクリックするとそのフレ
ームを選択する。「フレーム」部分をクリックすると動
作メニュー：「フレーム修正」、「フレーム追加」およ
び「フレーム削除」が表示される。どれかの項目の一つ
をクリックすると、連想づけられた動作が行われる。デ
フォルト（ダブルクリック）は「フレーム修正」であ
る。「終了」をクリックするとケースベースエディタを
退去する。

【０６９１】フレームの表示 ケースフレームを追加または修正すると、選択されたフ
レームのために定義されたデータ源のリストと「ソー
ス」、「ケース」、「コンパイル」「記号」および「行
動」の機能ボタンを含む表示が開かれる。データ源をク
リックするとデータ源が選択される。「ソース」をクリ
ックすると行動メニュー：「ソース修正」、「ソース追
加」および「ソース削除」を表示する。ユーザがこれら
の項目のどれかをクリックすると、希望の行動が行われ
る。デフォルト（ダブルアクション）は「ソース修正」
である。「ケース」をクリックすると、現在のフレーム
に対するケースベース表示が呼び出される。「コンパイ
ル」をクリックすると、ケースベースの編集を行う。
「記号」をクリックすると、記号表表示を呼び出す。
「行動」をクリックすると、ケース行動表示が呼び出さ
れる。以下にこれらの行動の詳細を説明する。

【０６９２】データ源表示 データ源が追加または修正されると、オブジェクト、属
性および重み（図７２）の入力域を含む表示が開かれ
る。このデータ源が索引であることを示すボタンが設け
てある。「ピック」ボタンはオブジェクトと属性を選択
するボタンである。「ＯＫ」ボタンをクリックすると変
更を保存し、「取消」はその変更を中断する。

【０６９３】記号表の表示 記号表表示、（図７３）は記号対記号比較演算子と「記
号」、「リターン」機能ボタンを使ってスコアするとき
に使われる全ストリングペアのリストを含む。最初の欄
はあるケースデータが持つことができるストリングを含
み、２番目の欄はあるライブ値を持つことができるスト
リングを含み、３番目の欄はそれらの組み合わせのスコ
アを含む。「記号」をクリックすると行動メニュー：
「記号修正」、「記号追加」および「記号削除」を表示
する。ユーザはこれらの項目のどれか一つをクリックし
て所望の行動を行う。「リターン」ボタンをクリックす
るとフレームの表示に戻る。

【０６９４】記号表示 記号を追加または修正するときは、ケースストリング、
ライブストリングおよびスコア（図７４）の入力域を含
む表示が開かれる。「ＯＫ」ボタンをクリックすると、
その変更を保存し、「取消」はその変更を中断する。

【０６９５】ケース行動表示 ケース行動表示（図７５）は、現在のケースフレームに
定義された行動リストと並んで各行動が行われるスコア
と機能ボタン「行動」と「リターン」を表示する。「行
動」をクリックすると行動メニュー：「行動修正」、
「行動追加」および「行動削除」を表示する。ユーザは
これらの項目のどれかをクリックして、希望の機能を働
かせる。「リターン」ボタンをクリックすると、フレー
ム表示に戻る。

【０６９６】行動表示 行動を追加または修正するときは、行動表示が表示され
る。この表示は、行動入力域（「ピック」ボタンを使
う）と行動が行われるスコアを含む。「ＯＫ」ボタンを
クリックすると変更を保存し、「取消」は変更を中断す
る。

【０６９７】ケースベース表示 ケースベース表示を選択すると、ウィンドウ（図７７参
照）一杯に、選択したケースフレームに定義されたケー
スのリストと機能ボタン「ケース」と「リターン」が表
示される。あるケースをクリックするとそのケースが選
択される。「ケース」をクリックすると行動メニュー：
「ケース修正」、「ケース追加」および「ケース削除」
が表示される。ユーザはこれらの項目のどれかをクリッ
クして選択したケースベースで希望する行動を行う。デ
フォルト（ダブルクリック）行動は、「ケース修正」で
ある。「リターン」をクリックするとフレームの表示に
戻る。これらの行動の詳細は以下に説明する通りであ
る。

【０６９８】ソース選択表示 ケースを追加または修正するときは、ソース選択表示が
示され（図７８参照）、ユーザは修正するデータ源を選
択できる。この表示は現在のフレームに定義されたデー
タ源のリストと機能ボタン「リターン」と「取消」を含
む。データ源をクリックすると、そのソースが選択さ
れ、ケースデータ表示を呼び出す。「リターン」をクリ
ックすると、ケースベース表示に戻る。「取消」でも同
様にケースベース表示に戻れるが、ケースデータになさ
れた変更は中断となる。

【０６９９】これはフレームライブラリで連想づけられ
たデータ源表示と違うことに注意すべきである。処理の
この段階では、ユーザは決してデータ源リストを変更す
ることはできない。このリストはデータ源を選択し、そ
のケースデータを各データ源に結びつけるためだけに用
いられる。

【０７００】ケースデータ（Ｄａｔａ）表示 あるデータ源を選択すると、選択されたソースに定義さ
れた値のリストと機能ボタン「値」と「リターン」を含
む表示が開かれる。ある値をクリックすると、その値が
選択される。「値」をクリックすると、行動メニュー：
「値修正」、「値追加」及び「値削除」が表示される。
ユーザはこれらの項目のどれかひとつをクリックし、希
望する行動を行う。デフォルト（ダブルクリック）行動
は「値修正」である。「リターン」をクリックすると、
ソース選択表示に戻る。これらの活動の詳細は以下に説
明する通りである。

【０７０１】ケースデータ（Ｄａｔｕｍ）表示 あるケースデータを追加又は修正するときは、入力域と
機能ボタン「ＯＫ」と「取消」を含む表示が開かれる
（図８０）。入力域では、値の種類（「ピック」ボタン
を使うことができる）、値、時間スタンプおよび重みを
選択できる。これらの他に、スコア演算子と演算子固有
値を入力しなければならない。詳細は以下に述べるとお
りである。

【０７０２】ケースベースエディタ機能 ケースフレームの修正 ケースフレームを修正するには、フレームライブラリ表
示中の希望するフレームをクリックして修正するフレー
ムを選択する。次に「フレーム」ボタンを押し、メニュ
ーから「修正」を選択する。すると選択されたフレーム
がフレーム表示の中に表示されるはずである。修正が完
了したら、「リターン」ボタンを押してフレームライブ
ラリ表示に戻る。

【０７０３】ケースフレームの追加 ケースフレームを選択するには、フレームライブラリ表
示の「フレーム」ボタンをクリックし、メニューから
「追加」を選択する。フレーム情報を入力できる空白の
フレーム表示が現れるはずである。作業が終わったら
「リターン」ボタンをクリックしてフレームライブラリ
表示に戻る。

【０７０４】ケースフレームの削除 ライブラリからケースフレームを消去するには、フレー
ムライブラリ表示を開き、希望するフレームをクリック
する。次に「フレーム」ボタンをクリックし、メニュー
から「消去」を選択する。対話ボックスが表示され、確
認を要求する。「ＯＫ」をクリックすればフレームが消
去され、「取消」をクリックすればその作業は中断とな
る。

【０７０５】データ源の修正 データ源を修正するには、フレーム表示の中の希望する
ソースをクリックして修正するソースを選択する。次に
「ソース」ボタンをクリックし、メニューから「修正」
を選択する。選択されたソースがデータ源表示の中に現
れる。修正が終わったら、「ＯＫ」ボタンをクリックし
てフレーム表示に戻る。「取消」をクリックすればその
作業は中断となる。

【０７０６】データ源の追加 データ源を追加するには、フレーム表示の「ソース」ボ
タンをクリックし、メニューから「追加」を選択する。
ソース情報を入力できる空白のデータ源表示が現れる。
作業が終わったら、「リターン」ボタンをクリックして
フレーム表示に戻る。

【０７０７】データ源の削除 データ源を消去するには、フレーム表示を開き、データ
源リストの中の希望するオブジェクト／属性をクリック
する。次に「ソース」ボタンをクリックし、メニューか
ら「削除」を選択する。対話ボックスが表示され、確認
を要求する。「ＯＫ」をクリックするとデータ源が削除
され、「取消」をクリックすればその作業が中断とな
る。

【０７０８】記号ペアの修正 記号ペアを修正するには、記号表表示の中の希望するペ
アをクリックして修正するペアを選択する。次に「記
号」ボタンをクリックし、メニューから「修正」を選択
する。選択されたペアが記号表示に表示される。修正が
終わったら、「ＯＫ」ボタンをクリックして記号表表示
に戻る。「取消」をクリックすれば、その作業は中断と
なる。

【０７０９】記号ペアの追加 記号ペアを追加するには、記号表表示の「記号」ボタン
をクリックし、メニューから「追加」を選択する。スト
リングおよびスコア情報が入力できる空白の記号表示が
現われる。作業が終わったら「ＯＫ」ボタンを押して記
号表表示に戻る。

【０７１０】記号ペアの削除 記号ペアを削除するには、記号表表示へ行き、希望する
ペアをクリックする。次に「記号」ボタンをクリック
し、メニューから「削除」を選択する。対話ボックスが
現れ、確認を要求する。「ＯＫ」をクリックするとデー
タ源が削除され、「取消」をクリックすれば作業が中断
となる。

【０７１１】ケース行動の修正 ケース行動を修正するには、ケース行動表示中の所望の
行動をクリックすることにより、修正さるべき行動を選
択する。選択された行動が行動表示に表示される。修正
が終了すると、「ＯＫ」ボタンをクリックし、ケース行
動表示に戻る。「取消」をクリックすると作業を中断す
る。

【０７１２】ケース行動の追加 選択されたケースに行動を追加するには、ケース行動表
示の「行動」ボタンをクリックする。ケースデータが入
力できる空の行動表示が現れる。「ピック」ボタンが行
動を入力するのに役立つ。完了すると、「ＯＫ」をクリ
ックしてその行動を保存する。「取消」をクリックする
と、作業が中断する。

【０７１３】ケース行動の削除 選択されたケースから行動を削除するには、先ずケース
行動表示中の入力にクリックすることになり、所望の行
動を選択し、次いでメニューから「行動」をクリックし
て「削除」を選択する。対話ボックスが表示され確認を
求める。「ＯＫ」をクリックすると、行動が削除され、
「取消」をクリックすると、作業が中断する。

【０７１４】ケースの修正 現在のケースベースの中のケースを修正するには、ケー
スメニューの中の入力をクリックする事によって希望す
るケースを選択する。次に「ケース」ボタンをクリック
し、メニューから「修正」を選択する。すると、ソース
選択リストが表示され、その中から修正するデータを選
択できる。ケースデータの処理は以下に説明する通りで
ある。

【０７１５】この方法ではケースデータのみが変更でき
ることに注意されたい。データ源行動および記号の修正
はケースフレームを編集して行わなければならない。

【０７１６】ケースの追加 現在のケースベースに新しいケースを追加するには、
「ケース」ボタンをクリックし、メニューから「追加」
を選択する。ソース選択リストが表示され、ユーザは追
加する最初のデータ源を指定することができる。ケース
データの処理方法は以下に説明する通りである。作業が
終わったら、「リターン」をクリックし、そのケースを
保存し、フレームに戻る。この方法ではケースデータし
か変更できないことに注意されたい。データ源、行動お
よび記号の修正はケースフレームを編集して行わなけれ
ばならない。

【０７１７】ケースの削除 現行のケースベースからケースを削除するには、ケース
ベースの画面表示のエントリーをクリックして、希望す
るケースを選ぶ。次に「Ｃａｓｅ（ケース）」ボタンを
クリックし、メニューから「Ｄｅｌｅｔｅ（削除）」を
選択する。対話ボックスが現れ、確認を求めてくる。
「ＯＫ」をクリックすると選ばれたケースが削除され、
ケースメニューに戻る。「Ｃａｎｃｅｌ（取消）」を押
すと、処理を中止する。

【０７１８】ケースデータの修正 ケースの値を修正するには、ケースデータ表示画面上で
希望する値をクリックして、修正すべき値を選択する。
次に「Ｖａｌｕｅ（バリュー）」ボタンをクリックし、
メニューの中から「Ｍｏｄｉｆｙ（修正）」を選ぶ。選
ばれた値はケースデータ表示画面に表示される。修正が
完了したならば「ＯＫ」ボタンを押すとケースデータ表
示画面に戻る。

【０７１９】ケースデータの追加 ケースデータを追加するには、ケース行動表示画面の
「Ｖａｌｕｅ（バリュー）」ボタンをクリックし、メニ
ューの中から「Ａｄｄ（追加）」を選択する。空のケー
スデータ表示が現れるので、その中にデータを入力する
ことができる。データのタイプを入力し、オペレータを
スコアする為に、「Ｐｉｃｋ（ピック）」ボタンが利用
できる。終わったならば、「ＯＫ」をクリックすると、
その行動が保存される。「Ｃａｎｃｅｌ（取消）」をク
リックすると、処理は中止される。

【０７２０】ケースデータの削除 ケースデータを削除するには、ケースデータ表示画面で
削除したい値を選び、クリックして入力する。次に「Ｖ
ａｌｕｅ（値）」ボタンをクリックし、メニューから
「Ｄｅｌｅｔｅ（削除）」を選択する。対話ボックスが
表示され、確認を求めてくる。「ＯＫ」をクリックする
と選択されたケースが削除され、画面はケースデータ表
示に戻る。「Ｃａｎｃｅｌ（取消）」をクリックする
と、処理は中止される。

【０７２１】ケースベースのコンパイル 現行ケースベースをコンパイルするには、フレーム表示
画面の「Ｃｏｍｐｉｌｅ（コンパイル）」ボタンをクリ
ックする。ケースベースのコンパイルの中には、いくつ
かのステップが含まれる。第一のステップでは、ケース
ベースで使われる全てのオブジェクト／属性のリストが
生成される。第二のステップでは、現行の黒板構成から
類似のリストが生成される。二つのリストを比較して、
ケースベースで引用されている全てのオブジェクト／属
性が、黒板の中に含まれているか否かが確認される。も
し相違があれば影響されるケース／データ源ペアのリス
トが表示され、コンパイルは中止される。

【０７２２】問題がなければ、開発ケースベースは、実
行時に使われる、より早く、よりコンパクトな表現に再
フォーマットされる。このプロセスが完了すると、コン
トロールはフレーム表示画面に戻る。

【０７２３】ケースベースエディタからの退去 ケースベースエディタから出るには、フレームライブラ
リ表示画面で、「Ｅｘｉｔ（退去）」ボタンをクリック
する。

【０７２４】実行時ユーザインターフェイスの開発 この節では、実行時エンドユーザインターフェイスを開
発するためのドメインシェルについて述べる。ここに述
べるツールを使って、アプリケーションの開発者は、エ
ンドユーザに示す画面表示の形を定義する。

【０７２５】Ｖｉｅｗｓ（一覧） 一覧は、映像、グラフ、表、メニューなどの画面表示リ
ソースをミックスして、エンドユーザと情報の交信をす
る複合ディスプレイである。これの基本的に意図する所
は、一覧がある物理的なアイテムのグラフ表示を、関連
する情報とともに、エンドユーザに提供することであ
る。一つのアイテムに対して、多数の一覧がある。もし
そのアイテムが黒板に表示されているならば、開発者
は、その一覧が表示するオブジェクトと属性を指定する
ことができる。

【０７２６】異なっているが、しかし関連のある一覧を
速やかに調べられるメカニズムを、エンドユーザに提供
することが望ましい。そのようなメカニズムとして、二
つのものが利用できる。それはメニューとホットスポッ
トグラフである。

【０７２７】ホットスポットは表示画面上の長方形のエ
リアであり、カーソルがその上にくると“Ｈｏｔ（ホッ
ト）”になる。そのエリアがホットになると、そこの回
りが点線でマークされる。マウスがこの区域から外れる
と点線で囲まれた長方形は消滅する。その他の形式のリ
ソースも（次の節で述べる如く）ホットスポットか、メ
ニュー選択で連想づけることができる。

【０７２８】一覧がこのような方法でリンクされるに従
って、グラフ情報の階層が展開される。この階層は、黒
板の階層を厳密に反映していることに注意されたい。し
かしこの二つはオーバーラップしない。

【０７２９】実行開始 実行時ユーザインターフェイスの開発を開始するため
に、アプリケーション開発者は最上位メニューの「ＣＯ
ＭＰＯＮＥＮＴ−Ｖｉｅｗｓ（コンポーネント一覧）」
選択を選ぶ（図５１）。この選択によって図８１に示す
最上位の一覧エディタウィンドウがオープンされる。

【０７３０】この時点で利用できるオプションは下記の
とおりである。

【０７３１】１．ＦＩＬＥ（ファイル）：開発者はファ
イルコマンドによって、ファイルを新規作成したり、古
いファイルをオープンしたり、また現ファイルを保存で
きる。各データベースファイルは特定のアプリケーショ
ンと特定のエンドユーザに対するエンドユーザ一覧仕様
の全てを網羅している。このプルダウン選択によって、
次の選択肢を持つメニューがポップアップする。

【０７３２】Ｃｒｅａｔｅ（作成）：作成は新しい一覧
データベースファイルを開始させる。これはいつでも新
しい一覧データベースをつくるときに最初になすべき作
業である。もしいま古いデータベースを編集しているな
らば、「Ｃｒｅａｔｅ（作成）」メニューを選択する前
に、必ずそれを保存しなければならない。「Ｃｒｅａｔ
ｅ（作成）」メニューを選択すると、選択ボックスが表
示される。このボックスで新しいデータベースファイル
の名前が定義される。“ＯＫ”ボタンを押すと、新しい
仕様の一覧、グラフ、表などでプログラムを開始する体
勢になる。もう一つ追加的エントリフィールドによっ
て、このアプリケーションに関連すべきユーザまたはグ
ループの選択が可能になる（ユーザ及びグループの仕様
は後で定義する）。ユーザまたはグループが選ばれたな
らば、そのユーザまたはそのグループに属するユーザの
組のみが、定義された特定のインターフェイスを実行す
ることを許される。

【０７３３】「Ｏｐｅｎ（オープン）」：既存のデータ
ベースを使用する。選択ボックスは現在存在している一
覧データベースのリストから、または次のエントリエリ
アに希望するデータベースファイルの名前をタイプする
ことにより、一覧データベースを選択することを可能に
している。アプリケーションが作成されたものからでは
なく、ディスクからまずロードされることを除いては、
この選択ボックスは本質的には「Ｃｒｅａｔｅ（作
成））」選択ボックスと同じである。この時点で一覧デ
ータベース中の情報が、ロードされ、編集のために利用
可能である。

【０７３４】「Ｓａｖｅ（保存）」：保存は現在使用中
の一覧ファイルをディスクに書き込む。指定された一覧
を保存するためには、「Ｃｒｅａｔｅ（作成）」や「Ｅ
ｘｉｔ（退去）」の選択の前に、この選択を行わなけれ
ばならない。

【０７３５】「Ｅｘｉｔ（退去）」：退去はデベロップ
メントウィンドウ及び全ての関連するウィンドウを閉
じ、最上位のウィンドウに戻す。

【０７３６】２．ＳＰＥＣＩＦＹ（スペシファイ）：開
発者はこのプルダウンメニューによって次の作業に使う
リソースのタイプを選択することができる。各々のＳＰ
ＥＣＩＦＹ（スペシファイ）を選択するとまず選択ボッ
クスがポップアップする。

【０７３７】それによって、アプリケーション開発者
は、利用可能なアイテムのリストからピックアップする
か、新しいアイテムの名前を入力できる。その一例が上
記の図７８「ＳｐｅｃｉｆｙＶｉｅｗ（スペシファイ一
覧）」の部分に示されている。以下の節に下記の選択の
詳細を説明する。

【０７３８】Ｖｉｅｗ（一覧）Ｇｒａｐｈ（グラフ）Ｔ
ａｂｌｅ（表） ＧｒａｐｈＧｒｏｕｐ（グラフグループ）：グラフグル
ープとは、画面表示される多数のグラフのリストであ
る。

【０７３９】ＴａｂｌｅＧｒｏｕｐ（テーブルグルー
プ）：テーブルグループとは、画面表示される多数の表
のリストである。

【０７４０】３．ＵＳＥＲＳ（ユーザ）：このプルダウ
ン選択によって、次のような選択ができるメニューがポ
ップアップする。

【０７４１】Ｕｓｅｒ（ユーザ）：開発者はユーザで、
新しいエンドユーザと、最初のパスワードを指定するこ
とができる。古いユーザもまた修正することができる。
このユーザ名は「ＦＩＬＥ（ファイル）」の下で「Ｇｒ
ｅａｔｅ（作成）」の選択に使用する。

【０７４２】「Ｇｒｏｕｐ（グループ）」：開発者は
「グループ」によって、グループ名として一括して引用
することが可能ないくつかのエンドユーザ名を指定する
ことができる。グループ名は指定されなければならな
い。古いグループは削除し、ユーザを追加するか削除す
ることができる。このグループ名は「ＦＩＬＥ（ファイ
ル）」の下で「Ｇｒｅａｔｅ（作成）」の選択に使用さ
れる。

【０７４３】実行時ユーザインターフェイスの規定 Ｖｉｅｗｓ（一覧）（システム表示） この節では、アプリケーション開発者が複合表示を指定
する方法が述べられている。図８２に示す一覧編集画面
は、実行時ユーザインターフェイスエディタの中の「Ｓ
ＰＥＣＩＦＹ−Ｖｉｅｗ（スペシファイ一覧）」を選択
することでオープンされる。各々一覧に対して次のフィ
ールドが定義される（いくつかのエントリはオプション
であることに注意）。

【０７４４】ＶｉｅｗＮａｍｅ（一覧名） 一覧名は作成された新しい一覧、または編集された古い
一覧で関連づけられた名称である。その名称は、その一
覧のみに関連づけられた唯一の名称でなければならな
い。しかし一覧の名称は黒板に中のオブジェクトの名称
と同じでも良い。ＶｉｅｗＴｙｐｅ（一覧タイプ） 一覧タイプは、ｉｓ−ａ属性の中で指定される。属性名
は、それが黒板ｉｓ−ａ属性と類似であることを示唆す
るために選ばれたが、一覧に関する限り、継承の概念は
ないことに注意すべきである。属性の主目的は、いくつ
かの決められたタイプの中の一つの中で、一覧のグルー
ピングを規定することである。ピックボタンは、次の選
択肢の内から一つを選ぶために設けられている（さらに
追加することも可能）。

【０７４５】Ｓｅｎｓｏｒ（センサ）：センサーは、一
般的には情報の計測のためにイクイップメント上または
その近くに設けられるディバイスである。一般的にはセ
ンサで連想づけられたホットスポットは、グラフ一覧に
はそれ以上進展せずに、むしろ、実際のセンサ情報の方
へ進展する。

【０７４６】Ｅｑｕｉｐｍｅｎｔ（イクイップメン
ト）：イクイップメントは、画像あるいは一覧として表
現されるコンポーネントである。

【０７４７】Ｃｏｎｎｅｃｔｉｏｎ（コネクション）：
コネクションは一般的には次のいずれかである。パイ
プ、ワイヤ、サポートその他であり、一つのコンポーネ
ントを他のコンポーネントに接続するものである。コネ
クションそれ自身はまた一つの一覧として表現される。

【０７４８】Ｓｙｓｔｅｍ（システム）：システムは通
常、イクイップメント、コネクション、センサ及びその
他のシステムの集合として規定される。システムもまた
一つの一覧として表現される。

【０７４９】またこの場合のｉｓ−ａ属性の主目的は、
特定の一覧の探求を促進する方法で、画面表示の自然な
グルーピングを提供するものであることに注目すべきで
ある。一方、センサは一般的にはグラフ一覧では表現さ
れず、「Ｄａｔａ−ｄｉｓｐｌａｙ（データ表示）」タ
イプの一覧で表現される。

【０７５０】一覧ピクチャ 一覧と共に表示される背景ピクチャを選択するために、
アプリケーション開発者はグラフィックイメージが収納
されているファイル名を指定しなければならない。アプ
リケーションに関連するイメージを含む全てのディスク
ファイルを、アプリケーションディレクトリのデフォル
トサブディレクトリの一つに格納する方法が推賞され
る。この方法で、ピクチャ選択に関連するＰＩＣＫ（ピ
ック）ボタンをクリックすることにより、存在する全て
のピクチャの選択ウィンドウの追跡が可能である（デフ
ォルトサブディレクトリ名である「Ｐｉｃｔｕｒｅ（ピ
クチャ）」が使用されるが、もしアプリケーション開発
者が望むならば、変更することも可能である）。ピクチ
ャタイプフィールドに関連したＰＩＣＫボタンをクリッ
クすると、グラフフォーマットのメニューが選択でき
る。ここに、選択はビットマップイメージか、二つのタ
イプのベクトルベースイメージの一つである（ＨＰＧＬ
ファイルまたＤＸＦファイル）。各々の選択を下記に述
べる。

【０７５１】ビットマップイメージ アプリケーション開発者は、ペイントプログラムのよう
な外部のソフトウェアパッケージを使うか、またはディ
ジタイズスキャナでイメージを走査して、ビットマップ
イメージを作成する。シェルが受け入れるイメージのタ
イプは、ＧＩＦ（グラフィックインターチェンジフォー
マット）、ＸＷＤ（Ｘウィンドウダンプ）またはＸＢＭ
（Ｘウィンドウビットマップ）である。その他のイメー
ジタイプは、外部パッケージでイメージを作成するため
に使われる。種々の他のタイプをシェルが理解する三つ
のフォーマットの内の一つに翻訳するコンバージョンユ
ーティリティが利用可能である。

【０７５２】ベクトルベースイメージ：ＨＰＧＬ ファイル アプリケーション開発者は、ビットマップイメージのよ
うに、外部パッケージを使って、ＨＰＧＬイメージを作
成しなければならない。ほとんどのＣＡＤ（コンピュー
タ支援設計）パッケージは、アプリケーション開発者が
ＨＧＰＬディバイスにプロットする能力を持っている。
アプリケーション開発者はディバイスにプロットするか
わりに、拡張子「Ｈｐｇｌ」を持つファイルにプロット
すべきである。ＨＰＧＬファイルがビットマップイメー
ジより勝っているのは次の点である。すなわち、もし実
行時ユーザがイメージを含むウィンドウを基準化したと
きに、ビットマップイメージではイメージ解像度が低下
するが、ｈｐｇｌではそれがないことである。ウィンド
ウは、絶対ビットマップ情報ではなく、ベクトル情報を
使って再描写される。不利な点としては、特にビットマ
ップ像イメージが走査された場合は、そのイメージが簡
単化されて見える傾向があることである。走査されたイ
メージは、ビットマップの方が、よりよく表現される。
またベクトルベースイメージは、描写されたり変換され
たビットマップイメージ（ベクトル形式からビットマッ
プ形式に変換され、次いでカラーシェードされた）程の
カラーシェイディング情報を持たない傾向にある。もう
一つの短所は、ベクトルベースのイメージは画面に表示
するのに、ずっと長い時間が掛かることである。

【０７５３】ベクトルベースイメージ：ＤＸＦファイル アプリケーション開発者は、ＨＰＧＬファイルのよう
に、ＤＸＦイメージと両立する外部ＣＡＤパッケージは
何であってもそれを利用して、ＤＸＦイメージを作成し
なければならない。パッケージの一例はＡｕｔｏｃａｄ
（オートキャド）である。

【０７５４】ＤＸＦイメージはインクルージョンをサポ
ートし、他のＤＸＦイメージを基準化する特性を持って
いる。内包されたイメージはホットスポットとして理解
され、別の一覧に通報される。従って、ＤＸＦファイル
を使う利点は、開発者が既存の一覧のコンポーネントを
使って、新しい一覧を定義することが容易になることで
ある。

【０７５５】黒板アイテム 一覧の階層と黒板階層間のマップは、このフィールドの
黒板オブジェクト／属性を指定することによって確立さ
れる。

【０７５６】表示タイトル このフィールドに入力されるテキストは、一覧のモチー
フスタイルウィンドウのタイトルとして表示される。

【０７５７】メニューの選択 最上位メニューの選定を、一覧と関連させることができ
る。「Ａｄｄ（追加）」ボタンをクリックすると、可能
なメニュー選択の全てを含むポップアップメニューが表
示され、その内の一つを選ぶと、それがこの一覧に対す
る現在のメニュー選択のリストに加えられる。その選択
はまたサブメニューの既に定義されたセット名を含んで
もよい。これはサブメニューボタンをクリックし、既に
定義されたサブメニューを選ぶことで行われる。サブメ
ニューの仕様をここに述べる。また、利用可能なメニュ
ー選択のリスともその中に記載されている。

【０７５８】コネクション（ホットスポット） ホットスポットはいったん画像を選ぶと、一覧で連想づ
けることができる。ホットスポットは二ステップのプロ
セスで作成される。第一は、エンドユーザがこのホット
スポットを活性化させたとき、実行時中に表示される一
覧を選択するため、エディタの「Ｃｏｎｎｅｃｔｉｏｎ
ｓ（コネクション）」部の「Ａｄｄ」ボタンをクリック
しなければならないということである。第二は、アプリ
ケーション開発者はホットスポットの区域を定義しなけ
ればならないということである。これを実行するために
は、マウスカーソルを希望する区域の左上側に置き、マ
ウスの左ボタンをクリックする。それから定義しようと
するホットスポットの所望区域の右側下までマウスを動
かし、マウスのボタンを放す。

【０７５９】ホットスッポットを消去するには、その名
称をクリックし、次に「Ｄｅｌｅｔｅ（削除）」ホタン
をクリックする。既存のホットスポットの区域を修正す
るには、そのホットスポットの名称（その連想づけられ
た）を選択し、次に「ｈｏｔ−ｓｐｏｔ（ホットスポッ
ト）」ボタンをクリックする。次いでアプリケーション
開発者は、上記の方法でホットスポットの新しい区域の
定義プロセスへ進む。Ｇｒａｐｈｓ（グラフ） 「Ａｄｄ」ボタンと「Ｄｅｌｅｔｅ」ボタンでグラフを
追加したり、既存のグラフを削除する。新しいグラフ
（まだ指定されていない）を追加するには、ここに述べ
たグラフ仕様エディタを実行する。

【０７６０】Ｕｓｅｒｓ Ａｎｄ Ｇｒｏｕｐｓ（ユー
ザ及びグループ） 特定のエンドユーザまたはユーザのグループは、「Ｕｓ
ｅｒ（ユーザ）」ホタンまた「Ｇｒｏｕｐ（グルー
プ）」ボタン（図７９には示されていない）をクリック
し、ユーザまたはグループのリストから希望するユーザ
またはグループを選択することにより、いずれかの一覧
と連想づけることができる。ユーザまたはグループは
「Ｓｔａｔｕｓｕ（ステータス）」ボタンをクリックし
て一覧の使用を除外することができる。これによって現
ユーザはまたグループに関連した組み込み／除外フラグ
を切り替える。デフォルトでは、一つの「Ｓｕｐｅｒｕ
ｓｅｒ（スーパーユーザ）」を除いて、他の全てのユー
ザが除外される。

【０７６１】データディスプレー グラフ グラフはエンドユーザにとってデータを描写するために
使用できるシェルの中で利用可能な方法の一つである。
グラフは履歴データ（Ｘ軸は時間）を示し、また黒板か
らどれかの二つのディメンションタイプの情報（それら
が相対応する履歴を有しさえすれば、一つのオブジェク
ト／属性値に対するどれか他のオブジェクト／属性値）
をプロットするこができる。図８３にグラフ情報を定義
し、編集するために用いられるスクリーンを示す。

【０７６２】グラフには名称とＹ軸黒板オブジェクト／
属性が与えられねばならない。その他の入力は任意であ
る。アプリケーション開発者は、下記の内いくつかまた
は全てを規定することができる。Ｘ軸は時間またはもう
一つの黒板オブジェクト／属性を表すことができる。も
し後者であれば、その黒板は、相応する全てのＸ及びＹ
の値を含まなければならない。グラフの向きはポップア
ップメニューで、水平または垂直何れでも選択できる。
Ｘ軸またはＹ軸のスケールは指定でき、もし「Ａｕｔｏ
（オート）」をクリックすれば、利用可能なデータに基
づいて自動的に選択される。希望するなら、ＸとＹのラ
ベルテキストとカラーが指定できる。最後に、多数の曲
線が互いに重なって見えるように、（このグラフのスケ
ーリングおよびラベリング情報を利用して）他の重ねグ
ラフが指定できる。言い替えれば、もし他の一つのグラ
フが、このグラフと一緒になっているならば、それらは
一つのウィンドウの中に表示される。スケーリングのた
めの情報は、このグラフの仕様から得られる。このグラ
フと一緒に表示する場合には、他のグラフのカラーのみ
が使用される。

【０７６３】Ｔａｂｌｅｓ（テーブル） テーブルは、黒板からのデータを表の形で表示するとき
に使われる。もし一列以上のデータを表示するときに
は、開発者は一つ以上のテーブルを定義し、「Ｏｔｈｅ
ｒ Ｔａｂｌｅｓ（他のテーブル）」を使って、それら
をこのテーブルと連結しなければならない。エンドユー
ザがテーブルを見た場合に、各列はこの表からの情報
と、リストされたそれに続く各テーブルからの情報を示
す。図８４に、テーブル情報を定義し、編集するために
使用されるスクリーンを示す。

【０７６４】Ｍｅｎｕｓ（メニュー） 実行時環境のユーザは、選択を行ったり、情報を与える
ために数種のメニュータイプの画面表示を使うことがで
きる。それらはプルダウン、ポップアップ、セレクショ
ン、ホックス、対話ウィンドウ及びボタンである。メニ
ュー／アクション情報の多くは特定の一覧と結び付ける
ことができ、あるいはメニューセットを定義し、一覧と
結び付けることができる。図８５はメニューを定義し、
編集するためのスクリーンを示す。

【０７６５】メニュー選択のリストを作成し、後で最上
位メニュー選択レベルの一覧、または他のメニューと結
合することができる。アプリケーション開発者はこれに
より、アプリケーション及びエンドユーザのニーズに最
もよく適合したエンドユーザに対するメニュー階層を指
定することができ、一方これと同時に類似の一覧に対す
る再作業量を減らすことができる。図８５の右側には、
グループと連想づけられた選択の全部をピックして、メ
ニューグループを指定する方法と、グループを表示する
ために使われるメニューのタイプを示す。図８５の左側
はメニュー選択が、行動と連想づけられる機構を示す。
テキストストリングの一つ以上の選択が、同じアクショ
ンに連想づけられる。利用可能な実行時メニューは次の
とおりである。

【０７６６】Ｅｘｉｔ（退去）：実行時システムから抜
ける。

【０７６７】Ｒｅｔｕｒｎ（リターン）：メニュー階層
において、一レベル戻る。

【０７６８】Ｈｅｌｐ（ヘルプ）：ヘルプする。

【０７６９】Ｎａｖｉｇａｔｅ（ナビゲート）：希望す
る一覧タイプに基づいた新しい一覧へ動く。この一覧に
結合する利用可能な一覧のリストが示される。この一覧
の「Ｐａｒｅｎｔｓ（親）」にナビゲートすることも可
能である。言い替えれば、現一覧と結合する何れの一覧
へ行くことも可能である。

【０７７０】Ｈｉｇｈｌｉｇｈｔ（ハイライト）：現一
覧に対して定義されたホットスポットをハイライトす
る。

【０７７１】Ｇｒａｐｈ（グラフ）：このビューに接続
されているグラフを表示する。

【０７７２】Ｔａｂｌｅ（表）：このビューに接続され
ている表を表示する。

【０７７３】Ｉｎｆｏｒｍａｔｉｏｎ（情報）：黒板オ
ブジェクト情報がもしあれば、それも含めてこのビュー
に関連する情報の全てを表示する。

【０７７４】Ｔａｇ（タグ）：接続をマークし、後でグ
ラフ多重オブジェクトに使われる格納場所に追加する。

【０７７５】アプリケーションのテスト ドメインシェルは、アプリケーション開発者がアプリケ
ーションをテストするに際して、それを支援するいくつ
かのツールを提供する。これらのツールはアプリケーシ
ョン開発環境の一部である。それらはアプリケーション
開発者に対して、アプリケーションを実際に実行時環境
で動かす以前に、その全体またはその一部の作動を観察
する方法を提供する。

【０７７６】ドメインシェルに関しては、開発者が利用
可能な三つのテストタイプがある。第一のタイプは、実
行時ユーザーインターフェイスの見栄えをプレビューす
るものである。次のタイプは各々の知識源のテストであ
る。最後のテストのタイプは、アプリケーション全体ま
たはその主要部を働かせるものである。更に、開発者は
テスト動作を支配するテストモードパラメータをセット
することができる。

【０７７７】ビューレベルでのテスト Ｔｏｐ Ｌｅｖｅｌ Ｄｅｖｅｌｏｐｅｒ’ｓ Ｗｉｎ
ｄｏｗ（最上位の開発者ウィンドウ）（４８図）からＴ
ＥＳＴ（テスト）コマンドのＶｉｅｗｓ（ビュー）を選
択することにより、各種のエンドユーザービューがプレ
ビューできる。エンドユーザーが見ることのできる色々
異なった表示エレメントが、ビュー仕様ウィンドウの中
のドメインシェルに対して定義される。これらのウィン
ドウが作成される方法と、色々異なったビュータイプの
特徴をここに述べる。

【０７７８】ＴＥＳＴ−Ｖｉｅｗｓ（テストビュー）選
択を選ぶと、一つのウィンドウがオープンされ、アプリ
ケーション開発者がユーザーインターフェイスの各部を
見ることができる。このウィンドウは、エンドユーザー
フェイス構成の全ての部分を通して、拾い読みするため
にアクセスできるメニューバーを持っている。図８６は
テストビュー制御ウィンドウの外観を示す。ＤＩＳＰＬ
ＡＹ（ディスプレイ）メニューオプションは次のカテゴ
リに分かれている。すなわちビュー、表及びメニューで
ある。

【０７７９】（実行時）ビュー ＤＩＳＰＬＡＹ Ｖｉｅｗｓ（ディスプレイ一覧）選択
を選ぶと、プレビューのために利用可能なビューのリス
トがポップアップ選択リストメニューとして現れる。そ
れらはシェルのビュー開発部分のビュー表示仕様セクシ
ョンの中に定義された名称で表示される。ビューの名称
を選ぶと、二つのウィンドウがオープンされる。一つの
ウィンドウは、選ばれたビューに対する表示仕様情報の
要約を含む情報ウィンドウである。もう一つのウィンド
ウはビューそれ自体のイメージを示す。第一のウィンド
ウの「Ｓｈｏｗ Ｈｏｔ Ｓｐｏｔｓ（ホットスポット
の展示）」ボタンをクリックすると、定義された全ての
ホットスポットがビュー上に示される。

【０７８０】（実行時）グラフ プレビューに利用可能なグラフのリストは、ＤＩＳＰＬ
ＡＹ−Ｇｒａｐｈｓ（グラフディスプレー）選択を選ぶ
と、ポップアップ選択リストメニューとして現れる。そ
れらは、シェルのビュー展開部のグラフ仕様セクション
の中に定義された名称でリストされている。グラフ名を
選択すると、二つのウィンドウがオープンされる。一つ
は選択されたグラフに対するグラフ仕様情報の要約を含
む情報ウィンドウである。他のウィンドウは、グラフ軸
のレイアウトとラベルを示す。グラフ関連情報が情報ウ
ィンドウに表示され、「Ｓｈｏｗ Ｈｏｔ Ｓｐｏｔ
ｓ」（ショウホットスポット）ボタンが現れないことを
除けば、二つのウィンドウの見かけは、図８７の中にビ
ュープレビューイングに対して示されたものと類似であ
る。

【０７８１】（実行時）表 プレビューに利用可能な表のリストは、ＤＩＳＰＬＡＹ
−Ｔａｂｌｅｓ（表ディスプレー）選択を選ぶと、ポッ
プアップ選択リストメニューとして現れる。それらは、
シェルのビュー展開部の表仕様セクションの中に定義さ
れた名称でリストされている。表の名称を選択すると、
二つのウィンドウがオープンされる。一つは選択された
表に対する表仕様情報の（要約）を含む情報ウィンドウ
である。他のウィンドウは、表のレイアウトを示す（デ
ータは入っていない）。表関連情報が情報ウィンドウに
表示され、ショウホットスポットボタンが現れないこと
を除けば、二つのウィンドウの見かけは、図８７の中に
ビュープレビューイグに対して示されたものと類似であ
る。

【０７８２】（実行時）メニュー プレビューに利用可能なメニューのリストは、ＤＩＳＰ
ＬＡＹ−Ｍｅｎｕｓ（表示メニュー）選択を選ぶと、ポ
ップアップ選択リストメニューとして現れる。それら
は、シェルのビュー展開部のメニュー仕様セクションの
中に定義された名称でリストされている。メニューの名
称を選択すると、そのメニューがディスプレイに現れ
る。メニュー選択と連想づけられた行動は、このモード
では禁止状態になるが、メニューの階層的レベルとその
連想づけられたサブメニューはまだ否定される。メニュ
ービューをテストしている間、ＥＸＩＴ（退去）選定は
常に利用可能であり、それを押すとメニューが画面表示
から消去される。

【０７８３】知識源レベルにおけるテスト 知識源レベルにおけるテストは、特定の知識源仕様ファ
イル上で、知識源タイプで連想づけられた推論機構を作
動させることから成る。知識源をテストするためには、
開発者がテスト情報を指定しなければならない。この情
報とはテスト作動モード、入出力ファイル名及びデータ
源である。

【０７８４】知識源テストオプションは、最上位の開発
者ウィンドウにあるＴＥＳＴ（テスト）コマンドメニュ
ーから、知識源選択を選ぶことで実行される。

【０７８５】知識源テスト制御パネル 知識源レベルのテストを選択すると、制御ウィンドウが
オープンされる。このウィンドウはテスト環境に対し
て、知識源テストの方法を教えるフィールドを持ってい
る。図８８に知識源テスト制御パネルの外観を示す。こ
のウィンドウのフィールドについて以下に説明する。

【０７８６】知識源名 知識源は、現在アプリケーションのために定義されてい
る知識源のリストから選択される。選択は知識源名のフ
ィールドの隣にあるＰＩＣＫ（ピック）ボタンをクリッ
クすることにより実行される。これによって、利用可能
な知識源のリストが表示される。リスト中の知識源名を
ハイライトし、選択リストウィンドウ内のＯＫボタンを
押すと、希望する知識源が選定される。

【０７８７】データソース このフィールドでは、テストのために使用するデータ源
が指定される。関連するＰＩＣＫボタンを押すと、利用
可能なデータ源のタイプのリストが表示される。Ｍａｎ
ｕａｌ（マニュアル）、Ｆｉｌｅ（ファイル）またはＲ
ｅａｌ−Ｔｉｍｅ（リアルタイム）が選択できる。

【０７８８】マニュアルを選択すると、新しいウィンド
ウがオープンされる。このウィンドウの外観を図８９に
示す。データのマニュアル入力を使用している限り、こ
のウィンドウは表示画面上に残っている（開発者が積極
的にウィンドウをクローズするまで）。ウィンドウはテ
キスト入力エリア、チェックボタン、送りボタン及びク
ローズボタンより成る。開発者はテキスト入力エリア
に、使用すべきデータポイントを入力する。各データポ
イントには、オブジェクト名、属性名、時間スタンプ、
データタイプ及びデータ値が指定されている。Ｃｈｅｃ
ｋ（チェック）ボタンを押すと、シェルがデータポイン
ト使用の妥当性をチェックする。送りボタンは、データ
を現在テスト中のアプリケーション部へ送る役目をす
る。

【０７８９】データ源としてファイルを選択すると、利
用可能な入力データファイル選択リストが表示される。
希望するファイルは、ファイル名をハイライトし、選択
リストウィンドウ中のＯＫボタンをクリックして選定す
る。ファイル名はデータ源フィールドに表示される（そ
れによってデータソースモードがファイルであることを
暗示する）。選択リストの入力データファイルは、現在
アプリケーションディレクトリ（ファイル拡張子：．ｄ
ａｔを有する）中に存在するファイルであることに注意
されたい。

【０７９０】もしリアルタイムをデータ源として選んだ
ときには、それ以上の情報は不要である。システム構成
の中の外部プロセスとして、前に指定したデータ源が活
性化される。開発者は、テストが完了したらテスト環境
のオペレーションを停止しなければならない。マニュア
ル及びファイルデータ源の場合には、データランが完了
すると、テストは自動的に停止する。

【０７９１】タイム（圧縮／伸張） ファイルデータを使うと、このフィールドが活性化され
る。これはタイム圧縮または伸張ファクターを入力でき
る数値入力フィールドから成る。正の実数がここに入力
される。１．０より大きな数字はタイム圧縮を表し、
１．０より小さな数字はタイム伸張を表す。

【０７９２】出力 このフィールドはテスト出力の行き先を指定するために
使用する。これは出力ファイル名の指定が許される。こ
こに入力される出力ファイル名はテスト期間中に作成さ
れる出力サマリファイルのための、ルートファイル名と
して使用される。各知識源はまたそれ自身のログファイ
ルも作成することに注意されたい。

【０７９３】テストモード このフィルードは一対のラジオボタンで構成されてい
る。「ｋｓ」のみのボタンは制御サブシステムを活性化
せずに、知識源をテストするために使用される。「ｋｓ
＋」制御ボタンは、その連想づけられたコントロールを
使って知識源をテストするために使用される。もし知識
源が連想づけられたコントロールなしで活性化される
と、知識源は新しいデータパケットを受け取る毎に発火
される。マニュアルの入力データを使用すると、知識源
は新しいデータポイントが入力されるごとに発火する。

【０７９４】「ｋｓ＋」制御ボタンは、もう一つのテス
トモードへのクイックボタンである。「ｋｓ＋」コント
ロールを押すと、シェルはシステムテストモードに入
る。このケースでは、テストされているシステムは、現
在の知識源と、その連想づけられたコントロールの定義
のみから構成されている。

【０７９５】知識源レベルにおけるテストオペレーション テストモード構成がセットされると、知識ベースのテス
トが進行する。開発者表示画面に、テストオペレーショ
ン制御ウィンドがオープンされる。それを図９０に示
す。このウィンドウを使って、開発者はテストを開始し
たり、停止したりすることができる。

【０７９６】ウィンドウの下部にあるコントロールによ
って、開発者はテストを開始したり停止したり、それか
ら抜け出したりする。開始ボタンを押すと、テストが開
始される。停止ボタンを押すとテストが休止される。も
しリアルタイムデータがデータ源として選ばれているな
らば、それはたとえテストを中止しても、システムの中
に入ったままになる。しかしテスト中止期間中は、デー
タはテスト環境の中に記憶されない。退去ボタンを押す
と、テストが終了し、関連する出力ファイル（知識源及
びサマリ）が書き込まれる。

【０７９７】図９０に示すウィンドウに加えて、テスト
された知識源自身のウィンドウが表示画面にオープンさ
れている。各知識源ウィンドウは他のオペレーティング
情報とともに、ファイリングの結果を表示する。

【０７９８】知識源レベルにおけるセッティングオプション テストオプション制御ウィンドウ（図９０）には、セッ
トオプションボタンがある。開発者はこのボタンを押す
ことによって、テストオプションを設定することができ
る。このウィンドウの機能を以下に述べる。

【０７９９】システムテスト アプリケーションの開発者はシステムレベルのテストに
おいて、常にコントロール部を伴うアプリケーション各
部のオペレーションを、全てに渡って確認することがで
きる。このタイプのテストにより、アプリケーションを
全体のインプリメンテーションが証明される。

【０８００】システム制御パネル システムレベルでテストを実行するためには、知識源の
コントロールの仕様が完成されていなければならない。
具体的にいうと、個々の知識源の優先度が設定され、事
象、前提条件、及び再ファイリング条件が指定されなけ
ればならない。これは開発環境のコンポーネントコント
ロール部分で行われる。

【０８０１】システムテスト選択を選ぶと、アプリケー
ションの為に現在定義されている知識源を、リストした
ウィンドウが表示される。このウィンドウはシステムテ
スト知識源構成ウィンドウと呼ばれる。その外観を図９
１に示す。知識源名をハイライトし、ＤＩＳＡＢＬＥ
（ディスエーブル）ボタンをクリックすると、知識源は
一時的に活性化活動停止状態（テストのために）にな
る。ＥＮＡＢＬＥ（エンエーブル）ボタンは、以前に活
性化停止状態にされた知識源を、再活性化するために使
用される。知識源名を二回クリックすると、その状態が
切り替わる。

【０８０２】この知識源の状態のコントロールは、テス
ト環境のみに影響を及ぼすことに注意されたい。知識源
を完全にアプリケーションから除外するには、開発者は
積極的に知識源を、アプリケーション開発環境の最上位
から削除しなければならない。 知識源がセットされた
後、開発者は知識源リストウィンドウのＯＫボタンをク
リックする。これにより、システムレベル制御パネルが
オープンされる。このパネルは、知識源名のラインが現
れないことを除いては、見かけ上は図９０に示される知
識源レベルテストのための制御パネルと同じである。テ
ストモードボタンも使用可能にはならない（システムレ
ベルのテストは常にコントロールがテストされているこ
とを暗示する）。

【０８０３】システムレベルにおけるテストオペレーション システムレベルテストのためのテストオペレーション
は、ここに記載する知識源レベルテストのためのテスト
オペレーションとは類似である。図９０に示すような制
御コントロールウィンドウが現れる。開発者はＳｅｔ
Ｏｐｔｉｏｎｓ（セットオプション）ボタンを押して、
テストモードオプションを設定する。

【０８０４】テストモードオプション 開発者はテストを推進するために、テストモード環境に
対するパラメータを事前に定義することができる。これ
は図９２に示すテストモードデフォルト構成ウィンドウ
の中で行われる。このウィンドウは、セットオプション
ボタンを押すことにより、テストオペレーション制御ウ
ィンドウ（図９０）からアクセスできる。このウィンド
ウで設定されるオプションは、開発者が積極的に変更す
るまではウィンドウに残っている。これらのオプション
の目的は、開発者が余り介在していなくても、テストが
進行するように、あるテストモードパラメータを事前定
義することである。

【０８０５】ウィンドウの“テストすべき最終の知識源
使用？”のセクションは、知識源モードテストに適用さ
れる。“ｙｅｓ”を押すと、シェルのテスト環境は自動
的に知識源エディタによって保存された最終の知識源を
ロードする。“ｎｏ”を押すと、開発者は知識源テスト
を指定するときに、テストを希望する知識源を選択しな
ければならない。“ｙｅｓ”を使うと、知識源に対して
行われた変更の結果をテストするためのアクセスがより
早くなる。“アウトプットファイルネーム”フィールド
はテスト環境全体に適用される。ファイルネームが“出
力ファイルネーム”フィールドの中に指定されると、シ
ェルは自動的に、これを出力ファイルネームとして使用
する。もしこのフィールドが空白であれば、開発者は各
テストを開始するときに、出力ファシルネームを積極的
に指定しなければならない。

【０８０６】データ源選定フィールドは、テストに使用
されるデフォルトのデータ源モードを指定する。もし空
白のままであれば、開発者はテストを始める度ごとに、
手動でデータ源を指定しなければならない。具体的なデ
ータ源がここで選ばれたならば、シェルは開発者が介在
しなくても自動的に希望したデータ源を使用する。もし
ファイルでーた源が指定されているならば、“タイムフ
ァクタ”フィールドには、希望した時間圧縮または伸張
ファクタが含まれているべきである。

【０８０７】ウィンドウの“知識源テストモード”セク
ションによって、開発者は知識源テストの為のデフォル
トテストモードを選ぶことができる。

【０８０８】“ｋｓ＋”コントロールを押すと、知識源
テストは直ちにデフォルトとしてコントロールテストを
含むようになる。“ｋｓ”のみを押した場合には、コン
トロールテストは知識源テストの中に含まれない。も
し、どちらのボタンも押さなければ、シェルは知識源テ
ストモードに関して何の仮定もせず、その選択は開発者
に委ねられる。

【０８０９】ウィンドウの“テストの構成を確認する指
示メッセージ？”セクションによって、開発者はテスト
モードにおいて検証を促すかどうかの選択をする。“ｙ
ｅｓ”を押すと、シェルは開発者がテストを進める前
に、テストモード構成情報を確認するよう促す。これに
よって、間違って現在存在する出力ファイルに重ね置き
することを防止できる。“ｎｏ”を押せば、このウィン
ドウ中に指定されたファイルは直ちにテスモードで使用
される。（現在の出力ファイルは書き直されるかもしれ
ない。）これにより開発者の介在を大幅に減少させるこ
とができる。

【０８１０】ドメインシェルプログラムは、ヒューレッ
ドパッカード９０００、シリーズ７００ファミリーワー
クステーション上で稼働するように設計されたものであ
る。ワークステーションはＨＰ−ＵＸオペレーティング
システムのバージョン８．０５または、より新しいバー
ジョンでランしなければならない。

【０８１１】ＨＰ−ＶＵＥビジュアルユーザ環境も存在
しなければならない。この環境はモティーフベースのＸ
ウィンドウシステム上に置かれる。ドメインシェルはＸ
タームウィンドウをこの枠組みの中で使用する。

【０８１２】シェルを使うために、ユーザはシステムに
使われる入力ファイルを作成しなければならない。従っ
てシェルの個々の入力ファイルの文法及び構成ととも
に、シェルの全体の設計構想をよく知っておくことが有
効である。

【０８１３】入力ファイルの作成は、シェルのオペレー
ションに先だって行わなければならない。シェルを使用
するためには、次のファイルを作成しなければならな
い。すなわち、システムファイル、黒板構成記述ファイ
ル、各ルールベースに対する一つのルールベース記述フ
ァイル、各ケースベースに対する一つのケース記述ファ
イル、及び少なくとも一つの入力データファイルであ
る。これらのファイルの用途について、ここに述べる。
これらのファイルの位置は制限されていない。しかし、
それらがシェルの実行可能なファイルと同じディレクト
リに存在していなければ、ファイルのフルパスネームを
システムファイルの中で指定する必要がある。

【０８１４】システムファイル システムファイルは、黒板構成記述ファイルを識別する
ためのファイル名のリスト、及びそのシステムの全ての
ルールベース及びケース記述ファイルから構成されてい
る。システムファイルはサフィックス“．ｓｙｓ”によ
って識別されている。ファイルフォーマットを図２７に
示す。

【０８１５】システムファイル中に名付けられたファイ
ルの順序が重要であることに注意されたい。黒板構成記
述ファイルが、まず一番に規定され、次いで全てのルー
ルベース記述ファイル、最後に全てのケース記述ファイ
ルの順になる。これは図２７に示した順序である。一行
につき一つのファイルが記述されねばならない。システ
ムファイルの中に規定した全てのファイルが存在しなけ
ればならない。さもないと初期状況設定エラーが起こ
る。

【０８１６】もしフルパスネームがシステムファイルに
使用されていないと、シェルはスステムファイルで指定
したファイルが、シェルの実行可能なファイルと共に、
同じディレクトリに存在すると判断する。

【０８１７】知識源ウィンドウを完全にオープンする
か、またはそれをアイコン化するかを決定するために利
用できるオプションがある。デフォルトシステムオペレ
ーションは、全ての知識源ウィンドウをアイコン化す
る。しかしもし“，ＮＯＲＭＡＬ”が知識源ファイル使
用ランの後に付いていると、その知識源プロセスで連想
づけられたウィンドウが完全にオープンされる。この機
能は、特定の知識源のオペレーションを詳細に観察する
には有効である。もし希望するなら、同じ“，ＮＯＲＭ
ＡＬ”サフィックスを全ての知識源ファイル仕様ライン
に付ければ、全て知識源ウィンドウは完全にオープンさ
れる。デフォルトの挙動（アイコン化された知識源）
は、知識源仕様ラインの後に“，ＩＣＯＮ”を付けるこ
とによって、明白に規定することができる。

【０８１８】黒板構成記述ファイル 黒板構成記述ファイルは、全てのオブジェクトの定義及
びケースオブジェクトに対する全ての属性を含んでい
る。オブジェクトと属性は、ユーザから与えられた名称
で識別される。黒板ファイルはサフィックス“，ｂｂ”
ＳＥ識別される。ファイルのフォーマットを図２８に示
す。

【０８１９】オブジェクト名と及び連想づけられた属性
は、知識源記述ファイル及び入力データファイルの中で
使用される。シェルが適性に作動するためには、名称は
スペルとケースが正確に一致していなければならない。

【０８２０】タイプダブルの黒板データ値のみが許容さ
れる。明白に示された最大履歴長さはない。黒板はデー
タポイントを保持するから、この履歴長さの範囲内で受
け取る。もし履歴長さが知識源が要求するものより長け
れば、余分なメモリが使われ、システムが不必要に遅く
なる。これをチェックする良い方法は、知識源が要求す
る履歴長さをよく調べ、そして黒板履歴長さを適切に調
整することである。

【０８２１】黒板が受け取った重要なデータは、ＤＥＭ
ＯＮ、ＭＭＩ ＷＲＩＴＥ（ＭＭＩライト）が含まれ
る。黒板がこのオブジェクト／属性の新しい値を受け取
ったならば、オブジェクトと属性の名称と、その値がマ
ン−マシンインターフェイスに転送される。その値はマ
ン−マシンウィンドウに示される。

【０８２２】これによりシステムがランしているとき
に、どのオブジェクト／属性にもトラックすることがで
きるので、シェルを働かせるのには有力なツールであ
る。しかしもし、余りにも多くのオブジェクト／属性が
ＤＥＭＯＮを働かせると、システムが遅くなり、マン−
マシンウィンドウに印字される値の数が多くなる。

【０８２３】一度アプリケーションをテストしたら、Ｄ
ＥＭＯＮの使用は故障の表示の如く重要なブジェクト／
属性のために、リザーブしておくべきである。

【０８２４】ルールベース記述ファイル 各ルールベースは、三つのセクションより成る記述ファ
イルによって定義される。第一のセクションはＥＶＥＮ
ＴＳ（事象）と呼ばれる事象表現のリストである。この
表現は事象検知部が、ある知識源を、（それはアジェン
ダマネジャニ送るものであるが）発火すべき知識源のリ
ストに入れるかどうかを決定するために使われる。第二
のセクションはＰＲＥＣＰＮＮＤＩＴＩＯＮＳ（プレン
ディション）と呼ばれる事象表現のリストである。これ
らの表現はアジェンダマネージャが、ある知識源を与え
られた時間に、発火すべきかどうかをチェックするため
に使われる。

【０８２５】ＥＶＥＮＴＳ（事象）セクションについて
は、新しいデータの到着次第、とりかかれる事象の表現
に注意が必要である。各イベントの表現は、一つのソー
ス（ユーザインターフェイス、またはその他の知識源）
のみから到着した新しいデータを参照すべきである。全
てのデータは事象検知部を通じて送られるが、各データ
のソース（知識源またはユーザインターフェイス）は、
それを別々のバッチで送る。従って事象検知部は、たと
えもう一つのソースから到着したデータが同じタイムス
タンプを持っていても、ただ個々のバッチの中のデータ
が新しいと認識することができるだけである。一般的
に、表現の中で、一つ以上の“新しい”データポイント
の事象表現を書くときには、注意しなければならない。

【０８２６】ＰＲＥＣＯＮＤＩＴＩＯＮＳセクション
は、事象セクションに類似した表現を含んでいる。知識
源を規則的な時間感覚で発火するために、周期的な前提
条件を設定することができる。これは“ｅｖｅｒｙ
ｎ” 命令文を前提条件として設定することによって実
行される。ここに“ｎ”は秒で表した経過間隔である。

【０８２７】第三番目のセクションは仮説、障害、ルー
ルなどのルールベースの全ての要素を含むルールベース
構造を定義する。ルールベース記述ファイルはサフィッ
クス“，ｒｂ”によって識別される。ファイルフォーマ
ットの詳細を図２９、図３０、図３１に示す。

【０８２８】黒板構造記述ファイルは、黒板要素として
ルールベースの中に名付けられている全てのオブジェク
ト／属性が、黒板中の名前と性格に合うように、必要に
応じて参照し、編集すべきである。ミスマッチがある
と、ルールベースを適性に初期設定することができな
い。ルールベース記述ファイルを構築するために利用で
きる多くの演算子がある。ユーザは利用できる演算子及
びそれらの使用の詳細について“演算子及び表現へのガ
イド”を参照されたい。

【０８２９】ケース記述ファイル 各ケースベースは、同じく三つのセクションから成る記
述ファイルによって定義される。最初の二つのセクショ
ンは、上記のＥＶＥＮＴＳとＰＲＥＣＯＮＤＩ−ＴＩＯ
Ｎである。第三番目のセクションは数値付きのケースの
セットよりなるケースベースそれ自身である。ケース記
述ファイルはサフィックス“，ｃｂ”で識別される。フ
ァイルフォーマットの詳細は図３２、図３３に示されて
いる。

【０８３０】ルールベース記述ファイルについては、ケ
ースベースファイルの中のオブジェクト／属性が、黒板
のオブジェクト／属性と性格にマッチせねばならない。
そうでないとローディングエラーが発生する。

【０８３１】各ケースは連想づけられたケース値付きの
オブジェクト／属性のセットで構成されねばならない。
ケース値に使用されるタイムスタンプは比較のために必
要なタイム間隔を反映しなければならない。絶対時間は
重要ではない。例えば、もしある特定のケースで、一つ
のオブジェクト／属性が１０秒を越える特性値のセット
を持っているとき、最も最近のタイムスタンプと最も古
いタイムスタンプとの差は１０秒でなければならない。

【０８３２】入力データファイル このファイルは、シェルが実際のデータの到着をシミュ
レートするために使われるデータから成っている。入力
データファイルはサフィックス“，ｄａｔ”で識別され
る。ファイルのフォーマットをＳＤＤの図３４に示す。

【０８３３】入力データは明確なタイムスタンプを持つ
全てのデータが、一緒に、同一のデータセットの中にグ
ループ化された構成になっていると思われる。

【０８３４】オブジェクト／属性は、黒板名と性格に一
致していなければならない。もし名前のミスマッチがあ
ると、入力データファイルを走査した時にエラーが出
る。

【０８３５】入力データファイルの中のデータは、新し
いデータから古いデータへと時間順に表示されるように
なっている。

【０８３６】プログラムの用途 ユーザは、ドメインシェルが実行可能なファイルが存在
するディレクトリを使わなければならない。どこかよそ
に存在するファイルに対して、フルパスネームが使われ
ていない限り、全ての入力ファイルも、このディレクト
リの中になければならばい。出力ファイルもまたこのデ
ィレクトリの中に書き込まれる。プログラムは実行中
に、少なくとも五つのウィンドウをオープンするので、
現在オープンされているウィンドウの内の、ただ一つの
ウィンドウを表示することを推奨する。このウィンドウ
は表示画面のどこにあってもよいが、画面の左下隅に置
くことが望ましい。

【０８３７】プログラムは、まずプログラム名をタイプ
することから始まり、次いでシステムファイル名をタイ
プする。現在インストールされているごとく、プログラ
ム名はｕｓｅｒ ｉｎｔ．である。

【０８３８】この知識源の状態のコントロールは、テス
ト環境のみに影響を及ぼすことに注意されたい。知識源
を完全にアプリケーションから除外するには、開発者は
積極的に知識源を、アプリケーション開発環境の最上位
から削除しなければならない。 知識源がセットされた
後、開発者は知識源リストウィンドウのＯＫボタンをク
リックする。これにより、システムレベル制御パネルが
オープンされる。このパネルは、知識源名のラインが現
れないことを除いては、見かけ上は図９０に示される知
識源レベルテストのための制御パネルと同じである。テ
ストモードボタンも使用可能にはならない（システムレ
ベルのテストは常に制御部がテストされていることを暗
示する）。

【０８３９】システムレベルにおけるテストオペレーション システムレベルテストのためのテストオペレーション
は、ここに記載する知識源レベルテストのためのテスト
オペレーションと類似している。図９０に示すような制
御ウィンドウが現れる。開発者はＳｅｔ Ｏｐｔｉｏｎ
ｓ（セットオプション）ボタンを押して、テストモード
オプションを設定する。

【０８４０】テストモードオプション 開発者はテストを推進するために、テストモード環境に
関するパラメータを事前に定義することができる。これ
は図９２に示すテストモードデフォルト構成ウィンドウ
の中で行われる。このウィンドウは、セットオプション
ボタンを押すことにより、テストオペレーション制御ウ
ィンドウ（図９０）からアクセスできる。このウィンド
ウで設定されるオプションは、開発者が積極的に変更す
るまではウィンドウに残っている。これらのオプション
の目的は、開発者が余り介在していなくても、テストが
進行するように、あるテストモードパラメータを事前定
義することである。

【０８４１】ウィンドウの“テストすべき最終の知識源
使用？”のセクションは、知識源モードテストに適用さ
れる。“ｙｅｓ”を押すと、シェルのテスト環境は自動
的に知識源エディタによって保存された最終の知識源を
ロードする。“ｎｏ”を押すと、開発者は知識源テスト
を指定するときに、テストを希望する知識源を選択しな
ければならない。“ｙｅｓ”を使うと、知識源に対して
行われた変更の結果をテストするためのアクセスがより
早くなる。「アウトプットファイルネーム」フィールド
はテスト環境全体に適用される。ファイル名が「出力フ
ァイルネーム」フィールドの中に指定されると、シェル
は自動的に、これを出力ファイル名として使用する。も
しこのフィールドが空白であれば、開発者は各テストを
開始するときに、出力ファイル名を積極的に指定しなけ
ればならない。

【０８４２】データ源選定フィールドは、テストに使用
されるデフォルトのデータ源モードを指定する。もし空
白のままであれば、開発者はテストを始める度ごとに、
手動でデータ源を指定しなければならない。具体的なデ
ータ源がここで選ばれたならば、シェルは開発者が介在
しなくても自動的に希望したデータ源を使用する。もし
ファイルデータ源が指定されているならば、「タイムフ
ァクタ」フィールドには、希望した時間圧縮または伸張
ファクタが含まれているべきである。

【０８４３】ウィンドウの「知識源テストモード」セク
ションによって、開発者は知識源テストの為のデフォル
トテストモードを選ぶことができる。

【０８４４】「ｋｓ＋」コントロールを押すと、知識源
テストは直ちにデフォルトとしてコントロールテストを
含むようになる。「ｋｓ」のみを押した場合には、コン
トロールテストは知識源テストの中に含まれない。も
し、どちらのボタンも押さなければ、シェルは知識源テ
ストモードに関して何の仮定もせず、その選択は開発者
に委ねられる。

【０８４５】ウィンドウの「テストの構成を確認する指
示メッセージ？」セクションによって、開発者はテスト
モードにおいて検証を促すかどうかの選択をする。「ｙ
ｅｓ」を押すと、シェルは開発者がテストを進める前
に、テストモード構成情報を確認するよう促す。これに
よって、間違って現在存在する出力ファイルに重ね置き
することを防止できる。「ｎｏ」を押せば、このウィン
ドウ中に指定されたファイルは直ちにテスモードで使用
される（現在の出力ファイルは書き直されるかもしれな
い）。これにより開発者の介在を大幅に減少させること
ができる。

【０８４６】ドメインシェルプログラムは、ヒューレッ
ドパッカード９０００、シリーズ７００ファミリーワー
クステーション上で稼働するように設計されたものであ
る。ワークステーションはＨＰ−ＵＸオペレーティング
システムのバージョン８．０５または、より新しいバー
ジョンでランしなければならない。

【０８４７】ＨＰ−ＶＵＥビジュアルユーザ環境も存在
しなければならない。この環境はモティーフベースのＸ
ウィンドウシステム上に置かれる。ドメインシェルはＸ
タームウィンドウをこの枠組みの中で使用する。

【０８４８】シェルを使うために、ユーザはシステムに
使われる入力ファイルを作成しなければならない。従っ
てシェルの個々の入力ファイルの文法及び構成ととも
に、シェル全体の設計構想をよく知っておくことが有効
である。

【０８４９】入力ファイルの作成は、シェルのオペレー
ションに先だって行わなければならない。シェルを使用
するためには、次のファイルを作成しなければならな
い。すなわち、システムファイル、黒板構成記述ファイ
ル、各ルールベースに対する一つのルールベース記述フ
ァイル、各ケースベースに対する一つのケース記述ファ
イル、及び少なくとも一つの入力データファイルであ
る。これらのファイルの用途について、ここに述べる。
これらのファイルの位置は制限されていない。しかし、
それらがシェルの実行可能なファイルと同じディレクト
リに存在していなければ、ファイルのフルパスネームを
システムファイルの中で指定する必要がある。

【０８５０】システムファイル システムファイルは、黒板構成記述ファイルを識別する
ためのファイル名のリスト、及びそのシステムの全ての
ルールベース及びケース記述ファイルから構成されてい
る。システムファイルはサフィックス「．ｓｙｓ」によ
って識別されている。ファイルフォーマットが図２７に
示されている。

【０８５１】システムファイル中に名付けられたファイ
ルの順序が重要であることに注意されたい。黒板構成記
述ファイルが、まず一番に規定され、次いで全てのルー
ルベース記述ファイル、最後に全てのケース記述ファイ
ルの順になる。これは図２７に示した順序である。一行
につき一つのファイルが記述されねばならない。システ
ムファイルの中に規定した全てのファイルが存在しなけ
ればならない。さもないと初期状況設定エラーが起こ
る。

【０８５２】もしフルパスネームがシステムファイルに
使用されていないと、シェルはシステムファイルで指定
したファイルが、シェルの実行可能なファイルと共に、
同じディレクトリに存在すると判断する。

【０８５３】知識源ウィンドウを完全にオープンする
か、またはそれをアイコン化するかを決定するために利
用できるオプションがある。デフォルトシステムオペレ
ーションは、全ての知識源ウィンドウをアイコン化す
る。しかしもし「，ＮＯＲＭＡＬ」が知識源ファイル使
用ランの後に付いていると、その知識源プロセスで連想
づけられたウィンドウが完全にオープンされる。この機
能は、特定の知識源のオペレーションを詳細に観察する
には有効である。もし希望するなら、同じ「，ＮＯＲＭ
ＡＬ」サフィックスを全ての知識源ファイル仕様ライン
に付ければ、全て知識源ウィンドウは完全にオープンさ
れる。デフォルトの挙動（アイコン化された知識源）
は、知識源仕様ラインの後に「，ＩＣＯＮ」を付けるこ
とによって、明確に規定することができる。

【０８５４】黒板構成記述ファイル 黒板構成記述ファイルは、全てのオブジェクトの定義及
びケースオブジェクトに対する全ての属性を含んでい
る。オブジェクトと属性は、ユーザから与えられた名称
で識別される。黒板ファイルはサフィックス「，ｂｂ」
ＳＥ識別される。ファイルのフォーマットを図２８に示
す。

【０８５５】オブジェクト名及び連想づけられた属性
は、知識源記述ファイル及び入力データファイルの中で
使用される。シェルが適性に作動するためには、名称は
スペルとケースが性格に一致していなければならない。

【０８５６】タイプダブルの黒板データ値のみが許容さ
れる。明白に示された最大履歴長さはない。黒板はデー
タポイントを保持するから、この履歴長さの範囲内で受
け取る。もし履歴長さが知識源が要求するものより長け
れば、余分なメモリが使われ、システムが不必要に遅く
なる。これをチェックする良い方法は、知識源が要求す
る履歴長さをよく調べ、そして黒板履歴長さを適切に調
整することである。

【０８５７】黒板が受け取った重要なデータは、ＤＥＭ
ＯＮ、ＭＭＩ ＷＲＩＴＥ（ＭＭＩライト）が含まれ
る。黒板がこのオブジェクト／属性の新しい値を受け取
ったならば、オブジェクトと属性の名称と、その値がマ
ン−マシンインターフェイスに転送される。その値はマ
ン−マシンウィンドウに示される。

【０８５８】これによりシステムがランしているとき
に、どのオブジェクト／属性にもトラックすることがで
きるので、シェルを働かせるのには有力なツールであ
る。しかしもし、余りにも多くのオブジェクト／属性が
ＤＥＭＯＮを働かせると、システムが遅くなり、マン−
マシンウィンドウに印字される値の数が多くなる。

【０８５９】一度アプリケーションをテストしたら、Ｄ
ＥＭＯＮの使用は故障の表示の如く重要なオブジェクト
／属性のために、リザーブしておくべきである。

【０８６０】ルールベース記述ファイル 各ルールベースは、三つのセクションより成る記述ファ
イルによって定義される。第一のセクションはＥＶＥＮ
ＴＳ（事象）と呼ばれる事象表現のリストである。この
表現は事象検知部が、ある知識源を（それはアジェンダ
マネジャに送るものであるが）、発火すべき知識源のリ
ストに入れるかどうかを決定するために使われる。第二
のセクションはＰＲＥＣＯＮＤＩＴＩＯＮＳ（前提条
件）と呼ばれる事象表現のリストである。これらの表現
はアジェンダマネージャが、ある知識源を与えられた時
間に、発火すべきかどうかをチェックするために使われ
る。ＥＶＥＮＴＳ（事象）セクションについては、新し
いデータの到着次第で書かれる事象の表現に注意が必要
である。各事象の表現は、一つのソース（ユーザインタ
ーフェイス、またはその他の知識源）のみから到着した
新しいデータを参照すべきである。全てのデータは事象
検知部を通じて送られるが、各データのソース（知識源
またはユーザインターフェイス）は、それを別々のバッ
チで送る。従って事象検知部は、たとえもう一つのソー
スから到着したデータが同じ時間スタンプを持っていて
も、ただ個々のバッチの中のデータが新しいと認識する
ことができるだけである。一般的に、表現の中で、一つ
以上の「新しい」データポイントの事象表現を書くとき
には、注意しなければならない。

【０８６１】ＰＲＥＣＯＮＤＩＴＩＯＮＳ（前提条件）
セクションは、事象セクションに類似した表現を含んで
いる。知識源を規則的な時間感覚で発火するために、周
期的な前提条件を設定することができる。これは「ｅｖ
ｅｒｙ ｎ」命令文を前提条件として設定することによ
って実行される。ここに「ｎ」は秒で表した経過間隔で
ある。

【０８６２】第三番目のセクションは仮説、障害、ルー
ルなどのルールベースの全ての要素を含むルールベース
構造を定義する。ルールベース記述ファイルはサフィッ
クス「，ｒｂ」によって識別される。ファイルフォーマ
ットの詳細を図２９、図３０、図３１に示す。

【０８６３】黒板構造記述ファイルは、黒板要素として
ルールベースの中に名付けられている全てのオブジェク
ト／属性が、黒板中の名前と性格に合うように、必要に
応じて参照し、編集すべきである。ミスマッチがある
と、ルールベースを適性に初期設定することができな
い。ルールベース記述ファイルを構築するために利用で
きる多くの演算子がある。ユーザは利用できる演算子及
びそれらの使用の詳細について「演算子及び表現へのガ
イド」を参照されたい。

【０８６４】ケース記述ファイル 各ケースベースは、同じく三つのセクションから成る記
述ファイルによって定義される。最初の二つのセクショ
ンは、上記のＥＶＥＮＴＳ（事象）とＰＲＥＣＯＮＤＩ
ＴＩＯＮ（前提条件）である。第三番目のセクションは
数値付きのケースのセットよりなるケースベースそれ自
身である。ケース記述ファイルはサフィックス（，ｃ
ｂ）で識別される。ファイルフォーマットの詳細は図３
２、図３３に示されている。

【０８６５】ルールベース記述ファイルについては、ケ
ースベースファイルの中のオブジェクト／属性が、黒板
のオブジェクト／属性と正確にマッチせねばならない。
そうでないとローディングエラーが発生する。

【０８６６】各ケースは連想づけられたケース値付きの
オブジェクト／属性のセットで構成されねばならない。
ケース値に使用される時間スタンプは比較のために必要
なタイム間隔を反映しなければならない。絶対時間は重
要ではない。例えば、もしある特定のケースで、一つの
オブジェクト／属性が１０秒を越える特性値のセットを
持っているとき、最も最近の時間スタンプと最も古い時
間スタンプとの差は１０秒でなければならない。

【０８６７】入力データファイル このファイルは、シェルが実際のデータの到着をシミュ
レートするために使われるデータから成っている。入力
データファイルはサフィックス「，ｄａｔ」で識別され
る。ファイルのフォーマットをＳＤＤの図３４に示す。

【０８６８】入力データは明確な時間スタンプを持つ全
てのデータが、一緒に同じデータセットの中にグループ
化された構成になっていると考えられる。

【０８６９】オブジェクト／属性は、黒板名と正確に一
致していなければならない。もし名前のミスマッチがあ
ると、入力データファイルを走査した時にエラーが出
る。

【０８７０】入力データファイルの中のデータは、新し
いデータから古いデータへと時間順に表示されるように
なっている。

【０８７１】プログラムの用途 ユーザは、ドメインシェルが実行することのできるファ
イルが存在しているディレクトリを使わなければならな
い。どこかよそに存在するファイルに対して、フルパス
ネームが使われていない限り、全ての入力ファイルも、
このディレクトリの中になければならない。出力ファイ
ルもまたこのディレクトリの中に書き込まれる。プログ
ラムは実行中に、少なくとも五つのウィンドウをオープ
ンするので、現在オープンされているウィンドウの内
の、ただ一つのウィンドウを表示することが推奨され
る。このウィンドウは表示画面のどこにあってもよい
が、画面の左下隅に置くことが望ましい。

【０８７２】プログラムは、まずプログラム名をタイプ
することから始まり、次いでシステムファイル名をタイ
プする。現在インストールされているごとく、プログラ
ム名はｕｓｅｒ ｉｎｔ．である。

【０８７３】これは希望すればユーザによって変更でき
る。しかし他の実行可能なファイル名は変更すべきでな
い。

【０８７４】各々のドメインシェル処理に対して、黒
板、事象検知部、アジェンダマネージャ、マン−マシン
インターフェイス及び各知識源のウィンドウが開かれ
る。ウィンドウは全てＸ項ウィンドウで、再サイジン
グ、移動及びアイコン化が可能である。各ウィンドウに
はタイトルバーの中で、適切なタイトルが付けられる。
知識源ウィンドウは、各記述ファイル名によって識別さ
れる。知識源ファイルは全て基本的にはアイコン化され
るが（システムファイルの中でＮＯＲＭＡＬ（ノーマ
ル）ウィンドウオプションを指定しない限り）、ユーザ
が希望すればオープンすることができる。ポインタをウ
ィンドウの中に置き、コントロールキーを押したまま
で、マウスの左または中央のボタンをクリックして、希
望するオプションを選ぶことにより、ユーザは、ウィン
ドウで、各種の一覧を選び、オプションを追跡すること
ができる。ウィンドウのスクロールバーはマウスの制御
センタボタンをクリックし、「Ｅｎａｂｌｅ Ｓｃｒｏ
ｌｌｂａｒ（エネーブルスクロールバー）オプション」
を選ぶことにより使用可能になる。

【０８７５】ウィンドウのタイトルバーは、ウィンドウ
の中でランしている処理の識別をする（ユーザが前もっ
てオープンした標準ターミナルウィンドウであるユーザ
インターフェイスウィンドウだけは例外である）。知識
源は、それに連想づけられた知識源記述ファイル名で識
別される。ウィンドウがアイコン化されたときも、知識
源は依然として記述ファイル名で識別される。その他の
処理は短縮された２文字で識別される。すなわち黒板は
「ｂｂ」、事象検知部は「ｅｄ」、アジェンダマネージ
ャは「ａｍ」、そしてマン−マシンインターフェイスは
「ｍｍ」である。

【０８７６】ユーザとの対話の大部分は、プログラムが
スタートした第一ウィンドウで行われる。このウィンド
ウは、システムがセットアップされた後の最上位オプシ
ョンのメニューを提供する。そこには四つの選択肢があ
る。それはスタートデータ、継続データ、操作パラメー
タの設定及びセッションの終了である。

【０８７７】Ｓｔａｒｔ Ｄａｔｅ（スタートデータ）
オプション １ ユーザがこのオプションを選ぶと、入力データファイル
名を促してくる。次いで、セッションをランするために
リセットし、準備すべき知識源を全て表示する。入力デ
ータファイルを走査すると、プログラムはデータランの
ために必要な時間を、秒単位で打ち出してくる。ユーザ
には、データセットのランをより短い時間、またはより
長い時間で完了するために、タイムスケールを圧縮する
選択が与えられる。圧縮ファクタは、圧縮間隔を決める
データファイルから引用された時間間隔に区分される。
圧縮ファクタが設定されると、データが入力データファ
イルから読み込まれ、適当な時間に、事象検知部へ送ら
れ、検知部はそれを黒板へ転送する。システムは入力デ
ータがなくなるまで、知識源を適宜発火しながら作動す
る。情報メッセージは、データセットのランが進むに従
ってシェルウィンドウに現れる。ランが終わるとユーザ
インターフェイスウィンドウに最上位メニューが表示さ
れる。

【０８７８】黒板の作動は、黒板ウィンドウに‘＞’と
‘＜’のキャラクタを使って示される。データを黒板に
入れると、‘＞’のキャラクタが打ち出され、データが
黒板から引き出されると‘＜’のキャラクタが打ち出さ
れる。

【０８７９】事象検知部は、事象表現の評価が進むにつ
れて、三つの‘．’キャラクタのセットを打ち出す。ア
ジェンダマネージャもまた活動の完了を示す三つ
の‘．’キャラクタのセットを表示する。マン−マシン
インターフェイスは、黒板がデータを送ると、その送ら
れたデータをウィンドウに表示する。送られた各データ
ポイントは、オブジェクトと属性名と一緒に表示され
る。ＤＥＭＯＮ，ＭＭＩ ＷＲＩＴＥを持つオブジェク
ト／属性のみが、そして黒板が新しい値を受け取ったと
きのみに表示される。

【０８８０】データセットをランした後、スタートデー
タを再び選ぶと、黒板の中にある全てのデータは廃棄さ
れ、知識源は全てリセットされる。これは実質的にはセ
ッションを再びやり直すことになる。それ以降のデータ
でランを継続するには、オプション２継続データを使
う。

【０８８１】Ｃｏｎｔｉｎｕｅ Ｄａｔｅ（継続デー
タ）オプション２ このオプションでは、システムはデータセットをオプシ
ョン１・スタートデータと同じやり方でランさせる。し
かし継続データオプションの場合は、リセットするため
のメッセージは知識源に送られず、黒板データは以前に
したものの中から保存される。これにより、以前のデー
タセットラン中の操作結果として設定された現在の値を
使って、ルールベースは操作を継続することが許され
る。オプション１では、ユーザに入力データファイル名
を促してくる。このオプションが正確に作動するため
に、このファイルのデータは、以前のデータセットの中
の最後のデータより時間的に新しい時間スタンプから始
まらなければならない。以前のランのデータより古い時
間スタンプを持ったデータが黒板に送られると、黒板は
そのデータを、履歴のない属性に対する現在値として黒
板に格納する。しかしゼロでない履歴長さを有する属性
に対して、黒板は、その値を履歴の最新値の場所ではな
く、他の場所に挿入する。事象検知部は到着した「新し
い」データに基づいて、知識源を発火させるので不確定
な挙動が起こる。知識源がデータを黒板から取り出すと
き、そのデータは所在が不明で、知識源は多分に不正確
なデータポイントを使って発火する。

【０８８２】データラインがランしているとき、シェル
処理の見かけは、オプション１スタートデータのそれと
同じである。

【０８８３】Ｓｅｔ Ｏｐｅｒｅｔｉｎｇ Ｐａｒａｍ
ｅｔｅｒｓ（操作パラメータの設定）オプション３ このオプションによって、ユーザはルールベースに対す
るパラメータを設定することができる。このオプション
を選ぶと、ユーザにルールベース名を入力するように促
してくる。ルールベースのみが操作パラメータを設定す
るオプションを持っている。ケースベースの知識源はパ
ラメータ設定オプションを持っていない。

【０８８４】パラメータを設定するには、六つの選択が
ある。すなわち、Ｔｒａｃｅ、Ｌｏｇ、Ｓｔｅｐ、Ｂｒ
ｅａｋｐｏｉｎｔ、Ａｌｐｈａ／Ｂｅｔａ及びＳＦ／Ｎ
Ｆである。

【０８８５】ユーザがオプション３を選ぶと、ルール源
ファイル名を入力するように促してくる。これにより、
パラメータが設定されるべき知識源ファイルが指定され
る。現在はルールベースのみが設定可能なパラメータを
持っている。知識源ファイルが指定されると、設定すべ
きパラメータに対応するコードを入力するよう、ユーザ
に促してくる。

【０８８６】Ｔｒａｎｃｅ−Ｐａｒａｍｅｔｅｒ（トレ
ースパラメータ）０：このオプションを選ぶと、ユーザ
にトレーシング機能を禁止状態にするか、または設定す
るかの問い合わせがくる。設定にすると、ルールベース
中のケースルールが発火されたとき、ルールベースウィ
ンドウに表示されるべき詳細記述が表示される。

【０８８７】Ｌｏｇ−Ｐａｒａｍｅｔｅｒ（ログパラメ
ータ）オプション１：このオプションを選ぶと、ユーザ
にロギング機能を禁止状態にするか、または設定するか
の問い合わせがくる。設定にすると、ファイルに送るべ
きトレースオプションに対して生成されたものと同じ記
述が生成される。ファイルは、それを作成したルールベ
ース記述ファイルと同じで、さらに「，ｌｏｇ」の拡張
コードを持った名称が付けられる。

【０８８８】Ｓｔｅｐ／Ｐａｒａｍｅｔｅｒ（ステップ
パラメータ）オプション２：このオプションを選ぶと、
ユーザに、ステップ機能を使用不能にするか、または設
定するかを問い合わせてくる。設定にするとステップオ
プションは各ルールが発火された後、ルールベースを停
止する。ルールベースはユーザが、ルールベースウィン
ドウでルール発火を承認する回答をしたときのみ継続さ
れる。従ってこのオプションを設定したときには、ユー
ザは注意の焦点をルールベースウィンドウに切り換える
ことが必要である。

【０８８９】ルールベースが発火されたら、処理は中止
され、ユーザはルールベースの範囲内で選択を行使でき
る。データは黒板に継続して送られ、全ての他のシェル
処理は進行する。しかしそれ以上の知識源の発火は、ユ
ーザがルールベースのルールを通じて、ステッピングを
完了するまでは遅れる。従ってシェルの残りの部分の実
行は不可能になる。ステップオプションの目的は、ユー
ザのルールベースで一連のルール発火を、詳細にわたり
フォローさせることである。それを使用することは、一
般的には処理の実行タイミングを台無しにするので、そ
れはデバッグのために、一つの知識源を持った構成の中
のみで使用すべきである。

【０８９０】Ｂｒｅａｋｐｏｉｔ−Ｐａｒａｍｅｔｅｒ
（ブレークポイントパラメータ）オプション３：このオ
プションを選ぶと、ユーザはルールベースウィンドウの
中で、ルールのブレークポイントを設定したり、取り除
いたりできる。このオプションを使うためには、ユーザ
はブレークポイントを設定するのに適当なルールベース
ウィンドウに移動しなければならない。ルールベースウ
ィンドウの中でユーザはルールベースの任意のルールを
設定し、または取り除いたりできる。完了したらユーザ
は第一ウィンドウに戻って、最上位オプションを選択し
なければならない。 ステップオプションでは、ブレー
クポイントが設定されると、発火中はルールベース操作
は一時中断される。ブレークポイントは、シェルの性能
全体としてよりも、むしろルールベース作動の観察のた
めに使用される。言い替えれば、それはデバッグのため
に、ただ一つの知識源を持った構成の中のみで使うべき
である。

【０８９１】Ａｌｐｈａ／Ｂｅｔａ−Ｐａｒａｍｅｔｅ
ｒ（α／βパラメータ）オプション４：このオプション
を選ぶと、特定のルールベースに関して、α及びβ遮断
の大域値が設定できる。ユーザに対して、αとβの値
（−１．０から＋１．０）の入力を促してくる。これら
の値は指定されたルールベースに渡される。

【０８９２】ＳＦ／ＮＦ−Ｐａｒａｍｅｔｅｒ（ＳＦ及
びＮＦパラメータ）オプション５：このオプションを選
ぶと、特定のルールベースに関して、ルールの十分性係
数と必要性係数ファクター（ＳＦ及びＮＦ）の大域値が
設定できる。ユーザに対して、ＳＦとＮＦの値（−１．
０から＋１．０）の入力を促してくる。これらの値は指
定されたルールベースに渡される。

【０８９３】Ｅｎｄ ｔｈｅ Ｓｅｓｓｉｏｎ（セッシ
ョンの終了）オプション５：このオプションを選ぶと、
セッションは終了し、プログラムから抜け出す。アウト
プットファイルには以下に述べるように書き込まれる。
各知識源は診断のリストを含むログファイルを作成す
る。黒板は黒板入力ファイルからの構造情報を含む出力
ファイルと、現在の中に蓄えられているデータ値のスナ
ップショットを書き込む。

【０８９４】出力ファイル セッションが終了すると、各知識源は、操作の結果を含
む少なくとも一つの主力ファイルをプリントアウトす
る。ルールベースは、もしそのパラメータがパラメータ
設定オプションを通じて設定されていたならば、ログフ
ァイルをプリントアウトする。

【０８９５】データセットのラン後、セッションが終了
するたびごとに、システムに関する各々のルールベース
は診断の結果と共に、出力ファイルを生成する。このフ
ァイルはルールベース記述ファイルと同じルートファイ
ル名を持っているが、サフィックス「，ｏｕｔ」が付い
ている。ルールベースが発火されるごとに生成される診
断結果は、このファイルに書き込まれる。書き込まれる
データには診断結果と、発火されたルールの数、及び１
秒あたり発火されたルールの数が含まれる。

【０８９６】ログオプションをルールベースとして選ぶ
と、出力ログファイルが生成される。このファイルは、
ルールベース記述ファイルと同じルートファイル名を持
っているが、サフィックス「．ｌｏｇ」が付いている。
これにはルールベースの操作の手順を指示する詳細なメ
ッセージを含んでいる。

【０８９７】ケースベースの処理はケースをスコアにし
た結果を、ケース記述ファイル名ルートと同じルート名
で、サフィックス「．ｏｕｔ」を付けて書き込む。ファ
イルは、データセットランの全部にわたりスコアした結
果の記録を含む。

【０８９８】黒板は、全ての入力ファイルからのオブジ
ェクト及び属性情報に加えて、現在黒板に記憶されてい
る全てのデータを含む出力ファイルを作る。このファイ
ルは、これ以降のセッションランの入力ファイルとして
使用することができる。この場合、入力データセットに
は、黒板の中にある最新のデータにより時間的により新
しい時間スタンプを含むべきである。そうでないと不確
定な処理になってしまう。

【０８９９】エラー シェルを使用するときに遭遇するエラーは、一般的には
二つのカテゴリーに分けられる。それは構文／ローディ
ングエラーと論理エラーである。もし特定の知識源にエ
ラーがあると、ファイルの中でエラーが存在するライン
番号を識別するエラーメッセージが打ち出される。エラ
ーメッセージはユーザインターフェイスに送られる。そ
の結果、ユーザインターフェイスはシェルの処理を止
め、それから抜け出す操作をする。

【０９００】論理エラーは不正確なルールその他によ
り、知識源ファイルの中に含まれる情報が、意図する性
能と対応していないことによって生ずる。これらのエラ
ーは突き止めるのが困難である。

【０９０１】シェルは、個々のシェルプロセスの動作を
フォローするのを助けるいくつかのツールを提供する。
これらは、ルールベースに対するセットパラメータオプ
ションを含む。また、黒板に入れられたオブジェクト／
属性の値は、ＤＥＭＯＮ機能を使ってマン−マシンウィ
ンドウにプリントされる。出力ファイルはすべて、エラ
ー発見を支援するものとして使うことができる。

【０９０２】ケースベース診断の例： インテリジェントノートブック 背景 このアプリケーションは、非常に大量の電子製品を、そ
の全寿命サイクルにわたってサポートする、大規模修理
デポであるWestinghouse電子修理センターのために開発
されたものである。修理のために返品されたユニット
は、通常先ず最初に診断する必要がある。これは先ずそ
のユニットに対して、自動テスト装置(ATE) を使って一
連のテストを行うことである。このステップは、機能的
に障害のあるユニットを指摘するものであって、実際の
部品の故障に関するものでない、一組の合格／不合格の
結果を生成する。ATE テストがすむと、ほとんどの場
合、修理候補UTT(ユニットアンダーテスト) のテストに
従事するテスト技術者による専門的な診断が行われる。
技術者の修理対策技術と専門的診断は、最初は試行錯誤
し、次第にUTT の動作の理解を通じて修得する経験を経
て培われたものである。製品が成熟するに連れて所定の
UTT の返品数が減ったり、退職等のような様々な理由の
ため、専門的知識はユニットの運転生命が終了する前に
失われることがしばしば起きる。この専門的知識を維持
しながら、このプロセスにおいて技術者の日々の作業を
助けることがこのアプリケーションの主要目的であっ
た。

【０９０３】ルールベースとモードベースのアプローチ 知識の修得と操作が中心問題であったため、エキスパー
トシステム技術を適用するのが適当であると考えられ
た。事実、当時(1980 年代所期) は、ルールベースシス
テムは、他の電子診断領域で使用されていた。あるクラ
スのユニットを診断するプットタイプシステムが１年が
かりで開発された。その後すぐにいくつかの限界が発見
され、このアプローチは実際的でないと判断された。こ
の努力の段階における決定的な制約は、これを有用なア
プリケーションにするには数百にのぼるエキスパートシ
ステムの開発が必要なことであった。その時点では、二
つの異なる方向が追求された。その内の一つは、「第一
原則」または深部におよぶ診断であった。このアプロー
チは有望なものであったが、見込みのあるアプリケート
ョンが実施され始めるようになるまででも数年を要し
た。この研究の結果は、補遺Ｂに簡単に説明する。

【０９０４】ケースベースアプローチ ほとんどの問題の解決において、戦いの半分は問題を正
しく整理することにある。この場合には、テスト技術者
達が採用した方法論を検討することによって、問題の再
整理が行われた。その結果、これらの技術者達が自分の
仕事を遂行するために使った方法を真似るアプローチが
最も妥当であることが明らかになった。その基本的認識
は、技術者達が長期に旦って彼らの知識を蓄積してきた
ということであった。このために彼らが使ったツール
は、技術者の日誌であって、これはテストしたユニット
毎に記入された日記のようなものであった。しかしなが
ら、この日誌は、内容が順を追って記入されて行くた
め、古い記録を探すのが次第に困難となり、時間の経過
とともにその価値を失って行った。一方、この日誌は過
去の事例の集成であり、経験豊かな技術者が行った診断
プロセスは、基本的に事例を探し出すプロセスであっ
た。このアプリケーションに対してはケースベースのア
プローチが妥当なことは明らかであった。

【０９０５】図９３は、インテリジェントノートブック
システムの簡素化したブロック図である。事例の記憶
は、常に増大する過去の事例を保管している。各事例は
次のものから構成される。

【０９０６】１．連続／部品番号：UTT の種類を唯一に
識別する ２．ATE テスト結果パターン：その種類のユニットに対
する特定のテスト手順によって番号が付けられる。

【０９０７】３．他の症状：視覚による観察（焼跡、遺
失部品、飛び散った半田、他）、テスト箇所で行われた
測定、誤動作の記述、その他。

【０９０８】４．対象：UTT の修理のために取られたス
テップ ５．コメント：自由形式の文章。

【０９０９】６．記入者名、記入日。

【０９１０】最初の三つの項目は、事例を探すのに使わ
れる。連続／部品番号とテスト結果は、ATE から自動的
に得られる。これらは検索の最初の段階で使われる。こ
の最初の段階で発見された事例に係わる他の症状に基づ
いて、ユーザからも情報が収集され、事例の件数を絞り
込むのに使われる。ユーザは最も妥当な事例を選び、新
しい事例をデータベースに書き加える前に必要に応じて
編集（集成と修理）を行う。同様にして、もし事例が無
かった場合は、その新しい事例をデータベースに追加す
る。いずれの場合も、これらの処理を要約した報告書が
プリントされる。

【０９１１】点線で結ばれた左側の３ブロックは、計画
されているシステムの拡張を示す。一番上のボックスは
別の環境では別の機能を使う必要性を説明する類似性測
定手法への拡張を示す。この拡張は得意先（Westinghou
se電子修理センター）によって行われている。真中のボ
ックスは、蓄積された多数の例（事例）を利用するため
の誘導機能の組み込みを取り扱う。その目的は、事例の
記録の検索時間の短縮である。コスト効率分析の結果、
この拡張はこのアプリケーションでは必要ないことが判
明し、そのため実施されるには至らなかった。第三の拡
張は、主として記入された項目の文章部分を使った索引
の改善を主たる目的とした疑似自然言語の使用を含むも
のであった。この拡張は、記入内容の「他の症状」のた
めに部分的に実施されるに留まった。

【０９１２】モデルベース診断例： Westinghouseエキスパート診断システム WSTCはWestinghouseエキスパート診断によるモデルベー
ス診断を使って成功を収めた。このシステムは三種類の
モデルベース診断を提供する。ドメインシェルに対する
モデルベースのフレームワークは、この技術をプラント
ドメインに適用させて、WEDSで発見されたものと類似の
抑制停止手段を用いる。

【０９１３】WEDSで用いられた診断の第一のタイプは、
発見的証明法と呼ばれるものである。これは、シミュレ
ーションモデルが使えないシステムに有効である。実際
のセンサ計測が行われるそれらの箇所を結ぶことによっ
て、診断されるシステムの「バーチャル」系統図が形成
される。システムはこの情報をつかって、自動テスト装
置(ATE) の計測シーケンスの管理用に使われる情報を推
測することができ、それによって電子回路モジュールの
診断速度を早めることになる。この種の診断はある種の
アプリケーションには有効であるが、実際のシミュレー
ションモデルが無いため、この形式のモデルベース診断
の有効性には限界がある。

【０９１４】WEDSで使われている第二のモデルベース診
断はシミュレーションである。これはシステムの行動の
複雑なシミュレーションモデルが有効な場合に使用され
る。故障の症状はモデルのフレームワークの中でシミュ
レートされ、可能性のある故障の候補のグループが生成
される。この診断形式は、シミュレーションモデルの枠
組みの中で表現できるあらゆるタイプの故障を取り扱う
ことができる。そのため、すべての可能性のある故障モ
ードを完全に検索できる。しかしながら、検索時間は非
常に長く、診断に要する時間も長くなる。この点がこの
技術の有効性の限界である。

【０９１５】ここで示す例はWEDSで使われている第三の
診断形式で、抑制停止によるシミュレーションである。
この例はデジタル論理回路を特徴とするが、ここに示す
概念は、モデルベース診断の前提条件が満足されれば、
別の種類のシステムにも適用できる。このシステムのモ
ジュール形式によるブロック図は図９４に示す通りであ
る。ここには六つの測定ができる人力と二つの測定でき
る出力がある。その内部構造は六つのモジュールを示
し、それぞれが独自の関係を持っている。この例は、デ
ジタル論理関係AND およびORを使い、下記のバラグラフ
で説明される例外を除いて、各モジュールに対して、別
の二つの値を与えるとある値が得られる。AND 及びORモ
ジュールにおいては、入出力の値のある組合わせにより
他の出力を決定することができなくなる。例えば、AND
ゲートのある入力が誤であり、その出力が誤である時
は、他の入力の値を決めることができない。これは、必
ずしも全てでないI/O 関係が完全に指定されている例で
あり、この抑制停止技術は、診断を行うためにどの関係
かと言うことを利用する。

【０９１６】ここで説明するように、制御停止モデルベ
ース診断計画のモデルとなるいずれのシステムに対して
も要求されることは、指定を過剰にするということであ
る。つまり、全ての内部的な値を完全に決定するのに最
低限必要とされる以上の測定されたパラメータがあると
言うことである。そうでない場合は、抑制の一つを解除
すると指定が不足するシステムが生まれ、何時でも不一
致が起こり得ないことになる。

【０９１７】この例においては、六つのモジュールのそ
れぞれが関係を持つことを想定する。各モジュールは三
つのポート値を持ち：そのため、全部で１８ポートでそ
のシステムを完全に指定できる。システムのトポロジー
が六つの関係を１８ポートの変数に配分する。八つの測
定可能な値（入力値と出力値）をポートへの接続は、八
つの機能的な関係を与える。そのため、六つのモジュー
ルの関係があれば、１８パラメータのシステムでは、全
部で２０の関係が存在する。従って、このシステムは要
求通りに過剰に指定されている。

【０９１８】例えば、人力に基づくシミュレーションを
使って、測定された出力、OUT2、と対応するシミュレー
ション出力の間に不一致が発見されたと仮定する。目的
は、食い違いの原因となり得る障害のリストを作成する
ことである。

【０９１９】別の情報（ルールベースからのように）に
よって、モジュールＡの障害が不一致の原因として示唆
される。モジュールＡとその入力の関係が解除され、不
一致が発見されるまでまたは計算がつきるまで、残りの
１９の関係がシミュレーションで用いられる。この例で
は、計算の流れは、モジュールＢ、Ｃ、Ｅ、ＦおよびＤ
の関係を、この順序で使って進められる。モジュールＤ
のシミュレーションによる出力と測定値とに不一致があ
り、モジュールＡは測定された不一致の原因の候補では
無いことになる。抑制停止の方法を同じように適用する
と、モジュールＤも故障の原因の候補でないことが明ら
かになる。この様にして可能性のある故障を決定するこ
とは、システムのトポロジーに関係するものであって、
そのモジュールの入力と出力の間の機能的な関係の正確
な性質に関係するものでは無いことに注意すべきであ
る。この種のトポロジー情報をコンパイルして、実行時
環境において高速で使うことができる。

【０９２０】別の場合においては、不一致の決定に機能
的関係が重要になり得ることに注意のこと。この例で
は、モジュールＢの障害が原因から除外される。モジュ
ールＢの抑制が停止されると、診断はモジュールＡ、
Ｄ、ＦおよびＥに対して行われる。この時点で、モジュ
ールＥの出力に不一致が発見され、モジュールＢの障害
が除外される。同様にモジュールＣも原因から除外され
る。

【０９２１】この例においては、抑制解除技術により、
故障の可能性のあるモジュールの数は６から２に減らさ
れた。測定を続けることによりこれをさらに減らすこと
ができ、この様にして故障したモジュールを唯一に突き
止めることができる。言い替えれば、大規模に測定され
たシステム（過剰な抑制の度合が強い）では、抑制緩和
の方法を使うことによって、故障の可能性のあるリスト
を大幅に絞り込むことができる。

【０９２２】この抑制停止方法は階層的なやり方で複雑
なシステムでも対応することができる。そうすることに
より、故障したモジュールの探索を、役立つモデルが許
す限り詳細に行うことができる。

【０９２３】以上、本発明の限定数の実施例を説明して
きたが、当業者には他にも多数の実施態様とその改良が
あること、それらが付属請求事項に定義される本発明の
範囲に含まれていると考えられることは明らかである。

【０９２４】

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

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図３８】典型的なデータコレクションと前処理システ
ムを示すブロック線図である。

【図３９】データ獲得システムに対するインタフェイス
を示すブロック線図である。

【図４０】黒板オブジェクト構造のリストを表す説明図
である。

【図４１】リンクオブジェクト構造のリストを表す説明
図である。

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

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

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

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

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

【図４７】詳細システムのプロトタイプブロック線図で
ある。

【図４８】ケースベース診断の時間曲線を示す図であ
る。

【図４９】代表的なセレクションリストウィンドウの図
である。

【図５０】代表的な警告ウィンドウの図である。

【図５１】トップレベルデベロッパのウィンドウの図で
ある。

【図５２】新しい応用ダイヤログウィンドウの図であ
る。

【図５３】トップレベル黒板エディタウィンドウの図で
ある。

【図５４】オブジェクト／属性／値表示の図である。

【図５５】値エディタウィンドウの図である。

【図５６】トップレベル制御エディタウィンドウの図で
ある。

【図５７】システムプロセス表示の図である。

【図５８】トップレベルのルールベースのエディタウィ
ンドウの図である。

【図５９】コンスタントエディタウィンドウの図であ
る。

【図６０】コンスタントエディタウィンドウの図であ
る。

【図６１】データノードエディタウィンドウの図であ
る。

【図６２】評価エディタウィンドウの図である。

【図６３】仮説エディタウィンドウの図である。

【図６４】機能障害エディタウィンドウの図である。

【図６５】メタノールエディタウィンドウの図である。

【図６６】区分線形関数エディタウィンドウの図であ
る。

【図６７】ルールエディタウィンドウの図である。

【図６８】ルールエディタウィンドウのオプションを示
す図である。

【図６９】可変エディタウィンドウの図である。

【図７０】フレームライブラリ表示の図である。

【図７１】フレーム表示の図である。

【図７２】データソース表示の図である。

【図７３】記号表の表示の図である。

【図７４】記号表示の図である。

【図７５】ケースアクション表示の図である。

【図７６】アクション表示の図である。

【図７７】ケースベースの表示の図である。

【図７８】ソースセレクト表示の図である。

【図７９】ケースデータ表示の図である。

【図８０】ケースデータ表示の図である。

【図８１】実行時最上位エディタの最上位画面の図であ
る。

【図８２】システム表示詳細図である。

【図８３】グラフ詳細エディタの図である。

【図８４】テーブル詳細図である。

【図８５】メニュー詳細図である。

【図８６】制御ウィンドウの図である。

【図８７】実行時一覧のプレ一覧の例を示す図である。

【図８８】知識源制御パネルのウィンドウの図である。

【図８９】手動入力データのエントリウィンドウの図で
ある。

【図９０】試験動作ウィンドウの図である。

【図９１】システム試験知識源配置のウィンドウの図で
ある。

【図９２】試験モードオプションのウィンドウの図であ
る。

【図９３】インテリジェントノートブックのウィンドウ
の図である。

【図９４】モデルベース推論の詳細例の図である。

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

Claims (53)

【特許請求の範囲】
1. 【請求項１】 プラント運転シミュレーション用の人工
   知能ソフトウェアシェルであって、工場の構成要素と概
   念とを表すオブジェクトを持つデータベースを備えた黒
   板モジュールと、人工知能動作スキムを含み、前記黒板
   モジュールと交信しながら、予め定義済みの特定の黒板
   オブジェクトに対して動作する、少なくとも一つの知識
   源モジュールと、前記黒板モジュールと交信しながら、
   ユーザが黒板の状態に関する情報を一覧することができ
   るようにするユーザインターフェイスモジュールと、前
   記黒板モジュールならびに少なくとも一つの知識源と交
   信しながら、入力データを受信し、少なくとも一つの知
   識源の動作を制御する制御モジュールと、を含むことを
   特徴とする前記人工知能ソフトウェアシェル。
2. 【請求項２】 請求項１に記載のソフトウェアシェルで
   あって、その中の前記制御モジュールが、前記ユーザイ
   ンターフェイスモジュールと交信しながら、少なくとも
   一つの知識源が実行を始めるべき時点を判断する一つの
   事象検知部モジュールと、少なくとも一つの知識源モジ
   ュールならびに前記事象検知部モジュールと交信しなが
   ら、予め定められた知識源優先スキムに従い、少なくと
   も一つの知識源を実行させる活性化／アジェンダマネー
   ジャモジュールと、を含むことを特徴とする前記ソフト
   ウェアシェル。
3. 【請求項３】 請求項１に記載のソフトウェアのシェル
   であって、その中で少なくとも一つの知識源モジュール
   が、連想づけられた信念レベルを用いたif-then-else形
   式のルールを含む前向き連鎖信念伝播スキムを持つルー
   ルベース知識源モジュールと、予め定義されたパターン
   と条件を含み、受信したデータと前記パターンの間に所
   定の一定レベルの近似度が見出される場合は、前記条件
   が真であると推論するデータ比較スキムを持つケースベ
   ース知識源モジュールと、を含むをことを特徴とする前
   記ソフトウェアシェル。
4. 【請求項４】 請求項２に記載されたソフトウェアのシ
   ェルであって、その中で少なくとも一つの知識源モジュ
   ールが、連想づけられた信念を用いたif-then-else形式
   のルールを含む前向き連鎖信念伝播スキムを持つルール
   ベース知識源モジュールと、予め定義されたパターンと
   条件を含み、受信したデータと前記パターンの間に所定
   の一定レベルの近似度が見出される場合は、前記条件が
   真であると推論されるデータ比較スキムを持つケースベ
   ース知識源モジュールと、を含むことを特徴とする前記
   ソフトウェアシェル。
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. 【請求項２４】 請求項２３に記載されたソフトウェア
    のシェルであって、その中でデータを受信して制御する
    手段が、イネーブル状態をもたらす手段と交信しなが
    ら、少なくとも一つの知識源モジュールを実行させるべ
    き時期を判定するための手段と、少なくとも一つの知識
    源モジュール及び前記判定手段と交信しながら、予め定
    められた知識源の優先スキムに従い、少なくとも一つの
    知識源を実行させるための手段と、を有することを特徴
    とする前記ソフトウェアシェル。
25. 【請求項２５】 請求項２４に記載のソフトウェアのシ
    ェルであって、その中で少なくとも一つの知識源モジュ
    ールが、連想づけられた信念のレベルを用いたif then
    else形式のルールを含む前向き連鎖信念伝播スキムを持
    つルールベース知識源モジュールと、予め定義されたパ
    ターンと条件を含み、ただしケースベース知識源の実行
    後に、受信したデータと前記パターンの間に所定の一定
    レベルの近似度が見出される場合は、前記条件が真であ
    るとする推論するデータ比較スキムを持つケースベース
    知識源モジュールと、を有することを特徴とする前記ソ
    フトウェアシェル。
26. 【請求項２６】 請求項２５に記載のソフトウェアのシ
    ェルであって、その中でさらに少なくとも一つの知識源
    モジュールが、シミュレーション関係と推論関係とを有
    して相互に接続されたモジュールを備えるモデルベース
    知識源を含むことを特徴とする前記ソフトウェアシェ
    ル。
27. 【請求項２７】 請求項２５に記載のソフトウェアのシ
    ェルであって、その中で前記記憶手段が垂直階層間接続
    群と水平リンク群とを持つオブジェクトの階層構造を備
    えるデータベースを含むことを特徴とする前記ソフトウ
    ェアシェル。
28. 【請求項２８】 請求項２７に記載のソフトウェアのシ
    ェルであって、その中でオブジェクトの各々が属性を持
    ち、しかも各属性が、少なくとも一つの値と、ハッシュ
    テーブルを含むデータベースと、オブジェクトをそれに
    対応する属性及び値と結合するための複数のポインタ
    と、を有することを特徴とする前記ソフトウェアシェ
    ル。
29. 【請求項２９】 請求項２８に記載のソフトウェアのシ
    ェルであって、その中で前記垂直階層間接続がIS-A階層
    間接続とPART-OF 階層間接続を含むことを特徴とするソ
    フトウェアシェル。
30. 【請求項３０】 請求項２５に記載のソフトウェアのシ
    ェルであって、その中で前記実行手段が、優先順位の低
    い一つの知識源の実行動作に割り込みをかけて、前記知
    識源優先スキムに従い、その知識源より優先順位の高い
    知識源を実行させる手段を含むことを特徴とする前記ソ
    フトウェアシェル。
31. 【請求項３１】 請求項２５に記載のソフトウェアのシ
    ェルであって、その中で前記判定手段が入力データを受
    信して知識源実行の前提条件が満足される実行時点を判
    定する手段を含む事を特徴とする前記ソフトウェアシェ
    ル。
32. 【請求項３２】 請求項２５に記載のソフトウェアのシ
    ェルであって、さらに、オブジェクトの名称及びオブジ
    ェクトの属性／値の対を含む、黒板構造記述ファイル
    と、前記ルールベース知識源を形成するルールならびに
    前記ルールベース知識源実行のための前提条件の記述を
    含むルールベース記述用ファイルと、前記ケースベース
    知識源を形成するケースならびに前記ケースベース知識
    源実行のための前提条件の記述を含む、一つのケースベ
    ース記述用ファイルと、実行時診断サイクルの入力デー
    タをシミュレートするデータの複数の組とそれに対応す
    る時間の常時記号を持つリンクされたリストを含む入力
    データファイルと、を含み、ただしその中で前記黒板構
    造記述ファイル、前記ルールベース記述ファイル及び前
    記入力データファイルはユーザによって作成されること
    を特徴とする前記ソフトウェアシェル。
33. 【請求項３３】 請求項３２に記載のソフトウェアのシ
    ェルであって、さらに、各入力データファイル作成サイ
    クルが完了するたびに前記シェルによって作成される診
    断ファイルであって、前記ルールベース知識源によって
    作られる診断と、前記ケースベース知識源によって見出
    されたケースの整合を含む診断ファイルと、前記シェル
    によって作成される黒板状態ファイルであって、ケース
    の入力データファイル作成サイクルの完了後に何らかの
    知識源によって修正される黒板情報を含む黒板情報ファ
    イルと、を有することを特徴とする前記ソフトウェアシ
    ェル。
34. 【請求項３４】 請求項２５に記載のソフトウェアのシ
    ェルであって、さらに相互接続のためのストリームソケ
    ットを含み、そのソケットが一対の要求−応答の形式に
    なっているメッセージの通信を行うことを特徴とする前
    記ソフトウェアシェル。
35. 【請求項３５】 請求項３４に記載のソフトウェアのシ
    ェルであって、その中で前記ソケットがデータ指向型ソ
    ケットと制御指向型ソケットを含むことを特徴とする前
    記ソフトウェアシェル。
36. 【請求項３６】 請求項３５に記載のソフトウェアのシ
    ェルであって、その中でデータ指向型ソケットが、受信
    確認メッセージと、故障通告メッセージと、データ要求
    メッセージと、データ供給済みメッセージと、知識源リ
    ストのメッセージと、を含む各種メッセージを伝達する
    ことを特徴とする前記ソフトウェアシェル。
37. 【請求項３７】 請求項３６に記載のソフトウェアのシ
    ェルであって、その中で前記制御指向型ソケットが、動
    作開始メッセージと、動作停止メッセージと、プロセス
    活性化メッセージと、パラメータ設定メッセージと、受
    信確認メッセージと、故障通告メッセージと、を含む各
    種メッセージを伝達することを特徴とする前記ソフトウ
    ェアシェル。
38. 【請求項３８】 人工知能のソフトウェアのシェルを用
    いてプラント運転のシミュレーションを行う方法であっ
    て、次のステップ、すなわちプラントの各種構成要素と
    概念とを表すオブジェクトをデータベースに格納するス
    テップと、入力データファイルから入力データを読み取
    るステップと、予め定められた知識源の優先スキムに従
    って人工知能の知識源を実行させる時点を判定するステ
    ップと、前記判定に従って予め定義されたオブジェクト
    に関して知識源を実行させるステップと、を含むことを
    特徴とする方法。
39. 【請求項３９】 請求項３８に記載の方法であって、そ
    の中で知識源を実行させる前記ステップがオブジェクト
    の値を更新するステップを含むことを特徴とする方法。
40. 【請求項４０】 請求項３８に記載の方法であって、そ
    の中で知識源を実行させる前記ステップがさらに次のス
    テップ、すなわち、連想づけられた信念のレベルを用い
    てif-then-else形式のルールを含む前向き連鎖信念伝播
    スキムを持つルールベースの知識源を実行させるステッ
    プと、予め定義されたパターンと条件を含むデータ比較
    スキムを持つケースベース知識源を実行するステップ
    と、を含むことを特徴とする方法。
41. 【請求項４１】 請求項４０に記載の方法であって、そ
    の中でケースベース知識源を実行させる前記ステップ
    が、受け取られたデータと前記パターンとの間で所定の
    一定レベルの近似度性が見出される場合に、前記条件が
    真であると推論するステップを含むことを特徴とする方
    法。
42. 【請求項４２】 請求項３８に記載の方法であって、そ
    の中で前記格納ステップが、オブジェクト、属性及び値
    を格納するステップを含み、各オブジェクトは属性を持
    ち、各属性は少なくとも一つの値を持つことを特徴とす
    る方法。
43. 【請求項４３】 請求項４２に記載の方法であって、そ
    の中で前記格納ステップがさらに、ハッシュテーブル
    と、各オブジェクトをそれに対応する属性及び値と結合
    する複数のポインタと、を有するデータベースを作成す
    るステップを含むことを特徴とする方法。
44. 【請求項４４】 請求項４３に記載の方法であって、そ
    の中で前記データベース作成ステップが、オブジェクト
    の階層状リンク群を作成するステップを含むことを特徴
    とする方法。
45. 【請求項４５】 請求項３８に記載の方法であって、そ
    の中で前記知識源ステップが、優先順位の低い一つの知
    識源の実行動作に割り込みをかけて、前記知識源優先ス
    キムに従い、その知識源より優先順位の高い知識源を実
    行させるステップを含むことを特徴とする方法。
46. 【請求項４６】 請求項４５に記載の方法であって、そ
    の中でさらに前記知識源実行ステップが、前記割り込み
    ステップの後で割り込みをかけられた知識源を実行計画
    の中に再度組み入れるべきかどうかを判定するステップ
    を含んでいることを特徴とする方法。
47. 【請求項４７】 請求項４６に記載の方法であって、そ
    の中でさらに前記知識源実行ステップが、割り込みをか
    けられた知識源を実行計画の中に再度組み入れるべきか
    どうかを判定した後で、その判定に従って当該知識源を
    実行計画の中に再度組み入れるステップを含んでいるこ
    とを特徴とする方法。
48. 【請求項４８】 請求項３８に記載の方法であって、そ
    の中で前記判定ステップがいつ知識源を実行すれば前提
    条件が満足されるかを判断するステップを含んでいるこ
    とを特徴とする方法。
49. 【請求項４９】 請求項４０に記載の方法であって、さ
    らに次のステップ、すなわち、オブジェクトの名称及び
    各属性との値の対を含む黒板構造記述ファイルを生成す
    るステップと、前記ルールベース知識源記述ファイルを
    生成するステップと、各種のケースならびに実行のため
    の前提条件の記述を含む、ケースベース記述ファイルを
    生成するステップと、実行時診断サイクルの入力データ
    をシミュレートするデータの複数の組とそれに対応する
    時間の表示記号を持つリンクされたリストを含む入力デ
    ータファイルを生成するステップと、を含むことを特徴
    とする方法。
50. 【請求項５０】 請求項４９で請求に記載の方法であっ
    て、さらに次のステップすなわち：前記ルールベース記
    述ファイルからルールベース知識源モジュールを生成す
    るステップと、前記ケースベース記述ファイルから一つ
    のケースベース知識源モジュールを生成するステップ
    と、を含むことを特徴とする方法。
51. 【請求項５１】 請求項４０に記載の方法であって、さ
    らに次のステップすなわち、前記ルールベース知識源に
    よって作られる診断内容と、前規ケースベース知識源に
    よって、見出されたケースの整合を含む診断ファイルを
    生成するステップと、実行期間中に何らかの知識源によ
    って修正される黒板情報を含む黒板情報ファイルを生成
    するステップと、を含むことを特徴とした方法。
52. 【請求項５２】 請求項３８に記載の方法であって、さ
    らにソケット経由により各種モジュール間で要求−応答
    の形式のメッセージ通信を行うステップを含むことを特
    徴とする方法。
53. 【請求項５３】 請求項４０に記載の方法であって、そ
    の中で前記記載知識源実行ステップが、さらにシミュレ
    ーション関係ならびに推論関係を有し相互に接続された
    各種モジュールを持つモデルベース知識源を実行させる
    ステップを含むことを特徴とする方法。