(57)【要約】      （修正有）【課題】ゲートウェイ装置においてセンサデータをルールに従って変換・加工するシステムにおいて、新たな演算処理を追加する手段を提供し、また、データを複数の関係者でシェアする際のルール変更の影響を最小化する。【解決手段】ルール中の加工演算識別子と対応する演算処理を行うロジックを含むプラグインファイルを関連付けるテーブルをゲートウェイ装置１１３に設け、プラグインファイルを外部のルール配信サーバからゲートウェイ装置１１３に配信する手段を設ける。また、ルールをゲートウェイ装置１１３に配信するルール配信サーバにおいてルールを管理し、ルールの中にアクセス権限を示す識別子を記述できるようにし、ルール配信サーバ中のルールを更新する際、更新者の識別子とルール中のアクセス権限を示す識別子を照らし合わせてアクセス制御する仕組みを設ける。【選択図】図１
2015026299.tif 000002
【特許請求の範囲】
【請求項１】
センサデータの変換・加工を設定するルール定義に従い、センサから収集したデータに対し、変換・加工を実行し、センタサーバに送信するゲートウェイ装置を備えたセンサデータ収集システムにおいて、
加工演算と対応する演算処理を行うロジックを含むプラグインファイルを関連付けるテーブルをゲートウェイ装置に設け、前記ルールおよびプラグインファイルを前記ルール配信サーバからゲートウェイ装置に配信するように構成したことを特徴とするセンサデータ収集システム。
【請求項２】
前記ルール配信サーバにて前記ルールを管理し、当該ルールの中にアクセス権限を示す識別子を記述できるようにし、前記ルール配信サーバ中のルールを更新する際、更新者の識別子とルール中のアクセス権限を示す識別子を照らし合わせてアクセス制御する手段を前記ルール配信サーバ内に備えることを特徴とする請求項１に記載のセンサデータ収集システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、センサ、ゲートウェイ装置、データ収集サーバからなるセンサデータ収集システムに関するものである。
【背景技術】
【０００２】
近年、様々な産業分野において、機器の自動制御・故障予兆検知を実現するため、機器やインフラに多数のセンサを取り付け、これらのセンサから自動制御、故障予兆検知のためのデータを収集し、分析したいとするニーズが増大している。
例えば、車両エンジンに取り付けられた温度センサや荷重センサからデータを収集し、車両内の部品負荷を分析することで部品の交換時期を予測するといったニーズが存在する。
【０００３】
センサデータを分析し、故障予兆検知のようなデータ活用の方法を確立するためには、大量のセンサからデータを収集するＭ２Ｍサーバの負荷とデータ通信料を軽減するために、センサとＭ２Ｍサーバの中間に位置し、データのフィルタリングや加工、圧縮を行うゲートウェイ装置が必要となる。
また、データ分析の精度向上のために、収集するデータとその活用方法について仮説を立て、データを収集し、統計分析と検証を行い、検証結果に基づいて、仮説を組み直して再度データを収集するといった仮説検証のサイクルが必要であり、ゲートウェイ装置情のデータのフィルタリングや加工方法については、動的に更新できる必要がある。
【０００４】
下記の非特許文献１で公開されているOSGiフレームワークでは、Java言語にて任意のフィルタリング・加工方法をコーディングし、コードをOSGiバンドルにコンパイルし、ゲートウェイ装置にOSGiバンドルをインストールすることで動的にフィルタリング・加工方法を変えることができる。
特許文献１では、１または複数のセンサと、センサからデータを収集・変換・加工・閾値判定・連結し、任意の時機でＭ２Ｍサーバへの送信が可能なゲートウェイ装置と、ゲートウェイ装置からセンサデータを収集するＭ２Ｍサーバからなり、Ｍ２Ｍサーバはセンサデータの変換・加工・閾値判定・圧縮・送信時機の設定をバイナリに圧縮し、ゲートウェイに送信する手段を持ち、ゲートウェイ装置は、バイナリに圧縮された各種設定に従い、センサから収集したデータに対し、変換・加工・閾値判定・連結を実行し、送信時機にデータ収集サーバにセンサデータを送信する手段を持つ。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】OSGi Service Platform Release4、URL：http://www.osgi.org/Release4/HomePage
【特許文献】
【０００６】
【特許文献１】特開２０１２−１６４３６９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
非特許文献１では、任意の加工ルールをOSGiバンドルとして記述することができるものの、Java言語によるプログラミング作業が必要であり、開発工数がかかってしまう。特許文献１においては、単純な加工ルールを記述するだけでよく、Java(登録商標）言語によるプログラミングは不要なものの、例えば平均値や最大値を取る等、予め定義された加工演算しか使うことができない。
さらに、特許文献１においては、ルールは誰でも記述・配信可能であるため、収集したデータを複数の関係者で活用する際に問題が生じうる。例えば、収集データを用いたデータ可視化業務を行う部署と、データを統計分析するデータサイエンティストが存在するとする。この際、データサイエンティストの都合でルールを変更すると、収集されるデータが変更になるためデータの可視化業務に影響がでる恐れがある。
【０００８】
本発明は、プログラミングを最小限にしつつ新たな演算処理を追加する手段を提供することを第一の目的とし、第二の目的はデータを複数の関係者でシェアする際のルール変更の影響を最小化することである。
【課題を解決するための手段】
【０００９】
上記第一の目的を達成するために、センサデータの変換・加工を設定するルール定義に従い、センサから収集したデータに対し、変換・加工を実行し、センタサーバに送信するゲートウェイ装置を備えたセンサデータ収集システムにおいて、
加工演算と対応する演算処理を行うロジックを含むプラグインファイルを関連付けるテーブルをゲートウェイ装置に設け、前記ルールおよびプラグインファイルを前記ルール配信サーバからゲートウェイ装置に配信するように構成したことを特徴とする。
また第二の目的を達成するために、前記ルール配信サーバにて前記ルールを管理し、当該ルールの中にアクセス権限を示す識別子を記述できるようにし、前記ルール配信サーバ中のルールを更新する際、更新者の識別子とルール中のアクセス権限を示す識別子を照らし合わせてアクセス制御する手段を前記ルール配信サーバ内に備えることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、例えば新たに「フーリエ変換」の加工演算が必要になった場合は、「フーリエ変換」の加工演算を容易に追加することができる。
また、ルール中のアクセス権限を示す識別子を照らし合わせてアクセス制御する手段によってデータ分析者がＭ２Ｍ管理者に無断でルールを変更されることを防ぐことができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態を示すシステム構成図である。
【図２】ゲートウェイ装置のソフトウェア構成を示した図である。
【図３】Ｍ２Ｍサーバのソフトウェア構成を示した図である。
【図４】変換・加工ルールの構成例を示した図である。
【図５】演算プラグインの構成を示した図である。
【図６】センサデータテーブルの構成を示した図である。
【図７】ルール管理テーブルの例を示した図である。
【図８】ルール管理テーブル中のルールの例を示した図である。
【図９】データ取得・加工・蓄積の一連の処理を示した図である。
【図１０】変換・加工ルール更新の一連の処理を示した図である。
【発明を実施するための形態】
【００１２】
以下、本発明の一実施形態を図面を参照しながら説明する。
本実施形態では車両に設置されたセンサからのデータ収集を例として取り上げる。
図１は、システム全体の構成を示した図である。
車両１１０にはセンサ群１１１が取り付けられており、冷却水温度、エンジン回転数などのデータを取得できるようになっている。センサ群１１１で取得されたデータは、ＣＡＮネットワーク１１２を通して、ゲートウェイ装置１１３で集約される。ゲートウェイ装置１１３の構成は図２で後述する。ゲートウェイ装置１１３は、集約されたデータを予め搭載された変換・加工ルールに従って変換・加工し、インターネット１２０を通して、Ｍ２Ｍサーバ１３０に送る。
【００１３】
Ｍ２Ｍサーバ１３０は、ゲートウェイ装置１１３に搭載されている変換・加工ルールを配信する機能を持つと共に、ゲートウェイ装置１１３から送信されたデータを蓄積する機能を備えている。詳細な構成は図３に示す。
業務システム１５０では、Ｍ２Ｍサーバ１３０に蓄積されたデータを使って例えばデータを地図と重ね合わせて可視化する等の業務支援機能を提供する。
データ分析者１６０は、Ｍ２Ｍサーバ１３０に蓄積されたデータのマイニングを行う。データ分析者１６０は業務システム１５０とは違う組織に所属すると想定する。Ｍ２Ｍ管理者１７０は、業務システム１５０の管理者である。
【００１４】
図２はゲートウェイ装置１１３の構成を示した図である。
ゲートウェイ装置１１３のハードウェアとしては、ＣＰＵ・ＲＡＭ・フラッシュＲＯＭ等の永続化ストレージおよびＣＡＮネットワーク１１２やインターネット１２０と通信するためのインタフェース装置から成り立っており、さらにLinux（登録商標）などのオペレーティングシステムが搭載されており、その上に図２のようなソフトウェアおよびデータが存在している。
データ取得機能２１０は、センサ群１１１からＣＡＮネットワーク１１２を通じてセンサデータを取得する機能である。ここで、センサデータはセンサ群１１１から任意のタイミングでＣＡＮネットワーク１１２をブロードキャストされる。データフォーマットとしては、CAN IDとセンサデータのバイナリデータが連結されたものとなっている。
【００１５】
データ取得機能２１０はブロードキャストされたデータを全て受信する。
変換・加工機能２２０は、データ取得機能２１０によって取得されたセンサデータをルール２５０に記載された変換・加工ルールに従ってデータを変換・加工する機能である。
データアップ機能２３０では、変換・加工機能２２０によって変換・加工されたデータをインターネット１２０を通じてＭ２Ｍサーバ１３０に送信する機能である。
ルール取得機能２４０は、ルール２５０に格納される変換・加工ルールをＭ２Ｍサーバ１３０から取得・更新する機能である。ルール２５０は、変換・加工機能２２０で使われる変換・加工ルールであり、詳細な構成は例を使って図４で説明する。
【００１６】
演算プラグイン２６０は、変換・加工機能２２０で用いる演算プラグインが格納されている。詳細は図５で説明する。
デバイス情報２７０には、デバイスを識別するデバイスＩＤおよび、デバイスのハードウェアを表す種別が予め格納されている。
【００１７】
図３は、Ｍ２Ｍサーバ１３０の構成を示した図である。
Ｍ２Ｍサーバのハードウェアとしては、ＣＰＵ・ＲＡＭ・ＨＤＤおよび社内ネットワーク１４０・インターネット１２０と通信するためのインタフェース装置から成り立っており、さらにLinux（登録商標）などのオペレーティングシステムが搭載されており、その上に図３のようなソフトウェアおよびデータが存在している。
【００１８】
データ収集機能３１０は、ゲートウェイ装置１１３から送信されるデータを受信し、センサデータテーブル３２０に保存する機能である。センサテーブル３２０の構成は図５で説明する。
ルール登録機能３３０は、ルール管理テーブル３４０で管理される変換・加工ルールを外部から社内ネットワーク１４０を通じて登録する機能である。
ルール管理テーブル３４０の構成は、図７，８で説明する。
【００１９】
ルールアクセス制御機能３５０は、ルール登録機能３３０の中で用いられる機能である。どう用いられるかは図１０で後述する。
ルール配信機能３６０は、ルール管理テーブル３４０で管理される変換・加工ルールをゲートウェイ装置１１３に配信するための機能である。
【００２０】
以上図２，３で示したゲートウェイ装置１１３およびＭ２Ｍサーバ１３０がどのように実際に用いられるかについては、一連の処理例を用いて図９、１０で説明されるものである。以降の図４から図８ではデータ構造について説明する。
【００２１】
図４は、変換・加工機能２２０で用いられるルール２５０の例を示したものである。４１１〜４２５で示される表は変換ルールを表している。
４１１は、CANネットワークに流れるCAN IDを表している。
４１２は対応するデータ種別、４１３はバイトオーダー、４１４，４１５はデータ位置、４１６は変換したいデータ型を表す。例えば、４２１は、ＣＡＮネットワーク１１２に流れるデータのCAN IDが「AAA」である場合にマッチし、０バイト目から８バイト目のデータを「エンジン冷却水温度」として識別、リトルエンディアンで配置されているデータをint 16型に変換する、というルールである。４２２の例では、ＣＡＮネットワーク１１２に流れるデータのCAN IDが「AAA」である場合にマッチし、8バイト目から16バイト目のデータを「エンジン回転数」として識別、リトルエンディアンで配置されているデータをuint 16型に変換する、というルールである。
４３１〜４４４は、変換ルールに従って識別・変換されたデータを加工する加工ルールである。
【００２２】
例えば、４４１は、変換ルールにより「エンジン冷却水温度」と識別・変換されたデータについての加工ルールが示されている。該当するデータの「６００秒」の間の「最大値」を取得し、「１バイト」のデータ長で保存、加工データＩＤ「Ｄ０１」で識別する、という意味である。
複雑な処理の例では、４４３のようにヒストグラムを取得する処理もある。
４４３には、変換ルールにより「エンジン冷却水温度」として識別・変換されたデータについての加工ルールが示されている。「温度０度から２０度幅、区間数５」の「ヒストグラム」を作成し、「１５バイト」の領域に保存し、データＩＤ「D03」として識別する、という意味である。
【００２３】
図５は演算プラグイン２６０の構成である。
図４の加工方法４３４に、加工演算の方法が書いてあるが、加工演算するためのロジックがどこにあるのかが５１２に示されている。例えば、５２１の行で、加工方法「最大値」については、演算プラグイン「内蔵」であり、変換・加工機能２２０に予めリンクされていることを意味する。また、５２３の行では、加工方法が「ヒストグラム」であり、演算プラグイン「histgram.so」であり、こちらはファイル名「histgram.so」というダイナミックリンクライブラリにヒストグラムの処理をするロジックが格納されていることを意味する。
【００２４】
図６はセンサデータテーブル３２０の構成である。
ゲートウェイ装置１１３より送信されたデータが、時刻、デバイスＩＤ，加工データＩＤ、データの組で保存されている。具体的にどうデータが保存されるかは図９の一連の処理の中で説明する。
【００２５】
図７はルール管理テーブル３４０の構成である。
７１１から７２２は、デバイスＩＤとそれに対応するゲートウェイ装置に格納されている変換・加工ルール、およびデバイス種別が格納されている。
７１２には、次の図８で例示するような変換・加工ルールが例えばＸＭＬのようなテキスト表現で格納されている。
７３１から７４４には、デバイス種別と加工方法に対応した演算プラグインのファイルシステム上でのパスが格納されている。演算プラグインの実体はＭ２Ｍサーバのファイルシステム上のパスで示される場所に格納されている。例えば、行７４１は、ARMアーキテクチャのゲートウェイ装置向けのヒストグラム演算処理を行うためのロジックが格納された演算プラグインのパスが格納されている。同様に、行７４２は、x86アーキテクチャのゲートウェイ装置向けのヒストグラム演算処理を行うためのロジックが格納された演算プラグインのパスが格納されている。
【００２６】
図８は、ルール管理テーブル３４０の７１２にて格納されている変換・加工ルールの論理構成をテーブルで表したものである。実際には、テーブルをＸＭＬで表現したテキスト表現で格納されている。
図４で示したゲートウェイ装置上に存在するルールとの違いは、８１７，８３６のように、その行にアクセスできる者を表すラベル情報が付与されていることである。このラベル情報は、予めＭ２Ｍ管理者７２０によって付与されているとする。このラベルによれば、例えば行８４１のルールについては、Ｍ２Ｍ管理者７２０しか変更が許されない。行８４３のルールについては、分析者１６０しか変更が許されない。
【００２７】
図９は、センサデータをゲートウェイ装置で収集、変換・加工し、Ｍ２Ｍサーバに蓄積されるまでの一連の処理の流れを説明した図である。
＜ステップ９１０＞
ゲートウェイ装置１１３は、データ取得機能２１０を使って、ＣＡＮネットワークを流れるセンサ群からデータを取得する。
＜ステップ９２０＞
ルール２６０の変換ルールに従って取得したデータを処理する。例えば、CAN ID AAAというデータを受信したならば、行４２１・行４２２のルールにマッチした処理を行う。つまり、受信データの0-8ビットをリトルエンディアンとしてint 16型に変換し、「エンジン冷却水温度」を示す識別子とペアでRAMに保存、さらに受信データの8-16ビットをリトルエンディアンとしてuint 16型に変換し、「エンジン回転数」と示す識別子とペアでRAM上に保存する。
【００２８】
＜ステップ９３０＞
ステップ９２０で保存されたRAM上のデータに対して、ルール２６０の加工ルールに従って加工処理を行う。例えば「エンジン冷却水温度」で識別されるデータについては、行４４１、４４３に示した処理が行われる。つまり、６００秒に渡るデータの最大値を取得１バイトのデータ長で、Ｄ０１というＩＤとペアでＲＡＭ上に保存、かつヒストグラムを１００時間にわたって取得した後に、D03というIDとペアでＲＡＭ上に保存する。ここで、最大値を取るロジック、ヒストグラムを取るロジックは、図５で示した演算プラグインで示されるプログラムにおいて実行される。今回の例では、最大値については、変換・加工機能に内蔵されたロジックで実行され、ヒストグラムについては、histgram.soというファイルからプログラムをロードして実行される。
【００２９】
＜ステップ９４０＞
ステップ９３０で保存されたＲＡＭ上のデータに対し、デバイス情報２７０に格納されるデバイスIDと送信時刻を付与してＭ２Ｍサーバ１３０に送信する。つまり、デバイスＩＤ・送信時刻・加工データＩＤ・加工されたデータが送信されることになる。
＜ステップ９５０＞
Ｍ２Ｍサーバ１３０は、ステップ９４０で送信されたデータを受信し、図６で示したようなセンサデータテーブル３２０に保存する。このようにして蓄積されたセンサデータを、業務システム１５０やデータ分析者１６０が活用することとなる。
【００３０】
図１０は、ゲートウェイ装置１１３内の変換・加工ルール２５０を更新する際の処理の流れを示したものである。まずは、既存のルールの引数を変更する場合について説明し、次に新たな演算プラグイン追加が必要な場合について説明する。
既存のルールの引数を変更する場合について説明する。今回の例では、Ｍ２Ｍ管理者１７０がデバイスID 1のゲートウェイ装置に対して、加工ルールの行４４１の引数「６００秒」を「１２００秒」に変更する場合を例として説明する。
＜ステップ１０１０＞
Ｍ２Ｍ管理者１７０は、変換・加工ルールを編集する。今回は、加工ルールの行４４１の引数を「６００秒」を「１２００秒」とする。
【００３１】
＜ステップ１０２０＞
Ｍ２Ｍ管理者１７０は、デバイスID「1」を指定し、Ｍ２Ｍサーバ１３０にルール登録機能３３０を使って編集したルールをルール管理テーブル３４０へ登録リクエストを送る。ルール登録機能３３０は、ルール管理テーブル３４０を更新する前に、ルールアクセス制御機能３４０を用いて次の処理を行う。
＜ステップ１０３０＞
ルールアクセス制御機能３４０は、現在のルール管理テーブル３４０の対応するデバイスID(今回は1)の変換・加工ルール（図８のようなテーブルとする）と、登録されたテーブルを比較する。更新されている部分のアクセス権限をラベル８１７，８３６を使ってチェックする。今回の例では、行８４１が更新されることとなり、ラベル８３６を見ると「管理者」のみが更新可能となっている。今回は、Ｍ２Ｍ管理者からのアクセスなのでアクセスは許可され、行８４１が更新される。
引数が(６００秒から１２００秒となる)。なお、アクセスが拒否される場合は、ルール管理テーブル３４０を更新せず処理を終了する。
【００３２】
＜ステップ１０４０＞
更新されたルール管理テーブル３４０の変換・加工ルールをゲートウェイ装置１１３に配信する。
＜ステップ１０５０＞
ゲートウェイ装置１１３は、受信した変換・加工ルールをルール２５０に保存する。
＜ステップ１０６０＞
更新後、ルール２５０、演算プラグイン２６０を比較し、不要な演算プラグインを削除する。つまり、演算プラグイン２６０の加工方法５１１のうち、加工ルールの加工方法４３４に現れていない演算プラグイン５１２を削除する。例えば、５１１の「ヒストグラム」が、４３４に現れていない場合は対応する演算プラグイン５１２であるhistgram.soを削除する。こうすることで、ゲートウェイ装置１１３のリソースが限られている場合、ルール更新後に無駄なプラグインが残留することを防ぐことができる。
【００３３】
次に演算プラグイン追加をする更新例として、デバイスIDが１の車両に対して、１０７０のような加工ルールを追加したい場合を例として説明する。
＜ステップ１０１０＞
データ分析者１６０は、デバイスID 1のゲートウェイ装置で取得されるエンジン回転数に関して、１０７０のようなルールを追加して、周波数分解を利用した分析を新たに行いたくなったとする。しかし、ゲートウェイ装置には周波数分解を行うのに必要なフーリエ変換処理が入っていないため、データ分析者１６０は必要なデータを得ることができない。そこで、データ分析者はフーリエ変換処理をするために必要な演算プラグインをプログラミングし用意する。今回は、ARM GW用、x86 GW用それぞれにコンパイルして用意する。
【００３４】
＜ステップ１０２０＞
データ分析者１７０は、１０７０が追加された変換・加工ルール（図４の行４４４の下に１０７０が追加されたルール）と、フーリエ変換演算プラグイン（ARM GW用ファイルとx86 GW用ファイル）それぞれについて、登録リクエストを送る。ルール登録機能３３０は、ルール管理テーブル３４０を更新する前に、ルールアクセス制御機能３４０を用いて次の処理を行う。
＜ステップ１０３０＞
ルールアクセス制御機能３４０は、現在のルール管理テーブル３４０の対応するデバイスID(今回は1)の変換・加工ルール（図８のようなテーブルとする）と、登録されたテーブルを比較する。更新されている部分のアクセス権限をラベル８１７，８３６を使ってチェックする。今回は、１０７０の追加なので該当するラベルは存在しないため処理を継続する。結果、図８のテーブルには１０７０が追加され、またルール管理テーブルの加工方法・プラグインパスが記された７３１−７４２には、１０８０のような２行が追加される。ここで、/plugins/arm/fft.so は、ARM GW用の演算プラグインファイル、/plugins/x86/fft.soはX86 GW用の演算プラグインファイルである。
【００３５】
＜ステップ１０４０＞
ステップ１０３０で更新された変換・加工ルールと追加された変換・加工ルールに対応する演算プラグインファイルをデバイスＩＤ 1のゲートウェイ装置に配信する。なお、今回の例で配信される演算プラグインであるが、図７によるとデバイスＩＤ  １のデバイス種別はARM Linux（登録商標） GWのため、ARM Linux（登録商標） GWに対応した加工方法「フーリエ変換」のプラグインである「/plugins/arm/fft.so」が配信される。
＜ステップ１０５０＞
ゲートウェイ装置１１３は、受信した変換・加工ルール、演算プラグインをルール２５０、演算プラグイン２６０にそれぞれ保存する。
＜ステップ１０６０＞
今回の例では何も行わない。
【符号の説明】
【００３６】
１１０    車両
１１１    センサ群
１１２    ＣＡＮネットワーク
１１３    ゲートウェイ装置
１２０    インタネット
１３０    Ｍ２Ｍサーバ
１４０    社内ネットワーク
１５０    業務システム
１６０    データ分析者
１７０    Ｍ２Ｍ管理者
２５０    ルール
２６０    演算プラグイン
２７０    デバイス情報
３２０    センサデータテーブル
３３０    ルール登録機能
３４０    ルール管理テーブル
３５０    ルールアクセス制御機能
３６０    ルール配信機能
【図１】
2015026299.tif 000003
【図２】
2015026299.tif 000004
【図３】
2015026299.tif 000005
【図４】
2015026299.tif 000006
【図５】
2015026299.tif 000007
【図６】
2015026299.tif 000008
【図７】
2015026299.tif 000009
【図８】
2015026299.tif 000010
【図９】
2015026299.tif 000011
【図１０】
2015026299.tif 000012