JP2004501447A - 保守システムをモデル形成する方法 - Google Patents
保守システムをモデル形成する方法 Download PDFInfo
- Publication number
- JP2004501447A JP2004501447A JP2002502617A JP2002502617A JP2004501447A JP 2004501447 A JP2004501447 A JP 2004501447A JP 2002502617 A JP2002502617 A JP 2002502617A JP 2002502617 A JP2002502617 A JP 2002502617A JP 2004501447 A JP2004501447 A JP 2004501447A
- Authority
- JP
- Japan
- Prior art keywords
- data
- database
- maintenance
- parts
- reliability
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Economics (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Development Economics (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Testing And Monitoring For Control Systems (AREA)
Abstract
保守システムをモデル形成する方法であって、その構成は、部品データベースと信頼性データベースとを有する計算機システムを用意することと;部品データベースに向けて、保守システムの一部として保守がされることになるいくつかの部品の状態に関する部品データを入力することと;信頼性データベースに向けて、部品データベース内の部品データにより表わされている少くとも一つの部品の予測された性能に関する信頼性データを入力することと;部品と信頼性データ間の予め定義された関係に従って、前記少くとも一つの部品に関する保守予測を表わしている出力データを計算することとを備えている。
【選択図】図1
【選択図】図1
Description
【0001】
発明の属する技術分野
この発明は、保守(メンテナンス)システムをモデル形成する(モデリング)方法に係り、限定するわけではないが、とくに航空機編隊(フリート、単に隊とも言う)についての保守システムをモデル形成するための方法に関する。またこの発明は、保守をモデル化するシステムにも関係している。
【0002】
従来の技術
製造された数多くのクラスの装置は、幅広い総合的な保守システムを必要とし装置の運用を安全にしかも効率的に保ち、また、この種のシステムは時として詳細な計画を必要としている。通常、計画は規則正しいスケジュールのサービスプログラムを特定することを含んでいるが、スケジュールにない保守作業について回避できない発生も許容されるものでなければならない。航空機産業を例にとると、スケジュールされていない保守作業の発生はある航空機がある期間について飛行できないという結果をしばしば生じさせていて、これがAOG(航空機が地上にある、“Aircraft on Ground”)として知られている。航空機を運用するものにとってこれはサービスとコストの妨害という点で明らかに不都合なことである。
【0003】
発明が解決しようとする課題
したがって、進んだ計画が必要とされ、運用するもの(オペレータ)にとってできるだけ早く、正しい修理サービス及び/又は部品の交換が利用可能となり、装置の“ダウンタイム(休止時間)”が最小に維持されるようにすることを確かにすることが必要とされている。このような計画はまた、航空機オペレータが可能とされる交換部品(このような交換部品の大部分はしばしば必要とされるとは思われないものである。)のすべてを購入し在庫として貯蔵しておくことに含まれる大きな支出という負担を負わなくてよいことを確かにするのにも必要とされる。
【0004】
保守システムは、次第次第に第三者である会社により取扱われるようになっており、換言するとその製造者とかオペレータ以外の会社によるものとなっている。ここでまた航空機産業を例にとると、航空機オペレータは、航空機の編成(編隊、フリート)を有していて、しばしば専門家である保守会社のサービスを採用して部品と貯蔵とについて連続した支持(サポート)を供給させている。保守システムを計画することは、新しい保守システムについての入札となるときに(通常は申し出る者(テンダ)にとって開かれている)、重要なこととなる。入札の準備は部品貯蔵レベルと関係する購買と貯蔵コストと、必要となるときの見積りとを含んでいる。
【0005】
従来、保守システムを考案することは多数の一般化された入力変数に基づいた主として手計算を含んでいて、契約期間長(コントラクトレングス)及びその契約に含まれることになる装置部品の数といった変数が使われていた。全体のプロセスは完成のために何週間もかかるものであり、もし入力変数が変るとすると、長ったらしい再計算が必要となったり、あるいは精度がもとの計算に大きく依存することにより妥協を求められるものとなるかのいずれかであった。
【0006】
課題を解決するための手段
この発明の第一の特徴(アスペクト)によると、保守システムをモデル化する方法であって、部品データベースと信頼性データベースとを有する計算機システムを用意する段階と;該部品データベースに向けて、該保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力する段階と;該信頼性データベースに向けて、該部品データベース内の部品データによって表わされた少くとも一つの部品についての予測される性能に関する信頼性データを入力する段階と;該部品と信頼性とのデータ間の予め規定された関係に従って、前記少くとも一つの部品に関する保守予測を表わしている出力データを計算する段階とを備えている方法が用意されている。
【0007】
部品データと信頼性データとをデータベース内に記憶することは、保守システムをモデル形成するについての融通性のある(フレキシブルな)やり方を与えている。“データベース”は特定のカテゴリイ(部類)のデータ組であること、またそこにはどのような形式も別なデータベースと一緒にあるいはそれとは別個に記憶されるようにできて、この別なデータベースには特定のカテゴリイのデータの別な組を含んでいる。出力データによって提示された保守予測は一般に予測された時間(時刻)を表わしていて、この時刻に特定の部品がある種の保守形式を必要とすることになり、それは単なる試験(テスト)、点検(チェック)、あるいはもっと複雑な作業となっている。出力データは、保守モデルを含むことになり、データベース内部のデータ要素間の予め定義された関係に基づいて計算されるので、いくつかのデータ要素に対してされた何らかの変動もしくは変化はこのモデル内部の別なところで自動的に反映されることになる。予測された性能は、一般に、予め定められた時間期間内で求められている動作上の規格にその部品が適っているための能力を確認するように点検もしくは試験をその部品が必要としていることの尤もらしさ(尤度,likelihood)に関係している。この増加されたフレキシビリテイに加えて、出力データの精度は維持されており、維持の理由は、新しい計算がもとの計算で使用されたのと同じ予め定義された関係に基づいていることによる。別な言葉で言うと、新しい計算は全く新しい計算であって、出力データの以前の組を単に変更したものではない。どんな事象についても、初期計算は完了するのに数秒しかかからず、何らかの更新計算も完了するのに同じような短時間をとることになる。モデル形成用プロセスは“インハウス(組織内)”で応用され、例えばストリーミングエクササイズ(実習)の一部として、組織体自身の保守システムをモデル化するようにしてよい。代って、このプロセスは第三者組織体の保守プログラムについての入札を用意するのに使用されてもよい。
【0008】
好ましいのは、この方法が、さらに、プロジェクトデータベースを用意する段階と、保守システムを定義しているいくつかのパラメータと関係しているプロジェクトデータを該プロジェクトデータベースに向けて入力する段階とを備えていることである。このプロジェクトデータベースはある組織体の特定の保守要件を定義しているパラメータに一般に関係しているプロジェクトデータを保持することになる。例えば、このプロジェクトデータは契約の長さ、保守されることになる装置、及び関係する経済的な情報を特定してよい。こういったパラメータを変更し、また生成された出力データを観察することによって、可能とされる保守シナリオの全体数への衝撃(インパクト)もしくは結果を評価することが可能である。
【0009】
好ましいのは、信頼性データベースは2以上の信頼性データのサブセット(部分組)を含み、所定の階層構造の規則に従って信頼性データ組の唯一つにアクセスすることを含んでいるプロジェクトデータを計算する段階を備えていることである。該信頼性データベースの一つのサブセットは推定された信頼性データを含んでいて、別のサブセットは部品データで提示されたいくつかの部品についての経験的な信頼性データを備えている。したがって、生成されたモデルの精度は複数の資源から好ましいとされるデータのサブセットへアクセスする手段によって最適化される。例えば、信頼性データについての最も正確な源(ソース)は一般にはオペレータ自身の装置から得られた経験的なデータ(すなわち測定もしくは観測されたデータ)であると考えられている、このデータがないときには、非常に類似している設定(いわゆる“クローン(Clone)オペレーション”)からの経験的なデータが信頼性データについての好ましい源として考えられることになるかと思われる。信頼性データについての別な源はその航空機について世界の編隊(フリート)について設定されたものと関係しているかと思われ、この信頼性データは航空機製造者により普通は用意されている。階層構造の最後にあるのは関係する部品についてのOEM(Original Equipment Manufacturer、他社製品の部品もしくは製品の供給元)により用意された推定された信頼性データとなる。計算機システムの一部としてこの階層構造を特定することによって、信頼性データについての最も好ましい源が保守システムモデルの計算で使用されることになる。
【0010】
計算された出力データは保守スケジュール(計画、計画表)の形式で出力データベースに向けて出力されてよく、言い換えると、部品データベース内で提示されたいくつかの部品が保守を必要とすることになる予測された時間に関するスケジュールである。これは特定の技術的な利点を提供していて、このモデルがどの部品を貯蔵し、また実際にそれらを貯蔵するのはシステム寿命の中のどの時点かを判断するためのツール(道具)となっている。出力データはまた現在貯蔵されている部品と利用可能な在庫量とを勘定に組入れることができ、追加の航空機についての支持を用意することにあてられる。
【0011】
部品コストデータベースは相互に相入れない保守作業に関するサブセットと、必要とされている各保守作業の尤度に関する統計的なデータとを含んでいて、出力データを計算する該段階は、必要とされている各保守作業の尤度(もっともらしさの度合)に基づいてコスト計算を実行することを含んでいる。例えば一つのサブセットはある部品をチェックする(調べる)ことと、“故障欠陥が見付からない(NFF,No−Fault Found)”状態を見つけることとのコストに関係していて、他のサブセットは部品の修理についてのコストに関係していてよいし、また別の組はある部品をチェックして、それが“経済的な修繕を越えている(BER,Beyond Economic Repair)”と判断するコストに関係していてよい。したがって、特定の部品の保守に含まれているコストは、こういった三つの事象が発生するという尤度を基にして計算されてよい。
【0012】
部品コストデータを用意することによって、保守計画が計算されて、出力データベースに向けて出力され、そこにはデータベースで提示されるいくつかの部品が保守を必要とすることになる予測される時間だけでなく、また保守期間中にわたりその部品を保守し及び/又は貯蔵するのに必要とされる関係コストについても含まれている。このコストの特徴は保守契約について入札を公式化するためにモデルを用いるときにとくに有用である。入札当事者が予測された保守レベルと特定の時間に保守されることになる必要な部品とを明示することができるようになるだけでなく、含まれている関係するコストを示すこともまたできるようになる。このコストデータは完全に統合された経済的な応用で計算機システムと関係しているものの中に組入れることができて、契約の継続期間にわたって消費についての詳細な内容明細を資金の流れ、利益、損失などとともに提供するのにあてられる。
【0013】
この方法はさらに、更新された保守システムモデルを用意することを備えていて、このモデルには更新された部品と、信頼性及び/又は部品コストデータであって、ある時間的な期間中に計算機システムに送られるものを含んでいる。これが計算機システムのデータベースのいずれかに対する増加した信頼性のデータを、そのデータが利用可能になるとすぐに、入力する手段を与えている。実際に、データフィードバック機能が用意されてこのシステムを最適化するようにする。モデル形成方法は、それ故に実際の寿命の間に保守システムを“ストリームラインとする(流れの中に入れる)”ために使用されてよい。更新されたデータは、例えばインターネットのような網リンクという手段によって遠隔の源からダウンロードされてよい。例えば、OEMはその者自身の計算機システムから、このモデル形成方法で使用するために推定された信頼性をダウンロードしてよい。
【0014】
部品データは部品データベースで提示されている少くとも一つの部品の年齢(age)と関係し、また該信頼性データは該少くとも一つの部品が保守を必要とすることになる予測された年齢もしくは年齢のずれ(オフセット)と関係しているデータを含んでいる。
【0015】
この発明の第二の特徴によると、計算機が使用できる媒体上に記憶された計算機プログラムが用意されていて、該計算機プログラムは部品データベースと信頼性データベースとを含んでいる応用を備えており、該応用はさらに以下の段階を該計算機が実行するようにする計算機が読取り可能な命令を含んでいるものであり:該段階は、保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力するようにユーザに助言する段階と;該部品データベース内に提示された少くとも一つの部品と関係した信頼性データを該信頼性データベースに向けて入力するようにユーザに助言する段階と;該部品と信頼性データとの間の予め規定した関係に従って、少くとも一つの該部品についての予測される保守に関する出力データを計算する段階とである計算機プログラムとなっている。
【0016】
この発明の第三の特徴によると、保守プロジェクトをモデル形成するためのシステムであって、処理手段を有する計算機と、該計算機のメモリ上に記憶された応用プログラムとを備えており、該応用プログラムは、該保守プロジェクトの一部として保守されることになるいくつかの部品の状態に関する部品データを記憶するための部品データベースと;該部品データベース内の部品データによって提示される少くとも一つの部品についての予測される性能に関する信頼性データを記憶するための信頼性データベースとを含んでおり、該処理手段は、該部品と信頼性データとの間の予め規定された関係に従って、該部品の少くとも一つについての予測される保守に関する出力データを計算するようにされているシステムとなっている。
【0017】
上述のシステムの好ましい特徴については特許請求の範囲に記載の請求項に記述されている。
【0018】
“保守”作業(maintenance operation)はここでの記述の文脈では単に修繕とオーバーホールとの作業を言うのではなく、完全な部品の交換作業も指すことは理解されると思う。また、モデル形成方法(modelling method)は修繕可能か交換可能な部品の保守を含むいずれもの保守システムに応用できることも理解できると思う。好ましい実施形態では、航空機保守システムをモデル形成するための方法とシステムとが記述されている。
【0019】
添付の図面を参照し、例をあげてこの発明を記述して行く。
【0020】
実施例
図1を見ると、航空機隊(フリート)の保守システムをモデル形成するための応用プログラム1がプロジェクトデータベース2と、マスターデータベース3と、出力データベース5とを備えている。マスターデータベース3は三つの別個のデータベース、すなわち、部品データベース7と、部品コストデータベース9と、信頼性データベース11とを備えている。
【0021】
以下に説明するように、応用プログラム1はある時間期間にわたって保守システムをモデル形成するためのツール(道具)を効果的に用意している。この応用プログラム1は保守スケジュール(計画表)の形式でモデルを生成し、この計画は推奨された貯蔵(在庫)レベルで特定の部品についてのものと、この特定部品が取得されなければならない日付とに関係している。保守スケジュールは、また、この保守システムの継続期間中にこの部品の保守に含まれる予測コストを生成することもし、そこには資金の流れ(キャッシュフロー)、利益及び損失についての解析を含んでいる。したがって、この応用プログラムは将来の保守システムをモデル形成して、既存の保守システムをストリームラインに加え、また将来の保守契約のための入札値を生成するためのツールとして作用するように使うことができることは評価されると思う。
【0022】
応用プログラム1は記憶されて、計算機システムである例えば通常のパーソナルコンピュータPC(図示せず)上で実行される。この計算機システム上で実行されるときには、応用プログラム1はデータか各データベース2,7,9,11に、通常の入力デバイス(例えばキーボード)という手段で、あるいは以下で説明するように計算機網を介してのデータダウンロード動作用手段によって、入力できるようにする。図1では、各データベース2,7,9,11へのこのデータ入力手段は矢印13,15,17,19によってそれぞれ表わされている。
【0023】
ソフトウエアレベルでは、応用プログラム1はマイクロソフト社のエクセルのような、通常のスプレッドシートプログラムを用いて構築される。代るものとして、リレーショナルデータベースも使用できる。当業者により理解されるように、スプレッドシートパッケージは、多数の別個のデータベーステーブルを規定している手段によって、別個のデータベースを便利に構築できる。データ入力もまた便宜を与えられる。各データベーステーブルはグリッド(格子)システムとして形成され、そこでは別個のデータ要素がいわゆる“セル”の中に入れたデータベースの“データ”を作り上げている。各セルは、したがって各データ要素は、ユニークなセルラベルによって提示される。数字がデータの行のラベルを表わしていて、アルファベット順の文字が列のラベルを表わしている。したがって、特定のセルについてのセルラベルは行と列とのラベルを備えている。応用プログラム1を備えている各データベース2,5,7,9,11はスプレッドシートプログラム内部で別個のデータベーステーブルとして形成されている。
【0024】
以下で明らかになるところであるが、プロジェクト、部品、部品コスト、及び信頼性データベース2,7,9,11内部の若干のデータ要素は他のデータベース内部の他のデータ要素と予め規定された関係に従ってリンクされている。図1では、このデータリンク機能が矢印21により表わされている。このような予め規定された関係は簡単な数学的関係を含んでいて、加減乗除算といったものであり、データベース内部のデータ要素間での計算であるが、もっと複雑な関係であるブール代数、対数あるいは統計関数といったものを含んでいてもよい。一番基本的なレベルではデータはデータベース間で単純に共用されていてよい。こうして、例えば、データベース2,7,9,11内部に記憶されたデータ要素の数はいくつかの他のデータベース内部に記憶されてもよいことになる。
【0025】
プロジェクト、部品、部品コスト、及び信頼性データベース2,7,9,11内部に記憶されたデータが使用されて、出力データを計算もしくは算出することになり、それが出力データベース5に記憶される。この記憶動作を表わしているデータチャンネルが矢印23で示されている。記述したのと同じように、出力データベース5内部のデータ要素の計算が、プロジェクト、部品、部品コスト信頼性、及びデータベース2,5,7,9,11内部のデータ要素間の多数の予め規定した関係に基づいている。出力データベース5におけるいわゆる出力データは終局的には保守モデルを形成するものである。
【0026】
一般に、市販のスプレッドシートプログラムは、異なるセルあるいはセル群の間で機能的な関係が規定できる便宜を提供している。データベース2,5,7,9,11内部の異なるセルあるいはセル群の間の異なる前もって規定された関係を特定するために使用され、これにより応用プログラム1は出力データベース5内に記憶するために出力データを計算する。こういった関係を特定することによって、新しいデータでプロジェクト、部品、部品コストもしくは信頼性データベース2,7,9,11のいずれかに入力されているものはこのモデル内のどこかで反映されることになる。
【0027】
プロジェクト、部品、部品コスト及び信頼性データベース2,7,9,11と、そこに含まれたデータとは、ここで詳細に説明されることになる。
【0028】
図2を見ると、プロジェクトデータベース2が示されている。プロジェクトデータベース2はいわゆる“プロジェクトデータ”を記憶するために使用される。このプロジェクトデータは保守要件と関係する経済的情報に関する各種パラメータを定義するために使用される。例えば、もし応用プログラム1が保守契約について入札ツールを用意するために使用されるとすると、航空機オペレータは各種の契約パラメータを特定することになり、これらのパラメータはプロジェクトデータベース2に入力される。プロジェクトデータベース2自体は多数のサブデータベース(部分的なデータベース)を含んでいて、言い換えると、契約データベース25と、フリート(隊)定義データベース27と、経済的データベース29と、コストマークアップ(値上げ)データベース31とを含んでいる。
【0029】
契約データベース25は次のデータを記憶している(上から下へと読む):フリートデータ(フリート名);#A/C(モデル内に組込まれることになる航空機の数);FHAnnual(航空機当りの平均年飛行時間数);フリートFH(編隊についての全飛行時間数);CL/gys(年単位の契約の長さ);BER値(経済的な修理を越える値、すなわち、修理コストが経済的には適切でないとされる、全部品コストの割合(百分率));AOGレベル(地上に航空機がある(AOG)レベル)−これはAOGアイテムとして分類される部品についての保守オペレータによって許されているシステムについての需要の(与えられた年についての)百分率として表現されている−(AOGアイテムは航空機を動作状態とするために緊急事項として取得されることになるものである);信頼カテゴリイレベル(保守作業が必要とされるときに貯蔵の中に特定の部品カテゴリイをもつことについて求められている確信レベルであり、三つのカテゴリイ1ないし3が定義されている。)
フリート定義データベース27は、このモデル内に組込まれることになるすべての航空機の実際の名前を規定し、またそれらが関係している飛行時間と年を単位とした年齢(エイジ)を規定している。
【0030】
経済的なデータベース29は多数の可変パラメータを規定していて、このパラメータは応用プログラム1により使用されて、そのモデルの中でのコスト情報に基づいて完全に詳細な経済的解析を構築するのにあてられる。これらのパラメータは:US$/£(すなわち通貨交換レート);現在の利率;リース(賃貸)レート;割引きレート;保証レート;インフレーションの現在レート;現在減価償却レート(current depreciation rate);資本控除(capital allowance)レート;及び法人税率(corporation tax rate)である。
【0031】
コストマークアップデータベース31は保守オペレータの乗数に関係したデータを含んでおり(これが百分率で与えられている)、これが保守オペレータの実際の持ち上げ(アップリフト)を用意するために、すべての計算されたコスト関連データに適用される。この例では、異なる乗数が異なるコスト形式について特定されている。信頼性要因(ファクタ)もまた特定されていて、これが“安全の因子(factor of safety)”であって、特定の部品をいつ注文するかを決めるのに使用されるようにし、保守を必要とすることが実際に予期されるときと関係している。
【0032】
他の形式のプロジェクト、もしくは契約が関係したデータがプロジェクトデータベース2の中に組込まれていてよい。終局的には、実際の航空機オペレータと応用プログラム1との間のインターフェースを用意することになっている。
【0033】
図3を見ると、部品データベース7が示されている。一般に、部品データベース7はすべての部品の詳細を記憶するために使用され、これらの部品は保守システムの一部として保存されているべきものである。この例では、三つの航空機部品(部品番号1,2,3)が部品データベース7内に含まれている。しかし、実用上は何千もの異なる部品の詳細が保管されていてよいことは評価できると思う。部品データベース7内に記憶されたデータの詳細は適当な列のラベルを参考にして記述されている。
【0034】
列Aでは、各部品番号が特定され、例えばPN1,PN2などとなっている。この列のすべてのデータセルは部品コストデータベース9と信頼性データベース11とにリンクしていて、こういった部品番号に対応しているデータが適当な部品番号と一緒に記憶されている。列Bには各部品の記述が特記されている。
【0035】
列CとDとでは、各部品について採用されるべき貯蔵施設の形式に関するデータが与えられている。この場合には二つの異なる貯蔵施設形式が用命に応じるようにしている。第一に、もし航空路線のオペレータが、その者の独占的な使用のために特別な預け場所(コンサインメントプール)に保管された部品を持つことを希望するとすると、そのときは列Cに“1”が入ってそのことが示される。列Dの中の“1”は、ある部品が中央プール内に保管されているべきこと、すなわち一つならず他の航空路線オペレータにとっても利用できてよいことを示している(“0”はオペレータが誰もいないことである)。無論コンサインメントプール内に部品を貯蔵することに含まれるコストは一般に余計支出を伴うことになる。列Eでの“1”は、その部品が全体の“R&O”(修理とオーバーホール.注.PCT原出願のRSOは誤記)モデル内に組入れられるべきことを示している。この場合には、三つ全部の部品、すなわちPN1,PN2,PN3が中央プール貯蔵施設とR&Oモデルの内に組入れられている。
【0036】
列FからLまでは保守システムの一部として含まれることになる部品の数に関するデータを保存している。列Fは“QPA(航空機についての数、Quantity Per Aircraft)に関係している。これはある航空機についての特定部品の正規の数量を表わしている。列GないしJは保守対象のフリート(隊)の航空機についてのその部品の実際の数量を示す。プロジェクトデータベース2は、七機がモデル内に含まれていたとしたが、ここでは説明を容易にするために、四機だけの詳細が示されている。特定の航空機はQPA列で特定されたものとは違った数の部品を取付けていてもよいことに注意されたい。例えば、航空機(A/C)“2”として列HにあるものはPN1の部品を一つも取付けておらず、しかしその航空機には二つが取付けられるべきものと仮定されている。こういうことが生ずるのは、古い部品で同じ機能をもっているが部品番号が違っているものが、その特定の航空機に取付けられていることによる。“QFitted”とした列、すなわち列Kはこのモデルについて取付けられた部品の全数である。
【0037】
列LからOまではモデル形成されているフリート(隊)の中の各航空機についてのその特定部品のうちの一番古いものについての年齢(飛行時間単位)に関するデータである。言い換えると、列LはA/C1に取付けた二つの部品のうちの一番古い部品の年齢に関するものであり、列MはA/C2に取付けた二つの部品のうちの一番古いものの年齢に係るといった具合である。最後に、列Pはフリートに取付けた一番古い部品の年齢を示し、この場合はA/C2上の最古部品に適合した20193飛行時間である。
【0038】
図4を参照すると、部品コストデータベース9が示されている。列Aは部品データベースの列Aとリンクしているので対応している部品番号が関連の部品コストデータと関係付けて示されている。この部品コストデータは、更新され新しくなっている今日的なコスト情報であって、部品データベース7内に記憶されている各部品に関するものを特定している。部品コスト情報は実際には二つの主な群に分けられている:列BからFまでは交換部品を購入するコストに関する部品コストデータを特定し、また列GからRまでは試験と修理を部品についてするコストに関係している。
【0039】
列BからFまでに関しては、列Bはその部品をOEMから新部品で購入することのコスト(コストニュー)に関係し、また列Cは部品を配送するコスト(コストデリバリイ)に関係している。列Dはその部品についての月当りの償却(Dep/MTH)コストに関係していて、もしその部品が新品として購入されたが償却された価値のものとなる後のときまで使用されないとした場合に関するものである。列Eは別の調達元から一新した部品を購入することのコスト(コストマーケット)と関係していて、部品コストデータについての代りの供給源を用意している。このようにして、このモデルは一番低い部品コスト価格を選ぶように構成できる。列Fは新しい部品を取得することに含まれる計算上の(ロジスティカルな)コストに関係している。
【0040】
ここで列GからRまでを見ることとして、三つの別なデータについてのサブセットが部品の試験と修理とのコストに関係して特定されている。先ず、列GからKまでは部品を試験して、“NFF”状態(No Fault Found,故障は何も見付からない)を見付けることに含まれるコストに関するデータを保存することである。(言い換えると、部品を取外して、試験して、航空機に戻すまでのコストである)。列LからNまでは部品のオーバーホール(O/H)を実行するのに含まれるコストであり、また列Oは部品を試験して、しかも“BER”(Beyond Economic Repair)状態、すなわち部品を修理するコストが新しい部品を購入するコストについての特定された百分率限界を越える状態を見付けることに含まれるコストに関係している。プロジェクトデータベース2に関して前述のようにプロジェクトデータはBERレベルを70%に設定している。
【0041】
“NFF”組のデータに関しては、列GはOEMによって供給されたところにより“NFF”状態を見つけることについての推定コストに関するデータを保持している。列Hは試験コストデータの代りの組に関するデータを保持している。列IとJとは二つの異なる部品製造元(すなわちOEMではないところ)からのさらに別な代りのコストデータ源を保持している。したがって、特定の部品について見付けられる“NFF”状態に関するコストデータについての四つの別個の源を用意していることになる。どの源をモデルに組入れるかについて出力データを計算するときにする選択は、コストデータの最小値となるように予め定義されている(無論、何らかの階層構造関係が定義されるようにできることではある)。このデータが列Kに記憶される。
【0042】
“NFF”データについては、二つの代替コストデータのサブセットが各部品の修理とオーバーヘッド(O/H)を実行するために特定されている。列Lは部品のOEMにより供給された推定のコストデータに関係していて、列Mは実際の源データに関係している。この場合に、実際のデータで列Mに記憶されているものが一番正確であると考えられるので、このデータが選ばれて列Nに記憶される。
【0043】
列Oは部品を試験して“BER”状態が発生したことを設定するためのコストデータを含んでいる。
【0044】
上記のことから分ることであるが、部品保持作業の異なる形式について更新された今日的な部品コストデータを用意し、併せて異なる源からのコストデータについての複数の組を用意することによって、保守についての最も経済的な方法が特定の源から識別される。
【0045】
列PからRまでは求められている各修理作業についての統計的なもっともらしさ(尤度、likelihood)に関係していて、言い換えると列Pは発生している“NFF”状態の尤度に関係し、列Qは求められているオーバーホール(O/H)作業に係り、また列Rは発生している“BER”状態に係る。この例が示すように、統計的には、“BER”状態は発生がゼロ確率を有している。この統計的な情報は、修理作業のコストを計算するときに勘定に加えられる。そこで、“NFF”状態は、時間の12%で発生しそうであり、オーバーホールは時間の88%を必要としそうであり、必要とされた修理作業を実行する全コストは列Kで与えられた値(好ましいとされる“NFF”コストデータ)の12%で、列Nに与えられている値(好ましいとされるオーバーホールコストデータ)の88に加えられたものと推定されてよい。再びここでも、コストデータ間のこの関係は応用プログラム1により実施された全体のモデルの中で前もって定義されている。列Sは修理に置かれている部品を保存するのに必要とされる“平均の現場(ショップ)にある時間(Mean Shop Time)”である。列Tは修理に置かれた部品を保存しこの部品を航空機上に戻すという二つのことについての“ターンアラウント”タイムTAT(所要時間)”に関係している。これはMSTに10日を加えるものとして予め定義されている。これが列Tに記憶されているデータによって反映されている。
【0046】
図5を見ると、信頼性データベース11が示されている。部品コストデータベース9のように、この信頼性データベースの列Aは部品データベース7の列Aとリンクしているので、対応している部品番号は関連部品の信頼性データと関係付けられている。次のことを心にとめて、すなわち、応用プログラム1の目的はスケジュールにない保守システムに含まれる予測された計画とコストとをモデル形成することであることを思うと、“MTBUR(スケジュールされていない修理(UR)間の平均時間)”データが、飛行時間という項目で、用意される。“修理(repair)”はまた部品交換と、実際のオーバーホール(O/H)形修理作業とを併せて、組込んでいることは理解できると思う。
【0047】
列BからEまでには、四つの代替源がMTBURデータについて用意されている。列Bは実際の航空路線オペレータからのMTBUR試験データを保持していて、このオペレータについてはモデルが使用されている。これは一般に最も正確なMTBURデータ源と考えられている。列Cはいわゆる“クローンフリート(clone fleet)”言い換えると、非常によく似た航空路線オペレータからのMTBURデータを保持している。
【0048】
列DはMTMURデータで似たような航空路線の全世界フリート(WF)からのものを保持し、また列Eは推定されたMTBURデータであって、通常四つの源(ソース)のうちの一番小さな信頼性のデータであると考えられているものを保持している。
【0049】
列FとGとは、それぞれMTBURデータの実際の値と源(SOURCE)とに関するデータを保持していて、所定の階層構造に従って選ばれたものである(Predictedは予測されたものを意味する)。上記のように、列BにあるMTBURデータは一番大きな信頼性のあるものと考えられており、したがって、もしこのデータが利用可能であるとすると、これが使用される。この場合は、このようなデータが列BかCかDかで利用可能となっているので、列Eの予測されたデータが選ばれる。このプロセスは信頼性データの一番正確な源はこのモデル使用される。
【0050】
列Hは“Essentiality(不可欠性)”の三つの類型(カテゴリイ)に関するデータを保持している。これらのカテゴリイはその部品が航空機の実際の作業にとってどのくらいクリティカル(重大)であるかを定義している。カテゴリイ1の部品は最もクリティカルであって、この部品なしには航空機は作動することができないものである。例えば翼(ウイング)部材がカテゴリイ1の部品である。カテゴリイ2の部品は“go if(条件付き進行)”部品であり、これが意味するところは航空機が同じ記述の一つの他の部品を有していることを条件として、航空機をそのまま運行してよいとすることである。カテゴリイ3の部品は“go(進行)”部品、すなわちノンクリティカル(非重要)である。読書用ランプとかコーヒーメーカーなどがカテゴリイ3の部品の例となろう。
【0051】
列Iは保守作業が求められている事象で在庫に部品があるという求められている確信(コンフィデンス)レベルに関するデータを保存している。プロジェクトデータベース2に関して述べたように、航空路線オペレータは各カテゴリイと関係付けて求められている確信レベルを特定する。したがって、列Hは列Gでの不可欠性カテゴリイとリンクした確信レベルを保持するように定義され、言い換えると、カテゴリイ1の部品については98%カテゴリイ2の部品については95%、またカテゴリイ3の部品については92%ということになる。
【0052】
列Jは計算された年齢(飛行時間として)に関するデータを保存していて、この年齢ではある部品が貯蔵されていなければならない、いわゆる購入どき(“buy at”)年齢である。この値は選ばれたMTBURを基に計算され、言い換えると、列Fに記憶されているデータにプロジェクトデータベースで特定されているような信頼性因子、すなわち0.9(90%)を乗じたものである。したがって、PN1については、選ばれたMTBURで使用されるものは32000飛行時間であり、それに購入どき(“バイアット”)年齢が28800飛行時間となる。
【0053】
列Kでは、年あたりの取外しについての計算された数に関するデータが記憶されている。このデータはプロジェクトデータベース2で特定されたFH年(FHannual)値を採り、それを列Fの中の選ばれたMTBURで除算したものである。したがって、PN1の場合には計算した値は0.1016となる(REM:Removal、取外しの意)。
【0054】
最後に、列Lでは、同じ部品について、ターンアラウンドタイム(TAT:所要時間)の間に必要とされる保守作業の尤度に関するデータが計算されて記憶される。すなわちこれがλ* となっている。換言すると、この列は保守を必要としているある部品についてのチャンスを表わしていて、それと同じ部品(これは交換してあってもよい)が依然として航空機には取付けられていない状態にある場合とする。これは列Kにある値を部品コストデータベース9の列T(ターンアラウンドタイム)に対応する値によって乗算して得られ、すべては一年の日数365.25で除算されている。
【0055】
前述したように、保守モデルを含んでいる出力データが、出力データベース5に矢印23で示したように入力されると、プロジェクト、部品、部品コスト及び信頼性データベース2,7,9,11内のデータ間の所定の計算機処理上の関係により計算されている。
【0056】
出力データベース5の動作についてここで詳述する。
【0057】
図6を見ると、出力データベースは三つの別なデータベースを含んでいてそれらは“If buy(買うとして)”データベース33と、“Qbuy(買う数量)”データベース35と、“When buy(いつ買うか)”データベース37であり、その各々は以下で詳述されることになる。これら三つのデータベース33,35,37は進行形の鎖(プログレッシブ チェーン)として示されているが、その理由は“Qbuy”データベース25が“If buy”データベース33から供給されるデータ値に依存している事実と、同じように、“When buy”データベース37が“If buy”と“When buy”データベース33,35の両方から供給されるデータ値に依存している事実による。矢印23(38)に示すように、プロジェクト、部品、部品コスト及び信頼性データベースからのデータは三つのデータベース33,35,37に入力されて、最終出力データが生成されるようになる。この出力データは三つの別々な出力データファイルの形で生成され、“出力スケジュール(計画)ファイル”39、“購入(Buy)リスト”41及び“見積り(Quote)”43である。
【0058】
“If buy”データベース33の目的は、どの部品が保守システムの一部として購入されるべきかを判断して決めることである。実際に、応用プログラム1によって用意される主な技術的利点の一つは、保守を必要としそうな度合が大きい部品が在庫されるようにできて(ダウンタイム(使用不能時間))を減らし、それによって保守を必要としそうもない部品を貯蔵する必要性を排除することである(これによって支出と在庫という面でのコスト減となる)。これは(a)ハイリスクアイテム(危険の大きい物品)すなわち保守を必要としそうな部品、及び(b)必要とされるアイテム、すなわち航空路線オペレータもしくは製造会社がともかくも使用可能であるべきと特定した部品であるアイテムを識別することによって実行される。
【0059】
図7を参照すると、“If buy(買うとして)”データベースが詳細に示されている。部品、部品コスト、及び信頼性データベース7,9,11の場合のように、第一の列(列A)は各部品の部品番号を含んでおり、すなわち、部品データベース7の列Aとリンクされている。列Bはその部品が航空路線オペレータによって“必要とされる部品”として特定されているかいないか(REQ?)に関するブール代数値を保持している。この例の場合には、PN1は必要とされる部品として特定されていて、それ故に“1”がこの列に入力されている。PN2とPN3とは必要な部品として特定されていない。列CとDとは信頼性データベース11で特定されたように選ばれたMTBURと、関係する源(SOURCE)データとを保持している(図5の列FとGとを参照)。列Eは、システムが使用される時間期間の始めにおける、その部品番号に対応している部品の最大年齢に関するデータ(PN AGE IN)を保持する。このデータは部品データベース7から採られる(図3の列Pを参照)。列Fは契約期間の終りにおけるその部品の予測年齢(飛行時間単位)に関するデータ(A/C AGE OUT)を保持する。この値はプロジェクトデータベース2からのFHannualとCL/年を乗算する手段により計算される。すなわちその部品が契約の有効期間にわたって持ちこたえることになる予測飛行時間数を計算し、次にこの数字を列Eに記憶されている現在の年齢値に加えることによって計算される。列Gは信頼性データベース11で特定されたようにその部品の不可欠性カテゴリイ(ESS)を示し、また列Hは別の不可欠性カテゴリイでESS= 1*(図7の列Hにつけた単なる名称)として知られているものを示し、この値は列Gで特定されたカテゴリイから求められる。この実施例の目的に対しては、列H内の値は重要なものではない。最後に、列Iはその部品が取得、すなわち買うか(Buy)借りるかされなければならないか否か(Don’t)を示している。前のパラグラフで示したように、この列に対して計算される値は二つの先行する試験に依存している。第一の試験はこの部品がハイリスクの部品であるか否かである。この試験は、列C内のMTBUR値が列F内の値よりも大きいことを条件として、列Iに対して“buy(買う)”という値を出力することになる。列Fの値は予測された部品年齢である。ここでの場合では、どの部品もハイリスクであるとは考えられていない。次に、どの部品もハイリスクと考えられていないとしても、もし航空路線オペレータがその部品が必要とされていることを特定したとすると、そのときは“buy(買う)”の値が戻される。こうして、PN1についての列B内の値が“1”であるから、列Iは“buy”をPN1について示している。
【0060】
ここで“Qbuy”データベース35(図6と8)を参照することとする。PN1が買うべきものとして決まると、次の段階は取得することになる部品の数量を判断して決めることになる。この計算はいわゆる“ラムダ(λ)”値についての統計的な解析を実行することによって決まるのであり、ラムダ値は信頼性データベース内で計算されたλ* 値から求められる。この統計的解析は、ポアッソン(Poisson)分布解析を実行して必要とされる確信(コンフィデンス)レベル(これは上述のように部品のカテゴリイに依存している)に適うことが求められている部品の数を決めることを含んでいる。当業者はポアッソン分布が通常の統計解析であって部品故障レートをモデル化するのに使用されているものであることを理解できると思う。“Qbuy”データベース35は図8に詳しく示されている。
【0061】
図8を参照すると、列Aは各部品の部品番号(PN)を示す。列Bは“If buy”データベース33の列Iに戻った値を示す。従って、PN1については“buy(買う)”が示され、PN2とPN3については“Don’t(買わない)”となっている。列Cは航空機の隊(フリート)に取付けられた部品の数に関するデータ、すなわち部品データベース7の列KからのQfitted値を保持している。列Dは各部品について必要とされた確信(コンフィデンス)レベルに関するデータ(Conf)、すなわち、信頼性データベース11の列Iに保持されているデータを保持している。列Eは、同じ部品についてのターンアラウンドタイム(所要時間)の間に必要とされる保守作業の尤度に関するデータ(すなわち、信頼性データベース11の列Lからのλ* 値)を保持する。列Fはいわゆる“ラムダ値”を保持し、この値は列CにあるQfitted値によりλ* 値を乗算して計算される。この乗算は、しかしながら、列Bに“buy(買う)”条件があるときに限り行なわれる。したがって、唯一つのラムダ値が“Qbuy”データベース35内に存在していて、それがPN1についてのものとなっている。最後に、ポアッソン分布解析が列Fのラムダ値(Lambda)について実行されて、列Dで特定されている確信度レベルすなわち95%に適うものとするために求められている部品数(Q)を判断して決める。この統計的解析は値“1”を結果とし、PN1部品が必要とされていると結論し、それにより“1”という値が列Gに戻される。システムの全寿命中にはPN1部品が一つではなくもっと部品が必要とされるであろうが、この解析が意味していることは、単一のPN1部品が在庫にある限りは別のPN1部品が、その単一のPN部品を含んでいるスケジュールにない保守作業のターンアラウンドタイム中に、必要とされることがない95%の尤度が存在していることである。
【0062】
ここで“When buy”データベース37を見ることとする。PN1が取得されることが設定され、また“1”という量が必要とされる確信度レベルに適うために在庫されることを要すると設定されると、次の段階はシステム寿命の中のどの時間にPN1部品が取得されるべきかを判断して決めることである。これは、次の保守作業が生ずることになる予測時間を基礎として計算される。
【0063】
図9は“When buy”データベース37を詳細に示している。図9を参照すると、列Aは各部品の部品番号を示す。列Bは各部品について必要とされた数量を示す。したがって、“Qbuy”データベース35の列Gに記憶された値は“When buy”データベース37の列Bにも記憶されている。列Cはその部品の現在の年齢(CAge)に関するデータ、すなわち部品データベース7の列7に記憶されている値を保持している。列Dは信頼性データベース11内に記憶された“Buy at”データに関するデータを保持する。列Eは“Buy at”時間が発生したとき、(すなわち、“Buy at”データから列C内の“現在の年齢(CAge)”を減算して計算が実行される)予測された時間のずれに関するデータを保持する。PN1の場合には、これが8607飛行時間という予測値を与え、言い換えるとその部品が8607飛行時間で購入されるべきとしている。列E内の値が与えられ、かつその部品を取付けた航空機の飛行時間についての期待数についての知識が与えられると、“When buy”データベースはその後にPN1部品がいつ取得されなければならないかのスケジュールを計算する。このスケジュールは契約の各年について出力され、すなわち列FないしKにある1ないし6年(YR1〜6)に対応している。各列に向けて出力された数字はその部品が取得されなければならない月を示しており、すなわち“4”は4月を、また“12”は12月を示している。こうして列HはPN1部品がシステムの寿命の三年次の4月に取得されなければならないことを示し、別のPN1部品がシステムの寿命の四年次及び5年次の12月に取得されるとしている。
【0064】
“If buy”,“Qbuy”及び“When buy”データベース33,35,37で出力データが生成されると、三つの別個の出力ファイルが生成されて便利な形式でこの出力データを提示するようにする。上述のように、これら三つの出力ファイルは“出力スケジュールファイル”39と、“購入リストファイル”41と、“見積りファイル”43である。
【0065】
出力スケジュールファイル39はシステムの寿命中に出力データの全部についての分解したもの(内訳細目、フルブレークダウン)を用意する。“When buy”データベース37からのデータは部品コストデータベース9からの部品コストデータと(相互に)他所参照されてシステムの寿命中にわたって必要とされる部品を保守することに含まれるコストの明細を生成する。理想を言えば、このコストはシステムについての毎年の中での異なる時間に注文されることになる部品のリストを表示するように分解されていて、これを実行するときの関係するコストも表示するようになっているのがよい。このデータはまた経済データとしてプロジェクトデータベース2にあるものと他所参照がされて、現在の利率、リースレート、インフレーションなどがすべての計算されたコストについての保守オペレータの上のせ分と一緒に計算するようにして、キャッシュフロー(資金の流れ)、利益及び損失といったものを含んでいる、システムの完全に詳しい経済分析を用意するようにしている。
【0066】
“購入リストファイル”41はシステムの寿命中の特定の時間で取得されることになる部品についての計画されたリストを簡単に用意する。この部品の計画されたリストをコストデータベース9からの部品コストデータと他所参照(クロスレファレンス)することによって、特定の部品供給元は、より競争できるコストデータを作るために将来の戦略的提携が識別されるようになる。
【0067】
“見積りファイル”43は出力スケジュールファイルについてのさほど詳細でないバージョン(版)を簡単に用意する。応用プログラム1が保守契約用の入札ツールとして使用される場合には、航空路線オペレータは一般に関係している全コストという項目で底の線を見たいと慾するのが普通であり、恐らくは年毎のコストの細目を伴うものとなる。
【0068】
前日のように、プロジェクト、部品、部品コスト、及び信頼性データベース2,7,9,11内部に記憶されたデータは繰返し更新できる。例えば、航空路線オペレータはプロジェクトデータベース2に異なる値を入力して、発生する全コストを判断するのにあてたいと慾することができる。このことは応用プログラム1に融通性を与えるものであり、航空路線オペレータは多数のシナリオやシステムの並べかえ、変更を急いで評価できるようになる。新しい部品が市場に出現すると、こういった部品についてのデータが部品データベース7で更新される。コストと信頼性データとの異なる源もまた部品データベース9と信頼性データベース11との中に、新データが利用可能となるとすぐに、入力されもする。こうして、更新されたアップトウデートのコストと信頼性データとがシステムの寿命中に組入れられて、それにより、このモデル中にフィードバックが取入れられ、そしてこのモデルにより生成された出力データの精度が改善される。このモデルにより生成された全体の出力データは前もって定義された計算機処理上の関係組に従って作られるのであるから、何らかのデータ更新作業は全体の応用プログラムの中で自動的に対処される。したがって、生成された出力データの各組は完全に新しい計算に基づいていて、以前の計算の単なる変更というのではない。こうして精度と融通性(フレキシビリテイ)とが備わったものとなっている。
【0069】
この実施形態のとくに好ましい特徴では、部品コストと信頼性データベース9,11についての更新されたデータが二つの遠隔計算機システム(示さず)の間のデータリンクという手段によって入力される。第一の計算機システムは更新されたアップトウデートの部品コストの源(ソース)となってインターネット接続を介して部品コストデータベース9に向けての直接ダウンロードにあたる。同じように第二の計算機システムはアップトウデートの信頼性データの源となって、インターネット接続を経由して信頼性データベース11への直接ダウンロードにあたる。
【0070】
応用プログラム1は、それ自体がオンライン計算機システムの一部として用意されてよい。すなわち、航空路線オペレータのような第三者が、例えばインターネット上での網接続を経て応用プログラムにアクセスできるようにする。応用プログラムは、ブラウザ形式のインターフェースを組込んでいて、プロジェクトデータベース2内のデータだけが処理されることになるようにする。プロジェクトデータベース内に異なる変数を入力することによって、航空路線オペレータは、結果として生ずる保守スケジュールに速かにアクセスでき、例えば必要とされる在庫とコストといったものにアクセスできる。
【0071】
最後に、ここで記述したシステムは保守が関係する各種形式のシステムをモデル形成するのに使用できることは理解されると考える。例えば、応用プログラム1は航空機ライン保守(メンテナンス)、保守訓練、大きな保守(ヘビイメンテナンス)及びエンジン保守システム(この場合には主変数は部品のパーツ番号ではなくログカードとなる)をモデル形成するのに適応できるものである。
【図面の簡単な説明】
【図1】
この発明による保守システムのモデル形成用応用プログラムの動作を示すブロック図。
【図2】
図1の応用プログラム内に組込まれたプロジェクトデータベースを示す図。
【図3】
図1の応用プログラム内に組込まれた部品データベースを示す図。
【図4】
図1の応用プログラム内に組込まれた部品コストデータベースを示す図。
【図5】
図1の応用プログラム内に組込まれた信頼性データベースを示す図。
【図6】
図1の応用プログラム内に組込まれた出力データベースの動作を詳細に示すブロック図。
【図7】
出力データベース内に組込まれた“もし買うとすると(イフバイ:購入条件)”データベースを示す図。
【図8】
出力データベース内に組込まれた“Qバイ(購入量)”データベースを示す。
【図9】
出力データベース内に組込まれた“ホエンバイ(いつ買うか)”データベースを示す図。
発明の属する技術分野
この発明は、保守(メンテナンス)システムをモデル形成する(モデリング)方法に係り、限定するわけではないが、とくに航空機編隊(フリート、単に隊とも言う)についての保守システムをモデル形成するための方法に関する。またこの発明は、保守をモデル化するシステムにも関係している。
【0002】
従来の技術
製造された数多くのクラスの装置は、幅広い総合的な保守システムを必要とし装置の運用を安全にしかも効率的に保ち、また、この種のシステムは時として詳細な計画を必要としている。通常、計画は規則正しいスケジュールのサービスプログラムを特定することを含んでいるが、スケジュールにない保守作業について回避できない発生も許容されるものでなければならない。航空機産業を例にとると、スケジュールされていない保守作業の発生はある航空機がある期間について飛行できないという結果をしばしば生じさせていて、これがAOG(航空機が地上にある、“Aircraft on Ground”)として知られている。航空機を運用するものにとってこれはサービスとコストの妨害という点で明らかに不都合なことである。
【0003】
発明が解決しようとする課題
したがって、進んだ計画が必要とされ、運用するもの(オペレータ)にとってできるだけ早く、正しい修理サービス及び/又は部品の交換が利用可能となり、装置の“ダウンタイム(休止時間)”が最小に維持されるようにすることを確かにすることが必要とされている。このような計画はまた、航空機オペレータが可能とされる交換部品(このような交換部品の大部分はしばしば必要とされるとは思われないものである。)のすべてを購入し在庫として貯蔵しておくことに含まれる大きな支出という負担を負わなくてよいことを確かにするのにも必要とされる。
【0004】
保守システムは、次第次第に第三者である会社により取扱われるようになっており、換言するとその製造者とかオペレータ以外の会社によるものとなっている。ここでまた航空機産業を例にとると、航空機オペレータは、航空機の編成(編隊、フリート)を有していて、しばしば専門家である保守会社のサービスを採用して部品と貯蔵とについて連続した支持(サポート)を供給させている。保守システムを計画することは、新しい保守システムについての入札となるときに(通常は申し出る者(テンダ)にとって開かれている)、重要なこととなる。入札の準備は部品貯蔵レベルと関係する購買と貯蔵コストと、必要となるときの見積りとを含んでいる。
【0005】
従来、保守システムを考案することは多数の一般化された入力変数に基づいた主として手計算を含んでいて、契約期間長(コントラクトレングス)及びその契約に含まれることになる装置部品の数といった変数が使われていた。全体のプロセスは完成のために何週間もかかるものであり、もし入力変数が変るとすると、長ったらしい再計算が必要となったり、あるいは精度がもとの計算に大きく依存することにより妥協を求められるものとなるかのいずれかであった。
【0006】
課題を解決するための手段
この発明の第一の特徴(アスペクト)によると、保守システムをモデル化する方法であって、部品データベースと信頼性データベースとを有する計算機システムを用意する段階と;該部品データベースに向けて、該保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力する段階と;該信頼性データベースに向けて、該部品データベース内の部品データによって表わされた少くとも一つの部品についての予測される性能に関する信頼性データを入力する段階と;該部品と信頼性とのデータ間の予め規定された関係に従って、前記少くとも一つの部品に関する保守予測を表わしている出力データを計算する段階とを備えている方法が用意されている。
【0007】
部品データと信頼性データとをデータベース内に記憶することは、保守システムをモデル形成するについての融通性のある(フレキシブルな)やり方を与えている。“データベース”は特定のカテゴリイ(部類)のデータ組であること、またそこにはどのような形式も別なデータベースと一緒にあるいはそれとは別個に記憶されるようにできて、この別なデータベースには特定のカテゴリイのデータの別な組を含んでいる。出力データによって提示された保守予測は一般に予測された時間(時刻)を表わしていて、この時刻に特定の部品がある種の保守形式を必要とすることになり、それは単なる試験(テスト)、点検(チェック)、あるいはもっと複雑な作業となっている。出力データは、保守モデルを含むことになり、データベース内部のデータ要素間の予め定義された関係に基づいて計算されるので、いくつかのデータ要素に対してされた何らかの変動もしくは変化はこのモデル内部の別なところで自動的に反映されることになる。予測された性能は、一般に、予め定められた時間期間内で求められている動作上の規格にその部品が適っているための能力を確認するように点検もしくは試験をその部品が必要としていることの尤もらしさ(尤度,likelihood)に関係している。この増加されたフレキシビリテイに加えて、出力データの精度は維持されており、維持の理由は、新しい計算がもとの計算で使用されたのと同じ予め定義された関係に基づいていることによる。別な言葉で言うと、新しい計算は全く新しい計算であって、出力データの以前の組を単に変更したものではない。どんな事象についても、初期計算は完了するのに数秒しかかからず、何らかの更新計算も完了するのに同じような短時間をとることになる。モデル形成用プロセスは“インハウス(組織内)”で応用され、例えばストリーミングエクササイズ(実習)の一部として、組織体自身の保守システムをモデル化するようにしてよい。代って、このプロセスは第三者組織体の保守プログラムについての入札を用意するのに使用されてもよい。
【0008】
好ましいのは、この方法が、さらに、プロジェクトデータベースを用意する段階と、保守システムを定義しているいくつかのパラメータと関係しているプロジェクトデータを該プロジェクトデータベースに向けて入力する段階とを備えていることである。このプロジェクトデータベースはある組織体の特定の保守要件を定義しているパラメータに一般に関係しているプロジェクトデータを保持することになる。例えば、このプロジェクトデータは契約の長さ、保守されることになる装置、及び関係する経済的な情報を特定してよい。こういったパラメータを変更し、また生成された出力データを観察することによって、可能とされる保守シナリオの全体数への衝撃(インパクト)もしくは結果を評価することが可能である。
【0009】
好ましいのは、信頼性データベースは2以上の信頼性データのサブセット(部分組)を含み、所定の階層構造の規則に従って信頼性データ組の唯一つにアクセスすることを含んでいるプロジェクトデータを計算する段階を備えていることである。該信頼性データベースの一つのサブセットは推定された信頼性データを含んでいて、別のサブセットは部品データで提示されたいくつかの部品についての経験的な信頼性データを備えている。したがって、生成されたモデルの精度は複数の資源から好ましいとされるデータのサブセットへアクセスする手段によって最適化される。例えば、信頼性データについての最も正確な源(ソース)は一般にはオペレータ自身の装置から得られた経験的なデータ(すなわち測定もしくは観測されたデータ)であると考えられている、このデータがないときには、非常に類似している設定(いわゆる“クローン(Clone)オペレーション”)からの経験的なデータが信頼性データについての好ましい源として考えられることになるかと思われる。信頼性データについての別な源はその航空機について世界の編隊(フリート)について設定されたものと関係しているかと思われ、この信頼性データは航空機製造者により普通は用意されている。階層構造の最後にあるのは関係する部品についてのOEM(Original Equipment Manufacturer、他社製品の部品もしくは製品の供給元)により用意された推定された信頼性データとなる。計算機システムの一部としてこの階層構造を特定することによって、信頼性データについての最も好ましい源が保守システムモデルの計算で使用されることになる。
【0010】
計算された出力データは保守スケジュール(計画、計画表)の形式で出力データベースに向けて出力されてよく、言い換えると、部品データベース内で提示されたいくつかの部品が保守を必要とすることになる予測された時間に関するスケジュールである。これは特定の技術的な利点を提供していて、このモデルがどの部品を貯蔵し、また実際にそれらを貯蔵するのはシステム寿命の中のどの時点かを判断するためのツール(道具)となっている。出力データはまた現在貯蔵されている部品と利用可能な在庫量とを勘定に組入れることができ、追加の航空機についての支持を用意することにあてられる。
【0011】
部品コストデータベースは相互に相入れない保守作業に関するサブセットと、必要とされている各保守作業の尤度に関する統計的なデータとを含んでいて、出力データを計算する該段階は、必要とされている各保守作業の尤度(もっともらしさの度合)に基づいてコスト計算を実行することを含んでいる。例えば一つのサブセットはある部品をチェックする(調べる)ことと、“故障欠陥が見付からない(NFF,No−Fault Found)”状態を見つけることとのコストに関係していて、他のサブセットは部品の修理についてのコストに関係していてよいし、また別の組はある部品をチェックして、それが“経済的な修繕を越えている(BER,Beyond Economic Repair)”と判断するコストに関係していてよい。したがって、特定の部品の保守に含まれているコストは、こういった三つの事象が発生するという尤度を基にして計算されてよい。
【0012】
部品コストデータを用意することによって、保守計画が計算されて、出力データベースに向けて出力され、そこにはデータベースで提示されるいくつかの部品が保守を必要とすることになる予測される時間だけでなく、また保守期間中にわたりその部品を保守し及び/又は貯蔵するのに必要とされる関係コストについても含まれている。このコストの特徴は保守契約について入札を公式化するためにモデルを用いるときにとくに有用である。入札当事者が予測された保守レベルと特定の時間に保守されることになる必要な部品とを明示することができるようになるだけでなく、含まれている関係するコストを示すこともまたできるようになる。このコストデータは完全に統合された経済的な応用で計算機システムと関係しているものの中に組入れることができて、契約の継続期間にわたって消費についての詳細な内容明細を資金の流れ、利益、損失などとともに提供するのにあてられる。
【0013】
この方法はさらに、更新された保守システムモデルを用意することを備えていて、このモデルには更新された部品と、信頼性及び/又は部品コストデータであって、ある時間的な期間中に計算機システムに送られるものを含んでいる。これが計算機システムのデータベースのいずれかに対する増加した信頼性のデータを、そのデータが利用可能になるとすぐに、入力する手段を与えている。実際に、データフィードバック機能が用意されてこのシステムを最適化するようにする。モデル形成方法は、それ故に実際の寿命の間に保守システムを“ストリームラインとする(流れの中に入れる)”ために使用されてよい。更新されたデータは、例えばインターネットのような網リンクという手段によって遠隔の源からダウンロードされてよい。例えば、OEMはその者自身の計算機システムから、このモデル形成方法で使用するために推定された信頼性をダウンロードしてよい。
【0014】
部品データは部品データベースで提示されている少くとも一つの部品の年齢(age)と関係し、また該信頼性データは該少くとも一つの部品が保守を必要とすることになる予測された年齢もしくは年齢のずれ(オフセット)と関係しているデータを含んでいる。
【0015】
この発明の第二の特徴によると、計算機が使用できる媒体上に記憶された計算機プログラムが用意されていて、該計算機プログラムは部品データベースと信頼性データベースとを含んでいる応用を備えており、該応用はさらに以下の段階を該計算機が実行するようにする計算機が読取り可能な命令を含んでいるものであり:該段階は、保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力するようにユーザに助言する段階と;該部品データベース内に提示された少くとも一つの部品と関係した信頼性データを該信頼性データベースに向けて入力するようにユーザに助言する段階と;該部品と信頼性データとの間の予め規定した関係に従って、少くとも一つの該部品についての予測される保守に関する出力データを計算する段階とである計算機プログラムとなっている。
【0016】
この発明の第三の特徴によると、保守プロジェクトをモデル形成するためのシステムであって、処理手段を有する計算機と、該計算機のメモリ上に記憶された応用プログラムとを備えており、該応用プログラムは、該保守プロジェクトの一部として保守されることになるいくつかの部品の状態に関する部品データを記憶するための部品データベースと;該部品データベース内の部品データによって提示される少くとも一つの部品についての予測される性能に関する信頼性データを記憶するための信頼性データベースとを含んでおり、該処理手段は、該部品と信頼性データとの間の予め規定された関係に従って、該部品の少くとも一つについての予測される保守に関する出力データを計算するようにされているシステムとなっている。
【0017】
上述のシステムの好ましい特徴については特許請求の範囲に記載の請求項に記述されている。
【0018】
“保守”作業(maintenance operation)はここでの記述の文脈では単に修繕とオーバーホールとの作業を言うのではなく、完全な部品の交換作業も指すことは理解されると思う。また、モデル形成方法(modelling method)は修繕可能か交換可能な部品の保守を含むいずれもの保守システムに応用できることも理解できると思う。好ましい実施形態では、航空機保守システムをモデル形成するための方法とシステムとが記述されている。
【0019】
添付の図面を参照し、例をあげてこの発明を記述して行く。
【0020】
実施例
図1を見ると、航空機隊(フリート)の保守システムをモデル形成するための応用プログラム1がプロジェクトデータベース2と、マスターデータベース3と、出力データベース5とを備えている。マスターデータベース3は三つの別個のデータベース、すなわち、部品データベース7と、部品コストデータベース9と、信頼性データベース11とを備えている。
【0021】
以下に説明するように、応用プログラム1はある時間期間にわたって保守システムをモデル形成するためのツール(道具)を効果的に用意している。この応用プログラム1は保守スケジュール(計画表)の形式でモデルを生成し、この計画は推奨された貯蔵(在庫)レベルで特定の部品についてのものと、この特定部品が取得されなければならない日付とに関係している。保守スケジュールは、また、この保守システムの継続期間中にこの部品の保守に含まれる予測コストを生成することもし、そこには資金の流れ(キャッシュフロー)、利益及び損失についての解析を含んでいる。したがって、この応用プログラムは将来の保守システムをモデル形成して、既存の保守システムをストリームラインに加え、また将来の保守契約のための入札値を生成するためのツールとして作用するように使うことができることは評価されると思う。
【0022】
応用プログラム1は記憶されて、計算機システムである例えば通常のパーソナルコンピュータPC(図示せず)上で実行される。この計算機システム上で実行されるときには、応用プログラム1はデータか各データベース2,7,9,11に、通常の入力デバイス(例えばキーボード)という手段で、あるいは以下で説明するように計算機網を介してのデータダウンロード動作用手段によって、入力できるようにする。図1では、各データベース2,7,9,11へのこのデータ入力手段は矢印13,15,17,19によってそれぞれ表わされている。
【0023】
ソフトウエアレベルでは、応用プログラム1はマイクロソフト社のエクセルのような、通常のスプレッドシートプログラムを用いて構築される。代るものとして、リレーショナルデータベースも使用できる。当業者により理解されるように、スプレッドシートパッケージは、多数の別個のデータベーステーブルを規定している手段によって、別個のデータベースを便利に構築できる。データ入力もまた便宜を与えられる。各データベーステーブルはグリッド(格子)システムとして形成され、そこでは別個のデータ要素がいわゆる“セル”の中に入れたデータベースの“データ”を作り上げている。各セルは、したがって各データ要素は、ユニークなセルラベルによって提示される。数字がデータの行のラベルを表わしていて、アルファベット順の文字が列のラベルを表わしている。したがって、特定のセルについてのセルラベルは行と列とのラベルを備えている。応用プログラム1を備えている各データベース2,5,7,9,11はスプレッドシートプログラム内部で別個のデータベーステーブルとして形成されている。
【0024】
以下で明らかになるところであるが、プロジェクト、部品、部品コスト、及び信頼性データベース2,7,9,11内部の若干のデータ要素は他のデータベース内部の他のデータ要素と予め規定された関係に従ってリンクされている。図1では、このデータリンク機能が矢印21により表わされている。このような予め規定された関係は簡単な数学的関係を含んでいて、加減乗除算といったものであり、データベース内部のデータ要素間での計算であるが、もっと複雑な関係であるブール代数、対数あるいは統計関数といったものを含んでいてもよい。一番基本的なレベルではデータはデータベース間で単純に共用されていてよい。こうして、例えば、データベース2,7,9,11内部に記憶されたデータ要素の数はいくつかの他のデータベース内部に記憶されてもよいことになる。
【0025】
プロジェクト、部品、部品コスト、及び信頼性データベース2,7,9,11内部に記憶されたデータが使用されて、出力データを計算もしくは算出することになり、それが出力データベース5に記憶される。この記憶動作を表わしているデータチャンネルが矢印23で示されている。記述したのと同じように、出力データベース5内部のデータ要素の計算が、プロジェクト、部品、部品コスト信頼性、及びデータベース2,5,7,9,11内部のデータ要素間の多数の予め規定した関係に基づいている。出力データベース5におけるいわゆる出力データは終局的には保守モデルを形成するものである。
【0026】
一般に、市販のスプレッドシートプログラムは、異なるセルあるいはセル群の間で機能的な関係が規定できる便宜を提供している。データベース2,5,7,9,11内部の異なるセルあるいはセル群の間の異なる前もって規定された関係を特定するために使用され、これにより応用プログラム1は出力データベース5内に記憶するために出力データを計算する。こういった関係を特定することによって、新しいデータでプロジェクト、部品、部品コストもしくは信頼性データベース2,7,9,11のいずれかに入力されているものはこのモデル内のどこかで反映されることになる。
【0027】
プロジェクト、部品、部品コスト及び信頼性データベース2,7,9,11と、そこに含まれたデータとは、ここで詳細に説明されることになる。
【0028】
図2を見ると、プロジェクトデータベース2が示されている。プロジェクトデータベース2はいわゆる“プロジェクトデータ”を記憶するために使用される。このプロジェクトデータは保守要件と関係する経済的情報に関する各種パラメータを定義するために使用される。例えば、もし応用プログラム1が保守契約について入札ツールを用意するために使用されるとすると、航空機オペレータは各種の契約パラメータを特定することになり、これらのパラメータはプロジェクトデータベース2に入力される。プロジェクトデータベース2自体は多数のサブデータベース(部分的なデータベース)を含んでいて、言い換えると、契約データベース25と、フリート(隊)定義データベース27と、経済的データベース29と、コストマークアップ(値上げ)データベース31とを含んでいる。
【0029】
契約データベース25は次のデータを記憶している(上から下へと読む):フリートデータ(フリート名);#A/C(モデル内に組込まれることになる航空機の数);FHAnnual(航空機当りの平均年飛行時間数);フリートFH(編隊についての全飛行時間数);CL/gys(年単位の契約の長さ);BER値(経済的な修理を越える値、すなわち、修理コストが経済的には適切でないとされる、全部品コストの割合(百分率));AOGレベル(地上に航空機がある(AOG)レベル)−これはAOGアイテムとして分類される部品についての保守オペレータによって許されているシステムについての需要の(与えられた年についての)百分率として表現されている−(AOGアイテムは航空機を動作状態とするために緊急事項として取得されることになるものである);信頼カテゴリイレベル(保守作業が必要とされるときに貯蔵の中に特定の部品カテゴリイをもつことについて求められている確信レベルであり、三つのカテゴリイ1ないし3が定義されている。)
フリート定義データベース27は、このモデル内に組込まれることになるすべての航空機の実際の名前を規定し、またそれらが関係している飛行時間と年を単位とした年齢(エイジ)を規定している。
【0030】
経済的なデータベース29は多数の可変パラメータを規定していて、このパラメータは応用プログラム1により使用されて、そのモデルの中でのコスト情報に基づいて完全に詳細な経済的解析を構築するのにあてられる。これらのパラメータは:US$/£(すなわち通貨交換レート);現在の利率;リース(賃貸)レート;割引きレート;保証レート;インフレーションの現在レート;現在減価償却レート(current depreciation rate);資本控除(capital allowance)レート;及び法人税率(corporation tax rate)である。
【0031】
コストマークアップデータベース31は保守オペレータの乗数に関係したデータを含んでおり(これが百分率で与えられている)、これが保守オペレータの実際の持ち上げ(アップリフト)を用意するために、すべての計算されたコスト関連データに適用される。この例では、異なる乗数が異なるコスト形式について特定されている。信頼性要因(ファクタ)もまた特定されていて、これが“安全の因子(factor of safety)”であって、特定の部品をいつ注文するかを決めるのに使用されるようにし、保守を必要とすることが実際に予期されるときと関係している。
【0032】
他の形式のプロジェクト、もしくは契約が関係したデータがプロジェクトデータベース2の中に組込まれていてよい。終局的には、実際の航空機オペレータと応用プログラム1との間のインターフェースを用意することになっている。
【0033】
図3を見ると、部品データベース7が示されている。一般に、部品データベース7はすべての部品の詳細を記憶するために使用され、これらの部品は保守システムの一部として保存されているべきものである。この例では、三つの航空機部品(部品番号1,2,3)が部品データベース7内に含まれている。しかし、実用上は何千もの異なる部品の詳細が保管されていてよいことは評価できると思う。部品データベース7内に記憶されたデータの詳細は適当な列のラベルを参考にして記述されている。
【0034】
列Aでは、各部品番号が特定され、例えばPN1,PN2などとなっている。この列のすべてのデータセルは部品コストデータベース9と信頼性データベース11とにリンクしていて、こういった部品番号に対応しているデータが適当な部品番号と一緒に記憶されている。列Bには各部品の記述が特記されている。
【0035】
列CとDとでは、各部品について採用されるべき貯蔵施設の形式に関するデータが与えられている。この場合には二つの異なる貯蔵施設形式が用命に応じるようにしている。第一に、もし航空路線のオペレータが、その者の独占的な使用のために特別な預け場所(コンサインメントプール)に保管された部品を持つことを希望するとすると、そのときは列Cに“1”が入ってそのことが示される。列Dの中の“1”は、ある部品が中央プール内に保管されているべきこと、すなわち一つならず他の航空路線オペレータにとっても利用できてよいことを示している(“0”はオペレータが誰もいないことである)。無論コンサインメントプール内に部品を貯蔵することに含まれるコストは一般に余計支出を伴うことになる。列Eでの“1”は、その部品が全体の“R&O”(修理とオーバーホール.注.PCT原出願のRSOは誤記)モデル内に組入れられるべきことを示している。この場合には、三つ全部の部品、すなわちPN1,PN2,PN3が中央プール貯蔵施設とR&Oモデルの内に組入れられている。
【0036】
列FからLまでは保守システムの一部として含まれることになる部品の数に関するデータを保存している。列Fは“QPA(航空機についての数、Quantity Per Aircraft)に関係している。これはある航空機についての特定部品の正規の数量を表わしている。列GないしJは保守対象のフリート(隊)の航空機についてのその部品の実際の数量を示す。プロジェクトデータベース2は、七機がモデル内に含まれていたとしたが、ここでは説明を容易にするために、四機だけの詳細が示されている。特定の航空機はQPA列で特定されたものとは違った数の部品を取付けていてもよいことに注意されたい。例えば、航空機(A/C)“2”として列HにあるものはPN1の部品を一つも取付けておらず、しかしその航空機には二つが取付けられるべきものと仮定されている。こういうことが生ずるのは、古い部品で同じ機能をもっているが部品番号が違っているものが、その特定の航空機に取付けられていることによる。“QFitted”とした列、すなわち列Kはこのモデルについて取付けられた部品の全数である。
【0037】
列LからOまではモデル形成されているフリート(隊)の中の各航空機についてのその特定部品のうちの一番古いものについての年齢(飛行時間単位)に関するデータである。言い換えると、列LはA/C1に取付けた二つの部品のうちの一番古い部品の年齢に関するものであり、列MはA/C2に取付けた二つの部品のうちの一番古いものの年齢に係るといった具合である。最後に、列Pはフリートに取付けた一番古い部品の年齢を示し、この場合はA/C2上の最古部品に適合した20193飛行時間である。
【0038】
図4を参照すると、部品コストデータベース9が示されている。列Aは部品データベースの列Aとリンクしているので対応している部品番号が関連の部品コストデータと関係付けて示されている。この部品コストデータは、更新され新しくなっている今日的なコスト情報であって、部品データベース7内に記憶されている各部品に関するものを特定している。部品コスト情報は実際には二つの主な群に分けられている:列BからFまでは交換部品を購入するコストに関する部品コストデータを特定し、また列GからRまでは試験と修理を部品についてするコストに関係している。
【0039】
列BからFまでに関しては、列Bはその部品をOEMから新部品で購入することのコスト(コストニュー)に関係し、また列Cは部品を配送するコスト(コストデリバリイ)に関係している。列Dはその部品についての月当りの償却(Dep/MTH)コストに関係していて、もしその部品が新品として購入されたが償却された価値のものとなる後のときまで使用されないとした場合に関するものである。列Eは別の調達元から一新した部品を購入することのコスト(コストマーケット)と関係していて、部品コストデータについての代りの供給源を用意している。このようにして、このモデルは一番低い部品コスト価格を選ぶように構成できる。列Fは新しい部品を取得することに含まれる計算上の(ロジスティカルな)コストに関係している。
【0040】
ここで列GからRまでを見ることとして、三つの別なデータについてのサブセットが部品の試験と修理とのコストに関係して特定されている。先ず、列GからKまでは部品を試験して、“NFF”状態(No Fault Found,故障は何も見付からない)を見付けることに含まれるコストに関するデータを保存することである。(言い換えると、部品を取外して、試験して、航空機に戻すまでのコストである)。列LからNまでは部品のオーバーホール(O/H)を実行するのに含まれるコストであり、また列Oは部品を試験して、しかも“BER”(Beyond Economic Repair)状態、すなわち部品を修理するコストが新しい部品を購入するコストについての特定された百分率限界を越える状態を見付けることに含まれるコストに関係している。プロジェクトデータベース2に関して前述のようにプロジェクトデータはBERレベルを70%に設定している。
【0041】
“NFF”組のデータに関しては、列GはOEMによって供給されたところにより“NFF”状態を見つけることについての推定コストに関するデータを保持している。列Hは試験コストデータの代りの組に関するデータを保持している。列IとJとは二つの異なる部品製造元(すなわちOEMではないところ)からのさらに別な代りのコストデータ源を保持している。したがって、特定の部品について見付けられる“NFF”状態に関するコストデータについての四つの別個の源を用意していることになる。どの源をモデルに組入れるかについて出力データを計算するときにする選択は、コストデータの最小値となるように予め定義されている(無論、何らかの階層構造関係が定義されるようにできることではある)。このデータが列Kに記憶される。
【0042】
“NFF”データについては、二つの代替コストデータのサブセットが各部品の修理とオーバーヘッド(O/H)を実行するために特定されている。列Lは部品のOEMにより供給された推定のコストデータに関係していて、列Mは実際の源データに関係している。この場合に、実際のデータで列Mに記憶されているものが一番正確であると考えられるので、このデータが選ばれて列Nに記憶される。
【0043】
列Oは部品を試験して“BER”状態が発生したことを設定するためのコストデータを含んでいる。
【0044】
上記のことから分ることであるが、部品保持作業の異なる形式について更新された今日的な部品コストデータを用意し、併せて異なる源からのコストデータについての複数の組を用意することによって、保守についての最も経済的な方法が特定の源から識別される。
【0045】
列PからRまでは求められている各修理作業についての統計的なもっともらしさ(尤度、likelihood)に関係していて、言い換えると列Pは発生している“NFF”状態の尤度に関係し、列Qは求められているオーバーホール(O/H)作業に係り、また列Rは発生している“BER”状態に係る。この例が示すように、統計的には、“BER”状態は発生がゼロ確率を有している。この統計的な情報は、修理作業のコストを計算するときに勘定に加えられる。そこで、“NFF”状態は、時間の12%で発生しそうであり、オーバーホールは時間の88%を必要としそうであり、必要とされた修理作業を実行する全コストは列Kで与えられた値(好ましいとされる“NFF”コストデータ)の12%で、列Nに与えられている値(好ましいとされるオーバーホールコストデータ)の88に加えられたものと推定されてよい。再びここでも、コストデータ間のこの関係は応用プログラム1により実施された全体のモデルの中で前もって定義されている。列Sは修理に置かれている部品を保存するのに必要とされる“平均の現場(ショップ)にある時間(Mean Shop Time)”である。列Tは修理に置かれた部品を保存しこの部品を航空機上に戻すという二つのことについての“ターンアラウント”タイムTAT(所要時間)”に関係している。これはMSTに10日を加えるものとして予め定義されている。これが列Tに記憶されているデータによって反映されている。
【0046】
図5を見ると、信頼性データベース11が示されている。部品コストデータベース9のように、この信頼性データベースの列Aは部品データベース7の列Aとリンクしているので、対応している部品番号は関連部品の信頼性データと関係付けられている。次のことを心にとめて、すなわち、応用プログラム1の目的はスケジュールにない保守システムに含まれる予測された計画とコストとをモデル形成することであることを思うと、“MTBUR(スケジュールされていない修理(UR)間の平均時間)”データが、飛行時間という項目で、用意される。“修理(repair)”はまた部品交換と、実際のオーバーホール(O/H)形修理作業とを併せて、組込んでいることは理解できると思う。
【0047】
列BからEまでには、四つの代替源がMTBURデータについて用意されている。列Bは実際の航空路線オペレータからのMTBUR試験データを保持していて、このオペレータについてはモデルが使用されている。これは一般に最も正確なMTBURデータ源と考えられている。列Cはいわゆる“クローンフリート(clone fleet)”言い換えると、非常によく似た航空路線オペレータからのMTBURデータを保持している。
【0048】
列DはMTMURデータで似たような航空路線の全世界フリート(WF)からのものを保持し、また列Eは推定されたMTBURデータであって、通常四つの源(ソース)のうちの一番小さな信頼性のデータであると考えられているものを保持している。
【0049】
列FとGとは、それぞれMTBURデータの実際の値と源(SOURCE)とに関するデータを保持していて、所定の階層構造に従って選ばれたものである(Predictedは予測されたものを意味する)。上記のように、列BにあるMTBURデータは一番大きな信頼性のあるものと考えられており、したがって、もしこのデータが利用可能であるとすると、これが使用される。この場合は、このようなデータが列BかCかDかで利用可能となっているので、列Eの予測されたデータが選ばれる。このプロセスは信頼性データの一番正確な源はこのモデル使用される。
【0050】
列Hは“Essentiality(不可欠性)”の三つの類型(カテゴリイ)に関するデータを保持している。これらのカテゴリイはその部品が航空機の実際の作業にとってどのくらいクリティカル(重大)であるかを定義している。カテゴリイ1の部品は最もクリティカルであって、この部品なしには航空機は作動することができないものである。例えば翼(ウイング)部材がカテゴリイ1の部品である。カテゴリイ2の部品は“go if(条件付き進行)”部品であり、これが意味するところは航空機が同じ記述の一つの他の部品を有していることを条件として、航空機をそのまま運行してよいとすることである。カテゴリイ3の部品は“go(進行)”部品、すなわちノンクリティカル(非重要)である。読書用ランプとかコーヒーメーカーなどがカテゴリイ3の部品の例となろう。
【0051】
列Iは保守作業が求められている事象で在庫に部品があるという求められている確信(コンフィデンス)レベルに関するデータを保存している。プロジェクトデータベース2に関して述べたように、航空路線オペレータは各カテゴリイと関係付けて求められている確信レベルを特定する。したがって、列Hは列Gでの不可欠性カテゴリイとリンクした確信レベルを保持するように定義され、言い換えると、カテゴリイ1の部品については98%カテゴリイ2の部品については95%、またカテゴリイ3の部品については92%ということになる。
【0052】
列Jは計算された年齢(飛行時間として)に関するデータを保存していて、この年齢ではある部品が貯蔵されていなければならない、いわゆる購入どき(“buy at”)年齢である。この値は選ばれたMTBURを基に計算され、言い換えると、列Fに記憶されているデータにプロジェクトデータベースで特定されているような信頼性因子、すなわち0.9(90%)を乗じたものである。したがって、PN1については、選ばれたMTBURで使用されるものは32000飛行時間であり、それに購入どき(“バイアット”)年齢が28800飛行時間となる。
【0053】
列Kでは、年あたりの取外しについての計算された数に関するデータが記憶されている。このデータはプロジェクトデータベース2で特定されたFH年(FHannual)値を採り、それを列Fの中の選ばれたMTBURで除算したものである。したがって、PN1の場合には計算した値は0.1016となる(REM:Removal、取外しの意)。
【0054】
最後に、列Lでは、同じ部品について、ターンアラウンドタイム(TAT:所要時間)の間に必要とされる保守作業の尤度に関するデータが計算されて記憶される。すなわちこれがλ* となっている。換言すると、この列は保守を必要としているある部品についてのチャンスを表わしていて、それと同じ部品(これは交換してあってもよい)が依然として航空機には取付けられていない状態にある場合とする。これは列Kにある値を部品コストデータベース9の列T(ターンアラウンドタイム)に対応する値によって乗算して得られ、すべては一年の日数365.25で除算されている。
【0055】
前述したように、保守モデルを含んでいる出力データが、出力データベース5に矢印23で示したように入力されると、プロジェクト、部品、部品コスト及び信頼性データベース2,7,9,11内のデータ間の所定の計算機処理上の関係により計算されている。
【0056】
出力データベース5の動作についてここで詳述する。
【0057】
図6を見ると、出力データベースは三つの別なデータベースを含んでいてそれらは“If buy(買うとして)”データベース33と、“Qbuy(買う数量)”データベース35と、“When buy(いつ買うか)”データベース37であり、その各々は以下で詳述されることになる。これら三つのデータベース33,35,37は進行形の鎖(プログレッシブ チェーン)として示されているが、その理由は“Qbuy”データベース25が“If buy”データベース33から供給されるデータ値に依存している事実と、同じように、“When buy”データベース37が“If buy”と“When buy”データベース33,35の両方から供給されるデータ値に依存している事実による。矢印23(38)に示すように、プロジェクト、部品、部品コスト及び信頼性データベースからのデータは三つのデータベース33,35,37に入力されて、最終出力データが生成されるようになる。この出力データは三つの別々な出力データファイルの形で生成され、“出力スケジュール(計画)ファイル”39、“購入(Buy)リスト”41及び“見積り(Quote)”43である。
【0058】
“If buy”データベース33の目的は、どの部品が保守システムの一部として購入されるべきかを判断して決めることである。実際に、応用プログラム1によって用意される主な技術的利点の一つは、保守を必要としそうな度合が大きい部品が在庫されるようにできて(ダウンタイム(使用不能時間))を減らし、それによって保守を必要としそうもない部品を貯蔵する必要性を排除することである(これによって支出と在庫という面でのコスト減となる)。これは(a)ハイリスクアイテム(危険の大きい物品)すなわち保守を必要としそうな部品、及び(b)必要とされるアイテム、すなわち航空路線オペレータもしくは製造会社がともかくも使用可能であるべきと特定した部品であるアイテムを識別することによって実行される。
【0059】
図7を参照すると、“If buy(買うとして)”データベースが詳細に示されている。部品、部品コスト、及び信頼性データベース7,9,11の場合のように、第一の列(列A)は各部品の部品番号を含んでおり、すなわち、部品データベース7の列Aとリンクされている。列Bはその部品が航空路線オペレータによって“必要とされる部品”として特定されているかいないか(REQ?)に関するブール代数値を保持している。この例の場合には、PN1は必要とされる部品として特定されていて、それ故に“1”がこの列に入力されている。PN2とPN3とは必要な部品として特定されていない。列CとDとは信頼性データベース11で特定されたように選ばれたMTBURと、関係する源(SOURCE)データとを保持している(図5の列FとGとを参照)。列Eは、システムが使用される時間期間の始めにおける、その部品番号に対応している部品の最大年齢に関するデータ(PN AGE IN)を保持する。このデータは部品データベース7から採られる(図3の列Pを参照)。列Fは契約期間の終りにおけるその部品の予測年齢(飛行時間単位)に関するデータ(A/C AGE OUT)を保持する。この値はプロジェクトデータベース2からのFHannualとCL/年を乗算する手段により計算される。すなわちその部品が契約の有効期間にわたって持ちこたえることになる予測飛行時間数を計算し、次にこの数字を列Eに記憶されている現在の年齢値に加えることによって計算される。列Gは信頼性データベース11で特定されたようにその部品の不可欠性カテゴリイ(ESS)を示し、また列Hは別の不可欠性カテゴリイでESS= 1*(図7の列Hにつけた単なる名称)として知られているものを示し、この値は列Gで特定されたカテゴリイから求められる。この実施例の目的に対しては、列H内の値は重要なものではない。最後に、列Iはその部品が取得、すなわち買うか(Buy)借りるかされなければならないか否か(Don’t)を示している。前のパラグラフで示したように、この列に対して計算される値は二つの先行する試験に依存している。第一の試験はこの部品がハイリスクの部品であるか否かである。この試験は、列C内のMTBUR値が列F内の値よりも大きいことを条件として、列Iに対して“buy(買う)”という値を出力することになる。列Fの値は予測された部品年齢である。ここでの場合では、どの部品もハイリスクであるとは考えられていない。次に、どの部品もハイリスクと考えられていないとしても、もし航空路線オペレータがその部品が必要とされていることを特定したとすると、そのときは“buy(買う)”の値が戻される。こうして、PN1についての列B内の値が“1”であるから、列Iは“buy”をPN1について示している。
【0060】
ここで“Qbuy”データベース35(図6と8)を参照することとする。PN1が買うべきものとして決まると、次の段階は取得することになる部品の数量を判断して決めることになる。この計算はいわゆる“ラムダ(λ)”値についての統計的な解析を実行することによって決まるのであり、ラムダ値は信頼性データベース内で計算されたλ* 値から求められる。この統計的解析は、ポアッソン(Poisson)分布解析を実行して必要とされる確信(コンフィデンス)レベル(これは上述のように部品のカテゴリイに依存している)に適うことが求められている部品の数を決めることを含んでいる。当業者はポアッソン分布が通常の統計解析であって部品故障レートをモデル化するのに使用されているものであることを理解できると思う。“Qbuy”データベース35は図8に詳しく示されている。
【0061】
図8を参照すると、列Aは各部品の部品番号(PN)を示す。列Bは“If buy”データベース33の列Iに戻った値を示す。従って、PN1については“buy(買う)”が示され、PN2とPN3については“Don’t(買わない)”となっている。列Cは航空機の隊(フリート)に取付けられた部品の数に関するデータ、すなわち部品データベース7の列KからのQfitted値を保持している。列Dは各部品について必要とされた確信(コンフィデンス)レベルに関するデータ(Conf)、すなわち、信頼性データベース11の列Iに保持されているデータを保持している。列Eは、同じ部品についてのターンアラウンドタイム(所要時間)の間に必要とされる保守作業の尤度に関するデータ(すなわち、信頼性データベース11の列Lからのλ* 値)を保持する。列Fはいわゆる“ラムダ値”を保持し、この値は列CにあるQfitted値によりλ* 値を乗算して計算される。この乗算は、しかしながら、列Bに“buy(買う)”条件があるときに限り行なわれる。したがって、唯一つのラムダ値が“Qbuy”データベース35内に存在していて、それがPN1についてのものとなっている。最後に、ポアッソン分布解析が列Fのラムダ値(Lambda)について実行されて、列Dで特定されている確信度レベルすなわち95%に適うものとするために求められている部品数(Q)を判断して決める。この統計的解析は値“1”を結果とし、PN1部品が必要とされていると結論し、それにより“1”という値が列Gに戻される。システムの全寿命中にはPN1部品が一つではなくもっと部品が必要とされるであろうが、この解析が意味していることは、単一のPN1部品が在庫にある限りは別のPN1部品が、その単一のPN部品を含んでいるスケジュールにない保守作業のターンアラウンドタイム中に、必要とされることがない95%の尤度が存在していることである。
【0062】
ここで“When buy”データベース37を見ることとする。PN1が取得されることが設定され、また“1”という量が必要とされる確信度レベルに適うために在庫されることを要すると設定されると、次の段階はシステム寿命の中のどの時間にPN1部品が取得されるべきかを判断して決めることである。これは、次の保守作業が生ずることになる予測時間を基礎として計算される。
【0063】
図9は“When buy”データベース37を詳細に示している。図9を参照すると、列Aは各部品の部品番号を示す。列Bは各部品について必要とされた数量を示す。したがって、“Qbuy”データベース35の列Gに記憶された値は“When buy”データベース37の列Bにも記憶されている。列Cはその部品の現在の年齢(CAge)に関するデータ、すなわち部品データベース7の列7に記憶されている値を保持している。列Dは信頼性データベース11内に記憶された“Buy at”データに関するデータを保持する。列Eは“Buy at”時間が発生したとき、(すなわち、“Buy at”データから列C内の“現在の年齢(CAge)”を減算して計算が実行される)予測された時間のずれに関するデータを保持する。PN1の場合には、これが8607飛行時間という予測値を与え、言い換えるとその部品が8607飛行時間で購入されるべきとしている。列E内の値が与えられ、かつその部品を取付けた航空機の飛行時間についての期待数についての知識が与えられると、“When buy”データベースはその後にPN1部品がいつ取得されなければならないかのスケジュールを計算する。このスケジュールは契約の各年について出力され、すなわち列FないしKにある1ないし6年(YR1〜6)に対応している。各列に向けて出力された数字はその部品が取得されなければならない月を示しており、すなわち“4”は4月を、また“12”は12月を示している。こうして列HはPN1部品がシステムの寿命の三年次の4月に取得されなければならないことを示し、別のPN1部品がシステムの寿命の四年次及び5年次の12月に取得されるとしている。
【0064】
“If buy”,“Qbuy”及び“When buy”データベース33,35,37で出力データが生成されると、三つの別個の出力ファイルが生成されて便利な形式でこの出力データを提示するようにする。上述のように、これら三つの出力ファイルは“出力スケジュールファイル”39と、“購入リストファイル”41と、“見積りファイル”43である。
【0065】
出力スケジュールファイル39はシステムの寿命中に出力データの全部についての分解したもの(内訳細目、フルブレークダウン)を用意する。“When buy”データベース37からのデータは部品コストデータベース9からの部品コストデータと(相互に)他所参照されてシステムの寿命中にわたって必要とされる部品を保守することに含まれるコストの明細を生成する。理想を言えば、このコストはシステムについての毎年の中での異なる時間に注文されることになる部品のリストを表示するように分解されていて、これを実行するときの関係するコストも表示するようになっているのがよい。このデータはまた経済データとしてプロジェクトデータベース2にあるものと他所参照がされて、現在の利率、リースレート、インフレーションなどがすべての計算されたコストについての保守オペレータの上のせ分と一緒に計算するようにして、キャッシュフロー(資金の流れ)、利益及び損失といったものを含んでいる、システムの完全に詳しい経済分析を用意するようにしている。
【0066】
“購入リストファイル”41はシステムの寿命中の特定の時間で取得されることになる部品についての計画されたリストを簡単に用意する。この部品の計画されたリストをコストデータベース9からの部品コストデータと他所参照(クロスレファレンス)することによって、特定の部品供給元は、より競争できるコストデータを作るために将来の戦略的提携が識別されるようになる。
【0067】
“見積りファイル”43は出力スケジュールファイルについてのさほど詳細でないバージョン(版)を簡単に用意する。応用プログラム1が保守契約用の入札ツールとして使用される場合には、航空路線オペレータは一般に関係している全コストという項目で底の線を見たいと慾するのが普通であり、恐らくは年毎のコストの細目を伴うものとなる。
【0068】
前日のように、プロジェクト、部品、部品コスト、及び信頼性データベース2,7,9,11内部に記憶されたデータは繰返し更新できる。例えば、航空路線オペレータはプロジェクトデータベース2に異なる値を入力して、発生する全コストを判断するのにあてたいと慾することができる。このことは応用プログラム1に融通性を与えるものであり、航空路線オペレータは多数のシナリオやシステムの並べかえ、変更を急いで評価できるようになる。新しい部品が市場に出現すると、こういった部品についてのデータが部品データベース7で更新される。コストと信頼性データとの異なる源もまた部品データベース9と信頼性データベース11との中に、新データが利用可能となるとすぐに、入力されもする。こうして、更新されたアップトウデートのコストと信頼性データとがシステムの寿命中に組入れられて、それにより、このモデル中にフィードバックが取入れられ、そしてこのモデルにより生成された出力データの精度が改善される。このモデルにより生成された全体の出力データは前もって定義された計算機処理上の関係組に従って作られるのであるから、何らかのデータ更新作業は全体の応用プログラムの中で自動的に対処される。したがって、生成された出力データの各組は完全に新しい計算に基づいていて、以前の計算の単なる変更というのではない。こうして精度と融通性(フレキシビリテイ)とが備わったものとなっている。
【0069】
この実施形態のとくに好ましい特徴では、部品コストと信頼性データベース9,11についての更新されたデータが二つの遠隔計算機システム(示さず)の間のデータリンクという手段によって入力される。第一の計算機システムは更新されたアップトウデートの部品コストの源(ソース)となってインターネット接続を介して部品コストデータベース9に向けての直接ダウンロードにあたる。同じように第二の計算機システムはアップトウデートの信頼性データの源となって、インターネット接続を経由して信頼性データベース11への直接ダウンロードにあたる。
【0070】
応用プログラム1は、それ自体がオンライン計算機システムの一部として用意されてよい。すなわち、航空路線オペレータのような第三者が、例えばインターネット上での網接続を経て応用プログラムにアクセスできるようにする。応用プログラムは、ブラウザ形式のインターフェースを組込んでいて、プロジェクトデータベース2内のデータだけが処理されることになるようにする。プロジェクトデータベース内に異なる変数を入力することによって、航空路線オペレータは、結果として生ずる保守スケジュールに速かにアクセスでき、例えば必要とされる在庫とコストといったものにアクセスできる。
【0071】
最後に、ここで記述したシステムは保守が関係する各種形式のシステムをモデル形成するのに使用できることは理解されると考える。例えば、応用プログラム1は航空機ライン保守(メンテナンス)、保守訓練、大きな保守(ヘビイメンテナンス)及びエンジン保守システム(この場合には主変数は部品のパーツ番号ではなくログカードとなる)をモデル形成するのに適応できるものである。
【図面の簡単な説明】
【図1】
この発明による保守システムのモデル形成用応用プログラムの動作を示すブロック図。
【図2】
図1の応用プログラム内に組込まれたプロジェクトデータベースを示す図。
【図3】
図1の応用プログラム内に組込まれた部品データベースを示す図。
【図4】
図1の応用プログラム内に組込まれた部品コストデータベースを示す図。
【図5】
図1の応用プログラム内に組込まれた信頼性データベースを示す図。
【図6】
図1の応用プログラム内に組込まれた出力データベースの動作を詳細に示すブロック図。
【図7】
出力データベース内に組込まれた“もし買うとすると(イフバイ:購入条件)”データベースを示す図。
【図8】
出力データベース内に組込まれた“Qバイ(購入量)”データベースを示す。
【図9】
出力データベース内に組込まれた“ホエンバイ(いつ買うか)”データベースを示す図。
Claims (22)
- 保守システムをモデル化する方法であって、
部品データベースと信頼性データベースとを有する計算機システムを用意する段階と;
該部品データベースに向けて、該保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力する段階と;
該信頼性データベースに向けて、該部品データベース内の部品データによって表わされた少くとも一つの部品についての予測される性能に関する信頼性データを入力する段階と;
該部品と信頼性とのデータ間の予め規定された関係に従って、前記少くとも一つの部品に関する保守予測を表わしている出力データを計算する段階とを備えている方法。 - 請求項1記載の方法であって、該信頼性データベースは2以上の信頼性データのサブセットを含み、該出力データを計算する段階は所定の階層構造の規則に従って信頼性データ組の唯一つにアクセスすることを含んでいる方法。
- 請求項2記載の方法であって、該信頼性データベースは該少くとも一つの部品についての推定された信頼性に関する一つのサブセットを含んでいて、別のサブセットは該少くとも一つの部品についての経験的な信頼性データである方法。
- 請求項1ないし3のいずれか1項記載の方法であって、該部品データは現在の年齢である該少くとも一つの部品のサービスの長さであって該部品データベースで提示されているものと関係し、また該信頼性データは該少くとも一つの部品が保守を必要とすることになる予測された年齢であるサービスの長さと関係しているデータを含んでいる方法。
- 請求項1ないし4のいずれか1項記載の方法であって、該計算された出力データは保守計画の形式で出力データベースに向けて出力され、該保守計画は、該部品データベース内で提示されたいくつかの部品が保守を必要とすることになる予測された時間に関係している方法。
- 請求項1ないし5のいずれか1項記載の方法であって、さらに部品コストデータベースを用意して;該コストデータベースに向けて、保守のコストに関するコストデータを入力するか、あるいは該部品データベースで提示されたいくつかの部品を記憶するか、またはその両方を行なう段階を備えていて、該出力データは該コストデータと、該部品データか該信頼性データかの一方もしくは両方との間の予め規定された関係に従って計算される方法。
- 請求項6記載の方法であって、該部品コストデータベースはコストデータのいくつかのサブセットを含んでいて、該出力データを計算する段階は所定の階層構造の規則に従って該コストデータ組の唯一つをアクセスすることを含んでいる方法。
- 請求項6記載の方法であって、該部品コストデータベースは相互に相入れない保守作業に関するコストデータについての複数のサブセットと、必要とされている各保守作業の尤度に関する統計的なデータとを含んでいて、出力データを計算する該段階は、必要とされている各保守作業の尤度に基づいてコスト計算を実行することを含んでいる方法。
- 請求項6ないし8のいずれか1項記載の方法であって、該計算された出力データは出力データベースに向けて保守計画の形式で出力され、この保守計画は、該部品データベースで提示されたいくつかの部品が保守を必要とすることになる該予測された時間に関係し、また該保守システムによってカバーされる時間期間にわたり該部品を保守し貯蔵することの一方もしくは両方にとって必要とされている関連のコストに関係している方法。
- 請求項1ないし9のいずれか1項記載の方法であって、さらに、該計算機システム上にプロジェクトデータベースを用意する段階と、
該保守システムを定義しているいくつかのパラメータと関係しているプロジェクトデータを該プロジェクトデータベースに向けて入力する段階とを備えており、該出力データは該プロジェクトデータと、該部品、コスト及び信頼性データのうちのいずれかとの間の予め規定した関係に従って計算されている方法。 - 請求項1ないし10のいずれか1項記載の方法であって、該保守システムによってカバーされた時間期間中に、該計算機システムのいくつかのデータベースに向けて更新されたデータを用意する段階をさらに備えている方法。
- 請求項11記載の方法であって、該更新された部品と信頼性データとの一方もしくは両方が該計算機システムに向けて別の計算機システムから網リンク手段によって定期的にダウンロードされる方法。
- 請求項12記載の方法であって、該網リンクはインターネット上で設定される方法。
- 請求項1ないし13のいずれか1項記載の、航空機保守システムのモデル形成する方法。
- 計算機が使用できる媒体上に記憶された計算機プログラムであって、
該計算機プログラムは部品データベースと信頼性データベースとを含んでいる応用を備えており、該応用はさらに以下の段階を該計算機が実行するようにする計算機が読取り可能な命令を含んでいるものであり:
該段階は、保守システムの一部として保守されることになるいくつかの部品の状態に関する部品データを入力するようにユーザに助言する段階と;
該部品データベース内に提示された少くとも一つの部品と関係した信頼性データを該信頼性データベースに向けて入力するようにユーザに助言する段階と;
該部品と信頼性データとの間の予め規定した関係に従って、少くとも一つの該部品についての予測される保守に関する出力データを計算する段階とである計算機プログラム。 - 保守プロジェクトをモデル形成するためのシステムであって、
処理手段を有する計算機と、該計算機のメモリ上に記憶された応用プログラムとを備えており、
該応用プログラムは、該保守プロジェクトの一部として保守されることになるいくつかの部品の状態に関する部品データを記憶するための部品データベースと;
該部品データベース内の部品データによって提示される少くとも一つの部品についての予測される性能に関する信頼性データを記憶するための信頼性データベースとを含んでおり、
該処理手段は、該部品と信頼性データとの間の予め規定された関係に従って、該部品の少くとも一つについての予測される保守に関する出力データを計算するようにされているシステム。 - 請求項16記載のシステムであって、該信頼性データベースは2以上の信頼性データのサブセットを含んでいるシステム。
- 請求項17記載のシステムであって、信頼性データの一つのサブセットは該少くとも一つの部品についての推定された信頼性と関係し、また第二のサブセットは該少くとも一つの部品についての経験的な信頼性データであるシステム。
- 請求項16ないし18のいずれか1項記載のシステムであって、該応用プログラムはさらに保守プロジェクトを規定しているいくつかのパラメータに関するプロジェクトデータを記憶するためのプロジェクトデータベースを含んでいるシステム。
- 請求項16ないし18のいずれか1項に記載のシステムであって、該応用プログラムはさらに部品コストデータベースを備えていて、計算機データベースで提示されたいくつかの部品を保守し貯蔵することの一方または両方のコストに関するコストデータを記憶するのにあてているシステム。
- 請求項16ないし20のいずれか1項記載のシステムであって、該計算機は別な計算機に網で結ばれていて、この別な計算機は更新されたデータを該計算機のデータベースに向けてダウンロードするようにされているシステム。
- 請求項16ないし21のいずれか1項に記載された、航空機保守プロジェクトをモデル形成するためのシステム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0013937A GB0013937D0 (en) | 2000-06-08 | 2000-06-08 | A method of aircraft maintenance |
GB0017985A GB0017985D0 (en) | 2000-07-21 | 2000-07-21 | A method of modelling a maintenance system |
PCT/GB2001/002270 WO2001095133A2 (en) | 2000-06-08 | 2001-05-21 | A method of modelling a maintenance system |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004501447A true JP2004501447A (ja) | 2004-01-15 |
Family
ID=26244445
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002502617A Pending JP2004501447A (ja) | 2000-06-08 | 2001-05-21 | 保守システムをモデル形成する方法 |
Country Status (6)
Country | Link |
---|---|
US (1) | US20030149548A1 (ja) |
EP (1) | EP1314104A2 (ja) |
JP (1) | JP2004501447A (ja) |
AU (1) | AU2001258593A1 (ja) |
CA (1) | CA2410355A1 (ja) |
WO (1) | WO2001095133A2 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012069076A (ja) * | 2010-09-27 | 2012-04-05 | Toshiba Corp | 評価装置 |
JP2014085876A (ja) * | 2012-10-24 | 2014-05-12 | Dainippon Printing Co Ltd | メンテナンス情報編集装置、メンテナンス提案装置、メンテナンス情報編集方法及びメンテナンス情報編集プログラム |
Families Citing this family (37)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AUPR530801A0 (en) * | 2001-05-28 | 2001-06-21 | Almator Pty Ltd | A method of and system for managing operations in an enterprise or institute |
US6871160B2 (en) * | 2001-09-08 | 2005-03-22 | Scientific Monitoring Inc. | Intelligent condition-based engine/equipment management system |
US6885921B1 (en) * | 2002-05-09 | 2005-04-26 | Grace H. Farmer | Method and apparatus for managing aircraft maintenance records |
US7584156B2 (en) * | 2002-05-15 | 2009-09-01 | Lockheed Martin Corporation | Method and apparatus for estimating the refresh strategy or other refresh-influenced parameters of a system over its life cycle |
US20040010474A1 (en) * | 2002-05-15 | 2004-01-15 | Lockheed Martin Corporation | Method and apparatus for estimating the refresh strategy or other refresh-influenced parameters of a system over its life cycle |
US6892936B2 (en) * | 2002-05-16 | 2005-05-17 | Caterpillar, Inc | Service interlink |
US20060217929A1 (en) * | 2004-08-06 | 2006-09-28 | Lockheed Martin Corporation | Lifetime support process for rapidly changing, technology-intensive systems |
US20060031390A1 (en) * | 2004-08-09 | 2006-02-09 | Tetsuro Motoyama | System and method to evaluate a service contract covering a monitored device by integrating device, user, and account information |
US8131653B2 (en) * | 2004-09-30 | 2012-03-06 | Alcatel Lucent | Method and apparatus for warranty cost calculation |
US20060184825A1 (en) * | 2004-10-01 | 2006-08-17 | Nancy Regan | Reliability centered maintenance system and method |
US8165968B2 (en) * | 2004-10-25 | 2012-04-24 | The Boeing Company | Method and system for evaluating costs of various design and maintenance approaches |
US20080172268A1 (en) * | 2005-01-13 | 2008-07-17 | Standard Aero (San Antonio), Inc. | System and method of enhancing cost performance of mechanical systems including life-limited parts |
US20070050310A1 (en) * | 2005-01-13 | 2007-03-01 | Standard Aero (San Antonio), Inc. | System and method for enhancing cost performance of mechanical systems |
US20060235707A1 (en) * | 2005-04-19 | 2006-10-19 | Goldstein David B | Decision support method and system |
US7536284B2 (en) * | 2005-08-30 | 2009-05-19 | Lectromechanical Design Company | Electrical wire interconnect system risk assessment tool |
US20070078791A1 (en) * | 2005-09-30 | 2007-04-05 | Caterpillar Inc. | Asset management system |
US20070100760A1 (en) * | 2005-10-31 | 2007-05-03 | Caterpillar Inc. | System and method for selling work machine projects |
US20070101017A1 (en) * | 2005-10-31 | 2007-05-03 | Caterpillar Inc. | System and method for routing information |
US20070150317A1 (en) * | 2005-12-23 | 2007-06-28 | Caterpillar Inc. | Asset management system |
US20070145109A1 (en) * | 2005-12-23 | 2007-06-28 | Caterpillar Inc. | Asset management system |
US20070150295A1 (en) * | 2005-12-23 | 2007-06-28 | Caterpillar Inc. | Asset management system |
US20070150073A1 (en) * | 2005-12-23 | 2007-06-28 | Jay Dawson | Asset management system |
US20070226091A1 (en) * | 2006-03-16 | 2007-09-27 | Lucent Technologies Inc. | Systems and methods for determining cost targets for cost reduction projects |
US20100262442A1 (en) * | 2006-07-20 | 2010-10-14 | Standard Aero, Inc. | System and method of projecting aircraft maintenance costs |
US7496475B2 (en) * | 2006-11-30 | 2009-02-24 | Solar Turbines Incorporated | Maintenance management of a machine |
FR2909786B1 (fr) * | 2006-12-08 | 2009-01-30 | Thales Sa | Elaboration d'un message de maintenance preventif concernant les degradations fonctionnelles d'un aeronef |
US20080295100A1 (en) * | 2007-05-25 | 2008-11-27 | Computer Associates Think, Inc. | System and method for diagnosing and managing information technology resources |
US8712814B1 (en) * | 2007-06-20 | 2014-04-29 | Sprint Communications Company L.P. | Systems and methods for economic retirement analysis |
US8315999B2 (en) | 2007-08-29 | 2012-11-20 | Nirvanix, Inc. | Policy-based file management for a storage delivery network |
US20100114838A1 (en) * | 2008-10-20 | 2010-05-06 | Honeywell International Inc. | Product reliability tracking and notification system and method |
US8290802B2 (en) * | 2009-02-05 | 2012-10-16 | Honeywell International Inc. | System and method for product deployment and in-service product risk simulation |
US8266171B2 (en) * | 2009-06-11 | 2012-09-11 | Honeywell International Inc. | Product fix-effectiveness tracking and notification system and method |
US8849690B1 (en) * | 2009-06-24 | 2014-09-30 | American Airlines, Inc. | Optimized bill of work for aircraft maintenance based on task prioritization and time slot proximity analysis |
FR2959578B1 (fr) * | 2010-05-03 | 2012-08-03 | Airbus Operations Sas | Verification d'un systeme de communication d'un aeronef en developpement |
US9058359B2 (en) * | 2012-11-09 | 2015-06-16 | International Business Machines Corporation | Proactive risk analysis and governance of upgrade process |
US20160203425A1 (en) * | 2015-01-08 | 2016-07-14 | Infinera Corp. | Supply Chain Risk Mitigation System |
EP3156867B1 (en) * | 2015-10-15 | 2017-11-29 | Siemens Aktiengesellschaft | Maintenance system and method for a reliability centered maintenance |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0411873A3 (en) * | 1989-08-02 | 1993-11-18 | Westinghouse Electric Corp | Improved plant operating system employing a deterministic, probabilistic and subjective modeling system |
FR2785066B1 (fr) * | 1998-10-21 | 2001-08-31 | Eurocopter France | Procede et dispositif d'aide a la maintenance d'un systeme complexe, notamment un aeronef |
-
2001
- 2001-05-21 WO PCT/GB2001/002270 patent/WO2001095133A2/en not_active Application Discontinuation
- 2001-05-21 AU AU2001258593A patent/AU2001258593A1/en not_active Abandoned
- 2001-05-21 EP EP01931902A patent/EP1314104A2/en not_active Withdrawn
- 2001-05-21 JP JP2002502617A patent/JP2004501447A/ja active Pending
- 2001-05-21 CA CA002410355A patent/CA2410355A1/en not_active Abandoned
- 2001-05-21 US US10/276,740 patent/US20030149548A1/en not_active Abandoned
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012069076A (ja) * | 2010-09-27 | 2012-04-05 | Toshiba Corp | 評価装置 |
JP2014085876A (ja) * | 2012-10-24 | 2014-05-12 | Dainippon Printing Co Ltd | メンテナンス情報編集装置、メンテナンス提案装置、メンテナンス情報編集方法及びメンテナンス情報編集プログラム |
Also Published As
Publication number | Publication date |
---|---|
WO2001095133A3 (en) | 2003-03-13 |
WO2001095133A2 (en) | 2001-12-13 |
US20030149548A1 (en) | 2003-08-07 |
CA2410355A1 (en) | 2001-12-13 |
EP1314104A2 (en) | 2003-05-28 |
AU2001258593A1 (en) | 2001-12-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2004501447A (ja) | 保守システムをモデル形成する方法 | |
US8229791B2 (en) | Methods, systems, and computer integrated program products for supply chain management | |
US20070203810A1 (en) | Supply chain modeling method and system | |
JPH0750495B2 (ja) | カストマの注文の変動による在庫コストの影響を評価する自動化方法 | |
JP6370757B2 (ja) | 損益予測装置及び損益予測プログラム | |
JP2007323680A (ja) | 経営意思決定支援システム | |
EP1162557A1 (en) | A method of aircraft maintenance | |
EP1179795A1 (en) | A method of modelling a maintenance system | |
Geertjes | A first step towards fully automated spare parts planning systems-An empirical study on ordering behaviour | |
Yan et al. | Sustainable policies for a disruptions-tolerant production network model with green investment and incentive scheme amid various quality inspection setups | |
Ivanov et al. | Integrated planning and scheduling with dynamic analysis and control of service level and costs | |
Islan de Castro Mechanical | INVENTORY MANAGEMENT OPTIMIZATION FOR CAPITAL GOODS MAINTENANCE | |
Rowe et al. | Methods to predict performance in major program acquisition | |
Oswald | Measuring the impact of business rules on inventory balancing | |
McKone | Guidelines for investments in total productive maintenance | |
Kalf et al. | Simulating order fulfillment for aircraft line replaceable unit strategy A case study at KLM Component Services | |
Kumar | Recommendations to Improve Spare Parts Forecasting for New Model | |
Hodge et al. | A multi-echelon supply chain model for strategic inventory assessment through the deployment of kanbans | |
Park | Co-ordinating flows across supply chains in the low volume gas turbine industry | |
Amornsawadwatana | Risk management in multi-site concurrent engineering projects | |
Chugh | Management of a high mix production system with interdependent demands: simulation of proposed policies | |
Malliga et al. | The stock service improvement by the deployment of Six Sigma | |
Turan | A Decision support system for inventory management of information technology spare parts | |
Gorang | Scheduling a global engine maintenance network | |
Horst | Inventory control with orders without usage |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060214 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060515 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060529 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20061010 |