(57)【要約】保守システムをモデル形成する方法であって、その構成は、部品データベースと信頼性データベースとを有する計算機システムを用意することと；部品データベースに向けて、保守システムの一部として保守がされることになるいくつかの部品の状態に関する部品データを入力することと；信頼性データベースに向けて、部品データベース内の部品データにより表わされている少くとも一つの部品の予測された性能に関する信頼性データを入力することと；部品と信頼性データ間の予め定義された関係に従って、前記少くとも一つの部品に関する保守予測を表わしている出力データを計算することとを備えている。【選択図】図１
2004501447.tif 000002
【特許請求の範囲】
【請求項１】
保守システムをモデル化する方法であって、
部品データベースと信頼性データベースとを有する計算機システムを用意する段階と；
該部品データベースに向けて、該保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力する段階と；
該信頼性データベースに向けて、該部品データベース内の部品データによって表わされた少くとも一つの部品についての予測される性能に関する信頼性データを入力する段階と；
該部品と信頼性とのデータ間の予め規定された関係に従って、前記少くとも一つの部品に関する保守予測を表わしている出力データを計算する段階とを備えている方法。
【請求項２】
請求項１記載の方法であって、該信頼性データベースは２以上の信頼性データのサブセットを含み、該出力データを計算する段階は所定の階層構造の規則に従って信頼性データ組の唯一つにアクセスすることを含んでいる方法。
【請求項３】
請求項２記載の方法であって、該信頼性データベースは該少くとも一つの部品についての推定された信頼性に関する一つのサブセットを含んでいて、別のサブセットは該少くとも一つの部品についての経験的な信頼性データである方法。
【請求項４】
請求項１ないし３のいずれか１項記載の方法であって、該部品データは現在の年齢である該少くとも一つの部品のサービスの長さであって該部品データベースで提示されているものと関係し、また該信頼性データは該少くとも一つの部品が保守を必要とすることになる予測された年齢であるサービスの長さと関係しているデータを含んでいる方法。
【請求項５】
請求項１ないし４のいずれか１項記載の方法であって、該計算された出力データは保守計画の形式で出力データベースに向けて出力され、該保守計画は、該部品データベース内で提示されたいくつかの部品が保守を必要とすることになる予測された時間に関係している方法。
【請求項６】
請求項１ないし５のいずれか１項記載の方法であって、さらに部品コストデータベースを用意して；該コストデータベースに向けて、保守のコストに関するコストデータを入力するか、あるいは該部品データベースで提示されたいくつかの部品を記憶するか、またはその両方を行なう段階を備えていて、該出力データは該コストデータと、該部品データか該信頼性データかの一方もしくは両方との間の予め規定された関係に従って計算される方法。
【請求項７】
請求項６記載の方法であって、該部品コストデータベースはコストデータのいくつかのサブセットを含んでいて、該出力データを計算する段階は所定の階層構造の規則に従って該コストデータ組の唯一つをアクセスすることを含んでいる方法。
【請求項８】
請求項６記載の方法であって、該部品コストデータベースは相互に相入れない保守作業に関するコストデータについての複数のサブセットと、必要とされている各保守作業の尤度に関する統計的なデータとを含んでいて、出力データを計算する該段階は、必要とされている各保守作業の尤度に基づいてコスト計算を実行することを含んでいる方法。
【請求項９】
請求項６ないし８のいずれか１項記載の方法であって、該計算された出力データは出力データベースに向けて保守計画の形式で出力され、この保守計画は、該部品データベースで提示されたいくつかの部品が保守を必要とすることになる該予測された時間に関係し、また該保守システムによってカバーされる時間期間にわたり該部品を保守し貯蔵することの一方もしくは両方にとって必要とされている関連のコストに関係している方法。
【請求項１０】
請求項１ないし９のいずれか１項記載の方法であって、さらに、該計算機システム上にプロジェクトデータベースを用意する段階と、
該保守システムを定義しているいくつかのパラメータと関係しているプロジェクトデータを該プロジェクトデータベースに向けて入力する段階とを備えており、該出力データは該プロジェクトデータと、該部品、コスト及び信頼性データのうちのいずれかとの間の予め規定した関係に従って計算されている方法。
【請求項１１】
請求項１ないし１０のいずれか１項記載の方法であって、該保守システムによってカバーされた時間期間中に、該計算機システムのいくつかのデータベースに向けて更新されたデータを用意する段階をさらに備えている方法。
【請求項１２】
請求項１１記載の方法であって、該更新された部品と信頼性データとの一方もしくは両方が該計算機システムに向けて別の計算機システムから網リンク手段によって定期的にダウンロードされる方法。
【請求項１３】
請求項１２記載の方法であって、該網リンクはインターネット上で設定される方法。
【請求項１４】
請求項１ないし１３のいずれか１項記載の、航空機保守システムのモデル形成する方法。
【請求項１５】
計算機が使用できる媒体上に記憶された計算機プログラムであって、
該計算機プログラムは部品データベースと信頼性データベースとを含んでいる応用を備えており、該応用はさらに以下の段階を該計算機が実行するようにする計算機が読取り可能な命令を含んでいるものであり：
該段階は、保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力するようにユーザに助言する段階と；
該部品データベース内に提示された少くとも一つの部品と関係した信頼性データを該信頼性データベースに向けて入力するようにユーザに助言する段階と；
該部品と信頼性データとの間の予め規定した関係に従って、少くとも一つの該部品についての予測される保守に関する出力データを計算する段階とである計算機プログラム。
【請求項１６】
保守プロジェクトをモデル形成するためのシステムであって、
処理手段を有する計算機と、該計算機のメモリ上に記憶された応用プログラムとを備えており、
該応用プログラムは、該保守プロジェクトの一部として保守されることになるいくつかの部品の状態に関する部品データを記憶するための部品データベースと；
該部品データベース内の部品データによって提示される少くとも一つの部品についての予測される性能に関する信頼性データを記憶するための信頼性データベースとを含んでおり、
該処理手段は、該部品と信頼性データとの間の予め規定された関係に従って、該部品の少くとも一つについての予測される保守に関する出力データを計算するようにされているシステム。
【請求項１７】
請求項１６記載のシステムであって、該信頼性データベースは２以上の信頼性データのサブセットを含んでいるシステム。
【請求項１８】
請求項１７記載のシステムであって、信頼性データの一つのサブセットは該少くとも一つの部品についての推定された信頼性と関係し、また第二のサブセットは該少くとも一つの部品についての経験的な信頼性データであるシステム。
【請求項１９】
請求項１６ないし１８のいずれか１項記載のシステムであって、該応用プログラムはさらに保守プロジェクトを規定しているいくつかのパラメータに関するプロジェクトデータを記憶するためのプロジェクトデータベースを含んでいるシステム。
【請求項２０】
請求項１６ないし１８のいずれか１項に記載のシステムであって、該応用プログラムはさらに部品コストデータベースを備えていて、計算機データベースで提示されたいくつかの部品を保守し貯蔵することの一方または両方のコストに関するコストデータを記憶するのにあてているシステム。
【請求項２１】
請求項１６ないし２０のいずれか１項記載のシステムであって、該計算機は別な計算機に網で結ばれていて、この別な計算機は更新されたデータを該計算機のデータベースに向けてダウンロードするようにされているシステム。
【請求項２２】
請求項１６ないし２１のいずれか１項に記載された、航空機保守プロジェクトをモデル形成するためのシステム。
【発明の詳細な説明】
【０００１】
発明の属する技術分野
この発明は、保守（メンテナンス）システムをモデル形成する（モデリング）方法に係り、限定するわけではないが、とくに航空機編隊（フリート、単に隊とも言う）についての保守システムをモデル形成するための方法に関する。またこの発明は、保守をモデル化するシステムにも関係している。
【０００２】
従来の技術
製造された数多くのクラスの装置は、幅広い総合的な保守システムを必要とし装置の運用を安全にしかも効率的に保ち、また、この種のシステムは時として詳細な計画を必要としている。通常、計画は規則正しいスケジュールのサービスプログラムを特定することを含んでいるが、スケジュールにない保守作業について回避できない発生も許容されるものでなければならない。航空機産業を例にとると、スケジュールされていない保守作業の発生はある航空機がある期間について飛行できないという結果をしばしば生じさせていて、これがＡＯＧ（航空機が地上にある、“Ａｉｒｃｒａｆｔ ｏｎ Ｇｒｏｕｎｄ”）として知られている。航空機を運用するものにとってこれはサービスとコストの妨害という点で明らかに不都合なことである。
【０００３】
発明が解決しようとする課題
したがって、進んだ計画が必要とされ、運用するもの（オペレータ）にとってできるだけ早く、正しい修理サービス及び／又は部品の交換が利用可能となり、装置の“ダウンタイム（休止時間）”が最小に維持されるようにすることを確かにすることが必要とされている。このような計画はまた、航空機オペレータが可能とされる交換部品（このような交換部品の大部分はしばしば必要とされるとは思われないものである。）のすべてを購入し在庫として貯蔵しておくことに含まれる大きな支出という負担を負わなくてよいことを確かにするのにも必要とされる。
【０００４】
保守システムは、次第次第に第三者である会社により取扱われるようになっており、換言するとその製造者とかオペレータ以外の会社によるものとなっている。ここでまた航空機産業を例にとると、航空機オペレータは、航空機の編成（編隊、フリート）を有していて、しばしば専門家である保守会社のサービスを採用して部品と貯蔵とについて連続した支持（サポート）を供給させている。保守システムを計画することは、新しい保守システムについての入札となるときに（通常は申し出る者（テンダ）にとって開かれている）、重要なこととなる。入札の準備は部品貯蔵レベルと関係する購買と貯蔵コストと、必要となるときの見積りとを含んでいる。
【０００５】
従来、保守システムを考案することは多数の一般化された入力変数に基づいた主として手計算を含んでいて、契約期間長（コントラクトレングス）及びその契約に含まれることになる装置部品の数といった変数が使われていた。全体のプロセスは完成のために何週間もかかるものであり、もし入力変数が変るとすると、長ったらしい再計算が必要となったり、あるいは精度がもとの計算に大きく依存することにより妥協を求められるものとなるかのいずれかであった。
【０００６】
課題を解決するための手段
この発明の第一の特徴（アスペクト）によると、保守システムをモデル化する方法であって、部品データベースと信頼性データベースとを有する計算機システムを用意する段階と；該部品データベースに向けて、該保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力する段階と；該信頼性データベースに向けて、該部品データベース内の部品データによって表わされた少くとも一つの部品についての予測される性能に関する信頼性データを入力する段階と；該部品と信頼性とのデータ間の予め規定された関係に従って、前記少くとも一つの部品に関する保守予測を表わしている出力データを計算する段階とを備えている方法が用意されている。
【０００７】
部品データと信頼性データとをデータベース内に記憶することは、保守システムをモデル形成するについての融通性のある（フレキシブルな）やり方を与えている。“データベース”は特定のカテゴリイ（部類）のデータ組であること、またそこにはどのような形式も別なデータベースと一緒にあるいはそれとは別個に記憶されるようにできて、この別なデータベースには特定のカテゴリイのデータの別な組を含んでいる。出力データによって提示された保守予測は一般に予測された時間（時刻）を表わしていて、この時刻に特定の部品がある種の保守形式を必要とすることになり、それは単なる試験（テスト）、点検（チェック）、あるいはもっと複雑な作業となっている。出力データは、保守モデルを含むことになり、データベース内部のデータ要素間の予め定義された関係に基づいて計算されるので、いくつかのデータ要素に対してされた何らかの変動もしくは変化はこのモデル内部の別なところで自動的に反映されることになる。予測された性能は、一般に、予め定められた時間期間内で求められている動作上の規格にその部品が適っているための能力を確認するように点検もしくは試験をその部品が必要としていることの尤もらしさ（尤度，ｌｉｋｅｌｉｈｏｏｄ）に関係している。この増加されたフレキシビリテイに加えて、出力データの精度は維持されており、維持の理由は、新しい計算がもとの計算で使用されたのと同じ予め定義された関係に基づいていることによる。別な言葉で言うと、新しい計算は全く新しい計算であって、出力データの以前の組を単に変更したものではない。どんな事象についても、初期計算は完了するのに数秒しかかからず、何らかの更新計算も完了するのに同じような短時間をとることになる。モデル形成用プロセスは“インハウス（組織内）”で応用され、例えばストリーミングエクササイズ（実習）の一部として、組織体自身の保守システムをモデル化するようにしてよい。代って、このプロセスは第三者組織体の保守プログラムについての入札を用意するのに使用されてもよい。
【０００８】
好ましいのは、この方法が、さらに、プロジェクトデータベースを用意する段階と、保守システムを定義しているいくつかのパラメータと関係しているプロジェクトデータを該プロジェクトデータベースに向けて入力する段階とを備えていることである。このプロジェクトデータベースはある組織体の特定の保守要件を定義しているパラメータに一般に関係しているプロジェクトデータを保持することになる。例えば、このプロジェクトデータは契約の長さ、保守されることになる装置、及び関係する経済的な情報を特定してよい。こういったパラメータを変更し、また生成された出力データを観察することによって、可能とされる保守シナリオの全体数への衝撃（インパクト）もしくは結果を評価することが可能である。
【０００９】
好ましいのは、信頼性データベースは２以上の信頼性データのサブセット（部分組）を含み、所定の階層構造の規則に従って信頼性データ組の唯一つにアクセスすることを含んでいるプロジェクトデータを計算する段階を備えていることである。該信頼性データベースの一つのサブセットは推定された信頼性データを含んでいて、別のサブセットは部品データで提示されたいくつかの部品についての経験的な信頼性データを備えている。したがって、生成されたモデルの精度は複数の資源から好ましいとされるデータのサブセットへアクセスする手段によって最適化される。例えば、信頼性データについての最も正確な源（ソース）は一般にはオペレータ自身の装置から得られた経験的なデータ（すなわち測定もしくは観測されたデータ）であると考えられている、このデータがないときには、非常に類似している設定（いわゆる“クローン（Ｃｌｏｎｅ）オペレーション”）からの経験的なデータが信頼性データについての好ましい源として考えられることになるかと思われる。信頼性データについての別な源はその航空機について世界の編隊（フリート）について設定されたものと関係しているかと思われ、この信頼性データは航空機製造者により普通は用意されている。階層構造の最後にあるのは関係する部品についてのＯＥＭ（Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅｒ、他社製品の部品もしくは製品の供給元）により用意された推定された信頼性データとなる。計算機システムの一部としてこの階層構造を特定することによって、信頼性データについての最も好ましい源が保守システムモデルの計算で使用されることになる。
【００１０】
計算された出力データは保守スケジュール（計画、計画表）の形式で出力データベースに向けて出力されてよく、言い換えると、部品データベース内で提示されたいくつかの部品が保守を必要とすることになる予測された時間に関するスケジュールである。これは特定の技術的な利点を提供していて、このモデルがどの部品を貯蔵し、また実際にそれらを貯蔵するのはシステム寿命の中のどの時点かを判断するためのツール（道具）となっている。出力データはまた現在貯蔵されている部品と利用可能な在庫量とを勘定に組入れることができ、追加の航空機についての支持を用意することにあてられる。
【００１１】
部品コストデータベースは相互に相入れない保守作業に関するサブセットと、必要とされている各保守作業の尤度に関する統計的なデータとを含んでいて、出力データを計算する該段階は、必要とされている各保守作業の尤度（もっともらしさの度合）に基づいてコスト計算を実行することを含んでいる。例えば一つのサブセットはある部品をチェックする（調べる）ことと、“故障欠陥が見付からない（ＮＦＦ，Ｎｏ−Ｆａｕｌｔ Ｆｏｕｎｄ）”状態を見つけることとのコストに関係していて、他のサブセットは部品の修理についてのコストに関係していてよいし、また別の組はある部品をチェックして、それが“経済的な修繕を越えている（ＢＥＲ，Ｂｅｙｏｎｄ Ｅｃｏｎｏｍｉｃ Ｒｅｐａｉｒ）”と判断するコストに関係していてよい。したがって、特定の部品の保守に含まれているコストは、こういった三つの事象が発生するという尤度を基にして計算されてよい。
【００１２】
部品コストデータを用意することによって、保守計画が計算されて、出力データベースに向けて出力され、そこにはデータベースで提示されるいくつかの部品が保守を必要とすることになる予測される時間だけでなく、また保守期間中にわたりその部品を保守し及び／又は貯蔵するのに必要とされる関係コストについても含まれている。このコストの特徴は保守契約について入札を公式化するためにモデルを用いるときにとくに有用である。入札当事者が予測された保守レベルと特定の時間に保守されることになる必要な部品とを明示することができるようになるだけでなく、含まれている関係するコストを示すこともまたできるようになる。このコストデータは完全に統合された経済的な応用で計算機システムと関係しているものの中に組入れることができて、契約の継続期間にわたって消費についての詳細な内容明細を資金の流れ、利益、損失などとともに提供するのにあてられる。
【００１３】
この方法はさらに、更新された保守システムモデルを用意することを備えていて、このモデルには更新された部品と、信頼性及び／又は部品コストデータであって、ある時間的な期間中に計算機システムに送られるものを含んでいる。これが計算機システムのデータベースのいずれかに対する増加した信頼性のデータを、そのデータが利用可能になるとすぐに、入力する手段を与えている。実際に、データフィードバック機能が用意されてこのシステムを最適化するようにする。モデル形成方法は、それ故に実際の寿命の間に保守システムを“ストリームラインとする（流れの中に入れる）”ために使用されてよい。更新されたデータは、例えばインターネットのような網リンクという手段によって遠隔の源からダウンロードされてよい。例えば、ＯＥＭはその者自身の計算機システムから、このモデル形成方法で使用するために推定された信頼性をダウンロードしてよい。
【００１４】
部品データは部品データベースで提示されている少くとも一つの部品の年齢（ａｇｅ）と関係し、また該信頼性データは該少くとも一つの部品が保守を必要とすることになる予測された年齢もしくは年齢のずれ（オフセット）と関係しているデータを含んでいる。
【００１５】
この発明の第二の特徴によると、計算機が使用できる媒体上に記憶された計算機プログラムが用意されていて、該計算機プログラムは部品データベースと信頼性データベースとを含んでいる応用を備えており、該応用はさらに以下の段階を該計算機が実行するようにする計算機が読取り可能な命令を含んでいるものであり：該段階は、保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力するようにユーザに助言する段階と；該部品データベース内に提示された少くとも一つの部品と関係した信頼性データを該信頼性データベースに向けて入力するようにユーザに助言する段階と；該部品と信頼性データとの間の予め規定した関係に従って、少くとも一つの該部品についての予測される保守に関する出力データを計算する段階とである計算機プログラムとなっている。
【００１６】
この発明の第三の特徴によると、保守プロジェクトをモデル形成するためのシステムであって、処理手段を有する計算機と、該計算機のメモリ上に記憶された応用プログラムとを備えており、該応用プログラムは、該保守プロジェクトの一部として保守されることになるいくつかの部品の状態に関する部品データを記憶するための部品データベースと；該部品データベース内の部品データによって提示される少くとも一つの部品についての予測される性能に関する信頼性データを記憶するための信頼性データベースとを含んでおり、該処理手段は、該部品と信頼性データとの間の予め規定された関係に従って、該部品の少くとも一つについての予測される保守に関する出力データを計算するようにされているシステムとなっている。
【００１７】
上述のシステムの好ましい特徴については特許請求の範囲に記載の請求項に記述されている。
【００１８】
“保守”作業（ｍａｉｎｔｅｎａｎｃｅ ｏｐｅｒａｔｉｏｎ）はここでの記述の文脈では単に修繕とオーバーホールとの作業を言うのではなく、完全な部品の交換作業も指すことは理解されると思う。また、モデル形成方法（ｍｏｄｅｌｌｉｎｇ ｍｅｔｈｏｄ）は修繕可能か交換可能な部品の保守を含むいずれもの保守システムに応用できることも理解できると思う。好ましい実施形態では、航空機保守システムをモデル形成するための方法とシステムとが記述されている。
【００１９】
添付の図面を参照し、例をあげてこの発明を記述して行く。
【００２０】
実施例
図１を見ると、航空機隊（フリート）の保守システムをモデル形成するための応用プログラム１がプロジェクトデータベース２と、マスターデータベース３と、出力データベース５とを備えている。マスターデータベース３は三つの別個のデータベース、すなわち、部品データベース７と、部品コストデータベース９と、信頼性データベース１１とを備えている。
【００２１】
以下に説明するように、応用プログラム１はある時間期間にわたって保守システムをモデル形成するためのツール（道具）を効果的に用意している。この応用プログラム１は保守スケジュール（計画表）の形式でモデルを生成し、この計画は推奨された貯蔵（在庫）レベルで特定の部品についてのものと、この特定部品が取得されなければならない日付とに関係している。保守スケジュールは、また、この保守システムの継続期間中にこの部品の保守に含まれる予測コストを生成することもし、そこには資金の流れ（キャッシュフロー）、利益及び損失についての解析を含んでいる。したがって、この応用プログラムは将来の保守システムをモデル形成して、既存の保守システムをストリームラインに加え、また将来の保守契約のための入札値を生成するためのツールとして作用するように使うことができることは評価されると思う。
【００２２】
応用プログラム１は記憶されて、計算機システムである例えば通常のパーソナルコンピュータＰＣ（図示せず）上で実行される。この計算機システム上で実行されるときには、応用プログラム１はデータか各データベース２，７，９，１１に、通常の入力デバイス（例えばキーボード）という手段で、あるいは以下で説明するように計算機網を介してのデータダウンロード動作用手段によって、入力できるようにする。図１では、各データベース２，７，９，１１へのこのデータ入力手段は矢印１３，１５，１７，１９によってそれぞれ表わされている。
【００２３】
ソフトウエアレベルでは、応用プログラム１はマイクロソフト社のエクセルのような、通常のスプレッドシートプログラムを用いて構築される。代るものとして、リレーショナルデータベースも使用できる。当業者により理解されるように、スプレッドシートパッケージは、多数の別個のデータベーステーブルを規定している手段によって、別個のデータベースを便利に構築できる。データ入力もまた便宜を与えられる。各データベーステーブルはグリッド（格子）システムとして形成され、そこでは別個のデータ要素がいわゆる“セル”の中に入れたデータベースの“データ”を作り上げている。各セルは、したがって各データ要素は、ユニークなセルラベルによって提示される。数字がデータの行のラベルを表わしていて、アルファベット順の文字が列のラベルを表わしている。したがって、特定のセルについてのセルラベルは行と列とのラベルを備えている。応用プログラム１を備えている各データベース２，５，７，９，１１はスプレッドシートプログラム内部で別個のデータベーステーブルとして形成されている。
【００２４】
以下で明らかになるところであるが、プロジェクト、部品、部品コスト、及び信頼性データベース２，７，９，１１内部の若干のデータ要素は他のデータベース内部の他のデータ要素と予め規定された関係に従ってリンクされている。図１では、このデータリンク機能が矢印２１により表わされている。このような予め規定された関係は簡単な数学的関係を含んでいて、加減乗除算といったものであり、データベース内部のデータ要素間での計算であるが、もっと複雑な関係であるブール代数、対数あるいは統計関数といったものを含んでいてもよい。一番基本的なレベルではデータはデータベース間で単純に共用されていてよい。こうして、例えば、データベース２，７，９，１１内部に記憶されたデータ要素の数はいくつかの他のデータベース内部に記憶されてもよいことになる。
【００２５】
プロジェクト、部品、部品コスト、及び信頼性データベース２，７，９，１１内部に記憶されたデータが使用されて、出力データを計算もしくは算出することになり、それが出力データベース５に記憶される。この記憶動作を表わしているデータチャンネルが矢印２３で示されている。記述したのと同じように、出力データベース５内部のデータ要素の計算が、プロジェクト、部品、部品コスト信頼性、及びデータベース２，５，７，９，１１内部のデータ要素間の多数の予め規定した関係に基づいている。出力データベース５におけるいわゆる出力データは終局的には保守モデルを形成するものである。
【００２６】
一般に、市販のスプレッドシートプログラムは、異なるセルあるいはセル群の間で機能的な関係が規定できる便宜を提供している。データベース２，５，７，９，１１内部の異なるセルあるいはセル群の間の異なる前もって規定された関係を特定するために使用され、これにより応用プログラム１は出力データベース５内に記憶するために出力データを計算する。こういった関係を特定することによって、新しいデータでプロジェクト、部品、部品コストもしくは信頼性データベース２，７，９，１１のいずれかに入力されているものはこのモデル内のどこかで反映されることになる。
【００２７】
プロジェクト、部品、部品コスト及び信頼性データベース２，７，９，１１と、そこに含まれたデータとは、ここで詳細に説明されることになる。
【００２８】
図２を見ると、プロジェクトデータベース２が示されている。プロジェクトデータベース２はいわゆる“プロジェクトデータ”を記憶するために使用される。このプロジェクトデータは保守要件と関係する経済的情報に関する各種パラメータを定義するために使用される。例えば、もし応用プログラム１が保守契約について入札ツールを用意するために使用されるとすると、航空機オペレータは各種の契約パラメータを特定することになり、これらのパラメータはプロジェクトデータベース２に入力される。プロジェクトデータベース２自体は多数のサブデータベース（部分的なデータベース）を含んでいて、言い換えると、契約データベース２５と、フリート（隊）定義データベース２７と、経済的データベース２９と、コストマークアップ（値上げ）データベース３１とを含んでいる。
【００２９】
契約データベース２５は次のデータを記憶している（上から下へと読む）：フリートデータ（フリート名）；＃Ａ／Ｃ（モデル内に組込まれることになる航空機の数）；ＦＨＡｎｎｕａｌ（航空機当りの平均年飛行時間数）；フリートＦＨ（編隊についての全飛行時間数）；ＣＬ／ｇｙｓ（年単位の契約の長さ）；ＢＥＲ値（経済的な修理を越える値、すなわち、修理コストが経済的には適切でないとされる、全部品コストの割合（百分率））；ＡＯＧレベル（地上に航空機がある（ＡＯＧ）レベル）−これはＡＯＧアイテムとして分類される部品についての保守オペレータによって許されているシステムについての需要の（与えられた年についての）百分率として表現されている−（ＡＯＧアイテムは航空機を動作状態とするために緊急事項として取得されることになるものである）；信頼カテゴリイレベル（保守作業が必要とされるときに貯蔵の中に特定の部品カテゴリイをもつことについて求められている確信レベルであり、三つのカテゴリイ１ないし３が定義されている。）
フリート定義データベース２７は、このモデル内に組込まれることになるすべての航空機の実際の名前を規定し、またそれらが関係している飛行時間と年を単位とした年齢（エイジ）を規定している。
【００３０】
経済的なデータベース２９は多数の可変パラメータを規定していて、このパラメータは応用プログラム１により使用されて、そのモデルの中でのコスト情報に基づいて完全に詳細な経済的解析を構築するのにあてられる。これらのパラメータは：ＵＳ＄／£（すなわち通貨交換レート）；現在の利率；リース（賃貸）レート；割引きレート；保証レート；インフレーションの現在レート；現在減価償却レート（ｃｕｒｒｅｎｔ ｄｅｐｒｅｃｉａｔｉｏｎ ｒａｔｅ）；資本控除（ｃａｐｉｔａｌ ａｌｌｏｗａｎｃｅ）レート；及び法人税率（ｃｏｒｐｏｒａｔｉｏｎ ｔａｘ ｒａｔｅ）である。
【００３１】
コストマークアップデータベース３１は保守オペレータの乗数に関係したデータを含んでおり（これが百分率で与えられている）、これが保守オペレータの実際の持ち上げ（アップリフト）を用意するために、すべての計算されたコスト関連データに適用される。この例では、異なる乗数が異なるコスト形式について特定されている。信頼性要因（ファクタ）もまた特定されていて、これが“安全の因子（ｆａｃｔｏｒ ｏｆ ｓａｆｅｔｙ）”であって、特定の部品をいつ注文するかを決めるのに使用されるようにし、保守を必要とすることが実際に予期されるときと関係している。
【００３２】
他の形式のプロジェクト、もしくは契約が関係したデータがプロジェクトデータベース２の中に組込まれていてよい。終局的には、実際の航空機オペレータと応用プログラム１との間のインターフェースを用意することになっている。
【００３３】
図３を見ると、部品データベース７が示されている。一般に、部品データベース７はすべての部品の詳細を記憶するために使用され、これらの部品は保守システムの一部として保存されているべきものである。この例では、三つの航空機部品（部品番号１，２，３）が部品データベース７内に含まれている。しかし、実用上は何千もの異なる部品の詳細が保管されていてよいことは評価できると思う。部品データベース７内に記憶されたデータの詳細は適当な列のラベルを参考にして記述されている。
【００３４】
列Ａでは、各部品番号が特定され、例えばＰＮ１，ＰＮ２などとなっている。この列のすべてのデータセルは部品コストデータベース９と信頼性データベース１１とにリンクしていて、こういった部品番号に対応しているデータが適当な部品番号と一緒に記憶されている。列Ｂには各部品の記述が特記されている。
【００３５】
列ＣとＤとでは、各部品について採用されるべき貯蔵施設の形式に関するデータが与えられている。この場合には二つの異なる貯蔵施設形式が用命に応じるようにしている。第一に、もし航空路線のオペレータが、その者の独占的な使用のために特別な預け場所（コンサインメントプール）に保管された部品を持つことを希望するとすると、そのときは列Ｃに“１”が入ってそのことが示される。列Ｄの中の“１”は、ある部品が中央プール内に保管されているべきこと、すなわち一つならず他の航空路線オペレータにとっても利用できてよいことを示している（“０”はオペレータが誰もいないことである）。無論コンサインメントプール内に部品を貯蔵することに含まれるコストは一般に余計支出を伴うことになる。列Ｅでの“１”は、その部品が全体の“Ｒ＆Ｏ”（修理とオーバーホール．注．ＰＣＴ原出願のＲＳＯは誤記）モデル内に組入れられるべきことを示している。この場合には、三つ全部の部品、すなわちＰＮ１，ＰＮ２，ＰＮ３が中央プール貯蔵施設とＲ＆Ｏモデルの内に組入れられている。
【００３６】
列ＦからＬまでは保守システムの一部として含まれることになる部品の数に関するデータを保存している。列Ｆは“ＱＰＡ（航空機についての数、Ｑｕａｎｔｉｔｙ Ｐｅｒ Ａｉｒｃｒａｆｔ）に関係している。これはある航空機についての特定部品の正規の数量を表わしている。列ＧないしＪは保守対象のフリート（隊）の航空機についてのその部品の実際の数量を示す。プロジェクトデータベース２は、七機がモデル内に含まれていたとしたが、ここでは説明を容易にするために、四機だけの詳細が示されている。特定の航空機はＱＰＡ列で特定されたものとは違った数の部品を取付けていてもよいことに注意されたい。例えば、航空機（Ａ／Ｃ）“２”として列ＨにあるものはＰＮ１の部品を一つも取付けておらず、しかしその航空機には二つが取付けられるべきものと仮定されている。こういうことが生ずるのは、古い部品で同じ機能をもっているが部品番号が違っているものが、その特定の航空機に取付けられていることによる。“ＱＦｉｔｔｅｄ”とした列、すなわち列Ｋはこのモデルについて取付けられた部品の全数である。
【００３７】
列ＬからＯまではモデル形成されているフリート（隊）の中の各航空機についてのその特定部品のうちの一番古いものについての年齢（飛行時間単位）に関するデータである。言い換えると、列ＬはＡ／Ｃ１に取付けた二つの部品のうちの一番古い部品の年齢に関するものであり、列ＭはＡ／Ｃ２に取付けた二つの部品のうちの一番古いものの年齢に係るといった具合である。最後に、列Ｐはフリートに取付けた一番古い部品の年齢を示し、この場合はＡ／Ｃ２上の最古部品に適合した２０１９３飛行時間である。
【００３８】
図４を参照すると、部品コストデータベース９が示されている。列Ａは部品データベースの列Ａとリンクしているので対応している部品番号が関連の部品コストデータと関係付けて示されている。この部品コストデータは、更新され新しくなっている今日的なコスト情報であって、部品データベース７内に記憶されている各部品に関するものを特定している。部品コスト情報は実際には二つの主な群に分けられている：列ＢからＦまでは交換部品を購入するコストに関する部品コストデータを特定し、また列ＧからＲまでは試験と修理を部品についてするコストに関係している。
【００３９】
列ＢからＦまでに関しては、列Ｂはその部品をＯＥＭから新部品で購入することのコスト（コストニュー）に関係し、また列Ｃは部品を配送するコスト（コストデリバリイ）に関係している。列Ｄはその部品についての月当りの償却（Ｄｅｐ／ＭＴＨ）コストに関係していて、もしその部品が新品として購入されたが償却された価値のものとなる後のときまで使用されないとした場合に関するものである。列Ｅは別の調達元から一新した部品を購入することのコスト（コストマーケット）と関係していて、部品コストデータについての代りの供給源を用意している。このようにして、このモデルは一番低い部品コスト価格を選ぶように構成できる。列Ｆは新しい部品を取得することに含まれる計算上の（ロジスティカルな）コストに関係している。
【００４０】
ここで列ＧからＲまでを見ることとして、三つの別なデータについてのサブセットが部品の試験と修理とのコストに関係して特定されている。先ず、列ＧからＫまでは部品を試験して、“ＮＦＦ”状態（Ｎｏ Ｆａｕｌｔ Ｆｏｕｎｄ，故障は何も見付からない）を見付けることに含まれるコストに関するデータを保存することである。（言い換えると、部品を取外して、試験して、航空機に戻すまでのコストである）。列ＬからＮまでは部品のオーバーホール（Ｏ／Ｈ）を実行するのに含まれるコストであり、また列Ｏは部品を試験して、しかも“ＢＥＲ”（Ｂｅｙｏｎｄ Ｅｃｏｎｏｍｉｃ Ｒｅｐａｉｒ）状態、すなわち部品を修理するコストが新しい部品を購入するコストについての特定された百分率限界を越える状態を見付けることに含まれるコストに関係している。プロジェクトデータベース２に関して前述のようにプロジェクトデータはＢＥＲレベルを７０％に設定している。
【００４１】
“ＮＦＦ”組のデータに関しては、列ＧはＯＥＭによって供給されたところにより“ＮＦＦ”状態を見つけることについての推定コストに関するデータを保持している。列Ｈは試験コストデータの代りの組に関するデータを保持している。列ＩとＪとは二つの異なる部品製造元（すなわちＯＥＭではないところ）からのさらに別な代りのコストデータ源を保持している。したがって、特定の部品について見付けられる“ＮＦＦ”状態に関するコストデータについての四つの別個の源を用意していることになる。どの源をモデルに組入れるかについて出力データを計算するときにする選択は、コストデータの最小値となるように予め定義されている（無論、何らかの階層構造関係が定義されるようにできることではある）。このデータが列Ｋに記憶される。
【００４２】
“ＮＦＦ”データについては、二つの代替コストデータのサブセットが各部品の修理とオーバーヘッド（Ｏ／Ｈ）を実行するために特定されている。列Ｌは部品のＯＥＭにより供給された推定のコストデータに関係していて、列Ｍは実際の源データに関係している。この場合に、実際のデータで列Ｍに記憶されているものが一番正確であると考えられるので、このデータが選ばれて列Ｎに記憶される。
【００４３】
列Ｏは部品を試験して“ＢＥＲ”状態が発生したことを設定するためのコストデータを含んでいる。
【００４４】
上記のことから分ることであるが、部品保持作業の異なる形式について更新された今日的な部品コストデータを用意し、併せて異なる源からのコストデータについての複数の組を用意することによって、保守についての最も経済的な方法が特定の源から識別される。
【００４５】
列ＰからＲまでは求められている各修理作業についての統計的なもっともらしさ（尤度、ｌｉｋｅｌｉｈｏｏｄ）に関係していて、言い換えると列Ｐは発生している“ＮＦＦ”状態の尤度に関係し、列Ｑは求められているオーバーホール（Ｏ／Ｈ）作業に係り、また列Ｒは発生している“ＢＥＲ”状態に係る。この例が示すように、統計的には、“ＢＥＲ”状態は発生がゼロ確率を有している。この統計的な情報は、修理作業のコストを計算するときに勘定に加えられる。そこで、“ＮＦＦ”状態は、時間の１２％で発生しそうであり、オーバーホールは時間の８８％を必要としそうであり、必要とされた修理作業を実行する全コストは列Ｋで与えられた値（好ましいとされる“ＮＦＦ”コストデータ）の１２％で、列Ｎに与えられている値（好ましいとされるオーバーホールコストデータ）の８８に加えられたものと推定されてよい。再びここでも、コストデータ間のこの関係は応用プログラム１により実施された全体のモデルの中で前もって定義されている。列Ｓは修理に置かれている部品を保存するのに必要とされる“平均の現場（ショップ）にある時間（Ｍｅａｎ Ｓｈｏｐ Ｔｉｍｅ）”である。列Ｔは修理に置かれた部品を保存しこの部品を航空機上に戻すという二つのことについての“ターンアラウント”タイムＴＡＴ（所要時間）”に関係している。これはＭＳＴに１０日を加えるものとして予め定義されている。これが列Ｔに記憶されているデータによって反映されている。
【００４６】
図５を見ると、信頼性データベース１１が示されている。部品コストデータベース９のように、この信頼性データベースの列Ａは部品データベース７の列Ａとリンクしているので、対応している部品番号は関連部品の信頼性データと関係付けられている。次のことを心にとめて、すなわち、応用プログラム１の目的はスケジュールにない保守システムに含まれる予測された計画とコストとをモデル形成することであることを思うと、“ＭＴＢＵＲ（スケジュールされていない修理（ＵＲ）間の平均時間）”データが、飛行時間という項目で、用意される。“修理（ｒｅｐａｉｒ）”はまた部品交換と、実際のオーバーホール（Ｏ／Ｈ）形修理作業とを併せて、組込んでいることは理解できると思う。
【００４７】
列ＢからＥまでには、四つの代替源がＭＴＢＵＲデータについて用意されている。列Ｂは実際の航空路線オペレータからのＭＴＢＵＲ試験データを保持していて、このオペレータについてはモデルが使用されている。これは一般に最も正確なＭＴＢＵＲデータ源と考えられている。列Ｃはいわゆる“クローンフリート（ｃｌｏｎｅ ｆｌｅｅｔ）”言い換えると、非常によく似た航空路線オペレータからのＭＴＢＵＲデータを保持している。
【００４８】
列ＤはＭＴＭＵＲデータで似たような航空路線の全世界フリート（ＷＦ）からのものを保持し、また列Ｅは推定されたＭＴＢＵＲデータであって、通常四つの源（ソース）のうちの一番小さな信頼性のデータであると考えられているものを保持している。
【００４９】
列ＦとＧとは、それぞれＭＴＢＵＲデータの実際の値と源（ＳＯＵＲＣＥ）とに関するデータを保持していて、所定の階層構造に従って選ばれたものである（Ｐｒｅｄｉｃｔｅｄは予測されたものを意味する）。上記のように、列ＢにあるＭＴＢＵＲデータは一番大きな信頼性のあるものと考えられており、したがって、もしこのデータが利用可能であるとすると、これが使用される。この場合は、このようなデータが列ＢかＣかＤかで利用可能となっているので、列Ｅの予測されたデータが選ばれる。このプロセスは信頼性データの一番正確な源はこのモデル使用される。
【００５０】
列Ｈは“Ｅｓｓｅｎｔｉａｌｉｔｙ（不可欠性）”の三つの類型（カテゴリイ）に関するデータを保持している。これらのカテゴリイはその部品が航空機の実際の作業にとってどのくらいクリティカル（重大）であるかを定義している。カテゴリイ１の部品は最もクリティカルであって、この部品なしには航空機は作動することができないものである。例えば翼（ウイング）部材がカテゴリイ１の部品である。カテゴリイ２の部品は“ｇｏ ｉｆ（条件付き進行）”部品であり、これが意味するところは航空機が同じ記述の一つの他の部品を有していることを条件として、航空機をそのまま運行してよいとすることである。カテゴリイ３の部品は“ｇｏ（進行）”部品、すなわちノンクリティカル（非重要）である。読書用ランプとかコーヒーメーカーなどがカテゴリイ３の部品の例となろう。
【００５１】
列Ｉは保守作業が求められている事象で在庫に部品があるという求められている確信（コンフィデンス）レベルに関するデータを保存している。プロジェクトデータベース２に関して述べたように、航空路線オペレータは各カテゴリイと関係付けて求められている確信レベルを特定する。したがって、列Ｈは列Ｇでの不可欠性カテゴリイとリンクした確信レベルを保持するように定義され、言い換えると、カテゴリイ１の部品については９８％カテゴリイ２の部品については９５％、またカテゴリイ３の部品については９２％ということになる。
【００５２】
列Ｊは計算された年齢（飛行時間として）に関するデータを保存していて、この年齢ではある部品が貯蔵されていなければならない、いわゆる購入どき（“ｂｕｙ ａｔ”）年齢である。この値は選ばれたＭＴＢＵＲを基に計算され、言い換えると、列Ｆに記憶されているデータにプロジェクトデータベースで特定されているような信頼性因子、すなわち０．９（９０％）を乗じたものである。したがって、ＰＮ１については、選ばれたＭＴＢＵＲで使用されるものは３２０００飛行時間であり、それに購入どき（“バイアット”）年齢が２８８００飛行時間となる。
【００５３】
列Ｋでは、年あたりの取外しについての計算された数に関するデータが記憶されている。このデータはプロジェクトデータベース２で特定されたＦＨ年（ＦＨａｎｎｕａｌ）値を採り、それを列Ｆの中の選ばれたＭＴＢＵＲで除算したものである。したがって、ＰＮ１の場合には計算した値は０．１０１６となる（ＲＥＭ：Ｒｅｍｏｖａｌ、取外しの意）。
【００５４】
最後に、列Ｌでは、同じ部品について、ターンアラウンドタイム（ＴＡＴ：所要時間）の間に必要とされる保守作業の尤度に関するデータが計算されて記憶される。すなわちこれがλ＊ となっている。換言すると、この列は保守を必要としているある部品についてのチャンスを表わしていて、それと同じ部品（これは交換してあってもよい）が依然として航空機には取付けられていない状態にある場合とする。これは列Ｋにある値を部品コストデータベース９の列Ｔ（ターンアラウンドタイム）に対応する値によって乗算して得られ、すべては一年の日数３６５．２５で除算されている。
【００５５】
前述したように、保守モデルを含んでいる出力データが、出力データベース５に矢印２３で示したように入力されると、プロジェクト、部品、部品コスト及び信頼性データベース２，７，９，１１内のデータ間の所定の計算機処理上の関係により計算されている。
【００５６】
出力データベース５の動作についてここで詳述する。
【００５７】
図６を見ると、出力データベースは三つの別なデータベースを含んでいてそれらは“Ｉｆ ｂｕｙ（買うとして）”データベース３３と、“Ｑｂｕｙ（買う数量）”データベース３５と、“Ｗｈｅｎ ｂｕｙ（いつ買うか）”データベース３７であり、その各々は以下で詳述されることになる。これら三つのデータベース３３，３５，３７は進行形の鎖（プログレッシブ  チェーン）として示されているが、その理由は“Ｑｂｕｙ”データベース２５が“Ｉｆ ｂｕｙ”データベース３３から供給されるデータ値に依存している事実と、同じように、“Ｗｈｅｎ ｂｕｙ”データベース３７が“Ｉｆ ｂｕｙ”と“Ｗｈｅｎ ｂｕｙ”データベース３３，３５の両方から供給されるデータ値に依存している事実による。矢印２３（３８）に示すように、プロジェクト、部品、部品コスト及び信頼性データベースからのデータは三つのデータベース３３，３５，３７に入力されて、最終出力データが生成されるようになる。この出力データは三つの別々な出力データファイルの形で生成され、“出力スケジュール（計画）ファイル”３９、“購入（Ｂｕｙ）リスト”４１及び“見積り（Ｑｕｏｔｅ）”４３である。
【００５８】
“Ｉｆ ｂｕｙ”データベース３３の目的は、どの部品が保守システムの一部として購入されるべきかを判断して決めることである。実際に、応用プログラム１によって用意される主な技術的利点の一つは、保守を必要としそうな度合が大きい部品が在庫されるようにできて（ダウンタイム（使用不能時間））を減らし、それによって保守を必要としそうもない部品を貯蔵する必要性を排除することである（これによって支出と在庫という面でのコスト減となる）。これは（ａ）ハイリスクアイテム（危険の大きい物品）すなわち保守を必要としそうな部品、及び（ｂ）必要とされるアイテム、すなわち航空路線オペレータもしくは製造会社がともかくも使用可能であるべきと特定した部品であるアイテムを識別することによって実行される。
【００５９】
図７を参照すると、“Ｉｆ ｂｕｙ（買うとして）”データベースが詳細に示されている。部品、部品コスト、及び信頼性データベース７，９，１１の場合のように、第一の列（列Ａ）は各部品の部品番号を含んでおり、すなわち、部品データベース７の列Ａとリンクされている。列Ｂはその部品が航空路線オペレータによって“必要とされる部品”として特定されているかいないか（ＲＥＱ？）に関するブール代数値を保持している。この例の場合には、ＰＮ１は必要とされる部品として特定されていて、それ故に“１”がこの列に入力されている。ＰＮ２とＰＮ３とは必要な部品として特定されていない。列ＣとＤとは信頼性データベース１１で特定されたように選ばれたＭＴＢＵＲと、関係する源（ＳＯＵＲＣＥ）データとを保持している（図５の列ＦとＧとを参照）。列Ｅは、システムが使用される時間期間の始めにおける、その部品番号に対応している部品の最大年齢に関するデータ（ＰＮ ＡＧＥ ＩＮ）を保持する。このデータは部品データベース７から採られる（図３の列Ｐを参照）。列Ｆは契約期間の終りにおけるその部品の予測年齢（飛行時間単位）に関するデータ（Ａ／Ｃ ＡＧＥ ＯＵＴ）を保持する。この値はプロジェクトデータベース２からのＦＨａｎｎｕａｌとＣＬ／年を乗算する手段により計算される。すなわちその部品が契約の有効期間にわたって持ちこたえることになる予測飛行時間数を計算し、次にこの数字を列Ｅに記憶されている現在の年齢値に加えることによって計算される。列Ｇは信頼性データベース１１で特定されたようにその部品の不可欠性カテゴリイ（ＥＳＳ）を示し、また列Ｈは別の不可欠性カテゴリイでＥＳＳ＝　１＊（図７の列Ｈにつけた単なる名称）として知られているものを示し、この値は列Ｇで特定されたカテゴリイから求められる。この実施例の目的に対しては、列Ｈ内の値は重要なものではない。最後に、列Ｉはその部品が取得、すなわち買うか（Ｂｕｙ）借りるかされなければならないか否か（Ｄｏｎ’ｔ）を示している。前のパラグラフで示したように、この列に対して計算される値は二つの先行する試験に依存している。第一の試験はこの部品がハイリスクの部品であるか否かである。この試験は、列Ｃ内のＭＴＢＵＲ値が列Ｆ内の値よりも大きいことを条件として、列Ｉに対して“ｂｕｙ（買う）”という値を出力することになる。列Ｆの値は予測された部品年齢である。ここでの場合では、どの部品もハイリスクであるとは考えられていない。次に、どの部品もハイリスクと考えられていないとしても、もし航空路線オペレータがその部品が必要とされていることを特定したとすると、そのときは“ｂｕｙ（買う）”の値が戻される。こうして、ＰＮ１についての列Ｂ内の値が“１”であるから、列Ｉは“ｂｕｙ”をＰＮ１について示している。
【００６０】
ここで“Ｑｂｕｙ”データベース３５（図６と８）を参照することとする。ＰＮ１が買うべきものとして決まると、次の段階は取得することになる部品の数量を判断して決めることになる。この計算はいわゆる“ラムダ（λ）”値についての統計的な解析を実行することによって決まるのであり、ラムダ値は信頼性データベース内で計算されたλ＊ 値から求められる。この統計的解析は、ポアッソン（Ｐｏｉｓｓｏｎ）分布解析を実行して必要とされる確信（コンフィデンス）レベル（これは上述のように部品のカテゴリイに依存している）に適うことが求められている部品の数を決めることを含んでいる。当業者はポアッソン分布が通常の統計解析であって部品故障レートをモデル化するのに使用されているものであることを理解できると思う。“Ｑｂｕｙ”データベース３５は図８に詳しく示されている。
【００６１】
図８を参照すると、列Ａは各部品の部品番号（ＰＮ）を示す。列Ｂは“Ｉｆ ｂｕｙ”データベース３３の列Ｉに戻った値を示す。従って、ＰＮ１については“ｂｕｙ（買う）”が示され、ＰＮ２とＰＮ３については“Ｄｏｎ’ｔ（買わない）”となっている。列Ｃは航空機の隊（フリート）に取付けられた部品の数に関するデータ、すなわち部品データベース７の列ＫからのＱｆｉｔｔｅｄ値を保持している。列Ｄは各部品について必要とされた確信（コンフィデンス）レベルに関するデータ（Ｃｏｎｆ）、すなわち、信頼性データベース１１の列Ｉに保持されているデータを保持している。列Ｅは、同じ部品についてのターンアラウンドタイム（所要時間）の間に必要とされる保守作業の尤度に関するデータ（すなわち、信頼性データベース１１の列Ｌからのλ＊ 値）を保持する。列Ｆはいわゆる“ラムダ値”を保持し、この値は列ＣにあるＱｆｉｔｔｅｄ値によりλ＊ 値を乗算して計算される。この乗算は、しかしながら、列Ｂに“ｂｕｙ（買う）”条件があるときに限り行なわれる。したがって、唯一つのラムダ値が“Ｑｂｕｙ”データベース３５内に存在していて、それがＰＮ１についてのものとなっている。最後に、ポアッソン分布解析が列Ｆのラムダ値（Ｌａｍｂｄａ）について実行されて、列Ｄで特定されている確信度レベルすなわち９５％に適うものとするために求められている部品数（Ｑ）を判断して決める。この統計的解析は値“１”を結果とし、ＰＮ１部品が必要とされていると結論し、それにより“１”という値が列Ｇに戻される。システムの全寿命中にはＰＮ１部品が一つではなくもっと部品が必要とされるであろうが、この解析が意味していることは、単一のＰＮ１部品が在庫にある限りは別のＰＮ１部品が、その単一のＰＮ部品を含んでいるスケジュールにない保守作業のターンアラウンドタイム中に、必要とされることがない９５％の尤度が存在していることである。
【００６２】
ここで“Ｗｈｅｎ ｂｕｙ”データベース３７を見ることとする。ＰＮ１が取得されることが設定され、また“１”という量が必要とされる確信度レベルに適うために在庫されることを要すると設定されると、次の段階はシステム寿命の中のどの時間にＰＮ１部品が取得されるべきかを判断して決めることである。これは、次の保守作業が生ずることになる予測時間を基礎として計算される。
【００６３】
図９は“Ｗｈｅｎ ｂｕｙ”データベース３７を詳細に示している。図９を参照すると、列Ａは各部品の部品番号を示す。列Ｂは各部品について必要とされた数量を示す。したがって、“Ｑｂｕｙ”データベース３５の列Ｇに記憶された値は“Ｗｈｅｎ ｂｕｙ”データベース３７の列Ｂにも記憶されている。列Ｃはその部品の現在の年齢（ＣＡｇｅ）に関するデータ、すなわち部品データベース７の列７に記憶されている値を保持している。列Ｄは信頼性データベース１１内に記憶された“Ｂｕｙ ａｔ”データに関するデータを保持する。列Ｅは“Ｂｕｙ ａｔ”時間が発生したとき、（すなわち、“Ｂｕｙ ａｔ”データから列Ｃ内の“現在の年齢（ＣＡｇｅ）”を減算して計算が実行される）予測された時間のずれに関するデータを保持する。ＰＮ１の場合には、これが８６０７飛行時間という予測値を与え、言い換えるとその部品が８６０７飛行時間で購入されるべきとしている。列Ｅ内の値が与えられ、かつその部品を取付けた航空機の飛行時間についての期待数についての知識が与えられると、“Ｗｈｅｎ ｂｕｙ”データベースはその後にＰＮ１部品がいつ取得されなければならないかのスケジュールを計算する。このスケジュールは契約の各年について出力され、すなわち列ＦないしＫにある１ないし６年（ＹＲ１〜６）に対応している。各列に向けて出力された数字はその部品が取得されなければならない月を示しており、すなわち“４”は４月を、また“１２”は１２月を示している。こうして列ＨはＰＮ１部品がシステムの寿命の三年次の４月に取得されなければならないことを示し、別のＰＮ１部品がシステムの寿命の四年次及び５年次の１２月に取得されるとしている。
【００６４】
“Ｉｆ ｂｕｙ”，“Ｑｂｕｙ”及び“Ｗｈｅｎ ｂｕｙ”データベース３３，３５，３７で出力データが生成されると、三つの別個の出力ファイルが生成されて便利な形式でこの出力データを提示するようにする。上述のように、これら三つの出力ファイルは“出力スケジュールファイル”３９と、“購入リストファイル”４１と、“見積りファイル”４３である。
【００６５】
出力スケジュールファイル３９はシステムの寿命中に出力データの全部についての分解したもの（内訳細目、フルブレークダウン）を用意する。“Ｗｈｅｎ ｂｕｙ”データベース３７からのデータは部品コストデータベース９からの部品コストデータと（相互に）他所参照されてシステムの寿命中にわたって必要とされる部品を保守することに含まれるコストの明細を生成する。理想を言えば、このコストはシステムについての毎年の中での異なる時間に注文されることになる部品のリストを表示するように分解されていて、これを実行するときの関係するコストも表示するようになっているのがよい。このデータはまた経済データとしてプロジェクトデータベース２にあるものと他所参照がされて、現在の利率、リースレート、インフレーションなどがすべての計算されたコストについての保守オペレータの上のせ分と一緒に計算するようにして、キャッシュフロー（資金の流れ）、利益及び損失といったものを含んでいる、システムの完全に詳しい経済分析を用意するようにしている。
【００６６】
“購入リストファイル”４１はシステムの寿命中の特定の時間で取得されることになる部品についての計画されたリストを簡単に用意する。この部品の計画されたリストをコストデータベース９からの部品コストデータと他所参照（クロスレファレンス）することによって、特定の部品供給元は、より競争できるコストデータを作るために将来の戦略的提携が識別されるようになる。
【００６７】
“見積りファイル”４３は出力スケジュールファイルについてのさほど詳細でないバージョン（版）を簡単に用意する。応用プログラム１が保守契約用の入札ツールとして使用される場合には、航空路線オペレータは一般に関係している全コストという項目で底の線を見たいと慾するのが普通であり、恐らくは年毎のコストの細目を伴うものとなる。
【００６８】
前日のように、プロジェクト、部品、部品コスト、及び信頼性データベース２，７，９，１１内部に記憶されたデータは繰返し更新できる。例えば、航空路線オペレータはプロジェクトデータベース２に異なる値を入力して、発生する全コストを判断するのにあてたいと慾することができる。このことは応用プログラム１に融通性を与えるものであり、航空路線オペレータは多数のシナリオやシステムの並べかえ、変更を急いで評価できるようになる。新しい部品が市場に出現すると、こういった部品についてのデータが部品データベース７で更新される。コストと信頼性データとの異なる源もまた部品データベース９と信頼性データベース１１との中に、新データが利用可能となるとすぐに、入力されもする。こうして、更新されたアップトウデートのコストと信頼性データとがシステムの寿命中に組入れられて、それにより、このモデル中にフィードバックが取入れられ、そしてこのモデルにより生成された出力データの精度が改善される。このモデルにより生成された全体の出力データは前もって定義された計算機処理上の関係組に従って作られるのであるから、何らかのデータ更新作業は全体の応用プログラムの中で自動的に対処される。したがって、生成された出力データの各組は完全に新しい計算に基づいていて、以前の計算の単なる変更というのではない。こうして精度と融通性（フレキシビリテイ）とが備わったものとなっている。
【００６９】
この実施形態のとくに好ましい特徴では、部品コストと信頼性データベース９，１１についての更新されたデータが二つの遠隔計算機システム（示さず）の間のデータリンクという手段によって入力される。第一の計算機システムは更新されたアップトウデートの部品コストの源（ソース）となってインターネット接続を介して部品コストデータベース９に向けての直接ダウンロードにあたる。同じように第二の計算機システムはアップトウデートの信頼性データの源となって、インターネット接続を経由して信頼性データベース１１への直接ダウンロードにあたる。
【００７０】
応用プログラム１は、それ自体がオンライン計算機システムの一部として用意されてよい。すなわち、航空路線オペレータのような第三者が、例えばインターネット上での網接続を経て応用プログラムにアクセスできるようにする。応用プログラムは、ブラウザ形式のインターフェースを組込んでいて、プロジェクトデータベース２内のデータだけが処理されることになるようにする。プロジェクトデータベース内に異なる変数を入力することによって、航空路線オペレータは、結果として生ずる保守スケジュールに速かにアクセスでき、例えば必要とされる在庫とコストといったものにアクセスできる。
【００７１】
最後に、ここで記述したシステムは保守が関係する各種形式のシステムをモデル形成するのに使用できることは理解されると考える。例えば、応用プログラム１は航空機ライン保守（メンテナンス）、保守訓練、大きな保守（ヘビイメンテナンス）及びエンジン保守システム（この場合には主変数は部品のパーツ番号ではなくログカードとなる）をモデル形成するのに適応できるものである。
【図面の簡単な説明】
【図１】
この発明による保守システムのモデル形成用応用プログラムの動作を示すブロック図。
【図２】
図１の応用プログラム内に組込まれたプロジェクトデータベースを示す図。
【図３】
図１の応用プログラム内に組込まれた部品データベースを示す図。
【図４】
図１の応用プログラム内に組込まれた部品コストデータベースを示す図。
【図５】
図１の応用プログラム内に組込まれた信頼性データベースを示す図。
【図６】
図１の応用プログラム内に組込まれた出力データベースの動作を詳細に示すブロック図。
【図７】
出力データベース内に組込まれた“もし買うとすると（イフバイ：購入条件）”データベースを示す図。
【図８】
出力データベース内に組込まれた“Ｑバイ（購入量）”データベースを示す。
【図９】
出力データベース内に組込まれた“ホエンバイ（いつ買うか）”データベースを示す図。
【図１】
2004501447.tif 000003
【図２】
2004501447.tif 000004
【図３】
2004501447.tif 000005
【図４】
2004501447.tif 000006
【図５】
2004501447.tif 000007
【図６】
2004501447.tif 000008
【図７】
2004501447.tif 000009
【図８】
2004501447.tif 000010
【図９】
2004501447.tif 000011
【国際公開パンフレット】
2004501447.tif 000012
2004501447.tif 000013
2004501447.tif 000014
2004501447.tif 000015
2004501447.tif 000016
2004501447.tif 000017
2004501447.tif 000018
2004501447.tif 000019
2004501447.tif 000020
2004501447.tif 000021
2004501447.tif 000022
2004501447.tif 000023
2004501447.tif 000024
2004501447.tif 000025
2004501447.tif 000026
2004501447.tif 000027
2004501447.tif 000028
2004501447.tif 000029
2004501447.tif 000030
2004501447.tif 000031
2004501447.tif 000032
2004501447.tif 000033
2004501447.tif 000034
2004501447.tif 000035
2004501447.tif 000036
2004501447.tif 000037
2004501447.tif 000038
2004501447.tif 000039
2004501447.tif 000040
2004501447.tif 000041
2004501447.tif 000042
2004501447.tif 000043
2004501447.tif 000044
2004501447.tif 000045
2004501447.tif 000046
2004501447.tif 000047
2004501447.tif 000048
2004501447.tif 000049
【国際公開パンフレット（コレクトバージョン）】
2004501447.tif 000050
2004501447.tif 000051
【国際調査報告】
2004501447.tif 000052
2004501447.tif 000053
2004501447.tif 000054