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

Description

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

特許文献１には、車両に搭載された演算資源を用いたグリッドコンピューティングシステムに関する技術が開示されている。特許文献１では、複数の処理装置の少なくともいずれかの処理能力が不足している場合に、管理サーバから車両にグリッドコンピューティングへの参加指示を送信するように構成されている。

特許文献２には、車両のユーザに提供されるサービスの内容をユーザごとに管理する技術が開示されている。特許文献２では、車両のユーザがサービスを利用するとき、車両に付与された車両ＩＤ及び当該ユーザに付与されたユーザＩＤの両方に関連付けられたライセンス情報を記憶部から読み出し、当該車両のユーザに提供するサービスの内容をサービス管理部を通じて管理する。

特開２０２０－１６０６６１号公報 特開２０１９－１０９８１６号公報

ところで、車両の非稼働時に、車両の演算資源を用いてグリッドコンピューティングの演算（以下、「グリッド演算」ともいう）を実行させるにあたり、グリッド演算における各演算資源の客観的な品質が求められる。したがって、グリッド演算の開始や停止について、所有者やドライバの意図しない演算の開始や停止が行われるのは好ましくない。一方で、商用車や社用車（以下、「商用車等」という）のような場合や、家族での自家用車の共用のような場合において、複数のユーザで１台の車両をシェアすることが想定される。

演算資源の客観的な品質を高めるために、グリッド演算の開始や停止のたびに、車両を使用する可能性のあるメンバー全員に問い合わせをすることも考えられるが、非常に煩雑かつ複雑になる恐れがある。また、車両の状況が把握できない場合も想定され、そういった場合には、グリッド演算の開始や停止の正しい判断ができないという課題がある。

ここに開示された技術は斯かる点に鑑みてなされたものであり、グリッド演算における演算資源の客観的な品質を確保しつつ、車両を使用する可能性のあるメンバー全員に問い合わせをするといった煩雑さや手続きの複雑さを解消することを目的とする。

前記課題を解決するために、本開示の第１態様では、管理サーバを用いて車両に搭載された演算資源を活用したグリッドコンピューティングを管理する管理方法を対象として、前記車両には、ドライバを認識するセンサが設けられ、オペレータまたは前記車両の所有者により指定された前記車両のドライバ候補者を登録ユーザとしてユーザテーブルに登録する登録工程と、前記管理サーバが、前記車両の利用予約状況を管理する予約テーブルに、オペレータまたは前記車両の利用者により指定された日時に当該車両の利用予約を設定する予約設定工程と、前記予約テーブルの予約日時に前記センサで前記予約テーブルに登録された登録ユーザによる前記車両の運転が確認された場合に、前記管理サーバが、当該車両におけるグリッドコンピューティングの演算開始及び演算停止を承認する操作を受け付ける対象ユーザを、演算開始の直前に運転していた前記登録ユーザに設定する管理ユーザ設定工程とを備える、という構成にした。

上記第１態様によると、車両におけるグリッドコンピューティングの演算開始及び演算停止を承認する操作を受け付ける対象ユーザを直前に運転していた登録ユーザに設定している。これにより、グリッド演算における演算資源の客観的な品質を確保しつつ、車両を使用する可能性のあるメンバー全員に問い合わせをするといった煩雑さや手続きの複雑さを解消することができる。

本開示の第２態様では、管理サーバを用いて車両に搭載された演算資源を活用したグリッドコンピューティングを管理する管理システムを対象として、前記車両は、ドライバを認識するセンサを備え、前記管理サーバは、制御部と、登録ユーザが登録されるユーザテーブル及び車両の利用予約状況を管理する予約テーブルが記憶される記憶部とを備え、前記管理サーバの制御部は、オペレータまたは前記車両の所有者により指定された前記車両のドライバ候補者を前記登録ユーザとして前記ユーザテーブルに登録する登録工程と、オペレータまたは前記車両の利用者により指定された日時における当該車両の利用予約を前記予約テーブルに設定する予約設定工程と、前記予約テーブルの予約日時に前記センサで前記予約テーブルに登録された登録ユーザによる前記車両の運転が確認された場合に、当該車両におけるグリッドコンピューティングの演算開始及び演算停止を承認する操作を受け付ける対象ユーザを前記演算開始の直前に運転していた前記登録ユーザに設定する管理ユーザ設定工程とを実行する、という構成にした。

上記第２態様によると、第１態様と同様に、グリッド演算における演算資源の客観的な品質を確保しつつ、車両を使用する可能性のあるメンバー全員に問い合わせをするといった煩雑さや手続きの複雑さを解消することができる。

以上説明したように、ここに開示された技術によると、グリッド演算における演算資源の客観的な品質を確保しつつ、車両を使用する可能性のあるメンバー全員に問い合わせをするといった煩雑さや手続きの複雑さを解消することができる。

実施形態のシステムの構成を例示する概略図 グリッドコンピューティングについて説明するための概念図 車両の構成を例示するブロック図 クライアントサーバの構成を例示するブロック図 管理サーバの構成を例示するブロック図 グリッドコンピューティングシステムの動作例を示すフローチャート グリッドコンピューティングシステムの動作例を示すフローチャート グリッド開始条件の判定フローの一例を示すフローチャート

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

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

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

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

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

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

図３に示すように、車両１０は、通信部１０１と、演算装置（プロセッサ）１０２と、記憶部１０３と、乗員センサ１１１と、運転操作センサ１１２と、車両状態センサ１１３と、位置センサ１１４とを備える。以下の説明では、乗員センサ１１１、運転操作センサ１１２、車両状態センサ１１３、及び位置センサ１１４を総称してセンサ群１１０という場合がある。

－通信部－
通信部１０１は、通信網６を介して管理サーバ５０と情報やデータを送受信する。通信部１０１により受信された情報やデータは、演算装置１０２に送られる。

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

演算装置１０２は、１または複数のプロセッサ及び１または複数のメモリを有する。演算装置１０２は、車両内の１箇所にまとめて配置されていてもよいし、車両内に分散して配置されてもよい。プロセッサの例としては、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）などが挙げられる。メモリは、プロセッサを動作させるためのプログラム、プロセッサの処理結果を示す情報やデータなどを記憶する。

本開示では、演算装置１０２の中でグリッドコンピューティングの演算・処理に利用可能なリソースを、説明の便宜上「演算資源」と称して説明する。

なお、演算資源は、車両１０の制御に用いられるリソースを兼用してもよいし、車両の制御に使用しないグリッドコンピューティング専用のＣＰＵやＧＰＵを用いてもよい。

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

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

－乗員センサ－
乗員センサ１１１は、ドライバを認証するのに必要な情報を取得する。乗員センサ１１１は、特に限定されないが、例えば、ドライバの顔が撮影可能な位置に設置された車内カメラ（図示省略）を含む。車内カメラによって撮像された画像は、演算装置１０２に送信される。演算装置１０２では、運転者の顔画像を抽出し、ドライバを特定する。

ドライバの特定方法は特に限定されないが、例えば、深層学習の技術を用いることができる。深層学習を用いる場合、抽出した顔画像と特定した運転者の情報は、人間モデルに入力として与えられる。人間モデルは、例えば深層学習によって生成された学習済みモデルである。

乗員センサ１１１として、虹彩認識、指紋センサ、声紋センサ、身体計測センサ等の生体情報センサを用いてもよい。また、車内カメラの画像と上記各センサ等で取得された情報を複合的に利用して運転者を特定するようにしてもよい。

ドライバを認証する認証部は、例えば、乗員センサと演算装置１０２で実現できる。なお、乗員センサ１１１で取得された情報を管理サーバ５０に送信し、演算装置１０２の機能の一部または全部を管理サーバ５０の制御部５０２で実現してもよい。ただし、車両内において認証部の機能を完結させることで、よりセキュアな処理を実現できる。

－運転操作センサ－
運転操作センサ１１２は、ドライバの運転操作を検出する。運転操作センサ１１２として、例えば、アクセル開度センサ、シフトセンサ、ブレーキセンサ及び操舵角センサ等が例示される。運転操作センサ１１２での検出信号は、演算装置１０２に送信される。駐車状態を検知する駐車検知部は、運転操作センサ１１２及び演算装置１０２で実現できる。例えば、ブレーキセンサでサイドブレーキがかけられた状態であることが検知され、かつ、シフトセンサでシフトレバーがパーキングに設定されたことが検知されたとき、演算装置１０２は車両１０が駐車状態であると判断する。なお、演算装置１０２は、運転操作センサ１１２に加えて、後述する位置センサ１１４や車両状態センサ１１３の検知情報を用いる等、複合的な情報に基づいて駐車状態を検知するようにしてもよい。

－車両状態センサ－
車両状態センサ１１３は、車両１０の状態を取得する。車両状態センサ１１３は、例えば、車速センサ、加速度センサ、ヨーレートセンサ等で構成される。運転操作センサ１１２での検出信号は、演算装置１０２に送信される。前述のとおり、車両状態センサ１１３が駐車検知部の一部を構成してもよい。

車両状態センサ１１３は、車両１０のドアロック状態を検知するセンサを含む。具体的に、車両状態センサ１１３は、ドアの開閉状態の検知、車両に設けられたドアのロック状態の検知、ボンネットの開閉状態の検知、及び、リフトゲートの位置やトランクの開閉状態の検知をするリッドセンサを含む。リッドセンサは、ドアロック状態を検知するロック検知部の一例である。

なお、ロック検知部の具体的態様は、リッドセンサに限定されない。例えば、キーレスエントリー装置やイモビライザー認証装置からの施錠信号に基づいてドアロック用のアクチュエータが作動された場合に、そのアクチュエータを作動させたことに基づいて車両がドアロック状態にあると判断としてもよい。

－位置センサ－
位置センサ１１４は、全地球測位システム（Global Positioning System：ＧＰＳ）を利用して、車両１０の位置（車両位置情報）を検出する。運転操作センサ１１２で取得された情報は、演算装置１０２に送信される。

前述のとおり、車両状態センサ１１３が駐車検知部の一部を構成してもよい。具体的に、例えば、演算装置１０２は、運転操作センサ等で車両の停車が確認された位置が駐車場等の駐車可能領域であれば駐車と判断し、停車位置が交差点等の駐車不可領域であれば駐車とは判断しない、としてもよい。

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

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

〈車両基本情報〉
車両基本情報Ｄ１１は、車両識別情報及びリソース情報を含む。

車両識別情報は、ＶＩＮのように車両を識別するための情報が含まれる。

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

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

車両位置情報は、車両１０の位置（緯度および経度）を示す。例えば、車両位置情報は、位置センサ１１４で取得される。

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

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

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

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

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

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

〈ユーザ情報〉
ユーザ情報Ｄ２０は、車両を運転する可能性があるドライバ候補者（以下、「登録ユーザ」という）に関する情報であり、例えば、主ユーザ情報Ｄ２１と副ユーザ情報Ｄ２２を含む。

主ユーザ情報Ｄ２１は、車両１０に登録された主となるユーザである主ユーザに関する情報である。主ユーザとは、例えば、商用車等の場合、主としてその商用車等を使用する従業員、利用頻度が最も高い従業員などである。

主ユーザ情報Ｄ２１は、主ユーザを特定するための情報を含む。主ユーザを特定するための情報とは、例えば、あらかじめ撮影された主ユーザの写真や、あらかじめ登録された主ユーザの虹彩情報、指紋情報、及び／または、声紋情報を含む。主ユーザ情報Ｄ２１は、主ユーザが変更された場合、更新される。例えば、商用車等であれば担当するドライバが変更されたりした際に更新される。なお、主ユーザ情報Ｄ２１として、主ユーザの連絡先（例えば、主ユーザが所有する端末装置４０のメールアドレス等）が登録されていてもよい。

副ユーザ情報Ｄ２２は、車両１０に登録された主ユーザ以外に運転する可能性のあるユーザ（「副ユーザ」と称する）に関する情報である。副ユーザ情報Ｄ２２は、副ユーザを特定するための情報を含む。副ユーザを特定するための情報とは、例えば、あらかじめ撮影された副ユーザの写真や、あらかじめ登録された副ユーザの虹彩情報、指紋情報、及び／または、声紋情報を含む。副ユーザ情報Ｄ２２は、追加や削除等の更新ができる。例えば、車両１０の所有者が副ユーザとして家族や友人等を追加・削除したり、商用車等であれば、運転する可能性のある従業員が副ユーザとして登録され得る。なお、副ユーザ情報Ｄ２２として、副ユーザの連絡先（例えば、副ユーザが所有する端末装置４０のメールアドレス等）が登録されていてもよい。

なお、運転する可能性があるすべてのドライバ候補者について、主ユーザと副ユーザとを区別せずに管理してもよい。ユーザ情報Ｄ２０に登録される主ユーザ及び副ユーザは、登録ユーザの一例である。

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

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

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

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

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

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

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

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

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

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

図５に示すように、管理サーバ５０は、通信部５０１と、制御部５０２と、記憶部５０３とを備える。管理サーバ５０は、１または複数のプロセッサ及び１または複数のメモリなどを有する。

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

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

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

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

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

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

〈ユーザテーブル〉
ユーザテーブルＤ５６は、各車両１０の登録ユーザ（例えば、主ユーザ及び副ユーザ）を管理するためのテーブルである。ユーザテーブルＤ５６には、例えば、各車両の車両識別情報と、それぞれの車両の主ユーザの識別情報及び副ユーザの識別情報とが紐づけされて、リスト化されて格納されている。主ユーザの識別情報及び副ユーザの識別情報の形態は特に限定されないが、例えば、各ユーザに付された識別ＩＤであってもよいし、各ユーザの氏名等であってもよい。また、ユーザテーブルには、主ユーザ及び副ユーザの連絡先が登録されている。

なお、管理サーバ５０で認証部の機能の一部を実現する場合、記憶部５０３にユーザ情報Ｄ２０に相当する情報（車両から受信した写真や生体情報等のデータに基づいて主ユーザを特定するのに必要な情報）を格納しておく必要がある。

〈予約テーブル〉
予約テーブルＤ５７は、車両の利用予約を管理するテーブルである。例えば、車両１０が特定の企業が従業員（以下、ユーザという）に使用させる商用車等の場合に、その商用車等の利用予約を管理するテーブルである。なお、普段使用するユーザが決まっている場合には、そのユーザを主ユーザとして登録し、それ以外のユーザの使用についてのみ予約テーブルＤ５７で管理するようにしてもよい。

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

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

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

制御部５０２は、クライアント端末３０から受信した情報やデータを記憶部５０３に記憶する。例えば、制御部５０２は、クライアント端末３０からジョブデータＤ１を受信すると、ジョブデータＤ１を記憶部５０３に保存する。また、制御部５０２は、クライアント端末３０からジョブ情報Ｄ３２を受信すると、記憶部５０３のジョブテーブルＤ５３に登録する。

制御部５０２は、それぞれの車両１０及び／または主ユーザの端末装置４０から受信された情報及び／またはデータを記憶部５０３に記憶する。制御部５０２は、例えば、車両１０から車両情報Ｄ１０（車両走行情報、リソース情報を含む）を受信すると、記憶部５０３の車両情報テーブルＤ５１に登録する。また、制御部５０２は、例えば、主ユーザの端末装置４０から副ユーザの追加／削除連絡を受信すると、ユーザテーブルＤ５６のユーザ情報を更新する。

〔グリッドコンピューティングシステムの動作〕
以下において、グリッドコンピューティングシステムの動作例について、図６～図８のフローチャートを参照しつつ説明する。図６は、車両の動作や車両での制御・処理を中心に記載したフローチャートである。図７は、図６と同じ内容の動作について、車両と管理装置の間の連携、及び管理装置と主ユーザの所有する端末装置の間における連携という観点で記載したフローチャートである。図６と図７において、同じ処理については、同じ符号を付している。また、図８は、グリッド開始条件の判定フローの一例を示している。

－ステップＳ１１（Ｓ４１，Ｓ５１）－
ステップＳ１１では、車両の所有者により指定されたドライバ候補者が、車両のユーザテーブルに登録ユーザとして登録される。

例えば、車両の所有者が車室内に設けられた乗員センサ１１１を登録ユーザを登録するための登録モードに設定し、車両の停車中または走行中に主ユーザの情報が登録されるようにしてもよい。また、主ユーザが所有する端末装置４０を用いて登録されてもよい。

主ユーザの登録情報は、記憶部１０３にユーザ情報Ｄ２０として格納される。また、車両１０に主ユーザの連絡先が登録されてもよい。その登録方法は、特に限定されず、従来から広く知られている方法を用いることができる。

ステップＳ５１に示すように、管理サーバ５０は、例えば、管理サーバ５０が管理する車両について、オペレータにより指定されたドライバ候補者を登録ユーザとしてユーザテーブルＤ５６に登録する。例えば、管理サーバ５０が企業に設置されている場合に、企業が所有する商用車等について、オペレータが、運転する可能性のあるドライバ候補者を登録ユーザとしてユーザテーブルＤ５６に登録する。この例では、図１に示すように、車両１１に登録ユーザとして主ユーザＰ１１が登録され、車両１２に登録ユーザとして主ユーザＰ２１と副ユーザＰ２２が登録されている。

なお、端末装置４０から管理サーバ５０に対して、車両１０の主ユーザが登録されてもよい。すなわち、車両の所有者により指定された車両のドライバ候補者を登録ユーザとして管理サーバ５０に登録してもよい。

－ステップＳ１２、Ｓ１３－
ステップＳ１２では、車両１０のイグニッション電源がＯＮ（電気自動車の場合、駆動電源がＯＮ）されて、車両１０の走行が開始される。次のステップＳ１３において、演算装置１０２は、車両の走行開始から駐車までの間に、センサ群１１０からの入力情報に基づいて、走行中の車両を運転するドライバを認識する。そして、車両を運転しているドライバがあらかじめ登録された登録ユーザと一致する場合、そのドライバをその車両におけるグリッド演算の承認手続き及び変更手続きができる管理ユーザに設定する。

－ステップＳ１４－
ステップＳ１４において、例えば、車両１０が駐車場に入って駐車領域に入り、イグニッション電源がＯＦＦ（電気自動車の場合、駆動電源がＯＦＦ）されて、走行状態から駐車状態となる。そうすると、駐車検知部（例えば、運転操作センサ１１２及び車両状態センサ１１３）により車両の駐車状態が検知され、フローは次のステップＳ１５に進む。

－ステップＳ１５－
ステップＳ１５では、演算装置１０２は、グリッド開始条件が充足されているかどうかを判定する。具体的には、例えば、グリッド開始条件として、駐車検知部で車両の駐車が検知されている状態において、ドライバの降車が確認された後に、ロック検知部で車両のドアロック状態が検知されることという条件が設定される。

図８には、グリッド開始条件の判定フローの一例を示す。図８の例では、演算装置１０２は、ステップＳ１５１～ステップＳ１５４の判定を並行して実行する。ステップＳ１５１では、リッドセンサを用いてドアの開閉状態を判定する。ステップＳ１５２では、リッドセンサを用いてドアロック状態を判定する。ステップＳ１５３では、リッドセンサを用いてボンネットの開閉状態を判定する。ステップＳ１５４では、リッドセンサを用いて、リフトゲートの位置やトランクの開閉状態を判定する。

次のステップＳ１５５において、演算装置１０２は、ステップＳ１５１～ステップＳ１５４の判定結果に基づいて、車両１０のドアロック状態を判定する。例えば、演算装置１０２は、車室が閉塞されかつそれらがロックされた状態となっていれば、ドアロック状態の判定結果としてＯＫである、すなわち、グリッド開始条件が充足されていると判定する。この例では、演算装置１０２は、ステップＳ１５１ですべてのドアが閉状態であること、ステップＳ１５２ですべてのドアがロック状態であること、ステップＳ１５３でボンネットが閉状態であること、かつ、ステップＳ１５４でリフトゲートが閉位置にありトランクが閉状態であることが検知された場合に、グリッド開始条件が充足されていると判定する。そして、ステップＳ１５５でＯＫ判定となれば、フローは次のステップＳ１６（図６参照）に進む。

－ステップＳ１７～Ｓ２０－
図６及び図７に戻り、ステップＳ１７では、演算装置１０２は、グリッド演算を開始することについて管理ユーザへの問い合わせ依頼を管理サーバ５０に送信する。

より具体的には、図７のステップＳ５２において、管理サーバ５０は、車両１２から上記の問い合わせ依頼を受信すると、記憶部５０３のユーザテーブルＤ５６を参照して、直前に運転している登録ユーザ（管理ユーザ）の連絡先に、これから車両１２でグリッド演算を実行してよいかの確認連絡を送信する。

ステップＳ４２において、端末装置４０は、管理サーバ５０から上記の確認連絡を受信すると、その内容を表示画面に表示し、管理ユーザの応答操作を受け付ける。端末装置４０は、管理ユーザからの応答操作情報を取得すると、その応答結果を管理サーバに送信する。

ステップＳ５３において、管理サーバ５０は、端末装置４２から管理ユーザの応答結果を受信すると、その内容を車両１０に送信する。

車両において、次のステップＳ１８では、管理ユーザからの使用許可が出たか否かが判定される。図７では、管理ユーザは、車両１０でのグリッド演算を許可した例を示している。

ステップＳ５４において、管理サーバ５０の制御部５０２は、依頼対象となるアプリケーションジョブ用のジョブデータＤ１を車両１２に送信する。なお、管理サーバ５０は、図７の場合と同様に、車両１２から送信要求を受けた後に、車両１２にジョブデータＤ１を送信するようにしてもよい。

ステップＳ２２において、演算装置１０２は、管理サーバ５０からジョブデータＤ１を受信する。その後、演算装置１０２は、ジョブデータＤ１を用いてグリッド演算を開始する（ステップＳ２３）。演算装置１０２は、グリッド演算が終了すると（ステップＳ２３）、その演算結果を管理サーバ５０に送信する（ステップＳ２４）。管理サーバ５０において、演算装置１０２からの演算結果が受信されると、一連の処理は終了となる。なお、駐車時間に余裕がある場合に、ステップＳ２０の処理を繰り返し実行してもよい。

一方で、ステップＳ５３において管理サーバ５０が受信した応答結果が、車両１２でのグリッド演算を許可しない場合、図６のステップＳ１８において、許可なしの判定となり、車両１２では、グリッド演算が実行されることなく、一連の処理が終了する。

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

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

１０ 車両
５０ 管理サーバ（管理装置）
１０１ 通信部
１１１ 乗員センサ（センサ）
１１２ 運転操作センサ（駐車検知部）
１１３ 車両状態センサ（駐車検知部、ロック検知部）
５０１ 通信部
５０３ 記憶部
Ｄ５６ ユーザテーブル
Ｄ５７ 予約テーブル

Claims (2)

1. 管理サーバを用いて車両に搭載された演算資源を活用したグリッドコンピューティングを管理する管理方法であって、
   前記車両には、ドライバを認識するセンサが設けられ、
   前記管理サーバの制御部が、オペレータまたは前記車両の所有者により指定された前記車両のドライバ候補者を登録ユーザとしてユーザテーブルに登録する登録工程と、
   前記管理サーバの制御部が、前記車両の利用予約状況を管理する予約テーブルに、オペレータまたは前記車両の利用者により指定された日時に当該車両の利用予約を設定する予約設定工程と、
   前記予約テーブルの予約日時に前記センサで前記予約テーブルに登録された登録ユーザによる前記車両の運転が確認された場合に、前記管理サーバの制御部が、当該車両におけるグリッドコンピューティングの演算開始及び演算停止を承認する操作を受け付ける対象ユーザを、演算開始の直前に運転していた前記登録ユーザに設定する管理ユーザ設定工程とを備える、
   グリッドコンピューティングの管理方法。
2. 管理サーバを用いて車両に搭載された演算資源を活用したグリッドコンピューティングを管理する管理システムであって、
   前記車両は、ドライバを認識するセンサを備え、
   前記管理サーバは、
   制御部と、
   登録ユーザが登録されるユーザテーブル及び車両の利用予約状況を管理する予約テーブルが記憶される記憶部とを備え、
   前記管理サーバの制御部は、
   オペレータまたは前記車両の所有者により指定された前記車両のドライバ候補者を前記登録ユーザとして前記ユーザテーブルに登録する登録工程と、
   オペレータまたは前記車両の利用者により指定された日時における当該車両の利用予約を前記予約テーブルに設定する予約設定工程と、
   前記予約テーブルの予約日時に前記センサで前記予約テーブルに登録された登録ユーザによる前記車両の運転が確認された場合に、当該車両におけるグリッドコンピューティングの演算開始及び演算停止を承認する操作を受け付ける対象ユーザを前記演算開始の直前に運転していた前記登録ユーザに設定する管理ユーザ設定工程とを実行する、
   グリッドコンピューティングの管理システム。