(57)【要約】  衛星ペイロードアプリケーション開発のシステムおよび方法が提供される。組込型処理システムを開発する方法は、ハードウェア層構成を選択するステップと、１つまたは複数の標準関数呼び出しを介して、インフラストラクチャサービス層、バス抽象化層、デバイス抽象化層、および周辺装置ドライバ層のうちの１つまたは複数からサービスを提供するインターフェーシング・ソフトウェアスタックを開発するステップとを含む。
2009508225.tif 000002
【特許請求の範囲】
【請求項１】
１つまたは複数のペイロードソフトウェアアプリケーション１５０を実行するように適合されたプロセッサ１１０と、
前記プロセッサ１１０に結合された少なくとも１つのシステムバス１２０と、
前記少なくとも１つのシステムバス１２０に結合された少なくとも１つのハードウェアデバイス１３０−１〜１３０−Ｎとを含み、
前記プロセッサ１１０は、インターフェーシング・ソフトウェアスタック２１０を実行するようにさらに適合され、
前記ソフトウェアインターフェーススタックは、
前記１つまたは複数のペイロードソフトウェアアプリケーション１５０からの１つまたは複数の関数呼び出しに応答する周辺装置ドライバ層２１４と、
前記１つまたは複数のペイロードソフトウェアアプリケーション１５０および前記周辺装置ドライバ層２１４のうちの１つまたは両方からの１つまたは複数の関数呼び出しに応答するデバイス抽象化層２１３と、
前記デバイス抽象化層２１３、前記１つまたは複数のペイロードソフトウェアアプリケーション１５０および前記周辺装置ドライバ層２１４のうちの１つまたは複数からの１つまたは複数の関数呼び出しに応答するバス抽象化層２１２と、
前記バス抽象化層２１２、前記デバイス抽象化層２１３、前記１つまたは複数のペイロードソフトウェアアプリケーション１５０および前記周辺装置ドライバ層２１４のうちの１つまたは複数からの１つまたは複数の関数呼び出しに応答するインフラストラクチャサービス層２１１と、を含む、
組込型コンピュータ処理システム。
【請求項２】
前記インフラストラクチャサービス層２１１は、エラー処理、例外処理、診断、ログ処理、スレッド処理、スレッド保護処理および相互排除サービスのうちの１つまたは複数を含むインフラストラクチャサービスを提供するように適合されている、請求項１に記載のシステム。
【請求項３】
前記バス抽象化層２１２は、システムバス初期化、システムバス問い合わせサービス、システムバス発見サービスのうちの１つまたは複数を含む、前記少なくとも１つのシステムバスに対するバスサービスを提供するように適合されている、請求項１に記載のシステム。
【請求項４】
前記デバイス抽象化層２１３は、デバイス初期化の管理、通信セッションの管理、相互デバイス排除サービス、およびデバイス発見のうちの１つまたは複数を含む、前記少なくとも１つのハードウェアデバイスに対するデバイス管理サービスを提供するように適合されている、請求項１に記載のシステム。
【請求項５】
前記周辺装置ドライバ層２１４は、前記少なくとも１つのハードウェアデバイス１３０−１〜１３０−Ｎの各々に対し、関連付けられた周辺装置ドライバ２５０−１〜２５０−Ｍを含み、前記関連付けられた周辺装置ドライバ２５０−１〜２５０−Ｍは、前記少なくとも１つのハードウェアデバイス１３０−１〜１３０−Ｎの１つまたは複数の特殊化したサービスを前記１つまたは複数のペイロードソフトウェアアプリケーション１５０に提供するように適合されている、請求項１に記載のシステム。
【請求項６】
前記ペイロードアプリケーション１５０、前記周辺装置ドライバ層２１４、前記デバイス抽象化層２１３、前記バス抽象化層２１２、およびインフラストラクチャサービス層２１１のうちの前記１つまたは複数は、１つまたは複数の標準関数呼び出しを介して通信する、請求項１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、コンピュータシステムに関し、特に、衛星のためのペイロードアプリケーションの設計に関する。
【背景技術】
【０００２】
衛星のためのペイロードアプリケーションは、通常、一から開発される。各ペイロードアプリケーションは、ペイロードアプリケーションを衛星ハードウェア物理層およびオペレーティングシステムと調整する新規のインフラストラクチャソフトウェアの開発および取り込みが必要である。この設計過程で生じる１つの問題は、開発サイクルの後期に物理ハードウェア層の変更がしばしば生じ、各ペイロードアプリケーションに著しいコード修正がしばしば必要になることである。例えば、ハードウェア層で、１つのベンダの通信ボードの別のベンダの通信ボードとの交換、または１つのシステムバス・アーキテクチャから別のものへの変更は、通信ボードを利用する各ペイロードアプリケーションに関するコードの相当の書き直しを必要とし得る。開発後期のそのような大規模なペイロードアプリケーションの書き直しを回避するために、開発チームはしばしば、設計サイクルのかなり早い段階で技術の固定を確約し、それにより衛星の展開前に利用可能になり得るより上級のハードウェア技術を用いる機会をなしで済ませる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上述した理由のため、および本明細書を読んで理解することにより当業者には明らかになるであろう以下で述べる他の理由のために、衛星ペイロードアプリケーション開発のより向上されたシステムおよび方法の必要性が当技術分野に存在する。
【課題を解決するための手段】
【０００４】
本発明の実施形態は、衛星のペイロードアプリケーションの開発のシステムおよび方法を実現し、以下の明細書を読んで研究することにより理解されるであろう。
一実施形態では、組込型コンピュータ処理システムが提供される。このシステムは、１つまたは複数のペイロードソフトウェアアプリケーションを実行するように適合されたプロセッサと、プロセッサに結合された少なくとも１つのシステムバスと、少なくとも１つのシステムバスに結合された少なくとも１つのハードウェアデバイスと、を含む。このプロセッサは、インターフェーシング・ソフトウェアスタックを実行するようにさらに適合され、１つまたは複数のペイロードアプリケーションがソフトウェアインターフェーススタックで通信することによって少なくとも１つのハードウェアデバイスとデータを通信する。インターフェーシング・ソフトウェアスタックは、１つまたは複数のペイロードソフトウェアアプリケーションに応答する周辺装置ドライバ層を含む。インターフェーシング・ソフトウェアスタックは、１つまたは複数のペイロードソフトウェアアプリケーションおよび周辺装置ドライバ層のうちの１つまたは両方に応答するデバイス抽象化層をさらに含む。インターフェーシング・ソフトウェアスタックは、デバイス抽象化層、１つまたは複数のペイロードソフトウェアアプリケーションおよび周辺装置ドライバ層のうちの１つまたは複数に応答するバス抽象化層をさらに含む。インターフェーシング・ソフトウェアスタックは、バス抽象化層、デバイス抽象化層、１つまたは複数のペイロードソフトウェアアプリケーションおよび周辺装置ドライバ層のうちの１つまたは複数に応答するインフラストラクチャサービス層をさらに含む。
【０００５】
別の実施形態では、組込型処理システムを開発する方法が提供される。方法は、ハードウェア層構成を選択するステップと、１つまたは複数の標準関数呼び出しを介して、インフラストラクチャサービス層、バス抽象化層、デバイス抽象化層、および周辺装置ドライバ層のうちの１つまたは複数からサービスを提供するインターフェーシング・ソフトウェアスタックを開発するステップとを含む。
【０００６】
さらに別の実施形態では、組込型ペイロードアプリケーションのためのインターフェーシング・ソフトウェアスタックが提供される。ソフトウェアインターフェーススタックは、１つまたは複数のペイロードソフトウェアアプリケーションからの１つまたは複数の関数呼び出しに応答する周辺装置ドライバ層と、１つまたは複数のペイロードソフトウェアアプリケーションおよび周辺装置ドライバ層のうちの１つまたは両方からの１つまたは複数の関数呼び出しに応答するデバイス抽象化層と、デバイス抽象化層、１つまたは複数のペイロードソフトウェアアプリケーションおよび周辺装置ドライバ層のうちの１つまたは複数からの１つまたは複数の関数呼び出しに応答するバス抽象化層と、バス抽象化層、デバイス抽象化層、１つまたは複数のペイロードソフトウェアアプリケーションおよび周辺装置ドライバ層のうちの１つまたは複数からの１つまたは複数の関数呼び出しに応答するインフラストラクチャサービス層とを含む。
【０００７】
本発明の実施形態は、実施形態の説明および以下の図面に照らして考慮することにより、より容易に理解することができ、そのさらなる利点および使用がより容易に明らかになり得る。
【発明を実施するための最良の形態】
【０００８】
一般的なやり方に従い、説明される種々の特性は、縮尺どおりに表現されていないが、本発明に関連する特性を強調するように表現されている。参照記号は、図面および本文を通して同様の要素を示す。
【０００９】
以下の詳細な説明では、本明細書の一部を成す添付の図面を参照して、本発明が実施され得る具体的で例証的な実施形態が例示目的として示される。これらの実施形態は、当業者による本発明の実施を可能にするのに充分な詳細が説明されており、別の実施形態が利用されてもよく、本発明の範疇から逸脱せずに論理的、機構的および電気的な変更がなされ得ることを理解されたい。それゆえに、以下の詳細な説明は、限定的な意味にとられるべきではない。
【００１０】
図１は、本発明の一実施形態の衛星コンピュータプラットフォームの典型的な物理ハードウェア層１００を示す。一実施形態では、ハードウェア層１００は、少なくとも１つのシステムバス１２０に結合され、オペレーティングシステム（Ｏ／Ｓ）１１５を実行する少なくとも１つのプロセッサ１１０と、システムバス１２０に結合された１つまたは複数のハードウェアデバイス１３０−１〜１３０−Ｎとを含む。動作中、プロセッサ１１０によって実行される１つまたは複数のペイロードアプリケーション１５０は、少なくとも１つのシステムバス１２０を介して通信することによって、ハードウェアデバイス１３０−１〜１３０−Ｎとデータを共有する。
【００１１】
本発明の実施形態によって、デバイスがそれらが取り付けられるバス、プロセッサおよびオペレーティングシステムにほとんど依存しないように、よりポータブルなやり方でデバイスを管理する方法が提供される。本発明の実施形態は、図２−Ａに示すように、機能的にモジュール化されたインターフェーシング・ソフトウェアスタック２１０を提供することによって、ペイロードアプリケーション１５０がハードウェア層１００に適合するようにカスタマイズされたコードを含む必要性を除去する。インターフェーシング・ソフトウェアスタック２１０は、以下で説明する複数のソフトウェア層を含み、それらは各々、標準関数呼び出しを介してハードウェア関連サービスを提供し、ペイロードアプリケーション１５０がハードウェアデバイス１３０−１〜１３０−Ｎと通信することを可能にする。これらの関数をインターフェーシング・ソフトウェアスタック２１０の層内に組み込むことによって、そのようなコードをペイロードアプリケーション１５０内に含む必要性が取り除かれる。その代わりに、ペイロードアプリケーション１５０の開発は、ペイロードアプリケーション１５０のミッションを実行するために必要なデバイス１３０−１〜１３０−Ｎのサービスを取得するために、インターフェーシング・ソフトウェアスタック２１０内に定義された関数呼び出しを含むだけの必要性が存在する。この理由のために、本発明の実施形態は、衛星プロジェクトの開発サイクルのより早期にペイロードアプリケーションのコーディングを開始することを可能にし、それによりペイロードアプリケーションの開発時間を低減し、静的な基礎ハードウェアプラットフォームに対するペイロードアプリケーション開発の依存を低減する。本出願に示された本発明の実施形態の例は、宇宙ベースのシステム上で実行されるペイロードアプリケーションを説明するが、当業者は本明細書を読むことにより、本発明の範疇が宇宙ベースのシステムだけに限定されず、その実施形態があらゆる組込型コンピューティングシステムを包含することを理解するであろう。
【００１２】
一実施形態では、インターフェーシング・ソフトウェアスタック２１０は、インフラストラクチャサービス層２１０、バス抽象化層２１２、デバイス抽象化層２１３、および１つまたは複数の周辺装置ドライバの層２１４を含む。インターフェーシング・ソフトウェアスタック２１０の各層は、ペイロードアプリケーション１５０がハードウェアデバイス１３０−１〜１３０−Ｎの１つと通信する、実施形態によっては制御する、のに必要な主要な関数を区分化する。インターフェーシング・ソフトウェアスタック２１０の各層は、以下で詳細が説明される。
【００１３】
一実施形態では、インフラストラクチャサービス層２１１は、ペイロードアプリケーション１５０、システムバス抽象化層２１２、デバイス抽象化層２１３、および周辺装置ドライバ層２１４に低レベル機能的支援を提供する。インフラストラクチャサービス層２１１によって提供されるサービスは、通常、用いられるハードウェア実装（例えば、プロセッサ１１０のチップセットまたはシステムバス１２０のアーキテクチャ）に関わらず必要なインフラストラクチャサービスである。インフラストラクチャサービス層２１１によって提供されるインフラストラクチャサービスは、限定されるものではないが、エラー処理、例外機構、診断、イベントおよびエラーのログ処理、スレッド処理、スレッド保護処理および相互排除機構を含む。一実施形態では、インフラストラクチャサービス層２１１は、Ｏ／Ｓ  １１５から抽出される通常のＯ／Ｓサービスをさらに含む。より高レベル層がインフラストラクチャサービスを要求する場合、それらは１つまたは複数の標準関数呼び出しを介してインフラストラクチャサービス層２１１からアクセスされる。
【００１４】
衛星開発者がハードウェア層１００の設計に含むのに、多種多様のシステムバス１２０のアーキテクチャが現在利用可能である。現在のシステムバスの技術は、限定されるものではないが、周辺構成要素相互接続（ＰＣＩ）、モジュラーバス、高速Ｉ／Ｏおよびスペースワイヤを含む。バス抽象化層２１２は、ペイロードアプリケーション１５０、デバイス抽象化層２１３、およびデバイスドライバ層２１４にシステムバス１２０とインターフェースをとるため、およびシステムバス１２０を介した通信をするために必要なバスサービス機能を提供する。標準関数呼び出しを介して、バス抽象化層２１２は、システムバス１２０の特定のアーキテクチャに一般的であるバスサービスを提供する。一実施形態では、バス抽象化層２１２によって提供されるバスサービス機能は、限定されるものではないが、バス初期化、バスハードウェア問い合わせおよびバス発見サービスを含む。例えば、一実施形態では、バス抽象化層２１２は、ＰＣＩシステムバス・アーキテクチャをサポートする。そしてバス抽象化層２１２は、全てのＰＣＩアーキテクチャに一般的なバスサービスを上位層に提供する。
【００１５】
デバイス抽象化層２１３は、ペイロードアプリケーション１５０および周辺装置ドライバ層２１４に、デバイス１３０−１〜１３０−Ｎと通信するために必要なデバイス管理サービスを提供する。一実施形態では、必要なデバイス管理サービスは、デバイス初期化、セッション、デバイスの相互排除、およびデバイス発見の管理等の標準機能を含む。デバイス抽象化層２１３は、ペイロードアプリケーション１５０および周辺装置ドライバ層２１４が、ハードウェア層１００のどこに特定のハードウェアデバイスがインストールされたか、どの種類のシステムバス・アーキテクチャが用いられているか、デバイスとどのようにセッションを確立するか、およびセッションとセッションに関連する状態とをどのように維持するかを知る必要性を除去する。さらに、デバイス抽象化層２１３および上位レベル層の間のやりとりは、ハードウェア層１００の基礎仕様に依存しない標準関数呼び出しを利用する。
【００１６】
インターフェーシング・ソフトウェアスタック２１０の最上位層は、周辺装置ドライバ層２１４である。一実施形態では、ハードウェアデバイス１３０−１〜１３０−Ｎは、限定されるものではないが、データ入力デバイス（例えば、環境センサ、画像キャプチャデバイス）、出力デバイス（例えば、モニタ、プリンタ）、データ記憶デバイス（例えば、ディスクまたはテープのドライブ、メモリデバイス）、通信デバイス（例えば、無線通信デバイス、ネットワークアダプタ）、機械的装置コントローラ（例えば、モータ、サーボ、ソレノイド、照明、加熱装置のコントローラ）、またはシステムの機能的能力を拡張するサービスを提供する他のあらゆるデバイスを含む。図２Ｂに示されるように、物理ハードウェア層１００にインストールされた各種類のハードウェアデバイス１３０−１〜１３０−Ｎに対し、周辺装置ドライバ層２１４は、ペイロードアプリケーション１５０が特定のハードウェアデバイスの特殊化したサービスにアクセスすることを可能にする、関連付けられた周辺装置ドライバ２５０−１〜２５０−Ｍ（関連付けを２５５−１〜２５５−Ｎによって示す）を含む。動作中、ペイロードアプリケーション１５０が（デバイス１３０−１等の）標的のデバイスのサービスにアクセスする必要がある場合、ペイロードアプリケーション１５０はデバイス１３０−１に関連付けられた（周辺装置ドライバ２５０−１等の）周辺装置ドライバによって提供される特定の関数を呼び出す。実施形態によっては、（ハードウェアデバイス１３０−１等の）単一のハードウェアデバイスが（周辺装置ドライバ２５０−１等の）単一の周辺装置ドライバに関連付けられる。ハードウェア１３０−１からのサービスを必要とするあらゆるペイロードアプリケーション１５０は、周辺装置ドライバ２５０−１によって提供される１つまたは複数の関数呼び出しを介してそれらのサービスにアクセスする。例えば、デバイス１３０−１が画像センサである一実施形態では、特殊化したサービスは、画像データのキャプチャリングを含み得る。周辺装置ドライバ２５０−１によって提供される関数呼び出しは、それに応じて、フレームキャプチャ速度、フレーム解像度、レンズ焦点、カメラ位置の設定および画像キャプチャの初期化等の機能の提供に専門化される。実施形態によっては、（ハードウェアデバイス１３０−２および１３０−３等の）２つ以上のハードウェアデバイス１３０−１〜１３０−Ｎがシステムに同じサービスを提供し、（周辺装置ドライバ２５０−２等の）単一の周辺装置ドライバがこれら２つ以上のハードウェアデバイス１３０−１〜１３０−Ｎに関連付けられる。一実施形態では、ペイロードアプリケーションが、関数呼び出しで１つまたは複数のパラメータを指定することによって、ハードウェアデバイス１３０−１および１３０−２のいずれと通信するかを特定する。
【００１７】
一実施形態では、ペイロードアプリケーション１５０が（例えば、画像をキャプチャするために）標的のデバイス１３０−１のサービスを必要とする場合、ペイロードアプリケーション１５０は、関連付けられた周辺装置ドライバ２５０−１によって提供され、周辺装置ドライバ層２１４内に配置された標準関数呼び出しを呼び出す。そして関連付けられた周辺装置ドライバは、周辺装置ドライバ層２１４と標的のデバイス１３０−１との間の通信セッションを確立するようにデバイス抽象化層２１３に要求する。
【００１８】
一実施形態では、デバイス抽象化層２１３は、どのシステムバスに標的のデバイス１３０−１が配置されているか、およびそのシステムバスによって利用されるバスアーキテクチャを知っている。例えば、一実施形態では、デバイス抽象化層２１３は、標的のデバイス１３０−１がシステムバス１２０上に配置され、そのシステムバス１２０がＰＣＩバスであることを知っている。一実施形態では、デバイス抽象化層２１３は、システムバス１２０のアーキテクチャを発見し、システムバス１２０上にどのデバイスがインストールされているかを決定するようにプログラミングされる。一実施形態では、システムバス１２０のアーキテクチャおよびデバイス１３０−１〜１３０−Ｎのインストールのうちの１つまたは両方がデバイス抽象化層２１３中にコード化される。一度、デバイス抽象化層２１３が、システムバス１２０上の標的のデバイス１３０−１の位置を特定すると、デバイス抽象化層２１３は、システムバス１２０の初期化に関する要求をバス抽象化層２１２に命令する。
【００１９】
一実施形態では、周辺装置ドライバ２１４からの要求に応じて、デバイス抽象化層２１３は、バス抽象化層２１２によって提供されるバスサービスを介して、システムバス１２０の初期化を要求し、デバイス１３０−１と周辺装置ドライバ層２１４内の関連付けられた周辺装置ドライバ２５０−１〜２５０−Ｍとのセッションを確立し、ペイロードアプリケーション１５０がデバイス１３０−１へのアクセスを要求する限り関連するセッション状態を保持する。一実施形態では、デバイス抽象化層２１３は、ペイロードアプリケーション１５０に対するデバイス１３０−１の独占使用を管理し、セッションが開かれている間、他のアプリケーションがデバイス１３０−１にアクセスすることを阻止する。
【００２０】
本発明の実施形態によって、ペイロードアプリケーション開発者はもはや、関連付けられたデバイスの位置を決定し、システムバスを特定および初期化し、セッションを確立してセッション状態を維持するための機能を備えた独自のソフトウェアをコード化する必要性がなくなり、というのは、上述したようにそれらの機能がバス抽象化層２１２およびデバイス抽象化層２１３の中に組み込まれているからである。さらに、エラー処理、例外機構、診断、ログ処理、スレッド処理、およびスレッド保護処理等の基本サービスは、インフラストラクチャサービス層２１１によって提供される。これによって、ペイロードアプリケーションのコード化は、関連付けされたデバイス１３０−１〜１３０−Ｎによって提供される機能を利用するために、周辺装置ドライバ層２１４のデバイスドライバとインターフェースをとることに専念することが可能になる。本発明のインターフェーシング・ソフトウェアスタックによって、ペイロードアプリケーション１５０の開発者は、特定のハードウェアがどこにインストールされているか、どの種類のシステムバス・アーキテクチャが用いられているか、デバイスとどのようにセッションを確立するか、およびセッションとセッションに関連する状態とをどのように維持するかを知る必要性が除去される。
【００２１】
図２−Ａに示されているように、インターフェーシング・ソフトウェアスタック２１０は、ペイロードアプリケーション１５０が、単に周辺装置ドライバ層２１４によって提供される関数呼び出しを介して、ハードウェアシステム層１００と直接的に通信する必要なしに、ハードウェアデバイス１３０−１〜１３０−Ｎによって提供されるサービスにアクセスすることを可能にする。しかしながら、インターフェーシング・ソフトウェアスタック２１０の階段性は、そのような直接的なアクセスを妨げない。インターフェーシング・ソフトウェアスタック２１０は、ペイロードアプリケーション１５０が、ハードウェアシステム層１００によって提供されるあらゆるサービスに直接的にアクセスすることを可能にする。さらに、本発明の実施形態は、層２１１〜２１４のうちのいずれかへの関数呼び出しを直接的を実行することによって、インターフェーシング・ソフトウェアスタック２１０の任意の１つまたは複数の層２１１〜２１４を迂回する選択肢をペイロードアプリケーションの開発者に提供する。例えば、アプリケーション開発者は、彼ら独自の専用デバイスドライバ関数呼び出しを彼らのペイロードアプリケーション内に組み込み、デバイス抽象化層２１３への関数呼び出しを直接的に行うようにコード化することを選択し得る。同様に、層２１１〜２１４のうちの任意の１つが、層２１１〜２１４のいずれかによって提供される関数呼び出しを直接的に実行することによって、またはハードウェアシステム層１００と直接的に通信することによって、他の層２１１〜２１４のうちの１つまたは複数によって提供される機能を迂回するようにコード化し得る。
【００２２】
本発明の実施形態は、さらに、ペイロードアプリケーションの開発者と衛星システムのベンダとの両者が、彼ら各自のソフトウェアを開発するための標準関数コードのライブラリを確立し、利用することを可能にする。例えば、ハードウェアデバイス１３０−１のサービスを利用するペイロードアプリケーションの開発者は、関連付けられた周辺装置ドライバ２５０−１によって提供される標準関数呼び出しを含む内部サブルーチンを開発し得る。将来的に、開発者は、同じハードウェアデバイス１３０−１を利用する衛星システムに関して彼らが開発する他のペイロードアプリケーション内でそのサブルーチンに関するコードを単純に再利用し得る。このやり方で、ペイロードアプリケーションの開発者は、彼らがいつも決まって利用するハードウェアデバイスに対するサブルーチンのライブラリを構築して保持し得る。さらに、周辺装置ドライバによって提供される標準関数呼び出しに依存することによって、システムバス・アーキテクチャ等のハードウェア仕様が衛星システムベンダによって変更された場合に、ペイロードアプリケーションの開発者は彼らのアプリケーションを再コード化する必要性と無関係でいられる。
【００２３】
同様のやりかたで、抽象化インフラストラクチャ層の標準関数呼び出しおよびモジュール設計のために、本発明の実施形態によって、衛星システムベンダが、特定のプロジェクトに対する抽象化インフラストラクチャ層を構築する際に、以前のプロジェクトから層２１１〜２１４に関して開発および試験されたコードを再利用することがさらに可能にされる。例えば、衛星システムベンダは、Ｏ／Ｓおよびプロセッサの種々の組み合わせに対し、インフラストラクチャサービス層コードのライブラリを構築し、利用することが可能である。以前に使用および試験されたコードのライブラリは、周辺装置ドライバ、デバイス抽象化層、およびバス抽象化層に対して、同様に構築され得る。標準関数呼び出しの使用は、特定のプロジェクトに対して層を著しく再コード化する必要性なしに、ライブラリから選択された層の相互運用を可能にする。
【００２４】
本発明の実施形態は、さらに、衛星システムベンダが開発サイクルの早期に（ハードウェア層のデバイスの使用の決定がなされてすぐに）、プロセッサ、オペレーティングシステム、またはシステムバス・アーキテクチャの変更が後で必要になった場合にやむを得ず完全に新規の周辺装置ドライバを作成しなければならないという恐れなしに、周辺装置ドライバを作成することを可能にする。実際、本発明の実施形態によって、インフラストラクチャとなるプロセッサコア、オペレーティングシステムまたはシステムバス・アーキテクチャの知識なしでの周辺装置ドライバの開発が可能にされる。
【００２５】
衛星システムベンダが、１つのベンダにより製造された１つまたは複数のハードウェアデバイス１３０−１〜１３０−Ｎを、同じ主要機能を提供するが異なるベンダにより製造されたデバイスに交換することを決定した場合、本発明の実施形態は、インターフェース・ソフトウェアスタック２１０全体を再コード化する必要なしに、開発者が周辺装置ドライバ層２１４内の関連付けられた周辺装置ドライバを適切に交換することを可能にする。同じやり方で、インターフェーシング・ソフトウェアスタックの各層は、システムハードウェア１００の仕様の変更が原因で必要になるソフトウェアの変更を局所化する。
【００２６】
図３は、本発明の一実施形態による、衛星ペイロードアプリケーションを開発する方法を図示するフローチャートである。この方法は、衛星のハードウェア層に関するハードウェア構成を選択することにより３１０で開始する。一実施形態では、ハードウェア構成を選択することは、プロセッサを選択すること、オペレーティングシステムを選択すること、１つまたは複数の周辺ハードウェアデバイスを選択すること、およびプロセッサと１つまたは複数のハードウェアデバイスとの間の少なくとも１つのシステムバスを選択することを含む。一実施形態では、１つまたは複数の周辺ハードウェアデバイスは、各々、限定されるものではないが、通信の送信および受信、データ記憶、センシング（例えば、画像、音声、温度、圧力、放射線レベル、または他の環境要因のキャプチャリング）、または機械的操作（例えば、電気的に制御されるモータ、ポンプ、バルブ、サーボ）等の特殊化した機能を提供する。一実施形態では、少なくとも１つのシステムバスは、限定されるものではないが、ＰＣＩバス、モジュラーバス、高速Ｉ／Ｏバスおよびスペースワイヤバス等の業界標準システムバスを含む。一実施形態では、プロセッサは、１つまたは複数のプロセッシングコアを含む。
【００２７】
この方法は、１つまたは複数のインフラストラクチャサービス、バスサービス、デバイス管理サービスおよび１つまたは複数のハードウェアデバイスに関連付けられた周辺装置ドライバを含むソフトウェア層に区分化されたペイロードアプリケーションに標準化された機能を提供するインターフェーシング・ソフトウェアスタックを開発することにより、３２０で継続する。一実施形態では、１つまたは複数のペイロードアプリケーションが、標準化された機能に関連付けられた１つまたは複数の標準関数呼び出しを介してインターフェーシング・ソフトウェアと通信する。一実施形態では、周辺装置ドライバは、ペイロードアプリケーションに、少なくとも１つのハードウェアデバイスの１つまたは複数の特殊化した機能にアクセスするための標準関数呼び出しを提供する。一実施形態では、インフラストラクチャサービスは、エラー処理、例外処理、診断、ログ処理、スレッド処理、スレッド保護処理および相互排除サービスのうちの１つまたは複数を提供することを含む。一実施形態では、少なくとも１つのシステムバスに関するバスサービスを提供することは、システムバス初期化、システムバス問い合わせサービス、およびシステムバス発見サービスのうちの１つまたは複数を提供することを含む。一実施形態では、デバイス管理サービスを提供することは、デバイス初期化の管理、通信セッションの管理、相互デバイス排除サービス、およびデバイス発見のうちの１つまたは複数を提供することを含む。この方法は、ペイロードアプリケーションコードを開発することにより、３３０で継続する。一実施形態では、ペイロードアプリケーションコードは、インフラストラクチャとなるハードウェア層とデータを通信するために、インターフェーシング・ソフトウェアスタックの層によって提供される機能およびサービスにアクセスするように設計されている。インターフェーシング・ソフトウェアスタック関数呼び出しだが、ハードウェア層にアクセスすることは、ハードウェア層の仕様に変更が生じた場合に、ペイロードアプリケーションを再コード化する必要性から著しく遠ざける。図３に示されるように、衛星ベンダが１つまたは複数のハードウェア仕様を変更する場合、インターフェーシング・ソフトウェアスタックはこの変更に適応するように修正される（３４０）。例えば、ハードウェアデバイスが１つのシステムバスから別のシステムバスに移転された場合、または１つのシステムバスに利用されるシステムバス・アーキテクチャが異なるシステムバス・アーキテクチャに交換された場合、構成の変更のため、インターフェーシング・ソフトウェアスタックの１つまたは複数の層は修正される必要があり得る。しかしながら、１つの実施形態では、ペイロードアプリケーションコードは、周辺装置ドライバによって提供される関数呼び出しが同じままである限り、ハードウェアデバイスへのアクセスの継続をするのに付加的な修正を必要としない。
【００２８】
図４は、衛星ペイロードアプリケーションと衛星システムハードウェア層のハードウェアデバイスとの間でデータの通信をする方法を示すフローチャートである。この方法は、ペイロードアプリケーションからハードウェアデバイスに関連付けられた周辺装置ドライバに少なくとも１つの関数呼び出しを送信することにより、４１０で開始する。一実施形態では、関数呼び出しの要求は、複数のハードウェアデバイスのうちのどの１つとペイロードアプリケーションが通信する必要があるかを特定する。この方法は、周辺装置ドライバとハードウェアデバイスとの間の通信セッションを確立するために、周辺装置ドライバからデバイス抽象化層に少なくとも１つの関数呼び出しを送信することにより、４２０で継続される。図２に関して説明されたように、デバイス抽象化層は、１つまたは複数のシステムバスのうちのどれが、ペイロードアプリケーションを実行するプロセッサをハードウェアデバイスに結合するかを知っている。この方法は、ハードウェアデバイスに結合されたシステムバスの初期化を要求する少なくとも１つの関数呼び出しをデバイス抽象化層からバス抽象化層に送信することにより、４３０で継続する。この方法は、次に、ハードウェアデバイスとドライバとの間の通信セッションを確立することにより、４４０に進み、ペイロードアプリケーションがハードウェアデバイスへのアクセスを必要とする限り、関連するセッションの状態を保持する（４５０）。
【００２９】
本明細書で、特定の実施形態が示されて説明されたが、当業者には、同じ目的を達成することが予測されるあらゆる配置が、示された特定の実施形態の代わりになることを理解するであろう。この出願は、本発明のあらゆる変形および変更を網羅することが意図されている。それゆえに、この出願は、特許請求の範囲およびその均等物によってのみ限定されることが明白に意図される。
【図面の簡単な説明】
【００３０】
【図１】本発明の一実施形態による、衛星処理システムハードウェア層の説明図である。
【図２Ａ】本発明の一実施形態による、インターフェーシング・ソフトウェアスタックの説明図である。
【図２Ｂ】本発明の一実施形態による、インターフェーシング・ソフトウェアスタックの周辺装置ドライバの説明図である。
【図３】本発明の一実施形態による方法を示すフローチャートである。
【図４】本発明の別の実施形態による方法を示すフローチャートである。
【図１】
2009508225.tif 000003
【図２Ａ】
2009508225.tif 000004
【図２Ｂ】
2009508225.tif 000005
【図３】
2009508225.tif 000006
【図４】
2009508225.tif 000007
【国際調査報告】
2009508225.tif 000008
2009508225.tif 000009
2009508225.tif 000010