JP7046862B2

JP7046862B2 - アプリケーション実行装置およびアプリケーション実行方法

Info

Publication number: JP7046862B2
Application number: JP2019064876A
Authority: JP
Inventors: 成昊金; 祐策大塚
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2019-03-28
Filing date: 2019-03-28
Publication date: 2022-04-04
Anticipated expiration: 2039-03-28
Also published as: JP2020166427A; EP3716061B1; US11106395B2; US20200310693A1; EP3716061A1

Description

本発明はアプリケーション実行装置およびアプリケーション実行方法に関し、例えばＩＯ装置から送信されたデータを取得するデータ取得部と、前記データ取得部により取得されたデータを活用するデータ活用部とを含んで構成されるアプリケーションを実行するアプリケーション実行装置およびアプリケーション実行方法に適用して好適なものである。

従来、リアルタイムシステムにおけるコントローラ上のアプリケーション（リアルタイムアプリケーション）のリアルタイム性を保証するために、専用のＲＴＯＳ（Real Time Operating System）を採用し、アプリケーションのリアルタイム性を保証している。また、アプリケーションでは、主に、アプリケーションへのデータの入力処理（データ取得）、当該データの演算処理、および演算結果の出力処理（データ活用）を行っている。

しかしながら、ＲＴＯＳは、リアルタイム性の保証に特化した機能しか持たず、近年のＩｏＴ（Internet of Things）に要求されている他の機器との接続性、データ処理のためのＡＩ（Artificial Intelligence）等の技術を実装（運用）できない。そのため、Linux（登録商標）等の汎用ＯＳ（Operating System）を採用したコントローラが普及している。

一方、汎用ＯＳは、多様な処理を行うため、リアルタイムアプリケーションのみならず他の機器との接続のためのアプリケーション、データ処理のためのアプリケーション、カーネル内のスレッド等が動作しているため、リアルタイムアプリケーションのリアルタイム性の保証が困難である。

リアルタイム性の保証のためには、アプリケーションの処理が決まった周期内で終了することを意味するデッドラインの保証と、アプリケーションが処理を開始するトリガとなるイベントが発生した時間からアプリケーションが処理を開始した時間までの時間差が予測できることを意味する定刻性の保証とが必要である。

デッドラインの保証のため、リアルタイムシステムにおいては、アプリケーションの設計時にアプリケーションの処理時間をデッドラインに対して所定の値（例えば、２０％）以下にする等して、デッドラインより十分小さく設定するのが通常である。それによって、汎用ＯＳを採用するコントローラ上でもデッドラインを満たすことができる。

しかしながら、定刻性の保証は、汎用ＯＳでは、他のアプリケーションの処理との干渉、カーネル内の処理との干渉によって大変困難である。この点、ある処理を主ＣＰＵではなく、子プロセッサにオフロードすることで、他の処理との干渉を回避する技術が知られている（特許文献１参照）。

特表２０１８－５１３４６３号公報

しかしながら、特許文献１に記載の技術では、オフロードする処理量がハードウェアに依存してしまい、多様なＩＯ処理を行うリアルタイムアプリケーションには適用が困難である。

汎用ＯＳ上で、多様なＩＯ処理を行うリアルタイムアプリケーションのリアルタイム性を保証するために、ハードウェアの要件に依存しないリアルタイムアプリケーションの実行方法を実現することが望まれる。特に、リアルタイムアプリケーションへの入力データを取りこぼさずに取得するためには、定刻性の保証が必須である。

本発明は以上の点を考慮してなされたもので、アプリケーションのリアルタイム性を満たすことができるアプリケーション実行装置を提案しようとするものである。

かかる課題を解決するため本発明においては、ＩＯ装置から送信されたデータを取得するデータ取得部と、前記データ取得部により取得されたデータを活用するデータ活用部とを含んで構成されるアプリケーションを実行するアプリケーション実行装置であって、前記アプリケーションを開始するイベントが発生してから前記アプリケーションが開始するまでの時間が前記アプリケーションに求められている時間を満たすことができる第１の空間で前記データ取得部を実行する第１の演算装置と、前記データ取得部で取得されたデータを前記データ活用部に連携するデータ連携部と、前記第１の空間とは異なる第２の空間で前記データ活用部を実行する第２の演算装置と、を設けるようにした。

上記構成では、例えば、定刻性を満たす演算装置にデータ取得部が配置され、他の処理との干渉によりデータの取得を開始できない事態を回避しているので、汎用ＯＳが設けられる装置であっても、汎用ＯＳでの性能の揺らぎを抑制でき、アプリケーションの定刻性を満たすことができる。

本発明によれば、アプリケーションのリアルタイム性を満たすことができるアプリケーション実行装置を実現することができる。

第１の実施の形態によるアプリケーション実行装置に係る構成の一例を示す図である。第１の実施の形態によるアプリケーション処理の構成とリアルタイム性を決める２つのパラメータとを示す図である。第１の実施の形態によるＩＯ管理テーブルの構成の一例を示す図である。第１の実施の形態によるモデルソースの構成の一例を示す図である。第１の実施の形態による関数テーブルの一例を示す図である。第１の実施の形態によるデータ活用部に係る処理の一例を示す図である。第１の実施の形態によるデータ連携部に係る処理の一例を示す図である。第１の実施の形態によるＩＯドライバ部に係る処理の一例を示す図である。第１の実施の形態によるユーザＩＦ部に係る処理の一例を示す図である。第１の実施の形態による生成部に係る処理の一例を示す図である。第１の実施の形態による関数解析部に係る処理の一例を示す図である。第１の実施の形態によるデータ取得部に係る処理の一例を示す図である。第１の実施の形態による管理部に係る処理の一例を示す図である。第２の実施の形態によるアプリケーション実行装置に係る構成の一例を示す図である。第２の実施の形態による生成部に係る処理の一例を示す図である。第２の実施の形態による関数解析部に係る処理の一例を示す図である。第３の実施の形態による生成部に係る処理の一例を示す図である。第３の実施の形態によるデッドライン判定処理に係るフローチャートの一例を示す図である。

以下図面について、本発明の一実施の形態を詳述する。本実施の形態は、アプリケーション（例えば、リアルタイムアプリケーション）のリアルタイム性を保証する技術に関するものである。例えば、本実施の形態では、アプリケーションをデータ取得部とデータ活用部とに分け、定刻性が求められるデータ取得部を他の処理との干渉を避けるため、他の処理との干渉が少ない空間（他のハードウェア、カーネルなど）にオフロードする。そして、オフロードされたデータ取得部は、取得したアプリケーションへの入力データをデータ活用部に渡し、データ活用部は、入力のデータの演算処理と演算結果の出力処理とを行う。

なお、以下の説明では、同種の要素を区別しないで説明する場合には、枝番を含む参照符号のうちの共通部分（枝番を除く部分）を使用し、同種の要素を区別して説明する場合は、枝番を含む参照符号を使用することがある。例えば、ＣＰＵを特に区別しないで説明する場合には、「ＣＰＵ１１０」と記載し、個々のＣＰＵを区別して説明する場合には、「ＣＰＵ１１０－１」、「ＣＰＵ１１０－２」のように記載することがある。

（１）第１の実施の形態
図１において、１００は全体として第１の実施の形態によるアプリケーション実行装置を示す。

図１は、アプリケーション実行装置１００に係る構成の一例を示す図である。

アプリケーション実行装置１００は、演算装置１０１と記憶装置１０２とを含んで構成される。アプリケーション実行装置１００は、ネットワーク装置（ＮＷ装置）１０３を介してネットワーク１０５に接続し、ＩＯ装置１０４からのデータを取得する。ネットワーク１０５は、シリアル通信、並列通信、Ethernet（登録商標）等であり、１以上のＩＯ装置１０４と演算装置１０１との接続を形成している。ＩＯ装置１０４は、例えば、各種のセンサである。

演算装置１０１は、各種のプログラムを実行する。演算装置１０１は、１以上のＣＰＵ（Central Processing Unit）１１０と、１以上のＦＰＧＡ（Field-Programmable Gate Array）１１１を備える。演算装置１０１は、ＮＷ装置１０３を通じて、アプリケーションで用いるデータを提供するＩＯ装置１０４とネットワーク１０５で接続されている。なお、演算装置１０１は、ＣＰＵ１１０、ＦＰＧＡ１１１に限るものではなく、ＧＰＵ（Graphics Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）などの１以上の他の半導体を備えていてもよい。

記憶装置１０２は、プログラムおよびプログラムの実行に必要なデータを格納する。記憶装置１０２は、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）などである。

次に、アプリケーション実行装置１００の機能構成について説明する。

アプリケーション実行装置１００は、ＯＳ１２０と、アプリケーション部１３０と、生成部１４０と、モデルソース１５０と、合成ソース１６０と、データ取得部１７０とを備える。

ＯＳ１２０は、Linux（登録商標）、WINDOWS（登録商標）のような汎用ＯＳであり、汎用ＯＳが備える機能を有する。アプリケーション部１３０は、ＯＳ１２０が管理するプロセス単位でＯＳ１２０によって実行される。生成部１４０は、モデルソース１５０から合成ソース１６０を生成し、生成した合成ソース１６０をコンパイルしてデータ取得部１７０を生成する。データ取得部１７０は、ＮＷ装置１０３を通じてＩＯ装置１０４からのデータを取得する。データ取得部１７０は、データ取得の定刻性を保証するため、ＦＰＧＡ１１１にオフロード（配置）され、ＦＰＧＡ１１１によって実行される。

より具体的には、ＯＳ１２０は、ＯＳ連携部１２１と、ＩＯ管理テーブル１２２と、ＩＯドライバ部１２３と、管理部１２４と、オフロード部１２５とを備える。アプリケーション部１３０は、データ活用部１３１と、データ連携部１３２と、データ格納部１３３とを備える。生成部１４０は、関数テーブル１４１と、関数解析部１４２とを備える。

（準備段階：ＯＳ１２０およびアプリケーション部１３０間のデータの連携）
ＯＳ連携部１２１は、データ取得部１７０により取得されたデータを格納する。ＯＳ連携部１２１は、アプリケーション部１３０のデータ連携部１３２によってアプリケーション部１３０のデータ格納部１３３と接続される。そのため、ＯＳ連携部１２１に格納されるデータは、データ格納部１３３にコピーなしで反映される。

より具体的には、データ連携部１３２がＯＳ１２０内のＩＯドライバ部１２３のユーザＩＦ部１２３Ａを呼び出すと、ＩＯドライバ部１２３がＯＳ１２０の機能であるメモリマップ機能を用い、データ格納部１３３のメモリをＯＳ１２０内のメモリの番地にマップする。かかる処理により、データ連携部１３２とＯＳ連携部１２１とが接続される。換言するならば、データ格納部１３３とＯＳ連携部１２１とは同じメモリを共有している。ただし、アプリケーション実行装置１００では、データ格納部１３３とＯＳ連携部１２１との接続方法については限定しない。

（準備段階：データ取得部１７０の生成）
以下では、ＦＰＧＡ１１１が実行できるデータ取得部１７０を生成する方法について説明する。

モデルソース１５０は、アプリケーションの開発者によって作成される。ただし、アプリケーション実行装置１００では、作成言語は限定しない。モデルソース１５０は、３つ構成を有している。アプリケーションの開発者が作成するのは、図４に示すデータ取得処理（記述部４３０）である。なお、ＩＯ装置１０４からのデータを取得するためのＩＯ装置１０４とのインターフェース処理（記述部４２０）、およびデータ活用部１３１とのインターフェース処理（記述部４１０）は、モデルソース１５０に記述されている。その詳細については、後述する。

データ取得部１７０を生成するために、生成部１４０は、モデルソース１５０を入力とし、入力したモデルソース１５０と関数テーブル１４１との合成を行い、合成ソース１６０を生成する。

関数解析部１４２は、合成ソース１６０を解析し、合成ソース１６０を更新する。より具体的には、関数解析部１４２は、ＩＯ装置１０４とのインターフェース処理の関連関数（後述のGET_IN関数）を読み出し、ＩＯ管理テーブル１２２を用い、ＮＷ装置１０３のメモリを読み出すような処理に置き換える（図１１を参照）。また、関数解析部１４２は、データ活用部１３１とのインターフェース処理の関連関数（後述のSET_OUT関数）を読み出し、ＩＯ管理テーブル１２２を用い、ＯＳ連携部１２１のメモリへ書き出すような処理に置き換える（図１１を参照）。

生成部１４０は、更新した合成ソース１６０をＦＰＧＡ１１１で実行可能なファイルにコンパイルし、データ取得部１７０を生成する。生成したデータ取得部１７０は、ＯＳ１２０内部のオフロード部１２５によりＦＰＧＡ１１１に書き込まれる。

（運用段階）
データ取得部１７０は、データを取得すると、ＯＳ連携部１２１にデータを格納し、演算装置１０１に対して割込みをあげる。割込みは、ＯＳ１２０で処理され、その結果、ＯＳ１２０は、ＯＳ１２０内の管理部１２４を起動する。管理部１２４は、アプリケーション部１３０のデータ活用部１３１を実行するために最優先してスケジュールする。

データ活用部１３１は、データ取得部１７０からデータ格納部１３３に格納されたデータについて演算（分析など）し、演算結果を出力する。ただし、アプリケーション実行装置１００では、演算結果の出力先については、限定しない。

図２は、アプリケーションが実行する処理（アプリケーション処理）の構成とリアルタイム性を決める２つのパラメータ（デッドライン２０１および定刻性２０２）とを示す図である。例えば、アプリケーションは、データ取得部１７０と、データ活用部１３１とを含んで構成される。

アプリケーション処理は、主に、アプリケーションにデータを入力する入力処理と、入力したデータを演算する演算処理と、演算した結果（演算結果）を出力する出力処理とを含んで構成される。

リアルタイム性の保証のためには、アプリケーション処理が決まった周期内で終了することを意味するデッドライン２０１の保証と、アプリケーション処理を開始するトリガとなるイベントが発生した時間からアプリケーション処理を開始した時間までの時間差が予測できることを意味する定刻性２０２の保証とが必要である。

本実施の形態では、アプリケーション処理の開始の入力処理をデータ取得部１７０に担当させ（割り当て）、データ取得部１７０をＦＰＧＡ１１１にオフロードし、処理することで、定刻性を保証する。また、演算処理と出力処理とをデータ活用部１３１に担当させ、管理部１２４で、高優先度でデータ活用部１３１の処理を行うことで、アプリケーション処理のデッドラインを保証する。

図３は、ＩＯ管理テーブル１２２の構成の一例を示す図である。ＩＯ管理テーブル１２２は、ＩＯ情報を管理するテーブルである。

ＯＳ１２０は、Linuxと同様に、ＩＯ装置１０４を制御するドライブの管理などを容易にするためにDevice Treeの仕組みを有している。Device Treeは、ハードウェアに係る情報を記述したデータ構造体である。Device Treeは、例えば、演算装置１０１内のＣＰＵ１１０、ＦＰＧＡ１１１、演算装置１０１と接続しているＮＷ装置１０３の割込み制御用番号（割込み識別子）、ＯＳ１２０とのデータアクセス用のメモリの番地（アドレス範囲）の情報などを提供している。

ＩＯドライバ部１２３は、ＯＳ１２０の機能を用い、Device Treeから、割込み制御用番号と、データアクセス用のメモリの番地との情報を取得し、それぞれ、ＩＯ識別子３０１と割込み識別子３０２とアドレス範囲３０３とに格納する。

ＩＯ管理テーブル１２２に格納された情報は、生成部１４０によりＩＯドライバ部１２３のユーザＩＦ部１２３Ａが用いられて取得される。

図４は、モデルソース１５０の構成の一例を示す図である。

モデルソース１５０は、記述部を３つ含んで構成される。より具体的には、データ活用部１３１にデータを提供するための処理「データ活用部とのインターフェース処理（OUT）」が記述される記述部４１０と、ＩＯ装置１０４からのデータを取得するＮＷ装置１０３からデータを取得するための処理「ＩＯ装置とのインターフェース処理（IN）」が記述される記述部４２０と、「ＩＯ装置とのインターフェース処理（IN）」を用いて実際にデータ取得し、「データ活用部とのインターフェース処理（OUT）」を用いてデータ活用部１３１にデータを提供する処理「データ取得処理」を記述する記述部４３０とから構成されている。

記述部４１０には、後述する関数テーブル１４１の関数（SET_OUT関数）の呼出しが記述される。記述部４２０には、後述する関数テーブル１４１の関数（GET_IN関数）の呼出しが記述される。データ取得処理の記述部４３０は、アプリケーションの開発者によって作成される。

なお、ＩＯ装置１０４とのインターフェース処理の関連関数（GET_IN関数）、およびデータ活用部１３１とのインターフェース処理の関連関数（SET_OUT関数）の具体的な処理内容は、後述するように、生成部１４０の処理によって置き換える。

図５は、関数テーブル１４１の一例を示す図である。

関数テーブル１４１を構成する関数は、例えば、プログラミング言語において予め用意された標準で使用できる関数（built-in関数）であり、モデルソース１５０で呼び出される処理として参照される。

GET_IN関数５１０は、モデルソース１５０の「ＩＯ装置とのインターフェース処理（IN）」で呼び出される関数である。SET_OUT関数５２０は、モデルソース１５０の「データ活用部とのインターフェース処理（OUT）」で呼び出される関数である。

図６は、データ活用部１３１に係る処理の一例を示す図である。

ステップＳ６１０では、データ活用部１３１は、データ連携部１３２に対し、ＯＳ連携部１２１との連携を要求（連携要求）する。なお、ステップＳ６１０は、ユーザ（例えば、アプリケーションの開発者、環境構築者、運用者など）の指示を契機に実行される。

ステップＳ６１０は、データ活用部１３１がデータ取得部１７０からのデータを取得するために、データ取得部１７０がＮＷ装置１０３から取得したデータを格納するＯＳ連携部１２１をデータ活用部１３１からアクセスできるようにするための準備段階のステップである。なお、ステップＳ６２０～ステップＳ６３０は、運用段階のステップである。

ステップＳ６２０では、データ活用部１３１は、データ取得処理を行う。例えば、データ活用部１３１は、ＯＳ連携部１２１からデータ取得する。

ステップＳ６３０では、データ活用部１３１は、ステップＳ６２０で取得したデータの演算処理を行う。

ステップＳ６４０では、データ活用部１３１は、ステップＳ６３０の演算結果の出力処理を行い、ステップＳ６２０に処理を移す。出力先は、ＡＩ等のデータ処理を行う別のアプリケーションでもよい。なお、アプリケーション実行装置１００では、出力先については限定しない。

図７は、データ連携部１３２に係る処理の一例を示す図である。かかる処理は、データ連携のための準備段階の処理であり、ステップＳ６１０の連携要求を契機に開始する。

ステップＳ７１０では、データ連携部１３２は、ＯＳ連携部１２１と連携するデータ格納部１３３の初期化（例えば、クリア）を行う。

ステップＳ７２０では、データ連携部１３２は、ユーザＩＦ部１２３Ａを呼び出し、データ格納部１３３をＯＳ連携部１２１と接続するための要求（接続要求）をする。なお、呼出しは、後述するステップＳ９２０およびステップＳ９３０にて処理される。アプリケーション実行装置１００では、ＯＳ１２０のアプリケーション側のメモリをＯＳ１２０内のメモリの番地にマップするメモリマップ機能を用い、データ格納部１３３とＯＳ連携部１２１との接続を行う。つまり、データ格納部１３３とＯＳ連携部１２１とは、同じメモリを共有することになる。

ステップＳ７３０では、データ連携部１３２は、データ格納部１３３とＯＳ連携部１２１との接続の結果（ＯＫ、ＮＧ等）をデータ活用部１３１に返す。

図８は、ＩＯドライバ部１２３に係る処理の一例を示す図である。かかる処理は、データ連携のための準備段階の処理であり、例えば、ユーザの指示を契機に開始される。

ステップＳ８１０では、ＩＯドライバ部１２３は、DEVICE TREEの情報を読み込む。

DEVICE TREEは、ＯＳ１２０が提供するデバイス制御のための割込み、制御、データアクセス用のメモリの番地等の情報を提供する仕組みである。なお、アプリケーション実行装置１００では、デバイス制御のための情報の取得先をDEVICE TREEに限定しない。

ステップＳ８２０では、ＩＯドライバ部１２３は、ステップＳ８１０で読み込んだDEVICE TREEの情報から、ＮＷ装置１０３の識別子、割込み識別子、アドレス範囲を読み込み、ＩＯ管理テーブル１２２に格納する。

ステップＳ８３０では、ＩＯドライバ部１２３は、ステップＳ８１０で読み込んだDEVICE TREEの情報から、ＦＰＧＡ１１１の識別子、割込み識別子、アドレス範囲を読み込み、ＩＯ管理テーブル１２２に格納する。

ステップＳ８４０では、ＩＯドライバ部１２３は、ＦＰＧＡ１１１の割込み識別子をもって、ＦＰＧＡ１１１からの割込みを処理する割込みハンドラーをＯＳ１２０に登録する。ＦＰＧＡ１１１にオフロードさせるデータ取得部１７０でデータの取得が完了したとき、または、定期的なタイマーイベント等をＯＳ１２０に知らせる手段として割込みを利用する。その割込みをＯＳ１２０で処理するための割込みハンドラーを登録するステップである。登録された割込みハンドラーの処理時に、後述する管理部１２４をトリガする。

図９は、ユーザＩＦ部１２３Ａに係る処理の一例を示す図である。ユーザＩＦ部１２３Ａは、接続要求、ＩＯ管理テーブル１２２のＩＯ情報の取得要求などに対する処理を行う（ユーザＩＦを提供する）。

ステップＳ９１０では、ユーザＩＦ部１２３Ａは、データ格納部１３３とＯＳ連携部１２１との接続要求であるか否かを判定する。ユーザＩＦ部１２３Ａは、接続要求であると判定した場合、ステップＳ９２０に処理を移し、接続要求でないと判定した場合、ステップＳ９４０に処理を移す。

ステップＳ９２０では、ユーザＩＦ部１２３Ａは、データ格納部１３３とＯＳ連携部１２１とを接続する。例えば、ユーザＩＦ部１２３Ａは、ＯＳ１２０のアプリケーション側のメモリの番地をＯＳ１２０内のメモリの番地にマップするメモリマップ機能を用い、データ格納部１３３とＯＳ連携部１２１との接続を行う。なお、マップされたメモリの番地の情報は、データ連携部１３２に提供される。

ステップＳ９３０では、ユーザＩＦ部１２３Ａは、ＯＳ連携部１２１の情報をＩＯ管理テーブル１２２に格納する。ＩＯ識別子３０１には「ＯＳ連携部」、割込み識別子３０２には、管理部１２４をトリガする割込み番号を登録する。また、アドレス範囲３０３には、データ格納部１３３のメモリをＯＳ１２０内のメモリの番地にマップしたメモリの番地（アドレスの範囲）を登録する。なお、ＯＳ連携部１２１の情報は、例えば、後述するステップＳ１１４０において生成部１４０によって、モデルソース１５０の構成の中の「データ活用部とのインターフェース処理（OUT）」の処理を実現するにあたって、利用される。

ステップＳ９４０では、ユーザＩＦ部１２３Ａは、ユーザＩＦの呼び先からのＩＯ識別子の情報と一致する、ＩＯ管理テーブル１２２の該当ＩＯの情報を返す。後述する生成部１４０の処理において、関数テーブル１４１の「GET_IN関数」と「SET_OUT関数」を実現するために必要な、ＮＷ装置１０３とＯＳ連携部１２１とのＩＯ情報の取得要求を処理するステップである。例えば、生成部１４０からの要求、より具体的には、関数解析部１４２の要求の際には、ＩＯ識別子情報として「ＮＷ装置」または「ＯＳ連携部」が指定される。

図１０は、生成部１４０に係る処理の一例を示す図である。かかる処理は、データ取得部１７０の生成のための準備段階の処理であり、例えば、ユーザの指示を契機に開始される。

ステップＳ１０１０では、生成部１４０は、モデルソース１５０を読み込む。なお、モデルソース１５０は、アプリケーションの開発者が作成するものであり、図４にモデルソース１５０の一例を示した。

ステップＳ１０２０では、生成部１４０は、関数テーブル１４１（built-in関数）を読み込み、モデルソース１５０と合成し、合成ソース１６０を生成する。

ステップＳ１０３０では、生成部１４０は、合成ソース更新処理を行う。合成ソース更新処理では、関数解析部１４２を呼び出し、ＮＷ装置１０３からのデータを取得するためのＩＯ装置１０４とのインターフェース処理のための処理と、ＯＳ連携部１２１にデータを書き込むためのデータ活用部１３１とのインターフェース処理とを完成し、合成ソース１６０を更新する。なお、詳細については、図１１を用いて後述する。

ステップＳ１０４０では、生成部１４０は、ＦＰＧＡ１１１で動作可能な実行ファイルを生成するために、ステップＳ１０３０で更新した合成ソース１６０をコンパイルし、データ取得部１７０を生成する。アプリケーション実行装置１００では、合成ソース１６０から実行ファイルを生成するコンパイラは限定しない。

ステップＳ１０５０では、生成部１４０は、オフロード部１２５を呼び出し、データ取得部１７０をＦＰＧＡ１１１へ書き込む。アプリケーション実行装置１００では、オフロード部１２５は、ＯＳ１２０（汎用ＯＳ）で提供する機能を利用する。例えば、ＯＳ１２０では、ＦＰＧＡ１１１が有しているデータ取得部１７０の書込み領域をユーザアプリケーション側でも読み書き可能にするためにファイルシステムでマップされている。そのため、オフロード部１２５は、通常のファイル書込みでＦＰＧＡ１１１へオフロード可能である。

図１１は、関数解析部１４２に係る処理の一例（合成ソース更新処理）を示す図である。

ステップＳ１１１０では、関数解析部１４２は、合成ソース１６０からGET_IN関数を検索する。

ステップＳ１１２０では、関数解析部１４２は、ＩＯドライバ部１２３のユーザＩＦ部１２３Ａを呼び出し、ＩＯ管理テーブル１２２からＮＷ装置１０３のアドレス範囲を読み出し、読み出したアドレス範囲のアドレスからデータを取得する処理を書き出し、合成ソース１６０のGET_IN関数（記述部４２０）を置き換える。ＩＯ装置１０４からのデータをＮＷ装置１０３が取得し、ＮＷ装置１０３が取得したデータをデータ取得部１７０が取得するための処理を実現するステップである。なお、ＩＯ管理テーブル１２２からＮＷ装置１０３のアドレス範囲を読み出しは、「ＮＷ装置」の指定を含むＩＯ情報の取得要求により行われる。

ステップＳ１１３０では、関数解析部１４２は、合成ソース１６０からSET_OUT関数を検索する。

ステップＳ１１４０では、関数解析部１４２は、ＩＯドライバ部１２３のユーザＩＦ部１２３Ａを呼び出し、ＩＯ管理テーブル１２２からＯＳ連携部１２１のアドレス範囲を読み出し、読み出したアドレス範囲のアドレスにデータを書き込む処理を書き出し、合成ソース１６０のSET_OUT関数（記述部４１０）を置き換える。なお、ＩＯ管理テーブル１２２からＯＳ連携部１２１のアドレス範囲を読み出しは、「ＯＳ連携部」の指定を含むＩＯ情報の取得要求により行われる。

図１２は、データ取得部１７０に係る処理の一例を示す図である。データ取得部１７０は、オフロード部１２５によりＦＰＧＡ１１１に書き込みされて、ＦＰＧＡ１１１上で動作する。

ステップＳ１２１０では、データ取得部１７０は、ＮＷ装置１０３のアドレスにデータが格納されたかを確認する。

ステップＳ１２２０では、データ取得部１７０は、ＮＷ装置１０３のアドレスにデータ（入力データ）があるか否かを判定する。データ取得部１７０は、入力データがあると判定した場合、ステップＳ１２３０に処理を移し、入力データがないと判定した場合、ステップＳ１２１０に処理を移す。

ステップＳ１２３０では、データ取得部１７０は、ＮＷ装置１０３のアドレスからデータを読み取り、ＯＳ連携部１２１に格納し、ＯＳ連携部１２１と接続されているデータ格納部１３３のデータを更新する。

ステップＳ１２４０では、データ取得部１７０は、ＯＳ１２０に割込みを発生させ、ステップＳ８４０で登録された割込みハンドラーを呼び出し、管理部１２４を呼び出す。

図１３は、管理部１２４に係る処理の一例を示す図である。かかる処理は、割込みハンドラーにより呼び出されたことを契機に開始する。

ステップＳ１３１０では、管理部１２４は、アプリケーション部１３０の優先度を高優先度（例えば、最高優先度）に変更する。アプリケーション部１３０のデータ活用部１３１の処理を優先させるためのステップである。データ活用部１３１の処理を優先することによってアプリケーション処理のデッドラインを満たすことができる。

ステップＳ１３２０では、管理部１２４は、アプリケーション部１３０をスケジュールする。ステップＳ１３１０で高優先度化されたアプリケーション部１３０のジョブは、ＯＳ１２０が有しているスケジュールキューの最初に位置することになる。ＣＰＵ１１０は、管理部１２４のスケジュールキューの先頭のジョブを選択して実行する。アプリケーション部１３０がスケジュールされると、データ活用部１３１の処理（例えば、ステップＳ６２０～ステップＳ６４０）が実行される。

上述した構成では、アプリケーションのデータ取得部が、多様な処理を行う汎用ＯＳを実現するＣＰＵではなく、ＦＰＧＡで実現されているので、コンピュータにおいて、アプリケーション処理の定刻性を保証することができる。

また、上述した構成では、アプリケーションのデータ活用部のジョブが優先的にＣＰＵで処理されるので、アプリケーション処理のデッドラインを満たすことができる。

本実施の形態によれば、汎用ＯＳを備える装置においてアプリケーションのリアルタイム性を保証することができる。

（２）第２の実施の形態
本実施の形態では、ユーザが指定したオフロード先にデータ取得部１７０をオフロードする点が第１の実施の形態と主に異なる。本実施の形態では、第１の実施の形態と異なる構成について主に説明する。

図１４は、本実施の形態のアプリケーション実行装置１４００に係る構成の一例を示す図である。

第１の実施の形態では、データ取得部１７０をＦＰＧＡ１１１にオフロードする構成について説明した。本実施の形態では、オフロード部１２５にオフロード先を選択可能な機能（ＦＰＧＡ部１４１０Ａ、カーネル部１４１０Ｂ、ＣＰＵ部１４１０Ｃ）を取り入れることで、オフロード先として、ＦＰＧＡ１１１のみならず、ＣＰＵ１１０、ＯＳ１２０のカーネル（カーネルモジュール）としてＯＳ１２０の内部にオフロードが可能である。

例えば、モデルソース１５０に関数テーブル１４１のSET_TYPEを記述するための記述部を設け、当該記述部にオフロード先を指定し、関数解析部１４２において、モデルソース１５０の記述部４１０（SET_OUT関数）および記述部４２０（GET_IN関数）がオフロード先に合わせた処理に変換され、合成ソース１６０が生成される。生成された合成ソース１６０がコンパイルされてデータ取得部１７０が生成され、データ取得部１７０がオフロード先にオフロードされる。

次に、データ取得部１７０をＯＳ１２０のカーネルにオフロードする構成の詳細について説明する。

ここで、本実施の形態において想定するＯＳ１２０のカーネルは、例えば、LinuxのeBPF（extended Berkeley Packet Filter）と同じ機能を有している。通常、Linuxでは、ＮＷ装置１０３からのデータ取得は、ＮＷ処理モジュールにて処理される。eBPFは、データ取得の際に、ユーザ指定の処理をするための仕組みを提供しており、その仕組みを用いてユーザ指定の処理を登録するができる。そのため、ＯＳ１２０のカーネルとしてＯＳ１２０の内部へオフロードするためには、関数解析部１４２の処理においてデータ取得部１７０の処理をeBPFが提供するユーザ処理として変換すればよい。

図１５は、生成部１４０に係る処理（データ取得部１７０をＯＳ１２０のカーネルにオフロードするための処理）の一例を示す図である。

ステップＳ１５１０では、生成部１４０は、モデルソース１５０を読み込む。

ステップＳ１５２０では、生成部１４０は、関数テーブル１４１（built-in関数）を読み込み、モデルソース１５０と合成し、合成ソース１６０を生成する。

ステップＳ１５３０では、生成部１４０は、合成ソース更新処理を行う。合成ソース更新処理では、関数解析部１４２を呼び出し、ＮＷ装置１０３からのデータを取得するためのＩＯ装置１０４とのインターフェース処理のための処理と、ＯＳ連携部１２１にデータを書き込むためのデータ活用部１３１とのインターフェース処理とを完成し、合成ソース１６０を更新する。なお、詳細については、図１６を用いて後述する。

ステップＳ１５４０では、生成部１４０は、ＯＳ１２０のカーネル（内部モジュール）として動作可能な実行ファイルを生成するために、ステップＳ１５３０で更新した合成ソース１６０をコンパイルし、データ取得部１７０を生成する。アプリケーション実行装置１４００では、合成ソース１６０から実行ファイルを生成するコンパイラは限定しない。

ステップＳ１５５０では、生成部１４０は、オフロード部１２５のカーネル部１４１０Ｂを呼び出し、データ取得部１７０をＯＳ１２０のカーネルとしてロードする。アプリケーション実行装置１４００では、前述のようにeBPFのモジュールを生成する。eBPFのモジュール用のコンパイラは、Linuxで提供されているものを使用してもよい。

図１６は、関数解析部１４２に係る処理の一例（合成ソース更新処理）を示す図である。

ステップＳ１６１０では、関数解析部１４２は、合成ソース１６０からGET_IN関数を検索する。

ステップＳ１６２０では、関数解析部１４２は、ＮＷ装置１０３からデータを取得するＯＳ１２０のカーネルにデータを取得する処理を登録する処理を書き出し、合成ソース１６０のGET_IN関数（記述部４２０）を置き換える。ＩＯ装置１０４からのデータをＮＷ装置１０３が取得し、ＮＷ装置１０３が取得したデータをデータ取得部１７０が取得するための処理を実現するステップである。

ステップＳ１６３０では、関数解析部１４２は、合成ソース１６０からSET_OUT関数を検索する。

ステップＳ１６４０では、関数解析部１４２は、ＩＯドライバ部１２３のユーザＩＦ部１２３Ａを呼び出し、ＩＯ管理テーブル１２２からＯＳ連携部１２１のアドレス範囲を読み出し、読み出したアドレス範囲のアドレスにデータを書き込む処理を書き出し、合成ソース１６０のSET_OUT関数（記述部４１０）を置き換える。

なお、本実施の形態では、データ取得部１７０をカーネルにオフロードする例を説明したが、データ取得部１７０をＣＰＵ１１０にオフロードする場合の原理は、ＦＰＧＡ１１１、ＯＳ１２０のカーネル等にオフロードする場合と同様であるので、その説明については省略する。

上述した構成では、アプリケーション空間（ユーザ空間）ではなく、カーネル空間にデータ取得部１７０がオフロードされるので、ＩＯ装置１０４からのデータの取得をカーネル空間で行うことができ、空間の移動にかかるオーバヘッドを排除することができる。なお、アプリケーション空間は、アプリケーションに割り当てられる計算リソースであり、実行しているアプリケーションが直接アクセス可能なリソースである。カーネル空間は、カーネルに割り当てられる計算リソースであり、アプリケーションが直接アクセスできないリソースである。

上述した構成では、モデルソース１５０と関数テーブル１４１とにより、オフロード先を指定することができ、ユーザは、オフロード先に依存しないデータ取得部１７０の処理（記述部４３０）を書くことができる。

本実施の形態によれば、オフロード先を指定することで、指定したオフロード先に対応したデータ取得部が生成されるので、ユーザは、所望のオフロード先にデータ取得部を容易にオフロードすることができる。

（３）第３の実施の形態
本実施の形態では、適切なオフロード先を生成部１４０が決定する点が第１の実施の形態と主に異なる。本実施の形態では、第１の実施の形態と異なる構成について主に説明する。

図１７は、生成部１４０に係る処理の一例（オフロード先を決定する処理）を示す図である。

ステップＳ１７１０では、生成部１４０は、許容するデッドラインの情報（許容デッドライン情報）を読み込む。例えば、許容デッドライン情報は、アプリケーションの開発者により、モデルソース１５０に設定される。許容デッドライン情報は、許容するデッドラインの値であってもよいし、範囲であってもよい。

ステップＳ１７２０では、生成部１４０は、デッドライン判定処理を行う。デッドライン判定処理では、アプリケーション処理がデッドラインを満たすか否か（ＣＰＵ１１０にデータ取得部１７０をオフロードしたときにデッドラインを超えるか否か）が判定される。なお、デッドライン判定処理の詳細については、図１８を用いて後述する。

ステップＳ１７３０では、生成部１４０は、デッドラインを超えると判定した場合（後述のデッドライン判定の結果がＮＧ）、ステップＳ１７８０に処理を移し、デッドラインを超えないと判定した場合（後述のデッドライン判定の結果がＯＫ）、ステップＳ１７４０に処理を移す。

ステップＳ１７４０では、生成部１４０は、ＣＰＵ１１０のコア数が２以上（複数）であるか否かを判定する。生成部１４０は、２以上であると判定した場合、ステップＳ１７５０に処理を移し、２以上でないと判定した場合、ステップＳ１７７０に処理を移す。

ステップＳ１７５０では、生成部１４０は、ＣＰＵ１１０が仮想化機能を搭載しているか否かを判定する。生成部１４０は、ＣＰＵ１１０が仮想化機能を搭載していると判定した場合、ステップＳ１７６０に処理を移し、ＣＰＵ１１０が仮想化機能を搭載していないと判定した場合、ステップＳ１７７０に処理を移す。

ステップＳ１７６０では、生成部１４０は、データ取得部１７０を専用コアにオフロードすると決定し、処理を終了する。例えば、第１のロジカルパーティションにＯＳ１２０を実行する第１のＣＰＵコアが割り当てられ、第２のロジカルパーティションに第２のＣＰＵコアが割り当てられているとき、生成部１４０は、第２のＣＰＵコアにオフロードすると決定する。なお、生成部１４０は、続いて、図１０、図１５等と同様に、データ取得部１７０を生成する。例えば、生成部１４０は、関数解析部１４２を呼び出し、ＮＷ装置１０３からのデータを取得するためのＩＯ装置１０４とのインターフェース処理のための処理と、ＯＳ連携部１２１にデータを書き込むためのデータ活用部１３１とのインターフェース処理とを完成し、合成ソース１６０を更新し、専用コアで動作可能な実行ファイルを生成するために、更新した合成ソース１６０をコンパイルし、データ取得部１７０を生成する。

ステップＳ１７７０では、生成部１４０は、データ取得部１７０をカーネルにオフロードすると決定し、処理を終了する。なお、生成部１４０は、続いて、図１５の処理を行う。

ステップＳ１７８０では、生成部１４０は、データ取得部１７０をＦＰＧＡ１１１にオフロードすると決定し、処理を終了する。なお、生成部１４０は、続いて、図１０の処理を行う。

図１８は、デッドライン判定処理に係るフローチャートの一例を示す図である。

ステップＳ１８１０では、生成部１４０は、合成ソース更新処理後の合成ソース１６０を参照し、ベーシックブロック（ＩＦ文などの分岐がない処理のブロック）単位でステップ数を算出する。

ステップＳ１８２０では、生成部１４０は、性能実績値１８０１を読み出す。性能実績値１８０１は、ＣＰＵ１１０の性能値の平均、分散などであり、これくらいのステップ数ならこれくらいの時間がかかるといった情報である。なお、性能実績値１８０１は、ＣＰＵ１１０の性能を測るベンチマークツール等により取得され、記憶装置１０２に登録されているものとする。

ステップＳ１８３０では、生成部１４０は、性能実績値１８０１およびステップ数からアプリケーション処理にかかる主な処理時間（処理量）を算出する。

ステップＳ１８４０では、生成部１４０は、処理時間にＩＯ処理時間を加算する。

ステップＳ１８５０では、生成部１４０は、処理時間にＩＯ処理時間を加算した時間にハードウェアディレイ値（レイテンシ）を加算し、アプリケーション処理時間を算出する。

ステップＳ１８６０では、生成部１４０は、許容デッドライン情報を参照し、アプリケーション処理時間がデッドラインを満たす否か（例えば、デッドライン≧アプリケーション処理時間であるか否か）を判定し、満たすと判定した場合、ＯＫを判定結果とし、満たさないと判定した場合、ＮＧを判定結果とし、処理を終了する。

本実施の形態によれば、適切なオフロード先が選定されてデータ取得部がオフロードされるので、演算装置の構成が異なるアプリケーション実行装置であっても適切にアプリケーションのリアルタイムを保証することができる。

（４）他の実施の形態
なお上述の実施の形態においては、本発明をアプリケーション実行装置に適用するようにした場合について述べたが、本発明はこれに限らず、この他種々のシステム、装置、方法、プログラムに広く適用することができる。

また、上述の実施の形態において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。

また、上述の実施の形態において、説明の便宜上、ＸＸテーブル、ＸＸファイルを用いて各種のデータを説明したが、データ構造は限定されるものではなく、ＸＸ情報などと表現してもよい。

また、上記の説明において、各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、本発明は、例えば、下記に示す特徴的な構成を有する。

ＩＯ装置（例えば、ＩＯ装置１０４）から送信されたデータを取得するデータ取得部（例えば、データ取得部１７０）と、上記データ取得部により取得されたデータを活用するデータ活用部（例えば、データ活用部１３１）とを含んで構成されるアプリケーションを実行するアプリケーション実行装置（例えば、アプリケーション実行装置１００、アプリケーション実行装置１４００）であって、上記アプリケーションを開始するイベントが発生してから上記アプリケーションが開始するまでの時間が上記アプリケーションに求められている時間を満たすことができる第１の空間（例えば、カーネル空間、ＦＰＧＡ１１１上）で上記データ取得部を実行する第１の演算装置（例えば、ＣＰＵ１１０、ＦＰＧＡ１１１。なお、ＧＰＵなどの他の演算装置であってもよい。）と、上記データ取得部で取得されたデータを上記データ活用部に連携するデータ連携部（例えば、データ連携部１３２）と、上記第１の空間とは異なる第２の空間（例えば、アプリケーション空間）で上記データ活用部を実行する第２の演算装置（例えば、ＣＰＵ１１０、ＦＰＧＡ１１１）と、を備えることを特徴とする。付言するならば、第１の演算装置と第２の演算装置とは、同じ演算装置であってもよいし、異なる演算装置であってもよい。また、上記第２の空間は、例えば、上記データ活用部の処理とは異なる他の処理（例えば、アプリケーション空間で実行される他のアプリケーションの処理、ＯＳ１２０が実行するカーネル内部の処理、ＩＯドライバ部１２３の処理）との干渉が上記第１の空間よりも多い空間である。

上記データ活用部とのインターフェース処理を指定する関数（例えば、SET_OUT関数）を示す第１の記述（例えば、記述部４１０）と、上記ＩＯ装置とのインターフェース処理を指定する関数（例えば、GET_IN関数）を示す第２の記述（例えば、記述部４２０）と、データ取得処理を示す第３の記述（例えば、記述部４３０）とを含むモデルソース（例えば、モデルソース１５０）から、上記第１の記述および上記第２の記述を上記第１の演算装置に対応した記述に変換した合成ソース（例えば、合成ソース１６０）を生成し、生成した合成ソースをコンパイルすることで上記データ取得部を生成する生成部（例えば、生成部１４０）を備えることを特徴とする。

上記構成では、例えば、データ活用部とのインターフェース処理を指定する関数と、ＩＯ装置とのインターフェース処理を指定する関数とを記述すると、第１の記述および第２の記述を第１の演算装置に対応した記述に変換した合成ソースが生成されるので、データ取得部を第１の演算装置に対応させるユーザの作業負担を軽減することができる。

なお、生成されたデータ取得部については、オフロード部（例えば、オフロード部１２５）により第１の演算装置にオフロードされてもよいし、ユーザにより手動で第１の演算装置に設けられてもよい。

上記データ活用部とのインターフェース処理を指定する関数を示す第１の記述と、上記ＩＯ装置とのインターフェース処理を指定する関数を示す第２の記述と、データ取得処理を示す第３の記述と、上記データ取得部を実行する演算装置を指定する第４の記述（例えば、SET_TYPEを記述するための記述部）を含むモデルソースから、上記第１の記述および上記第２の記述を上記第４の記述で指定された演算装置に対応した記述に変換した合成ソースを生成し、生成した合成ソースをコンパイルすることで上記データ取得部を生成する生成部（例えば、生成部１４０）を備える、ことを特徴とする。

上記構成では、例えば、演算装置を指定する第４の記述をすると、指定した演算装置に対応した合成ソースが生成されるので、データ取得部を指定した演算装置に対応させるユーザの作業負担を軽減することができる。

モデルソースから上記データ取得部を生成する生成部（例えば、生成部１４０）を備え、上記第２の演算装置は、上記第１の演算装置（例えば、ＣＰＵ１１０－２、ＦＰＧＡ１１１）とは異なる演算装置（例えば、ＣＰＵ１１０－１）であり、上記生成部は、上記データ取得部を上記第２の演算装置で実行可能であるか否かを判定し、上記第２の演算装置で上記データ取得部を実行できないと判定した場合、上記モデルソースを上記第１の演算装置に対応するように変更して上記データ取得部を生成する、ことを特徴とする。

上記構成では、例えば、第２の演算装置でデータ取得部を実行できない場合に、第１の演算装置で実行するようにしたので、第１の演算装置を無駄に利用する事態を低減することができる。

上記第２の演算装置には、オペレーティングシステム（例えば、ＯＳ１２０）が設けられ、上記生成部は、上記第２の演算装置で上記データ取得部を実行できると判定した場合、上記第２の演算装置が複数のコアを有しているか否かを判定し、上記第２の演算装置が複数のコアを有していないと判定した場合、上記モデルソースを上記オペレーティングシステムのカーネルに対応するように変更して上記データ取得部を生成する、ことを特徴とする。

上記構成によれば、例えば、第２の演算装置として、複数のコアを有していない演算装置を採用することができる。

上記生成部は、上記第２の演算装置が複数のコアを有していると判定した場合、上記データ取得部に専用のコアが設けられているか否かを判定し、専用のコアが設けられていると判定した場合、上記モデルソースを上記専用のコアに対応するように変更して上記データ取得部を生成する、ことを特徴とする。

上記構成では、例えば、第２の演算装置として、複数のコアを有している演算装置を採用することができる。

上記第２の空間で行われる処理のスケジュールを管理する管理部（例えば、管理部１２４）を備え、上記管理部は、上記データ活用部の処理を優先してスケジュールする、ことを特徴とする。

上記構成では、例えば、データ活用部の処理が優先して実行されるので、データ活用部の揺らぎを吸収（処理の開始までの時間を短縮）できるので、アプリケーションのデッドラインを満たさなくなる事態を回避できるようになる。

また上述した構成については、本発明の要旨を超えない範囲において、適宜に、変更したり、組み替えたり、組み合わせたり、省略したりしてもよい。

上記構成によれば、アプリケーションのリアルタイム性を満たすことができる。

１００……アプリケーション実行装置、１０１……演算装置、１３１……データ活用部、１３２……データ連携部、１７０……データ取得部。

Claims

ＩＯ装置から送信されたデータを取得するデータ取得部と、前記データ取得部により取得されたデータを活用するデータ活用部とを含んで構成されるアプリケーションを実行するアプリケーション実行装置であって、
前記アプリケーションに求められている時間内に、前記アプリケーションを開始するイベントが発生してから前記アプリケーションが開始できる、第１のハードウェアまたは第１のカーネルに割り当てられた第１の空間で、前記データ取得部を実行するように構成されている第１の演算装置と、
前記データ取得部で取得されたデータを前記データ活用部に連携するデータ連携部と、
前記第１の空間とは異なる空間であって、前記第１のハードウェアまたは前記第１のカーネルとは異なる第２のハードウェアまたは第２のカーネルに割り当てられた空間である第２の空間で、前記データ活用部を実行するように構成されている第２の演算装置と、
前記データ活用部とのインターフェース処理を指定する関数を示す第１の記述と、前記ＩＯ装置とのインターフェース処理を指定する関数を示す第２の記述と、データ取得処理を示す第３の記述とを含むモデルソースから、前記第１の記述および前記第２の記述を前記第１の演算装置に対応した記述に変換した合成ソースを生成し、生成した合成ソースをコンパイルすることで前記データ取得部を生成するように構成されている生成部と、
を備えるアプリケーション実行装置。
前記第２の空間で行われる処理のスケジュールを管理する管理部を備え、
前記管理部は、前記データ活用部の処理を優先してスケジュールする、
請求項１に記載のアプリケーション実行装置。
ＩＯ装置から送信されたデータを取得するデータ取得部と、前記データ取得部により取得されたデータを活用するデータ活用部とを含んで構成されるアプリケーションを実行するアプリケーション実行装置であって、
前記アプリケーションに求められている時間内に、前記アプリケーションを開始するイベントが発生してから前記アプリケーションが開始できる、第１のハードウェアまたは第１のカーネルに割り当てられた第１の空間で、前記データ取得部を実行するように構成されている第１の演算装置と、
前記データ取得部で取得されたデータを前記データ活用部に連携するデータ連携部と、
前記第１の空間とは異なる空間であって、前記第１のハードウェアまたは前記第１のカーネルとは異なる第２のハードウェアまたは第２のカーネルに割り当てられた空間である第２の空間で、前記データ活用部を実行するように構成されている第２の演算装置と、
前記データ活用部とのインターフェース処理を指定する関数を示す第１の記述と、前記ＩＯ装置とのインターフェース処理を指定する関数を示す第２の記述と、データ取得処理を示す第３の記述と、前記データ取得部を実行する演算装置を指定する第４の記述を含むモデルソースから、前記第１の記述および前記第２の記述を前記第４の記述で指定された演算装置に対応した記述に変換した合成ソースを生成し、生成した合成ソースをコンパイルすることで前記データ取得部を生成するように構成されている生成部と、
を備えるアプリケーション実行装置。
ＩＯ装置から送信されたデータを取得するデータ取得部と、前記データ取得部により取得されたデータを活用するデータ活用部とを含んで構成されるアプリケーションを実行するアプリケーション実行装置であって、
前記アプリケーションに求められている時間内に、前記アプリケーションを開始するイベントが発生してから前記アプリケーションが開始できる、第１のハードウェアまたは第１のカーネルに割り当てられた第１の空間で、前記データ取得部を実行するように構成されている第１の演算装置と、
前記データ取得部で取得されたデータを前記データ活用部に連携するデータ連携部と、
前記第１の空間とは異なる空間であって、前記第１のハードウェアまたは前記第１のカーネルとは異なる第２のハードウェアまたは第２のカーネルに割り当てられた空間である第２の空間で、前記データ活用部を実行するように構成されている第２の演算装置と、
モデルソースから前記データ取得部を生成する生成部と、を備え、
前記第２の演算装置は、前記第１の演算装置とは異なる演算装置であり、
前記生成部は、前記データ取得部を前記第２の演算装置で実行可能であるか否かを判定し、前記第２の演算装置で前記データ取得部を実行できないと判定した場合、前記モデルソースを前記第１の演算装置に対応するように変更して前記データ取得部を生成する、
アプリケーション実行装置。
前記第２の演算装置には、オペレーティングシステムが設けられ、
前記生成部は、前記第２の演算装置で前記データ取得部を実行できると判定した場合、前記第２の演算装置が複数のコアを有しているか否かを判定し、前記第２の演算装置が複数のコアを有していないと判定した場合、前記モデルソースを前記オペレーティングシステムのカーネルに対応するように変更して前記データ取得部を生成する、
請求項４に記載のアプリケーション実行装置。
前記生成部は、前記第２の演算装置が複数のコアを有していると判定した場合、前記データ取得部に専用のコアが設けられているか否かを判定し、専用のコアが設けられていると判定した場合、前記モデルソースを前記専用のコアに対応するように変更して前記データ取得部を生成する、
請求項５に記載のアプリケーション実行装置。
ＩＯ装置から送信されたデータを取得するデータ取得部と、前記データ取得部により取得されたデータを活用するデータ活用部とを含んで構成されるアプリケーションを実行するアプリケーション実行方法であって、
第１の演算装置が、前記アプリケーションに求められている時間内に、前記アプリケーションを開始するイベントが発生してから前記アプリケーションが開始できる、第１のハードウェアまたは第１のカーネルに割り当てられた第１の空間で、前記データ取得部を実行する第１のステップと、
データ連携部が、前記データ取得部で取得されたデータを前記データ活用部に連携する第２のステップと、
第２の演算装置が、前記第１の空間とは異なる空間であって、前記第１のハードウェアまたは前記第１のカーネルとは異なる第２のハードウェアまたは第２のカーネルに割り当てられた空間である第２の空間で、前記データ活用部を実行する第３のステップと、
生成部が、前記データ活用部とのインターフェース処理を指定する関数を示す第１の記述と、前記ＩＯ装置とのインターフェース処理を指定する関数を示す第２の記述と、データ取得処理を示す第３の記述とを含むモデルソースから、前記第１の記述および前記第２の記述を前記第１の演算装置に対応した記述に変換した合成ソースを生成し、生成した合成ソースをコンパイルすることで前記データ取得部を生成する第４のステップと、
を備えるアプリケーション実行方法。
ＩＯ装置から送信されたデータを取得するデータ取得部と、前記データ取得部により取得されたデータを活用するデータ活用部とを含んで構成されるアプリケーションを実行するアプリケーション実行方法であって、
第１の演算装置が、前記アプリケーションに求められている時間内に、前記アプリケーションを開始するイベントが発生してから前記アプリケーションが開始できる、第１のハードウェアまたは第１のカーネルに割り当てられた第１の空間で、前記データ取得部を実行する第１のステップと、
データ連携部が、前記データ取得部で取得されたデータを前記データ活用部に連携する第２のステップと、
第２の演算装置が、前記第１の空間とは異なる空間であって、前記第１のハードウェアまたは前記第１のカーネルとは異なる第２のハードウェアまたは第２のカーネルに割り当てられた空間である第２の空間で、前記データ活用部を実行する第３のステップと、
生成部が、前記データ活用部とのインターフェース処理を指定する関数を示す第１の記述と、前記ＩＯ装置とのインターフェース処理を指定する関数を示す第２の記述と、データ取得処理を示す第３の記述と、前記データ取得部を実行する演算装置を指定する第４の記述を含むモデルソースから、前記第１の記述および前記第２の記述を前記第４の記述で指定された演算装置に対応した記述に変換した合成ソースを生成し、生成した合成ソースをコンパイルすることで前記データ取得部を生成する第４のステップと、
を備えるアプリケーション実行方法。
ＩＯ装置から送信されたデータを取得するデータ取得部と、前記データ取得部により取得されたデータを活用するデータ活用部とを含んで構成されるアプリケーションを実行するアプリケーション実行方法であって、
第１の演算装置が、前記アプリケーションに求められている時間内に、前記アプリケーションを開始するイベントが発生してから前記アプリケーションが開始できる、第１のハードウェアまたは第１のカーネルに割り当てられた第１の空間で、前記データ取得部を実行する第１のステップと、
データ連携部が、前記データ取得部で取得されたデータを前記データ活用部に連携する第２のステップと、
第２の演算装置が、前記第１の空間とは異なる空間であって、前記第１のハードウェアまたは前記第１のカーネルとは異なる第２のハードウェアまたは第２のカーネルに割り当てられた空間である第２の空間で、前記データ活用部を実行する第３のステップと、
生成部が、モデルソースから前記データ取得部を生成する第４のステップと、を備え、
前記第２の演算装置は、前記第１の演算装置とは異なる演算装置であり、
前記生成部は、前記データ取得部を前記第２の演算装置で実行可能であるか否かを判定し、前記第２の演算装置で前記データ取得部を実行できないと判定した場合、前記モデルソースを前記第１の演算装置に対応するように変更して前記データ取得部を生成する、
を備えるアプリケーション実行方法。