特許 7547049 無人の航空交通管理のためのセキュアなマイクロサービスアーキテクチャ

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

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

(11)【特許番号】

(24)【登録日】2024-08-30

(45)【発行日】2024-09-09

(54)【発明の名称】無人の航空交通管理のためのセキュアなマイクロサービスアーキテクチャ

(51)【国際特許分類】

   G08G 5/00 20060101AFI20240902BHJP

   B64F 1/36 20240101ALI20240902BHJP

   G06Q 50/26 20240101ALI20240902BHJP

   G06Q 50/10 20120101ALI20240902BHJP

【ＦＩ】

G08G5/00 A

B64F1/36

G06Q50/26

G06Q50/10

【請求項の数】 14

(21)【出願番号】P 2019541758

(86)(22)【出願日】2019-06-29

(65)【公表番号】

(43)【公表日】2022-10-24

(86)【国際出願番号】 US2019040024

(87)【国際公開番号】W WO2021002826

(87)【国際公開日】2021-01-07

【審査請求日】2022-06-20

(73)【特許権者】

【識別番号】519275331

【氏名又は名称】エイ・キューブド・バイ・エアバス・エル・エル・シー

(74)【代理人】

【識別番号】110001173

【氏名又は名称】弁理士法人川口國際特許事務所

(72)【発明者】

【氏名】ポーラスター，ジョーセフ

(72)【発明者】

【氏名】バラクリシュナン，カルティック

【審査官】田中 将一

(56)【参考文献】

【文献】特開２００２－２４５１５２（ＪＰ，Ａ）

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

【文献】国際公開第２０１８／１４４８５９（ＷＯ，Ａ１）

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

Ｇ０８Ｇ １／００ － ９９／００

Ｂ６４Ｂ １／００ － １／７０

Ｂ６４Ｃ １／００ － ９９／００

Ｂ６４Ｄ １／００ － ４７／０８

Ｂ６４Ｆ １／００ － ５／６０

Ｂ６４Ｇ １／００ － ９９／００

Ｂ６４Ｕ １０／００ － ８０／８６

Ｇ０６Ｑ １０／００ － １０／３０

Ｇ０６Ｑ ３０／００ － ３０／０８

Ｇ０６Ｑ ５０／００ － ５０／２０

Ｇ０６Ｑ ５０／２６ － ９９／００

Ｇ１６Ｚ ９９／００

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

【請求項1】

航空交通管理システムにおいて使用するための方法であって、
サーバにより、複数の外部サービスの各それぞれのサービスに関してデータを獲得することであって、データが、（ａ）サービスに関するデータタイプを示すメタデータと、（ｂ）サービスのパフォーマンス特性とを備える、ことと、
サーバにより、遠隔デバイスから、データに対する要求を受信することであって、要求が、データの要求されるタイプを示す情報と、サービスに関する少なくとも１つの要求されるパフォーマンス要件とを含む、ことと、
サーバにより、複数の外部サービスの各々の、それぞれのメタデータおよびそれぞれのパフォーマンス特性に基づいて、複数の外部サービスのうちの１つ以上の外部サービスを識別することであって、要求されるタイプのデータを出力し、少なくとも１つの要求されるパフォーマンス要件を満足させる１つ以上の外部サービスを識別することと、
サーバにより、１つ以上の外部サービスから、要求に応答するためのサービスを選択することであって、選択することが、選択されたサービスに関するパフォーマンス特性に基づいて実行される、ことと、
サーバにより、遠隔デバイスに、遠隔デバイスからの要求に応答して、遠隔デバイスが、選択されたサービスからデータを受信することができるインターフェースを識別するために十分な通信情報を提供することと
を備える、方法。

【請求項2】

パフォーマンス特性が、サービスに関するパフォーマンスメトリック、またはサービスのパフォーマンス能力のうちの少なくとも１つである、請求項１に記載の方法。

【請求項3】

遠隔デバイスからの要求が、地理空間データに対する要求である、請求項１に記載の方法。

【請求項4】

複数の外部サービスの各外部サービスに関して、サービスに関連付けられたサービスプロバイダの認定ステータスを検証することをさらに備える、請求項１に記載の方法。

【請求項5】

複数の外部サービスの各それぞれのサービスに関してデータを獲得することが、
獲得されるデータのソースが信頼できるソースであることを識別すること、
獲得されるデータが改ざんされていないことを識別することを備える、請求項１に記載の方法。

【請求項6】

遠隔デバイスからの要求が、航空関連のデータに対する要求であり、
サービスに関する少なくとも１つの要求されるパフォーマンス要件が、サービスが遠隔デバイスに航空関連のデータを提供することができる速度もしくは適時性、サービスによって提供される航空関連のデータに関する距離範囲、サービスによって提供される航空関連のデータに関する地理的特化、最小限のデータ精度要件、またはサービスによって提供される航空関連のデータに関連付けられた価格のうちの１つである、請求項１に記載の方法。

【請求項7】

サーバと、各サービスが航空関連のデータを提供する複数のサービスにそれぞれ関連付けられた複数のサービスラッパとを備える航空交通管理システムによって実行される方法であって、
サーバにより、ユーザから、航空関連のデータに対する要求を受信することと、
サーバにより、要求から、航空関連のデータの要求されるタイプ、および要求される第１のサービス特性を獲得することと、
サーバにより、航空関連のデータに対する要求に応答して、サービスラッパに関連付けられた複数のサービスラッパの各々からのサービスのサービス情報を要求することと、
サーバにより、複数のサービスラッパの各々から、サービスラッパに関連付けられたサービスに関する要求されるサービス情報を獲得することであって、サービス情報が、サービスタイプと、サービスメトリックとを備える、ことと、
サーバにより、複数のサービスから、航空関連のデータの要求されるタイプに対応するサービスタイプを有する１つ以上のサービスを識別することと、
サーバにより、航空関連のデータの要求されるタイプに対応するサービスタイプを有する１つ以上のサービスから、要求される第１のサービス特性を満足させるサービスメトリックを有する１つ以上のサービスを識別すること、
サーバにより、要求される第１のサービス特性を満足させるサービスメトリックを有する１つ以上のサービスからサービスを選択することと、
サーバにより、選択されたサービスに関連付けられたサービスラッパに接続するための接続情報をユーザに提供することと、
サーバにより、ユーザと、選択されたサービスに関連付けられたサービスラッパとの間の関連付けをメモリに記憶することと
を備える、方法。

【請求項8】

選択されたサービスに関連付けられたサービスラッパに接続するためにユーザに提供される接続情報が、接続ポートである、請求項７に記載の方法。

【請求項9】

選択されたサービスに関連付けられたサービスラッパに接続するためにユーザに提供される接続情報が、航空関連データの要求されるタイプに対応するサービスタイプを有する１つ以上のサービスの別のサービスに関連付けられたサービスラッパに、ユーザにより接続するための接続情報と同一である、請求項７に記載の方法。

【請求項10】

要求される第１のサービス特性が、選択されたサービスがユーザに要求される航空関連のデータを提供することができる速度である、請求項７に記載の方法。

【請求項11】

要求される第１のサービス特性が、選択されたサービスが要求される航空関連のデータをユーザに提供することができる地理的区域である、請求項７に記載の方法。

【請求項12】

要求される第１のサービス特性が、選択されたサービスの準拠検証である、請求項７に記載の方法。

【請求項13】

準拠検証が、（ａ）選択されたサービスが認定ステータスを満たすというインジケーション、（ｂ）選択されたサービスが所定のデータ標準を満たすというインジケーション、（ｃ）選択されたサービスが所定のデータ範囲を満たすというインジケーション、または（ｄ）選択されたサービスが所定のパフォーマンス基準を満たすというインジケーションのうちの１つである、請求項１２に記載の方法。

【請求項14】

要求される第１のサービス特性が、選択されたサービスに関連付けられたレイテンシ測定である、請求項７に記載の方法。

【発明の詳細な説明】

【背景技術】

【0001】

航空交通管理の複雑さは、無人の航空機の可用性および使用が急速に増加するにつれて増大している。膨大な数の民間および私用の有人の飛行機に加えて、無人の航空機が、多くの地理的区域において、ますます存在感を高めることになる。例えば、趣味および商業上の目的（データ収集および配送など）でのドローン、軽飛行機、ヘリコプタ、電動垂直離着陸航空機（ｅ－ＶＴＯＬ）、およびこれらに類するものの形態の航空タクシー、政府のドローンおよび乗り物、ならびにその他の民間および私用の無人の飛行体が、高い、中間、および／または低い高度で、従来の有人の航空機と空域を共用することが可能である。有人の乗り物が従来、航空交通制御オペレーションを要求するのと同じやり方で、将来の空域管理は、有人および無人の交通のすべて、ならびに自律的な、部分的に自律的な、および／または非自律的なソリューションのすべてに対処する必要がある。さらに、共用される空域における乗り物の密度が増加するにつれ、交通航空ソリューションの可用性、速度、および信頼性の要件が、リアルタイムの応答を必要とする追跡、識別、および登録などのセーフティクリティカルな機能とともに変化する可能性がある。

【0002】

航空交通管理ソリューションは、高いハードルなしに空域へのアクセスを提供し、地球規模的または政治的境界をわたって使用されることができるソリューションを標準化および最適化し、ならびに将来に生じる可能性がある技術革新のためのスケーラビリティおよび柔軟性を提供する、安全を確実にするように航空交通を管理する構造化された方法を要求する。特に重要なのが、乗客、航空機、および輸送されている貨物の、ならびに航空機が上空を飛行する人々、リソース、および財産の、安全、セキュリティ、および快適さである。

【0003】

本開示は、以下の図面を参照してよりよく理解されることが可能である。図面の要素は、必ずしも、互いに一律の縮尺に従っておらず、代わりに、本開示の原理を明確に例示することに重点が置かれている。

【図面の簡単な説明】

【0004】

【図1A】本開示のいくつかの実施形態による無人交通管理（ＵＴＭ）システムの一部分を例示するブロック図である。

【図1B】本開示のいくつかの実施形態によるＵＴＭシステムの概念的設計を例示する図である。

【図2A】本開示のいくつかの実施形態によるＵＴＭシステムの選定された構成要素を例示する図である。

【図2B】本開示のいくつかの実施形態によるＵＴＭシステムの選定された構成要素を例示する図である。

【図3A】本開示のいくつかの実施形態によるＵＴＭシステムのアーキテクチャを例示する図である。

【図3B】本開示のいくつかの実施形態によるＵＴＭシステムのアーキテクチャを例示する図である。

【図4】本開示のいくつかの実施形態によるＵＴＭプラットフォームを介して航空サービスプロバイダからデータを獲得するための方法を示すフローチャートである。

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

【0005】

図において、参照符号の左端の数字は、参照符号が最初に出現する図を識別する。異なる図における同じ参照符号の使用は、類似した、または同一のアイテムまたは特徴を示す。さらに、同じ部分の複数の事例は、ダッシュ記号によって事例番号から分離された共通のプレフィックスによって指定される。図面は、一律の縮尺に従っていない。

【0006】

本開示は、全体的に、無人交通管理（ＵＴＭ）システムを通過するデータに関するデータ標準の設定、およびシステム内のデータインターフェースの標準化を可能にするＵＴＭのためのシステムおよび方法に関する。さらに、本開示は、データおよびパフォーマンス標準のエンドツーエンドの施行のためのシステムおよび方法に関する。一実施形態において、本明細書においてマイクロサービスまたはマイクロレベルサービスとして参照される、複数の独立に動作させられる単一機能サービス（例えば、とりわけ、気象、飛行追跡、または地形データをキャプチャするサービスなど）がユーザに利用可能であり、各単一機能サービスは、ＵＴＭプラットフォームに対する接続を可能にする固有のサービスラッパ内に収容される。サービスラッパは、その中に入っているコアサービスプログラムに対してカスタマイズされてよく、所望される構成標準およびパフォーマンス標準を満たすことを確実にし、コアサービスによって提供されるデータに対する標準化されたエントリのポイント、すなわち、データ交換のための標準化されたインターフェースを提供する。サービスラッパは、サービスコアに関するそれぞれの能力ベンチマークを獲得し、それらのベンチマークをＵＴＭプラットフォームに提供してよい。サービスによって提供されるタイプのデータに対するアクセスに関するエンドユーザ（別のサービスまたは他の任意のエンティティであってよい）によるクエリに応答して、プラットフォームは、複数のサービスのうちのいずれが、クエリするユーザに関して必要なパフォーマンスベンチマークまたは要求される能力を満たすか、したがって、最も適切に使用されるかを、インテリジェントに決定してよい。次に、プラットフォームは、ユーザを、ユーザが、クエリ要件を満たす選択されたサービスによって生成される情報にアクセスできる制御された標準のエントリのポイントに接続する。類似したサービスに関するサービスプロバイダは、異なるベンチマーク要件を満たすように、異なる能力、パフォーマンスの標準、および／または価格をオファーすることによって、他のプロバイダと競争してよい。

【0007】

いくつかの実施形態において、個別のサービスラッパにそれぞれラップされた単一機能サービスは、マクロサービスまたはマクロレベルサービス（例えば、飛行計画または回避サービスなどの、航空機のためのコマンドを、またはＵＴＭシステムのためのアクショナブルな情報を提供するサービス）を定義するサービスラッパの下で一緒にグループ化されてよい。いくつかの実施形態において、インテリジェントな分析、勧告、承認、または「データダンプ」を超える他の機能を提供するものなど、生のデータを上回るものを提供する単一機能サービスが、さらに、または代替的に、マクロレベルサービスとみなされてよい。マクロレベルサービスは、マクロレベル（または高レベル）ＵＴＭ機能にアクセスする単一の標準化されたインターフェースを提供するために使用されてよい。

【0008】

いくつかの実施形態において、エンドユーザは、単一機能サービスにサブスクライブするのではなく、例えば、生命の安全（ｓａｆｅｔｙ ｏｆ ｌｉｆｅ）制約、または他の要求される安全標準を満たすべくユニットとして一緒に認定される２つ以上のサービスの組合せにサブスクライブしてよい。いくつかの実施形態において、ＵＴＭプラットフォームは、いくつかの単一機能サービスのうちのいずれが、高レベルＵＴＭサービスが機能するために必要であるか（または、そうでなければともに含まれるべきであるか）を識別することができる論理構成要素を収容し、安全およびパフォーマンス標準により、これらの構成要素サービスの間でデータの伝送を調整する。

【0009】

いくつかの実施形態において、マイクロレベルサービス（単一機能サービス）およびマクロレベルサービス（１つ以上の単一機能サービスを含んでよい）の各々は、互いに論理的に独立であってよく、または１つ以上の論理構成において一緒にグループ化されてよい。サービスに関するサービスコア（サービスプロバイダによって書かれる、および／または提供される基本プログラム）が、サービスラッパの所定のＡＰＩ接続を通じてプラットフォームから隔離されてよい。いくつかの実施形態において、複数のサードパーティサービスプロバイダが、類似した、または同一の機能の航空サービスを提供してよく、すなわち、サービスコアは、同じタイプのデータを収集／出力／処理してよく、一方で、異なるサービスコアのパフォーマンス、レイテンシ、精度、分解能、価格、または他の因子は変わってよい。これらの類似した機能のサービスコアの各々は、サービスがプラットフォームに「プラグ接続」してよい同一のエントリポイントを提供するサービスラッパ内で構成される。サービスコアは、そのカプセル化するラッパと共に、ＵＴＭプラットフォームのエンドユーザ（またはＵＴＭプラットフォームを使用する他のエンティティ）に可視である、および／または提案されるサービスとしてひとまとめにして理解されてよい。これらの手段によって、いずれの特定のサービスに障害がおきた場合でも、プラットフォームは、サービス障害が、障害がおきたサービスの出力に依拠するユーザおよび／または他のサービスにカスケードしないように、代わりに、類似した機能のサービスに交通を単に向かわせてよい。

【0010】

いくつかの実施形態において、サービスラッパは、プラットフォームによって明示的に提供される標準化されたＡＰＩを使用してよく、したがって、サービスは、サービスラッパもその中のサービスコアも変更することなしに、任意の、類似したように構成された基礎をなすインフラストラクチャに接続されることができる、「インフラストラクチャ独立」（いくつかの実施形態において、「クラウド独立」）である。プラットフォームは、適宜、または必要に応じてインフラストラクチャサービスを切り換えてよく、それにより、サービスラッパの変化も、その中のサービスコアの変化も要求することなしに、最良のインフラストラクチャサービスを選択する。

【0011】

いくつかの実施形態において、サービスラッパは、標準化されたＡＰＩを提供してよく、したがって、プラットフォームは、サービス機能、同じＡＰＩを提供するために同じＵＴＭ機能を実現するサービスを要求することが可能である。これらの手段によって、サービスラッパは、サービスの間のモジュール性または互換性をオファーして、機能を使用する際の接続および経験の一貫性を依然としてエンドユーザにオファーしながら、プラットフォームが、最良の、または最も適切なサービスを見出すように、異なるコアサービスの使用の間で切り替わることを可能にする。

【0012】

いくつかの実施形態において、提供されるサービスがセーフティクリティカルであるか否かにかかわらず、プラットフォームは、サービスラッパを通じて、エンドツーエンドで関係のあるセーフティクリティカルな、またはセキュリティクリティカルな準拠標準を施行してよい。例えば、一実施形態において、サードパーティによってホストされるサービスから受信される生のデータは、方法のなかでもとりわけ、事前定義された署名および／または他の暗号機能の使用を通じて認証され、認証の機構は、データが様々なコンピュータシステム／リポジトリ上を伝送されるにつれて維持される（または追加される）。これらの手段によって、プラットフォームは、ＵＴＭシステムへのエントリから、オペレータまたは意思決定エンティティへのデータの最終的な伝送まで、そのようなデータに対する受け渡し記録の管理（ｃｈａｉｎ ｏｆ ｃｕｓｔｏｄｙ）を維持してよい。いくつかの実施形態において、データの伝送は、セーフティクリティカルであると認定されているリポジトリにおけるコンピュータシステムおよびストレージに限定されてよい。いくつかの実施形態において、プラットフォームはコンピュータバスであってよく、それは、セーフティクリティカルな情報の真正性および信頼性を検証し、そのデータを、セーフティクリティカルなリポジトリに格納されるように伝送し、格納されたデータに対する変形を禁止し、もしくは制限し、格納されたデータに対するアクセスを、許可された、もしくは検証されたユーザおよび／またはサービスプロバイダに制限する。

【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】

これらのサービス、またはサービスデータのタイプおよび／もしくは特性の指定は、例えば、サービス要件データの手動のエントリ、グラフィカルユーザインタフェースを通じた入力、または入力の他の任意の適切な手段を通じて行われてよい。いくつかの実施形態において、ユーザは、パフォーマンスまたは動作の要求されるサービスレベル（またはサービス特性）を指定してよく、この要求される特性は、ステップ４０４においてプラットフォーム３００によって受信される（またはいくつかの実施形態において、能動的に獲得される）。これらの要求されるパフォーマンス特性は、例えば、最低限として受入れ可能な速度（例えば、５秒）、距離（例えば、１００ｍもしくは１ｋｍ）、またはデータが獲得されることが可能な地理的区域を含んでよいが、とはいえ、特定のサービスプロバイダまたは組織の名前などの他の条件が、異なる実施形態において使用されてよい。他の実施形態において、ユーザは、いずれのサービス特性も明示的に入力する必要も、定義する必要もなく、代わりに、プラットフォーム３００が、要求自体から適切なサービス特性を認識してよい。一例として、プラットフォーム３００は、ユーザの位置に関連付けられた地理的情報から（例えば、ＧＰＳデータもしくはセンサデータ、ＩＰアドレス、ユーザプロファイルデータ、または以上に類するものから）、データが獲得されるべき適切な地理的区域を決定してよく、要求される１つ以上のサービス特性を決定すべくそのような情報を使用してよい。他の情報が、例えば、ユーザについての情報、ユーザのデータ接続、航空機のタイプ、ユーザの飛行計画、その他に基づいて、類似した様態で獲得されてよい。いくつかのそのような実装において、プラットフォーム３００は、異なるタイプのユーザにより高いレベル、またはより低いレベルのサービス要件を提供するようにユーザ間を区別せず、むしろ、サービスの最小限の要求されるレベルを決定すべく情報を獲得してよく、またはユーザ情報から推測を行ってよく、しかし、ユーザが、そのような情報を明示的に提供しない状況において、他の実施形態において他の実施例が可能であってよい。別の実施形態において、ユーザは、組織のメンバであってよく、プラットフォーム３００は、組織上の標準から、または同じ組織傘下の他のユーザの要求から、要求されるサービス特性を決定してよい。さらに別の実施形態において、プラットフォーム３００は、要求されるサービス特性の代わりに、所定の、またはデフォルトのサービス特性、例えば、平均サービスレベルまたは最良／最高サービスレベルを使用してよい。

【0048】

各サービスラッパ３０２は、そのラッパに関連付けられたサービスに関して、プラットフォーム３００の残りの部分に向けてそのサービスの特性をさらしてよい。無論、サービスは、サードパーティサービスに限定される必要はなく、マイクロもしくはマクロレベルサービス、バンドルされたサービスオファー、および／またはより低いもしくはより高いレベルのサービスを含んでもよく、そのサービスのデータは、サードパーティから調達されてよく、またはプラットフォーム３００もしくはそれに関連付けられたコンピュータシステムによって収容されるロジックによって全部もしくは一部が生成されてよいものと理解される。プラットフォームは、それらのサービスのサービス特性を、ステップ４０６においてそれらのサービスのそれぞれのサービスラッパから受信する。一実施形態において、プラットフォームは、ユーザの要求を受信すると、この情報を提供する要求をサービスラッパに伝送する。他の実施形態において、サービスラッパは、サービスラッパを介してサービスがプラットフォームに接続されたとき、またはユーザ、プラットフォーム、もしくは他の構成要素から要求されたとき、周期的に情報を提供してよく、プラットフォームは、サービスラッパによってさらされる情報をメモリ３２５、３２７に記憶してよい。

【0049】

サービスラッパ３０２によってさらされる情報は、例示的な実施形態において、サービス自体からの実際の航空データの公開を含まないように、サービスについての情報ポイント（本明細書において「メタデータ」としても参照される）に限定されてよい。いくつかの実施形態において、情報は、例えば、サービスによって提供されるデータのデータタイプ（例えば、気象データ、センサデータ、飛行計画データ、衝突回避データ、サービス２０４もしくはサービスオファリング２１２のいずれかによって提供されるデータ）、または任意の適切なデータを含んでよい。いくつかの事例において、１つのサービスは、複数のタイプのデータ（例えば、リアルタイムの気象データ、および予測される気象データ）を提供してよく、その場合、サービスラッパは、データタイプと関係する複数の情報ポイントを提供してよい。さらに他の実施形態において、ユーザは、１つのサービスによって明示的に提供されないデータを要求してよく、代わりに、２つ以上のサービスから収集されるデータの分析および／または処理を要求する。例えば、ユーザが、飛行計画などの高レベルサービスを求めている場合、マクロレベルサービスラッパ（例えば、複数のサービス２１２－１、２１２－２、および２１２－６をカプセル化する、図２Ｂにおけるサービスラッパ２５０）が、サービスの要求されるタイプに関するメタデータを提供してよい。他の実施形態において、ユーザのクエリ（例えば、飛行計画サービス）に応答して、サービス３１０が、いずれのサービスが、ユーザの要求を完了させるために必要なデータのすべてまたは部分を供給することができるかを決定すべくメタデータに関して１つ以上の他の類似したレベルのサービスを探索し、および／またはポーリングすることが可能である（すなわち、マイクロサービスが、別のマイクロサービスをポーリングすることができる）。

【0050】

さらに、サービスラッパによって公開されるサービス情報は、サービスによって供給されるデータ（例示的な実施形態において、航空関連データ、とはいえ、航空サービスの分析に関係がありながら、必ずしも、または定義によって気象関連であるわけではない、気象データなどの他のタイプのデータがアクセスされてよい）に関してサービスラッパによって施行されるサービスレベルまたはサービス特性についての情報を含んでよい。このサービス特性情報は、例えば、パフォーマンス（例えば、速度および／もしくは精度）、範囲、地理的特化、データの粒度、サービスの可用性（例えば、２４時間）、提供されるデータに関する誤差限界、サービスプロバイダについての情報（サービスプロバイダが有することが可能な認定証、もしくはサービスプロバイダのサービスの価格など）、および／または他の任意の適切な差別化するポイントを含んでよい。別の言い方をすると、これらの情報（またはこれらの情報の任意のサブセット）のいずれか、またはすべてが、パフォーマンスメトリックなどの、サービスについてのメトリックであると考えられてよい。

【0051】

いくつかの実施形態において、サービスラッパ３０２は、サービスおよび／またはサービスラッパ３０２がプラットフォーム３００に対する接続のために構成された時点でサービスプロバイダによって供給された情報を通じて、サービスおよび／またはそのパフォーマンスについてのメタデータを収集してよい。他の実施形態において、サービスラッパ３０２は、サービスプロバイダ、および／または検証インターフェース３６６に収容されるロジックからの伝送から行われた測定を通じて、１つ以上のサービス特性を決定してよい。１つの説明的な例として、サービスラッパ３０２のインターフェース３６６は、レイテンシ（往復時間）の測定などの、任意の知られている手段を通じてサービスプロバイダから（または別のサービスから）データが送られる速度を測定してよく、またはサービスによって提供されるデータの、知られているタイプの航空データとの比較を通じてデータのタイプを決定してよい。類似した様態で、様々な実施形態において、インターフェース３６６が、自らロジックを適用することを通じて、他のタイプの情報を決定できることができる。

【0052】

次に、プラットフォーム３００は、いくつかの実施形態において、各サービスの特性に関して検索を実行して、各サービスの特性を分析してよい（ステップ４０８）。分析は、いくつかの実施形態において、２部分の決定を含んでよい。第１に、プラットフォームが、複数の利用可能なサービス３１０のうちいずれが、ユーザによって要求されるタイプのデータを提供するかを識別すべく、そのサービスのサービスラッパによって提供される情報またはメタデータにおいて指定されるサービスのタイプを考慮してよい。第２に、正しいタイプのデータを提供するサービス３１０のそのサブセットのなかで、プラットフォームが、いずれのサービスが、もしあるなら、ユーザによって要求されるサービス特性またはサービスレベルを満たすかまたは超えるかを決定すべく、関連付けられたサービスラッパによって提供されるサービスメトリックを調べてよい。いくつかの実施形態において、プラットフォーム３００は、これらの決定の各々を通じて、サービスの利用可能なセットを、ユーザ要求を満足させるより小さいサブセットに漸進的にフィルタして、最終的に、ユーザによって要求されるサービス基準をすべて満足させるサービスのフィルタされたセットに達する。さらに他の実施形態において、ユーザからの要求は、考慮するためのサービスのセット、またはサービスのセットが識別されることが可能な１つ以上の特性／基準を識別してよい。プラットフォームは、サービスの識別されたセットのサービスメトリックを、それらのサービスが、ユーザによって要求されるサービス基準を満足させるかどうかを決定すべく、最初に（または、いくつかの実施形態において、優先的に、もしくは排他的に）分析してよい。サービスが顧客のユーザ要件を満たすことを確認するプロセスは、サービスの検証、またはユーザクエリに対するサービスパフォーマンスの検証であると一般に理解されてよい。

【0053】

いくつかの実施形態において、プラットフォームは、フィルタされたサブセットの中に、そのサービスによって提供されるデータが依然としてユーザの使用に役立つことが可能であるように、サービス特性／サービスレベルが要求されるレベルに近い、または所定の度合の差の範囲内にあるサービス３１０を含んでもよい。この実施形態は、ユーザの要求が広く制限的であり、および／もしくはユーザによって要求されるタイプのデータを提供するサービスが比較的少数しか存在しない場合、またはユーザが、さもなければ、理想的なサービスを見出すことができない可能性がある場合（いくつかの実施形態において、厳密な、または理想的なマッチが見出される可能性があるものの）、最も役立つことが可能である。さらに他の実施形態において、プラットフォームは、考慮されるサービスのうちのいずれが、ユーザによって要求される基準に最も近いか、または最も差が小さいかを決定すべく、見込みのあるそれぞれのサービスをユーザによって要求されるサービス基準にマップして、サービスの差が大きくなる度合に基づいて、サービスを差別化する（例えば、格付け、グループ化、範囲設定された値比較、または以上に類するものを通じて）サービスの探索を実行してよい。

【0054】

次に、プラットフォーム３００は、ユーザ要求に応答して、サービスのフィルタされたセットからサービス３１０を選択してよく、ユーザに接続情報を提供してよく、またはそのサービスにユーザをリダイレクトしてよい（ステップ４１０）。いくつかの実施形態において、プラットフォームは、ユーザ要求によって指定された基準を満たす（または基準に十分に近いところに来る）ことをプラットフォームが見出す最初のサービスを選択してよい。そのような実施形態は、発見プロセスが、最初にマッチするサービスが見出された後、停止してよいので、プラットフォームのサービス発見プロセスが、計算的に、制約されている、または時間的に制約されているという場合、特に役立つ可能性がある。他の実施形態において、プラットフォームは、ユーザ要求において指定された基準を満たすサービスのセットのなかから、例えば、最良のパフォーマンス、最良の速度、データの最良の粒度、または別の適切な尺度を有する「最良」のサービスであるサービスを選択してよい。さらに他の実施形態において、プラットフォーム３００は、ユーザ要求の基準を満たす（または十分に近いところに来る）サービスのセットを分析してよく、「最良マッチ」を見出すべく、任意の数のヒューリスティクスまたは尺度に基づいて、その基準に近いサービスを選択してよい。例えば、最良マッチ選択は、サービスの特性とユーザ要求の特性の間の類似性に基づくスコアの割当てを含んでよい。別の代替の実施形態において、プラットフォームによるサービスの選択は、ランダム化されてよく、関係のある基準を満たすサービスの間でラウンドロビン様態で適用されてよく、１つ以上の基準（例えば、利用可能な計算時間が最も多いこと、応答が最も迅速であること、最も安価であること、その他）に基づいて選択されてよく、または他の任意の適切な方法に基づいて選択されてよい。また、プラットフォーム３００は、適宜、上の技法の組合せまたはサブセットを適用してもよい（例えば、さもなければ、同等に「最良」マッチするサービスのうちで最も迅速である）。いくつかのそのような実施例は、ユーザが同じサービスに後に接続されることが可能であるように、サービススコアおよび／または「最良マッチ」を、プラットフォーム３００がアクセスできるメモリ内のユーザを識別するために十分な情報（ＩＤ、ログイン／パスワード、およびＩＰアドレス、ＭＡＣアドレス、もしくは他の固有のハードウェアＩＤ、または以上に類するもの）に関連付けることを含んでよい。選択の後、プラットフォーム３００は、そのサービス（またはサービスラッパ）に関する標準化された接続情報をユーザに配信してよく（ステップ４２０）、次に、ユーザをサービス／サービスラッパにセキュアに接続し（または接続情報をユーザに供給し）、その接続上でサービスからユーザにデータを配信してよい（ステップ４２２）。

【0055】

代替のシナリオにおいて、プラットフォーム３００は、サービス自体を選択するのではなく、すべての利用可能なサービスオプション（または利用可能なサービスオプションのサブセット）をユーザに（例えば、サービスの能力およびパフォーマンスについてのメタデータを有するリストとして）提示し、ユーザが、提供されるオプションに関して適切な、または所望されるサービスを選択することを可能にしてよい（ステップ４１２、４１４）。そのような実施形態は、例えば、利用可能なサービスのいずれも、パフォーマンスのユーザによって要求される標準を満たさない場合、またはオプションの間でユーザ要件と比較した欠点が比較的同等である場合、最も役立つ可能性がある。

【0056】

例示的な実施形態において、選択されたサービスがどういうわけか利用不能になる事例において、プラットフォームは、サービスが検証要件をもはや満たさないと決定し、プラットフォームは、障害を自動的に検出し、またはいくつかの事例において、サービス（またはサービスプロバイダ）が、規格の所望されるセット、または公共の、もしくは公開されたセットをもはや満たさない場合、サービスプロバイダから、もしくはいくつかの実施形態においてユーザから、そのような変更の通知を受信する（ステップ４２４）。利用不能であることは、例えば、機械的なエラー（例えば、センサもしくは他のハードウェアの障害もしくは信頼性の欠如）、またはデータ転送のレイテンシ、サービスプロバイダの認定が失われたこと、または他の任意の関係のある理由によることが可能である。利用不能であることに気付くと、プラットフォーム３００は、ユーザによるプロンプトなしに、同じ（または十分に類似した）クエリされたサービス特性を満たす、またはそれらの特性を超える代わりのサービスを探索し、見出してよい（ステップ４２６および４２８）。他の実施形態において、プラットフォーム３００は、ユーザプロンプト／要求に応答してそのようなアクションを行ってよい。

【0057】

その後、プラットフォーム３００は、ユーザを代わりのサービスに接続することを始める（ステップ４３０）。サービスプロバイダのこの変更は、例示的な実施形態において、元のサービスと代わりの選択されたサービスに関する接続プロトコル、およびインターフェースのポイントが同一であるので、ユーザに不可視（またはほぼ不可視）であってよい。代替として、プラットフォーム３００は、変更をユーザ３８０に通知してよく、またはいくつかの事例において、代わりのサービスに切り換える許可を提供するクエリをユーザ３８０に伝送してよい。許可を求めることは、代わりのサービスが、パフォーマンス、提供されるデータのスコープ、および／またはコストなどの、ユーザが気付くことが可能な区域において実質的に異なる状況において最も有益であることが可能である。

【0058】

合計１００のサービス３１０がプラットフォーム３００を通じて利用可能な１つの説明的な例として、ユーザが、米国の南西部の範囲内の予測的な気象データを要求することができる。プラットフォーム３００は、１００のサービスのうちのいずれが予測的な気象データを供給することができるかを決定すべく、合計１００のサービスの各々にそれぞれ関連付けられた１００のサービスラッパからメタデータを獲得してよい。例示的な目的で、それら合計１００のサービスのうちの１０のサービスがそのようなデータを提供する場合、プラットフォーム３００は、１０のサービスに対するユーザのクエリに応答してサービスのセットをフィルタしてよい。次に、それら１０のサービスのうち、プラットフォーム３００は、いずれのサービスが米国の南西部に地域的であるデータを提供するかを考慮してよい。例示の目的で、１つのサービスが、地球規模の地域にわたる予測的な気象データを提供し、２つのサービスが、米国について包括的である予測的な気象データを提供し、１つのサービスが、米国南西部に特有である予測的な気象データを提供する場合（残りの５つのサービスが、米国南西部に関するデータを提供しない場合）、プラットフォーム３００は、元の１００のサービスのうち、ユーザの要求を満足させる５つのサービスを見出している。次に、プラットフォームは、それら５つのサービスのうちの１つ、例えば、米国南西部に特有の予測的な気象データを提供するサービスを、それが、ユーザの要求に最も近く、「最良マッチ」とみなされてよいので、選択してよい。次に、プラットフォーム３００は、ユーザと選択されたサービスの間の関連付けを（メモリに）記憶してよく、ユーザを、選択されたサービスをカプセル化するサービスラッパに接続してよい。例えば、プラットフォーム３００は、サービスラッパに接続する接続ポートをユーザに提供してよい。後の時点で、選択されたサービスが利用不能になった場合、すると、プラットフォーム３００は、ユーザの要求を満足させる５つのサービスのうちの別のサービス、例えば、米国について包括的である予測的な気象データを提供するサービスを選択してよく、ユーザと新たに選択されたサービスの間の関連付けを格納しよい。プラットフォームは、更新された接続ポートをユーザに提供する必要はない；むしろ、新たなサービスに対する再構成がユーザに不可視であるように、各サービスラッパに関する接続情報が標準化される。これは、無論、１つの例示的な実施例に過ぎず、実装の他の方法が、異なる実施形態において可能であってよい。

【0059】

図４の例示的な方法によって見て取ることが可能であるとおり、プラットフォーム３００は、航空交通管理サービス（およびそれらをサポートするサービス）を、サービスのそれぞれのソースにではなく、それらの能力に匿名化する（または比較的匿名化する）。満足されることをエンドユーザが所望する、或る数量のサービス基準を、エンドユーザは選択してよい。プラットフォームは、ユーザによって提供される要件を満足するサービス（またはサービスのグループもしくはセット）を見出し、見出されたサービスからの選択を可能にする十分なロジックを収容する。すなわち、例示的な実施形態において、例えば、気象サービスを求める組織またはユーザが、特定の気象サービスまたは気象プロバイダをより好まない可能性があり、代わりに、要求されるサービス能力またはサービス境界のセットをプラットフォームに単に提供することが可能である。これらは、一実施形態において、応答の速度、帯域幅量、またはコストなどの情報を含んでよい。例として、追跡サービスが、名前の認知、または制度的な優先に関してではなく、とりわけ、追跡が実行される距離、帯域幅、および／または価格に関して他の追跡サービスと競争することが可能である。

【0060】

いくつかの実施形態において、特定のバンドルされたサービス２５０が、高い帯域幅と低いレイテンシ、高い完全性、ならびに／またはセキュリティおよび／もしくは可用性に関する信頼できる標準などの標準を設定するために機能するデータソースおよび／または補助的サービスを要求することが可能である。したがって、プラットフォーム３００は、いくつかの事例において、提供されるサービスのパフォーマンス標準に完全に、または部分的に基づいてサービスプロバイダを選択してよい。このことは、各ルーティング決定が、複数のサービスの間で分散された計算および調整を含むことが可能な、またはリアルタイムのデータが必要とされる（例えば、衝突検出のために）サービス２５０に関して特に重要である。

【0061】

いくつかの実施形態において、プラットフォームによって達成された匿名化の結果、サービスプロバイダは、サービスプロバイダのサービスのデータの最終的な受取人についての情報を有さないことが可能であり、したがって、サービスプロバイダは、特定の顧客、または特定のタイプの航空機を（例えば、サービスの品質または速度を通じて）より好むことができない。したがって、アクセスの比較的な公平性が、任意の特定のサービスタイプに関して異なる乗り物に提供される。

【0062】

図３Ａに再び転じると、プラットフォーム３００上のデータの処理が、１つ以上のプロセッサ３４０を介して実装されることが可能である。プロセッサ３４０は、中央処理装置（ＣＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）、グラフィックスプロセッシングユニット（ＧＰＵ）、ＦＰＧＡ、ＡＳＩＣ、もしくは他のタイプの処理ハードウェアのうちのいずれか、または以上の任意の組合せを含んでよい。さらに、プロセッサ３４０は、より速い処理速度および／または冗長性を提供すべく任意の数の処理装置を含んでよく、そのようなプロセッサは、ローカルである、もしくは地理的に分散させられる、または以上の任意の組合せである。また、プラットフォーム３００は、図３Ａに共有されるデータリポジトリ３２５および３２７として示され、図３Ｂにデータベース３７２および３７４として示される、１つ以上の共有されるメモリまたはデータリポジトリにアクセスできてよい。そのようなデータベースリポジトリ／データベースは、例えば、キャッシュ、データベース、他のデータ構造、または任意の適切なタイプのリポジトリであってよい。メモリ３２５、２３７、３７２、３７４は、プロセッサ３４０によってアクセス可能である情報を記憶する、揮発性および不揮発性の任意の適切な記憶媒体（例えば、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＳＲＡＭ、フラッシュメモリ、ディスクもしくは光ストレージ、磁気ストレージ、または他の任意の有形もしくは非一時的媒体）であってよい。いくつかの事例において、メモリ３２５、３２７の両方またはサブセットが、生命の安全認定（ｓａｆｅｔｙ－ｏｆ－ｌｉｆｅ ｃｅｒｔｉｆｉｅｄ）されてよいが、とはいえ、他の構成が他の実施形態において可能である。さらに、メモリ３２５、３２７、３７２、３７４のうちの１つ以上が、プラットフォーム３００の機能を実施するための命令またはロジックを記憶してよく、このロジックは、ハードウェアで、ソフトウェアで、ファームウェアで、または以上の任意の組合せで実装されてよい。さらに、ネットワークインターフェース３５５（例えば、ポートまたはピン）が、プラットフォーム３００の構成要素を他のコンピューティング構成要素またはシステムにインターフェースしてよい。

【0063】

リスク評価サービスが、そのリスク評価を追跡データに基づいて更新することを所望することが可能な例示的な実施形態が、図３Ｂを参照して説明される。リスク評価サービスは、プラットフォーム３００にクエリをサブミットしてよい。プラットフォーム３００は、クエリにおいて示されるサービス要件を満たす追跡サービスを提示するサービスプロバイダを見出してよく（例えば、メモリに記憶されたデータの参照により、または１つ以上のサービスラッパに対するクエリにより）、リスク評価サービスを、追跡サービスの（１つ以上のＡＰＩを含んでよい）サービス間インターフェース３６４にルーティングしてよい。別の実施形態において、プラットフォーム３００は、データベース３７２（例えば、共有されるキャッシュであってよい）に追跡データを格納してよい。プラットフォームは、リスク評価サービスに対する要求があったとき、プラットフォームインターフェース３６６を介してサービスラッパ３０２からの追跡データにアクセスしてよく、追跡データを共有されるキャッシュ３７２に格納してよい。次に、プラットフォーム３００は、共有されるキャッシュ３７２に対するアクセスをリスク評価サービスに提供してよい。そのような実施形態は、データがセーフティクリティカルであり、認定標準を満たすデータリポジトリに格納される必要があり得るとき、特に役立つ可能性がある。

【0064】

より詳細には、いくつかのサービス、およびそれらの間の通信は、それらが飛行の安全にどれだけクリティカルであるかに依存するさらなる要件を有する。例えば、航空機追跡サービスが、提供されるデータの精度およびセキュリティ、サービスの可用性、応答の速度、および／または規定される誤差限界に関する要件を有してよい。その追跡サービスと交通管理サーバの間の通信チャネルは、送信中のデータのセキュリティ、利用可能な帯域幅、およびチャネルの可用性、その他に関する要件を有してよい。通常、極めてクリティカルなシステム（またはそれをサポートするデータ）を扱う仕事をしているサービスプロバイダは、サービスプロバイダのサービスのためのライセンスを獲得するために規制または認定の対象となることが可能である。規制機関は、サービスが満足のいく様態で実装される（例えば、空域およびポリシーについての配慮の機能を維持しながら）ことを確実にする要件を設定してよく、そのような実装を監査してよい。これらの要件は、サービスのセキュリティおよび信頼性に影響を及ぼし、したがって、飛行中の乗り物およびその中で空輸されている人々および財産の安全に直接影響を与える。また、ライセンス交付が、クリティカルなサービスが、他のサービス事例と正しく、信頼できるように相互運用されることが可能であることを確実にするために必要とされてもよい。

【0065】

サービスラッパが、プラットフォーム３００と一緒に、認定および／または規制上の要件が満たされることを確実にするように機能してもよい。例えば、バンドルされたサービス２５０（図２Ｂ）のためのラッパ３０２が、バンドルされたサブサービス２１２のすべてに関するそれぞれのラッパが行うのと同じ検証、構成、およびパフォーマンス標準を施行してよい。一実施形態において、プラットフォーム３００は、認定可能であるまとまりのあるバンドルされたサービスを形成すべく、或る範囲のサービスプロバイダから、既に認定されたサービスをインテリジェントに選択してよい。他の実施形態において、ラッパ３０２は、マイクロサービスの登録および識別を通じて、個々のサービスの準拠および／または認証を維持してよい。例えば、ラッパ３０２は、セーフティクリティカルなサービスが、例えば、検証、情報、監査、施行、その他を担当する当事者と接触する方法を提供することを実施してよい。したがって、プラットフォーム３００のインテリジェンスとラッパ３０２の施行は、バンドルされた航空交通管理サービスのパフォーマンスおよび認定可能な態様を維持するように一緒に機能してよい。いずれのシナリオにおいても、例示的な実施形態において、バンドルされたサービス２５０は、全体として安全認定されてよい。

【0066】

別の実施形態において、セーフティクリティカルなサービスのための生のデータまたは補助的なデータを提供するサービスは、それら自体、セーフティクリティカルでない可能性がある。しかし、そのような実施形態において、プラットフォーム３００自体、セーフティクリティカルであると認定可能であってよく、ラッパ３０２は、認定されないサービスからのデータが、それでも、セーフティクリティカル認定標準を満たすために十分であることを確実にしてよい。例えば、プラットフォーム３００が、１つ以上のセーフティクリティカルなデータストア（例えば、メモリ３２５）、および／または関連するシステム上を通信するための１つ以上の適切な暗号標準を維持してよい。いくつかの実施形態において、プラットフォーム３００は、データストア、ならびにローカルおよびネットワークインターフェースを、それらのパフォーマンス、セキュリティ、および以上に類するものを制御すべく、抽象化して管理してよい。

【0067】

セーフティクリティカルな航空データ（すなわち、地理空間データ）に特有であるデータおよび通信抽象化を維持することによって、データがＵＴＭプラットフォームを通過する際にセーフティクリティカル認定が失われることがない。これらの手段によって、プラットフォーム３００およびラッパ３０２は、従来のクラウドベースのインフラストラクチャのものを超えるセーフティクリティカル機能を提供する。したがって、分散されたエンドツーエンド準拠が維持されることが可能である。

【0068】

いくつかの事例において、プラットフォーム３００は、データソースからのデータの受け渡し記録の管理を維持するように機能してよく、それにより、データが、それほどセキュアでない、または信頼できないネットワーク上で伝送されている可能性がある場合でさえ、データの真正性および／または正確性を確実にする。より詳細には、いくつかの実施形態は、データのソースが信頼できること、および収集されたデータが正確であることを認証すべく、特定のデータ（センサデータなどの）を収集するハードウェアデバイスに関連付けられた暗号鍵または署名の使用を含んでよい。プラットフォーム３００は、いくつかの実施形態において、鍵または署名を、プラットフォーム３００のコンピュータシステムを通るデータの動きのすべてのポイントでデータに関連付けることを続けてよい。このデータは、必ずしもセーフティクリティカルであると認定される必要はない、１つ以上のデータストア（例えば、メモリ３２７）に記憶されてよい。鍵または署名が変更されないままであること、またはそうでなければ、それらの元の署名を収容することを検証することによって、プラットフォーム３００は、（例えば、ソフトウェアもしくはシステム障害、または予期せぬイベントを通じて）データが改ざんされていないこと、許可なしに変更されていないこと、またはそうでなければ、改められていないことを確かめてよく、（すなわち、プラットフォーム３００は、データの完全性が維持されていることを確実にする。いくつかの実施形態において、サービスラッパ３０２の検証されたインターフェース３６６（図３Ｂ）が、データの妥当性確認または検証を実行するように機能して、サービスが、そうすると称する、データのタイプ、フォーマット、および標準を提供することを確実にしてよい。さらに、いくつかの実施形態において、検証されたインターフェース３６６は、精度（例えば、提供されるデータが収まる誤差限界）および／またはパフォーマンス（例えば、データが提供される速度／帯域幅／レイテンシ）に関する標準を施行してよい。例示的な実施形態において、プラットフォーム３００を運用するため、サービスプロバイダは、いくつかのデータ標準およびパフォーマンス標準に準拠することに同意するものと理解されてよい。サービスラッパ３０２は、その妥当性確認および検証インターフェースを通じて、データの品質、および要求されるプラットフォーム標準に対するデータの準拠を測定する。

【0069】

以上は、本開示の原理を例示するものに過ぎず、様々な変形形態が、本開示の範囲を逸脱することなく、当業者によって作成されることが可能である。上で説明された実施形態は、限定するためではなく、例示するために提示される。また、本開示は、本明細書において明示的に説明される以外の多くの形態をとることも可能である。したがって、本開示は、明示的に開示される方法、システム、および装置に限定されるのではなく、特許請求の範囲の趣旨に含まれる、それらの様々な変更形態および変形形態を含むことが意図されることが強調される。

【0070】

さらなる例として、本明細書において示され、説明される、提供される構造、デバイス、および方法をさらに最適化すべく、装置またはプロセスパラメータ（例えば、寸法、構成、構成要素、プロセスステップ順序、その他）の変形形態が行われてよい。いずれにしても、本明細書において説明される、構造およびデバイス、ならびに関連付けられた方法は、多くの用途を有する。したがって、開示される主題は、本明細書において説明されるいずれの単一の実施形態にも限定されるべきではなく、むしろ、添付の特許請求の範囲による広さおよび範囲において解釈されなければならない。

【図1A】

【図1B】

【図2A】

【図2B】

【図3A】

【図3B】

【図4】