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

Abstract

【課題】演算資源の客観的な品質を確保しつつ、問い合わせ手続きの複雑さを解消する。【解決手段】グリッドコンピューティングの管理方法は、車両の登録ユーザをユーザテーブルに登録する登録工程と、車両が走行状態から駐車状態となり、車両の駐車が検知されかつ車両のドアロック状態が検知された場合において、センサで車両の車室内に乗員が検知されていないとき、自動的に前記演算資源によるグリッドコンピューティングの演算を開始する一方で、センサで前記車両の車室内に乗員が検知されているとき、報知部にグリッドコンピューティングの演算開始の問い合わせを発し、問い合わせに対する乗員の承認操作が受け付けられたことを条件としてグリッドコンピューティングの演算を開始する演算工程とを備える。【選択図】図６

Description

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

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

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

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

ところで、車両の非稼働時に、車両の演算資源を用いてグリッドコンピューティングの演算（以下、「グリッド演算」ともいう）を実行させるにあたり、グリッド演算における各演算資源の客観的な品質が求められる。

車両の非稼働時には、乗員が搭乗していないのが一般的であるが、例えば、乗員が別々の行動をする場合や待ち合わせをしているような場合に、乗員が車中に残っている場合がある。このように、車中に乗員が残っている場合に、一律でグリッド演算をできないものとすると、グリッド演算の機会ロスが発生する。

ここに開示された技術は斯かる点に鑑みてなされたものであり、乗員が車内で過ごすような場合においても、セキュリティを保った状態でグリッド演算を開始できるようにすることを目的とする。

前記課題を解決するために、本開示の第１態様では、車両に搭載された演算資源を活用したグリッドコンピューティングの管理方法を対象として、前記車両には、乗員を認識するセンサと、当該車両の駐車状態を検知する駐車検知部と、当該車両のドアロックの状態を検知するロック検知部と、乗員向けのコンテンツを発する報知部が設けられ、前記車両の登録ユーザをユーザテーブルに登録する登録工程と、前記車両が走行状態から駐車状態となり、前記駐車検知部で当該車両の駐車が検知されかつ前記ロック検知部で当該車両のドアロック状態が検知された場合において、前記センサで前記車両の車室内に乗員が検知されていないとき、前記車両は、自動的に前記演算資源によるグリッドコンピューティングの演算を開始し、前記センサで前記車両の車室内の乗員として前記登録ユーザが検知されているとき、前記車両では、前記報知部からグリッドコンピューティングの演算開始の問い合わせを発し、その後に、当該問い合わせに対する前記登録ユーザの承認入力が受け付けられたことを条件としてグリッドコンピューティングの演算を開始する演算工程とを含む、という構成にした。

上記第１態様によると、車両の駐車後にドアロック状態が検知された場合に、車両の車室内に乗員が検知されていない場合、自動的に演算を開始するようにしている。これにより、ユーザの手を煩わせることなく、グリッド演算を開始することができる。また、登録ユーザがドアロック後に車室内で過ごすような場合においても、車載の報知部に問い合わせを表示し、登録ユーザの承認応答が受け付けられたことを条件としてグリッド演算を開始するようにしている。これにより、セキュリティを保った状態でグリッド演算を開始することができる。

本開示の第２態様では、車両に搭載された演算資源を活用したグリッドコンピューティングシステムを対象として、前記車両は、乗員を認識するセンサと、前記車両の駐車状態を検知する駐車検知部と、前記車両のドアロックの状態を検知するロック検知部と、乗員向けのコンテンツを発する報知部と、前記車両の登録ユーザが登録されるユーザテーブルが格納される記憶部と、演算装置とを備え、前記演算装置は、前記車両の登録ユーザを前記ユーザテーブルに登録する登録工程と、前記車両が走行状態から駐車状態となり、前記駐車検知部で当該車両の駐車が検知されかつ前記ロック検知部で当該車両のドアロック状態が検知された場合において、前記センサで前記車両の車室内に乗員が検知されていないとき、自動的に前記演算資源によるグリッドコンピューティングの演算を開始し、前記センサで前記車両の車室内の乗員として前記登録ユーザが検知されているとき、前記車両では、前記報知部からグリッドコンピューティングの演算開始の問い合わせを発し、その後に、当該問い合わせに対する前記登録ユーザの承認入力が受け付けられたことを条件としてグリッドコンピューティングの演算を開始する演算工程とを実行する、という構成にした。

上記第２態様によると、第１態様と同様に、車両の車室内に乗員が検知されていない場合には、ユーザの手を煩わせることなくグリッド演算を開始することができる。また、乗員が車内で過ごすような場合においても、セキュリティを保った状態でグリッド演算を開始することができる。

以上説明したように、ここに開示された技術によると、乗員が車内で過ごすような場合においても、セキュリティを保った状態でグリッド演算を開始することができる。

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

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

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

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

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

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

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

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

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

－タッチパネル－
タッチパネル１０５は、後述する「グリッドコンピューティングシステムの動作」において、車両の駐車後にドアロック状態が検知された場合に、車中に残っている乗員に対して問い合わせ画面を表示して、その乗員の入力操作を受け付ける機能を有する。

タッチパネル１０５の構成及び画面の表示形態は、特に限定されないが、例えば、車載のカーナビゲーションシステムの画面をタッチパネル１０５として利用することができる。また、メータパネルやヘッドアップディスプレイなどにタッチパネル１０５としての機能を持たせるようにしてもよい。

また、タッチパネル１０５に代えて、車中に残っている乗員に対して問い合わせ画面を表示する表示部と、応答操作を受け付ける入力部とを別々に構成してもよい。入力部への入力形態は、特に限定されない。例えば、押しボタン式のスイッチや前述のタッチパネルのように手で操作する形式であってもよい。タッチパネル１０５は、報知部の一例である。

なお、報知部の報知態様は、表示部への表示に限定されない、例えば、音声による通知であってもよい。入力部もタッチ操作に限定されず、例えば、マイクなどの音声入力装置（図示省略）であってもよいし、モーションキャプチャー装置（図示省略）を用いてもよい。

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

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

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

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

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

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

－乗員センサ－
乗員センサ１１１は、車室内の乗員（ドライバを含む）を認証するのに必要な情報を取得する。乗員センサ１１１は、特に限定されないが、例えば、ドライバや他の乗員の顔が撮影可能な位置に設置された車内カメラ（図示省略）、及びオーバーヘッドコンソールに設置された超音波式の人感センサを含む。車内カメラによって撮像された画像は、演算装置１０２に送信される。演算装置１０２では、乗員の顔画像を抽出し、ドライバや、他座席の乗員をそれぞれ特定する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

〈ユーザテーブル〉
ユーザテーブルＤ２０には、登録されたユーザ（以下、登録ユーザと称する）に関する情報（以下、「ユーザ情報」という）が登録されている。ユーザ情報には、主ユーザ情報Ｄ２１と副ユーザ情報Ｄ２２を含む。

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

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

なお、運転する可能性があるすべてのドライバ候補者について、主ユーザと副ユーザとを区別せずに、両者を単なる「登録ユーザ」として管理してもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

－ステップＳ１１（Ｓ４１，Ｓ５１）－
ステップＳ１１では、車両１０に登録ユーザが登録される。登録ユーザの登録方法は、特に限定されない。例えば、車室内に設けられた乗員センサ１１１を用いて停車中または走行中に登録ユーザの情報が登録されてもよいし、登録ユーザが所有する端末装置４０を用いて登録されてもよい。登録ユーザの情報は、記憶部１０３のユーザテーブルＤ２０に登録される。また、ユーザテーブルＤ２０に登録ユーザの連絡先が登録されてもよい。その登録方法は、特に限定されず、従来から広く知られている方法を用いることができる。

また、図７に示すように、端末装置４０から管理サーバ５０に対して、車両１０の登録ユーザが連絡先とともに登録される。

この例では、図１に示すように、車両のオーナーＰ１１が、所有する車両１１について、端末装置４１を用いて自分を主ユーザＰ１１として管理サーバ５０に登録する。また、車両のオーナーＰ２２が、所有する車両１２について、端末装置４２を用いて自分を主ユーザＰ２１、他人を副ユーザＰ２２として管理サーバ５０に登録する。

それぞれの端末装置４１，４２では、それぞれの主ユーザＰ１１，Ｐ２１の入力情報に基づいて、ユーザテーブルＤ５６での管理に必要な情報を管理サーバ５０に送信する。管理サーバ５０では、受信したユーザ情報を記憶部５０３のユーザテーブルＤ５６に登録する。

ここでの処理は、登録ユーザをユーザテーブルＤ２０またはユーザテーブルＤ５６に登録する登録工程に相当する。なお、ユーザテーブルＤ２０の情報と、ユーザテーブルＤ５６の情報とが車両１０と管理サーバ５０との間で同じ情報となるように、相互間の情報共有がされるように構成してもよい。この例では、車両１０のユーザテーブルＤ２０の情報と、管理サーバ５０のユーザテーブルＤ５６の情報は、同じであるものとする。

－ステップＳ１２，Ｓ１３－
ステップＳ１２では、車両１０のイグニッション電源がＯＮ（電気自動車の場合、駆動電源がＯＮ）されて、車両１０の走行が開始される。次のステップＳ１３において、演算装置１０２は、車両の走行開始から駐車までの間に、センサ群１１０からの入力情報に基づいて、走行中の車両を運転するドライバを認識する。この例では、車両１１では、主ユーザＰ１１が運転し、車両１２では、副ユーザＰ２２が運転している、そうすると、車両１１では、主ユーザＰ１１がドライバとして認識され、車両１２では、副ユーザＰ２２がドライバとして認識される。また、演算装置１０２は、他の乗員についてもドライバと同様に認識する。この例では、車両１２には、登録ユーザではないユーザＰ２３が乗員として乗っている。

このとき、演算装置１０２は、ユーザテーブルＤ２０を用いて、それぞれの乗員が登録ユーザであるか否かを判定するようにしてもよい。この例では、車両１１では、主ユーザＰ１１が登録ユーザと判定される。車両１２では、副ユーザＰ２２が登録ユーザと判定され、ユーザＰ２３は登録ユーザではないと判定される。なお、登録ユーザの判定に際し、管理サーバ５０に乗員の情報を送信し、判定結果を問い合わせるようにしてもよい。

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

－ステップＳ２０－
ステップＳ２０では、演算装置１０２は、グリッド開始条件が充足されているかどうかを判定する。以下、具体例を示しつつ説明する。

－ステップＳ２１－
ステップＳ２１では、グリッド演算の開始条件を満たすかどうかを判定している。グリッド演算の開始条件は、例えば、駐車検知部で車両の駐車が検知された後に、乗員センサ１１１で乗員の降車が確認され、かつ、車室内に誰も残っていない状態においてロック検知部で車両のドアロック状態が検知されることである。

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

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

ステップＳ２１の条件が満たされる場合、すなわち、車両１０の駐車後に乗員がいない状態でドアロックがされたことが検知された場合（Ｓ２１でＹＥＳ）、演算装置１０２は、自動的に演算資源によるグリッド演算を開始する（ステップＳ３０）。図６のステップＳ３０は、図７ＡのステップＳ３１～Ｓ３５に相当する。

図７Ａには、図６のステップＳ２１でＹＥＳ判定となり、次のステップＳ３０において自動的にグリッド演算が開始された場合のフローを示している。図７ＡのステップＳ１１～Ｓ１５，Ｓ２０までの動きは、図６と同じであり、ここではステップＳ３１以降の動作について説明する。

ステップＳ３１において、演算装置１０２は、管理サーバ５０に対して、グリッド演算に用いるジョブデータＤ１の送信を要求する。

ステップＳ５４において、演算装置１０２からの送信要求を受けた管理サーバ５０の制御部５０２は、依頼対象となるアプリケーションジョブ用のジョブデータＤ１を車両１１に送信する。

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

一方で、車両１０のドアロックが検知された後に、車室内に乗員が残っている場合には、ステップＳ２１でＮＯ判定となり、フローはステップＳ２２に進む。

－ステップＳ２２～Ｓ２６－
ステップＳ２２では、車両１０のドアロックが検知された後に、車室内に残っている乗員が、登録ユーザか否かが判定される。

〈車室内に残っているユーザが登録ユーザの場合〉
図７Ｂには、ドアロック時に車室内に残っている登録ユーザにより演算開始が承認された場合のフローを示している。この例では、車両１１においてドアロック時に主ユーザＰ１１が車室内に残っている場合、及び、車両１２においてドアロック時に副ユーザＰ２２が車室内に残っている場合の動作に相当する。なお、図７ＢのステップＳ１１～Ｓ１５及びＳ２０までの動きは、図６と同じであり、ここではステップＳ２２以降の動作について図６及び図７Ｂを用いて説明する。

図６のステップＳ２２において、車室内に残っている乗員が登録ユーザの場合（Ｓ２２でＹＥＳ）、次のステップＳ２３において、演算装置１０２は、グリッド演算を開始してよいかの問い合わせ画面がタッチパネル１０５に表示されるように制御する。次のステップＳ２４では、乗員（登録ユーザ）からの使用許可が得られた否かが判定される。

より具体的には、図７ＢのステップＳ４２において、タッチパネル１０５に問い合わせ画面が表示され、登録ユーザによるタッチ操作が行われると、その操作情報が演算装置１０２に送信される。

図６に戻り、ステップＳ２４において、乗員からグリッド演算の承認操作がされた場合、フローは次のステップＳ３０、すなわちグリッド演算の実行に進む。図７ＢのステップＳ３１～Ｓ３５，Ｓ５４及びＳ５５の動きは、図７Ａと同じであり、ここではその説明を省略する。

一方で、ステップＳ５３において、乗員からグリッド演算の不許可操作がされた場合、図６のステップＳ２４において、許可なしの判定となる。その結果、車両１２では、グリッド演算が実行されることなく、一連の処理が終了する。

〈車室内に残っているユーザが登録ユーザ以外の場合〉
図７Ｃには、ドアロック時に車室内に残っている乗員が登録ユーザ以外のユーザであり、車外にいる登録ユーザに通知がされて、その登録ユーザにより演算開始が承認された場合のフローを示している。この例では、車両１２においてドアロック時にユーザＰ２３が車室内に残っている場合の動作に相当する。なお、図７ＣのステップＳ１１～Ｓ１５，Ｓ２０までの動きは、図６と同じであり、ここではステップＳ２２以降の動作について図６及び図７Ｃを用いて説明する。

図６のステップＳ２２において、車室内に残っている乗員が登録ユーザ以外の場合（Ｓ２２でＮＯ）、次のステップＳ２３において、演算装置１０２は、グリッド演算を開始することについて主ユーザＰ２１への問い合わせ依頼を管理サーバ５０に送信する。次のステップＳ２６では、主ユーザＰ２１からの使用許可が出たか否かが判定される。

より具体的には、図７ＣのステップＳ５２において、管理サーバ５０は、車両１２から上記の問い合わせ依頼を受信すると、記憶部５０３のユーザテーブルＤ５６を参照して、登録ユーザの連絡先（この例では、主ユーザＰ２１の端末装置４２）に、これから車両１２でグリッド演算を実行してよいかの確認連絡を送信する。この確認連絡をする際に、車室内に残っている乗員がユーザＰ２３であることをあわせて通知してもよい。このように、車室内に残っている乗員情報を主ユーザＰ２１に連絡することで、主ユーザＰ２１にグリッド演算の認否についての判断材料を提供することができる。

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

ステップＳ５３において、管理サーバ５０は、端末装置４２から上記の主ユーザＰ２１の応答結果を受信すると、その内容を車両１２に送信する。その後、ステップＳ５４において、管理サーバ５０の制御部５０２は、依頼対象となるアプリケーションジョブ用のジョブデータＤ１を車両１２に送信する。なお、管理サーバ５０は、図７Ｂの場合と同様に、車両１２から送信要求を受けた後に、車両１２にジョブデータＤ１を送信するようにしてもよい。その後のステップＳ３２～Ｓ３５及びステップＳ５５の処理については、図７Ｂの場合と同じである。

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

以上のように、本実施形態によると、車両１０の駐車後にドアロック状態が検知された場合に、車両１０の車室内に乗員が検知いない場合、自動的にグリッド演算を開始するようにしている。これにより、登録ユーザの手を煩わせることなく、グリッド演算を開始することができる。

また、登録ユーザが車両１０のドアロック後に車室内で過ごすような場合においても、タッチパネル１０５に問い合わせを表示し、タッチパネル１０５を介して乗員（登録ユーザ）の承認操作が受け付けられたことを条件としてグリッド演算を開始するようにしている。これにより、セキュリティを保った状態でグリッド演算を開始することができる。

さらに、本実施形態では、ドアロック後に登録ユーザ以外の乗員が車室内で過ごすような場合においても、登録ユーザの承認を条件にグリッド演算を開始するようにしているので、演算資源の客観的な品質を確保しつつ、グリッド演算の実施についての機会ロスをなるべく少なくすることができる。

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

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

１０ 車両
１０５ タッチパネル（報知部）
１１１ 乗員センサ（センサ）
１１２ 運転操作センサ（駐車検知部）
１１３ 車両状態センサ（駐車検知部、ロック検知部）

Claims (3)

1. 車両に搭載された演算資源を活用したグリッドコンピューティングの管理方法であって、
   前記車両には、乗員を認識するセンサと、当該車両の駐車状態を検知する駐車検知部と、当該車両のドアロックの状態を検知するロック検知部と、乗員向けのコンテンツを発する報知部が設けられ、
   前記車両の登録ユーザをユーザテーブルに登録する登録工程と、
   前記車両が走行状態から駐車状態となり、前記駐車検知部で当該車両の駐車が検知されかつ前記ロック検知部で当該車両のドアロック状態が検知された場合において、
   前記センサで前記車両の車室内に乗員が検知されていないとき、前記車両は、自動的に前記演算資源によるグリッドコンピューティングの演算を開始し、
   前記センサで前記車両の車室内の乗員として前記登録ユーザが検知されているとき、前記車両では、前記報知部からグリッドコンピューティングの演算開始の問い合わせを発し、その後に、当該問い合わせに対する前記登録ユーザの承認入力が受け付けられたことを条件としてグリッドコンピューティングの演算を開始する演算工程とを含む、
   グリッドコンピューティングの管理方法。
2. 前記演算工程において、前記車両が走行状態から駐車状態となり、前記駐車検知部で当該車両の駐車が検知されかつ前記ロック検知部で当該車両のドアロック状態が検知された場合において、前記センサで前記車両の車室内に乗員が検知され、かつ、当該乗員が前記登録ユーザでない場合、前記車両は、前記登録ユーザが前記グリッドコンピューティングの処理開始を承認したことを示す承認情報が外部から受信されたことを条件としてグリッドコンピューティングの演算を開始する、
   請求項１に記載のグリッドコンピューティングの管理方法。
3. 車両に搭載された演算資源を活用したグリッドコンピューティングシステムであって、
   前記車両は、
   乗員を認識するセンサと、
   前記車両の駐車状態を検知する駐車検知部と、
   前記車両のドアロックの状態を検知するロック検知部と、
   乗員向けのコンテンツを発する報知部と、
   前記車両の登録ユーザが登録されるユーザテーブルが格納される記憶部と、
   演算装置とを備え、
   前記演算装置は、
   前記車両の登録ユーザを前記ユーザテーブルに登録する登録工程と、
   前記車両が走行状態から駐車状態となり、前記駐車検知部で当該車両の駐車が検知されかつ前記ロック検知部で当該車両のドアロック状態が検知された場合において、
   前記センサで前記車両の車室内に乗員が検知されていないとき、自動的に前記演算資源によるグリッドコンピューティングの演算を開始し、
   前記センサで前記車両の車室内の乗員として前記登録ユーザが検知されているとき、前記車両では、前記報知部からグリッドコンピューティングの演算開始の問い合わせを発し、その後に、当該問い合わせに対する前記登録ユーザの承認入力が受け付けられたことを条件としてグリッドコンピューティングの演算を開始する演算工程とを実行する、
   グリッドコンピューティングシステム。

Images