特許 6207451 センサデータ収集システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6207451

(24)【登録日】2017年9月15日

(45)【発行日】2017年10月4日

(54)【発明の名称】センサデータ収集システム

(51)【国際特許分類】

   G06F 13/00 20060101AFI20170925BHJP

   G06F 9/50 20060101ALI20170925BHJP

   G06F 17/40 20060101ALI20170925BHJP

【ＦＩ】

   G06F13/00 520C

   G06F9/46 465D

   G06F17/40 330A

【請求項の数】2

【全頁数】11

(21)【出願番号】特願2014-79916(P2014-79916)

(22)【出願日】2014年4月9日

(65)【公開番号】特開2015-201060(P2015-201060A)

(43)【公開日】2015年11月12日

【審査請求日】2016年5月23日

(73)【特許権者】

【識別番号】000233055

【氏名又は名称】株式会社日立ソリューションズ

(74)【代理人】

【識別番号】110001678

【氏名又は名称】特許業務法人藤央特許事務所

(72)【発明者】

【氏名】中村 雄一

(72)【発明者】

【氏名】山崎 典之

【審査官】 寺谷 大亮

(56)【参考文献】

【文献】 特開２００７−２４３４７８（ＪＰ，Ａ）

【文献】 特開平０９−０７３３８１（ＪＰ，Ａ）

【文献】 特開２０１１−２４４４０６（ＪＰ，Ａ）

【文献】 奥野 通貴, 伊藤 大輔, 宮本 啓生, 青木 秀貴, 對馬 雄次, 矢崎 武己，次世代クラウドシステムに向けた分散情報通信処理アーキテクチャに関する検討，電子情報通信学会技術研究報告 NS2009-162〜NS2009-260，日本，社団法人電子情報通信学会，２０１０年 ２月２５日，第109巻, 第448号，pp.241-246

【文献】 鹿野 裕明, 緒方 祐次, 高田 芽衣, 中代 浩樹, 山田 雅毅, 村中 延之，センサ情報高効率集約技術の提案と評価，電子情報通信学会技術研究報告 CS2009-73〜CS2009-136，日本，社団法人電子情報通信学会，２０１０年 ２月２２日，第109巻, 第436号，pp.47-52

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ １７／４０

(57)【特許請求の範囲】

【請求項1】

センサデータの変換・加工を設定するルール定義に従いセンサから収集したデータに対し、変換・加工を実行するゲートウェイ装置と、
センサデータの変換・加工を設定するルール定義に従い前記ゲートウェイ装置から収集したデータに対し、変換・加工を実行する中間サーバと、
前記中間サーバから変換・加工されたデータを収集するデータ収集サーバと、を備え、
前記データ収集サーバは、
データの変換・加工処理のルールと当該処理を実行するデバイスとの関連付けを管理する、ルール管理情報と、
前記デバイスそれぞれの保持する計算リソースと前記デバイス間の親子関係とを管理する、デバイス管理情報と、
データの加工演算それぞれが要する計算リソースを管理する、加工演算リソース管理情報と、
前記ルール管理情報と前記加工演算リソース管理情報とに基づき、前記ゲートウェイ装置と前記中間サーバそれぞれの消費計算リソースを決定し、
前記デバイス管理情報が示す前記ゲートウェイ装置と前記中間サーバとがそれぞれ保持する計算リソースと、前記ゲートウェイ装置と前記中間サーバそれぞれの消費計算リソースと、に基づき、前記ゲートウェイ装置と前記中間サーバそれぞれの計算余力を決定し、
前記デバイス管理情報が示す前記ゲートウェイ装置と前記中間サーバの親子関係と、前記計算余力とを表示しながら、前記ゲートウェイ装置と前記中間サーバの変換・加工処理のルールの編集を行い、その編集の結果を新たなデータの変換・加工処理のルールとして前記ゲートウェイ装置と前記中間サーバとに配信する、手段と、を備えることを特徴とするセンサデータ収集システム。

【請求項2】

請求項１に記載のセンサデータ収集システムであって、
前記センサ及び前記ゲートウェイ装置は車両に取り付けられ、前記センサは前記車両のデータを取得する、センサデータ収集システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、センサ、ゲートウェイデバイス、データ収集サーバからなるセンサデータ収集システムに関するものである。

【背景技術】

【0002】

様々な産業分野において、機器の自動制御・故障予兆検知を実現するため、機器やインフラに取り付けられたセンサからデータを収集し、分析したいとするニーズが増大している。例えば、車両エンジンに取り付けられた温度センサや荷重センサからデータを収集し、車両内の部品負荷を分析することで部品の交換時期を予測するといったニーズが存在する。

【0003】

センサデータを分析し、故障予兆検知のようなデータ活用の方法を確立するためには、大量のセンサからデータを収集するM2Mサーバの負荷とデータ通信料を軽減するために、センサとM2Mサーバの中間に位置し、データのフィルタリングや加工、圧縮を行うゲートウェイ装置が必要となる。
また、データ分析の精度向上のために、収集するデータとその活用方法について仮説を立て、データを収集し、統計分析と検証を行い、検証結果に基づいて、仮説を組み直して再度データを収集するといった仮説検証のサイクルが必要であり、前記ゲートウェイ装置上のデータのフィルタリングや加工方法については、動的に更新できる必要がある。

【0004】

下記の特許文献1では、1または複数のセンサと、センサからデータを収集・変換・加工・閾値判定・連結し、任意の時機でＭ２Ｍサーバへの送信が可能なゲートウェイデバイスと、ゲートウェイデバイスからセンサデータを収集するＭ２Ｍサーバからなり、Ｍ２Ｍサーバはセンサデータの変換・加工・閾値判定・圧縮・送信時機の設定をバイナリに圧縮し、ゲートウェイに送信する手段を持ち、ゲートウェイデバイスは、バイナリに圧縮された各種設定に従い、センサから収集したデータに対し、変換・加工・閾値判定・連結を実行し、送信時機にデータ収集サーバにセンサデータを送信する手段を持つ。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特願２０１３−１５８４９５号「センサデータ収集システム」

【発明の開示】

【発明が解決しようとする課題】

【0006】

しかしながら、前記特許文献１では、ゲートウェイデバイス上の加工演算の変更をルールの配信のみで行うことができるものの、センサ数が増えたり加工演算が複雑になるなどして、ゲートウェイデバイス上での計算量が多くなると、ゲートウェイデバイスでの加工演算が間に合わなくなる問題がある。特に、ゲートウェイデバイスは、サーバとは異なりCPUやメモリ資源が限定されているため演算が間に合わなくなる可能性が高い。

【0007】

本発明は、特許文献１のようなルールに基づいてセンサデータ加工を行う処理を、複数の計算機資源に分割して行うことができるセンサデータ収集システムを提供することを第一の目的とし、さらには、複数の計算機にまたがるルール設定を支援することができるセンサデータ収集システムを提供することを第二の目的とする。

【課題を解決するための手段】

【0008】

本発明の一態様に係るセンサデータ収集システムは、センサデータの変換・加工を設定するルール定義に従いセンサから収集したデータに対し、変換・加工を実行するゲートウェイ装置と、センサデータの変換・加工を設定するルール定義に従い前記ゲートウェイ装置から収集したデータに対し、変換・加工を実行する中間サーバと、前記中間サーバから変換・加工されたデータを収集するデータ収集サーバと、を備え、前記データ収集サーバは、データの変換・加工処理のルールと当該処理を実行するデバイスとの関連付けを管理する、ルール管理情報と、前記デバイスそれぞれの保持する計算リソースと前記デバイス間の親子関係とを管理する、デバイス管理情報と、データの加工演算それぞれが要する計算リソースを管理する、加工演算リソース管理情報と、前記ルール管理情報と前記加工演算リソース管理情報とに基づき、前記ゲートウェイ装置と前記中間サーバそれぞれの消費計算リソースを決定し、前記デバイス管理情報が示す前記ゲートウェイ装置と前記中間サーバとがそれぞれ保持する計算リソースと、前記ゲートウェイ装置と前記中間サーバそれぞれの消費計算リソースと、に基づき、前記ゲートウェイ装置と前記中間サーバそれぞれの計算余力を決定し、前記デバイス管理情報が示す前記ゲートウェイ装置と前記中間サーバの親子関係と、前記計算余力とを表示しながら、前記ゲートウェイ装置と前記中間サーバの変換・加工処理のルールの編集を行い、その編集の結果を新たなデータの変換・加工処理のルールとして前記ゲートウェイ装置と前記中間サーバとに配信する、手段と、を備えることを特徴とする。

【発明の効果】

【0009】

本発明によれば、ルールに基づいた加工演算を拠点サーバ、車両という複数のデバイスで連携して処理できるようになり、また、ルールの編集も複数のデバイスをまたがって一括して行うことができる。かつ、計算力を表示することで、例えば、加工ルールを車両Aに追加し続けた結果、車両Aの残り計算力が少なくなって来たら、ルールを車両Aから削除し、削除したルールを拠点サーバAに追加することで、分散して処理させるという判断をすることができる。

【図面の簡単な説明】

【0010】

【図1】本発明に係るセンサデータ収集システムの実施の形態を示す全体構成図である。

【図2】ゲートウェイ装置のソフトウェア構成を示した図である。

【図3】拠点サーバのソフトウェア構成を示した図である。

【図4】Ｍ２Ｍサーバのソフトウェア構成を示した図である。

【図5】ゲートウェイ装置上の変換・加工ルールの構成例を示した図である。

【図6】拠点サーバ上の変換・加工ルールの構成例を示した図である。

【図7】デバイス管理テーブルの構成を示した図である。

【図8】センサデータテーブルの構成を示した図である。

【図9】ルール管理テーブルの例を示した図である。

【図10】加工演算・計算リソーステーブルの例を示した図である。

【図11】データ取得・加工・蓄積の一連の処理を示した図である。

【図12】ルール編集・配信機能を示した図である。

【発明を実施するための形態】

【0011】

以下、本発明の一実施形態を図面を参照しながら説明する。
本実施形態では建設機械など産業用車両に設置された多数のセンサからのデータ収集を、工事現場等に設定された拠点サーバと分散して実施する例を取り上げる。
図１は、システム全体の構成を示した図である。
工事現場等の拠点の内部で、車両１１０が複数台稼動している。本実施形態では、車両A、B、Cの3台が稼動しているとする。拠点の内部に拠点サーバ１３０が設置されており、WiFiネットワーク１２０にて車両１１０と接続されている。
車両１１０にはセンサ群１１１が取り付けられており、冷却水温度、エンジン回転数などのデータを取得できるようになっている。

【0012】

センサ群１１１で取得されたデータは、ＣＡＮネットワーク１１２を通して、ゲートウェイ装置１１３（ゲートウェイデバイス）で集約される。ゲートウェイ装置１１３の構成は図２で後述する。ゲートウェイ装置１１３は、集約されたデータを予め搭載された変換・加工ルールに従って変換・加工し、WiFi120を通じて拠点サーバ１３０に送信する。

【0013】

拠点サーバ１３０は、車両１１０から受け取ったデータを予め搭載された変換・加工ルールに従って変換・加工し、インターネット１４０を通して、Ｍ２Ｍサーバ１５０に送る。Ｍ２Ｍサーバ１５０は、ゲートウェイ装置１１３、拠点サーバ１３０に搭載されている変換・加工ルールを編集・配信する機能を持つと共に、ゲートウェイ装置１１３から送信されたデータを蓄積する機能を備えている。詳細な構成は図４に示す。業務システム１７０では、Ｍ２Ｍサーバ１５０に蓄積されたデータを使って例えばデータを地図と重ね合わせて可視化する等の業務支援機能を提供する。

【0014】

図２はゲートウェイ装置１１３の構成を示した図である。
ゲートウェイ装置のハードウェアとしては、ＣＰＵ、ＲＡＭ、フラッシュＲＯＭ等の永続化ストレージおよびＣＡＮネットワーク１１２やWiFi１２０と通信するためのインタフェース装置から成り立っており、さらにLinux(登録商標）などのオペレーティングシステムが搭載されており、その上に図２のようなソフトウェアおよびデータが存在している。

【0015】

データ取得手段２１０は、センサ群１１１からＣＡＮネットワーク１１２を通じてセンサデータを取得するものである。ここで、センサデータはセンサ群１１１から任意のタイミングでＣＡＮネットワーク１１２にブロードキャストされる。データフォーマットとしては、CAN IDとセンサデータのバイナリデータが連結されたものとなっている。データ取得手段２１０は、ブロードキャストされたデータを全て受信する。
変換・加工手段２２０は、データ取得手段２１１によって取得されたセンサデータをルール２５０に記載された変換・加工ルールに従ってデータを変換・加工するものである。
データアップ手段２３０は、変換・加工手段２２０によって変換・加工されたデータをWiFi１２０を通じて拠点サーバ１３０に送信するものである。
ルール取得手段２４０は、ルール２５０に格納される変換・加工ルールをＭ２Ｍサーバ１５０から取得・更新するものである。
ルール２５０は、変換・加工手段２２０で使われる変換・加工ルールであり、詳細な構成は例を使って図４で説明する。デバイス情報２６０には、デバイスを識別するデバイスＩＤおよび、デバイスのハードウェアをあらわす種別が予め格納されている。

【0016】

図３は、拠点サーバ１３０の構成を示した図である。
拠点サーバのハードウェアとしては、ＣＰＵ、ＲＡＭ、フラッシュＲＯＭ等の永続化ストレージおよびWiFi１２０やインターネット１４０と通信するためのインタフェース装置から成り立っており、さらにLinux（登録商標）などのオペレーティングシステムが搭載されており、その上に図３のようなソフトウェアおよびデータが存在している。
データ取得手段３１０は、車両１１０からWiFi 120を通じて送信されるデータを取得するものである。
変換・加工手段３２０は、データ取得手段３１０によって取得されたセンサデータをルール３５０に記載された変換・加工ルールに従ってデータを変換・加工するものである。
データアップ手段３３０では、変換・加工手段３２０によって変換・加工されたデータをインターネット１４０を通じてＭ２Ｍサーバ１５０に送信するものである。
ルール取得手段３４０は、ルール３５０に格納される変換・加工ルールをＭ２Ｍサーバ１５０から取得・更新するものである。
ルール３５０は、変換・加工手段２２０で使われる変換・加工ルールであり、詳細な構成は例を使って図６で説明する。デバイス情報３６０には、デバイスを識別するデバイスＩＤおよび、デバイスのハードウェアをあらわす種別が予め格納されている。

【0017】

図４は、Ｍ２Ｍサーバ１５０の構成を示した図である。Ｍ２Ｍサーバのハードウェアとしては、ＣＰＵ、ＲＡＭ、ＨＤＤおよび社内ネットワーク１６０、インターネット１４０と通信するためのインタフェース装置から成り立っており、さらにLinux（登録商標）などのオペレーティングシステムが搭載されており、その上に図４のようなソフトウェアおよびデータが存在している。
データ収集手段４１０は、拠点サーバ１３０から送信されるデータを受信し、センサデータテーブル４４０に保存するものである。センサデータテーブル４４０の構成は図８で説明する。デバイス管理手段４２０は、拠点サーバ１３０や車両１１０の親子関係を管理するものである。本機能で使われるデータはデバイス管理テーブル４５０にて管理されている。デバイス管理テーブルの構成は図７で説明する。
ルール編集・配信手段４３０は、ルール管理テーブル４６０で管理される変換・加工ルールを外部から社内ネットワーク１６０を通じて登録するものである。ルール管理テーブル４６０の構成は、図９で説明する。
加工演算・計算リソーステーブル４７０は、ルール編集・配信手段４３０で使われるテーブルであり、構成は図１０で説明する。

【0018】

以上、図２，３，４で示したゲートウェイ装置１１３、拠点サーバ１３０、Ｍ２Ｍサーバ１５０がどのように実際に用いられるかについては、一連の処理例を用いて図１１で説明されるものである。以降の図５から図１０ではデータ構造について説明する。

【0019】

図５は、ゲートウェイ装置１１３上の変換・加工手段２２０で用いられるルール２５０の例を示したものである。この実施例では、車両A、車両B、車両Cの全てのゲートウェイ装置において、本図と同じルールが格納されているとする。５１１〜５２５で示される表は変換ルールを表している。
５１１は、CANネットワーク１１２に流れるCAN IDを表している。５１２は対応するデータ種別、５１３はバイトオーダー、５１４，５１５はデータ位置、５１６は変換したいデータ型をあらわす。例えば、５２１は、ＣＡＮネットワークに流れるデータのCAN IDが「AAA」である場合にマッチし、０バイト目から８バイト目のデータを「エンジン冷却水温度」として識別、リトルエンディアンで配置されているデータをint16型に変換する、というルールである。
５２２の例は、ＣＡＮネットワーク１１２に流れるデータのCAN IDが「AAA」である場合にマッチし、8バイト目から16バイト目のデータを「エンジン回転数」として識別、リトルエンディアンで配置されているデータをuint16型に変換する、というルールである。

【0020】

５４１、５４４は、変換ルールに従って識別・変換されたデータを加工する加工ルールである。例えば、５４１は、変換ルールにより「エンジン冷却水温度」と識別・変換されたデータについての加工ルールが示されている。該当するデータの「６００秒」の間の「最大値」を取得し、「１バイト」のデータ長で保存し、加工データＩＤ「Ｄ０１」で識別する、という意味である。複雑な処理の例では、５４３のようにヒストグラムを取得する処理もある。５４３には、変換ルールにより「エンジン冷却水温度」として識別・変換されたデータについての加工ルールが示されている。「温度０度から２０度幅、区間数５」の「ヒストグラム」を作成し、「１５バイト」の領域に保存し、データＩＤ「D03」として識別する、という意味である。
５４４は、拠点サーバ１３０にて加工されるべきデータを表し、「エンジン回転数」として識別されたデータをそのまま拠点サーバ１３０に転送することを意味する。

【0021】

図６は、拠点サーバ１３０の中のルール３５０の例である。
図５の加工ルールと構成が異なる部分は列６１６のデバイスIDである。こちらは、対応するデバイスIDの車両から送信されてきたデータのみを加工対象とするということを意図したものである。

【0022】

図７は、デバイス管理テーブル４５０の構成を示した図である。
デバイスID７１１は、デバイス情報260およびデバイス情報３６０にて管理された情報を元にしている。親デバイス７１３は、デバイスの親子関係を管理している。図７の例の親子関係は、M2Mサーバ１５０の下に拠点サーバ１３０が接続されており、その下に車両A,B,Cが接続されているという図１で示された関係を元にしている。計算リソース７１４はCPU周波数やRAMの容量などから計算された計算力を定量化した数値である。

【0023】

図８はセンサデータテーブル４４０の構成である。拠点サーバ１３０を介してゲートウェイ装置１１３より送信されたデータが、時刻、デバイスＩＤ，加工データＩＤ、データの組で保存されている。具体的にどうデータが保存されるかは図１１の一連の処理の中で説明する。

【0024】

図９はルール管理テーブル４６０の構成である。９１１から９２２は、デバイスＩＤとそれに対応するゲートウェイデバイスもしくは拠点サーバ１３０に格納されている変換・加工ルールが格納されている。９１２には、前述の図５、図６で例示したような変換・加工ルールが例えばＸＭＬのようなテキスト表現で格納されている。

【0025】

図１０は、加工演算・ 計算リソーステーブル４７０の構成例である。図５、図６で用いられるような、加工演算がどの程度の計算リソースを要するかを、CPU時間や消費メモリ等の尺度から定量化した指標を管理している。列１０１１に加工演算種別、列１０１２に計算リソース量が示されている。

【0026】

図１１は、センサデータをゲートウェイデバイス（ゲートウェイデバイス装置）１１３および拠点サーバ１３０で収集、変換・加工し、Ｍ２Ｍサーバ１５０に蓄積されるまでの一連の処理の流れを説明した図である。
＜ステップ１１１０＞
ゲートウェイ装置１１３は、データ取得手段２１０を使って、ＣＡＮネットワーク１１２を流れるセンサ群からのデータを取得する。
＜ステップ１１２０＞
ルール２５０の変換ルールに従って取得したデータを処理する。例えば、CAN ID AAAというデータを受信したならば、行４２１・行４２２のルールにマッチした処理を行う。すなわち、受信データの0−8ビットをリトルエンディアンとしてint16型に変換し、「エンジン冷却水温度」を示す識別子とペアでRAMに保存し、さらに受信データの8−16ビットをリトルエンディアンとしてuint16型に変換し、「エンジン回転数」と示す識別子とペアでRAM上に保存する。
＜ステップ１１３０＞
ステップ１１２０で保存されたRAM上のデータに対して、ルール２５０の加工ルールに従って加工処理を行う。例えば「エンジン冷却水温度」で識別されるデータについては、行５４１、５４３に示した処理が行われる。つまり、６００秒に渡るデータの最大値を取得１バイトのデータ長で、Ｄ０１というＩＤとペアでＲＡＭ上に保存、かつヒストグラムを１００時間にわたって取得した後に、D03というIDとペアでＲＡＭ上に保存する。ここで、最大値を取るロジック、ヒストグラムを取るロジックなど加工処理に必要なロジックは予め変換・加工手段２２０に内蔵されているとする。
なお、行５４４のように、加工データIDが「スルー」となっている行にマッチするデータ種別のデータ（本実施例では、「エンジン回転数」で識別されるデータ）については、そのままステップ１１４０に渡す。
＜ステップ１１４０＞
ステップ１１３０で保存されたＲＡＭ上のデータに対し、デバイス情報２６０に格納されるデバイスIDと送信時刻を付与して拠点サーバ１３０に送信する。つまり、デバイスＩＤ、送信時刻、加工データＩＤ、加工されたデータが送信されることになる。
なお、ステップ１１３０にて、加工データIDが「スルー」になっている行にマッチするデータ種別のデータについては、デバイスID、送信時刻、データ種別を付与して拠点サーバ１３０に送信する。

【0027】

＜ステップ１１５０＞
ステップ１１４０にて送信されたデータを受信する処理である。デバイスID、送信時刻、加工データID、加工されたデータの組でステップ１１４０にて送信されたデータについては、そのままM2Mサーバ１５０に送信する。
ステップ１１４０にて、デバイスID、送信時刻、データ種別、データの組で送信されたデータについて、ステップ１１６０の処理に渡す。
＜ステップ１１６０＞
図６で例示されるルール３５０の加工ルールに従って加工処理を行う。この例では、列６１６で指定されるデバイスID毎に、「エンジン回転数」で識別されるデータについて、600秒間蓄積を続け、周波数０から１００００hz、区間幅１００ｈｚにて、高速フーリエ変換演算を行い、D04という加工データID、ステップ１１４０で送信元となったデバイスID、演算終了後の時刻とペアで、演算結果をRAM上に保存する。
＜ステップ１１７０＞
ステップ１１６０にてRAMに保存された、デバイスID、時刻、加工データID、加工後データを、M2Mサーバ１５０に送信する。
＜ステップ１１８０＞
Ｍ２Ｍサーバ１５０は、ステップ１１５０，１１７０で送信されたデータを受信し、図８で示したようなセンサデータテーブル４４０に保存する。このようにして蓄積されたセンサデータを、業務システム１７０が活用することとなる。

【0028】

図１２は、Ｍ２Ｍサーバ１５０におけるルール編集・配信手段４３０の主要機能を示した図である。図７のデバイス管理テーブル４５０で示される親子関係に基づき、ツリーを表示し、残り計算力を、加工演算計算リソーステーブル４７０に基づき表示する。この残り計算力を、ルール編集者が見ることで、デバイスの計算余力を大まかに知ることができ、編集の参考にすることができる。
残り計算力の計算方式の例を、以下記す。
１２２０の車両Aの残り計算力は、「デバイス管理テーブルの計算リソース−ルール中の計算リソースの和」で求められている。デバイス管理テーブルの計算リソースは、図７によると５００である。ルール中の計算力の和は、行５４１、５４２、５４３の計算リソースは図９を参照すると、それぞれ５０，１００、２００であるため、和は３５０であり、１２２０に記される計算力は「５００−３５０」で「１５０」と記される。１２１０の拠点サーバAの残り計算力は、「デバイス管理テーブルの計算リソース−ルール中の計算力の和」となる。これも同様に、「５０００−１５００＝３５００」となる。１２１０，１２２０，１２３０，１２４０を選択すると、図5、図６のような表に対して、追加削除操作を行うことができる。編集結果は図９のルール管理テーブルにテキスト表現として保存され、また編集後は図９のルール管理テーブルに保存されたデータが対応するデバイスIDのデバイスに配信され、対応するルール２５０、ルール３５０に保存される。

【0029】

以上のように上記した実施形態によれば、ルールに基づいた加工演算を拠点サーバ、車両という複数のデバイスで分割連携して処理できるようになり、また、ルールの編集や設定も複数のデバイスをまたがって一括して行うことができる。かつ、図１２のように計算力を表示することで、例えば、加工ルールを車両Aに追加し続けた結果、車両Aの残り計算力が少なくなって来たら、ルールを車両Aから削除し、削除したルールを拠点サーバAに追加することで、分散して処理させるという判断をすることができる。

【符号の説明】

【0030】

１１０ 車両
１１１ センサ群
１１２ ＣＡＮネットワーク
１１３ ゲートウェイ装置（ゲートウェイデバイス）
１２０ ＷｉＦｉ
１３０ 拠点サーバ
１４０ インターネット
１５０ Ｍ２Ｍサーバ
１６０ 社内ネットワーク
１７０ 業務システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】