(57)【要約】  本明細書に記述されたソリューションは、そのユニークな設計により、指揮統制、状況認識、運用管理などの機能および他の戦術的機能を、特定の戦略的あるいは戦術的ソリューションを構築する目的で追加または拡張される構築ブロックとして提供する。戦略的または戦術的システムを実施するための従来の手法は歴史的に排他的であり、クローズドアーキテクチャに基づいて構築されてきた。このソリューションは、新しいシステムとレガシーシステムとの両方に容易に統合できるようにするために、オープン規格とオープンインターフェースとを使用して設計される。【選択図】図３
2014531635.tif 000002
【特許請求の範囲】
【請求項１】
プレゼンテーション層にカスタマイズ可能なユーザインターフェースを提供するための方法において、
第１のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して第１のプレゼンテーションサービスをダイナミック・サービス・レジストリに登録することと、
前記ダイナミック・サービス・レジストリに登録された前記第１のプレゼンテーションサービスを使用して第１のデータモデルから取得した第１のデータの第１の視覚化をユーザに提示することと、
を含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、
第２のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して第２のプレゼンテーションサービスを前記ダイナミック・サービス・レジストリに登録することと、
前記ダイナミック・サービス・レジストリに登録された前記第２のプレゼンテーションサービスを使用して第２のデータモデルから取得した第２のデータの第２の視覚化を前記ユーザに提示することと、
をさらに含むことを特徴とする方法。
【請求項３】
請求項２に記載の方法において、
前記第２のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を削除することによって前記ダイナミック・サービス・レジストリから前記第２のインフラストラクチャサービスを削除すること、
をさらに含むことを特徴とする方法。
【請求項４】
請求項１に記載の方法において、
第３のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して第１のインフラストラクチャサービスを前記ダイナミック・サービス・レジストリに登録することと、
前記第１のデータモデルに前記第１のインフラストラクチャサービスからのデータを入力することと、
をさらに含むことを特徴とする方法。
【請求項５】
請求項４に記載の方法において、
第４のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して第２のインフラストラクチャサービスを前記ダイナミック・サービス・レジストリに登録することと、
第２のデータモデルに前記第２のインフラストラクチャサービスからのデータを入力することと、
をさらに含むことを特徴とする方法。
【請求項６】
請求項１に記載の方法において、
前記第１のデータモデルが第２のデータを含み、
前記ユーザが、前記第２のデータを前記第１の視覚化の前記提示から選択的に非表示にする
ことを特徴とする方法。
【請求項７】
プレゼンテーション層にカスタマイズ可能なユーザインターフェースを提供するための装置において、
第１のデータモデルからユーザに第１のデータの第１の視覚化を提示する第１の登録済み提示サービスと、
第１のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して前記第１の登録済み提示サービスを登録するダイナミック・サービス・レジストリと、
を備えることを特徴とする装置。
【請求項８】
請求項７に記載の装置において、
第２のデータモデルから取得した第２のデータの第２の視覚化をユーザに提示する第２の登録済み提示サービスと、
第２のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して前記第２の登録済み提示サービスを登録するダイナミック・サービス・レジストリと、
をさらに含むことを特徴とする装置。
【請求項９】
カスタマイズ可能なユーザインターフェースを有するプレゼンテーション層を提供するための装置において、
第１のデータモデルから取得した第１のデータの第１の視覚化をユーザに提示するための第１の手段と、
第１のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して前記第１の手段を登録するための第２の手段と、
を備えることを特徴とする装置。
【請求項１０】
第１のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して、コンピュータに、第１のプレゼンテーションサービスをダイナミック・サービス・レジストリに登録させるためのコードと、
前記ダイナミック・サービス・レジストリに登録された前記第１のプレゼンテーションサービスを使用して、コンピュータに、第１のデータモデルから取得した第１のデータの第１の視覚化をユーザに提示させるためのコードと、
を含むコンピュータ可読記憶媒体
を含むことを特徴とするコンピュータプログラム製品。
【請求項１１】
請求項１０に記載のコンピュータプログラム製品において、
第２のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して、コンピュータに、第２のプレゼンテーションサービスをダイナミック・サービス・レジストリに登録させるためのコードと、
前記ダイナミック・サービス・レジストリに登録された前記第２のプレゼンテーションサービスを使用して、コンピュータに、第２のデータモデルから取得した第２のデータの第２の視覚化を前記ユーザに提示させるためのコードと、
をさらに含むことを特徴とするコンピュータプログラム製品。
【請求項１２】
請求項１１に記載のコンピュータプログラム製品において、
前記第２のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を削除することによってコンピュータに前記ダイナミック・サービス・レジストリから前記第２のインフラストラクチャサービスを削除させるためのコード
をさらに含むことを特徴とするコンピュータプログラム製品。
【請求項１３】
請求項１０に記載のコンピュータプログラム製品において、
第３のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して、コンピュータに、第１のインフラストラクチャサービスを前記ダイナミック・サービス・レジストリに登録させるためのコードと、
コンピュータに、前記第１のインフラストラクチャサービスからのデータを前記第１のデータモデルへと入力させるためのコードと、
をさらに含むことを特徴とするコンピュータプログラム製品。
【請求項１４】
請求項１３に記載のコンピュータプログラム製品において、
第４のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して、コンピュータに、第２のインフラストラクチャサービスを前記ダイナミック・サービス・レジストリに登録させるためのコードと、
コンピュータに、前記第２のインフラストラクチャサービスからのデータを第２のデータモデルへと入力させるためのコードと、
をさらに含むことを特徴とするコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本開示は、２０１１年８月２９日に出願された米国仮出願番号第６１／５２８，３０２号の便益を要求するものであり、同出願は、参照により本明細書に援用される。
【０００２】
本発明は、分散して存在する異質システムを管理するための方法と装置とに関するものであり、特に、上記システムの指揮統制、状況認識、運用管理および他の機能のためのフレームワークを実現する方法と装置とに関するものである。
【背景技術】
【０００３】
現在展開されている管制部門管理システムは、軍事要件を満たすために、複雑なソリューションを提供してきた。提供されてきた機能は最新のものだが、かかるシステムの拡張を妨げる形で実装されてきた。この問題の根本は多面的だが、次に示す構造上および運用上の欠陥によってまとめることができる。
【０００４】
開放性と外在性に対する要件が定義されてこなかったため、地上管制部門と遠隔資産部門との間でのデータ層の連結が密接となり、排他的な独自のシステムを事実上生産してきた。
【０００５】
地上管制部門と、地上管制部門が制御しているシステムとの間でのインターフェース定義（ＩＣＤ）および仕様が流動的であることから、外部インターフェースを維持するのが極めて困難である。
【０００６】
このようなレガシーシステムには、外部ベンダーが既存のレガシーシステムに入札したりサポートしたりすることができないことが多いため、顧客には、現在のベンダーとの契約を継続する以外の選択肢がほとんど、あるいはまったくない。
【０００７】
特定のハードウェアで稼働することを目的としたソフトウェアは、システム全体の機能および拡張性を制限する。既存のシステムで機能を追加または改変することは不可能なので、顧客は異なるシステムで新機能を展開することになる。
【０００８】
開発業者がシステムのさまざまな部分の所有権をしっかりと握っていることに加え、開発に使用されてきた技術に柔軟性がないことから、レガシーインターフェースとの統合に多額の費用がかかる。
【０００９】
ユーザインターフェースが醜く、統一感もないため、任務を十分に遂行できず、効率も悪い。
【００１０】
検討不十分のトレーニングインフラストラクチャと雑然とした操作画面により、トレーニングが長引き、費用もかさむ。
【００１１】
複数の専用ハードウェアシステムおよびソフトウェアアプリケーションを提供するこの方法は、長期的に見ると、開発、展開、そしてサポートに多額の費用がかかることが判明した。このような傾向を緩和するために、最新のオープン規格に基づいて構築されたオープンで拡張可能なアーキテクチャの設計提案を、ロードマップを使用して概説する。
【発明の概要】
【００１２】
プレゼンテーション層にカスタマイズ可能なユーザインターフェースを提供するための方法に、本発明の一態様が存在し得る。この方法では、第１のプレゼンテーションサービスが、第１のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用してダイナミック・サービス・レジストリに登録される。ダイナミック・サービス・レジストリに登録された第１のデータモデルの第１のデータの第１の視覚化が、第１のプレゼンテーションサービスを使用してユーザに提示される。
【００１３】
本発明のさらに詳細な態様では、第２のプレゼンテーションサービスが、第２のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用してダイナミック・サービス・レジストリに登録され得る。ダイナミック・サービス・レジストリに登録された第２のプレゼンテーションサービスを使用して、第２のデータモデルの第２のデータの第２の視覚化がユーザに提示され得る。第２のインフラストラクチャサービスは、第２のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を削除することによってダイナミック・サービス・レジストリから削除され得る。
【００１４】
より詳細な本発明の他の態様では、第１のインフラストラクチャサービスが、第３のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用してダイナミック・サービス・レジストリに登録され得る。第１のデータモデルには、第１のインフラストラクチャサービスからのデータが入力され得る。さらに、第２のインフラストラクチャサービスが、第４のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用してダイナミック・サービス・レジストリに登録され得る。第２のデータモデルには、第２のインフラストラクチャサービスからのデータが入力され得る。第１のデータモデルは、第２のデータを含み得る。そしてユーザは、第２のデータを第１の視覚化の提示から選択的に非表示にし得る。
【００１５】
プレゼンテーション層にカスタマイズ可能なユーザインターフェースを提供するための装置に、第１のデータモデルからの第１のデータの第１の視覚化をユーザに提示する第１の登録済み提示サービスと、第１のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して第１の登録済み提示サービスを登録するダイナミック・サービス・レジストリと、を備える、本発明の別の態様が存在し得る。
【００１６】
プレゼンテーション層にカスタマイズ可能なユーザインターフェースを提供するための装置に、第１のデータモデルからの第１のデータの第１の視覚化をユーザに提示するための手段と、第１のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して第１の登録済み提示サービスを登録するための手段と、を備える、本発明の別の態様が存在し得る。
【００１７】
コンピュータプログラム製品に、第１のプラグイン・アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して、コンピュータに、第１のプレゼンテーションサービスをダイナミック・サービス・レジストリに登録させるためのコードと、ダイナミック・サービス・レジストリに登録された第１のプレゼンテーションサービスを使用して、コンピュータに、第１のデータモデルから取得した第１のデータの第１の視覚化をユーザに提示させるためのコードと、を備える非一時的なコンピュータ可読記憶媒体を備える、本発明の別の態様が存在し得る。
【図面の簡単な説明】
【００１８】
【図１】図１は、複数のトレーニングをサポートする複数の相互接続されたオープン・インターフェース・フレームワークから成るコアフレームワーク自体の概略を表す。
【図２】図２は、アプリケーションと、メッセンジャーモジュールおよびデータ処理モジュールとから成るインフラストラクチャフレームワークを表す。
【図３】図３はプレゼンテーションフレームワークを表す。
【図４】図４はプラグインフレームワークを表す。
【図５】図５は、アプリケーションからハードウェア通信を抽象化し、標準的なＳＯＡ方式によってそれらのインターフェースを露出させるように設計されているサービスおよびパッケージから成る通信フレームワークを表す。
【図６】図６は、トレーニング目的でのシステム規模のイベントの時間的制御、フィードバック、およびスクリプト記述を可能にするように設計されているパッケージおよびモジュールから成るトレーニングフレームワークを表す。
【発明を実施するための形態】
【００１９】
現在展開されている地上部門アーキテクチャが生来的に有する先述の欠陥に効果的に対処するために、本明細書における包括的ソリューションは、オープン規格を活用してオープンな拡張可能アーキテクチャを作成する。このアーキテクチャは、指揮統制（Ｃ２）、状況認識（ＳＡ）、および運用管理（ＯＭ）を１つの簡潔なソリューションにまとめる。このソリューションは、最大限の拡張性に加え、コンポーネントの追加または除去もできるようにするために、サービス指向アーキテクチャ（ＳＯＡ）パラダイムとプラグイン・アーキテクチャ・パラダイムとの混成として実装される。このプラグインとオープンインターフェースベースのアーキテクチャとを活用して、目標とする特定のアプリケーションを、わずかな開発労力で構築することができる。このシステムのユーザインターフェースは、オペレータに真の戦場認識と空域認識とを提供するために、４次元の地理空間的および時間的領域を活用すべきである。
【００２０】
この共通地上システムアーキテクチャ（ＣＧＳＡ）のソリューションは、汎用的に定義された遠隔資産の指揮統制（Ｃ２）、状況認識（ＳＡ）、および運用管理（ＯＭ）を遂行する能力を有するという考えの上に構築するべきである。
【００２１】
共通の地上部門アーキテクチャを手に入れるという目標を効果的に達成するために、このソリューションは、アプリケーションフレームワークに関するコア機能を、遠隔資産の受け渡しに関連する汎用的な運用機能（Ｃ２、ＳＡ、ＯＭ）から効果的に切り離すような方法で設計する必要がある。連結の緩いこの２つの層は、実装されると、特定のＵＡＳシステム、そのサブシステム、および関連する運用構想を統合するための基盤の働きをする。
【００２２】
さらに、先述のコア運用機能（Ｃ２、ＳＡ、ＯＭ）は、顧客特有のソリューションの具体的な要件を満たすために、他の業務アプリケーションを拡張、拡大、あるいは補完できる必要がある。このような理由から、このコアアーキテクチャにはオープンインターフェースを実装すべきであり、ＡＰＩにより、ユーザコミュニティがコアインフラストラクチャに準拠したオーダーメイドのソリューションを開発できるようにすべきである。中核的なデータモデリング、ユーティリティ、およびインフラストラクチャに直接アクセスするため、アプリケーションに際限がなく、拡張性が高い。
【００２３】
コアフレームワーク
現在展開されているシステムは非常に厳格であり、実質的な拡張性と構成可能性を見込んでいない。これらのシステムのインターフェースの改変しようとする場合、特にそのインターフェースに複数のシステムが関わっていると、多額の費用がかかる。機能および／またはシステムを追加するには、レガシーシステムおよびインターフェースに変更を加える必要があり、ひいてはすべての関連システムに影響が波及する。小さな変更の統合費用を理由に、細かい点が省略されたり、機能が省かれたりすることが多い。
【００２４】
柔軟で拡張性があり、構成の変更が可能なコアフレームワークを設計するという任務を引き受けるには、現在受容されている２つの構造的フレームワークの混成を伴うパラダイムシフトが必要である。まず、今日流通しているフレームワークの中でおそらく最も柔軟とされる、サービス指向アーキテクチャ（ＳＯＡ）を取り上げる。ＳＯＡは、コンポーネントおよびサービスの設計が流動的で常に変化することを想定しており、システムの外部のユーザへの影響がわずかないし皆無である。一言で言えば、最も柔軟性が高い。次に、互換性と拡張性を持つソフトウェアユニットを割り当て可能にすることによって拡張性と構成可能性に秀でたプラグインフレームワークを取り上げる。ＳＯＡシステムの柔軟性とプラグインシステムの拡張性および構成可能性を混成して、最大限の柔軟性、拡張性、および構成可能性を有する最適なソリューションに至る。
【００２５】
図１は、複数のトレーニングをサポートする複数の相互接続されたオープン・インターフェース・フレームワークから成るコア１００フレームワーク自体の概略を表す。記載のとおり、コアフレームワークは、アーキテクチャ全体の中で各々独自の重要な役割を持つ複数の目標フレームワークを収容するハウジングの働きをする。コアフレームワーク内に収容されたフレームワークは、インフラストラクチャフレームワークと、プレゼンテーションフレームワークと、プラグインフレームワークと、通信フレームワークと、トレーニングフレームワークと、を含む。
【００２６】
コンポーネントの内訳：
１０１−オープンインターフェースにより、あらゆるインフラストラクチャおよび通信から完全に分離されるように設計されたプレゼンテーションフレームワーク。
【００２７】
４００−研修場面で記録、再生、記述、および対話できるように設計されたトレーニングフレームワーク。
【００２８】
３００−コアフレームワークからハードウェアデバイスのＩ／Ｏを抽象化するように設計された通信フレームワークであり、オープン規格（ウェブサービスなど）を介して自らのインターフェースを露出させる。
【００２９】
２００−システム内で実行中の相互通信およびアプリケーションの中核。
【００３０】
インフラストラクチャフレームワーク
インフラストラクチャフレームワークは、広く使用およびサポートされているＪａｖａ  ＥＥ  ５．０＋完全準拠のオープン・ソース・スタックの上位に位置する必要がある。そして、システムのワークフローに影響を及ぼさずに機能を実装および解除できる必要がある。このインフラストラクチャは、オープンソース規格ならびにベストプラクティスを活用して、クライアントに影響を及ぼすことなく、常に増強および変化する機能群として構築される必要がある。
【００３１】
アプリケーション・サーバ・コンセプトは、高度にスケーラブルで管理のしやすいインフラストラクチャコアを想定している。アプリケーションサーバは、高度にスケーラブルで可搬性の高い管理下環境における業務プロセスのホストとしての働きをする。システム全体の展開に影響を及ぼすことなく、コンポーネントの展開または展開取り消しを簡単に行うことができ、すべての業務プロセスが、Ｊａｖａ開発規格によって設定されたオープン規格に準拠する。アプリケーションサーバは、データアクセス、ロードバランシング、フェールオーバ、クラスタリングなどを監視および制御する。レガシーシステムは、これらの機能をどのアプリケーションにも組み入れる必要があることが多いため、維持費が極端にかさみ、システムのスケーラビリティに大きく影響する。
【００３２】
このアプリケーションは、１つの一体型ワークステーションで展開したり、複数の異なるプラットフォームでクラスタ化および展開して、顧客要件に合わせたりすることができる。オープンソースのアプリケーションサーバは、開発環境で構成設定を少し変えるだけで、いとも簡単にこの機能を実現する。
【００３３】
アプリケーションサーバは、ＥＳＢ（エンタープライズ・サービス・バス）などのデータ変換バス、ＪＣＡ（Ｊａｖａ接続アーキテクチャ）、あるいはＤＤＳ（データ配信サービス）など先進のデータ・モデリング・フレームワークを使用して補完することができる。データバスを使用することは、システムを複数の異なるデータフィードと統合する上で極めて重要である。データバスは、インフラストラクチャと外部インターフェース間の変換層となるように設計されている。このようなバスを使用する利点は、大半のケースで、開発者が新しいインターフェースあるいはレガシーインターフェースに統合するのに１行のコード行も書かずに済ませるビルトイン・サービス・ユニットを格納しているということである。構成ファイルを使用すれば、外部システムに接続するのに費用も時間もかからない。
【００３４】
データモデルおよびデータ配信は、インフラストラクチャを通過するメッセージングの核心である。このアーキテクチャは、多様なデータ配信技法をサポートしており、柔軟で構成可能なデータフローのために、すべてが同じパプリッシュ／サブスクライブパラダイムを使用する。広く用いられている２つのデータ配信メカニズムがＪＭＳおよびＤＤＳであり、ともにこのインフラストラクチャでサポートされている。ＪＭＳは、このインフラストラクチャを、非常に広く使用されているこの規格にも準拠した任意のシステムに簡単に統合できるオープン規格である。ＤＤＳは、ＪＭＳのようなイベントベースのモデルではなく、データ中心のモデルに特化した堅牢なリアルタイムデータ配信メカニズムである。
【００３５】
このインフラストラクチャの中核にあるのが、コア・データ・モデルである。排他的なＳＯＡシステムにならないようにするには、すべてがオープンで拡張性を持つ必要があり、中でも大切なことは、データモデルである。データモデルは、極論すれば、クライアントが従う契約である。このインフラストラクチャフレームワークにより、コア・データ・モデルを定義することができ、その後、顧客が適合すると判断すれば拡張することができる。コア・データ・モデルにより、インターフェースは異なるがよく似たデータを有する外部インターフェースを１つのグローバルモデルとして表すことができる。拡張可能なこれらのコア・データ・モデルの利点は非常に大きい。外部インターフェースが変わっても、システムの残り部分をこのシステムと仲介させるために変更する必要がない。データモデルは変わるが、インターフェースは変わらない。ソフトウェアシステムが、進化と微調整を絶えず繰り返しているインターフェースであることから、これは莫大なコストの節約となる。アプリケーションをこれらの変更に対応させていくのに構成ファイルを変更する必要がなく、ソフトウェアも不要である。
【００３６】
コンポーネントの内訳：
２００−任意の数のアプリケーションサーバ、メッセージングバス、変換サービス、およびデータベースサービスから成り得るインフラストラクチャフレームワーク。
【００３７】
２０１−戦術的なデータフローをサポートするために必要な基底データ翻訳、メッセージング、およびドメイン不問のコアサービスのすべてを格納するための戦術的コアサービス。
【００３８】
２０２−戦術的領域サービスは、より高水準のアプリケーションのためのフレームワークとして必要とされるドメイン固有のサービスのすべてを含む。
【００３９】
２０３−戦術的アプリケーションサービスは、戦術的コアおよびドメインサービスの上位に構築された第１のアクティブな水準のアプリケーション一式である。このアプリケーションは、コアサービスとドメインサービスとを使用して、戦術的タスクを遂行する。
【００４０】
２０４−ＪＭＳやＤＤＳなど、モジュール間通信ならびに外部モジュール通信とデータモデル管理とを可能にするエンタープライズ・メッセージング・バス。メッセージングバスは、対応する任意のメッセージングシステムとの間で実装／解除することができる。
【００４１】
２０６−データベースインタラクションを業務プロセスから抽象化するように設計されたパーシステンスフレームワーク。Ｈｉｂｅｒｎａｔｅなどの標準フレームワークを使用して、さらに抽象化することができる。
【００４２】
２０７−任意のデータベース（ＳＱＬ、ＤＥＲＢＹ、ＯＲＡＣＬＥなど）内に格納された永続データ。
【００４３】
２０８−データモデル。すべてのモジュールおよびシステムタイプの共通コア・データ・モデル。すべての外部エンティティおよび／または資産データがこれらのデータモデルに変換されてシステム内で回送されるため、外部インターフェースが変わっても、データモデルは１か所で更新するだけでよい。
【００４４】
２０９−外部エンティティに命令または信号を送るとともに、それらのエンティティからの返答を受信するための標準的なワークフローを抽象化するように設計されたコア指揮統制フレームワーク。
【００４５】
２０９−１−システム内のすべてのサービスおよびアプリケーションが使用するサービスレジストリ内に登録されるＡＰＩ。
【００４６】
２１０−任意の定義済みワークフロー処理に統合可能な戦術的コアサービス用のサードパーティ製サービスリポジトリ。
【００４７】
２１１−インフラストラクチャ・サービス・フレームワークの核心。すべての既存サービスのレジストリを維持するとともに、サービス間でサービスリクエストを配信するダイナミック・サービス・レジストリ（ＯＳＧｉなど）。
【００４８】
２１２〜２１４−アプリケーション・サーバ・コンテナ内で実行されるドメインサービス例。具体例として、運用管理、荷重管理、物流管理、ならびにサービスレジストリ内に登録されているそれらの対応ＡＰＩなどがある。
【００４９】
２１５−サービスレジストリに登録されるとともに、すべてのサービスがアクセスするウェブサービスベースの技術によって露出される戦術的コアサービスのＡＰＩ。
【００５０】
２１６−サービスレジストリに登録されるとともに、すべてのサービスがアクセスするウェブサービスベースの技術によって露出される戦術的ドメインサービスのＡＰＩ。
【００５１】
２１７−サービスレジストリに登録されるとともに、すべてのサービスがアクセスするウェブサービスベースの技術によって露出される戦術的アプリケーションサービスのＡＰＩ。
【００５２】
２１８〜２２０−戦術的アプリケーション層内で実行される戦術的アプリケーションおよびサービスの例。具体例として、タスク管理およびコラボレーション管理、ならびにサービスレジストリ内で登録されるそれらの対応ＡＰＩなどがある。
【００５３】
２２１−外部エンティティ−インフラストラクチャフレームワークからデータをプッシュ、プル、および受け取る外部エンティティ。これらのエンティティは、リンク１６などの典型的な標準インターフェース、ならびに航空機資産など、インフラストラクチャフレームワークを介して直接制御されるエンティティである。
【００５４】
２２２〜２２４−追加処理または視覚化のためにインフラストラクチャのデータコンテンツを活用する外部エンティティ。典型的な例は、データコンテンツを視覚化するプレゼンテーション層であろう。
【００５５】
２２５−サービスレジストリ通信。レジストリ内に登録されているサービスを登録、ルックアップ、および直接タスク処理するための標準的なオープン通信。
【００５６】
２２６−データモデル管理サービスをパプリッシュまたはサブスクライブするためのデータモデル／データバス通信。
【００５７】
２２７−ウェブサービスベースのオープンプロトコルならびにサービス・レジストリ・プロトコルを使用したパッケージ間通信。
【００５８】
使用事例：
２０９外部エンティティから受信データを受け取る。
【００５９】
１．標準リンク（リンク１６）を介してデータが受け取られる。
【００６０】
２．データがソリューション・データ・モデル・フォーマット２０４に変換される。
【００６１】
３．データが２０４エンタープライズ・メッセージング・システムに渡され、適切なエンティティに送られる。
【００６２】
４．２０６データベースサービスが受信２０４データを受け取り、２０６必要に応じて永続し、２２６新たなデータ変更についてシステムにアラートする。
【００６３】
５．２０２〜２０３  サブスクライブされたエンタープライズアプリケーションがデータとプロセスとを受け取る。
【００６４】
プレゼンテーションフレームワーク
アプリケーション・プレゼンテーション・フレームワークは、広く使用およびサポートされている複数のオープンソースのプレゼンテーション技術であるＮＡＳＡ  ＷｏｒｌｄＷｉｎｄ  ＪａｖａおよびＪａｖａ  ＦＸに基づかないで構築されている。プレゼンテーションフレームワークは、層管理コンポーネント、サービス層コンポーネント、データモデル管理およびプラグイン管理フレームワークから成る。
【００６５】
オープンソースのＪａｖａ  Ｗｏｒｌｄ  Ｗｉｎｄコア機能の上位に構築することにより、高度にカスタマイズ可能なユーザインターフェースを実現するための層管理フレームワークを実装した。これにより、煩雑性が軽減され、ユーザが必要なデータだけを参照できるようになる。層管理コンポーネントにより、ユーザは、選択した任意のアイテムを選択的に表示／非表示化することができる。
【００６６】
プレゼンテーション層は、どの単一インフラストラクチャからも完全に分離されている。プレゼンテーション層はオープンインターフェース（サービス、ＪＭＳ、ＤＤＳなど）を介して外部システムに接続し、接続先に応じてそのローカル・データ・モデルにデータを入力する。サービスコンポーネントは、オープンコントラクト（ＷＳＤＬ、ＪＭＳ、ＸＭＬ）を使用して、プレゼンテーション層を速やかにレガシーインフラストラクチャに統合できるインフラストラクチャ、あるいは現在のプレゼンテーションシステムを拡大する目的で使用されるインフラストラクチャと通信する。これにより、顧客は１つのプレゼンテーション層またはインフラストラクチャに縛り付けられる必要がなくなり、必要に応じてプレゼンテーションコンポーネントを追加または削除することができる。
【００６７】
インフラストラクチャと同様、プレゼンテーションは、コアインフラストラクチャと共有可能か、あるいは顧客のニーズから独立して拡張可能な１組のコア・データ・モデルを有する。プレゼンテーション層はインフラストラクチャがなくても使用できるため、インフラストラクチャに記載されたコア・データ・モデル・コンセプトがプレゼンテーション層にも適用される。データモデル層は、コア・データ・モデルに外部データを入力し、拡大するためのオープンインターフェースを提供するため、外部またはサードパーティのデータフィードと統合するのに必要なソフトウェア開発がほとんど必要ない。
【００６８】
１０２−プレゼンテーション層の残り部分からプロトコルおよびメッセージングフォーマットに関する詳細を抽象化する外部通信アダプタを収容するように設計されたアダプタ層。
【００６９】
１０３―アダプタ層通信を構成し、プレゼンテーション層の残り部分からデータ・メッセージング・プロトコルとフォーマットとをさらにフィルタリングおよび抽象化するように設計されたモジュール層。
【００７０】
１０４−プロキシ層は、データのフィルタリングおよび配信効率を高めるためにプロキシを作成できる配信層である。
【００７１】
１０５−プラグイン層は、任意の視覚化サービスにコンポーネントを追加することができ、視覚化サービスのデータを受信するためにプロキシ層（またはその他任意の層）と直接通信できる視覚化層である。
【００７２】
１０６〜１０８−任意の外部エンティティと通信する目的で作成可能なアダプタ例。
【００７３】
１０６−１〜１０８−１−アダプタが、全員が参照するサービスレジストリに自身を登録するためのＡＰＩ。
【００７４】
１０９−システム内で適切に管理および発見されるためにすべてのアダプタが実装する必要のあるコアアダプタＡＰＩ。
【００７５】
１１０〜１１５−アダプタを構成し、データをフィルタリングするように設計されたモジュール例。これらのモジュールは、どのような戦術的インストールに標準装備されている。
【００７６】
１１６−拡張可能なサードパーティ製モジュールが既存のモジュールと共存するか、あるいは既存のモジュールに置き換わるコンテナ。
【００７７】
１１７−システム内で適切に管理および発見されるためにすべてのモジュールが実装する必要のあるコアモジュールＡＰＩ。
【００７８】
１１８〜１２３−プレゼンテーション層から通信の詳細を抽象化し、データをフィルタリングするように設計されたプロキシ例。これらのプロキシは、どのような戦術的インストールにも標準装備されている。
【００７９】
１２４−拡張可能なサードパーティ製プロキシが既存のプロキシと共存するか、あるいは既存のプロキシに置き換わるコンテナ。
【００８０】
１２５−システム内で適切に管理および発見されるためにすべてのプロキシが実装する必要のあるコアプロキシＡＰＩ。
【００８１】
１２６−すべての戦術的システムで利用可能なコアプラグイン。
【００８２】
１２７−拡張可能なサードパーティ製プラグインが既存のプラグインと共存するか、あるいは既存のプラグインに置き換わるコンテナ。
【００８３】
１２８−システム内で適切に管理および発見されるためにすべてのプラグインが実装する必要のあるコアプラグインＡＰＩ。
【００８４】
１２９−登録されたコアサービスを登録し、ルックアップし、さらにタスク処理するためのサービスレジストリ通信。
【００８５】
１３０−システム内のすべてのサービスおよびアプリケーションを登録し、ルックアップし、さらにタスク処理するためのサービスレジストリ通信。
【００８６】
１３１−アプリケーションの開始点は、そのアプリケーションの全コンポーネントが互いに通信できるようにするためのサービス登録コンポーネントである。
【００８７】
１３２−サービスおよびシステムの通信を管理および監視するとともに、他のサービスおよびシステムがサービスイベントを問い合わせ、サービスイベントの有無を監視するサービスを提供するように設計されたサービスマネージャとそのＡＰＩ。
【００８８】
１３３−コア視覚化コンポーネント。
【００８９】
１３４−すべてのコンポーネントが使用する汎用レイアウト管理サービス。
【００９０】
１３５−プラグインマネージャは、プラグインのロードおよびアンロードを制御する。
【００９１】
１３６−サードパーティの視覚化サービス用の拡張可能なコンテナ。
【００９２】
１３７−すべてのコンポーネントが使用する目的で提供されたコアＧＩＳサービス。
【００９３】
１３８−すべてのコンポーネントが使用する目的で提供されたコア・ウィジェット・サービス。
【００９４】
１４０〜１４１−任意の通信プロトコルを介してアダプタと直接通信する任意の外部エンティティ。
【００９５】
１４２〜１４４−任意のエンティティとアダプタ層との間で行われるオープンで拡張可能な通信。
【００９６】
プラグインフレームワーク
プラグインフレームワークは、プレゼンテーション層を真に拡張可能にするフレームワークである。このフレームワークを通じて、開発者は、視覚化面に配置される新しい層を作成することにより、自身のデータ視覚化をアプリケーションに追加することができる。提供されるＡＰＩは極めてオープンであり、アプリケーション内で表示され得る任意のカスタムグラフィカル要素を導入することができる。このＡＰＩにより、開発者は、外部データソースへの接続を速やかに確立することもでき、それによってプラグインが動作することができる。これによって顧客は、必要に応じてその場で機能を開発できるようになるとともに、顧客要件を考慮してアプリケーションを速やかに拡張できるようになる。プラグインは非常に構成可能性が高く、新しいステータスウィジェットと同じくらいシンプルな新しい３Ｄモデリング機能などを実現するように構築することができる。また、システムを再コンパイルしたり、再展開したりすることなく、プラグインを動的に追加／削除することもできる。
【００９７】
このプラグインパラダイムは、ＳＯＡシステムを理想的に補完する。プレゼンテーション層全体を交換できるだけでなく、プレゼンテーションの内部を交換することもできる。これにより、コアインフラストラクチャを書き変えることなく、新技術をディスプレイに速やかに統合することができる。
【００９８】
プラグインの描画：
１：クライアントによって開発されるプラグイン。プラグインフレームワークにアクセスする唯一の方法は、提供されたＡＰＩを経由することであり、これにより、クライアントはカスタムグラフィックを作成し、外部サービスに接続できるようになる。
【００９９】
２．クライアントがＷｏｒｌｄＷｉｎｄ層コンストラクトを拡張して自身の層を地球儀に追加できるようにする。
【０１００】
３．クライアントがＪＭＳインターフェースを介して外部データソースに簡単に接続できるようにする。提供される必要があるのは、ＪＭＳサービスの位置だけであり、フレームワークがデータの取得を処理する。
【０１０１】
４．プラグインに、ユーザが管理できる設定項目がある場合には、このモジュールにより、クライアントが設定項目を指定することができる。設定項目はメイン・アプリケーション・メニューにＪａｖａＦＸウィジェットとして自動的に表示される。
【０１０２】
５．  プラグインに、ユーザに提供する必要のあるツールがある場合には、このモジュールにより、メイン・アプリケーション・ウィンドウにＪａｖａＦＸウィジェットとして表示することができる。
【０１０３】
６．３Ｄデータを地球儀に表示するための簡単なメカニズムを提供する。何らかのカスタムメカニズムが所望されない限り、ユーザは、３Ｄオブジェクトを地球儀に配置するためにカスタムコードを記述する必要がない。
【０１０４】
通信フレームワーク
通信フレームワークは、ハードウェアコンポーネント（ラジオやリンクなど）と速やかに統合できるように設計されている。このフレームワークは、すべてのハードウェアインターフェースを、ＳＯＡ互換のサービスとしてインフラストラクチャの残り部分に露出するため、内部クライアントは、たとえば、通信リンクの特定ハードウェア実装について認識する必要がない。低レベルのハードウェアドライバおよびインターフェースの変更は抽象化されるため、通信ハードウェアが変更されても、インフラストラクチャの全部分に影響が波及せず、プレゼンテーション層にさえ波及しない。
【０１０５】
通信フレームワークは、どのようなＳＯＡ互換サービスまたはシステムでもハードウェアと速やかに統合、制御、および通信できるように、オープンコントラクトをシステムの残り部分に露出する。ハードウェアがソフトウェアと同じくらい頻繁に変わる世界では、通信フレームワークにより、顧客が、システムのハードウェアコンポーネントをアップグレードしたり交換したりすることを心配せずに、ハードウェアを柔軟に選択することができる。
【０１０６】
コンポーネントの内訳：
３００−通信フレームワーク−ＳＯＡ互換のモジュール群として構築されており、このフレームワークは、どのＳＯＡコンテナからも追加または削除することができる。
【０１０７】
３０１−サービス層：ハードウェアインターフェースをアプリケーションの残り部分に露出するように設計されたオープンなウェブサービスベースのサービス群。
【０１０８】
３０２−データ変換モジュール。ハードウェアメッセージをＳＯＡ互換のメッセージング形式に変換する。
【０１０９】
３０３−デバイスマネージャ−デバイス固有のドライバおよび独自プロトコルを収容するためのコンテナ。このマネージャから、新しいデバイスを、通信フレームワークの残り部分に影響を及ぼすことなく追加／削除することができる。
【０１１０】
３０４−デバイスモジュール−特定のハードウェアデバイスと通信するための具体的な詳細情報、メッセージングパターン、およびプロトコルを格納する自己格納型モジュール。
【０１１１】
３０５−プロトコルマネージャ−すべてのデバイスが使用するプロトコルソフトウェアの標準的なプールが存在するように、デバイスおよびインフラストラクチャの各々から共通プロトコルを抽象化するように設計されている。標準規格の例として、ＴＣＰ／ＩＰ、１５５３、ＡＲＩＮＣ  ２４９などがある。
【０１１２】
３０６−外部ハードウェアデバイス。ソリューションコアと通信するのに特定のプロトコルおよび／またはドライブを必要とするローカライズされたハードウェアデバイス。
【０１１３】
３０７−ハードウェア固有のＩ／Ｏ（ＴＣＰ／ＩＰなど）。
【０１１４】
３０８−サービス層とインフラストラクチャフレームワークとの間で行われるオープンな標準通信。
【０１１５】
使用事例：
１５５３ベースのハードウェアデバイスとの通信。
【０１１６】
１．外部デバイスがプロトコルマネージャに接続する。プロトコルマネージャは、そのデバイスが稼働する接続箇所（ポートなど）を指定する。
【０１１７】
２．プロトコルマネージャが、デバイスの種類を判断し、各デバイスのメッセージに関する具体的な詳細情報を格納している１つまたは多数のデバイスモジュールのインスタンスを生成する。
【０１１８】
３．デバイスマネージャが、データ変換サービスを使用して、独自のハードウェア固有メッセージをソリューション・コア・データ・モデル形式に変換する。
【０１１９】
４．サービス層が、必要に応じて、追加処理のためにソリューション・コア・データ・モデルをインフラストラクチャフレームワークに送信する。
【０１２０】
トレーニングフレームワーク
トレーニングフレームワークは、システムのすべてのコンポーネントに組み込まれている。トレーニングフレームワークは、すべてのデータフィード、スクリプト化されたシミュレーションモード、ならびに実施中のトレーニングの記録および再生を１つのシステムでできるようにする。
【０１２１】
システムの使用状況を非常に細かく記録することにより、オペレータは自身の任務を再生し、別のやり方ができた可能性のある箇所と上手くできた箇所とを確認することができる。
【０１２２】
このシステムには、ユーザが資産または他のシステムを、まるで展開済みのシステムを使用しているかのように参照および制御できるようにするいくつかのシミュレーション要素が統合されている。このインフラストラクチャは、データフィード（シミュレーションと現実）を区別しないため、トレーニングから展開への移行がシームレスである。
【０１２３】
教官は、フレームワーク内でシナリオを書くことができ、再生の様子をシステム上で見て、ユーザのやりとりを監視することができる。このシステムは、一時停止、および早送りや巻き戻しを行うことができるため、ユーザはシナリオを見直したり、飛ばしたりすることができる。
【０１２４】
コンポーネントの内訳：
４００−トレーニングフレームワーク−ＳＯＡ互換のモジュール群として構築されており、どのＳＯＡコンテナに対しても追加または削除することができる。
【０１２５】
４０１−時間制御モジュール−インフラストラクチャフレームワークに対し、時間ベースの応答、処理、およびデータ配信を露出および制御するように設計されている。
【０１２６】
４０２−イベントエンジン−システム内で起こる重要なイベントを、後で再生するために記憶したり、再生中にそれらを生成したりする目的で生成および消費するように設計されている。
【０１２７】
４０３−全エンジン間で行われるループ通信で、時間制御モジュールを介して制御される。
【０１２８】
４０４−サービス層−トレーニングインターフェースをアプリケーションの残り部分に露出するように設計されたオープンなウェブサービスベースのサービス群。
【０１２９】
４０５−シミュレーションエンジン−動的な外部インタラクション（航空機や衛星など）のシミュレーションとエミュレーションを可能にするプラグ可能なシミュレーション。
【０１３０】
４０６−スクリプトエンジン−システムインタラクションのスクリプト化再生を可能にするように設計されている。
【０１３１】
４０７−トレーニング永続データ−再生とスクリプトの実行に必要な永続データ。永続データは、リアルタイム飛行記録データなど、任意のデータベース群に由来するように構成することができる。
【０１３２】
４０８−サービス層とインフラストラクチャフレームワークとの間で行われるオープンな標準通信。
【０１３３】
使用事例：
任務の再生：
１．トレーニングフレームワークが、飛行記録のデータベースから再生されるように設定される。
【０１３４】
２．時間制御モジュールがエンジンループを開始し、リアルタイム再生の準備を整える。
【０１３５】
３．スクリプトエンジンが、記録されたデータを取得し、解析し、処理のためにイベントエンジンに提供する。
【０１３６】
４．イベントエンジンがメッセージを、追加処理のためにサービス層を介してインフラストラクチャにプッシュする。
【０１３７】
５．イベントエンジンが、メッセージをシミュレーションエンジンにプッシュする。
【０１３８】
６．シミュレーションエンジンが、そのメッセージに外部のエンティティのエミュレーションまたはシミュレーションが必要かどうかを判断し、必要であればそのメッセージをサービス層にプッシュする。不要な場合には、スクリプトエンジンでループバックを終了し、次の一時メッセージ群を読み込む。
【０１３９】
状況認識
状況認識（ＳＡ）ソリューションは、非同期ビュー、リアルタイムビュー、操作ビュー一式をユーザに提供するように設計されている。ＳＡソリューションには、リアルタイムでの資産監視および追跡から、資産の将来予測モデリングならびに資産履歴の確認まで、ユーザがシステムの接続先資産のリアルタイムステータスを参照できるようにするいくつかのモジュール式プラグインが格納されている。
【０１４０】
ＳＡソリューションは、１つの操作ビュー内にある複数の異なる資産からステータスデータを表示および操作することができる。システムは、構成可能性と拡張性の高い４次元の次世代ユーザインターフェース群でステータスを表示および維持することができる。ＳＡソリューションは、最新のグラフおよび図表作成機能を使用して、リアルタイム分析用にリアルタイムデータおよびオフラインデータを操作するためのツールおよびユーティリティを提供する。
【０１４１】
ＳＡソリューションは、ＳＯＡインフラストラクチャとプラグインベースのプレゼンテーションアーキテクチャとに基づいており、構成可能性と拡張性が高い。新しい資産またはデータ群を参照できようになると、ＳＡソリューションはこれらのデータフィードを見つけ、その情報をユーザに表示する。ユーザはさらに、自分のＳＡインターフェース、３Ｄモデル、データソースなどを追加することにより、わずかな開発労力で、あるいはまったく開発労力をかけずにＳＡソリューションを拡張することができる。
【０１４２】
ＳＡソリューションは、１つの共通操作画像に異なるシステムをすべてまとめることを意図するものである。
【０１４３】
指揮統制
指揮統制（Ｃ２）にはさまざまな形態があり、これまでは、すべてのシステムが、独自の指揮統制インターフェース群を有する必要があった。Ｃ２ソリューションは、複数の資産に複数のＣ２システムを使用するというパラダイムを覆す目的で設計されている。Ｃ２ソリューションは、ＳＯＡフレームワークの上位に構築され、実際、インフラストラクチャにシームレスに織り込まれている。Ｃ２ソリューションは、すべてのシステムが自らのシステムのＣ２メッセージングをＣ２ソリューションに簡単に統合できるようにするサービス群を提供する。
【０１４４】
Ｃ２ソリューションは、一般に異なる複数のシステムに散在する共通のコマンドの重複を排するとともに、ユーザにこれらの共通コマンド群から拡張し、独自の指揮統制インターフェースを統合できるようにする。これにより、レガシーシステムと将来のシステムとをコミュニティがＣ２インフラストラクチャに統合できるようになる。
【０１４５】
操作上、Ｃ２ソリューションは、すべての資産タイプに対する単一の指揮統制インターフェースとなる。飛行資産から無人の船舶資産まで、Ｃ２ソリューションは、独自のコマンド構造を各々の特定システムと統合できるようにするだけではく、共通のコントロール群を介してコマンド群を参照および配送できる視覚的なインターフェースも提供する。これらの機能をすべて組み合わせることにより、あらゆるシステムにコンパクトなソリューションを提供するとともに、維持費と研修費を削減する。
【０１４６】
運用管理
この運用管理（ＯＭ）ソリューションは、資産の運航計画、再計画、および動的なタスク処理を可能にするように設計されている。ＯＭはこれまで、２次元図表作成・グラフィック機能を使用して個々のシステムで行われてきた。このＯＭソリューションは、ソリューションＳＯＡフレームワークの上位に構築され、ユーザが運用管理に必要なすべてのタスクを実行できるようにするサービス群およびアプリケーション群を含んでいる。
【０１４７】
ＯＭソリューションは、運航経路の計画、分析、およびレポート生成を支援するサービスを含んでいる。ＯＭソリューションは、ユーザがリアルタイムで運航計画を更新できるようにし、更新された経路情報や任務遂行情報を資産に直接パブリッシュする。
【０１４８】
革新的な４Ｄユーザインターフェースを使用して、操作上、このシステムは、異なる複数の資産の任務または運航を管理するように展開および構成することができる。加えて、ＯＭソリューションはＳＯＡフレームワークの上位に構築されるため、他の主要サービスによって拡張および拡大することもできる。
【０１４９】
ＯＭソリューションは、すべてのシステムと資産タイプに共通のインターフェースおよびサービス群を提供し、任意の特定資産を展開するのに必要なシステムを大幅に減らす。
【図１】
2014531635.tif 000003
【図２】
2014531635.tif 000004
【図３】
2014531635.tif 000005
【図４】
2014531635.tif 000006
【図５】
2014531635.tif 000007
【図６】
2014531635.tif 000008
【国際調査報告】
2014531635.tif 000009