JP2023029002A - グリッドコンピューティングシステム、管理方法及び管理システム - Google Patents

Abstract

【課題】データ転送時間がシステムボトルネックとなることを回避する。【解決手段】グリッドコンピューティングシステム１は、処理対象のジョブを複数のユニットに分割し、ユニット毎にマスタ装置から車両にジョブデータを転送する第１転送処理、車両１０での各ユニットの演算処理、及び車両からマスタ装置に演算処理後の演算結果データを転送する第２転送処理のそれぞれを異なるステージとするパイプラインで処理する。【選択図】図６

Description

ここに開示された技術は、グリッドコンピューティングシステム並びにグリッドコンピューティングの管理方法及び管理システムに関する技術分野に属する。

特許文献１には、 計算ノードとして機能する車載端末で構成される分散処理システムにおいて、各車両が基地局に自端末の資源情報を送信するとともに、自車両を計算ノードとして登録し、基地局がそれに基づいてジョブを割り当てる技術が開示されている。

特開２００７－８７２７３号公報

ところで、移動体（例えば、車両）に搭載される演算資源を活用したグリッドコンピューティングシステム（以下、「移動体グリッドシステム」ともいう）では、データセンターを活用した一般的なグリッドコンピューティングシステム（以下、「従来システム」という）と比較して、グリッドを構成するコンピュータ間の通信性能が低いという問題がある。具体的に、従来システムでは、専用ハードワイヤ通信であり、相互間の物理的距離も近い。これに対し、移動体グリッドシステムでは、車両同士が専用通信線で接続されているわけでもなく、かつ、互いの物理的距離が離れている。

さらに、従来システムでは、一般的に２４時間稼働されており、演算負荷が低いときに、データのダウンロードやアップロードなどのバックグラウンド処理がしやすい。これに対して、グリッドコンピューティングシステムでは、本来の使用目的（車両であれば走行）での使用との兼ね合いでグリッドコンピューティングとしての稼働時間が限られている。

ここに開示された技術は斯かる点に鑑みてなされたものであり、その目的とするところは、グリッドコンピューティングシステムにおいて、データ転送時間がシステムボトルネックとなることを回避することで高効率な計算を可能にすることにある。

前記課題を解決するために、本開示の第１態様では、複数の移動体のそれぞれに搭載される演算資源を活用したグリッドコンピューティングシステムを対象として、クライアント端末から依頼されたジョブを複数のユニットに分割し、グリッドコンピューティングのマスタ装置から前記移動体に前記ユニット毎にデータを転送する第１転送処理、当該移動体における当該各ユニットの演算処理、及び当該移動体から前記マスタ装置に当該演算処理後のジョブ結果を転送する第２転送処理のそれぞれを異なるステージとするパイプラインで処理する、という構成にした。

上記第１態様によると、マスタ装置から移動体にデータを転送する第１転送処理期間中及び移動体からマスタ装置にデータを転送する第２転送処理期間中においても、並列して演算処理を実行することができる。これにより、一連のジョブ完了までの時間に対して転送処理時間が与える影響を軽減することができる。

また、本開示の第２態様として、複数の移動体のそれぞれに搭載される演算資源を活用したグリッドコンピューティングを管理する管理方法を対象として、処理対象となるジョブについて、当該ジョブを複数のユニットに分割した場合における前記ユニットのジョブデータ容量、前記ユニットの演算における必要リソース及び前記ユニットの演算処理後のジョブ結果容量を推定するジョブ分析工程と、それぞれの前記移動体について、当該移動体と前記グリッドコンピューティングのマスタ装置との間の通信帯域情報及び当該移動体の演算リソース情報を取得する移動体情報取得工程と、前記ジョブデータ容量と前記通信帯域情報に基づくジョブ転送時間、前記必要リソースと前記演算リソース情報に基づく演算時間、及び、前記ジョブ結果容量と前記通信帯域情報に基づく結果転送時間を推定し、当該推定された前記ジョブ転送時間、前記演算時間及び前記結果転送時間の相互間の時間差が所定時間内に収まるように移動体とジョブとのマッチングをするマッチング工程と、前記マスタ装置から前記マッチング工程で選定された移動体に対してマッチングされたジョブのユニット毎のジョブデータを転送する第１転送処理、当該移動体における当該各ユニットの演算処理、及び当該移動体から前記マスタ装置に当該演算処理後の演算結果データを転送する第２転送処理のそれぞれを異なるステージとするパイプラインで処理するパイプライン処理工程とを含む。

上記第２態様によると、第１態様と同様に、パイプライン処理工程を実行することで、一連のジョブ完了までの時間に対して転送処理時間が与える影響を軽減することができる。さらに、パイプライン処理工程に先立って、パイプライン処理の各ステージに関連するジョブ転送時間、演算時間及び結果転送時間の相互間の時間差が所定時間内に収まるようにジョブと移動体のマッチングを取るようにしている。これにより、パイプライン処理を実行する上でそれぞれのジョブに対して最適な移動体を割り当てることができる。

より具体的には、移動体グリッドシステムでは、それぞれの移動体に搭載されている演算資源のばらつきが大きいという問題がある。また、移動体ごとに通信環境が一定ではないので、通信帯域にもばらつきが生じるという問題がある。そこで、第２態様のような構成にすることで、それぞれのジョブ毎にそのジョブのパイプライン処理を実行する上で適した移動体を割り当てることができ、全体としての処理の効率化を促進することができる。

以上説明したように、ここに開示された技術によると、移動体グリッドシステムにおいて、データ転送時間がシステムボトルネックとなることを回避することができ、その結果、高効率な計算が可能となる。

実施形態のシステムの構成を例示する概略図 グリッドコンピューティングについて説明するための概念図 車両の構成を例示するブロック図 クライアントサーバの構成を例示するブロック図 管理サーバの構成を例示するブロック図 車両及び管理サーバの機能モジュールの構成例及び接続例を示すブロック図 グリッドコンピューティングシステムの動作例を示すフローチャート パイプライン処理が構築可能な車両の決定処理の一例を示すフローチャート パイプライン処理について説明するための図 パイプライン処理の異常処理の一例を示す図 パイプライン処理の異常処理の他の例を示す図 パイプライン処理の異常処理の他の例を示す図

実施形態について、図面を参照しながら詳細に説明する。図中同一または相当部分には同一の符号を付すものとし、繰り返しの説明を省略する場合がある。また、以下の実施形態では、本開示の内容に関連性の高い構成を中心に説明する。なお、以下の実施形態は、例示的なものであり、記載の有無や例示した数値等によって本開示の内容を限定する意図はまったくない。

＜第１実施形態＞
（グリッドコンピューティングシステム）
図１は、実施形態のグリッドコンピューティングシステム１（以下、単に「システム１」ともいう）の構成を例示する。

このシステム１は、複数の車両１０と、複数のクライアント端末３０と、管理サーバ５０とを備える。これらの構成要素は、通信網６を経由して互いに通信可能である。複数の車両１０の各々には、演算装置１０２が搭載される。管理サーバ５０は、マスタ装置の一例である。車両は、移動体の一例である。

〔グリッドコンピューティング〕
図２に示すように、実施形態のシステム１では、複数の演算装置１０２によりグリッドコンピューティング（以下、単に「グリッドＧ」ともいう）が構成され、複数の演算装置１０２のうち利用可能な演算装置１０２にアプリケーションジョブ（以下、単に「ジョブ」ともいう）のジョブデータＤ１を処理させるグリッドコンピューティング処理が行われる。

なお、車両１０が走行している場合、車両１０の走行制御のために演算装置１０２の計算能力が必要となり、演算装置１０２が稼働状態となる。一方、例えば、車両１０が停車して車両１０の電源がオフ状態になると、車両の走行制御に対する演算装置１０２の計算能力が実質的に不要となる。そこで、車両１０の非稼働中（例えば、停車中）に上記のグリッドコンピューティング処理が実行される。

〔車両〕
車両１０には、電池（図示省略）が搭載される。電池の電力は、演算装置１０２などの車載機器に供給される。このような車両１０の例としては、電気自動車、プラグインハイブリッド自動車などが挙げられる。

図３に示すように、車両１０は、通信部１０１と、演算装置（プロセッサ）１０２と、記憶部１０３とを備える。

－通信部－
通信部１０１は、情報やデータを送受信する。通信部１０１により受信された情報やデータは、演算装置１０２に送られる。

－演算装置－
演算装置１０２は、車両１０の各部を制御する。この例では、演算装置１０２は、センサ（図示省略）により得られた各種の情報に応じて各アクチュエータ（図示省略）を制御する。なお、演算装置１０２として、車両１０の制御に用いられる演算装置に加えて、グリッドコンピューティング専用、すなわち、車両１０の制御に関わらない演算装置を搭載してもよい。

演算装置１０２は、プロセッサ、メモリなどを有する。プロセッサの例としては、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）などが挙げられる。メモリは、プロセッサを動作させるためのプログラム、プロセッサの処理結果を示す情報やデータなどを記憶する。

図６右側には、車両１０の機能モジュールの構成例を示す。図６の機能モジュールは、例えば、演算装置１０２に設けられる。

この例では、演算装置１０２は、解凍モジュール１１１と、演算モジュール１１３と、パイプライン管理モジュール１１５と、圧縮モジュール１１８と、バッファ用のメモリ１１２，１１７とを備える。

解凍モジュール１１１は、通信網６の通信路６１を介して管理サーバ５０の圧縮モジュール５１６から受信した圧縮データを解凍する。圧縮データには、後述するジョブデータＤ１が含まれる。解凍モジュール１１１で解凍されたジョブデータＤ１は、メモリ１１２に一旦格納され、演算モジュール１１３に入力される。

演算モジュール１１３は、各種の演算処理を実行する。演算モジュール１１３は、解凍モジュール１１１で解凍されたジョブデータＤ１を受信し、順次処理を実行する。演算モジュール１１３は、ジョブデータＤ１のジョブが終了すると、演算結果データＤ２をメモリ１１７に出力する。また、ジョブデータＤ１のジョブが完了したことを示す完了フラグをパイプライン管理モジュール１１５に送信する。また、演算モジュール１１３は、ジョブデータＤ１のジョブが異常終了した場合、パイプライン管理モジュール１１５に異常通知を送信する。

パイプライン管理モジュール１１５は、ジョブデータＤ１のパイプライン処理を管理する機能を有する。パイプライン管理モジュール１１５は、通信路６１を介して管理サーバ５０から受信されたデータから取得された同期信号を受信し、その同期信号に基づいて動作する。同期信号は、（１）通信路６１にジョブデータＤ１と並行して同期信号自体を送信するようにしてもよいし、（２）クロックリカバリ回路（図示省略）を設けて、通信路６１から受信されたジョブデータＤ１から同期信号（クロック）を分離するようにしてもよい。

パイプライン管理モジュール１１５は、メモリ１１７に格納された演算結果を圧縮モジュールに出力するタイミングを規定するデータ制御信号をメモリ１１７に出力する。また、パイプライン管理モジュール１１５は、同期信号を出力する。同期信号は、通信網６の通信路６２を介して出力される。同期信号は、圧縮モジュール１１８から通信路６２に出力される演算結果データＤ２に重畳されてもよいし、演算結果データＤ２と並行して出力されるようにしてもよい。また、パイプライン管理モジュール１１５は、演算モジュール１１３から管理サーバ５０への通知対象となる異常通知を受信した場合、その異常通知が通信路６２を介して管理サーバ５０に出力されるようにする。なお、パイプライン管理モジュール１１５の具体的な動作については、後ほど説明する。

メモリ１１７は、データ制御信号に基づいて、演算モジュール１１３から受信した演算結果データＤ２を順次圧縮モジュール１１８に出力する。メモリ１１７は、例えば、格納されている演算結果データＤ２のサイズが、所定のパケットサイズよりも大きい場合、演算結果データＤ２を所定のパケットサイズに分割し、その分割されたパケットをデータ制御信号で規定されたタイミングごとに順次出力する。

圧縮モジュール１１８は、メモリ１１７から受信した演算結果データＤ２を圧縮し、通信路６２を介して管理サーバ５０に出力する。

なお、本開示では、ＣＰＵやＧＰＵのように、グリッドコンピューティングの計算・処理に利用可能な資源を「演算資源」と称する。演算資源は、車両１０に搭載されたＣＰＵ及びＧＰＵの一部または全部を含む。

また、例えば、演算資源としての利用を許可される時間帯と、演算資源としての利用を制限する時間帯とが分けられていてもよい。すなわち、単一のＣＰＵが、ある時間帯では演算資源としてカウントされ、他の時間帯では演算資源としてカウントされないとしてもよい。ＧＰＵについても同様である。

また、ＣＰＵが単一または複数のコアで実現されている場合において、その複数のコアの一部が演算資源としてカウントされ、それ以外のコアは演算資源としてカウントされないとしてもよい。ＧＰＵについても同様である。

－記憶部－
記憶部１０３は、各種の情報やデータを記憶する。記憶部１０３の具体的な構成は、特に限定されない。例えば、チップに内蔵されたメモリで実現されてもよいし、ＨＤＤ（Hard disk drive）、ＳＳＤ(Solid State Drive)で実現されてもよいし、ＤＶＤやＢＤのような光ディスクで実現されてもよい。

この例では、記憶部１０３は、車両情報Ｄ１０を記憶する。車両情報Ｄ１０には、車両基本情報Ｄ１１と、車両状態情報Ｄ１３と、稼働情報Ｄ１５が含まれる。

〈車両基本情報〉
車両基本情報Ｄ１１は、車両識別情報、リソース情報、並びに、車両に搭載される圧縮モジュール性能情報及び解凍モジュール性能情報を含む。

車両識別情報は、ＶＩＮのように車両を識別するための情報や、車両１０の所有者を識別するユーザ識別情報を含む。

リソース情報は、演算資源（ＣＰＵやＧＰＵなど）に関する情報である。リソース情報は、例えば、演算資源ごとに付与された演算資源ＩＤ、各演算資源の性能を示す性能情報を含む。演算資源の性能には、演算資源の計算能力（具体的には最大計算能力）を示す計算能力、演算資源におけるＣＰＵとＧＰＵの比率などが含まれる。演算資源の計算能力は、例えば、それぞれの演算資源が単位時間当たりに計算することができるデータ量である。

圧縮モジュール性能情報は、圧縮モジュールの性能に関する情報である。解凍モジュール性能情報は、解凍モジュールの性能に関する情報である。

〈車両状態情報〉
車両状態情報Ｄ１３は、車両１０の状態を示す情報であり、例えば、車両位置情報、車両通信情報、車両電源情報等を含む。

車両位置情報は、車両１０の位置（緯度および経度）を示す。例えば、車両位置情報は、ＧＰＳ（Global Positioning System）により取得可能である。

車両通信情報は、車両１０と通信網６との通信状態を示す情報、車両１０と管理サーバ５０との通信帯域の情報を含む。車両通信情報は、例えば、所定時間毎に更新される。

車両電源情報は、車両１０の電源の状態を示す情報、車両電池残量情報、車両充電情報などを含む。例えば、車両電源情報は、イグニッション電源のオンオフ、アクセサリ電源のオンオフなどを示す。車両電池残量情報は、車両１０に搭載された電池（図示省略）の残量を示す。車両充電情報は、充電設備（図示省略）において車両１０が充電中であるか否かを示す。

〈稼働情報〉
稼働情報Ｄ１５は、例えば、車両１０の走行履歴を示す車両走行情報と、演算装置１０２の稼働履歴を示す稼働履歴情報と、演算装置１０２の稼働予定を示す稼働予定情報を含む。

車両走行情報は、例えば、車両１０の位置と時刻とを関連付けて示す。なお、走行履歴情報に加えて、車両１０の未来の走行予定を示す走行予定情報が含まれてもよい。

稼働履歴情報は、例えば、演算装置１０２の演算資源の利用率及び／またはジョブの処理量と、時刻とを関連付けて示す。稼働履歴情報は、通常稼働履歴と、グリッド稼働履歴とを含む。通常稼働履歴は、例えば、車両の走行やカーナビ、音楽再生等のサービスの提供等のように、ユーザーの利用のために演算装置１０２を稼働させた履歴を示す情報である。グリッド稼働履歴は、グリッドコンピューティング処理を実行するために演算装置１０２を稼働させた履歴を示す情報である。

稼働予定情報は、例えば、演算装置１０２の未来の利用状況を示す利用予定情報などを示す。

〔クライアント端末〕
クライアント端末３０は、クライアントにより所有される。クライアントは、ジョブデータの計算を依頼する。このようなクライアントの例としては、企業、研究機関、教育機関などが挙げられる。

図４に示すように、クライアント端末３０は、通信部３０１と、記憶部３０３と、制御部３０２とを備える。

－通信部－
通信部３０１は、管理サーバと双方向通信が可能に接続され、相互間での情報やデータを送受信する。通信部３０１により受信された情報やデータは、制御部３０２に送られる。

－制御部－
制御部３０２は、クライアント端末３０の各部を制御する。制御部３０２は、プロセッサ、メモリなどを有する。メモリは、プロセッサを動作させるためのプログラム、プロセッサの処理結果を示す情報やデータなどを記憶する。

－記憶部－
記憶部３０３は、情報やデータを記憶する。この例では、記憶部３０３は、クライアント情報Ｄ３１と、ジョブデータＤ１とを記憶する。

〈クライアント情報〉
クライアント情報Ｄ３１は、クライアントに関する情報である。クライアント情報Ｄ３１は、クライアントに設定されたクライアントＩＤ、クライアントにより所有されるクライアント端末３０に設定されたクライアント端末ＩＤ、担当者名、住所、電話番号などを含む。

〈ジョブデータ〉
ジョブデータＤ１は、ジョブに対応するデータであり、ジョブの実施のために処理されるデータである。

なお、ジョブデータＤ１は、計算タイプにより分類可能である。計算タイプの例としては、ＣＰＵ系の計算タイプ、ＧＰＵ系の計算タイプなどが挙げられる。ＣＰＵ系の計算タイプのジョブデータＤ１では、シミュレーション計算など、条件分岐の多い複雑な計算が要求される傾向にある。ＧＰＵ系の計算タイプのジョブデータＤ１では、画像処理や機械学習など、膨大な量の単純計算が要求される傾向にある。

なお、本開示のパイプライン処理は、計算タイプの種別にはよらずに適用できるが、特に、ＧＰＵ系の計算タイプにおいて好適に適用できる場合がある。ＧＰＵ系の計算タイプ（ＧＰＵ系に適した処理）は、ジョブの並列化をしやすい傾向があるためである。

また、ジョブデータＤ１に付随してジョブに関するジョブ情報が記憶されてもよい。ジョブ情報は、例えば、ジョブの名称情報、ジョブの内容情報、ジョブデータの計算タイプ、処理条件、必要計算能力、ジョブの納期情報などを含む。

〔管理サーバ〕
管理サーバ５０は、グリッドコンピューティングの運営を管理する。換言すると、システム１は、管理サーバ５０を備える。管理サーバ５０は、システム１を運営する事業者により所有される。

図５に示すように、管理サーバ５０は、通信部５０１と、制御部５０２と、記憶部５０３とを備える。

－通信部－
通信部５０１は、車両１０やクライアント端末３０と双方向通信が可能に接続され、相互間での情報やデータを送受信する。通信部５０１により受信された情報やデータは、制御部５０２に送られる。

－制御部－
この例では、制御部５０２は、グリッドコンピューティングの運営や管理に関する一連の制御及び処理を実行する機能を有する。例えば、後述する図７及び図８のフロー図内での制御や処理を実行する。なお、以下の説明では、管理サーバ５０を主体をとして記載した動作などについて、制御部５０２がその処理や制御に寄与することで実現される場合がある。

図６左側には、管理サーバ５０の機能モジュールの構成例を示す。図６の機能モジュールは、例えば、制御部５０２に設けられる。

この例では、制御部５０２は、アプリケーション分析モジュール５１１と、パイプライン設定モジュール５１２と、演算ノード管理モジュール５１３と、演算管理モジュール５１４と、圧縮モジュール５１６と、パイプライン管理モジュール５１７と、解凍モジュール５１８と、バッファ用のメモリ５１５とを備える。

アプリケーション分析モジュール５１１は、車両１０に振り分けるジョブを分析するジョブ分析工程を実行する。

具体的に、アプリケーション分析モジュール５１１では、クライアント端末３０から受信したそれぞれのジョブデータＤ１について、（１）複数の同じようなサイズのジョブユニット（以下、単に「ユニット」という）に分割が可能かどうかを分析する、（２）ジョブデータＤ１全体及びユニット毎のジョブデータ容量を算出する、（３）ジョブデータＤ１全体及びユニット毎にジョブを実行するのに必要なリソース（以下「必要リソース」という）を算出する、（４）ジョブデータＤ１全体及びユニット毎のアプリケーションジョブの演算処理後の演算結果データＤ２の容量を予測する、といった処理を実行する。複数のユニットに分割が可能というのは、例えば、ジョブを細かく分割ができ、その細かく分割されたジョブを組み合わせることで、複数のユニット（それぞれが同じようなサイズ）が構築できるという形態であってもよい。なお、複数のユニットのサイズは、必ずしも同じようなサイズでなくてもよいが、ユニットのサイズが揃うことで、パイプライン処理の効果をより高めることができる。

演算ノード管理モジュール５１３は、それぞれの車両１０についての通信帯域情報及びリソース情報を取得する移動体情報取得工程を実行する。

具体的に、演算ノード管理モジュール５１３では、グリッドＧを構成する各車両について、（１）演算リソース情報を含む車両基本情報Ｄ１１を取得する、（２）管理サーバ５０との間の通信帯域情報を取得する、といった処理を実行する。通信帯域情報を取得方法は、特に限定されない。例えば、管理サーバ側で所定の時間毎に各車両との間の通信帯域を測定するようにしてもよいし、各車両から車両状態情報Ｄ１３の車両通信情報を取得することで通信帯域情報を取得してもよい。

パイプライン設定モジュール５１２では、処理対象となるジョブデータＤ１と、それを実行する車両１０とのマッチングをするマッチング工程を実行する。

具体的に、まず、パイプライン設定モジュール５１２は、アプリケーション分析モジュール５１１で算出されたユニット毎のジョブデータ容量、ユニット毎の演算結果データの予測容量を取得する。また、パイプライン設定モジュール５１２は、演算ノード管理モジュール５１３で取得された各車両の演算リソース情報及び通信帯域情報を取得する。

次に、パイプライン設定モジュール５１２では、処理対象となるジョブデータＤ１と選択された車両１０に対して、（１）ユニットのジョブデータ容量とその車両１０の通信帯域情報に基づいてユニットのジョブ転送時間を推定する、（２）ユニットの必要リソースとその車両１０の演算リソース情報とに基づいてユニットの演算時間を推定する、（３）ユニットのジョブ結果容量とその車両１０の通信帯域情報に基づいて結果転送時間を推定する、といった処理を実行する。

そして、パイプライン設定モジュール５１２は、処理対象となるジョブデータＤ１に対して、上記のジョブ転送時間、演算時間及び結果転送時間の相互間の時間差が所定時間内に収まるような車両１０（以下、「対象車両１０」という）をマッチングする。

その後、パイプライン設定モジュール５１２は、演算管理モジュール５１４にパイプライン設定情報を出力する。パイプライン設定情報は、ユニットに分割が可能なジョブデータＤ１についての各ステージ時間の情報や、そのジョブデータＤ１を処理する車両１０とのマッチング結果の情報（以下、「マッチング情報」という）を演算管理モジュール５１４に出力する。

演算管理モジュール５１４は、上記のパイプライン設定情報に基づいて、ジョブの分割処理及びパイプライン設定処理を実行する。ジョブの分割処理では、記憶部５０３から処理対象となるジョブデータＤ１を取り出し、アプリケーション分析モジュール５１１の分析結果に基づいてジョブデータＤ１をユニットに分割する。パイプライン設定処理には、ジョブデータＤ１の演算のスケジューリングやパイプラインを構成する対象車両１０へのジョブデータＤ１を用いたアプリケーションジョブの演算処理依頼が含まれる。演算処理依頼には、対象車両１０とのデータ転送帯域の確保、対象車両１０の演算リソースの予約処理が含まれる。

演算管理モジュール５１４は、ジョブの分割処理及びパイプライン設定処理が完了すると、処理対象のジョブデータＤ１を分割したユニットを順次メモリ５１５に出力する。そして、メモリ５１５へのユニットの出力処理が完了すると、完了フラグをパイプライン管理モジュール５１７に出力する。また、上記の各種処理が途中で異常終了した場合には、異常フラグをパイプライン管理モジュール５１７に出力する。

パイプライン管理モジュール５１７は、メモリ５１５に格納された演算結果を圧縮モジュールに出力するタイミングを規定するデータ制御信号をメモリ５１５に出力する。また、パイプライン管理モジュール５１７は、同期信号を出力する。同期信号は、通信路６１を介して出力される。同期信号は、圧縮モジュール５１６から通信路６１に出力されるジョブデータＤ１に重畳されてもよいし、通信路６１においてジョブデータＤ１と並行するように出力されてもよい。

メモリ５１５は、パイプライン管理モジュール５１７から受信したデータ制御信号に基づいて、演算管理モジュール５１４から受信した各ユニットのジョブデータを順次圧縮モジュール５１６に出力する。

圧縮モジュール５１６は、メモリ５１５から受信した各ユニットのジョブデータを圧縮し、順次通信路６１を介して対象車両１０に出力する。

解凍モジュール５１８は、通信路６２を介して対象車両１０の圧縮モジュール１１８から受信した演算結果データＤ２の圧縮データを解凍する。解凍モジュール５１８で解凍された演算結果データＤ２は、演算管理モジュール５１４に出力される。演算管理モジュール５１４は、解凍モジュール５１８から受信した演算結果データＤ２を記憶部５０３に保存する。

－記憶部－
記憶部５０３は、情報やデータを記憶する。記憶部５０３の具体的な構成は、特に限定されない。例えば、チップに内蔵されたメモリで実現されてもよいし、ＨＤＤ（Hard disk drive）、ＳＳＤ(Solid State Drive)で実現されてもよいし、ＤＶＤやＢＤのような光ディスクで実現されてもよい。

この例では、記憶部５０３には、車両情報テーブルＤ５１と、ジョブテーブルＤ５３と、マッチングテーブルＤ５５と、ジョブデータＤ１と、演算結果データＤ２等の各種データが格納される。

〈車両情報テーブル〉
車両情報テーブルＤ５１は、車両情報を管理するためのテーブルである。車両情報テーブルＤ５１には、例えば、各車両の車両情報Ｄ１０がリスト化されて格納されている。

〈ジョブテーブル〉
ジョブテーブルＤ５３は、クライアントから依頼されたジョブを管理するためのテーブルである。ジョブテーブルＤ５３には、ジョブ毎に、そのジョブに設定された受付番号、そのジョブを依頼したクライアントに設定されたクライアントＩＤ、そのジョブの名称および内容などが登録される。また、ジョブテーブルＤ５３には、ジョブ毎に、そのジョブに対応するジョブデータＤ１の計算タイプおよび処理条件、そのジョブデータＤ１の計算に必要となる計算能力である必要計算能力、そのジョブに設定された納期などが登録される。ジョブテーブルＤ５３では、それぞれのジョブデータＤ１がどのクライアントから依頼されたジョブなのかがわかるように紐づけされている。

〈マッチングテーブル〉
マッチングテーブルＤ５５は、マッチング工程でのマッチングの結果を管理するためのテーブルである。マッチングテーブルＤ５５には、ジョブ毎に、そのジョブに設定された受付番号、そのジョブに対応するジョブデータＤ１に設定されたジョブデータＩＤ、マッチング処理によりそのジョブデータに対して割り当てられた車両の車両識別情報などが登録される。

〈ジョブデータ〉
記憶部５０３に記憶されるジョブデータＤ１は、後述するジョブ受付処理でクライアント端末から受け付けられたジョブのデータである。

〈演算結果データ〉
記憶部５０３に記憶される演算結果データＤ２は、後述するグリッドコンピューティング処理により各対象車両１０で実行されたジョブの計算結果のデータである。

〔グリッドコンピューティングシステムの動作〕
以下において、グリッドコンピューティングシステムの動作例について、図７及び図８のフローチャートを参照しつつ説明する。

－ステップＳ１－
ステップＳ１において、管理サーバ５０は、クライアントからのジョブ依頼を受け付けるジョブ受付処理を実行する。

具体的には、まず、クライアント端末３０が、クライアントの担当者による入力操作に応答して、ジョブ依頼申請を管理サーバ５０に送信する。

管理サーバ５０では、依頼されたジョブに対応するジョブデータＤ１の送信をクライアント端末３０に要求する。クライアント端末３０は、その要求に応答して、依頼するジョブに対応するジョブデータＤ１を管理サーバ５０に送信する。管理サーバ５０は、ジョブデータＤ１を受信し、記憶部５０３に格納する。

－ステップＳ２－
ステップＳ２において、管理サーバ５０は、クライアント端末３０から受信したジョブデータＤ１の分析を行う。具体的な分析内容は、前述のとおりであり、例えば、管理サーバ５０のアプリケーション分析モジュール５１１が、（１）複数のユニットになるべく均等に分割できるかどうかの分析、（２）ユニットのジョブデータ容量の算出、（３）必要リソースの算出、（４）ユニットの演算結果データＤ２の容量を予測する、といった分析を実行する。

－ステップＳ３－
ステップＳ３において、管理サーバ５０は、各車両１０の車両情報Ｄ１０を取得する。

まず、管理サーバ５０は、各車両１０に最新の車両情報Ｄ１０の送信を要請する。各車両１０は、管理サーバ５０の求めに応じて、管理サーバ５０に最新の車両情報Ｄ１０を送信する。このときに送信される車両情報Ｄ１０は、車両情報Ｄ１０の一部が送信されてもよいし、全ての車両情報Ｄ１０が送信されてもよい。例えば、各車両１０から管理サーバ５０に送信される車両情報Ｄ１０には、車両識別情報とリソース情報が含まれる。

管理サーバ５０では、各車両１０から受信した車両情報Ｄ１０を車両情報テーブルＤ５１に登録する。なお、すでに管理サーバ５０に車両情報Ｄ１０が登録されている車両１０については、登録されている登録情報との差分情報のうち、必要な情報を車両１０から管理サーバ５０に送信するようにしてもよい。

－ステップＳ４－
ステップＳ４において、管理サーバ５０は、パイプライン処理が構築可能な車両の決定を行う。この例では、ステップＳ４は、後述する終了条件が設定されたループ処理である。以下、図８を参照しつつ詳細に説明する。

〈ステップＳ４１〉
ステップＳ４１において、管理サーバ５０は、パイプライン処理を実行する候補となる車両の選定処理を実行する。換言すると、管理サーバ５０は、この後の処理を実行する車両１０を絞り込む処理を実行する。例えば、管理サーバーにグリッドコンピューティングへの参加意思を表明している車両１０に関する車両情報Ｄ１０を普段から取集・蓄積しておく。そして、管理サーバ５０は、その情報に基づいて車両１０の絞り込みを実行する。本選定処理（絞り込み）の方法は、特に限定されないが、例えば、（１）必要リソースが明らかに不足している車両を除外する、（２）通信帯域が明らかに不足している車両を除外する、（３）グリッドコンピューティングへの参加可能時間が明らかに不足している車両を除外する、等の方法がある。

このような絞り込みを事前に行うことで、パイプライン処理が構築可能な車両の決定処理に必要な時間を短縮することができる。なお、ステップＳ４１は、ステップＳ４のループ処理の過程で毎回必要な処理ではなく、一度候補車両が確定した後は、このステップＳ４１の処理を飛ばしてもよい。

〈ステップＳ４２〉
ステップＳ４２において、管理サーバ５０は、ステップＳ４１で選定された車両１０（以下、選定車両１０ともいう）について、ユニットのジョブ転送時間を推定する。ジョブ転送時間の推定は、例えば、ユニットのジョブデータ容量、選定車両１０と管理サーバ５０との間の通信帯域情報、管理サーバ５０の圧縮モジュール５１６の性能、及び選定車両１０の解凍モジュール１１１の性能に基づいて実行される。なお、ジョブ転送時間の推定は、すべてのユニットに対して実行してもよいし、いくつかのユニットをピックアップしてジョブ転送時間を推定してもよい。以下で説明するジョブ演算時間の推定及び演算結果転送時間の推定についても同様である。

〈ステップＳ４３〉
ステップＳ４３において、管理サーバ５０は、選定車両１０について、ユニットのジョブ演算時間を推定する。ジョブ演算時間の推定は、例えば、ステップＳ２で算出された必要リソース、選定車両１０の演算リソース情報、及び同様の演算の実績時間などに基づいて実行される。

〈ステップＳ４４〉
ステップＳ４４において、管理サーバ５０は、選定車両１０について、ユニットの演算結果転送時間を推定する。演算結果転送時間の推定は、例えば、ユニットの演算結果データの予測容量、選定車両１０と管理サーバ５０との間の通信帯域情報、選定車両１０の圧縮モジュール１１８の性能、及び管理サーバ５０の解凍モジュール５１８の性能に基づいて実行される。

〈ステップＳ４５〉
ステップＳ４５において、管理サーバ５０は、選定車両１０について、ジョブの連続実行可能性について判定する。具体的には、管理サーバ５０は、ジョブの総実行時間の推定を行い、その総実行時間と選定車両１０の今後のグリッドコンピューティングとしての利用可能時間（以下、単に「利用可能時間」という）とに基づいて、ジョブの連続実行可能性を判定する。ジョブの総実行時間の推定は、例えば、ステップＳ２でのアプリケーションの分析結果、ステップＳ４２で推定されたジョブ転送時間、ステップＳ４３で推定されたジョブ演算時間、及びステップＳ４４で推定された演算結果転送時間に基づいて実行される。選定車両１０の利用可能時間は、例えば、選定車両１０の車両状態情報Ｄ１３及び／又は稼働情報Ｄ１５に基づいて推定される。

より具体的には、管理サーバ５０は、例えば、ジョブデータＤ１を処理するのに３時間要すると推定される場合に、車両情報Ｄ１０などに基づいて、選択車両１０がその後の３時間駐車されている予定かどうかを判定する。

〈ステップＳ４６〉
ステップＳ４６において、管理サーバ５０は、パイプライン処理のステージ時間を決定する。この例では、パイプライン処理は、データ受信ステージ、ジョブ演算ステージ、データ送信ステージの３つのステージで構成されており、それぞれのステージ時間を決定する。データ受信ステージは、選択車両１０が管理サーバ５０からジョブデータＤ１を受信するステージである。ジョブ演算ステージは、選択車両１０でジョブデータＤ１を用いた演算をするステージである。データ送信ステージは、選択車両１０から管理サーバ５０に演算結果データＤ２を送信するステージである。この例では、ステージの名称や動作説明などにおいて、便宜上、車両１０から見た場合の「受信」及び「送信」でデータの流れを説明をする場合がある。なお、データ受信ステージでの転送処理は、第１転送処理の一例である。データ送信ステージでの転送処理は、第２転送処理の一例である。

このとき、管理サーバ５０は、選択車両１０について、データ受信ステージにおけるユニットのジョブ転送時間、ジョブ演算ステージにおけるユニットのジョブ演算時間、及びデータ送信ステージにおけるユニットの演算結果転送時間の相互間の時間差が所定時間内に収まっているかどうかを確認する。この所定時間は、任意に設定することができる。ただし、所定時間が小さいほど、すなわち、各ステージ間の時間差が小さいほど、効率の高い処理が実現できる。上記の相互間の時間差が所定時間を超える場合、管理サーバ５０は、選択車両１０のステージ時間を「未決定」として処理を終了する。

〈ステップＳ４７，Ｓ４８〉
次のステップＳ４７では、選択車両１０について、ステップＳ４５のジョブの連続実行可能性が充足され、かつ、ステップＳ４６のステージ時間が決定されているかどうかを判定する。そして、ＹＥＳ判定（両方満たされている）の場合、ステップＳ４８に進む。ステップＳ４８では、管理サーバ５０は、選択車両１０をパイプライン処理の構築が可能な車両と判断し、ループ内の一連の処理を終了する。

一方で、ステップＳ４７において、ＮＯ判定（いずれかの条件が満たされていない）の場合、ステップＳ４８の処理を実行せずに、そのままループ内の一連の処理を終了する。

そして、パイプライン処理の構築が可能な車両１０（対象車両１０）が決定するか、すべての車両１０についての処理（例えば、図８の処理）が完了することを終了条件として、ステップＳ４１からステップＳ４８のループ処理を実行する。例えば、ステップＳ４８で所定の条件を満たす対象車両１０が決定した時点でループ処理を終了としてもよいし、一部または全部の車両１０についてステップＳ４のループ処理を実行し、すべてのループ処理が終了した後に、最も適した１または複数の車両１０を対象車両１０に設定するようにしてもよい。なお、終了条件は、これに限定されず、例えば、パイプライン処理に必要な対象車両１０の台数が確保できた時点で終了としてもよい。

－ステップＳ５－
図７に戻り、ステップＳ５において、管理サーバ５０は、パイプライン処理が構築可能な対象車両１０が存在するかどうかを確認する。対象車両１０が存在する場合（ＹＥＳ判定）、フローはステップＳ６に進む。一方で、対象車両１０が存在しない場合（ＮＯ判定）、フローはステップＳ８に進む。

－ステップＳ６－
ステップＳ６において、管理サーバ５０は、パイプライン処理のための設定や準備を実行する。

具体的に、管理サーバ５０は、記憶部５０３からジョブデータＤ１を取り出し、ステップＳ２での分析結果に基づいて、ジョブデータＤ１を複数のユニットに分割する。

また、管理サーバ５０及び対象車両１０において、パイプライン設定を実行する。例えば、管理サーバ５０において、ステップＳ４６で設定されたステージ時間に基づいて、パイプライン処理でのデータ送信のタイミングなどの設定が実行される。同様に、対象車両１０においても、パイプライン処理でのデータ受信のタイミングや、演算処理後の演算結果の送信タイミングなどの設定が実行される。

さらに、管理サーバ５０は、対象車両１０との通信帯域を確保するとともに、対象車両１０に対して演算リソースの予約処理を実行する。

－ステップＳ７－
ステップＳ７は、パイプラインジョブの完了を終了条件とするループ処理である。

〈通常処理（異常なし）〉
ステップＳ７１では、パイプライン処理（パイプラインサイクル）が実行される。図９にパイプライン処理の一例を示す。

図９において、第１サイクルでは、データ受信ステージにおいて、第１ユニットのデータ受信処理が実行される。具体的には、管理サーバ５０における第１ユニットのデータ圧縮処理、管理サーバ５０から対象車両１０へのデータ転送処理、対象車両１０における第１ユニットの解凍処理が実行される。

第２サイクルでは、データ受信ステージにおいて、第２ユニットのデータ受信処理が実行される。第１サイクルと同様に、第２ユニットについて、データ圧縮処理、データ転送処理、及び解凍処理が実行される。また、演算ステージにおいて、第１ユニットを用いたアプリケーションジョブの演算処理（第１演算）が実行される。

第３サイクルでは、データ受信ステージにおいて、第３ユニットのデータ受信処理が実行される。第１サイクルと同様に、第３ユニットについて、データ圧縮処理、データ転送処理、及び解凍処理が実行される。また、演算ステージにおいて、第２ユニットを用いたアプリケーションジョブの演算処理（第２演算）が実行される。また、データ送信ステージにおいて、第１ユニットのデータ送信処理が実行される。具体的には、対象車両１０における第１ユニットのデータ圧縮処理、対象車両１０から管理サーバ５０へのデータ転送処理、管理サーバ５０における第１ユニットの解凍処理が実行される。

以後、同様にして、パイプライン処理のジョブが完了するまで、データ受信ステージ、演算ステージ及びデータ送信ステージの３ステージでのパイプライン処理が実行される。

〈異常処理（１）〉
次に、ステップＳ７のループ処理の過程において、異常が発生した場合（図７のステップＳ７２でＹＥＳ判定になった場合）について、図面を参照しつつ説明する。

図１０は、第４サイクルのデータ受信ステージにおいて、異常が発生した例を示す。すなわち、この例では、管理サーバ５０から対象車両１０への第４ユニットのデータ受信処理において異常が発生している（図１０上段参照）。

まず、対象車両１０の演算モジュール１１３で異常が確認されると、演算モジュール１１３からパイプライン管理モジュール１１５に異常通知が送信される。パイプライン管理モジュール１１５は、通信路６２を介して管理サーバ５０に異常通知を送信し、第４ユニットのデータ再送依頼をする。さらに、対象車両１０では、演算ステージにおいて、第３演算の演算まで実行し、その後待機状態になる。また、データ送信ステージにおいて、第３ユニットのデータ送信処理まで実行し、その後待機状態となる。

管理サーバ５０では、異常通知を受信すると、データ転送を一旦停止する。

その後、データ受信ステージにおいて、第４ユニットのデータ受信処理が再度実行される。図１０下段には、第６サイクルのデータ受信ステージにおいて、第４ユニットのデータ受信処理が再開された例を示している。

対象車両１０では、第４ユニットのデータが受信されると解凍処理が実行され、その後の演算ステージ及びデータ送信ステージの処理が再開される。そして、パイプライン処理のジョブが完了するまで、データ受信ステージ、演算ステージ及びデータ送信ステージの３ステージでのパイプライン処理が実行される。

なお、所定時間にわたって異常状態が解消されない場合に、ステップＳ７のループ処理を抜けるようにしてもよい。後述する「異常処理（２）」及び「異常処理（３）」についても同様である。

〈異常処理（２）〉
図１１は、第４サイクルの演算ステージにおいて、異常が発生した例を示す。すなわち、この例では、第３ユニットを用いたアプリケーションジョブの演算処理（第３演算）の過程で異常が発生している（図１１上段参照）。

まず、対象車両１０の演算モジュール１１３で異常が確認されると、演算モジュール１１３からパイプライン管理モジュール１１５に、第３ユニットの演算処理についての異常通知が送信される。パイプライン管理モジュール１１５は、通信路６２を介して管理サーバ５０に異常通知を送信し、異常が発生した第３ユニットのデータ再送依頼をする。さらに、対象車両１０では、演算ステージにおいて、第３演算のデータを破棄して演算を一旦停止し、待機状態になる。また、データ送信ステージにおいて、第２ユニットのデータ送信処理まで完了させて、その後待機状態となる。

管理サーバ５０では、異常通知を受信すると、データ転送を一旦停止する。

その後、データ受信ステージにおいて、第３ユニットのデータ受信処理が再度実行される。図１１下段には、第５サイクルのデータ受信ステージにおいて、管理サーバ５０から対象車両１０への第３ユニットのデータ受信処理が再開された例を示している。

対象車両１０では、第３ユニットのデータが受信されると解凍処理が実行され、その後の演算ステージ及びデータ送信ステージの処理が再開される。そして、パイプライン処理のジョブが完了するまで、データ受信ステージ、演算ステージ及びデータ送信ステージの３ステージでのパイプライン処理が実行される。

〈異常処理（３）〉
図１２は、第４サイクルのデータ送信ステージにおいて、異常が発生した例を示す。すなわち、この例では、対象車両１０から管理サーバ５０への第２ユニットのデータ送信処理の途中で異常が発生している（図１２上段参照）。

まず、例えば、解凍モジュール５１８で異常が確認されると、解凍モジュール５１８から演算管理モジュール５１４に、第２ユニットのデータ送信処理についての異常通知が送信される。演算管理モジュール５１４は、異常通知を受信すると、データ受信ステージにおけるデータ転送を一旦停止する。また、演算管理モジュール５１４は、通信路６１を介して対象車両１０に異常通知を送信する。

対象車両１０では、異常通知を受信すると、演算ステージにおいて、第３演算以降のデータを破棄して演算を一旦停止し、待機状態になる。また、データ送信ステージにおいて、第２ユニット以降のデータを破棄して、待機状態となる。

その後、データ受信ステージにおいて、第４ユニットのデータ受信処理が再度実行される。図１２下段には、第５サイクルのデータ受信ステージにおいて、管理サーバ５０から対象車両１０への第２ユニットのデータ受信処理が再開された例を示している。

対象車両１０では、第２ユニットのデータが受信されると解凍処理が実行され、その後の演算ステージ及びデータ送信ステージの処理が再開される。そして、パイプライン処理のジョブが完了するまで、データ受信ステージ、演算ステージ及びデータ送信ステージの３ステージでのパイプライン処理が実行される。

－ステップＳ８－
ステップＳ８では、ジョブデータＤ１を用いて、パイプライン処理を伴わない通常のアプリケーションジョブの演算処理が実行される。

〔実施形態の効果〕
以上のように、上記の実施形態によると、管理サーバ５０において、処理対象となるジョブを複数のユニットに分割している。そして、本システム１では、管理サーバ５０から対象車両１０にユニット毎のジョブデータを転送するデータ受信ステージ、車両において各ユニットの演算を実行する演算ステージ、対象車両１０から管理サーバ５０に演算処理後の演算結果データを転送するデータ送信ステージの３ステージのパイプラインで処理するようにしている。

これにより、管理サーバ５０と対象車両１０との間におけるデータ転送期間中においても演算処理を実行することができるので、一連のジョブ完了までの時間に対して転送処理時間が与える影響を軽減することができる。

さらに、上記の実施形態では、３ステージでのパイプライン処理に先立って、管理サーバ５０から対象車両１０へのジョブ転送時間、対象車両１０における演算時間及び対象車両１０から管理サーバ５０への演算結果データの転送時間の相互間の時間差が所定時間内に収まるようにジョブと車両１０のマッチングを取るようにしている。これにより、パイプライン処理を実行する上でそれぞれのジョブに対して最適な車両１０を割り当てることができる。

なお、以上の実施形態を適宜組み合わせて実施してもよい。以上の実施形態は、本質的に好ましい例示であって、ここに開示する技術、その適用物、あるいはその用途の範囲を制限することを意図するものではない。すなわち、前述の実施形態は単なる例示に過ぎず、本開示の範囲を限定的に解釈してはならない。本開示の範囲は請求の範囲によって定義され、請求の範囲の均等範囲に属する変形や変更は、全て本開示の範囲内のものである。

以上説明したように、ここに開示する技術は、グリッドコンピューティングを管理する技術として有用である。

１０ 車両（移動体）
５０ 管理サーバ（マスタ装置）

Claims (3)

1. 複数の移動体のそれぞれに搭載される演算資源を活用したグリッドコンピューティングシステムであって、
   処理対象のジョブを管理するマスタ装置と、
   ネットワークを介して前記マスタ装置に接続された前記複数の移動体とを備え、
   前記マスタ装置において、処理対象となるジョブを複数のユニットに分割し、
   前記マスタ装置から前記移動体に前記ユニット毎のジョブデータを転送する第１転送処理、当該移動体における当該各ユニットの演算処理、及び当該移動体から前記マスタ装置に当該演算処理後の演算結果データを転送する第２転送処理のそれぞれを異なるステージとするパイプラインで処理する、
   グリッドコンピューティングシステム。
2. 複数の移動体のそれぞれに搭載される演算資源を活用したグリッドコンピューティングを管理する管理方法であって、
   処理対象となるジョブについて、当該ジョブを複数のユニットに分割した場合における前記ユニットのジョブデータ容量、前記ユニットの演算における必要リソース及び前記ユニットの演算処理後のジョブ結果容量を推定するジョブ分析工程と、
   それぞれの前記移動体について、当該移動体と前記グリッドコンピューティングのマスタ装置との間の通信帯域情報及び当該移動体の演算リソース情報を取得する移動体情報取得工程と、
   前記ジョブデータ容量と前記通信帯域情報に基づくジョブ転送時間、前記必要リソースと前記演算リソース情報に基づく演算時間、及び、前記ジョブ結果容量と前記通信帯域情報に基づく結果転送時間を推定し、当該推定された前記ジョブ転送時間、前記演算時間及び前記結果転送時間の相互間の時間差が所定時間内に収まるように移動体とジョブとのマッチングをするマッチング工程と、
   前記マスタ装置から前記マッチング工程で選定された移動体に対してマッチングされたジョブのユニット毎のジョブデータを転送する第１転送処理、当該移動体における当該各ユニットの演算処理、及び当該移動体から前記マスタ装置に当該演算処理後の演算結果データを転送する第２転送処理のそれぞれを異なるステージとするパイプラインで処理するパイプライン処理工程とを含む、
   管理方法。
3. 複数の移動体のそれぞれに搭載される演算資源を活用したグリッドコンピューティングを管理する管理システムであって、
   処理対象となるジョブについて、当該ジョブを複数のユニットに分割した場合における前記ユニットのジョブデータ容量、前記ユニットの演算における必要リソース及び前記ユニットの演算処理後のジョブ結果容量を推定するジョブ分析モジュールと、
   それぞれの前記移動体について、当該移動体と前記グリッドコンピューティングのマスタ装置との間の通信帯域情報及び当該移動体の演算リソース情報を取得する演算ノード管理モジュールと、
   前記ジョブデータ容量と前記通信帯域情報に基づくジョブ転送時間、前記必要リソースと前記演算リソース情報に基づく演算時間、及び、前記ジョブ結果容量と前記通信帯域情報に基づく結果転送時間を推定し、当該推定された前記ジョブ転送時間、前記演算時間及び前記結果転送時間の相互間の時間差が所定時間内に収まるように移動体とジョブとのマッチングをする設定モジュールと、
   前記マスタ装置から前記設定モジュールで選定された移動体に対してマッチングされたジョブのユニット毎のジョブデータを転送する第１転送処理、当該移動体における当該各ユニットの演算処理、及び当該移動体から前記マスタ装置に当該演算処理後の演算結果データを転送する第２転送処理のそれぞれを異なるステージとするパイプラインで処理するパイプライン管理モジュールとを含む、
   管理システム。
   
   

Images