JP2018010617A - 航空機の不定期保守スケジューリングシステム - Google Patents

Abstract

【課題】航空機の不定期保守スケジューリングシステムを提供すること
【解決手段】システムは、航空機および前記非準拠条件の修理にリソースを割り当てる際の非準拠システムに関するデータを集約する。前記システムは、修理代替物を生成する前記非準拠条件および最適化ツールを受信し分配するサービス・バスを備える。前記最適化ツールは、ルール集合内の独立なルールを起動および停止しその重みを変更するためのルールの動的な再構成を可能とする。
【選択図】図２

Description

本開示は一般に航空機の不定期保守スケジューリングに関し、より具体的には、保守リスクを評価し、定期的な、時間配分型の部品取替に対するスケジュールの外部またはスケジュールされた検査およびそれらの関連付けられた修理動作の何れかで発生するコンポーネント障害イベントに関する航空機保守活動を指示するシステムに関する。

航空機は、都市間の人と材料のタイムリーな移動のためにかかる航空機に依存する航空会社または任意の企業の活力のもとである。特にサービスまたは他の保守のために地上にある航空機は、収入を生み出すことができない。目標は、航空機が必要に応じて利用できるように、航空機を耐空性条件において維持することである。

障害コードまたは予知警告のようなイベント、即ち、任意の非準拠条件が発生したとき、いつどこで必要なサービスを実施するかに関する判定をしなければならない。最適なソリューションに到達するための経路、修理場所、部品可用性等の様々な因子を最適化するのは困難な課題である。

本開示の１態様では、航空機保守スケジューリングに関するシステムは、メモリを有するプロセッサに接続されたフィールド・インタフェースを含み、ネットワーク・インタフェースを介してエラー・レポートを当該プロセッサと通信する電子非準拠リポジトリから受信するように構成され、当該エラー・レポートは航空機内の非準拠条件に関する情報を含む。当該システムはまた、当該メモリを有する当該プロセッサに接続されたベンダ・インタフェースを含み、航空機固有の障害情報および航空機内の非準拠条件に関する保守情報ならびに当該メモリを有する当該プロセッサに接続されたサービス・ブリッジを、航空機のオペレータ、航空機の飛行スケジュール、１つまたは複数の修理場所およびそれらの夫々の修理能力、および当該１つまたは複数の修理場所の各々に対する部品在庫から受信するように構成される。当該システムはさらに、当該メモリを有する当該プロセッサに接続された補助インタフェースを含み、当該飛行スケジュールに対応する位置および当該１つまたは複数の修理場所に対する少なくとも１つの天気サービスから天気データを受信するように構成される。当該システムはメモリおよびプロセッサを備える。当該メモリは少なくとも１つのルール集合を格納する。ルール集合は、航空機固有の障害情報、保守情報、飛行スケジュール、１つまたは複数の修理場所およびそれらの夫々の修理能力、部品在庫、および天気データを処理するための複数の独立なルールを含み、当該ルール集合はオペレータの基準ごとに構成される。当該プロセッサは、当該フィールド・インタフェース、当該ベンダ・インタフェース、当該オペレータ・インタフェース、当該補助インタフェース、および当該メモリに接続される。当該プロセッサは、当該ルール集合を実行して、ｉ）非準拠条件の補正を延期できるかどうかを判定し、延期可能であるとき、ｉｉ）非準拠条件を訂正するための一連の動作を決定するように構成される。当該システムはまた、当該プロセッサに接続され、非準拠条件を訂正するための当該一連の動作で規定された位置および時刻で提供されるように航空機に指示するための当該一連の動作を提示する、ディスプレイを含む。

本開示の別の態様では、航空機内の非準拠条件に関するデータを集約し非準拠条件の修理にリソースを割り当てるシステムは、非準拠条件に関するデータと、航空機に対する遅延されたリスク・データおよび技術データを格納し取り出す、当該サービス・バスに接続されたデータ・アプリケーション・サービスとを受信し配分するサービス・バスを備え、当該アプリケーション・サービスは当該サービス・バスを介して受信された要求に応答して当該遅延されたリスクおよび技術データを供給する。当該システムはまた、当該サービス・バスをオペレータ・ビジネス・アプリケーション・サービスに接続するサービス・アダプタを備え、当該サービス・アダプタはオペレータ・データをオペレータから受信するように構成され、当該オペレータ・データは経路計画および部品在庫を含む。当該システムはさらに、当該サービス・バスに接続された最適化ツールを備える。当該最適化ツール自体は、当該サービス・バスを介して受信されたデータをフォーマットするプリプロセッサと、ルール集合を用いて修理交換物を生成する最適化器とを備える。当該ルール集合は当該最適化ツールの動作中に構成可能である。

本開示のさらに別の態様では、航空機内の非準拠条件に対する保守応答を決定する方法は、メモリを有するプロセッサに接続されたフィールド・インタフェースを介して、航空機内の非準拠条件を受信するステップを含む。当該方法は、当該プロセッサおよび当該メモリに接続されたベンダ・インタフェースを介して、航空機に固有の非準拠条件に対応するさらなる障害のリスクを含む障害および保守情報の要求と受信を続ける。当該方法は、航空機のオペレータから、当該プロセッサおよび当該メモリに接続されたオペレータ・インタフェースを介して、航空機の飛行スケジュール、１つまたは複数の修理場所、および非準拠条件に関連する部品在庫を受信するステップを含む。単純性、曖昧性および変動性（ＳＡＶ）評価が、非準拠条件に対する修理履歴記録を非準拠条件に対する修理プロセスと比較することによって非準拠条件に対して生成される、当該ＳＡＶ評価は非準拠条件を解決するための単純性値、曖昧性値、および変動性値を含む。当該方法は、当該プロセッサで実行される当該メモリに格納されたルール集合を用いて、当該障害および保守情報、さらなる障害のリスク、航空機の飛行スケジュール、当該１つまたは複数の修理場所および非準拠条件に対するＳＡＶ評価を評価して、航空機に非準拠条件を解決させるための位置および時間を生成することで終了する。

説明した特徴、機能、および利点は様々な実施形態で独立に実現できまたはさらに他の実施形態で結合してもよく、そのさらなる詳細は以下の説明および図面を参照して理解することができる。

当該開示された方法および装置のより完全な理解については、添付図面でより詳細に示された実施形態を参照されたい。

本開示に従う航空機環境のブロック図である。 本開示に従う航空機保守スケジューリングシステムのサービス・アーキテクチャのブロック図である。 航空機保守スケジューリングシステムにおけるデータ・フローを示す図である。 航空機保守スケジューリングシステムの出力を示す例示的な図である。 航空機保守スケジューリングシステムを構成するためのステップの図である。 航空機保守スケジューリングシステムの利用に関連付けられたステップの流れ図である。 図６の流れ図の続きを示す図である。 航空機保守スケジューリングシステムに対するルール集合をカスタマイズする図である。 航空機保守スケジューリングシステムの機能的ブロック図である。

図面は必ずしも正しい縮尺で描かれておらず、当該開示された実施形態はしばしば概略的に部分図で示されていることは理解されるべきである。幾つかの事例では、当該開示された方法および装置の理解に必要でないかまたは他の詳細の認識を困難にする細部は省略されているかもしれない。勿論、本開示は示した特定の実施形態には限定されないことは理解されるべきである。

図１は航空機保守スケジューリングのためのシステム１０２の要素を示す。航空機１０４はイベントを生成し、当該イベントは分析のためにシステム１０２に送信される。当該イベントを、例えば、航空無線データ通信（ＡＣＡＲＳ）を用いて自動的に報告してもよい。他の条件では、当該イベントをパイロット、機械工または他の地上人員により報告してもよいか、または、過去の保守履歴に基づいて自動的に生成してもよい。

当該イベントが、軽い障害を読み取るような単純なレポートから、現在の危険を表しうる重大なエンジンコンポーネント条件までの幾つかの条件の何れかであってもよい。単純なものと重大なものの間には、この２つの間にある何千もの条件がある。これらのイベントの各々を評価し、資格ある保守人員による保守のために展開しなければならない。本開示の目的のため、「サービス」および「保守」とうい用語を交互に使用してもよい。多くの場合、保守は、航空機が必要な部品および技術責任者がある好都合な乗継点にくるまで、遅延されうる。他のケースでは、当該イベントは、航空機を修理工場にもっていくか、または、修理を保留して設置させる必要があるかもしれない。

当該イベントがシステム１０２に報告されることに応答して、データが航空機の製造業者１０６、オペレータ１０８、１つまたは複数の空港１１０、および天気情報ソース１１２を含む幾つかのソースから受信される。１実施形態では、ディスパッチャ１１４がシステム１０２の動作を監視する。

図３を参照して以下でより詳細に説明するように、製造業者１０６は、サービス手続きおよびリスク情報を含む航空機に関する情報を提供し、オペレータ１０８は、飛行経路サービス能力に関する情報を様々な空港１１０で提供する。天気情報ソース１１２は、航空機１０４の現在の飛行経路に沿った天気が可能な修理場所の選択に影響するかどうかを判定するために使用される。

図２は、システム１０２の例示的なサービス・アーキテクチャ・ビューを示すブロック図である。システム１０２の機能的ビューを図９に関して以下で提供する。システム１０２の独立な要素は、様々なシステム・コンポーネントの間のデータ接続性およびトラフィック管理を提供するデータ・サービス・バス１２０により接続される。サービス・ブリッジ１２２は、データ・サービス・バス１２０と様々な外部エンティティの間の接続性を可能とするための様々な標準およびカスタマイズされたアダプタを提供する。サービス・ブリッジ１２２はまた、様々なデータプロバイダへのおよび特に航空会社または他の航空運送業者へのインタフェースを構築する際に使用するための所定のプロトコルを有する統合アダプタを使用してもよい。本例示的な実施形態では、オペレータ・サービス・バス１２４への接続により、情報を全てのオペレータ・ビジネス・アプリケーション・サービス１２８およびオペレータ・データ・サービス１２６から転送することができる。

本実施形態のオペレータ・ビジネス・アプリケーション・サービス１２８は、オペレータの保守管理システム、飛行スケジュール、航空機構成、ならびにスペア部品の在庫可用性を含む。オペレータ・データ・サービスは、ビジネス、運用、および保守に対する一般的な運用プラクティスおよびポリシを含むがこれらに限られない。

システム１０２に戻ると、データ・アプリケーション・サービス・コンポーネント１３０は、とりわけ、保守計画最適化、最小機器リスト（ＭＥＬ）情報（後述）、特定のイベントに関連付けられた延期されたリスクおよび遅延されたリスクの両方、ならびに航空機技術データを提供するサブシステムである。

最適化ツール１３２は、全ての利用可能なソースからのデータを同期して、特定のイベントを解決するための１つまたは複数の推奨された一連の行動を提供する。プリプロセッサ１３４は、データを当該様々なソースから受信し、特定のデータタイプおよびそのソースに対して必要とされるデータ変換および正規化を提供する。管理サービス１３６は処理とリソーススケジューリングを監視し、最適化器１３８は、特定の状況またはイベントに適用可能なルールを用いて、当該１つまたは複数の一連の行動を製造業者データ、オペレータ（例えば、航空会社）データ、および天気情報のような他のデータから生成する。１実施形態では、当該ルールが予め決定され、複数のルールまたはルール集合から選択される。別の実施形態では、ルール集合内の独立なルールが、以下でより詳細に説明されるように、当該特定の状況またはイベントに従ってカスタマイズされてもよい。当該ルールの実行は、大抵の場合、当該問題を修正するための一連のアクションをもたらす。当該一連の動作の結果を提供するための１実施形態が図４で示され、以下で説明される。

示した実施形態において、システム１０２はまた、データ・サービス・バス１２０を介して接続された幾つかの例示的なサポート・サービスを含む。データ・サービス１４０は、記憶およびバックアップならびにアーカイブプロセスへのアクセスを含む。補助インタフェース１４１は、気象庁または商用データ・サービスのような標準データ・サービスに接続する。かかるデータ・サービスへのかかる接続は一般に公開され良く文書化されているので、サービス・ブリッジ１２２のライブラリが統合の簡単さのため必要とされなくてもよい。しかし、幾つかの実施形態において、補助インタフェース１４１により提供された能力をサービス・ブリッジ１２２に組み込んでもよい。

認証およびセキュリティデバイスまたはサービス１４２は、サービス・ブリッジ１２２を介してアクセスされる内部コンポーネントならびに外部サービスの間のログイン制御および単方向および相互認証を提供する。認証およびセキュリティ・サービス１４２はまた、１実施形態では、望まれるときまたは必要なときにファイルおよび／または通信暗号化を提供する。全体として、当該アーキテクチャおよびインタフェースは、１実施形態ではＤＡＰとして知られる、デジタル航空プラットフォームの一部である。図３は、イベントを処理するための例示的なデータ・フロー１６０を示す。最適化ツール１３２の管理サービス１３６は、必要なデータが受信されたときに、要求を送信し、データの収集およびスケジュール処理を管理する。プリプロセッサ１３４は、派生情報、例えば、タイム・ゾーン変換または部品サプライヤ採番システムの間の変換を生成するためにデータを再フォーマットまたは使用する必要があるときに、使用される。最適化器１３８により最終的に使用されるデータは２つのプライマリソースおよび幾つかのセカンダリソースからくる。第１のプライマリソースは製造業者データ１６１を提供する製造業者１０６である。または、代替的な実施形態では、製造業者データ１６１が、製造業者データ１６１をカタログ化するサードパーティデータプロバイダにより提供されてもよい。

製造業者データ１６１は、様々な実施形態では、以下の一部または全部を提供する。
・障害隔離マニュアル（ＦＩＭ）−ＦＩＭは、障害または他のイベントコードのソースを決定するためのステップ・バイ・ステップのプロセスを提供する。当該障害隔離ステップの各々を実施するために必要な時間が当該ＦＩＭに関連付けられる。幾つかの場合、航空機の一部の特定の量の分解が、障害隔離プロセスにおける幾つかのステップを実施するために必要とされるかもしれない。この影響は、幾つかのステップが、他のステップより多くの時間を必要としうるといものである。
・保守マニュアル−保守マニュアルは、航空機に必要な定期保守と、特定のコンポーネントにアクセスしかつ／または当該コンポーネントを置き換えるかまたは油圧システムのチェックのような定期保守タスクを実施するのに必要なまた分解および再組立てとの両方を分類する。全部ではないとしても幾つかの保守マニュアルはまた、特定の保守ステップを実施するのに必要な期待される時間を含んでもよい。
・最小機器リスト（ＭＥＬ）−特定のイベントが航空機の着陸を必要とするかどうかを判定するためにディスパッチャにより使用されるリファレンスである。ＭＥＬは、特定の工程および航空機のモデルに固有であり、使用不可であり適切な条件および制限による安全性の受理可能なレベルを維持していないかもしれない、耐空性および動作規制に関連する機器を指定する。
・航空機健康管理（ＡＨＭ）−航空機保守管理最適化である。ＡＨＭは、リアルタイムな航空機データを使用して、スケジュール割込みを減らし、障害隔離を改善し、保守効率を高めるための改善された障害転送トラブルシューティング、および履歴修理情報を提供するサービスである。
・天気警告−天気サービス・レポートおよび条件に加えて、様々な位置に対する天気情報を製造業者により報告してもよい。
・航空機技術データ−航空機に対する動作的および機械的な仕様および許容値に関する情報である。高レベルな航空機のカスタマイズのため、幾つかの仕様を個々の航空機に対して詳細化してもよい。例えば、座席構成およびエンジン変形のため、重みおよびバランスに関する仕様が航空機ごとに変化してもよい。
・遅延された保守動作リスク評価（ＤＭＯＲＡ）−「遅延されたリスク」としても知られ、個々の航空機ならびに航空機隊の動作的容易性に対するイベントの影響の評価である。これは、保守の遅延に関連付けられたリスクレベルを定量化する。
・遅延リスク−これは、特定のシステム障害が飛行スケジュールに対して有するかもしれない相対的なリスクを示す。特定の航空機システムが飛行スケジュール遅延をもたらす可能性を評価し、その割込み可能性を、履歴イベント平均飛行スケジュール遅延長の大きさと相関付ける。
・改修効果情報−改修効果は、修理プロセスの過去に履歴に基づき、保守記録のテキスト分析を使用して、どの修理動作が故障を直したのかを判定する。改修効果情報の適用を以下でさらに説明する。

保守の状況に関する判定を行う際に使用される情報の第２のプライマリソースはオペレータ・データ１６２である。即ち、航空会社のような航空機のオペレータからのデータである。様々な実施形態において、オペレータ・データ１６２は限定ではなく以下を含む。

保守管理システム−オペレータ群の航空機に対する保守関連活動をスケジューリングし、追跡し、記録するためのオペレータのシステムである。
・飛行スケジュール−考慮されている航空機の飛行スケジュールである。航空機に対する経路、到着時刻および地上時間が、保守活動がいつどこでスケジュールされるかを判定する際に最適化器１３８により使用される。
・航空機構成−考慮されている航空機の特定の構成であり、寿命、最後のサービスからの時間、座席構成、エンジンタイプ、油圧システム、およびウィングレットタイプを含むがこれらに限られない。
・位置能力−特定のレベルのサービスを実施するための特定の位置の能力であり、ハンガー容量、ツールおよび検査機器の可用性、および技術者サービス認証を含むがこれらに限られない。
・部品在庫−考慮されている航空機に対するイベントに対応する位置で利用可能な部品である。あらゆる部品が常にあらゆる位置にあるのが理想的である。しかし、識別された部品が必要であるが所望の位置にないとき、この必要性を解決するための幾つかの方法がある。第１に、航空機を、当該部品がある場所に、特に当該部品が航空機の飛行スケジュール上の位置にある場合に、移動することができる。第２に、オペレータは当該部品を、当該オペレータのスケジュールされた飛行のうち１つの上にある修理場所に移動することができる。第３に、当該部品を、ＵＰＳまたはフェデラル・エクスプレスのような標準配送サービスの１つにより移動することができる。別の方法に対する或る方法の望ましい状況は、当該部品のサイズまたは重さ、当該部品を配送するのに必要な時間、飛行スケジュール、天気等に依存する。部品の可用性は、以下でより詳細に説明する他の因子とともに、ルール集合を実行する際にシステム１０２により扱われる。

・一般プラクティス・マニュアル−優先順位付けガイドライン、好ましい保守位置等のような項目を含みうる、特定のオペレータに対する標準動作手続きのマニュアルである。
・マスタ最小機器リスト−製造業者の最小機器リスト（ＭＥＬ）のスーパーセットおよびオペレータの追加の安全性レベルおよび航空機を操作するのに必要な快適性を含む、リファレンスである。
・ポリシ、運用、ビジネスおよび保守情報−特定のオペレータに対する期待されるコスト、報告手続き等による人員、承認レベルに関する追加の関連情報である。

最適化器１３８により使用される情報の追加のソースを図３に補助データ１６４として示す。補助データが、連邦航空局（ＦＡＡ）およびアメリカ海洋大気庁（ＮＯＡＡ）からの天気情報を含んでもよい。天気情報は多数の目的のために当該最適化器により使用される。１例では、当該天気情報を使用して、航空機が可能な保守目的地に到達できるかどうかを、その飛行経路上でまたはスケジュールされていない目的地として、予測してもよい。別の例では、天気情報を使用して、期待される余分な地上時間が与えられれば、保守活動を実行できる位置で航空機を遅延されるかどうかを判定してもよい。保守をハンガー内部で実施する必要がありうるかどうかの指標として天気を使用し、修理を行うことから、特定の空港の能力に影響を与えることができる。例えば、強風条件は、屋外の上昇したプラットフォーム上で機械工が作業するのを不可能とする可能性があり、当該修理が外部パネルの除去を必要とする場合、雨から生ずる航空機構造内部への水浸のため、作業を屋外で実施するのは勧められないかもしれない。

関連データの一部または全部が最適化ツール１３２で受信されるとき、再フォーマット、計算または正規化が必要な任意のデータがプリプロセッサ１３４で処理される。プリプロセッサ１３４はまた、ルールカスタマイズを管理してもよい。これを以下でより詳細に説明する。

管理サービス１３６は、要求のスケジューリングとジョブの処理を監督する。最適化器１３８は、当該ルールを使用して修理計画を開発し、当該ルールの目的（重み付け）に基づいてそれらの有効性に従ってそれらを提供する。

当該修理計画を、追加の自動化システムまたはディスパッチャベースのシステムの何れかにより使用して、保守活動に関する改善されたターンアラウンド時間を実現し、修理施設の間で移動しなければならない部品数を削減することで部品コストを下げる、動的なライン保守を提供してもよい。

改修効果／ＳＡＶ評価
次に、上述の改修効果を議論する。改修効果情報は、どの部品が欠陥の根源であったかを判定するために、テキスト分析器で過去の保守活動レポートをレビューすることで開発される。より具体的には、統計値が、１実施形態では、当該問題が１０日間再現しない結果となった報告された修理に関して保持される。例えば、フィルタ１をその時間の２０％置き換え、フィルタ２をその時間の５％置き換えることによって、システムのリセットがその時間の７５％実施された後、或る特定の空気圧システムコードが１０日間の（またはそれより長い）修理をもたらす。フィルタ１を置き換えることに関する改修効果は、フィルタ２を置き換えることの改修効果より高く、そのため、この場合、おおまかにその時間の９５％で、フィルタ２が置き換えられる前に障害が２回以下の修理動作で修理されることを想定することができる。別の例では、コンプレッサを置き換える第４のＦＩＭステップが、障害をその時間の７５％でクリアすることができる。かかるステップを障害隔離プロセスの先頭に移動するのが論理的であるかもしれないが、当該ステップの位置を移動させる他の検討事項があってもよい。かかるケースでは、当該第４のステップは、修理するのに高価でありかつ時間を浪費するコンポーネントを含むかもしれず、したがって、当該プロセスの前の方においてより簡単でよりコストのかからない障害隔離ステップを、あまり効果的でないかもしれないが、実施する価値がある。

全体として、改修効果情報を開発することの価値は、それが、統計的に正確に修理時間を予測するための方法を提供することである。個々のケースは変動しうるが、機隊規模で考えたとき、当該修理時間とコストを、予測し、保守人員、地上施設、および航空機のダウン時間をスケジュールするために使用できる。

当該改修効果を、３つの統計値、即ち、単純性値、曖昧性値、および変動性値（ＳＡＶ）により取得してもよい。当該ＳＡＶ評価を決定するためのデータは、解決された問題レポートのテキスト・ログの分析に基づく。当該レポートは一般に、修理技術者が作成したフリーフォームのテキスト・エントリである。計算の例がそれぞれの簡単な説明に続く。

単純性とは、どれだけ良くＦＩＭが特定のコードまたはイベントに対して理解されるかを示す測定値である。単純性の値は三進値（−１、０、＋１）である。＋１は、サービス・レポートの５０％より多くが「再検査／チェックＯＫ」の修理でコードされているときに割り当てられる。０は、エラー・レポートの５０％未満が１つの例外で「チェックＯＫ」としてコードされているときに割り当てられる。当該例外は、エラー・レポートの５０％より多くが「その他」または「未知」としてコードされるときに−１が割り当てられることである。「コードされる」という用語が使用されているが、実際には、「コードされる」が単純に、エラー・レポートが「チェックＯＫ」、「その他」、または「未知」という平文を含むことを意味してもよい。

曖昧性値は、欠陥を修理するのに平均的に必要なＦＩＭ内の総ステップの割合の測定値である。当該値は、最大改修効果割合を、当該ＦＩＭ内の他の可能なステップの数と比較する式で取得される。１実施形態では、以下の式を使用して曖昧性値を計算する。
（最大改修効果％+ (100 / (1+ ((# of FIM steps-1) / 10)))) / 2

変動性値は、特定の割合改修効果に到達するのに必要なステップの数の測定値である。１実施形態では、所望の改修効果は９０％の予め選択された信頼度レベルに設定される。即ち、どれだけ多くのＦＩＭのステップが９０％の累積改修効果に到達するために必要であるかである。ベスト・ケース（BC）値は、所与の改修効果に到達するのに必要な、先頭からカウントしたステップの数として計算される。最悪ケース（WC）値は、当該所与の改修効果に到達するのに必要な、当該ＦＩＭの最後のステップからカウントしたステップの数である。当該変動性値は次の式により与えられる。
((BC + WC) / 2) - 1

単純性値を決定するステップは、１組の保守レポートが与えられれば分かりやすいものであるが、曖昧性および変動性の計算を示す幾つかの例が続く。

例１：１００％の有効性：｛１００％｝を有する１ステップＦＩＭ
曖昧性= (100 + (100 / (1 + (0 /10)))) / 2 = (100 + 100) / 2 = 100、絶対確実性
変動性= ((1 + 1) / 2) - 1 = 2/2 - 1 = 0、ゼロ変動性

例２：値：｛９０％、１０％｝を有する２ステップＦＩＭ
曖昧性=(90+(100/(1+(1/10))))/2=(90+91)/2=90.5、高確実性
変動性=((1+2)/2)-1=3/2-1=0.5、微妙な変動性

例３：値：｛５０％、３０％、１５％、５％｝を有する４ステップＦＩＭ
曖昧性=(50+(100/(1+(3/10))))/2=(50+77)/2=63.5、中程度の確実性
変動性=((3+4)/2)-1=7/2-1=6 増大する変動性（ＢＣは、９０％の確実性に到達するために左から３つのステップを必要する。ＷＣは、９０％の確実性に到達するために右から４つのステップを必要とし、この場合は１００％の確実性でもある。）

例４：各ステップが１％の改修効果：｛１％、１％、１％、・・・｝をもつ、１００ステップＦＩＭ
曖昧性=(1+(100/(1+(99/10))))/2=(1+9.2)/2=5、低い確実性
変動性=((90+90)/2)-1=180/2-1=89、高い変動性（ＢＣとＷＣは同一である。なぜならば、先頭から９０ステップと終端から９０ステップの両方で９０％の信頼度に到達するからである。）

明らかに、当該例のうち幾つかは、例示の目的のために極端なものであるが、分かるように、ＦＩＭ内のステップが増えれば、一般に、曖昧性および変動性の値の両方が増大する。同様に、全体的に低い有効性を有するステップはまた、曖昧性値と変動性値を増大させる。当該方程式は経験的に導出され、保守レポートをデータマイニングすることで容易に取得される変数を使用するために選択されている。当該方程式はまた、より少数のＦＩＭステップのより貴重な特性と、当該プロセスの先頭付近のより良い解像度との間の顕著な距離を生成するために選択されている。このため、これらの方程式は例にすぎず、本明細書で開示された概念および原理により導かれるとき、他の適切な方程式を、大幅な工数がありうるにもかかわらず、開発し置換することができる。

図６および７に関して後述するように、ＳＡＶ（単純性、曖昧性、変動性）に対する計算された値は単に、保守計画をもたらす最適化プロセスを実施するためのルールエンジンへの別の組の入力である。他の実施形態では、当該ＳＡＶ値をシステム１０２と独立に使用することができる。

図４は、最適化ツール１３２により生成された結果の例示的な表示のスクリーン・ショット１９０を示す。カレンダ部分１９１は、３つの段階を含む作業順序に対する代替物を示す。プラン１のサマリ線１９２はプラン１がルール集合に９３％準拠することを示し、ステップ１および２が午前５：３０と午前６：３０の間にシアトルで実行されることを示す。航空機は次いでデンバーに飛行し、そこで残りのステップ３が午前９：００の後すぐに開始される。プラン２のサマリ線１９４は、プラン２がルール集合に８９％準拠することを示す。プラン２では、ステップ１および２はまたシアトルで完了しているが、ステップ３はおよそ午後１：１５にセント・ルイスで完了する。

詳細セクション１９６は、この例示的な実施形態において、最高評価プランに対する詳細を示す。当該最高評価プランはしたがってデフォルトのプラン１である。時間、位置、説明、期間、および部品のカラムは一目瞭然であり、もしあれば修理ごとの期待される時間と必要な部品が示される。「選択」ボタン１９８により、ディスパッチャ１１４はプラン１を起動でき、これは、シアトルとデンバーにおいて作業命令を発行させ、必用な技術者と部品をその作業に割り当てる。「変更」ボタン１９９は、別のウィンドウ内で、プラン２の選択、別の低い評価の計画の選択、またはルールを変更して保守サービスに対する他の基準を最適化することを可能とする。

図５は、システム１０２をセットアップし管理するための管理ツール２００の１実施形態を示す。ブロック２０２で、判定に必要な情報が決定され、対応して、当該情報のソースが決定される。図５に示すように、情報ソース２０４、一般にオペレータ、は飛行スケジュールのような上述の情報を含む。情報ソース２０６、一般に製造業者、は図２に関して上述した情報要素を提供し、障害隔離マニュアル（ＦＩＭ）およびリスク評価を含む。補助データ２０７は、追加の第３のパーティを介して受信された天気情報または他のデータを含んでもよい。

ブロック２０８で、識別されたデータソースへのインタフェースが開発され実装される。これらのインタフェースをサービス・ブリッジ１２２で具体化してもよい（図２）。１実施形態では、インタフェースのライブラリを使用して、様々なデータベースベンダと通信プロトコルのためのライブラリを含む独立なインタフェースの開発を促進してもよい。

クライアント、例えば、特定の航空会社ごとに、特定のルールはポリシ、ルール重み付けを変更し、スコア付けがブロック２１０で開発される。ルールの重み付けとスコア付けは当該特定のキャリアの機能である。主に（または排他的に）国際的に飛行するキャリアは、外国に配送された修理部品に関する高配送コストと潜在的な税関問題とに晒されるのを制限するために、それらのメイン・ハブへ戻ることに対してより高い価値を与えるかもしれない。カナダを基盤とする航空会社のようなより厳しい天候で運行するキャリアが、メキシコを基盤とする航空会社のようなよりマイルドな天候で主に運行するキャリアよりも、計画の際に天気により重みをおいてもよい。

ルール変更ポリシは、どのルールを修正できるかおよび／またはどのような制限をそれらの重み付けに付与できるかに対する制限を設定する。幾つかのキャリアは、システム１０２が修理を推奨するためのより多くのまたは異なるオプションを開発するように、ルール変更に関するより多くの裁量をもつためにシステム１０２と対話するディスパッチャまたはその他を必要とするかもしれない。動的なルール変更を以下でより詳細に説明する。

ルールエンジンがブロック２１２で構築される。１実施形態では、当該ルールエンジンは商用在庫（ＣＯＴＳ）製品であるが、他の実施形態では、当該ルールエンジンを内部で開発するかまたは在庫製品から修正してもよい。当該ルールエンジンが構成されテストされた後、システム１０２がブロック２１４でユーザにリリースされてもよい。当該ユーザは一般に、航空会社または配送会社のような他の航空運送業者である。他の実施形態では、当該ユーザが、航空機隊を管理するチャーター航空機隊または連邦機関であってもよい。

図６および図７は、航空機保守スケジューリングに使用されるシステム１０２を動作させる際に実施されるステップを有するプロセス２３０を示す流れ図である。ブロック２３２で、障害またはエラー・レポートに関する警告が、航空機１０４に関するシステム１０２で受信される。当該イベント、欠陥、またはエラー・レポートが、航空機データシステムから直接受信されてもよく、飛行人員または地上保守人員または他のソースから受信されたレポートから受信されてもよい。当該イベント、欠陥、またはエラー・レポートはまた、来たる定期保守要件のログを保持する航空機保守スケジューリングシステムにより生成されてもよい。ブロック２３４からの情報を含む、当該障害に関するデータがブロック２３６で収集される。１実施形態では、当該データは航空機タイプ、フライト・デッキ・エフェクト、保守メッセージおよび関連付けられた最小機器リスト（ＭＥＬ）である。フライト・デッキ・エフェクトは、必ずしもシステム内のどのコンポーネントが故障したかではなく、現在の条件への応答を搭乗員が判定するのを支援する、搭乗員に表示されるメッセージである。ＭＥＬは、航空機の特定の外観とモデルに固有であり、操作を禁止しない使用不可でありうる機器を指定する。

ブロック２３８で、当該障害が遅延可能かどうかの判定を行う。おそらく明らかに、当該判定が「いいえ」である場合、即ち、当該障害が遅延可能でない場合は、実行がブロック２４４で継続され、航空機は着陸し、修理を開始する作業命令が生成される。ブロック２３８で当該障害が遅延可能であるとき、実行がブロック２４０で継続し、航空機に対する既存の保守順序があるかどうかを判定するためのチェックを行う。そうである場合、実行はブロック２４２で継続し、この追加の欠陥が、直近に識別された障害と組み合せて、当該障害がもはや遅延可能でないとの状況を生成するかどうかを判定する。例えば、当該新たな欠陥は、航空機の機能的システムを許容可能なＭＥＬ要件未満に低下させるかもしれない。これが発生したとき、実行はブロック２４４で継続し、以前のように、航空機を着陸させ、作業命令が生成される。

ブロック２４０に戻ると、他の係属中の保守条件がないとき、実行はブロック２４６で継続する。これはまた、ブロック２４２で当該追加の保守条件が航空機地上滞留（ＡＯＧ）条件を生成しない場合に当てはまる。

システム１０２は、ブロック２４６で、ブロック２３６で収集された障害条件情報以外のデータを収集する。上述のように、図３に関して、ブロック２４６で収集されたデータは一般に、ＦＩＭのような機器関連のデータ２４８、および飛行スケジュール、部品可用性、および天気を含む環境関連のデータ２５０を含む。また上述のように、とりわけデータ２４８およびデータ２５０からの情報を用いて、ＳＡＶデータ２５２が計算され、ブロック２４６で収集されたデータに含まれる。

最適化ツール１３２がブロック２５６で起動される。最適化ツール１３２は、航空機１０４が経験した条件または障害を解決するための少なくとも１つの一連の行動を生成することを試みる。幾つかの場合、ルール集合の要件全てを満たす一連の行動が見つからないかもしれない。他のケースでは、１つまたは複数の一連の行動が開発され、利用可能とされる。

図７の「１」マーカで続けると、当該流れ図はブロック２６０で継続し、当該ルールの最小要件を満たす計画があるかどうかが判定される。そうである場合、実行がブロック２６２で継続し、１つまたは複数の一連の行動が表示される。当該結果の表示の１例は図４で示されており、上述されている。最上位のプランが受け入れ可能である場合、当該プランをブロック２６４で承認してもよく、「はい」の分岐がブロック２６６に続き、作業命令が生成され、航空機１０４の修理が当該計画に従って実施される。当該計画の実行は、航空機１０４、部品、またはその両方を当該計画で示された位置に移動に移動するように要求してもよい。

ブロック２６４で最高評価プランが選択されない場合、実行はブロック２６４からブロック２６８への「いいえ」分岐を辿ってもよく、そこで別のプランがブロック２６６へのオプション（１）に続いて選択されてもよい。代替的に、ブロック２６８で、全ての提案された計画が拒絶されてもよく、当該計画の何れかに対する手動更新をブロック２７２へのオプション（２）を辿ることで行ってもよい。

ブロック２６８で利用可能な第３のオプションは、図６のブロック２５４に戻り特定のイベントまたは考慮されている障害に対するルールをユーザが更新できるようにするオプション（３）である。当該ルールの変更が完了すると、ブロック２５６で最適化ツール１３２のよる実行が実施される。注目すべきことに、ブロック２５４で行われたルール変更は当該ルールに対する一時的な変更であり、現在検討中の障害またはイベントに関して航空機１０４にのみ適用される。一般的なルール集合は無傷のままであり、プロセス２３０の別の並列な利用で未修正のルールを使用する。

ブロック２６０に簡単に戻ると、実行可能な計画が最適化ツール１３２により生成されない場合、実行は、「いいえ」分岐をブロック２７４に辿ってもよく、そこで、自動的に生成されたオプションの欠如をオペレータに警告してもよい。実行はブロック２６８で継続してもよく、そこでオプション２および３のみが表示される（オプション１は別の計画の選択に関連付けられており、この場合は存在しない）。

図８は、ルールを修正するための図６のブロック２５４で使用するのに適した１つの可能なユーザ・インタフェース３００を示す図である。ルール集合３０２が複数の独立なルール３０３乃至３１０とともに示されている。本例示的な実施形態では、各ルールは、コンピュータプログラミング言語ではなく、平文で提供され、個々のルールを、チェックボックスを用いて選択または選択解除してもよい。選択解除されたルールを、アクティブなルールを容易に識別できるようにするためにグレーアウトしてもよい。ルール３０３および３０４とともに示したもののような幾つかのルールが、ユーザ設定可能な値を有してもよく、この場合は当該値それぞれ、障害隔離および修理作業のための何分かのターン時間である。各ルールにはソフトまたはハード実行のための値が与えられる。ソフトルールは望ましいが必要でないと考えられ、換言すればプログラム的に「〜してもよい」である。ハードルールは必要と考えられ、または、プログラム的に「〜するものとする」である。示すように、「ハード」または「ソフト」はゼロの値で選択解除される。ルールの重みは、本実施形態で示すように−１から−３の範囲でその夫々の「ハード」または「ソフト」値を増大することで変更される。オペレータが選択的にルールをオフにするかまたはルール実行をハード（必要）からソフト（望ましい）に変更しそれらの重みを変更する能力は、最適化ツール１３２の有用性を大幅に拡大する能力である。ルール集合に対するかかるリアルタイムかつ非永続的な変更は、特殊な状況に適応し、一事例ではオペレータに利用可能であるがデータ２４８および２５０内で容易に更新できない情報を適用するための裁量をオペレータに与える。例えば、オペレータは、データ２５０（図６）で取得されていない天気情報に反映されていないまさに現在の天気情報を有することができ、その結果、オペレータは、修理場所および時間に対する代替物を増加させるために天気関連のルールをオフにすることができる。具体的には、ルール変更に対する他の理由の例が期待され、これは、現在のニュースイベント、オペレータの個人的な経験、人員スケジュール等を含むがこれらに限られない。

ルールに加えられる変更を手動または自動で記録しレビューできることが期待され、その結果、時間とともに、基本ルールを、定期的にまたは選択された状況で出現する変化を反映するように更新することができる。この方式では、当該基本ルールはより洗練されたものになり、システム１０２全体は自己学習的になる。

図８に示すように、幾つかのルールは、複数のタスクが必要とされるときに、それらが順番に完了されるべきであることを述べるルール３０９のようなタスク自体に関連する。必要とされるＦＩＭ内の部品番号が部品データベースに既知でないことを記述するルール３０５のような幾つかのルールは、部品の可用性に関連する。これは、当該ＦＩＭが特定の部品番号を要求しうるが、例えば別のベンダからの異なる番号を有する均等な部品を使用してもよいことを意味する。修理工場の認証のレベルを規定するルール３１０のような幾つかのルールは、サービスが実施される工場に関連する。他のルールが天気予報に対する感度を規定してもよく、他のルールがＳＡＶ値に対する感度を設定することができる。

上述のように、ルールをオンまたはオフにしてもよく、または、システムが構成された（ブロック２１０、図５）ときに規定されるポリシ説明の制限内で変更されるそれらの「ハード」または「ソフト」値を有してもよい。このように、航空会社は、どの程度の裁量でシステム１０２のオペレータがルールをカスタマイズできるかについて制限を設けることができる。１実施形態では、ポリシ自体をルールの形で指定して、適切な権限を有する人により、複数州にまたがるブリザードまたはハリケーンのような特定の状況に対して当該ポリシを修正できるようにしてもよい。

図９は、図２で示したサービス・アーキテクチャ・ビューと対照をなすシステム１０２の機能的ビューを示す。システム１０２は、データバス３４６を介してメモリ３４２およびディスプレイ３４４に接続されたプロセッサ３４０を備える。データバス３４６はまたプロセッサ３４０を幾つかのインタフェースに接続し、フィールド・インタフェース３４８、ベンダ・インタフェース３５０、補助インタフェース１４１、サービス・ブリッジ１２２、およびユーザ・インタフェース３５４を含むがこれらに限られない。

フィールド・インタフェース３４８は、様々な報告エンティティに接続され、特定の航空機１０４に関する問題レポートを電子非準拠リポジトリ３４９から受信するために使用される。１実施形態では、非準拠リポジトリ３４９は、ＡＣＡＲＳのような自動化された報告システムであるが、様々な搭乗員および地上員報告システムを備えてもよい。図６に示すように、問題レポートの受信はシステム１０２を起動するための初期トリガである。ベンダ・インタフェース３５０は、航空機１０４に対する製造業者データを有するシステム１０２を、一般的なモデルと特定の機体登録番号（独立な航空機）との両方により接続する。かかる情報は、航空機に対するＦＩＭおよびＭＥＬを含むがこれらに限られない。１実施形態では、当該情報は航空機１０４の当該製造業者からのものであるが、他の実施形態では別のデータ集約器から利用可能であってもよい。

補助インタフェース１４１は、例えば、様々な位置に対する天気データを提供するサービスに接続するために使用される。特に、システム１０２は、航空機１０４の経路上の目的地に対する天気予報を使用して、可能な修理場所が所望の時間フレームでアクセス可能であるかどうかを判定する。上述のサービス・ブリッジ１２２は、航空会社または他のキャリアに接続して、システム１０２からの問合せに応答して、飛行経路、サービス位置、および部品在庫に関する情報を受信するために使用できる１組のライブラリを提供する。ユーザ・インタフェース３５４は、ディスプレイ３４４に関連して、情報をオペレータに提供し、命令を当該オペレータから受信するために使用される。図４に示すように１実施形態では、当該情報は１つまたは複数の一連の行動を含む。当該命令は、図８に関して上述したように、ルールを有効化または無効化することならびに当該ルールの重みを変更することを含めて、ルールに対する変更を含んでもよい。

上述のサービス・ブリッジ１２２は、他の項目のうち、航空機１０４のポリシ情報、部品在庫、および経路情報を含む航空会社またはキャリアのデータベースにシステム１０２を接続する。

メモリ３４２は物理メモリであり、搬送波または伝送媒体を含まない。メモリ３４２は、様々な実施形態では、オペレーティング・システム３５６およびユーティリティ３５８を含む。オペレーティング・システム３５６およびユーティリティ３５８は、システム１０２の動作全体を管理するために使用され、セットアップと診断のために使用される。ルール３６０は、図８に関して上述した独立なルール３０３乃至３１０を含んでもよい。これらのルール３６０がルール集合３０２内にあってもよい。追加のルール集合（図示せず）を、システム１０２の異なるユーザ（例えば、異なるキャリア）で使用するために、または、同一のユーザによる異なる状況のために格納してもよい。メモリ３４２はまた、認証およびセキュリティ・サービス１４２により使用される暗号化サービス３６２を備えてもよい（図２）。他の実施形態では、暗号サービスが、スマートチップ（図示せず）のようなハードウェアユニットにより提供されてもよい。メモリ３４２はまた、上述の最適化ツール１３２を備えてもよい。最適化ツール１３２は、１実施形態では、プロセスルール３６０を処理するためにプロセッサ３４０上で実行されるルールエンジン３６６を備える。メモリ３４２はまた、ＳＡＶツール３６８を備えてもよい。上述のように、ＳＡＶツール３６８は、サービス・レポートから抽出した情報を収集し、１実施形態では、航空機１０４内の当該報告された問題を解決するための一連の行動を生成する際に当該ルールエンジンにより使用される３つの値を生成する。

複数のソースからデータを集約し、代替的な修理計画を生成し評価し、カスタマイズされたルール集合を用いてこれらの計画を高速に再評価する能力は、堅苦しく定義されデータへのアクセスが制限されている先行技術のシステムに対する大幅な改善である。さらに、可能な一連の行動の評価における単純性、曖昧性、および変動性（ＳＡＶ）の利用は、同一の問題レポートの分析および修理に関する履歴データの値を認識する。当該ＳＡＶ情報は、システム１０２またはマニュアルディスパッチャに、複雑性へのウィンドウを提供し、したがって課題を解決するのに必要である時間へのウィンドウを提供する。システム１０２は、手動で既に実施されたプロセスを自動化するだけでなく、システム１０２は、先行技術システムと比較して、追加のデータだけでなく構成可能なルールにもアクセスできるので、システム１０２は保守プラン生成の速度および精度の両方を高める。これは、航空機が空でより多くの時間を費やし地上でより少ない時間を費やすこととなり、航空輸送業界における根本的な原動力である。

さらに、本開示は以下の項に従う実施形態を含む。

項１．航空機内の非準拠条件を修理するためのリソースを割り当てるシステムであって、当該システムは、プロセッサと、非準拠条件に関するデータを受信し分配するサービス・バスに接続されたメモリと、当該サービス・バスに接続された最適化ツールと、ルール集合を用いて修理代替物を生成する最適化器とを備え、当該サービス・バスはさらに、航空機に対する遅延されたリスク・データおよび技術データを取り出すように構成され、サービス・アダプタはオペレータ・データを航空機のオペレータから受信するように構成され、当該オペレータ・データは経路計画および部品在庫を含み、当該最適化ツールは、当該サービス・バスを介して受信されたデータをフォーマットするプリプロセッサを備え、当該ルール集合は当該最適化ツールの動作の間に構成可能である、システム。

項２．当該サービス・アダプタを介した通信のためのデータ暗号化および認証サービスを提供する、当該サービス・バスに接続された認証およびセキュリティデバイスをさらに備える、項１に記載のシステム。

項３．当該ルール集合を生成し、当該オペレータと通信して当該オペレータ・データを受信するための当該サービス・アダプタを設定する管理ツールをさらに備える、項１または２に記載のシステム。

項４．当該ルール集合の変更を実装するための命令を受信するユーザ・インタフェースをさらに含み、当該変更は航空機内の非準拠条件に固有である、項１乃至３の何れか１項に記載のシステム。

項５．当該ユーザ・インタフェースは、独立なルールを当該ルール集合から停止するための命令を受信する、項４に記載のシステム。

項６．当該ユーザ・インタフェースは、当該ルール集合内の独立なルールのルール重みを変更するための命令を受信する、項４または５に記載のシステム。

項７．当該サービス・バスに接続された単純性、曖昧性、変動性（ＳＡＶ）ツールをさらに含み、当該ＳＡＶツールは、非準拠条件に対する履歴データを受信し、当該修理代替物を生成する際に当該最適化器により使用するためのＳＡＶ評価を提供する、項１乃至６の何れか１項に記載のシステム。

項８．当該ＳＡＶ評価は＋１、０、または−１の三進値を有する単純性値を含み、「問題なしとチェック」の非準拠条件に対する診断が閾値を超過したとき＋１が割り当てられ、「問題なしとチェック」の非準拠条件の診断が当該閾値を満たさないとき０が割り当てられ、幾つかの中間診断が第２の閾値を超過するとき−１が割り当てられる、項７に記載のシステム。

項９．当該ＳＡＶ評価は、修理ステップの平均数の、非準拠条件を解決するのに必要な修理ステップの全ての可能な数に対する割合の関数である曖昧性値を含む、項７または８に記載のシステム。

項１０．当該ＳＡＶ評価は、予め選択された信頼度レベルに対する非準拠条件を解決するための最良ケースステップ数と当該予め選択された信頼度レベルに対する非準拠条件を解決するための最悪ケースステップ数との組合せである変動性値を含む、項７乃至９の何れか１項に記載のシステム。

項１１．航空機内の非準拠条件に対する保守応答を決定する方法であって、メモリを有するプロセッサで、航空機内の非準拠条件を受信するステップと、当該プロセッサおよび当該メモリで、航空機に固有の非準拠条件に対応するさらなる障害のリスクを含む障害および保守情報を受信するステップと、航空機のオペレータから、当該プロセッサおよび当該メモリで、航空機の飛行スケジュール、１つまたは複数の修理場所、および非準拠条件に関連する部品在庫を受信するステップと、非準拠条件に対する修理履歴記録を非準拠条件に対する修理プロセスと比較することによって、非準拠条件に対する単純性、曖昧性、変動性（ＳＡＶ）評価を生成するステップであって、当該ＳＡＶ評価は非準拠条件を解決するための単純性値、曖昧性値、および変動性値を含む、ステップと、当該プロセッサで実行される当該メモリに格納されたルール集合を用いて、非準拠条件に対する障害および保守情報、さらなる障害のリスク、航空機の飛行スケジュール、１つまたは複数の修理場所およびＳＡＶ評価を評価して、航空機に非準拠条件を解決させるための位置および時間を生成する、ステップとを含む方法。

項１２．当該プロセッサで実行される当該メモリに格納されたルール集合を使用するステップは、使用前に、当該ルール集合の１つまたは複数のルールを選択的に停止することによって修正される当該メモリに格納されたルールを使用するステップを含む、項１１に記載の方法。

項１３．当該プロセッサで実行される当該メモリに格納された当該ルール集合を使用するステップは、使用前に、当該ルール集合の１つまたは複数のルールを選択的に再重み付けすることにより修正される当該メモリに格納されたルールを使用するステップを含む、項１１または１２に記載の方法。

項１４．当該ＳＡＶ評価の変動性値は、((BC + WC) / 2) - 1として計算され、BCは、予め選択された信頼度レベルに対する非準拠条件を解決するのに必要な最良ケースのステップ数であり、WCは、当該予め選択された信頼度レベルに対する非準拠条件を解決するのに必要な最悪ケースのステップ数である、項１１乃至１３の何れか１項に記載の方法。

項１５．当該ＳＡＶ評価の曖昧性値は、(HFE % + (100 / (1 + (# of other steps / 10)))) / 2として計算され、HFEはパーセントでの最大改修効果であり、「# of other steps」は１より小さい解決プロセスにおけるステップの総数である、項１１乃至１４の何れか１項に記載の方法。

項１６．メモリを有するプロセッサであって、当該メモリは、エラー・レポートを当該プロセッサと通信する電子非準拠リポジトリから受信し、当該エラー・レポートは航空機内の非準拠条件に関する情報を含む、プロセッサと、当該メモリを有する当該プロセッサに接続され、航空機のオペレータから、航空機の飛行スケジュール、１つまたは複数の修理場所およびそれらの夫々の修理能力、および当該１つまたは複数の修理場所の各々に対する部品在庫から受信するように構成された、サービス・ブリッジとを備えた、航空機保守スケジューリングに関するシステムであって、当該メモリに格納されたルール集合は、非準拠条件、当該飛行スケジュール、当該１つまたは複数の修理場所およびそれらの夫々の修理能力、および当該部品在庫を処理するための複数の独立なルールを含み、当該プロセッサはｉ）非準拠条件の補正を延期できるかどうかを判定し、延期可能であるとき、ｉｉ）当該飛行スケジュール上の位置を選択し、非準拠を補正するための位置で部品と人員をスケジュールするための当該ルール集合を実行するように構成される、システム。

項１７．当該ルール集合内の当該複数の独立なルールの１つまたは複数を起動および停止するための命令を受信して当該プロセッサによる実行のための改良されたルール集合を生成するユーザ・インタフェースをさらに含む、項１６に記載のシステム。

項１８．当該ルール集合内の独立なルールを再重み付けして、当該プロセッサによる実行のための改良されたルール集合を生成するための命令を受信するユーザ・インタフェースをさらに含む、項１６または１７に記載のシステム。

項１９．非準拠条件を補正するための当該選択された位置を拒絶するための命令を受信するユーザ・インタフェースをさらに備え、当該プロセッサは非準拠条件を補正するための別の位置を生成する、項１６乃至１８の何れか１項に記載のシステム。

項２０．前記サービス・ブリッジを介してアクセス可能な既存のデータソースへのインタフェースを構築するための所定のプロトコルを有する統合アダプタをさらに備える、項１６乃至１９の何れか１項に記載のシステム。

特定の実施形態のみを説明したが、代替的なおよび修正は上の説明から当業者には明らかであろう。特に、様々な実施形態の態様を互いと結合するかまたは互いで置き換えることができる。これらのおよび他の代替物は、均等物であると考えられ、本開示の趣旨および範囲および添付の特許請求の範囲内にある。

１２０ データ・サービス・バス
１２２ サービス・ブリッジ／統合アダプタ
１２４ オペレータ・サービス・バス
１２６ オペレータ・データ・サービス
１２８ オペレータ・ビジネス・アプリケーション・サービス
１３０ データ・アプリケーション・サービス
１３２ 最適化ツール
１３４ プリプロセッサ
１３６ 管理サービス
１３８ プラン最適化器
１４０ データ・サービス
１４１ 補助インタフェース（天気サービス等）
１４２ 認証セキュリティ・サービス
１４４ 他のサービス

Claims (10)

1. 航空機（１０４）内の非準拠条件に対する保守応答を決定する方法であって、
   メモリ（３４２）を有するプロセッサ（３４０）で、前記航空機内の前記非準拠条件を受信するステップと、
   前記プロセッサおよび前記メモリで、前記航空機に固有の前記非準拠条件に対応するさらなる障害のリスクを含む障害および保守情報を受信するステップと、
   前記航空機のオペレータ（１０８）から、前記プロセッサおよび前記メモリで、前記非準拠条件に関連する前記航空機の飛行スケジュール、１つまたは複数の修理場所、および部品在庫を受信するステップと、
   前記非準拠条件に対する修理履歴記録を前記非準拠条件に対する修理プロセスと比較することによって、前記非準拠条件に対する単純性、曖昧性、変動性（ＳＡＶ）評価を生成するステップであって、前記ＳＡＶ評価は前記非準拠条件を解決するための単純性値、曖昧性値、および変動性値を含む、ステップと、
   前記プロセッサで実行される前記メモリに格納されたルール集合（３０２、３６０）を用いて、前記非準拠条件に対する前記障害および保守情報、さらなる障害の前記リスク、前記航空機の前記飛行スケジュール、前記１つまたは複数の修理場所および前記ＳＡＶ評価を評価して、前記航空機に前記非準拠条件を解決させるための位置および時間を生成するステップと、
   を含む、方法。
2. 前記プロセッサ（３４０）で実行される前記メモリ（３４２）に格納された前記ルール集合（３０２、３６０）を使用するステップは、使用前に、前記ルール集合の１つまたは複数のルールを選択的に停止することによって修正される前記メモリに格納されたルール（３０３−３１０）を使用するステップを含む、請求項１に記載の方法。
3. 前記プロセッサ（３４０）で実行される前記メモリ（３４２）に格納された前記ルール集合（３０２、３６０）を使用するステップは、使用前に、前記ルール集合の１つまたは複数のルールを選択的に再重み付けすることにより修正される前記メモリに格納されたルール（３０３−３１０）を使用するステップを含む、請求項１または２に記載の方法。
4. 前記SAV評価の前記変動性値は((BC + WC) / 2) - 1として計算され、BCは、予め選択された信頼度レベルに対する前記非準拠条件を解決するのに必要なステップの最良ケース数であり、WCは、前記予め選択された信頼度レベルに対する前記非準拠条件を解決するのに必要なステップの最悪ケース数である、請求項１乃至３の何れか１項に記載の方法。
5. 前記ＳＡＶ評価の前記曖昧性値は、
   (HFE % + (100 / (1 + (# of other steps / 10)))) / 2として計算され、ＨＦＥはパーセントでの最大改修効果であり、「# of other steps」は１より小さい解決プロセスにおけるステップの総数である、請求項１乃至４の何れか１項に記載の方法。
6. 航空機保守スケジューリングのためのシステム（１０２）であって、
   エラー・レポートをプロセッサと通信する電子非準拠リポジトリ（３４９）から受信するメモリ（３４２）を有する前記プロセッサ（３４０）であって、前記エラー・レポートは航空機（１０４）内の非準拠条件に関する情報を含む、プロセッサ（３４０）と、
   前記メモリを有する前記プロセッサに接続され、前記航空機の飛行スケジュール、１つまたは複数の修理場所およびそれらの夫々の修理能力、および前記１つまたは複数の修理場所の各々に対する部品在庫を前記航空機のオペレータ（１０８）から受信するように構成された、サービス・ブリッジ（１２２）と、
   前記非準拠条件、前記飛行スケジュール、前記１つまたは複数の修理場所およびそれらの夫々の修理能力、および前記部品在庫を処理するための複数の独立なルール（３０３−３１０）を含む前記メモリに格納されたルール集合（３０２、３６０）であって、前記プロセッサは、ｉ）前記非準拠条件の補正を延期できるかどうかを判定し、延期可能であるとき、ｉｉ）前記飛行スケジュール上の位置を選択し、前記非準拠を補正するための位置で部品と人員をスケジュールするための前記ルール集合を実行するように構成される、ルール集合（３０２、３６０）と、
   を備える、航空機保守スケジューリングのためのシステム（１０２）。
7. 前記プロセッサ（３４０）による実行のための改良されたルール集合を生成するために前記ルール集合（３０２、３６０）内の前記複数の独立なルール（３０３−３１０）のうち１つまたは複数を起動および停止するための命令を受信するユーザ・インタフェース（３００、３５４）をさらに備える、請求項６に記載のシステム（１０２）。
8. 前記プロセッサ（３４０）による実行のための改良されたルール集合を生成するために前記ルール集合（３０２、３６０）内の独立なルール（３０３−３１０）を再重み付けするための命令を受信するユーザ・インタフェース（３００、３５４）をさらに備える、請求項６または７に記載のシステム（１０２）。
9. 前記非準拠条件を補正するための前記選択された位置を拒絶するための命令を受信するユーザ・インタフェース（３００、３５４）をさらに備え、前記プロセッサ（３４０）は前記非準拠条件を補正するための別の位置を生成する、請求項６乃至８の何れか１項に記載のシステム（１０２）。
10. 前記サービス・ブリッジ（１２２）を介してアクセス可能な既存のデータソースへのインタフェースを構築するための所定のプロトコルを有する統合アダプタをさらに含む、請求項６乃至９の何れか１項に記載のシステム（１０２）。