特許 6228635 安全を再重視すべき産業において職員作業混乱を管理するための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6228635

(24)【登録日】2017年10月20日

(45)【発行日】2017年11月8日

(54)【発明の名称】安全を再重視すべき産業において職員作業混乱を管理するための方法およびシステム

(51)【国際特許分類】

   G06Q 10/06 20120101AFI20171030BHJP

【ＦＩ】

   G06Q10/06 332

【請求項の数】10

【外国語出願】

【全頁数】19

(21)【出願番号】特願2016-129508(P2016-129508)

(22)【出願日】2016年6月30日

(65)【公開番号】特開2017-21794(P2017-21794A)

(43)【公開日】2017年1月26日

【審査請求日】2016年8月24日

(31)【優先権主張番号】14/795,513

(32)【優先日】2015年7月9日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】390041542

【氏名又は名称】ゼネラル・エレクトリック・カンパニイ

(74)【代理人】

【識別番号】100137545

【弁理士】

【氏名又は名称】荒川 聡志

(74)【代理人】

【識別番号】100105588

【弁理士】

【氏名又は名称】小倉 博

(74)【代理人】

【識別番号】100129779

【弁理士】

【氏名又は名称】黒川 俊久

(74)【代理人】

【識別番号】100113974

【弁理士】

【氏名又は名称】田中 拓人

(72)【発明者】

【氏名】ホンウェイ・リョウ

(72)【発明者】

【氏名】デイヴィッド・ソ・クン・チャン

(72)【発明者】

【氏名】ハロルド・ウッドラフ・トムリンスン

(72)【発明者】

【氏名】マーク・トーマス・ハリントン

(72)【発明者】

【氏名】リージョ・マシュー

(72)【発明者】

【氏名】ハン・ユー

【審査官】 阿部 潤

(56)【参考文献】

【文献】 特開２００７−００４６８８（ＪＰ，Ａ）

【文献】 特開平７−７３１５９（ＪＰ，Ａ）

【文献】 特開２００９−２８９０５６（ＪＰ，Ａ）

【文献】 特開２０１０−２６４９１４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

(57)【特許請求の範囲】

【請求項1】

スケジュールを受信し、イベント（３０２）を送信するように動作可能なイベントモジュール（１０２）と、
前記イベントモジュール（１０２）からの出力を受信するためのクルー追跡モジュール（１０４）であって、前記クルー追跡モジュール（１０４）は、
各イベント（３０２）に割り当てられる個々のクルーメンバの状態を追跡および更新し、
前記イベントモジュール（１０２）にクルー状態更新を送信するように動作可能である、クルー追跡モジュール（１０４）と、
前記クルー追跡モジュール（１０４）からの出力を受信するためのクルー分析モジュール（１０６）であって、前記クルー分析モジュール（１０６）は、
作業混乱を予測するように動作可能である、クルー分析モジュール（１０６）と、
プログラム命令（５１２）を記憶するためのメモリ（５３０）と、
前記メモリ（５３０）に結合されており、前記イベントモジュール（１０２）、前記クルー追跡モジュール（１０４）、前記クルー分析モジュール（１０６）と通信している少なくとも１つの作業混乱プラットフォームプロセッサ（５００）であって、
前記クルー分析モジュール（１０６）を介して、前記個々のクルーメンバのうちの少なくとも１人および前記個々のクルーメンバから成るグループの疲労レベルを推定し、
前記クルー分析モジュール（１０６）を介して、１つまたは複数の予測される作業混乱が存在するか否かを判定するために、前記クルー分析モジュールを介して、前記個々のクルーメンバのうちの少なくとも１人の前記疲労レベル、１つまたは複数の履歴イベント、前記イベントと関連付けられる、判定された導き出される混乱、および、クルー規則違反のうちの少なくとも１つと関連付けられるデータを分析し、
前記クルー分析モジュール（１０６）を介して、１つまたは複数の判定された予測される作業混乱に基づいて１つまたは複数の予測される作業混乱の指示を生成するためのプログラム命令（５１２）を実行するように動作可能である、少なくとも１つの作業混乱プラットフォームプロセッサ（５００）と
を備える、システム（１００）。

【請求項2】

前記履歴イベントは、前記送信されたイベント（３０２）と同じイベントタイプのものである、請求項１記載のシステム。

【請求項3】

前記クルー分析モジュール（１０６）は、原因分析に基づいて前記イベント（３０２）と関連付けられる、導き出される混乱を判定する、請求項１記載のシステム。

【請求項4】

前記イベント（３０２）と関連付けられる、前記判定された導き出される混乱は、先行する混乱の結果である、請求項３記載のシステム。

【請求項5】

前記クルー追跡モジュール（１０４）から出力を受信するためのクルー規則モジュール（１０８）であって、前記クルー規則モジュール（１０８）は、前記個々のクルーメンバの状態が、疲労リスクおよび規則違反のうちの少なくとも１つをもたらすか否かを判定するように動作可能である、クルー規則モジュール（１０８）をさらに備える、請求項１記載のシステム。

【請求項6】

前記クルー分析モジュール（１０６）および前記クルー規則モジュール（１０８）のうちの少なくとも一方から出力を受信するためのクルー回復モジュール（１１０）であって、前記クルー回復モジュール（１１０）は、予測される作業混乱、疲労リスクおよび規則違反のうちの少なくとも１つに応答して回復ソリューションを生成するように動作可能である、クルー回復モジュール（１１０）をさらに備える、請求項５記載のシステム。

【請求項7】

前記イベント（３０２）は、フライト出発、フライト到着、航空機装荷、クルーの業務に関する報告のうちの少なくとも１つである、請求項１記載のシステム。

【請求項8】

前記イベントモジュール（１０２）はシミュレーションモジュールであり、前記イベント（３０２）はシミュレートされるイベントである、請求項１記載のシステム。

【請求項9】

イベントモジュール（１０２）において、スケジュール（１１２）を受信し、イベント（３０２）を送信するステップと、
クルー追跡モジュール（１０４）において、前記スケジュール（１１２）および前記イベント（３０２）を受信し、各イベント（３０２）に割り当てられる個々のクルーメンバの状態を追跡および更新するステップと、
クルー分析モジュール（１０６）を介して、前記個々のクルーメンバのうちの少なくとも１人および前記個々のクルーメンバから成るグループの疲労レベルを推定するステップと、
１つまたは複数の予測される作業混乱が存在するか否かを判定するために、前記クルー分析モジュール（１０６）を介して、
前記個々のクルーメンバのうちの少なくとも１人の前記疲労レベル、１つまたは複数の履歴イベント、クルー規則違反、および、前記イベントと関連付けられる、判定された導き出される混乱のうちの少なくとも１つと関連付けられるデータを分析するステップと、
前記クルー分析モジュール（１０６）を介して、１つまたは複数の判定された予測される作業混乱に基づいて１つまたは複数の予測される作業混乱の指示を生成するステップと
を含む、方法。

【請求項10】

作業混乱プラットフォームプロセッサによって実行されると、前記作業混乱プラットフォームプロセッサに、作業混乱と関連付けられる方法を実施させる命令を記憶している非一時的コンピュータ可読媒体であって、前記方法は、
イベントモジュール（１０２）において、スケジュール（１１２）を受信し、イベント（３０２）を送信するステップと、
クルー追跡モジュール（１０４）において、前記スケジュール（１１２）および前記イベント（３０２）を受信し、各イベントに割り当てられる個々のクルーメンバの状態を追跡および更新するステップと、
クルー分析モジュール（１０６）を介して、前記個々のクルーメンバのうちの少なくとも１人および前記個々のクルーメンバから成るグループの疲労レベルを推定するステップと、
前記または複数の予測される作業混乱が存在するか否かを判定するために、前記クルー分析モジュール（１０６）を介して、前記個々のクルーメンバのうちの少なくとも１人の前記疲労レベル、１つまたは複数の履歴イベント、クルー規則違反、および、前記イベントと関連付けられる、および、前記判定された導き出される混乱のうちの少なくとも１つと関連付けられるデータを分析するステップと、
前記クルー分析モジュール（１０６）を介して、１つまたは複数の判定された予測される作業混乱に基づいて１つまたは複数の予測される作業混乱の指示を生成するステップと
を含む、非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、職員作業混乱を管理するための方法およびシステムに関する。

【背景技術】

【0002】

安全を再重視すべき産業（たとえば、航空、鉄道、医療、石油、およびガス）において、職員は多くの場合、安全操業を保証するために、１日２４時間週７日ベースで厳密な作業スケジュールおよび規則に従い得る。作業スケジュール混乱は、たとえば、極端な天候状態、予期せぬ設備保守管理、インフラストラクチャによって引き起こされる遅延、示威行為および職員の病気のような混乱によって引き起こされる場合がある。

【0003】

一般的に、職員作業混乱管理システムは、現在の混乱または過去の混乱に（すなわち、受身的に）反応する。受身的でしかない混乱ソリューションは、安全を再重視すべき産業にとっては非常にコストがかかるものであり得る。安全を再重視すべき産業において、職員は、厳密な作業スケジュールおよび規則に従うことが多く、そのため、混乱に対する反応時間窓が短くなるほど、混乱からの回復のために存在し得る選択肢がより少なくなるため、混乱が招くコストはより高くなる。たとえば、航空路線の運用において航空便がキャンセルされるとき、すぐに応じられるクルーが用意されなければならず、たとえフライトがキャンセルされたとしても、賃金が支払われなければならない。別の例として、出発時間近くに検出される、クルーに関連する混乱（たとえば、クルーの疲労）が結果として、フライトのキャンセルをもたらす場合があり、これは航空路線におって非常にコストがかかる。

【0004】

それゆえ、職員作業スケジュールに対する将来の／可能性のある混乱を積極的に予測し処理するためのより迅速でより効率的な方法を提供するシステムおよび方法を設計することが望ましい。

【発明の概要】

【0005】

いくつかの実施形態によれば、システムが提供される。システムは、スケジュールを受信し、イベントを送信するように動作可能なイベントモジュールと、イベントモジュールからの出力を受信するためのクルー追跡モジュールであって、クルー追跡モジュールは、各イベントに割り当てられる個々のクルーメンバの状態を追跡および更新し、イベントモジュールにクルー状態更新を送信するように動作可能である、クルー追跡モジュールと、クルー追跡モジュールからの出力を受信するためのクルー分析モジュールであって、クルー分析モジュールは、作業混乱を予測するように動作可能である、クルー分析モジュールと、プログラム命令を記憶するためのメモリと、メモリに結合されており、イベントモジュール、クルー追跡モジュール、クルー分析モジュールと通信している少なくとも１つの作業混乱プラットフォームプロセッサであって、クルー分析モジュールを介して、個々のクルーメンバのうちの少なくとも１人および個々のクルーメンバから成るグループの疲労レベルを推定し、クルー分析モジュールを介して、１つまたは複数の予測される作業混乱が存在するか否かを判定するために、クルー分析モジュールを介して、個々のクルーメンバのうちの少なくとも１人の疲労レベル、１つまたは複数の履歴イベント、イベントと関連付けられる、判定された導き出される混乱、および、クルー規則違反のうちの少なくとも１つと関連付けられるデータを分析し、クルー分析モジュールを介して、１つまたは複数の判定された予測される作業混乱に基づいて１つまたは複数の予測される作業混乱の指示を生成するためのプログラム命令を実行するように動作可能である、少なくとも１つの作業混乱プラットフォームプロセッサとを含む。

【0006】

いくつかの実施形態によれば、方法が提供される。方法は、イベントモジュールにおいて、スケジュールを受信し、イベントを送信するステップと、クルー追跡モジュールにおいて、スケジュールおよびイベントを受信し、各イベントに割り当てられる個々のクルーメンバの状態を追跡および更新するステップと、クルー分析モジュールを介して、個々のクルーメンバのうちの少なくとも１人および個々のクルーメンバから成るグループの疲労レベルを推定するステップと、１つまたは複数の予測される作業混乱が存在するか否かを判定するために、クルー分析モジュールを介して、個々のクルーメンバのうちの少なくとも１人の疲労レベル、および、１つまたは複数の履歴イベント、クルー規則違反、イベントと関連付けられる、判定された導き出される混乱のうちの少なくとも１つと関連付けられるデータを分析するステップと、クルー分析モジュールを介して、１つまたは複数の判定された予測される作業混乱に基づいて１つまたは複数の予測される作業混乱の指示を生成するステップとを含む。

【0007】

いくつかの実施形態によれば、非一時的コンピュータ可読媒体が提供される。コンピュータ可読媒体は、作業混乱プラットフォームプロセッサによって実行されると、作業混乱プラットフォームプロセッサに、作業混乱と関連付けられる方法を実施させる命令を記憶しており、方法は、イベントモジュールにおいて、スケジュールを受信し、イベントを送信するステップと、クルー追跡モジュールにおいて、スケジュールおよびイベントを受信し、各イベントに割り当てられる個々のクルーメンバの状態を追跡および更新するステップと、クルー分析モジュールを介して、個々のクルーメンバのうちの少なくとも１人および個々のクルーメンバから成るグループの疲労レベルを推定するステップと、１つまたは複数の予測される作業混乱が存在するか否かを判定するために、クルー分析モジュールを介して、個々のクルーメンバのうちの少なくとも１人の疲労レベル、および、１つまたは複数の履歴イベント、クルー規則違反、イベントと関連付けられる、判定された導き出される混乱のうちの少なくとも１つと関連付けられるデータを分析するステップと、クルー分析モジュールを介して、１つまたは複数の判定された予測される作業混乱に基づいて１つまたは複数の予測される作業混乱の指示を生成するステップとを含む。

【0008】

本明細書において使用される場合、動作を「促進」することは、動作を実施すること、動作をより容易にすること、動作を実行するのを助けること、または、動作が実施されるようにすることを含む。したがって、限定ではなく例として、動作が実施されるようにするか、または、動作が実施されるのを補助するための適切なデータまたはコマンドを送信することによって、１つのプロセッサ上で実行する命令が、遠隔プロセッサ上で実行する命令によって実行される動作を促進することができる。疑義を回避するために、動作者が動作を実施する以外のことによって動作を促進する場合、動作はそれにもかかわらず、何らかの実体または実体の組み合わせによって実施される。

【0009】

本発明またはその要素の１つまたは複数の実施形態は、示されている方法ステップを実施するためのコンピュータ使用可能プログラムコードを有するコンピュータ可読媒体を含むコンピュータプログラム製品の形態で実施することができる。さらに、本発明またはその要素の１つまたは複数の実施形態は、メモリと、メモリに結合され、例示的な方法ステップを実施するように動作可能である少なくとも１つのプロセッサとを含むシステム（または装置）の形態で実施することができる。またさらに、別の態様において、本発明またはその要素の１つまたは複数の実施形態は、本明細書に記載されている方法ステップのうちの１つまたは複数を実行するための手段の形態で実施することができ、手段は、（ｉ）ハードウェアモジュール（複数可）、（ｉｉ）コンピュータ可読記憶媒体（または複数のそのような媒体）内に記憶されており、ハードウェアプロセッサ上で実装されるソフトウェアモジュール（複数可）、または、（ｉｉｉ）（ｉ）および（ｉｉ）の組み合わせを含むことができ、（ｉ）〜（ｉｉｉ）のいずれかが、本明細書に記載されている特定の技法を実施する。

【0010】

本発明のいくつかの実施形態の技術的効果は、職員作業混乱を管理するための改善された技法およびシステムである。以降で明らかになるこのおよび他の利点および特徴によって、以下の詳細な説明および本明細書に添付の図面を参照することによって本発明の性質のより完全な理解を得ることができる。

【0011】

他の実施形態は、本明細書に記載されている方法のいずれかを実施するための命令を記憶しているシステムおよび／またはコンピュータ可読媒体と関連付けられる。

【図面の簡単な説明】

【0012】

【図1】いくつかの実施形態によるシステムを示す図である。

【図2】いくつかの実施形態による流れ図である。

【図3】いくつかの実施形態によるデータセットを示す図である。

【図4】いくつかの実施形態による流れ図である。

【図5】いくつかの実施形態による、作業混乱管理処理ツールまたはプラットフォームのブロック図である。

【発明を実施するための形態】

【0013】

安全を再重視すべき産業（たとえば、航空、鉄道、医療、石油、およびガス）において、職員は、安全操業を保証するために、１日２４時間週７日ベースで厳密な作業スケジュールおよび規則に従い得る。作業スケジュール混乱は、たとえば、極端な天候状態、予期せぬ設備保守管理、インフラストラクチャによって引き起こされる遅延、示威行為および職員の病気のような混乱によって引き起こされる場合がある。従来の、作業職員管理システムは、現在のまたは過去の混乱に（すなわち、受身的に）反応する。将来のおよび／または可能性のある混乱を積極的に予測し、この情報を使用して職員混乱をより良好に管理することが望ましい。

【0014】

いくつかの実施形態は、現在の職員作業混乱を検出し、さらに、たとえば、原因分析に基づいて将来の混乱を予測するために、イベントモジュール、クルー追跡モジュール、およびクルー分析モジュールを介してシステム動作状態および職員状態を追跡および分析することを含む。１つまたは複数の実施形態は、受身的にと積極的にの両方で職員作業混乱を管理することを可能にする。１つまたは複数の実施形態において、検出された混乱および導き出された混乱（現在の、将来のおよび可能性のある）は、混乱に対する解決のための回復モジュール（たとえば、「回復ソリューション」）に送信することができる。１つまたは複数の実施形態において、既存の作業計画を、職員混乱リスク（たとえば、職員疲労または作業混乱によって引き起こされる）について評価することができる。１つまたは複数の実施形態は、リアルタイムまたは即時にシミュレーション、分析および決定を行うために、安全を再重視すべき産業において操業する日の間に使用することができる。１つまたは複数の実施形態は、作業計画を評価し、混乱シナリオの様々な例の「ｗｈａｔ−ｉｆ」分析（たとえば、もし飛行機Ｘが２０分遅延したらどうなるか？それによって飛行機Ｙのフライトにどのような影響があるか？）を行うために「オフライン」で使用することができる。

【0015】

航空産業は本明細書において例として使用される安全を再重視すべき産業であるが、本発明の実施形態は、他の安全を再重視すべき産業（たとえば、鉄道、医療、石油、ガスなど）に適用可能である。

【0016】

図１は、いくつかの実施形態による、作業混乱管理処理システム１００の一例である。システム１００は、イベントモジュール１０２と、クルー追跡モジュール１０４と、クルー分析モジュール１０６と、クルー規則モジュール１０８と、クルー回復モジュール１１０とを含むことができる。

【0017】

下記にさらに説明するように、イベントモジュール１０２は、職員割り当ておよびフライトスケジュールを含む作業スケジュール１１２を受信１０１し、イベントを作成する。本明細書において使用される場合、「イベント」は、システム状態に変化を生じる任意のものを指し得る。たとえば、運転調査において使用されるものとしての「個別イベントシミュレーション」のような語句がある。「イベント」は、システム動作、規則および動態によって駆動される通常の運転イベントを指し得る。たとえば、フライトをシミュレートするために、対象のイベントは、クルーの搭乗、乗客の搭乗、貨物の積載、ゲートからのプッシュバック、タクシーアウト、離陸、上昇、巡航、降下、着陸、タクシーイン、ゲートへの到着、貨物を降ろすこと、乗客を降ろすこと、クルーが飛行機を降りることを含み得る。通常運転を逸脱する要因によって、混乱イベントが駆動される場合がある。たとえば、混乱イベントは、天候の混乱、滑走路の渋滞、クルーの病気、クルーの空港に遅刻するという報告、または、フライトキャンセル、フライト遅延のような一般的な結果的イベントのような外部イベントである場合がある。いくつかの実施形態において、「イベント」は、特定数の職員を使用する特定の時間に発生するようにスケジュールされている何らかの事例である。たとえば、航空産業に関して、おおまかに言って、イベントは、点Ａから点Ｂまでのスケジュールされているフライトであり得、一方で、医療産業に関して、イベントは、外科手術であり得る。本明細書において使用される場合、「職員」および「クルー」は、交換可能に使用されてもよい。作業スケジュール１１２は、ユーザ１１４によって入力されてもよく、別のシステムもしくはシステムの構成要素、または任意の他の適切な手段から受信されてもよい。１つまたは複数の実施形態において、イベントモジュール１０２は、イベントに関する更新をリアルタイムで受信することができる。たとえば、航空産業に関して、イベント（たとえば、スケジュールされているフライト）は、フライト状態情報（たとえば、クルーの到着、乗客の搭乗、出発、離陸、飛行中、到着）がイベントモジュール１０２によって受信されると、更新される場合がある。１つまたは複数の実施形態において、イベントモジュール１０２は、下記にさらに説明するように、作業混乱を予測するために、イベントの更新またはクルー追跡モジュール１０４および／もしくはクルー分析モジュール１０６への送信のうちの少なくとも１つのために、（たとえば、ユーザ１１４から、または、たとえば、クルー追跡モジュール１０４から）実際の混乱、推定される混乱、予測される混乱および／または仮定の混乱（たとえば、天候、フライトキャンセルまたは遅延、クルー病気休暇、空港外出禁止）に関する情報を受信することができる。

【0018】

１つまたは複数の実施形態において、イベントモジュール１０２は、たとえば、作業スケジュール１１２に内の各個々のフライトをシミュレートし、シミュレートされたフライト状態情報（たとえば、クルー出勤、乗客の搭乗、出発、離陸、飛行中、到着）、ならびに、シミュレートされた実際の混乱、推定される混乱、予測される混乱および／または仮定の混乱をクルー追跡モジュール１０４に提供して、クルー分析モジュール１０６を拡張することによって、シミュレートされたフライトに関して作業混乱を予測することができる。１つまたは複数の実施形態において、シミュレートされた実際の混乱は、実際の（たとえば、履歴）混乱をモデル化することができ、この混乱はすでに起こったものであり、シミュレーションによってユーザに分かる。たとえば、午前９時に吹雪が発生しており、現在時刻は午前１０時である。混乱の影響をシステムに組み込むように実際の天候シナリオをシミュレートすることができ、これによって、決定を進めることを促進することができる。シミュレーションは、ユーザが仮定のイベントをテストすることを可能にすることができ、ビジネス決定を知らせるのに役立ち得る。１つまたは複数の実施形態において、シミュレートされた仮定の混乱は、仮定の混乱をモデル化する。上記の吹雪の例示形態を続けると、天気予報が、午後３時から午後５時の間に６〜１０インチの降雪量の別の吹雪が来ることを示している。このシナリオにはいくつかの不確定要素がある（たとえば、吹雪の時間および深刻度）。シミュレーションにおいて、不確定要素に対処するために、いくつかの仮定混乱シナリオが作成される（たとえば、午後３時６インチ、午後３時８インチ、午後３時１０インチ、午後３時３０分６インチ、午後３時３０分８インチなど）。シミュレートされる仮定混乱の別の応用形態は、たとえば、混乱の様々なシナリオ下で作業計画をストレステストするための、作業計画の「ｗｈａｔ−ｉｆ」分析である。イベントモジュール１０２は、シミュレーションベースのプロセスを使用して、様々なシステム構成要素およびリソースをモデル化し、（たとえば、航空路線フライト、フライト状態、乗客状態、手荷物状態、貨物状態、空港状態、空域状態、天候状態などに関して）それらの状態を追跡することができる。１つまたは複数の実施形態において、シミュレーションモジュールとして、イベントモジュール１０２は、シミュレーションベースの技法（たとえば、個別イベントシミュレーション）を使用して、たとえば、他のモジュールに情報を提供するためのフレームワークとして作用する「仮想航空路線」をモデル化することができる。

【0019】

イベントモジュール１０２は、クルー追跡モジュール１０４にイベント発生情報（たとえば、フライト出発、フライト到着、航空機装荷、業務に関する報告など）を送信１０３することができる。１つまたは複数の実施形態において、クルー追跡モジュール１０４は、イベント発生情報からクルー状態情報を導き出すことができ、受信されたイベント発生情報に基づいてクルー追跡モジュール１０４内に記憶されている現在のクルー状態情報を更新することができる。１つまたは複数の実施形態において、個々のクルー状態情報は、クルー位置、累積作業時間（たとえば、業務時間および飛行時間）、休憩時間、および作業計画を含むことができる。他の適切なクルー状態情報が使用されてもよい。注目すべきことに、個々のクルーは業務中であり得るが飛行中ではない場合があり、各カテゴリと関連付けられる複数の異なる規則があり得る（非飛行業務対飛行業務）。１つまたは複数の実施形態において、クルー追跡モジュール１０４は、受信されたイベント発生情報に基づいて各イベント（たとえば、フライト）に割り当てられる個々のクルーの状態を追跡および更新することができる。１つまたは複数の実施形態において、更新されたクルー状態情報は、シミュレートされたイベントを促進するためにイベントモジュール１０２に返信１０５され得る。１つまたは複数の実施形態において、クルー追跡モジュール１０４は、作業スケジュール１１２ごとに、イベントモジュール１０２から受信されるクルー情報とは異なるクルー状態情報を含むことができる。たとえば、更新されたクルー状態情報は、作業スケジュール１１２がシステム１００に入力された後に、外部ソースから（たとえば、クルーメンバ、クルー管理者などから直に）クルー追跡モジュール１０４に入力することができる。１つまたは複数の実施形態において、クルー追跡モジュール１０４は、イベントと関連付けられるクルーのクルー状態情報と、そのクルーの他のクルー状態情報（たとえば、外部ソースからのクルー状態情報）とを比較し、クルー状態情報が異なる場合、外部入力されたクルー状態情報を、イベントモジュール１０２に対する更新として、クルー追跡モジュール１０４に送信１０５することができる。

【0020】

クルー追跡モジュール１０４は、クルー分析モジュール１０６に（クルー状態を含む）システム状態情報を送信１０７することができる。１つまたは複数の実施形態において、クルー状態およびシステム状態は、現在の状態および履歴状態情報を含むことができる。１つまたは複数の実施形態において、「クルー」は「システム」の一部分であるため、クルー状態は、システム状態のサブセットであり得る。１つまたは複数の実施形態において、システム状態は、フライト、航空機、クルーメンバ、乗客、貨物などの状態を含むことができる。たとえば、クルーメンバについて、それらの状態は、現在位置、現在の飛行業務、累積飛行時間、累積業務時間、飛行時間制限、業務時間制限などを含むことができる。履歴状態は、業務におけるフライトの流れ、以前の飛行業務、業務の出勤時刻、業務において経験された混乱などを含むことができる。１つまたは複数の実施形態において、クルー分析モジュール１０６は、受信された情報を使用して、クルーの疲労レベルを個々にまたはグループとして推定することができ、これは、１つまたは複数の作業混乱を予測するためにクルー分析モジュール１０６によって使用される少なくとも１つの態様であり得る。１つまたは複数の実施形態において、クルー分析モジュール１０６は、クルー疲労関連情報を含む履歴データを使用することができる機械学習プロセスを使用して、予測モデルおよびクルーの推定疲労スコアを生成することができる。いくつかの実施形態において、クルー分析モジュール１０６は、生理学的モデルを使用して、環境要因、業務、フライト、休憩、および経験された混乱に関連してクルー疲労レベルを特性化することができる。疲労レベルを推定する他の適切な方法が使用されてもよい。１つまたは複数の実施形態において、クルー分析モジュール１０６は、受信されたクルー状態およびシステム状態情報を分析して、（たとえば、遅延、クルー疲労および／または下記にさらに論じるようなクルー規則、ならびに、いくつかの実施形態ではシミュレーション論理に基づいて）現在の作業混乱を検出し、（たとえば、原因分析に基づいて）将来の作業混乱を導き出し、（たとえば、予想に基づいて）可能性のある作業混乱を予測することができる。

【0021】

図２を参照すると、いくつかの実施形態による動作の一例において、いくつかの実施形態によるプロセス２００の流れ図が提供される。プロセス２００および本明細書に記載されている他のプロセスは、ハードウェア（たとえば、回路（複数可））、ソフトウェアまたは手動手段の任意の適切な組み合わせを使用して実施されてもよい。１つまたは複数の実施形態において、システム１００は、プロセス２００を実施するように調整され、それによって、システム１００は、汎用コンピュータまたはデバイスによって実施可能でない動作を実施するように構成されている専用要素になる。これらのプロセスを具現化するソフトウェアは、固定ディスク、フロッピーディスク、ＣＤ、ＤＶＤ、フラッシュドライブ、または磁気テープを含む任意の非一時的有形媒体によって記憶されてもよい。これらのプロセスの例はシステム１００の要素に関連して下記に説明されるが、実施形態はそれに限定されない。

【0022】

最初に、Ｓ２１０において、システムおよびクルーの現在のおよび履歴状態情報が、クルー分析モジュール１０６において受信される。１つまたは複数の実施形態において、現在のおよび履歴状態情報は、特定のイベントと関連付けられるシステムおよび／またはクルーに関するものであり得る。１つまたは複数の実施形態において、履歴イベントは、送信されたイベントと同じイベントタイプのものである。その後Ｓ２１２において、クルー分析モジュール１０６は、この情報の、イベント（たとえば、フライト）に対する影響を判定するために、現在のおよび履歴情報を分析する。現在のクルー作業混乱がＳ２１４において判定される。Ｓ２１６において、現在のクルー混乱と関連付けられる原因分析に基づいて、将来のクルー混乱を導き出すことができる（たとえば、現在のクルー混乱が将来の導き出されるクルー混乱を引き起こす）。１つまたは複数の実施形態において、原因分析は、クルー関連分析およびフライト関連分析の両方を使用して、将来のクルー混乱を導き出すことができる。たとえば、現在のクルー混乱が（現在のおよび／または将来の）フライト混乱を引き起こす場合があり、フライト混乱が、将来のクルー混乱を引き起こす場合がある。クルーおよび航空機は、フライトを運用するための２つのタイプのリソースと考えることができ、一方のタイプのリソースが混乱した場合、この混乱が他方のリソースに影響を与える場合がある（「相互作用的影響」）。この相互作用的影響は、産業全体を通じて下流へと伝播するおそれがある。１つまたは複数の実施形態において、原因分析を使用して、上述した相互作用的影響および伝播影響を捕捉することができる。将来のクルー混乱は、他の適切な分析を使用して導き出されてもよい。Ｓ２１８において、判定された現在のクルー混乱および導き出された将来のクルー混乱が、クルー回復モジュール１１０に送信される。Ｓ２２０において、クルー分析モジュール１０６が、現在のおよび履歴状態情報をさらに分析して、可能性のあるイベント影響、混乱、およびクルー疲労状態を予測することができる。１つまたは複数の実施形態において、Ｓ２２０は、Ｓ２１８の前、Ｓ２１８の後、または、Ｓ２１８と実質的に同時に行われてもよい。その後、Ｓ２２２において、図３に関連して下記にさらに説明するように、可能性のあるクルー混乱を、予測および予想に基づいて導き出すことができる。１つまたは複数の実施形態において、可能性のあるクルー混乱は、一般的な混乱、クルーの疲労によって引き起こされる混乱を含むことができる。その後、Ｓ２２４において、予測された可能性のあるクルー混乱が、クルー回復モジュール１１０に送信される。Ｓ２２６において、さらなるイベントが分析に利用可能であるか否かの判定が行われる。Ｓ２２６において、さらなるイベントが利用可能でないと判定される場合、プロセスはＳ２２８において終了する。Ｓ２２６において、さらなるイベントが利用可能であると判定される場合、プロセス２００はＳ２１０に戻り、特定のイベントに関するシステムおよびクルーの現在のおよび履歴状態情報が受信される。

【0023】

クルー分析モジュール１０６は、クルー回復モジュール１１０に、予測されるおよび実際のクルー作業混乱を送信１０９することができる。１つまたは複数の実施形態において、クルー回復モジュール１１０は、作業混乱を分析することができ、分析に基づいて、クルー回復モジュール１１０は、作業混乱に対する１つまたは複数の回復ソリューションを生成することができる。１つまたは複数の実施形態において、クルー回復モジュール１１０は、回復ソリューションを生成するために、いくつかのクルー回復プロセスのうちの少なくとも１つを作業混乱に適用することができる。たとえば、クルー回復モジュール１１０は、最適化ソルバベースのプロセス、シミュレーションベースのプロセス、規則ベースのプロセス、経験的プロセス、および、発見ベースのプロセスのうちの少なくとも１つを作業混乱に適用して、回復ソリューションを生成することができる。他の適切なクルー回復プロセスが適用されてもよい。

【0024】

１つまたは複数の実施形態において、クルー追跡モジュール１０４はまた、イベントの少なくとも１つの局面（たとえば、フライト出発）の前にクルー規則モジュール１０８にクルー状態情報を送信１１１することもできる。１つまたは複数の実施形態において、クルー状態情報は、クルー分析モジュール１０６およびクルー規則モジュール１０８に実質的に同時に送信することができる。クルー規則モジュール１０８は、イベントに関与することによって、クルー業務および休憩要件のいずれかが違反されているか否かを判定することができる。１つまたは複数の実施形態において、イベントに関連付けられる産業（たとえば、航空産業に対する１４ ＣＦＲ １１７）は、クルーと関連付けられる要件および規制を含むことができる。たとえば、航空産業において、４つの飛行区間に携わるクルーは、最大１３時間にわたって業務で作業することができる。規則および／または規制が違反された場合、クルー規則モジュール１０８は、１つまたは複数の実施形態において、クルー回復モジュール１１０に違反を送信１１３することができる。クルー回復モジュール１１０は、作業混乱と考えることができる違反を分析することができ、分析に基づいて、クルー回復モジュール１１０は、作業混乱に対する１つまたは複数の回復ソリューションを生成することができる。

【0025】

図３は、４つの異なるイベント３０２（たとえば、フライトＡ、フライトＢ、フライトＣ、およびフライトＤ）の例示的なスケジュール３００を提供し、これは、各フライトについて、フライト出発時刻３０４と、出発都市３０６と、到着時刻３０８と、到着都市３１０とを含む。１人のクルーが業務中であり、フライトＡ、Ｂ、ＣおよびＤを飛ぶように割り当てられている。本明細書に記載されている例について、クルーは１つのフライトから別のフライトへと乗り換えるために少なくとも３０分を必要とする。クルーは自身の最初の業務を午前７時に開始しており、航空機保守管理に起因する、フライトＡの遅延によって引き起こされた９０分の遅延を経験している。航空機保守管理遅延は、イベントモジュール１０２に混乱イベントとして入力することができる。この遅延によって、クルーは９：３０に加えて９０分後（すなわち、１１：００）に都市Ｘ２に到着することを余儀なくされる。

【0026】

図２のＳ２１４に関連して上述したように、クルー分析モジュール１０６は、クルーが都市Ｘ２に遅れて到着すると判定することができる。回復動作が行われなかった場合、クルーは、１１：００に加えて３０分後（すなわち、１１：３０）にフライトＢに対する準備ができることになり、これによって、フライトＢに対して１時間の出発遅延が引き起こされる。１つまたは複数の実施形態において、この混乱は、クルー回復モジュール１１０に送信１０９することができ、それによって、クルー回復モジュール１１０は、回復ソリューションを生成する。回復ソリューションは、たとえば、混乱を受けたクルーに代わってフライトＢを飛ぶための待機クルーを見つけることであってもよく、これによって、フライトＢの出発遅延を回避または低減することができ、混乱を受けたクルーを別のフライトを介して都市Ｘ２から都市Ｘ３に回送することができる。本明細書において使用される場合、「クルーを回送する」とは、クルーを１つの場所から別の場所へと移動させることを意味するが、この移動は「能動的業務」の一部分ではなく、それによって、移動に費やされる時間は飛行時間の一部分とは考えなくてもよく、ただし、業務時間の一部分であると考えられ得る。

【0027】

上記で与えられた回復ソリューションが使用された場合、元のクルーは都市Ｘ３に回送されることになり、１４：００に到着する。クルーは１つのフライトから別のフライトへと乗り換えるのに少なくとも３０分を必要とするため、クルーは１４：３０にフライトＣに対する準備ができ、これによって、フライトＣの３０分の出発遅延が引き起こされる。このフライトＣの遅延は、「導き出される」混乱と考えることができ、これは、図２のＳ２１６において説明したように、原因分析から導き出すことができる。

【0028】

上記に基づいて、フライトＣは、たとえば、３０分の出発遅延を有することになる。出発が遅くなることによって、さらなる遅延が招かれ得る（たとえば、離陸する滑走路に対する待機がより長くなり、航空交通管制の制約に起因して飛行時間がより長くなり、より多くの航空機が後の時間において飛んでいることになり得るため、行き先における発着枠が不足する、など）。クルー分析モジュール１０６は、その後、図２のＳ２２０のように、たとえば、履歴運用の分析に基づいて、可能性のある混乱／遅延を予測および分析することができる。たとえば、予測分析が、履歴運用に基づいて、離陸する滑走路に対する待機がより長くなることに起因して、フライトＣに対して３５分の予測遅延が追加されると判定することができる。そのため、フライトＣが１４：３０に出発する場合、クルー分析モジュール１０６によって実施される予測分析に基づいて、フライトＣは１７：０５に都市Ｘ４に到着することになる（１６：００に３０分の出発遅延が加わり、３５分の予測遅延が加わる）。

【0029】

フライトＣが１７：０５に都市Ｘ４に到着する場合、クルーがフライトＤに対する準備ができるのは最も早くて１７：３５であり、これによって、フライトＤに対して３５分の出発遅延が引き起こされる。本明細書における予測される混乱は、予想に加えて原因分析を使用するが、混乱を予測するために他の分析が使用されてもよい。フライトＤがいかなる他の遅延も経験しないと仮定すると、フライトＤは２０：２０に都市Ｘ５に到着することになる。

【0030】

上述したように、回復ソリューションは、クルー回復モジュール１１０からイベントモジュール１０２に送信１１５することができる。１つまたは複数の実施形態において、回復ソリューションは、イベントモジュール１０２からクルー追跡モジュール１０４に送信１０３することができ、その後、クルー規則モジュール１０８に送信１１１することができる。クルー規則モジュール１０８は、回復ソリューションを様々な規則および規制と比較して、ソリューションがクルーに対する制限および要件を満たすか否かを判定することができる。１つまたは複数の実施形態において、回復ソリューションは、クルー規則モジュール１０８に直に送信されてもよく、クルー規則モジュールは、ソリューションがクルーに対する制限および要件を満たすか否かを判定するために、クルー追跡モジュール１０４からのクルー状態情報をも受信１１１する。本明細書における例において、飛行および業務制限および休憩要件に関する米国連邦規制によって、午前７時に業務を開始しており、４つの飛行区間を有するクルーは、最大１３時間にわたって業務で作業することができる。しかしながら、クルーがフライトＤを飛ぶ場合、クルー規則モジュール１０８は、クルーが２０分だけ業務制限に違反すると判定することができる。この例において、業務制限違反は「予測」分析（フライトＣに対する）および原因分析の両方に基づいて判定されるが、他の分析が使用されてもよい。クルー規則モジュール１０８は、クルー回復モジュール１１０にこの違反を送信１１３することができ、クルー回復モジュール１１０は、別の回復ソリューションを提案することができる。１つまたは複数の実施形態において、クルー分析モジュール１０６は、可能性のある違反を判定するために、クルー規則モジュール１０８に、予測されるおよび実際のクルー作業混乱を送信１２３することができる。上述したように、クルー規則モジュール１０８が違反を検出した場合、クルー規則モジュール１０８は、回復ソリューションのために、クルー回復モジュール１１０にこの違反を送信１１３することができる。規則に違反している（することになる）か否かをクルー規則モジュール１０８が判定する利点は、クルー規則モジュール１０８が、異なる管理機関および／または特別な規則から規制を捕捉するように容易に適合することができることである。

【0031】

図４を参照すると、クルー回復モジュール１１０によって実施されるプロセス４００の一例が、フライトに関係する作業混乱について与えられる。Ｓ４１０において、クルー回復モジュール１１０によって作業混乱が受信される。Ｓ４１２において、混乱を受けたクルーの情報を判定するために、クルー回復モジュール１１０が、作業混乱を分析する。本明細書に示す例において、クルー回復モジュール１１０は、分析を介して、クルー作業混乱が３つのシナリオのうちの１つの結果であるか否かを判定することができる。他の適切なシナリオが使用されてもよい。Ｓ４１４において、クルー回復モジュール１１０は、上流フライトが遅延しているか否かを判定する。１つまたは複数の実施形態において、１人のクルーおよびそのクルーの業務における２つの連続したフライトを所与として、このクルーに関して、先行するフライトが後のフライトの「上流フライト」である。たとえば、図３において、フライトＣは、この例における考慮事項下では、このクルーに関してフライトＤの上流フライトである。上流のフライトが遅延した場合、方法４００はＳ４１６に進み、クルー回復モジュール１１０が回復ソリューションを提案する。上流フライト遅延シナリオについて、提案される回復ソリューションは、後続のフライトを（たとえば、１５分以下だけ）遅延させることであり得る。その後、Ｓ４１８において、クルー回復モジュール１１０は、クルー作業混乱（たとえば、問題）が解決されているか否かを判定する。クルー作業混乱が解決されている場合、クルー回復モジュール１１０は、Ｓ４２０において結果を出力することができる。１つまたは複数の実施形態において、ユーザ１１４は、複数の提案されるソリューションを受信し、１つのソリューションを選択することができる。

【0032】

Ｓ４１８において、提案される回復ソリューションがクルー作業混乱を解決していないと判定される場合、方法はＳ４１６に戻って、別の回復ソリューションが提案される。１つまたは複数の実施形態において、クルー回復モジュール１１０は、クルー作業混乱問題の少なくとも１つが解決される、ユーザ定義の時間制限に達しても解決がもたらされない、および、クルー作業混乱を解決しないユーザ定義の数のソリューションが提案された、のうちの少なくとも１つまで、回復ソリューションを繰り返し提案することができる。１つまたは複数の実施形態において、ソリューションが見つからない場合、フライトはキャンセルされる場合がある。たとえば、上流フライト遅延シナリオに対する別の回復ソリューションは、後続のフライトにおける最も短い往復がスキップされる、直接自己修正提案であり得る。このフライトをスキップすることによってクルー作業混乱が解決する場合、スキップされるフライトに待機／予備クルーが与えられ得るか、または、そのフライトはキャンセルされ得る。直接自己修正提案がクルー作業混乱を解決しない場合（たとえば、Ｓ４１８が「いいえ」であるように判定される）、Ｓ４１６において間接自己修正が提案され得、それによって、クルーは後続のフライトに回送され得る。１つまたは複数の実施形態において、クルー回復モジュール１１０は、回復ソリューションの一部分として、混乱を受けたクルーの間で実現可能な交換動作を決定することができる（たとえば、発見的手法）。

【0033】

Ｓ４１４において、上流フライトが遅延されていないとクルー回復モジュール１１０が判定する場合、方法４００はＳ４２２に進み、クルー回復モジュール１１０は、後続のフライトがキャンセルされているか否かを判定する。Ｓ４２２において後続のフライトがキャンセルされた場合、Ｓ４１６において回復ソリューションが提案され、Ｓ４２０において回復ソリューションが出力されるまで方法４００は継続し、そうでなければ、プロセスは完了する。

【0034】

Ｓ４２２において、後続のフライトがキャンセルされていないとクルー回復モジュール１１０が判定する場合、方法４００はＳ４２４に進み、クルー回復モジュール１１０は、回送されたクルーが再び混乱を受けるか否かを判定する。上述したように、本明細書において使用される場合、「クルーを回送する」とは、クルーを１つの場所から別の場所へと移動させることを意味するが、この移動は「能動的業務」の一部分ではなく、それによって、移動に費やされる時間は飛行時間の一部分とは考えなくてもよく、ただし、業務時間の一部分であると考えられ得る。Ｓ４２４において回送されたクルーが再び混乱を受けた場合、Ｓ４１６において回復ソリューションが提案され、Ｓ４２０において回復ソリューションが出力されるまで方法４００は継続し、そうでなければ、プロセスは完了する。

【0035】

後続のフライトのキャンセル（シナリオ２）および回送されたクルーの再度の混乱（シナリオ３）について、第１の提案される回復ソリューションは、たとえば、上流フライトの遅延（シナリオ１）に関連して上述したような、後続のフライトにおける最も短い往復がスキップされる直接自己修正提案であり得る。このフライトをスキップすることによってクルー作業混乱が解決する場合、スキップされるフライトに待機／予備クルーが与えられ得るか、または、そのフライトはキャンセルされ得る。直接自己修正提案がクルー作業混乱を解決しない場合（たとえば、Ｓ４１８が「いいえ」であるように判定される）、シナリオ１に関連して上述したように、Ｓ４１６において間接自己修正の第２の回復ソリューションが提案され得、それによって、クルーは後続のフライトに回送され得る。１つまたは複数の実施形態において、クルー回復モジュール１１０は、回復ソリューションの一部分として、混乱を受けたクルーの間で実現可能な交換動作を決定することができる（たとえば、発見的手法）。

【0036】

図１に戻って参照すると、１つまたは複数の実施形態において、クルー回復モジュール１１０は、回復ソリューションをイベントモジュール１０２に直に送信１１５することができる。１つまたは複数の実施形態において、クルー回復モジュール１１０は、回復ソリューションをイベントモジュール１０２に送信する前に、またはそれと実質的に同時に、回復ソリューションを１者または複数のユーザ１１４に送信１１７することができる。１つまたは複数の実施形態において、ユーザ１１４は、その回復ソリューションを承認および／もしくは選択するか、または、２つ以上の回復ソリューションが提案される場合には１つの回復ソリューションを選択し、あるいは、提案されている回復ソリューションを拒絶することができ、それらに優先する回復ソリューションを与えることができ、または、クルー回復モジュール１１０が追加の提案される回復ソリューションを提供することができるように、情報（たとえば、制約、仮定、パラメータ、入力データ）を補正することができる。ユーザ１１４の最終決定は、クルー回復モジュール１１０に送信１１９することができ、その後、イベントモジュール１０２に送信１１５することができる。ユーザ１１４は、たとえば、操作者、制御者、ステーション管理者、クルーメンバ、クルー管理者、航空サービス提供者、航空路線スケジュール査定人、航空網研究者のうちの少なくとも１者であってもよい。他の適切なユーザが使用されてもよい。１つまたは複数の実施形態において、ユーザは、結果としてシステム１００が完全に自動化されるようにすることができる、自動決定プロセスであってもよい。

【0037】

１つまたは複数の実施形態において、イベントモジュール１０２は、回復ソリューションを求める要求を、クルー回復モジュール１１０に直に送信１２１することができる。たとえば、不規則な航空路線運用に起因してフライトが完全なフライトクルーを有しないとき、イベントモジュール１０２は、回復ソリューションを生成するためにクルー回復モジュール１１０を呼び出すことができる。

【0038】

本明細書に記載されている実施形態は、任意の数の異なるハードウェア構成を使用して実装されてもよいことに留意されたい。たとえば、図５は、たとえば、図１のシステム１００と関連付けることができる作業混乱管理処理プラットフォーム５００を示す。作業混乱管理処理プラットフォーム５００は、通信ネットワーク（図５には示さず）を介して通信するように構成されている通信デバイス５２０に結合されている１チップマイクロプロセッサの形態の１つまたは複数の市販の中央処理装置（ＣＰＵ）のような、作業混乱プラットフォームプロセッサ５１０を備える。通信デバイス５２０は、たとえば、１者または複数のユーザと通信するために使用することができる。作業混乱管理処理プラットフォーム５００は、入力デバイス５４０（たとえば、変数、クラスタリングおよび最適化に関する情報を入力するためのマウスおよび／またはキーボード）と、（たとえば、選択されたサンプルを出力および表示するための）出力デバイス５５０とをさらに含む。

【0039】

プロセッサ５１０はまた、記憶デバイス５３０とも通信する。記憶デバイス５３０は、磁気記憶デバイス（たとえば、ハードディスクドライブ）、光学記憶デバイス、携帯電話、および／または半導体メモリデバイスの組み合わせを含む、任意の適切な情報記憶デバイスを含んでもよい。記憶デバイス５３０は、プロセッサ５１０を制御するためのプログラム５１２および／または作業混乱管理処理論理５１４を記憶することができる。プロセッサ５１０は、プログラム５１２、５１４の命令を実施し、それによって、本明細書に記載されている実施形態のいずれかに従って動作する。たとえば、プロセッサ５１０は、イベントデータを受信することができ、その後、１つまたは複数の作業混乱を予測するために、プログラム５１２、５１４の命令を介して、クルー追跡モジュール１０４を適用し、その後、クルー分析モジュール１０６を適用することができる。記憶デバイス５３０はまた、データ５１６（たとえば、スケジュール、産業クルー規則など）を、たとえば、データベース内に記憶することもできる。

【0040】

プログラム５１２、５１４は、圧縮フォーマット、コンパイルされていないフォーマットおよび／または暗号化フォーマットで記憶されてもよい。プログラム５１２、５１４は、オペレーティングシステム、データベース管理システム、および／または、周辺デバイスとインターフェースするためにプロセッサ５１０によって使用されるデバイスドライバのような、他のプログラム要素をさらに含んでもよい。

【0041】

本明細書において使用される場合、情報は、たとえば、（ｉ）別のデバイスからのプラットフォーム５００、または、（ｉｉ）別のソフトウェアアプリケーション、モジュール、もしくは任意の他のソースからのプラットフォーム５００内のソフトウェアアプリケーションもしくはモジュールによって「受信」されてもよく、または、それらに「送信」されてもよい。

【0042】

当業者には明らかになるように、本発明の態様は、システム、方法、またはコンピュータプログラム製品として具現化することができる。したがって、本発明の諸態様は、本明細書においてはすべて包括的に「回路」、「モジュール」または「システム」と称する場合がある、全体がハードウェアの実施形態、全体がソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または、ソフトウェアの態様とハードウェアの態様とを組み合わせた実施形態の形態を取り得る。さらに、本発明の諸態様は、コンピュータ可読プログラムコードを具現化される任意の１つまたは複数のコンピュータ可読媒体内で具現化されるコンピュータプログラム製品の形態を取り得る。

【0043】

図面内のフローチャートおよびブロック図は本発明の様々な実施形態によるシステム、方法およびコンピュータプログラム製品の可能な実施態様のアーキテクチャ、機能、および動作を例示する。これに関連して、流れ図およびブロック図内の各ブロックは、指定の論理機能（複数可）を実施するための１つまたは複数の実行可能命令を含む、モジュール、セグメント、またはコードの一部分を表すことができる。また、いくつかの代替的な実施態様において、ブロックに記載されている機能は、図面に記載されている順序と一致せずに行われてもよいことに留意されるべきである。たとえば、連続して示されている２つのブロックは実際には、関与する機能に応じて、実質的に同時に実行されてもよく、または、これらのブロックは、時として逆順に実行されてもよい。また、ブロック図および／または流れ図の図解の各ブロック、ならびにブロック図および／または流れ図の図解のブロックの組み合わせは、指定の機能もしくは動作を実行する専用ハードウェアベースのシステム、または専用ハードウェアとコンピュータ命令との組み合わせによって実施することができることも留意されよう。

【0044】

本明細書に記載されている方法のいずれかは、コンピュータ可読記憶媒体上で具現化される個別のソフトウェアモジュールを備えるシステムを提供する追加のステップを含むことができ、モジュールは、たとえば、ブロック図に示されているおよび／または本明細書に記載されている要素のいずれかまたはすべてと、限定ではなく例として、クラスタリングモジュールと、最適化モジュールとを含むことができることが留意されるべきである。したがって、方法ステップは、上述したように、１つまたは複数のハードウェアプロセッサ５１０（図５）上で実行する、システムの個別のソフトウェアモジュールおよび／またはサブモジュールを使用して実行することができる。さらに、コンピュータプログラム製品が、システムに個別のソフトウェアモジュールを提供することを含む、本明細書に記載されている１つまたは複数の方法ステップを実行するために実装されるように適合されているコードを有するコンピュータ可読記憶媒体を含むことができる。

【0045】

本明細書は発明を開示し、さらに当業者が発明を実践することを可能にするために、任意のデバイスまたはシステムを作成および使用すること、ならびに任意の組み込まれた方法を使用することを含む、好ましい実施形態を含む実施例を使用している。本発明の特許可能な範囲は特許請求の範囲によって画定され、当業者が着想する他の実施例を含んでもよい。そのような他の実施例は、それらが特許請求の範囲の文言と異ならない構造要素を有する場合に、またはそれらが特許請求の範囲の文言との十分な差違を有しない等価な構造要素を含む場合に、特許請求の範囲内に入ることが意図される。記載されている様々な実施形態からの諸態様、および、各そのような態様の他の公知の等価物を、本出願の原理に従って追加の実施形態および技法を構築するために当業者によって混合および適合することができる。

【0046】

特許請求項の範囲および精神から逸脱することなく、上述した実施形態の様々な適合および修正を構成することができることを、当業者は諒解しよう。それゆえ、特許請求項は、本明細書に特定的に記載されている以外の様式で実践されてもよいことが理解されるべきである。

【符号の説明】

【0047】

１００ 作業混乱管理システム
１０１ 通信方向矢印
１０２ イベントモジュール
１０３ 通信方向矢印
１０４ クルー追跡モジュール
１０５ 通信方向矢印
１０６ クルー分析モジュール
１０７ 通信方向矢印
１０８ クルー規則モジュール
１０９ 通信方向矢印
１１０ クルー回復モジュール
１１１ 通信方向矢印
１１２ 作業スケジュール
１１３ 通信方向矢印
１１４ ユーザ
１１５ 通信方向矢印
１１７ 通信方向矢印
１１９ 通信方向矢印
１２１ 通信方向矢印
１２３ 通信方向矢印
２００ プロセス
２１０ プロセスステップ
２１２ プロセスステップ
２１４ プロセスステップ
２１６ プロセスステップ
２１８ プロセスステップ
２２０ プロセスステップ
２２２ プロセスステップ
２２４ プロセスステップ
２２６ プロセスステップ
２２８ プロセスステップ
３００ スケジュール
３０２ イベント
３０４ フライト出発時刻
３０６ 出発都市
３０８ 到着時刻
３１０ 到着都市
４００ プロセス
４０２ プロセスステップ
４０４ プロセスステップ
４０６ プロセスステップ
４０８ プロセスステップ
４１０ プロセスステップ
４１２ プロセスステップ
４１４ プロセスステップ
４１６ プロセスステップ
４１８ プロセスステップ
４２０ プロセスステップ
４２２ プロセスステップ
４２４ プロセスステップ
５００ 作業混乱管理処理プラットフォーム
５１０ プロセッサ
５１２ プログラム
５１４ 処理論理
５２０ 通信デバイス
５３０ メモリ／記憶デバイス
５４０ 入力デバイス
５５０ 出力デバイス

【図1】

【図2】

【図3】

【図4】

【図5】