JP5737696B2 - センサデータ収集システム - Google Patents

Description

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

近年、様々な産業分野において、機器の自動制御・故障予兆検知を実現するため、機器やインフラに取り付けられたセンサからデータを収集・分析したいとするニーズが増大している。
例えば、車両エンジンに取り付けられた温度センサや荷重センサからデータを収集し、車両内の部品負荷を分析することで部品の交換時期を予測するといったニーズが存在する。
センサデータを分析し、故障予兆検知のようなデータ活用の方法を確立するためには、大量のセンサからデータを収集するサーバの負荷とデータ通信料を軽減するために、センサとサーバの中間の位置し、データのフィルタリングや加工、圧縮を行うゲートウェイ装置が必要となる。

また、データ分析の精度向上のために、収集するデータとその活用方法について仮説を立て、データを収集し、統計分析と検証を行い、検証結果に基づいて、仮説を組み直して再度データを収集するといった仮説検証のサイクルが必要であり、ゲートウェイ装置上のデータのフィルタリングや加工方法については、動的に更新できる必要がある。

下記の特許文献１には、多種多様な形式で送信されるセンサデータを、サーバから配信された変換ルールに基づき、ゲートウェイ上で統一されたフォーマットに変換することにより、センサデータを活用するアプリケーションの新規追加や拡張コストを抑制する方式が開示されている。
また、下記の特許文献２には、車両内のセンサから収集した交通情報を、車車間通信によって、複数車両間で集計し、サーバに送信することにより、サーバ負荷と通信量の軽減する方式が開示されている。

特開２０１２−１６４３６９号公報 特開２００７−３１０７３３号公報

しかしながら、センサデータの効率的な収集を実現するためには、ゲートウェイの機能は、特許文献１記載のような収集したセンサデータの変換・加工だけでは不十分であり、異常値を検出した場合に即時にサーバにアラートを送信する異常検知機能、複数センサデータを圧縮することによる通信量削減機能、定時や位置等の送信時機を定義する機能が必要である。
異常検知機能が無ければ、緊急性の高いセンサデータをリアルタイムに収集することはできない。
また、データを圧縮する機能が無ければ、通信量の削減効果は弱く、さらに、送信時機を定義できなければ、大量にあるゲートウェイからサーバへの通信負荷を分散できない。よって、ゲートウェイはセンサデータの変換・加工・異常値検知・圧縮・送信時機を併せて設定可能でなければならない。
さらに、ゲートウェイは省リソースなデバイスである場合もあり、設定するルールが多くなれば、設定情報がメモリやストレージ容量を超過してしまうことも考えられる。

また、特許文献２に記載の方式では、各車両が共通のプロトコルで車車間通信が可能な車載通信デバイスを搭載している必要があり、利用シーンの限定される方式になっている。

本発明の目的は、データ収集サーバの負荷と通信量の軽減と、通信量を削減しながらも緊急性の高いデータに関してはリアルタイムにデータを収集可能とし、さらに緊急性の高いデータの収集のリアルタイム性確保のためにセンサデータの変換・加工・閾値判定・圧縮・送信時機の方法を記載するルール定義については、データ収集サーバから動的に更新可能とし、各ルール定義は、ゲートウェイデバイスが省リソースなデバイスであっても実行可能とするセンサデータ収集システムを提供することである。

上記目的を達成するために、本発明は、１ないし複数のセンサと、これらのセンサからデータを収集・変換・加工・閾値判定・圧縮し、任意の設定時機にデータ収集サーバへの送信が可能なゲートウェイデバイスと、ゲートウェイデバイスからセンサデータを収集するデータ収集サーバから構成され、当該データ収集サーバはセンサデータの変換・加工・閾値判定・圧縮・送信時機の設定をバイナリに圧縮し、ゲートウェイデバイスに送信する手段を備え、前記ゲートウェイデバイスは、バイナリに圧縮されたセンサデータの変換・加工・閾値判定・圧縮・送信時機の設定に従い、前記センサから収集したデータに対し、変換・加工・閾値判定・圧縮を実行し、設定された送信時機にデータ収集サーバにセンサデータを送信する手段を備えることを特徴とする。

本発明によれば、センサデータの変換・加工・閾値判定・圧縮・送信時機のルール定義を省リソースなゲートウェイデバイスにも広域ネットワークを介して設定可能となり、センサデータを収集するデータ収集サーバの負荷と通信量を軽減しつつ、緊急性の高いデータのリアルタイムな収集を実現できる。

本発明の実施形態におけるルール定義更新型のセンサデータ収集システムの構成図である 変換ルール定義の一例を示す図である。 加工ルール定義の一例を示す図である。 加工前閾値ルール定義の一例を示す図である。 加工後閾値ルール定義の一例を示す図である。 送信時機定義の一例を示す図である。 送信内容定義の一例を示す図である。 バイナリ定義テーブル群の構成を説明する図である。 変換ルールバイナリ構成テーブルの一例を示す図である。 データ種別ビット列テーブルの一例を示す図である。 バイトオーダービット列テーブルの一例を示す図である。 データ型ビット列テーブルの一例を示す図である。 変換方法ビット列テーブルの一例を示す図である。 最新値キャッシュの一例を示す図である。 加工データキャッシュの一例を示す図である。 データ格納部の一例を示す図である。 ルール定義の生成・配信処理を示すシーケンス図である。 ルールバイナリ生成処理を示すフローチャートである。 変換ルールバイナリの一例を示す図である。 センサデータの加工・送信処理を示すシーケンスである。 データ変換処理を示すフローチャートである。 データ加工処理を示すフローチャートである。 加工前閾値判定処理を示すフローチャートである。 加工後閾値判定処理を示すフローチャートである。 データ送信処理を示すフローチャートである。 送信データの一例を示す図である。 データ受信処理を示すフローチャートである。 加工ルール更新時のセンサデータ加工・送信処理を示すフローチャートである。

以下、図面を参照して本発明の実施形態について説明する。
図１は、本発明に係るセンサデータ収集システムの実施形態を示すシステム構成図である。
本実施形態のセンサデータ収集システムは、大別すると、データ収集サーバ１０１とゲートウェイデバイス１２１と複数のセンサ１４１からなる。
収集サーバ１０１とゲートウェイデバイス１２１はインターネット等の広域ネットワーク１５１で接続され、ゲートウェイデバイス１２１とセンサ１４１はＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＺｉｇｂｅｅ（Ｚｉｇｂｅｅ Ａｌｌｉａｎｃｅの登録商標）、Ｗｉ−Ｆｉ（Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅの登録商標）のようなローカルネットワークで接続される。
例えば、車載センサの場合は、ゲートウェイデバイス１２１とセンサ１４１はＣＡＮによって接続され、ゲートウェイデバイス１２１からエンジン負荷やブレーキ状態のようなデータをデータ収集サーバ１０１に収集することによって、車の故障予兆診断などが可能になる。

データ収集サーバ１０１はセンサデータを収集・管理するサーバであり、ルール定義生成部１０９とルールバイナリ生成部１１０とルール定義配信部１１２とルール定義格納部１０８とバイナリ定義テーブル群１１１とデータ受信部１１３とデータ格納部１１４からなる。
ルール定義生成部１０９はデータ収集サーバ１０１の管理者によるＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を介した入力を受け、ゲートウェイデバイス１２１のセンサデータの変換方法、加工方法、加工済データの送信方法と送信時機、即時のデータ送信可否を判断するための閾値を変換ルール定義１０２、加工ルール定義１０３、送信内容ルール定義１０７、送信時機ルール定義１０６、加工前閾値ルール定義１０４、加工後閾値ルール定義１０５として、ルール定義格納部１０８に格納する。

加工前閾値ルール定義１０４と加工後閾値ルール定義１０５をそれぞれ用意しているのは、収集したデータに対する閾値判定とヒストグラム生成等の統計処理を行った後のデータに対する閾値判定を共に行うためである。例えば、エンジン冷却水温度では、９０℃以上であれば即座に異常値と判定する場合と、１日間収集したデータの中で７０℃以上の値を検知した回数が一定数以上であれば異常値と判定する場合がありうる。なお、サーバ側ルール定義格納部１０８には、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）やテーブルのようなフォーマットにて、各種ルール定義が格納されている。
ルールバイナリ生成部１１０は、省リソースのゲートウェイデバイス１２１でもルール定義の格納可能とするために、サーバ側ルール定義格納部１０８から各種ルール定義を読み込み、バイナリ定義テーブル群１１１で設定されているバイナリ変換ルールに従い、ルール定義をルールバイナリに変換する。

ルール定義配信部１１２は、ルールバイナリ生成部１１０から受け取ったルールバイナリをゲートウェイデバイス１２１に配信する。
データ受信部１１３は、ゲートウェイデバイス１２１から受信したデータを、送信内容ルール定義１０７に従い、分解して、データ格納部１１４に格納する。

変換ルール定義１０２の一例を図２に示す。ＣＡＮ ＩＤ２０１（Ｉｄｅｎｔｉｆｉｅｒ）はＣＡＮ内に流れるセンサデータを一意に表すためのＩＤ（識別情報）である。ＣＡＮ以外のネットワークの場合も、同様にセンサデータを一意に表すＩＤが入る。例えば、Ｚｉｇｂｅｅの場合では、センサに付与されているＩＤが入る。データ種別２０２は、エンジン冷却水温度やエンジン回転数等のセンサデータのセマンティクスを表す。ここで例示するＣＡＮ ＩＤ２０１「ＡＡＡ」には、エンジン冷却水温度とエンジン回転数の二つのデータが紐付いているが、これは、ＣＡＮでは、単一のＣＡＮ ＩＤ２０１を付与されている１パケットデータに複数データが含まれる場合があるためである。その他、センサデータのバイトオーダービット列１１０１、受信したパケット内の、目的とするデータの開始位置２０４とデータ長２０５、ゲートウェイデバイス１２１上のプログラミング言語におけるデータ型２０６、変換回数２０７、変換方法２０８、変換処理の引数２０９が格納される。ＣＡＮのようなセンサネットワークでは、データサイズ削減のため、送信するデータの値を除算してから送信する場合や、異なる単位系であらわされた値を送信する場合もありうる。

図２の場合であれば、エンジン冷却水温度を、絶対温度で表現し、かつ、桁数削減のため「５」で除算してから送信しているため、「５」を乗算し、「２７３」を減算する必要がある。
加工ルール定義１０３の一例を図３に示す。加工ルール定義１０３には、データ種別２０２、加工済データを一意に識別するための加工データＩＤ３０１、加工データのデータ長３０２、加工回数３０３、加工方法３０４、加工処理の引数３０５が格納される。

図３のエンジン冷却水温度のように、単一のデータ種別２０２のセンサデータに対し、複数の加工処理を行う場合もありうる。加工データ「Ｄ０１」の加工処理では、取得したエンジン冷却水温度に対し、別のセンサ１４１から取得した外気温を減じたのち、ヒストグラムを生成する。
また、加工データ「Ｄ０２」の加工処理では、６００秒間でのエンジン冷却水温度の最大値を求める。また、加工データ「Ｄ０４」の場合では、取得したＯｎ／Ｏｆｆのデータに、取得時刻を付与し、さらに、これまで取得した加工済データに対し、時刻付与後のデータを連結する。
また、加工データ「Ｄ０５」の場合では、取得した走行時間と、これまでに取得した走行時間との合計値を求める。また、可変データが可変長の場合は、データ長３０２に「可変長：２」のようにヘッダに可変長を示す文字列とデータ長を表すためのバイト数が付与される。

加工前閾値ルール定義１０４の一例を図４に示す。
加工前閾値ルール定義１０４には、閾値判定の条件数４０１、閾値超過した場合の送信方法を一意に表す送信定義ＩＤ４０２、データ種別２０２、閾値判定の条件４０３、閾値４０４が格納される。この例の場合、取得したエンジン冷却水温度が閾値「８０」より大きく（条件）、かつエンジン回転数が閾値「４０００」より小さければ（条件）、データ送信処理により、データを送信するという定義になっている。

加工後閾値ルール定義１０５の一例を図５に示す。加工後閾値ルール定義１０５には、閾値判定の条件数５０１、閾値超過した場合の送信方法を表す送信定義ＩＤ４０２、加工データＩＤ３０１、閾値判定の条件５０２、標準値５０３、閾値５０４が格納される。標準値５０３は、条件５０２に記載された閾値判定方法において、加工データとの比較に用いられる。例えば、条件５０２がヒストグラム相関の場合、標準値５０３には正常なヒストグラムが格納され、加工データとの比較に利用される。

送信時機ルール定義１０６の一例を図６に示す。
送信時機ルール定義１０６には、送信時機６０１、送信時機の引数６０２、送信時機６０１記載の時機になった場合に送信するデータを定義する送信定義ＩＤ４０２が格納される。例えば、送信時機６０１が定時の場合は、引数６０２記載の時刻（この例では１０時）にデータ送信が行われる。また、送信時機６０１が周期の場合は、引数６０２記載の時刻が経過（この例では８６４００秒経過）するたびにデータ送信が行われ、送信時機６０１が位置変化の場合、引数６０２記載の距離（この例では１００Ｋｍ）移動するたびにデータ送信が行われる。

送信内容ルール定義１０７の一例を図７に示す。
送信内容ルール定義１０７には、送信定義ＩＤ４０２、送信データ数７０１、送信する加工データ１５０１を指定する送信内容７０２、及び送信時に加工データ１５０１を削除するか否かを表すキャッシュ削除フラグ７０３が格納される。
例えば、送信定義ＩＤ４０２が「Ｐ００」の場合、ゲートウェイデバイス１２１は、加工データＩＤ３０１が「Ｄ０１」「Ｄ０２」「Ｄ０３」「Ｄ０４」の加工データ１５０１を連結し、データ収集サーバ１０１に送信した後、送信した加工データをストレージから削除する。

バイナリ定義テーブル群１１１の構成を図８に示す。
バイナリ定義テーブル群１１１は、各ルール定義をルールバイナリに変換するためのビット列構成を定義するテーブルであり、変換ルール用バイナリ定義テーブル群８０１、加工ルール用バイナリ定義テーブル群８１１、加工前閾値判定ルール用バイナリ定義テーブル群８２１、加工後閾値判定ルール用バイナリ定義テーブル群８３１、送信内容ルール用バイナリ定義テーブル群８４１、送信時機ルール用バイナリ定義テーブル群８５１からなる。

変換ルール用バイナリ定義テーブル群８０１は、変換ルールバイナリ１２３のビット列配置を定義する変換ルールバイナリ構成テーブル８０２、変換ルール定義１０２の項目をビット列に変換するためのデータ種別ビット列テーブル８０３、バイトオーダービット列テーブル８０４、変換方法ビット列テーブル８０５から構成される。
ＣＡＮ ＩＤ２０１や開始位置２０４のように変換ルール定義１０２中の値をそのままビット列に変換すればよい場合は、ビット列テーブルは作成不要である。また、図８中には記載していないが、他のバイナリ定義テーブル群１１１も変換ルール用バイナリ定義テーブル群８０１と同様にルールバイナリのビット列配置を定義するテーブルと、ルール定義中の項目をビット列に変換するためのテーブルを持つ。

変換ルールバイナリ構成テーブル８０２の一例を図９に示す。
変換ルールバイナリ構成テーブル８０２は、バイナリ中に項目を配置する順番を表すインデックス９０１と、変換方法２０８と引数２０９のように項目が複数存在する場合にその順番を表すサブインデックス９０２と、変換ルール定義１０２中の項目名９０３、データ長９０４、ビット列変換方法２０８が指定されているビット列テーブル名９０５を持つ。
変換ルール定義１０２の各項目は、それぞれデータ長９０４のビット列に変換され、インデックス９０１とサブインデックス９０２で指定された順番に連結される。

データ種別ビット列テーブル８０３を図１０に示す。
データ種別ビット列テーブル８０３は、データ種別２０２とデータ種別ビット列１００１からなる。ルールバイナリ生成部１１０は、本テーブルに従い、データ種別２０２をビット列に変換する。
その他、バイトオーダービット列テーブル８０４、データ型ビット列１２０１テーブル、変換方法ビット列テーブル８０５の例をそれぞれ、図１１、図１２、図１３に示す。
データ種別ビット列テーブル８０３と同様に、ルールバイナリ生成部１１０は、変換ルール定義１０２の各項目をビット列に変換する。

ゲートウェイデバイス１２１は、センサ１４１から収集したデータを変換、加工し、データ収集サーバ１０１に送信するデバイスであり、ルール定義受信部１２２、ルールバイナリ格納部１２９、データ収集部１３０、データ変換部１３１、データ加工部１３２、閾値判定部１３３、データ送信部１３９、データキャッシュ１３６から構成される。
ルール定義受信部１２２は、データ収集サーバ１０１から受信した各種ルールバイナリをルールバイナリ格納部１２９に格納する。

ルールバイナリ格納部１２９には、変換ルールバイナリ１２３、加工ルールバイナリ１２４、加工前閾値ルールバイナリ１２５、加工後閾値ルールバイナリ１２６、送信時機ルールバイナリ１２７、送信内容ルールバイナリ１２８が格納され、それぞれ、変換ルール定義１０２、加工ルール定義１０３、加工前閾値ルール定義１０４、加工後閾値ルール定義１０５、送信時機ルール定義１０６、送信内容ルール定義１０７が、ルールバイナリ生成部１１０によって、バイナリ変換されたものである。

データ収集部１３０は、センサ１４１から収集したデータをデータ変換部１３１に渡す。
データ変換部１３１は、データ収集部１３０から受け取ったセンサデータに含まれる値を、変換ルールバイナリ１２３に従い、汎用的な値に変換して、データキャッシュ１３６に格納し、データ加工部１３２と閾値判定部１３３に通知する。対応する変換ルールバイナリ１２３が存在しない場合、センサデータは不要データとして、破棄される。
データ加工部１３２は、データ変換部１３１から通知を受け取った後、データキャッシュ１３６からデータを取得する。取得したデータを加工ルールバイナリ１２４に従い、データキャッシュ１３６に格納されている既存の加工データ１５０１と併せて、ヒストグラム生成や最大値判定等の加工処理を行った後、再度、データキャッシュ１３６に値を格納する。

閾値判定部１３３は、加工前閾値判定部１３４と加工後閾値判定部１３５からなり、加工前閾値判定部１３４は、加工前閾値ルールバイナリ１２５に従い、データ変換部１３１から通知を受け取った後、データキャッシュ１３６から取得したデータの閾値超過を判定する。
加工前閾値ルールバイナリ１２５が、図４に示した加工前閾値ルール定義１０４から生成されており、閾値判定に必要なデータ種別２０２が複数存在する場合は、データキャッシュ１３６から対応する最新値１４０１を取得して、閾値判定を行う。
加工後閾値判定部１３５は、加工後閾値ルールバイナリ１２６に従い、データ加工部１３２から取得した加工データ１５０１の閾値超過を判定する。加工後閾値判定も加工前閾値判定と同様に、閾値判定に必要な加工データ１５０１が複数存在する場合は、データキャッシュ１３６から対応する加工データ１５０１を取得して、閾値判定を行う。

閾値判定部１３３は、いずれも閾値超過があった場合、データ送信部１３９にデータ送信を依頼する。
データ送信部１３９は、送信時機ルールバイナリ１２７に従い、送信時機６０１を監視し、送信時機６０１に達した時、データ収集サーバ１０１に対し、加工データ１５０１を送信する。
データキャッシュ１３６は、最新値１４０１を格納する最新値キャッシュ１３７と、加工データ１５０１を格納する加工データキャッシュ１３８からなる。
最新値キャッシュ１３７の一例を図１４に示す。
最新値キャッシュ１３７には、データ種別２０２とその最新値１４０１が格納されており、データ加工部１３２がデータを受け取る度に対応するデータ種別２０２の最新値１４０１が更新される。

加工データキャッシュ１３８の一例を図１５に示す。
加工データキャッシュ１３８には、加工データＩＤ３０１と加工データ１５０１、データ長３０２が格納されており、データ加工部１３２がデータを受け取る度に読込みと更新が行われる。
例えば、加工データＩＤ３０１「Ｄ０１」は、データ加工ルール定義１０３で、加工方法３０４として外気温による減算とヒストグラムが設定されており、ヒストグラムの引数３０５として、間隔２０、基準値０を表す「２０／０」が設定されているため、値０から２０℃間隔でエンジン冷却水温度から外気温を引いた値を集計したヒストグラムが格納される。

データ格納部１１４の一例を図１６に示す。
データ格納部１１４には、ゲートウェイデバイス１２１から収集した加工データＩＤ３０１、データ種別２０２、加工データ１５０１、データを収集した時刻を表すタイムスタンプ１６０２が格納されており、デバイスの状態可視化や統計分析に活用される。

ルール定義の生成・配信処理を説明するシーケンスを図１７に示す。
ルール定義生成部１０９が、ＵＩからの入力を受けて、ルール定義を生成する。既にルール定義が存在する場合は更新する（ステップ１７０１）。
ルール定義生成部１０９が、ステップ１７０１で生成したルール定義をルール定義格納部１０８に格納し、ルールバイナリ生成部１１０に対し、ルールバイナリ生成要求を出す（ステップ１７０２）。

ルールバイナリ生成部１１０が、ステップ１７０２で格納されたルール定義を取得し、バイナリ定義テーブル群１１１に記載されたバイナリ変換方法２０８を元に、ルール定義をルールバイナリに変換し、ルール定義配信部１１２にルール定義配信要求を出す（ステップ１７０３）。ルール定義のルールバイナリへの変換処理は図１８にて詳細に説明する
ルール定義配信部１１２が、ルール定義受信部１２２にルール定義生成・更新通知を出す（ステップ１７０４）。通知は、ＳＭＳやＬｏｎｇＰｏｌｌｉｎｇによって行われる。本ステップは、生成したルール定義を即時にゲートウェイデバイス１２１に反映するためのものであり、即時性を必要としない場合では、本ステップは不要である。
ルール定義受信部１２２が、ルールバイナリ配信要求をルール定義配信部１１２に出す（ステップ１７０５）。

ルール定義配信部１１２は、ステップ１７０３で生成したルールバイナリをルール定義受信部１２２に送信する（ステップ１７０６）。
ルール定義受信部１２２は、ステップ１７０６で受信したルールバイナリをルールバイナリ格納部１２９に格納する（ステップ１７０７）。

図１８に、ステップ１７０３における変換ルールバイナリ１２３の生成処理のフローチャートを示す。他のルールバイナリについても本フローチャートと同様の処理が行われる。
まず、変数ｎに０を格納する。ｎはバイナリ生成処理中の変換ルール定義１０２の行を表す。後述するステップ１８０５でインクリメントされ、変換ルール定義１０２の最終行までルールバイナリ生成処理を繰り返す（ステップ１８０１）。
次に、変数ｍに０を格納する。ｍは変換ルールバイナリ構成テーブル８０２のインデックス９０１に対応し、変換処理中の変換ルール定義１０２の項目を表す。後述するステップ１８２１でインクリメントされ、変換ルール定義１０２の全項目に対して、ルールバイナリ生成処理を行う（ステップ１８０２）。
この後、変換ルールバイナリ構成テーブル８０２からインデックス９０１がｍのレコードを読み込む。図９の場合、ｍが０の時は、項目名９０３「ＣＡＮ ＩＤ２０１」のレコードが読み込まれる（ステップ１８０３）。

ステップ１８０３において、レコードが存在する場合、ステップ１８０６に進み、存在しない場合、ステップ１８０５に進む。図９の例の場合は、ｍが０〜７の時、レコードが存在するため、ステップ１８０６に進み、ｍが８の時、変換ルール定義１０２の次の行のルールバイナリ生成に移る（ステップ１８０４）。
次に、ｎをインクリメントして、ステップ１８０２に戻る（ステップ１８０５）。
ステップ１８０３で取得したレコードのサブインデックス９０２がｎｕｌｌの場合は、ステップ１８０７に進み、サブインデックス９０１に値が格納されている場合は、１レコードに複数存在する項目として、ステップ１８０８以降の処理を行う。
図９の例の場合、ｍが０〜６の時はサブインデックス９０２がｎｕｌｌであり、項目名９０３で指定される項目が変換ルール定義１０２に１回しか登場しないことを表す。また、ｍが７のときは、サブインデックス９０２に値が格納されており、項目「変換方法２０８」と「引数２０９」が変換ルール定義１０２に複数回登場することを表す（ステップ１８０６）。

次に、変換ルール定義１０２のｎ行目のレコードからステップ１８０３で取得した変換ルールバイナリ構成テーブル８０２の項目名９０３と同一のカラム名の値を取得する。例えば、ｎ＝０、ｍ＝０の場合、図２の変換ルール定義１０２の０行目のレコードから、図９の変換ルールバイナリ構成テーブル８０２のインデックス９０１０の項目名９０３「ＣＡＮ ＩＤ２０１」のカラムの値である「ＡＡＡ」が取得される（ステップ１８０７）。
次に、変数ｌに０を格納する。ｌは変換ルール定義１０２に複数回登場する項目の順番を表す値であり、ステップ１８１２でインクリメントされ、項目の登場回数分、ステップ１８０９からステップ１８２０の処理を繰り返す（ステップ１８０８）。

次に、変数ｉに０を格納する。ｉは変換ルールバイナリ１２３生成処理の対象となっている変換ルールバイナリ構成テーブル８０２のサブインデックス９０２の値を表す値であり、ステップ１８２０でインクリメントされ、複数回登場する項目の数だけ、ステップ１８１０からステップ１８１９の処理を繰り返す（ステップ１８０９）。
次に、変換ルールバイナリ構成テーブル８０２から、インデックス９０１ｍ、サブインデックス９０２ｉのレコードを取得する（ステップ１８１０）。

次にステップ１８１０で、レコードが存在した場合は、ステップ１８１３に進み、存在しなかった場合は、ステップ１８１４に進む。例えば、ｍ＝７、ｉ＝０の場合は、ステップ１８０９で、変換ルールバイナリ構成テーブル８０２にインデックス９０１「７」とサブインデックス９０２「０」のレコードが存在するため、ステップ１８１３に進み、ｍ＝６、ｉ＝０の場合は、変換ルールバイナリ構成テーブル８０２に対象となるレコードが存在しないため、ステップ１８１２に進む。
次に、変数ｌをインクリメントして、ステップ１８０９に戻る（ステップ１８１２）。
次に、変換ルール定義１０２のｎ行目のレコードから、ステップ１８１０で取得したレコードの項目名９０３とｌの連結文字をもつカラムの値を取得する。ｎ＝０、ｍ＝７、ｌ＝０の場合は、図２の変換ルール定義１０２の０行目のレコードの、「変換方法０ ２０８−１」のカラムから「乗算」を取得する（ステップ１８１３）。

ステップ１８１３で、カラムが存在し、値が取得できた場合は、ステップ１８１５に進み、対象となるカラムが存在しなかった場合は、ステップ１８２１に進む。例えば、ｍ＝７、ｉ＝０、ｌ＝０の場合は、変換ルール定義１０２に「変換方法０ ２０８−１」のカラムが存在し、ステップ１８１３で値を取得できるため、ステップ１８１５に進む。
また、ｍ＝７、ｉ＝０、ｌ＝２の場合、変換ルール定義１０２に「変換方法２０８３」のカラムは存在しないため、ステップ１８２１に進む（ステップ１８１４）。
ステップ１８０３、もしくはステップ１８１０で取得した変換ルールバイナリ構成テーブル８０２のバイナリテーブル名の値がｎｕｌｌであれば、ステップ１８１６に進み、バイナリテーブル名にｎｕｌｌ以外の値が格納されていれば、バイナリテーブルによる変換を行うため、ステップ１８１７に進む（ステップ１８１５）。
ステップ１８０７、もしくはステップ１８１３で取得した、変換ルール定義１０２に格納されている値を変換ルールバイナリ１２３に後置連結する（ステップ１８１６）。

変換ルールバイナリ１２３の一例を図１９に示す。
変換ルール定義１０２に記載された「ＣＡＮ ＩＤ２０１」、「データ種別２０２」、「バイトオーダービット列１１０１」、「開始位置２０４」、「データ長２０５」、「データ型２０６」、「変換回数２０７」、「変換方法０ ２０８−１」、「引数０ ２０９−１」、「変換方法１ ２０８−２」、「引数１ ２０９−２」がビット列に変換され、連結されている。
図１９の例は、変換ルール定義１０２の１行目を変換したものであり、変換ルール定義１０２の１行目記載のＣＡＮ ＩＤ２０１「ＡＡＡ（１６進数）」はビット列「１０１０１０１０１０１０１０１０」として、変換ルールバイナリ１２３に連結されている。また、データ種別２０２「エンジン冷却水温度」は図１０のデータ種別ビット列テーブル８０３でビット列「０ｘ００」に変換され、変換ルールバイナリ構成テーブル８０２記載のデータ長９０４に直されて、ビット列「００００００００」として連結されている。

次に、ステップ１８０７、もしくはステップ１８１３で取得した、変換ルール定義１０２に格納されている値を、ステップ１８０３、もしくはステップ１８１０で取得した変換ルールバイナリ構成テーブル８０２のバイナリテーブル名記載のテーブルで変換する。例えば、変換ルール定義１０２からデータ種別２０２「エンジン冷却水温度」を取得した場合、図１０のデータ種別ビット列テーブル８０３８０３で「エンジン冷却水温度」に対応するデータ種別ビット列１００１「０ｘ００」に変換する（ステップ１８１７）。

次に、ステップ１８１７で変換した値を、変換ルールバイナリ１２３に後置連結する。このとき、データ長は、変換ルールバイナリ構成テーブル８０２のデータ長９０４の値に従う。例えば、項目名９０３がデータ種別２０２の場合、ビット列「０ｘ００」を８ビット「００００００００」として、変換ルールバイナリ１２３に後置連結する（ステップ１８１８）。
次に、ステップ１８０４で取得したレコードのサブインデックス９０２の値が、ｎｕｌｌではない場合は、次のサブインデックス９０２の項目を変換するため、ステップ１８２０に進む。また、ステップ１８０４で取得したレコードのサブインデックス９０２の値が、ｎｕｌｌである場合は、次のインデックス９０１の項目を変換するため、ステップ１８２１に進む（ステップ１８１９）。
次に、変数ｉをインクリメントして、ステップ１８１０に戻る（ステップ１８２０）。
次に、変数ｍをインクリメントして、ステップ１８０２に戻る（ステップ１８２１）。

センサデータの加工・送信処理を説明するシーケンス図を図２０に示す。
まず、データ収集部１３０が、センサ１４１からデータを受信し、データ変換部１３１に渡す（ステップ２００１）。
次に、データ変換部１３１が、データ収集部１３０から受け取ったデータを、データ変換ルールバイナリ１２３記載の変換ルールに従って変換し、最新値キャッシュ１３７に格納し、加工前閾値判定部１３４とデータ加工部１３２にデータの項目名９０３を通知する（ステップ２００２）。データ変換処理の詳細は、図２１にて説明する。

次に、加工前閾値判定部１３４が、データ変換部１３１から受け取った通知に含まれる項目名９０３のデータを最新値キャッシュ１３７から取得し、加工前閾値バイナリ記載の閾値ルールに従って閾値判定を行う（ステップ２００３）。加工前閾値判定処理の詳細は、図２２にて説明する
次に、ステップ２００３で、閾値超過した場合は、データ送信部１３９に送信定義ＩＤ４０２を通知して、ステップ２００８に進み、閾値超過しなかった場合は、処理を終了する（ステップ２００４）。

次に、データ加工部１３２が、データ変換部１３１から受け取った通知に含まれる項目名９０３のデータを最新値キャッシュ１３７から取得し、加工ルールバイナリ１２４記載の加工ルールに従って加工処理を行い、加工データキャッシュ１３８に格納し、加工後閾値判定部１３５にデータの加工データＩＤ３０１を通知する（ステップ２００５。データ加工処理の詳細は、図２３にて説明する）

次に、加工後閾値判定部１３５が、データ加工部１３２から受け取った通知に含まれる加工データＩＤ３０１のデータを加工データキャッシュ１３８から取得し、加工後閾値ルールバイナリ１２６記載の閾値ルールに従って閾値判定を行う（ステップ２００６）。加工後閾値判定処理の詳細は、図２４にて説明する。
ステップ２００６で、閾値超過した場合は、データ送信部１３９に送信定義ＩＤ４０２を通知して、ステップ２００８に進み、閾値超過しなかった場合は、処理を終了する（ステップ２００７）。

次に、データ送信部１３９が、加工前閾値判定部１３４、もしくは加工後閾値判定部１３５から受け取った送信定義ＩＤ４０２に対応する送信内容ルールバイナリ１２８記載の送信ルールに従い、データをデータ受信部１１３に送信する。また、送信時機ルールバイナリ１２７記載の送信時機６０１になった時、同様に送信内容ルールバイナリ１２８定義の送信ルールに従い、データをデータ受信部１１３に送信する（ステップ２００８）。データ送信処理の詳細は、図２５にて説明する。

次に、データ受信部１１３が、データ送信部１３９から受信したデータを、各種ルール定義記載のルールに従って分解し、データ格納部１１４に格納する（ステップ２００９）。データ格納処理の詳細は図２６にて説明する。

図２１に、ステップ２００２のデータ変換処理のフローチャートを示す。
まず、データ収集部１３０から取得したＣＡＮデータを、ＣＡＮ ＩＤ２０１とデータバイナリに分解する（ステップ２１０１）。
次に、ルールバイナリ格納部１２９からステップ２１０１で取得したＣＡＮ ＩＤ２０１と一致する変換ルールバイナリ１２３を全て取得する。例えば、ＣＡＮ ＩＤ２０１が「ＡＡＡ」の場合、変換ルール定義１０２の１、２行目に記載のルール定義から生成された変換ルールバイナリ１２３が取得される（ステップ２１０２）。
次に、ステップ２１０２で取得したデータ変換バイナリの、バイトオーダービット列１１０１ビット列で指定されているバイトオーダービット列１１０１でデータバイナリを読み込む。ＣＡＮ ＩＤ２０１が「ＡＡＡ」の場合、バイトオーダービット列１１０１ビット列は全てリトルエンディアンを表す「１」であり、リトルエンディアンとして、データバイナリを読み込む（ステップ２１０３）。

次に、変数ｎに１を代入する。ｎは変換ルールバイナリ１２３の順番を表す（ステップ２１０４）。
次に、ｎ番目の変換ルールバイナリ１２３から開始位置２０４とデータ長２０５を取得する。図２の変換ルール定義１０２１行目のルール定義から生成された変換ルールバイナリ１２３の場合、開始位置２０４として「０」、データ長２０５として「８」が取得される（ステップ２１０５）。

次に、ステップ２１０３で読み込んだデータバイナリの、ステップ２１０５で取得した開始位置２０４からデータ長２０５分のビット列を取得する（ステップ２１０６）。
次に、ステップ２１０６で取得したビット列を、ｎ番目の変換データバイナリのデータ型ビット列１２０１で指定されているデータ型２０６に変換する。図２の変換ルール定義１０２１行目のルール定義から生成された変換ルールバイナリ１２３の場合に、取得したビット列が「００１１１１００」とすると、データ型２０６「ｉｎｔ１６」として「６０」に変換される（ステップ２１０７）。

次に、ｎ番目の変換ルールバイナリ１２３から変換回数２０７を取得する。図２の変換ルール定義１０２１行目のルール定義から生成された変換ルールバイナリ１２３の場合、変換回数２０７「２」が取得される（ステップ２１０８）。
次に、変数ｍに１を代入する。ｍは変換の順番を表し、ステップ２１０８で取得した変換回数２０７になるまでインクリメントされる（ステップ２１０９）。

次に、ステップ２１０７でデータ型２０６を変換したデータ、もしくは本ステップで変換したデータに対し、ｎ番目の変換ルールバイナリ１２３のｍ番目の変換方法ビット列１３０１で指定されている変換処理を行う。ステップ２１０７の例の場合、ｍが０の時に、データ「６０」に対し、「５」を乗算、ｍが１の時に、「２７３」を減算し、データ「２７」を得る（ステップ２１１０）。

次に、ｍがステップ２１０８で取得した変換回数２０７未満の場合、ステップ２１１２に進み、変換回数２０７以上の場合、ステップ２１１３に進む（ステップ２１１１）。
次に、変数ｍをインクリメントして、ステップ２１１０に戻る（ステップ２１１２）。
次に、ステップ２１１０で変換したデータを、データ種別２０２と共に最新値キャッシュ１３７に格納する（ステップ２１１３）。

次に、ステップ２１１０で変換したデータのデータ種別２０２を、加工前閾値判定部１３４とデータ加工部１３２に通知する（ステップ２１１４）。
次に、ｎがステップ２１０２で取得した変換ルールバイナリ１２３数未満の場合、ステップ２１１６に進み、変換ルールバイナリ１２３数以上の場合、データ変換処理を終了する（ステップ２１１５）。
次に、変数ｎをインクリメントして、ステップ２１０５に戻る（ステップ２１１６）。

図２２に、ステップ２００５のデータ加工処理のフローチャートを示す。
まず、図２１のデータ変換処理から通知されたデータ種別２０２を持つデータを最新値キャッシュ１３７から取得する。通知されたデータ種別２０２が「エンジン冷却水温度」の場合、最新値キャッシュ１３７から「６０」が取得される（ステップ２２０１）。
次に、データ変換処理から通知されたデータ種別２０２を持つ加工ルールバイナリ１２４を全て取得する。データ種別２０２が、「エンジン冷却水温度」の場合、図３の加工ルール定義１０３の１、２行目から生成された加工ルールバイナリ１２４が取得される（ステップ２２０２）。

次に、変数ｎに１を代入する。ｎはステップ２２０２で取得した加工ルールバイナリ１２４の数だけインクリメントされる（ステップ２２０３）。
次に、ｎ番目の加工ルールバイナリ１２４から加工回数３０３を取得する。例えば、図３の加工ルール定義１０３の１行目から生成された加工ルールバイナリ１２４の場合、加工回数３０３「２」が取得される（ステップ２２０４）。
次に、変数ｍに１を代入する。ｍはステップ２２０４で取得した加工回数３０３だけインクリメントされる（ステップ２２０５）。

次に、ｎ番目の加工ルールバイナリ１２４からｍ番目の引数ビット列を取得し、引数値に変換する。例えば、図３の加工ルール定義１０３の１行目から生成された加工ルールバイナリ１２４の場合、ｍが０の時、「データ種別２０２：外気温」を取得・変換し、ｍが１の時、「２００／０」を取得・変換する（ステップ２２０６）。
ステップ２２０６で取得した引数３０５がデータ種別２０２である場合は、ステップ２２０８に進み、データ種別２０２以外である場合は、ステップ２２０９に進む（ステップ２２０７）。

次に、引数３０５記載のデータ種別２０２の値を最新値キャッシュ１３７から取得する。例えば、ステップ２２０６で「データ種別２０２：外気温」が取得された場合、図１４の最新値キャッシュ１３７から「１７」が取得される（ステップ２２０８）。
次に、ステップ２２０１で取得したデータ、もしくは本ステップで加工したデータに対し、ステップ２２０６、もしくはステップ２２０７で取得した引数値を用いて、ｎ番目の加工ルールバイナリ１２４のｍ番目の加工方法ビット列で指定された加工処理を行う。ｎ＝０、ｍ＝０の時、加工方法３０４は「減算」であり、ステップ２２０７で取得した外気温「１７」をエンジン冷却水温度の最新値１４０１「６０」から減算し、「４３」を得る。さらに、ｍ＝１の時、「４３」を「ヒストグラム」に加える（ステップ２２０９）。
ｍがステップ２２０４で取得した加工回数３０３未満の場合、ステップ２２１１に進み、加工回数３０３以上の場合、ステップ２２１２に進む（ステップ２２１０）。
次に、ｍをインクリメントして、ステップ２２０６に戻る（ステップ２２１１）。

次に、ステップ２２０９で加工したデータを加工データキャッシュ１３８に格納し、加工後閾値判定部１３５に通知する。加工データキャッシュ１３８のデータ長３０２に何も格納されていない場合は、ｎ番目の加工ルールバイナリ１２４のデータ長３０２を共に格納する（ステップ２２１２）。
ｎがステップ２２０２で取得した加工ルールバイナリ１２４数未満の場合、ステップ２２１４に進み、加工ルールバイナリ１２４数以上の場合、データ加工処理を終了する（ステップ２２１３）。
最後に、ｎをインクリメントしてステップ２２０４に戻る（ステップ２２１４）。

図２３に、ステップ２００３の加工前閾値判定処理のフローチャートを示す。
まず、データ変換部１３１から通知されたデータ種別２０２を持つ加工前閾値ルールバイナリ１２５を全て取得する。通知されたデータ種別２０２が「エンジン冷却水温度」の場合、図４の加工前閾値ルール定義１０４の１行目のレコードから生成された加工前閾値ルールバイナリ１２５が取得される（ステップ２３０１）。

次に、変数ｎに１を代入する。ｎは加工前閾値ルールバイナリ１２５の数だけインクリメントされる（ステップ２３０２）。
次に、ステップ２３０１で取得したｎ番目の加工前閾値ルールバイナリ１２５から条件数４０１を取得する（ステップ２３０３）。
次に、変数ｍに１を代入する。ｍは閾値判定の条件４０３の数だけインクリメントされる。図４の加工前閾値ルール定義１０４の１行目から生成された加工前閾値ルールバイナリ１２５からは、「２」が取得される（ステップ２３０４）。
次に、ｎ番目の加工前閾値ルールバイナリ１２５からｍ番目のデータ種別２０２を取得する。ｍ＝０の時、「エンジン冷却水温度」が取得され、ｍ＝１の時、「エンジン回転数」が取得される（ステップ２３０５）。

次に、ステップ２３０５で取得したデータ種別２０２の値を最新値キャッシュ１３７から取得する。データ種別２０２が「エンジン冷却水温度」の場合、図１４の最新値キャッシュ１３７から「６０」が取得される（ステップ２３０６）。
次に、ｎ番目の加工前閾値ルールバイナリ１２５から、ｍ番目の条件４０３と閾値４０４を取得し、閾値判定を行う（ステップ２３０７）

ステップ２３０７の閾値判定で閾値超過だった場合、ステップ２３１０に進み、閾値超過でない場合は、ステップ２３１１に進む。図４の加工前閾値ルール定義１０４から生成された加工前閾値ルールバイナリ１２５の場合、「エンジン冷却水温度」が「８０」よりも大きい場合、ステップ２３１０に進む（ステップ２３０８）。
次に、ｍがステップ２３０３で取得した条件数４０１未満の場合はステップ２３０に進み、条件数４０１以上の場合はステップ２３０９に進む（ステップ２３０９）。

次に、ｍをインクリメントして、ステップ２３０５に戻る（ステップ２３１０）。
ｎ番目の加工前閾値ルールバイナリ１２５から送信定義ＩＤ４０２を取得し、データ送信部１３９に渡す（ステップ２３１１）。
ｎがステップ２３０１で取得した加工前閾値ルールバイナリ１２５の数未満の場合、ステップ２３１３に進み、加工前閾値ルールバイナリ１２５の数以上の場合、加工前閾値判定処理を終了する（ステップ２３１２）。
最後に、ｎをインクリメントして、ステップ２３０３に戻る（ステップ２３１３）。

図２４に、ステップ２００６の加工後閾値判定処理のフローチャートを示す。
まず、データ加工部１３２から通知された加工データＩＤ３０１を持つ加工後閾値ルールバイナリ１２６を全て取得する。通知された加工データＩＤ３０１が「Ｄ０１」の場合、図５の加工後閾値ルール定義１０５の１行目のレコードから生成された加工後閾値ルールバイナリ１２６が取得される（ステップ２４０１）。
次に、変数ｎに１を代入する。ｎは加工後閾値ルールバイナリ１２６の数だけインクリメントされる（ステップ２４０２）。
ステップ２４０１で取得したｎ番目の加工後閾値ルールバイナリ１２６から条件数５０１を取得する（ステップ２４０３）。

次に、変数ｍに１を代入する。ｍは閾値判定の条件５０２の数だけインクリメントされる。図５の加工後閾値ルール定義１０５の１行目から生成された加工後閾値ルールバイナリ１２６からは、「１」が取得される（ステップ２４０４）。
次に、ｎ番目の加工後閾値ルールバイナリ１２６からｍ番目の加工データＩＤ３０１を取得する。ｍ＝０の時、「Ｄ０１」が取得される（ステップ２４０５）。
次に、ステップ２４０５で取得した加工データＩＤ３０１の値を加工データキャッシュ１３８から取得する（ステップ２４０６）。

次に、ｎ番目の加工後閾値ルールバイナリ１２６から、ｍ番目の条件５０２と標準値５０３、閾値５０４を取得し、閾値判定を行う。条件５０２が「ヒストグラム相関」の場合、加工データキャッシュ１３８内のヒストグラムと標準値５０３に格納されているヒストグラムの相関係数を求め、閾値超過を判定する（ステップ２４０７）。
ステップ２４０５の閾値判定で閾値超過だった場合、ステップ２４０９に進み、閾値超過ではなかった場合は、ステップ２４１０に進む（ステップ２４０８）。
ｍがステップ２４０３で取得した条件数５０１未満の場合はステップ２４１０に進み、条件数５０１以上の場合はステップ２４１１に進む（ステップ２４０９）。

次に、ｍをインクリメントして、ステップ２４０５に戻る（ステップ２４１０）。
次に、ｎ番目の加工後閾値ルールバイナリ１２６から送信定義ＩＤ４０２を取得し、データ送信部１３９に渡す（ステップ２４１１）。
次に、ｎがステップ２４０１で取得した加工後閾値ルールバイナリ１２６の数未満の場合、ステップ２４１３に進み、加工後閾値ルールバイナリ１２６の数以上の場合、加工後閾値判定処理を終了する（ステップ２４１２）。
最後に、ｎをインクリメントして、ステップ２４０３に戻る（ステップ２４１３）。

図２５に、ステップ２００７のデータ送信処理のフローチャートを示す。
まず、データ送信処理の開始トリガーは、閾値判定部１３３による閾値超過検知時に送信定義ＩＤ４０２を受け取った場合（ステップ２５０１）と、送信時機ルールバイナリ１２７で指定された送信時機６０１に達した時に送信ルールバイナリから送信定義ＩＤ４０２を取得した場合（ステップ２５０２とステップ２５０３）のいずれかである。いずれもステップ２５０４以降の処理は同じである。
そこで、ステップ２５０１、もしくはステップ２５０３で取得した送信定義ＩＤ４０２を持つ送信内容バイナリを取得する（ステップ２５０４）。

次に、ステップ２５０４で取得した送信内容バイナリから送信データ数７０１と送信内容７０２、キャッシュ削除フラグ７０３を取得する（ステップ２５０５）。
次に、ゲートウェイデバイス１２１のＩＤと送信データを連結し、送信データを生成する。以降のステップでデバイスＩＤ１６０１に加工データ１５０１を連結する（ステップ２５０６）。

次に、変数ｎに１を代入する。ｎは送信データ数７０１だけインクリメントされ、繰り返し処理に利用される（ステップ２５０７）。
ステップ２５０５で取得した送信内容７０２からｎ番目の加工データＩＤ３０１を取得する。送信定義ＩＤ４０２が「Ｐ００」で、ｎ＝１の場合は、加工データＩＤ３０１「Ｄ０１」を取得する（ステップ２５０８）。
次に、ステップ２５０８で取得した加工データＩＤ３０１の加工データ１５０１とデータ長３０２を加工データキャッシュ１３８から取得する。ステップ２５０８で取得した加工データＩＤ３０１が「Ｄ０４」の場合、加工データ１５０１「８：３０／Ｏｎ，９：３０／Ｏｆｆ」とデータ長３０２「可変長：２」が取得できる（ステップ２５０９）。

ステップ２５０９で取得したデータ長３０２が可変長である場合は、ステップ２５１１に進み、固定長の場合は、ステップ２５１２に進む（ステップ２５１０）。
ステップ２５０９で取得した加工データ１５０１のデータ長３０２を算出し、ステップ２５０９で取得したデータ長３０２で指定されたバイト数分、送信データに加工データ１５０１のデータ長を後置連結する。ステップ２５０８で取得した加工データＩＤ３０１が「Ｄ０４」であった場合は、加工データ１５０１のデータ長は２バイトで表現される。加工データ１５０１のデータ長を１７バイトとすると、バイナリ「０ｘ００１１」が送信データに加工データ１５０１のデータ長として後置連結される（ステップ２５１１）。
ステップ２５０９で取得した加工データ１５０１を送信データに後置連結する（ステップ２５１２）。

次に、ｎがステップ２５０５で取得した送信データ数７０１未満の場合、ステップ２５１４に進み、送信データ数７０１以上の場合、ステップ２５１４に進む（ステップ２５１３）。
次に、ｎをインクリメントして、ステップ２５０８に戻る（ステップ２５１４）。
次に、送信データをデータ収集サーバ１０１に送信する。送信定義ＩＤ４０２「Ｐ０１」の送信データは図２６のようになる。ステップ２５０６で付与されたデバイスＩＤ１６０１と送信定義ＩＤ４０２、送信定義ＩＤ４０２「Ｐ０１」で送信内容７０２として指定されている加工データＩＤ３０１「Ｄ０１」「Ｄ０２」「Ｄ０３」「Ｄ０４」の加工データ１５０１が連結されている。加工データＩＤ３０１「Ｄ０４」の加工データ１５０１は可変長であるため、加工データ１５０１の前にデータ長を表す「００ １１」が付与されている（ステップ２５１５）。

次に、ステップ２５０５で取得したキャッシュ削除フラグ７０３がＴＲＵＥの場合は、ステップ２５１７に進み、ＦＡＬＳＥの場合は、データ送信処理を終了する（ステップ２５１６）。
次に、加工データキャッシュ１３８から、ステップ２５０５で取得した送信内容７０２に記載されている加工データＩＤ３０１の加工データ１５０１を全て削除する（ステップ２５１７）。

図２７に、ステップ２００８のデータ格納処理のフローチャートを示す。
まず、ゲートウェイデバイス１２１からデータを受信する（ステップ２７０１）。
次に、ステップ２７０１で受信したデータからデバイスＩＤ１６０１と送信定義ＩＤ４０２を取得する。図２６で示したデータを受信した場合は、デバイスＩＤ１６０１「Ｄｅｖ１」と送信定義ＩＤ４０２「Ｐ０１」が取得される（ステップ２７０２）。
次に、送信内容ルール定義１０７からステップ２７０２で取得した送信定義ＩＤ４０２と一致するレコードの送信データ数７０１と送信内容７０２を取得する。送信定義ＩＤ４０２が「Ｐ０１」であれば、送信データ数７０１「４」と送信内容７０２「Ｄ０１ Ｄ０２ Ｄ０３ Ｄ０４」が取得される（ステップ２７０３）。

次に、変数ｎに１を代入する。ｎはステップ２７０３で取得した送信データ数７０１分インクリメントされ、送信データからの加工データ１５０１取得とデータ格納部１１４への格納の繰り返し処理に利用される（ステップ２７０４）。
次に、ステップ２７０３で取得した送信内容７０２からｎ番目の加工データＩＤ３０１を取得する。ｎ＝１であれば、加工データＩＤ３０１「Ｄ０１」が取得される（ステップ２７０５）。
次に、加工ルール定義１０３からステップ２７０５で取得した加工データＩＤ３０１と一致するレコードのデータ長３０２を取得する（ステップ２７０６）。

ステップ２７０６で取得したデータ長が可変長の場合は、ステップ２７０８に進み、固定長の場合は、ステップ２７０９に進む。例えば、ステップ２７０５で取得した加工データＩＤ３０１が「Ｄ０４」の場合、データ長は「可変長：２」であるため、ステップ２７０８に進み、ステップ２７０５で取得した加工データＩＤ３０１が「Ｄ０１」の場合、データ長は「２６」であり、固定長であるため、ステップ２７０９に進む（ステップ２７０７）。
次に、受信データからステップ２７０６で取得したデータ長分の加工データ１５０１のデータ長を表すバイト列を取得し、加工データ１５０１のデータ長を求める。例えば、ステップ２７０５で取得した加工データＩＤ３０１が「Ｄ０４」の場合、データ長が「可変長：２」であるため、２バイトのバイト列「００ １１」を加工データ１５０１のデータ長を表すデータとして取得し、加工データ１５０１のデータ長「１７」を得る。（ステップ２７０８）
受信データからステップ２７０６、もしくはステップ２７０８で取得したデータ長分の加工データ１５０１を取得する（ステップ２７０９）。

ステップ２７０２で取得したデバイスＩＤ１６０１と、ステップ２７０５で取得した加工データＩＤ３０１、ステップ２７０９で取得した加工データ１５０１、本ステップ実行時のタイムスタンプ１６０２をデータ格納部１１４に格納する（ステップ２７１０）。
次に、ｎがステップ２７０３で取得した送信データ数７０１未満であれば、ステップ２７１２に進み、送信データ以上であれば、データ格納処理を終了する（ステップ２７１１）。
最後に、ｎをインクリメントし、ステップ２７０５に戻る（ステップ２７１２）。

１０１ データ収集サーバ
１０２ 変換ルール定義
１０３ 加工ルール定義
１０４ 加工前閾値ルール定義
１０５ 加工後閾値ルール定義
１０６ 送信時機ルール定義
１０７ 送信内容ルール定義
１０８ ルール定義格納部
１０９ ルール定義生成部
１１０ ルールバイナリ生成部
１１１ バイナリ定義テーブル群
１１２ ルール定義配信部
１１３ データ受信部
１１４ データ格納部
１２１ ゲートウェイデバイス
１２２ ルール定義受信部
１２３ 変換ルールバイナリ
１２４ 加工ルールバイナリ
１２５ 加工前閾値ルールバイナリ
１２６ 加工後閾値ルールバイナリ
１２７ 送信時機ルールバイナリ
１２８ 送信内容ルールバイナリ
１２９ ルールバイナリ格納部
１３０ データ収集部
１３１ データ変換部
１３２ データ加工部
１３３ 閾値判定部
１３４ 加工前閾値判定部
１３５ 加工後閾値判定部
１３６ データキャッシュ
１３７ 最新値１４０１キャッシュ
１３８ 加工データキャッシュ
１３９ データ送信部
１４１ センサ
１５１ 広域ネットワーク
８０１ 変換ルール用バイナリ定義テーブル群
８０２ 変換ルールバイナリ構成テーブル
８０３ データ種別ビット列テーブル
８０４ バイトオーダービット列テーブル
８０５ 変換方法ビット列テーブル
８１１ 加工ルール用バイナリ定義テーブル群
８２１ 加工前閾値判定ルール用バイナリ定義テーブル群
８３１ 加工後閾値判定ルール用バイナリ定義テーブル群
８４１ 送信内容ルール用バイナリ定義テーブル群
８５１ 送信時機ルール用バイナリ定義テーブル群

Claims (3)

1. １ないし複数のセンサと、これらのセンサからデータを収集・変換・加工・閾値判定・圧縮し、任意の設定時機にデータ収集サーバへの送信が可能なゲートウェイデバイスと、ゲートウェイデバイスからセンサデータを収集するデータ収集サーバから構成され、当該データ収集サーバはセンサデータの変換・加工・閾値判定・圧縮・送信時機の設定をバイナリに圧縮し、ゲートウェイデバイスに送信する手段を備え、前記ゲートウェイデバイスは、バイナリに圧縮されたセンサデータの変換・加工・閾値判定・圧縮・送信時機の設定に従い、前記センサから収集したデータに対し、変換・加工・閾値判定・圧縮を実行し、設定された送信時機にデータ収集サーバにセンサデータを送信する手段を備えることを特徴とするセンサデータ収集システム。
2. 前記データ収集サーバは、センサデータの変換・加工・閾値判定・圧縮・送信時機を設定するルール定義を生成する手段を備え、生成したルール定義を広域ネットワークを介して前記ゲートウェイデバイスに送信することを特徴とする請求項１に記載のセンサデータ収集システム。
3. 前記データ収集サーバは、前記ルール定義をデータサイズの小さい定義ルールバイナリに変換する手段と、広域ネットワークを介して、前記定義ルールバイナリを前記ゲートウェイデバイスに送信する手段を備えることを特徴とする請求項２に記載のセンサデータ収集システム。
   

Images