以下では、上述した課題を解決するための手段を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。
以下の実施の形態においては便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明するが、特に明示した場合を除き、それらはお互いに無関係なものではなく、一方は他方の一部または全部の変形例、応用例、詳細説明、補足説明等の関係にある。また、以下の実施の形態において、要素の数等(個数、数値、量、範囲等を含む)に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。
さらに、以下の実施の形態において、その構成要素(動作ステップ等も含む)は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではない。同様に、以下の実施の形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。このことは、上記数等(個数、数値、量、範囲等を含む)についても同様である。
<実施の形態1>
図1は、実施の形態1にかかるセンサシステム1000の概要構成を示すブロック図である。センサシステム1000は、センサ装置11と、外部装置2とを備える。センサ装置11は、センサ素子1と、センサ制御装置10とを備える。センサ素子1は、測定対象物に対して設定値に基づく測定を行う。ここで、測定対象物とは、例えば、橋梁、橋脚、道路又はビル等の大型建造物が挙げられるが、これらに限定されない。そして、センサ素子1は、例えば、加速度センサ、温度センサ、バッテリ、MEMS(Micro Electro Mechanical Systems)等が挙げられるが、これらに限定されない。また、設定値とは、例えば、加速度センサにおけるサンプリングレート、測定レンジ、1回の測定数等である。また、温度センサにおけるサンプリングレート、アラームの上限及び下限等である。または、バッテリにおけるサンプリングレート、アラームの上限及び下限等である。そして、センサ素子1による測定結果は、例えば、橋脚における振動等である。
センサ制御装置10は、少なくとも1以上のセンサ素子1と接続される。そのため、センサ装置11は、センサ素子1を搭載したものといえる。センサ制御装置10は、記憶部1100と、制御部1200とを備える。記憶部1100は、複数のユーザプログラム1101、1102、・・・と、実行定義情報1110と、定時処理プログラム1120とを記憶する。
ユーザプログラム1101等のそれぞれは、センサ素子1に対して所定の設定を行い、当該設定に基づく測定結果を加工し、当該加工結果を外部装置2へ送信する一連の処理が実装されたコンピュータプログラムである。つまり、ユーザプログラム1101にはある一連の処理が実装され、ユーザプログラム1102には、ユーザプログラム1101とは異なる一連の処理が実装されていることになる。
実行定義情報1110は、複数のユーザプログラム1101等の間でそれぞれ異なる実行時間帯が定義された情報である。つまり、各実行時間帯の間で重複がないものとする。定時処理プログラム1120は、外部装置2から所定のメンテナンス情報を受信する処理と、当該メンテナンス情報に基づく処理とが実装されたコンピュータプログラムである。ここで、メンテナンス情報とは、センサ装置11に所定のメンテナンス処理を行うために用いられる情報である。メンテナンス情報としては、例えば、センサ装置11の起動時の初期設定の変更に関する情報、ファームウェアの更新プログラム、ユーザプログラムの更新プログラム等が挙げられるが、これらに限定されない。そして、メンテナンス情報に基づく処理とは、例えば、センサ装置11の初期設定の変更処理、ファームウェアの更新処理、ユーザプログラムの更新処理等である。
制御部1200は、実行定義情報1110に基づき、複数のユーザプログラム1101の中から実行時間帯の開始時刻が現在時刻となったユーザプログラムの実行を開始する。また、制御部1200は、実行定義情報1110に基づき複数のユーザプログラム1101等のうち第1のプログラムの実行中に、外部装置2から所定のメンテナンス情報を受信し、当該メンテナンス情報に基づく処理を実行する。すなわち、制御部1200は、第1のプログラムの実行中に、定時処理プログラム1120を並列実行する。
外部装置2は、ネットワーク等を介してセンサ装置11と通信可能なコンピュータ装置であるサーバ又はコンセントレータ等である。尚、本実施形態にかかるサーバやコンセントレータについては、後述する。
このように、本実施の形態では、1つのセンサ素子に対する設定、測定値の加工及び加工結果の送信までの一連の処理を1つのユーザプログラムに実装させ、センサ素子の利用目的ごとに異なる実装をさせた複数のユーザプログラムを用いる。そして、各ユーザプログラムには、異なる実行時間帯が定義されており、ある時刻においては2以上のユーザプログラムが実行されることはない。そのため、各ユーザプログラムはそれぞれ、センサ素子を占有することができる。つまり、各ユーザプログラムは実行時にセンサ素子に対する独自の設定を行い、その設定による測定結果に対して独自の加工を行い、加工結果を独自の送信先へ送信することができる。よって、他のユーザプログラムの設定やアルゴリズムの影響を受けずに、ユーザプログラムの実装内容を変更することができる。それ故、センサ素子を複数の目的で効率的に利用することができる。
図2は、実施の形態1にかかるセンサシステム1000の全体構成を示すブロック図である。尚、図2は、上述した図1の構成を含めて具体化したものである。センサシステム1000は、センサ装置11、12及び13と、コンセントレータ20と、センサ装置管理サーバ30と、エンドユーザ端末41、・・・4m(mは2以上の整数。)と、クラウドサービスサーバ51、・・・5n(nは2以上の整数。)とを備える。
センサ装置11〜13のそれぞれは、異なるセンサ素子が搭載され、有線又は無線によりコンセントレータ20と通信可能なコンピュータ装置である。尚、センサ装置11〜13は、少なくとも1以上であればよい。コンセントレータ20は、センサ装置11〜13と管理サーバ30との間のデータの転送を中継するコンピュータ装置である。コンセントレータ20は、クラウド接続可能な有線又は無線機器を内蔵しており、ネットワークNを介して管理サーバ30と通信が可能である。ここで、ネットワークNは、一般的なネットワークインフラ回線であり、例えば、インターネット等である。尚、コンセントレータ20は1つである必要はなく、センサ装置11等の設置の利用条件に合わせて複数のコンセントレータを用いてもよい。
管理サーバ30は、センサ装置11〜13並びにコンセントレータ20を管理するコンピュータ装置である。管理サーバ30は、ネットワークNを介してコンセントレータ20と、エンドユーザ端末41〜4m及びクラウドサービスサーバ51〜5nと通信を行う。尚、コンセントレータ20又はセンサ装置管理サーバ30は、上述した外部装置2に相当する。
ここで、センサ装置11〜13、コンセントレータ20及び管理サーバ30を管理及び運用する会社を管理会社とする。クラウドサービスサーバ51〜5nを運用する企業X1〜Xnのそれぞれは、管理会社と事前に契約し、管理会社から配布された認証鍵を受領済みとする。認証鍵は、例えば、1日のうちセンサ装置11等を占有できる時間帯(例えば、1時間単位)ごとに割り当てられた一意な情報である。そして、企業X1〜Xnのそれぞれは、センサ装置11〜13に搭載されたセンサ素子に対する自社の利用目的に基づいて、測定用の設定値、測定結果の加工処理、加工結果の自社サーバを宛先とした送信処理等を実装したユーザプログラムを開発させる。尚、認証鍵は、時間帯に限らず、ファームウェアや、初期設定の変更情報等にも割り当てられている。
その後、クラウドサービスサーバ51〜5nのそれぞれは、自社に配布された認証鍵及び時間帯(開始時刻)を付加した各ユーザプログラムを、管理サーバ30に対して送信、つまり、アップロードする。管理サーバ30は、クラウドサービスサーバ51〜5nのそれぞれから受信したユーザプログラムに付加された認証鍵と時間帯の組合せが適正か否かを判定する。そして、適正と判定した場合、管理サーバ30は、受信したユーザプログラム内に付加された認証鍵と時間帯の組合せを所定の記載方法で追記する。所定の記載方法とは、例えば、ユーザプログラムのプログラムコードの先頭に注釈行と解釈されるように、開始時刻と認証鍵を記載し、また、対象時刻外の認証鍵を空白として記載することが挙げられる。その後、管理サーバ30は、ユーザプログラムを、コンセントレータ20に転送する。コンセントレータ20は、転送されたユーザプログラムをセンサ装置11〜13に転送する。センサ装置11〜13のそれぞれは、転送されたユーザプログラムを記憶部に保存し、実行定義情報の一例である登録プログラムリスト内の、付加された開始時刻に対応する時間帯に、プログラムの保存先のアドレスを記入する。また、クラウドサービスサーバ51〜5nのそれぞれは、コンセントレータ20及び管理サーバ30を介して、センサ装置11等に関する各種情報を受信する。尚、管理サーバ30は、セキュリティ確保のため定期的又は不定期に認証鍵を更新する。その際、管理サーバ30は、クラウドサービスサーバ51〜5nのそれぞれに対して、契約した時間帯に対応する更新後の認証鍵を通知する。また、管理サーバ30は、各センサ装置に対して更新後の認証鍵を送信し、ユーザプログラム内の認証鍵の記載の書換え処理と、登録プログラムリスト内の認証鍵の記載の書換え処理とを指示する。
エンドユーザ端末41〜4mは、エンドユーザが操作する端末装置である。エンドユーザ端末41〜4mは、例えば、パーソナルコンピュータ、タブレット端末、又は、スマートフォン等が挙げられるが、これらに限定されない。また、エンドユーザは、企業X1〜Xnから提供される、センサ装置11等の測定結果からの加工結果(解析結果)に対して、対価を支払う企業又は個人である。エンドユーザ端末41〜4mは、クラウドサービスサーバ51〜5nから付与されたアクセス権限に基づき、管理サーバ30にアクセスし、各企業により提供されるデータの閲覧や、自社や個人の記憶媒体(ハードディスクドライブなど)にデータをダウンロードする。
図3は、実施の形態1にかかるセンサ装置11の構成を示すブロック図である。尚、センサ装置12及び13の構成は図3と同等であるため、図示及び説明を省略する。センサ装置11は、ソフトウェア層110とハードウェア層120の2階層に分けて説明できる。ハードウェア層120は、CPU(Central Processing Unit)121、RAM(Random Access Memory)122、ROM(Read Only Memory)123、シリアルI/F(InterFace)1241及び1242、ADC(Analog-to-Digital Converter)125、セキュアIP(Internet Protocol)126、RF(Radio Frequency)127、MEMS128及びアナログセンサ129を備える。ここで、RF127はシリアルI/F1241により、MEMS128はシリアルI/F1242により、アナログセンサ129はADC125により、それぞれセンサ装置11の本体と接続される。尚、接続されるセンサ素子は、測定対象物に応じて変更することができる。また、アナログセンサ129は、抵抗(R)や容量(C)の変化を出力するセンサ素子の一例である。
ソフトウェア層110は、ハードウェア層120の上層であり、オペレーティングシステム(Operating System)111、デバイスドライバ(Device Driver)112、パワーマネージャ(Power Manager)113、タスクマネージャ(Task Manager)114、セキュリティマネージャ(Security Manager)115、アプリケーション設定プログラム(Application set-up Program)1161、ネットワーク初期化プログラム(Network Initialization Program)1162、定時処理プログラム(Periodic Program)1163、ミドルウェア(Middleware)/インタプリタ(interpreter)1164、ユーザプログラム(User Program)11651、11652〜1165nを備える。デバイスドライバ112は、CPU121によりデバイスを制御するためのドライバである。デバイスドライバ112は、制御対象のセンサ素子により測定されたデータの取得処理、センサ素子の故障検出処理、センサ素子に対する設定値の設定処理等が実装されている。パワーマネージャ113、タスクマネージャ114及びセキュリティマネージャ115は、マネジメント処理層といえる。タスクマネージャ114やオペレーティングシステム111は、アプリケーション設定プログラム1161、ネットワーク初期化プログラム1162、定時処理プログラム1163及びミドルウェア/インタプリタ1164の実行を制御する。特に、タスクマネージャ114は、内蔵の時計により定期的に定時処理プログラム1163の実行を開始し、また、定期的に実行定義情報1110を参照して、ミドルウェア/インタプリタ1164上で実行するためのユーザプログラム11651〜1165nの選択及び実行の開始及び終了を行う。アプリケーション設定プログラム1161は、センサ装置11の起動時の初期設定等が実装されたプログラムである。アプリケーション設定プログラム1161は、装置セットアッププログラムと呼んでもよい。ネットワーク初期化プログラム1162は、センサ装置11がコンセントレータ20とのネットワークを確立するための処理等が実装されたプログラムである。定時処理プログラム1163は、上述した定時処理プログラム1120に相当する。具体的には、定時処理プログラム1163は、コンセントレータ20を介した管理サーバ30との時刻同期処理、センサ装置11の情報変更の有無の確認処理等が実装されている。ミドルウェア/インタプリタ1164は、ユーザプログラム11651〜1165nの実行を支援し、インタプリタ型の言語処理を行う。ユーザプログラム11651〜1165nのそれぞれは、最上層のアプリケーション層といえ、クラウドサービス企業が設計したセンサ装置の具体的な運用方法を記述したプログラムである。すなわち、ユーザプログラム11651〜1165nのそれぞれは、センサ素子に対する測定用の設定値の定義、センサ素子による測定結果の受信処理、測定結果(センサ情報)の加工処理(センサ情報の演算に必要な数値演算処理等)、通信フォーマットの定義、センサ情報を通信フォーマットに基づき変換して通信データを生成する処理等が、インタプリタ型の言語により実装されている。このように、ユーザプログラムをインタプリタ型とすることにより、CPUのアーキテクチャ依存性を無くし、複数のユーザプログラムがお互いに干渉しないように動作保障し、クラウドサービス会社のソフトウェア開発に対する開発環境の整備及びプログラミングスキル等に係る費用と時間を短縮することができる。
図4は、実施の形態1にかかるセンサ装置11のハードウェア構成を示すブロック図である。図4では電源線を明記している。センサ装置11は、センサ制御装置10の一例であるMCU(Micro Control Unit)100を備える。MCU100は、タイマ(Timer)101、セキュアIP126、リセット制御(Reset Control)102、ウォッチドッグタイマ(Watch Dog Timer)103、システム制御(System Control)104、インタラプト制御(Interrupt Control)105、データ転送制御(Data Transfer Control)106、RAM122、データメモリ(Data Memory)1231、CPU121、コードメモリ(Code Memory)1232、DSP(Digital Signal Processor)107、シリアルI/F1242、GPIO(General Purpose Input/Output)1091、ADC125、GPIO1092、シリアルI/F1241を備える。ここで、MEMS128はシリアルI/F1242により、センサ(Sensors)1291はGPIO1091及びADC125により、バッテリ(Battery)1292はADC125により、電圧レギュレータ(Voltage Regulator)1293はGPIO1092により、RF127はシリアルI/F1241により、それぞれMCU100と接続される。
MEMS128やアナログのセンサ1291は消費電力が小さいため、MCU100のGPIO1091ポートから電源供給が可能である。GPIO1091から直接電源を供給することで、センサ1291の電源ON/OFFを任意のタイミングで実施することができる。そのため、センサ装置11の低消費電力化が実現できる。一方で、電源供給能力の不足が懸念されるRF127に対しては、レギュレータの動作制御端子をMCU100から制御することを行い、センサ1291と同様に、不要なときにはOFFとすることを実施する。
図5は、実施の形態1にかかるコンセントレータ20の構成を示すブロック図である。コンセントレータ20は、ソフトウェア層210とハードウェア層220の2階層に分けて説明できる。ハードウェア層220は、CPU221、RAM/ROM222、シリアルI/F2241及び2242、Ether225、セキュアIP226、RF2271及び2272を備える。ここで、RF2271及び2272はシリアルI/F2241及び2242により、それぞれコンセントレータ20の本体と接続される。尚、RF2271及び2272は、無線機器の一例であり、少なくとも1以上であればよい。
ソフトウェア層210は、ハードウェア層220の上層であり、デバイスドライバ211、オペレーティングシステム212、ミドルウェア213、センサネットワーク管理及び伝送アプリ214を備える。オペレーティングシステム212、ミドルウェア213、並びに、センサネットワーク管理及び伝送アプリ214は、Ether225によるネットワークNとの接続(例えば、インターネット接続)を可能とする複数の通信ネットワーク間のブリッジ機能を実現する。尚、当該ブリッジ機能には、それぞれの通信ネットワークに対して高い応答性が求められることから、CPU221はマルチCPU構成であってもよい。
図6は、実施の形態1にかかる管理サーバ30の構成を示すブロック図である。管理サーバ30は、ソフトウェア層310とハードウェア層320の2階層に分けて説明できる。ハードウェア層320は、CPU321、RAM/ROM322、Ether323、シリアルI/F324、セキュアIP325、S−ATA(Serial ATA)326、ストレージ(Storage)327を備える。ここで、ストレージ327はS−ATA326により管理サーバ30の本体と接続される。セキュアIP325は、クラウドサービスサーバ51等から送信される情報に付加される認証鍵が適正なものかを判定及び支援する。
ソフトウェア層310は、ハードウェア層320の上層であり、デバイスドライバ311、オペレーティングシステム312、ミドルウェア313、センサ管理3141、ユーザ管理3142、・・・保守アプリ3143を備える。特に、センサ管理3141、ユーザ管理3142は、クラウドサービス企業とのやり取りを支援するためのアプリケーションソフトウェアである。また、保守アプリ3143は、管理会社がメンテナンスするための保守用ソフトウェアである。
図7は、実施の形態1にかかるセンサ装置11における1日の動作スケジュールの概念を示す図である。すなわち、図7は、上述した実行定義情報1110の定義内容の一例を概念的に示したものである。まず、定時処理プログラム1120は、毎日、0時0分0秒から23時0分0秒まで1時間おきに、つまり1日24回起動するようにスケジュールされている。尚、センサ装置11における定時処理プログラム1120の1回当たりの実行時間は1時間未満であるものとする。また、ユーザプログラム1101、1102、1103及び1104のそれぞれは、X1社の処理1、X2社の処理2、X3社の処理3及びX4社の処理4がそれぞれ実装されたプログラムである。そして、ユーザプログラム1101は毎日0時0分0秒に起動し、ユーザプログラム1102は毎日6時0分0秒に起動し、ユーザプログラム1103は毎日15時0分0秒に起動し、ユーザプログラム1104は毎日18時0分0秒に起動するようにスケジュールされている。つまり、ユーザプログラム1101は毎日0時から5時59分59秒までの実行時間帯、ユーザプログラム1102は毎日6時から14時59分59秒までの実行時間帯、ユーザプログラム1103は毎日15時から17時59分59秒までの実行時間帯、ユーザプログラム1104は毎日18時から23時59分59秒までの実行時間帯が、それぞれ割り当てられている。言い換えると、ユーザプログラム1101〜1104のそれぞれは、割り当てられた実行時間帯において、他のユーザプログラムに対して排他的な実行が保証される。そして、各ユーザプログラムは、センサ制御装置10に接続されたセンサ素子の設定及び測定結果と、センサ制御装置10の通信機器のリソースを占有することができる。そして、リソースの占有により、センサ素子から時系列で連続した測定結果を漏れなく取得できる。
図8は、実施の形態1にかかる登録プログラムリストの例を示す図である。尚、登録プログラムリストは、実行定義情報1110の一実施例である。登録プログラムリストは、ユーザプログラムの開始時刻、認証鍵及び実行アドレスを1つの組合せとして、0時から23時まで24回分が定義されている。尚、開始時刻は、「時間」のみで表現し、「分」及び「秒」は0分0秒で固定のため、省略している。認証鍵は、上述した認証情報の一例である。つまり、認証鍵は時間ごとに異なる値である。実行アドレスはセンサ制御装置10の記憶部内で各ユーザプログラムが保存されている保存先のアドレス情報である。尚、登録プログラムリストは、これに限定されない。つまり、開始時刻は時間単位である必要はなく、年月日を含む定義であっても、時分秒を含む定義であっても、開始時刻と終了時刻の対で定義しても構わない。但し、特定の時刻においては1つのユーザプログラムのみが定義されているものとする。
図9は、実施の形態1にかかるユーザプログラムの記載例を示す図である。まず、コード部P32は、センサ装置のユーザである企業等が実装するユーザプログラムの実装内容である。そして、コード部P31は、企業等からユーザプログラムを受け付けた管理サーバが適正と判断した場合に、管理サーバにより追記される内容である。コード部P31は、インタプリタ言語における注釈として記載される。この例では、コード部P31の各行の行頭に注釈として解釈される記号が記載され、続けて、開始時刻と認証鍵のペアを区切り記号(本例では<>)で囲って記載されていることを示す。尚、コード部P31の行数に制限はなく、当該ユーザプログラムの実行対象外の時間帯における認証鍵は無記入とされる。仮に、実行対象外の時間帯に不適正な認証鍵が記載されたとしても、適正な文字でないとしてエラー扱いとなり、センサ装置には登録されない。
図10は、実施の形態1にかかるセンサ装置11の起動後の状態遷移図である。図10を用いてセンサ装置11の動作について、起動から順を追って説明する。まず、センサ装置11はスイッチ(不図示)を搭載しており、ユーザがスイッチを切り替えることにより2つの起動モードのいずれかに設定される。スイッチは、例えば、メカニカルなスイッチであるディップスイッチや電気信号線を切り替えるジャンパースイッチなどを用いることができる。そして、2つの起動モードとしては、初期設定モードと、ネットワーク確立モードがある。初期設定モードは、センサ装置11が測定対象物に設置される前に設定される。一方、ネットワーク確立モードは、センサ装置11が実際に測定対象物に設置された後に設定される。まず、スイッチが初期設定モードに設定されている場合について説明する。
センサ装置11は、装置起動61によりスイッチの設定から起動モードを判定する。起動モードが初期設定モードの場合、センサ装置11は初期設定モード621へ移行し、アプリケーション設定プログラム1161(装置セットアッププログラムP1)を起動する。初期設定モード621において、センサ装置11は、センサ装置11を運用する際に必要なネットワーク情報やセンサ装置の初期設定、搭載ファームウェアのアップデートを行う。その後、センサ装置11は、装置テストモード622に移行する。装置テストモード622において、センサ装置11は、装置の設定が正しく行われたかを確認するため、疑似環境上にあるサーバと有線又は無線にて接続し、装置のテストを実施する。この場合、設定の正常系に対する試験のみならず、ネットワークがハッキングされた場合を想定し、無効な接続に対して排除又は無視する動作が正しく実行されるかを確認することができる。ネットワークがハッキングされた場合を想定した一連の動作は、サーバ側の端末からコマンド等を送信し人手を介して行ってもよい。または、テストプログラムにより一連の確認動作が自動で行われてもよい。装置テストモード622におけるテストに合格した場合、センサ装置11は装置停止モード623に移行し、センサ装置11を停止する。テストに不合格の場合、センサ装置11は不合格となった項目を通信ログデータと共にサーバへ送信する。これにより、メーカへの連絡用情報として扱うことができる。尚、センサ装置11は、サーバからのコマンドにより、初期設定モード621から装置テストモード622、そして、装置停止623へ移行してもよい。
一方、スイッチがネットワーク確立モードに設定されている場合、センサ装置11は、装置起動61により起動モードがネットワーク確立モードと判定し、ネットワーク確立モード63へ移行する。ネットワーク確立モード63において、センサ装置11は、ネットワーク初期化プログラム1162を起動する。そして、センサ装置11は、初期設定モード621にて設定されたネットワーク情報に基づいてネットワークに参加する手続きを行う。ネットワーク確立後、センサ装置11は、装置内の時計を設定するための時刻同期モード641に移行する。
センサ装置11は、起動後にタスクマネージャ114が実行され、各モードへの移行と、プログラムの起動を制御する。
図11は、実施の形態1にかかる定時処理プログラムの処理を示すフローチャートである。まず、時刻同期モード641において、センサ装置11は、定時処理プログラムP2を起動する(S111)。次に、センサ装置11は、ユーザプログラムが実行中の場合に、ユーザプログラムがコンセントレータ20と通信中又はセンサ素子が測定中であるかを判定する(S112)。通信中又は測定中である場合、センサ装置11は、一定時間待機し、再度ステップS112の判定を実行する。いずれのユーザプログラムも未実行であるか、通信中ではなく、かつ、測定中でもない場合に、ステップS113へ進む。尚、センサ装置11がネットワーク確立モード63から移行した場合には、いずれのユーザプログラムも未実行となる。また、ユーザプログラムが実行中であっても、測定結果の加工処理中等である場合には通信中ではなく、かつ、測定中でもない場合に該当する。
続いて、センサ装置11は、コンセントレータ20を介して管理サーバ30へ時刻問合せ要求を送信する(S113)。そして、センサ装置11は、管理サーバ30からコンセントレータ20を介して、管理サーバ30における現在の時刻情報と、場合によりメンテナンスモードへの移行指示とを含む応答メッセージを受信する。これにより、センサ装置11は、受信した時刻情報を内部の時計に設定し、管理サーバ30と時刻同期を行う。すなわち、前記制御部は、前記第1のプログラムの実行中において、前記センサ素子の動作中又は前記外部装置への送信中でない場合に、前記外部装置との間で時刻同期を行う。これにより、測定結果の測定時刻と加工結果の送信処理に影響を与えずに、センサ装置の時刻を正確にすることができる。
そして、センサ装置11は、受信した応答メッセージにメンテナンスモードへの移行指示が含まれるか否かを判定する(S114)。具体的には、応答メッセージ内にメンテナンスモードへの移行指示の有無を示すフラグ又はコマンドが含まれているものとする。移動指示が含まれる場合、センサ装置11は、メンテナンスモード642へ移行する。メンテナンスモード642での処理が終了した後、センサ装置11は、定時処理プログラムP2の実行を終了する(S117)。また、ステップS114において移動指示が含まれない場合、センサ装置11は、スケジューラモード65へ移行し(S116)、定時処理プログラムP2の実行を終了する(S117)。
メンテナンスモード642において、センサ装置11は、管理サーバ30から受信したメンテナンス情報に応じて、初期設定モードで設定された設定情報の変更、ユーザプログラムの更新、又は、センサ装置のファームウェアの更新等のメンテナンス処理を実行する。特に、メンテナンス情報には認証鍵が含まれており、センサ装置11は、メンテナンス情報を受信した場合に、管理サーバ30において検証させるために当該メンテナンス情報を管理サーバ30へ送り返し、管理サーバ30におけるメンテナンス情報の検証結果が正常である場合に、当該メンテナンス情報に基づく処理を実行する。これにより、ユーザプログラムの実行中であっても、検証されたメンテナンス情報に基づく処理を安全に並列実行することができる。以下、具体的に説明する。
図12は、実施の形態1にかかるセンサ装置側のメンテナンスモードの処理を示すフローチャートである。また、図13は、実施の形態1にかかる管理サーバ側のメンテナンスモードの処理を示すフローチャートである。以下では適宜、図12及び図13を参照して説明を行う。尚、以下の説明において、センサ装置11と管理サーバ30との送受信については、コンセントレータ20を経由する旨の記載は省略するものとする。
まず、センサ装置11は、メンテナンス情報の受信待ち状態である旨を示す受信待ちコードを管理サーバ30に対して送信する(S211)。尚、2回目以降のステップS211では、センサ装置11は、受信待ちコードに加えて、後述するステップS219の判定結果やステップS220のメンテナンス処理の正常終了通知である処理済みメンテナンスコード等を含めて、管理サーバ30へ送信してもよい。そして、センサ装置11は、一定時間、待機して、管理サーバ30からのメンテナンス情報の受信を待ち受ける(S212)。
また、図13において、管理サーバ30は、ステップS211に応じて、センサ装置11から受信待ちコードを受信する(S231)。そして、管理サーバ30は、センサ装置11がメンテナンス終了状態か否かを判定する(S232)。メンテナンス終了状態である場合には、ステップS232へ進み、センサ装置11にメンテナンスが必要であればステップS233へ進む。
この時点では、メンテナンス情報が未送信のため、管理サーバ30は、未処理のメンテナンス処理を抽出する(S233)。そして、管理サーバ30は、メンテナンス事項が存在するか否かを判定する(S234)。例えば、管理会社においてセンサ装置11の初期設定の変更内容やファームウェアの更新プログラムの登録がされていた場合、企業X1等からユーザプログラムの更新プログラムが登録されている場合、又は、更新用の認証鍵が登録されている場合には、メンテナンス事項が存在することになる。メンテナンス事項が存在する場合、管理サーバ30は、抽出されたメンテナンス処理データをメンテナンス情報としてセンサ装置11へ送信する(S235)。このとき、送信されるメンテナンス情報には、認証鍵が含まれていることになる。特に、メンテナンス情報がユーザプログラムの更新プログラムである場合には、該当する複数の開始時刻及び各開始時刻に対応する複数の認証鍵の組合せが、上述の通りユーザプログラム内の所定の領域に記載されている。
図12のセンサ装置11の処理に戻り、センサ装置11は、管理サーバ30からデータを受信したか否かを判定する(S212)。受信していない場合、センサ装置11は、待機時間が一定時間を超えたか、つまり、メンテナンスモードのタイムアップか否かを判定する(S213)。尚、待機時間の上限値は、例えば5分間である。但し、ネットワークの管理や設定環境や同一ネットワーク上のセンサ装置の個数等の理由によるユーザからの指示等により、センサ装置11は、初期設定やメンテナンスモードにて待機時間の上限値を変更できるものとする。タイムアップではない場合、ステップS212へ戻る。タイムアップである場合、センサ装置11は、タイムアップが3回連続か否かを判定する(S214)。つまり、センサ装置11は、ステップS212でデータ受信をせずに、ステップS211が3回連続で実行され、都度、ステップS213でタイムアップとなったかを判定する。タイムアップが1回又は2回連続までの場合、ステップS211へ戻る。一方、タイムアップが3回連続である場合、ステップS221へ進む。
また、ステップS212において、管理サーバ30からメンテナンス情報を受信した場合、センサ装置11は、受信したデータの内容分析を行い(S215)、受信したデータがメンテナンス終了指示であるか否かを判定する(S216)。メンテナンス終了指示である場合、ステップS221へ進む。尚、メンテナンス終了指示は、スケジューラモードへの移行指示であってもよい。
一方、メンテナンス終了指示でない場合、センサ装置11は、受信したデータのエコーバックを行う(S217)。つまり、センサ装置11は、受信したメンテナンス情報をそのまま管理サーバ30へ送り返す。
そして、図13において管理サーバ30は、エコーバックデータを受信し、エコーバックデータのベリファイを行い(S236)、ベリファイ結果が適正か否かを判定する(S237)。ベリファイ結果が不適正である場合、管理サーバ30は、センサ装置11へ不適正通知を送信する(S238)。一方、ベリファイ結果が適正である場合、管理サーバ30は、センサ装置11へ適正通知を送信し(S239)、当該メンテナンス事項を未処理のメンテナンス処理から削除する(S240)。ステップS238又はS240の後、ステップS231へ戻る。また、図12においてセンサ装置11は、管理サーバ30からベリファイ結果を受信し(S218)、ベリファイ結果が適正か否かを判定する(S219)。ベリファイ結果が適正である場合、センサ装置11は、メンテナンス処理を実行する(S220)。尚、メンテナンス処理については、後述する。
ステップS219でベリファイ結果が不適正である場合、又は、ステップS220の後、ステップS211へ戻り、センサ装置11は、再度、受信待ちコードを管理サーバ30へ送信する。ここでは、2回目のステップS211であるため、センサ装置11は、上述したように受信待ちコードに加えて、ステップS219の判定結果やステップS220のメンテナンス処理の正常終了通知である処理済みメンテナンスコード等を含めて、管理サーバ30へ送信してもよい。
そして、図13のステップS232でメンテナンス終了状態ではなく、メンテナンス事項がある場合(S234でYES)には、管理サーバ30は、別のメンテナンス情報をセンサ装置11へ送信し、上述の通り以降の処理を実行する。そして、センサ装置11は、別のメンテナンス情報を受信した場合には、続けてメンテナンス処理を実行する。一方、管理サーバ30においてメンテナンス事項がない場合(S234でNO)、又は、ステップS232でメンテナンス終了状態である場合、センサ装置11に対してメンテナンスモード終了コードを送信する(S241)。そして、図12においてセンサ装置11は、メンテナンスモード終了コードを受信し(S212でYES)、メンテナンス終了指示であると判定し(S216でYES)、ステップS221へ進む。そして、センサ装置11は、メンテナンスモード終了通知を管理サーバ30へ送信する(S221)。そして、センサ装置11は、メンテナンスモード処理を終了し、スケジューラモード65へ移行する。また、図13において管理サーバ30は、センサ装置11からメンテナンスモード終了通知を受信し(S242でYES)、メンテナンスモードを終了する。但し、ステップS242において管理サーバ30は、メンテナンスモード終了通知を受信できない場合、タイムアップか否かを判定し(S243)、タイムアップではない場合、ステップS241へ戻る。タイムアップである場合、管理サーバ30は、タイムアップが3回連続か否かを判定し(S244)、タイムアップが1回又は2回連続までの場合、ステップS241へ戻る。一方、タイムアップが3回連続である場合、管理サーバ30は、メンテナンスモードを終了する。
ここで、上述したメンテナンス処理は、上述した「メンテナンス情報に基づく処理」に相当し、例えば、センサ装置11の初期設定の変更処理、ファームウェアの更新処理、ユーザプログラムの更新処理、認証鍵の変更処理等である。まず、メンテナンス処理がセンサ装置11の初期設定の変更処理の場合、メンテナンス情報には、センサ装置11の初期設定の変更内容が含まれている。そして、センサ装置11は、変更処理が実行可能な場合に、初期設定の値を変更内容へ更新する。そして、必要に応じて、センサ装置11は、装置テストやネットワーク確立等を行う。そのため、当該変更処理には、アプリケーション設定プログラム1161及びネットワーク初期化プログラム1162の一部を用いても構わない。
また、メンテナンス処理がファームウェアの更新処理の場合、メンテナンス情報には、ファームウェアの更新プログラムが含まれている。そして、センサ装置11は、現在のファームウェアとは別の記憶領域に更新プログラムを保存する。センサ装置11は、ファームウェアの更新処理が実行可能な場合に、現在のファームウェアを更新プログラムに差し替えて実行させる。
また、メンテナンス処理が認証鍵の変更処理の場合、メンテナンス情報には、変更用の認証鍵と開始時刻の組合せが含まれている。そして、センサ装置11は、登録プログラムリスト内の該当する開始時刻に対応付けて記載されている認証鍵をメンテナンス情報に含まれる変更用の認証鍵に書き換える。併せて、センサ装置11は、登録プログラムリスト内の該当する開始時刻に対応付けて記載されている実行アドレスに格納されているユーザプログラム内の該当する開始時刻に対応付けて記載されている認証鍵も変更用の認証鍵に書き換える。
また、メンテナンス処理がユーザプログラムの更新処理である場合、メンテナンス情報には、ユーザプログラムの更新プログラムが含まれている。そして、更新プログラム内の所定の領域に開始時刻及び認証鍵の組合せが記載されている。そして、センサ装置11は、既存のユーザプログラムとは別の記憶領域に更新プログラムを保存する。そして、センサ装置11は、登録プログラムリスト内から、更新プログラム内の開始時刻及び認証鍵の組合せと一致する開始時刻及び認証鍵の組合せを検索する。その後、センサ装置11は、登録プログラムリスト内で検索された開始時刻及び認証鍵の組合せに対応する実行アドレスを、当該更新プログラムの保存先のアドレスに書き換える。尚、この場合、センサ装置11は、プログラム更新モード643に移行し、更新後にメンテナンスモード642へ戻る。
言い換えると、前記制御部は、第1のプログラムの実行中に、複数のプログラムのうち第2のプログラムに対する更新プログラムをメンテナンス情報として管理サーバ30から受信し、当該更新プログラムを記憶部に追加して格納し、前記実行定義情報に基づく前記第2のプログラムの実行開始時に、当該第2のプログラムの代わりに前記更新プログラムの実行を開始する。これにより、ユーザプログラムの実行中であっても、他のユーザプログラムの更新を安全に行い、更新プログラムを適切に実行することができる。
そして、前記実行定義情報は、前記記憶部内の各プログラムの保存先を実行アドレスとして含み、前記制御部は、前記複数のプログラムのそれぞれの前記実行時間帯の開始時刻に、各開始時刻に対応する前記実行アドレスに保存されたプログラムの実行を開始し、前記実行定義情報内の前記第2のプログラムにおける実行アドレスを前記更新プログラムの保存先に書き換え、前記第2のプログラムにおける前記実行時間帯の開始時刻において、前記実行定義情報を参照して、前記第2のプログラムにおける実行アドレスから前記更新プログラムを読み出して実行を開始するとよい。これにより、実行中のユーザプログラムに影響を与えずに、他のユーザプログラムの参照先を適切に更新することができる。
または、前記制御部は、前記第1のプログラムの実行中に、前記第1のプログラムに対する更新プログラムを前記メンテナンス情報として前記外部装置から受信し、当該更新プログラムを前記記憶部内の前記第1のプログラム以外の保存先に保存し、前記第1のプログラムの実行終了後、前記実行定義情報に基づき再実行を開始する際に、当該第1のプログラムの代わりに前記更新プログラムの実行を開始する。これにより、実行中のユーザプログラムの更新プログラムを受信したとしても、安全に受け付けて、次回の実行時には、適切に更新プログラムを実行することができる。
ここで、現在のメンテナンスモード642が後述するスケジューラモード65に移行する前である場合、つまり、ネットワーク確立モード63から(時刻同期モード641を経由して)移行しただけである場合には、この時点ではユーザプログラムが未実行である。また、現在のメンテナンスモード642がスケジューラモード65から(時刻同期モード641を経由して)移行してきた場合には、ユーザプログラムが実行中である。そこで、ユーザプログラムが未実行であれば、上述した「変更処理」又は「ファームウェアの更新処理」が「実行可能な場合」に相当し、メンテナンス処理としては、初期設定の変更処理、ファームウェアの更新処理、認証鍵の変更処理、ユーザプログラムの更新処理のいずれも実行可能である。
一方、ユーザプログラムが実行中であれば、初期設定の変更処理及びファームウェアの更新処理は保留し、センサ装置11の再起動を行う。例えば、現在実行中のユーザプログラムが終了するまで待機し、終了後にセンサ装置11を再起動する。そのため、次のようにしてもよい。すなわち、前記メンテナンス情報は、前記センサ制御装置の設定情報を含み、前記制御部は、前記記憶部内の前記センサ制御装置の再起動時に初期設定として読み出される領域に、前記受信したメンテナンス情報を保存するようにしてもよい。または、前記メンテナンス情報は、前記センサ制御装置のファームウェアの更新プログラムを含み、前記制御部は、前記記憶部内の前記センサ装置の前記ファームウェアの更新領域に、前記受信した更新プログラムを保存し、前記センサ制御装置の再起動時に、前記更新領域に保存された更新プログラムにより前記ファームウェアを更新するようにしてもよい。これらにより、実行中のユーザプログラムの動作に影響を与えずに、安全にメンテナンス処理を実行できる。
続いて、スケジューラモード65について説明する。まず、センサ装置11は、時刻同期モード641又はメンテナンスモード642からスケジューラモード65に移行する。そして、センサ装置11は、定期的に定時処理プログラムP2を起動して時刻同期モード641へ移行し、並行して、実行定義情報1110に基づいてユーザプログラムP3を起動してユーザプログラム実行モード66へ移行する。これらの制御は、上述の通りタスクマネージャ114により行われる。
言い換えると、前記記憶部は、前記外部装置から前記所定のメンテナンス情報を受信する処理と、当該メンテナンス情報に基づく処理とが実装された定時処理プログラムをさらに記憶し、前記制御部は、前記実行定義情報に基づき前記複数のプログラムのいずれかの実行を開始すると共に、所定の間隔で前記定時処理プログラムの実行を開始する。これにより、センサ素子による測定やユーザプログラムの加工処理等を停止することなく、メンテナンス処理を実行できる。
図14は、実施の形態1にかかるタスクマネージャによるユーザプログラムと定時処理プログラムの並列実行処理を示すフローチャートである。まず、タスクマネージャ114は、定時であるか否かを判定する(S11)。例えば、タスクマネージャ114は、内蔵のタイマにより現在時刻が任意の時間の0分0秒となったか否かを判定する。定時である場合、タスクマネージャ114は、定時処理プログラムP2の起動処理を行う(S12)。具体的には、上述した図11の処理を実行する。
これと並行して、タスクマネージャ114は、実行定義情報1110を参照し、現在時刻が開始時刻として登録されているか否かを判定する(S13)。具体的には、登録プログラムリストには上述したように開始時間のみが登録されているため、タスクマネージャ114は、内蔵のタイマにより現在時刻が任意の時間の0分0秒であり、該当する時間が登録プログラムリストに存在するか否かを判定する。開始時刻である場合、タスクマネージャ114は、現在時刻に該当するユーザプログラムP3の起動処理を行う(S14)。具体的には、以下の図15の処理を行う。
図15は、実施の形態1にかかるユーザプログラムの起動処理を示すフローチャートである。まず、タスクマネージャ114は、登録プログラムリストの該当する時間に対応して記載された認証鍵が適正であるか否かを判定する(S311)。例えば、センサ装置11は、登録プログラムリスト内の該当する開始時刻と認証鍵の組合せと、対応する実行アドレスに存在するユーザプログラム内の開始時刻と認証鍵の組合せとの照合を行うことで判定する。認証鍵が不適正である場合、タスクマネージャ114は、登録プログラムリストの該当する開始時刻及び認証鍵に対応して記載された実行アドレスを削除し(S314)、スタンバイモードへ移行する(S315)。尚、ステップS317において、センサ装置11は、内部の各デバイスへの電力の供給を停止し、MCU100は、待機電力を抑えたスタンバイモードへ移行する。スタンバイモードへ移行後、定時刻となった場合に、センサ装置11は、スケジューラモード65へ移行する。
ステップS311で認証鍵が適正と判定した場合、タスクマネージャ114は、登録プログラムリストの該当する開始時刻に対応して記載された実行アドレスに保存されたユーザプログラムを、データメモリ1231から読み出して実行を開始する(S312)。その後、センサ装置11は、スケジューラモード65へ移行する(S313)。
上述したことから、前記実行定義情報には、前記複数のプログラムの各実行時間帯に対応する認証情報が含まれ、前記制御部は、前記複数のプログラムのそれぞれの前記実行時間帯の開始時刻に、対応する前記認証情報の検証を行い、検証結果が正常である場合に、当該開始時刻におけるプログラムの実行を開始する、といえる。これにより、センサ装置に更新プログラムが登録後に、改竄等された場合でも、検出して不正なプログラムの実行を排除できる。
ここで、上述したように各ユーザプログラムはインタプリタ言語で記述され、ミドルウェア/インタプリタ1164によりユーザプログラムの先頭から順次解釈されて実行される。ここで、ユーザプログラムには、(1)センサ素子に対する測定レンジやサンプリングレート、1回の測定数、アラームの上限値又は下限値などのパラメータ情報の定義、(2)センサ素子の測定結果を取得する処理、(3)測定結果の演算及び比較等の加工処理等、(4)通信フォーマットの定義、(5)加工結果を通信フォーマットに基づき変換して通信データを生成する処理、(6)通信データを管理サーバ30へ送信する処理等が実装されている。尚、上記(1)には、センサ制御装置10における確保すべきメモリ領域、データベース領域の指定値をさらに含めてもよい。
図16は、実施の形態1にかかるユーザプログラムの処理を示すフローチャートである。まず、センサ装置11は、デバイスドライバ112によりユーザプログラムに定義されたパラメータ情報をセンサ素子に設定する(S410)。次に、センサ装置11は、現在時刻が本ユーザプログラムの終了時刻に達したか否かを判定する(S411)。すなわち、センサ装置11は、タイマから現在時刻を取得し、登録プログラムリスト内の開始時刻のうち現在時刻に該当する時刻の実行アドレスを特定し、特定した実行アドレスと本ユーザプログラムの実行アドレスとが異なる場合には、次の実行時間帯に他のユーザプログラムが定義されているため、本ユーザプログラムの終了時刻に達したと判定する。その場合、センサ装置11は、本ユーザプログラムの実行を終了する。そして、センサ装置11は、スケジューラモード65へ移行する。
一方、本ユーザプログラムの終了時刻に達していない場合、センサ装置11は、センサ素子による測定データが存在するか否かを判定する(S412)。ここで、センサ素子は、ステップS410のパラメータ設定により測定を行い、測定データを内部のメモリ等に保持する。そして、センサ装置11は、センサ素子の測定データの有無を確認する。尚、パラメータ設定には、測定間隔も含まれる。よって、測定間隔次第では、ステップS412で測定データが存在しない場合がある(S412でNO)。その場合、一定時間、待機後、再度、ステップS412を実行する。特に、複数の時刻の測定データをまとめて解析及び加工を行う場合には、必要な量の測定データが蓄積されるまで、ステップS410後から一定時間を要する。
ステップS412で必要な量の測定データが蓄積されたと判定した場合、センサ装置11は、センサ素子のドライバプログラム(デバイスドライバ112)を呼び出して、測定データを取得し、記憶領域に保存する(S413)。
図17は、実施の形態1にかかるセンサ素子のドライバプログラムの処理を示すフローチャートである。まず、センサ装置11は、ユーザプログラムからの呼び出しに応じてドライバプログラムを起動する(S421)。そして、センサ装置11は、ドライバプログラムによりセンサ素子から測定データを取得する(S422)。続いて、センサ装置11は、ドライバプログラムによりセンサ素子の状態を確認する(S423)。例えば、センサ装置11は、取得した測定データの最大及び最小値の比較処理や、連続して同値が存在するかの検査処理等をドライバプログラムにより実行する。そして、ドライバプログラムにより異常が検出された場合、センサ装置11は、宛先アドレスを管理サーバ30として異常を検出した情報を送信し、管理会社へ通達する。一方、ステップS423によりセンサ素子の状態が正常であると確認できた場合には、センサ装置11は、ドライバプログラムにより呼び出し元のユーザプログラムへ測定データを転送する(S424)。
図16に戻り説明を続ける。センサ装置11は、取得した測定データに対して所定の加工処理を行う(S414)。所定の加工処理としては、例えば、数値演算、周波数変換、ピーク検出、比較処理等である。そして、センサ装置11は、加工処理の結果、送信の必要性があるか否かを判定する(S415)。送信の必要性がある場合、センサ装置11は、ユーザプログラム内に定義した通信フォーマットに基づいて、加工結果を変換して通信データを生成する(S416)。そして、センサ装置11は、生成した通信データを管理サーバ30に向けて送信する(S417)。ステップS417の後、又は、ステップS415にて送信の必要性がない場合、ステップS410へ戻る。
このように、本実施の形態では、1つのセンサ装置内で同じ時間帯に動作するユーザプログラムは、スケジューラ(例えば、タスクマネージャ114)によりただ1つ選択される。また、ユーザ(企業X1等)がセンサ素子の利用のために割り当てられている時間帯における測定用のパラメータは、当該ユーザが作成するユーザプログラムにより任意に設定可能であり、他のユーザプログラムの設定には依存しない。さらに、実行中のユーザプログラムは、終了時刻に達するまで停止されることがないため、その間のセンサ素子からの情報取得や加工結果の通信処理は止まることなく継続することができる。
ここで、ステップS423のセンサデイバスの状態確認処理について補足する。特に、センサ素子が故障した場合には、特徴的なデータ出力がある。例えば、同一の値又は周期性をもって同じ値が繰り返し出力される場合がある。ここで、センサ素子はデジタル値を出力するものが増えてきたが、センサ素子の内部ではアナログの出力である。そのため、センサ素子から出力されるデジタル値は、アナログデジタル変換された情報に過ぎない。よって、測定データがある周期をもって同じ値が繰り返されるというのは現実的ではないといえる。
また、センサ素子の故障を判定するためには、最大値及び最小値を監視することも有効な手段である。設定した測定レンジに対して最大値が上回ること、もしくは、最小値を下回ること、または、上限値以下にならない、もしくは、下限値以上にならないなどは異常と判断しても良い場合が多い。本実施形態にかかるセンサ装置の故障検出は、センサ素子とのインターフェイスのドライバプログラムにより実現される。これにより、ユーザプログラムの動作への影響を排除できる。
続いて、図18を用いてコンセントレータ20及び管理サーバ30の役割を説明する。図18は、実施の形態1にかかるセンサシステム1000の情報の流れの概略を示す図である。コンセントレータ20は、図18に示すように次の3つの役割がある。
(1−1)管理サーバ30から各センサ装置11〜13への情報の転送制御
(1−2)センサ装置11〜13からクラウドサービスサーバ51〜5nへの情報の転送制御
(1−3)センサ装置11〜13から管理サーバ30へセンサ素子の異常通知の転送制御
尚、それぞれの転送において、ネットワークNのマルチホッピングや送信に対する応答メッセージの流れは省略する。
(1−1)センサ装置11〜13への情報の転送制御においては、コンセントレータ20は、管理サーバ30から各センサ装置への指示を一時的に保存する。また、コンセントレータ20は、各センサ装置から定時処理としての時刻問い合わせ要求を受信した場合、前記一時的に保存された指示を要求元のセンサ装置へ返信する。尚、コンセントレータ20は、センサ装置に情報を転送する前に同一センサ装置への転送情報の内容が更新された場合、古いものは破棄し、新しいものだけを転送する。
(1−2)センサ装置11〜13からクラウドサービスサーバ51〜5nへの情報(通信データ)の転送制御においては、コンセントレータ20は、各センサ装置が測定結果の加工及び圧縮等を行った通信データを受信し、通信データに指定された宛先アドレスを参照して宛先のクラウドサービスサーバを特定し、特定したクラウドサービスサーバへ通信データを転送する。
(1−3)センサ装置11〜13から管理サーバ30へセンサ素子の異常通知の転送制御においては、コンセントレータ20は、各センサ装置からセンサ素子やセンサ装置の異常通知を受信した場合に、管理サーバ30へ当該異常通知を転送する。
管理サーバ30は、図18に示すように次の3つの役割がある。
(2−1)ユーザであるクラウドサービス企業からユーザプログラムを受付
(2−2)コンセントレータ20を介してセンサ装置11〜13にユーザプログラムを配信
(2−3)センサ装置11〜13から異常通知を受け付け、管理会社へ通達
(2−1)ユーザプログラムは、センサ制御装置及びセンサ素子の制御用プログラムである。管理サーバ30は、例えば、企業X1のクラウドサービスサーバ51から企業X1の利用目的のために開発されたユーザプログラムをネットワークNを介して受信する。ここで、管理サーバ30は、センサ素子の利用を占有できる時間帯に対応する認証鍵を、企業X1に対して事前に配布済みである。そのため、クラウドサービスサーバ51は、送信対象のユーザプログラムに認証鍵及び利用する時間帯(開始時刻等)を付加して管理サーバ30へ送信する。管理サーバ30は、受信したユーザプログラムに付加された開始時刻における認証鍵の検証及びユーザプログラムの動作の妥当性の検証を実施する。そして、受信したユーザプログラムが不正又は不適切である場合には、管理サーバ30は、受信したユーザプログラムを破棄する。また、受信したユーザプログラムが適正である場合、管理サーバ30は、受信したユーザプログラムの所定の領域に、付加された開始時刻及び認証鍵の組合せを書き込む。
(2−2)管理サーバ30は、コンセントレータ20を介してセンサ装置11〜13にユーザプログラムを配信する。但し、配信時にコンセントレータ20が通信データの転送中であるか、異常通知の転送中等である場合には、管理サーバ30は、ユーザプログラムの配信を待機し、コンセントレータ20における転送処理を優先させる。また、センサ装置11〜13に配信したユーザプログラムがエコーバックのために送り返された場合、管理サーバ30は、当該ユーザプログラム内に記載された開始時刻における認証鍵のベリファイを行い、ベリファイ結果を返信する。これにより、ベリファイ結果が不適正な場合、占有時間外の認証鍵によるユーザプログラムをセンサ装置11等から削除させることができる。
(2−3)センサ装置11等からコンセントレータ20を介して異常通知を受け付けた場合、管理サーバ30は、自身のメール機能等を用いて管理会社の特定の管理者又はメーリングリストへメール配信し、異常を通知する。また、管理サーバ30は、異常通知の内容をウェブブラウザ上で閲覧させることも可能とする。これにより、管理者による異常状態の把握を支援できる。
これらにより、クラウドサービスを提供する各企業は、従来のサービス内容を変えることなく、最終受益者であるエンドユーザに対してデータの閲覧やダウンロードサービスを提供することができる。
このように、本実施の形態では、クラウドサービスを提供する企業のサーバとは別に、センサ装置を管理するための管理サーバを設けることと、センサ装置のスケジューラモードにて管理サーバとの連携により定時処理の実施、センサ装置の設定やプログラム更新及び不正排除機能、ユーザプログラムを排他的に実行する機能を持たせたものである。
これらの構成により、複数の利用目的によるユーザプログラムを共存することができ、上述した課題を解決可能となる。さらに、他のユーザプログラムに影響を与えることなく、センサ装置上のユーザプログラムの書き換えが可能である。また、測定データの加工処理のアルゴリズムを他のユーザに対して非公開にできる。さらに、低コストと低消費電力を両立し、センサデバイスにおける測定データの欠損がなく情報を取得して、データの加工が可能となる。
<実施の形態2>
本実施の形態2は、上述した実施の形態1の変形例である。図19は、実施の形態2にかかるセンサシステム2000の全体構成を示すブロック図である。センサシステム2000は、上述したセンサシステム1000全体においてコンセントレータ20が1台のみである場合に、管理サーバ30とコンセントレータ20と一体型としたコンセントレータ兼管理サーバ60に置き換えたものである。その他の構成及びセンサ装置11等の動作については、実施の形態1と同様であるため説明を省略する。
図20は、実施の形態2にかかるセンサシステム2000の情報の流れの概略を示す図である。コンセントレータ兼管理サーバ60は、図20に示すように次の4つの役割がある。
(3−1)ユーザであるクラウドサービス企業からユーザプログラムを受付
(3−2)センサ装置11〜13にユーザプログラムを配信
(3−3)センサ装置11〜13からクラウドサービスサーバ51〜5nへの情報の転送制御
(3−4)センサ装置11〜13から異常通知を受け付け、管理会社へ通達
ここで、上述した実施の形態1と同様に、それぞれの転送において、ネットワークNのマルチホッピングや送信に対する応答メッセージの流れは省略する。
(3−1)コンセントレータ兼管理サーバ60は、上記(2−1)と同様に、各企業のクラウドサービスサーバ51〜5nから、各企業のユーザプログラム及び認証鍵及び開始時刻を受け付け、各種検証を行い、不正又は不適切な場合には、受信したユーザプログラムを破棄する。また、受信したユーザプログラムが適正である場合、コンセントレータ兼管理サーバ60は、受信したユーザプログラムの所定の領域に、付加された開始時刻及び認証鍵の組合せを書き込む。
(3−2)コンセントレータ兼管理サーバ60は、上記(2−2)及び(1−1)をまとめて実現すべく、直接、センサ装置11〜13へユーザプログラムを配信する。
(3−3)コンセントレータ兼管理サーバ60は、上記(1−2)と同様に、宛先のクラウドサービスサーバへ通信データを転送する。
(3−4)コンセントレータ兼管理サーバ60は、上記(2−3)及び(1−3)をまとめて実現すべく、直接、特定の管理者又はメーリングリストへメール配信する。
これらにより、本実施の形態2は、上述した実施の形態1と同様の効果に加え、システム運用の簡素化、並びに、設置費用及び運転費用を抑制するという効果を奏する。
<実施の形態3>
本実施の形態3は、上述した実施の形態1又は2の一実施例であり、橋梁監視システムに関するものである。図21は、実施の形態3にかかる橋梁監視システム3000の全体構成を示すブロック図である。橋梁監視システム3000は、橋梁71及び橋脚72と、橋梁71を通過する車両73及び74を監視するための情報システムである。橋梁監視システム3000は、センサ装置11a及び11bと、コンセントレータ20aと、管理サーバ30aとを備える。
センサ装置11a及び11bは、上述したセンサ装置11等の一例である。センサ装置11aは少なくとも1つのセンサ素子1a及びセンサ素子1aと接続されるセンサ制御装置を搭載し、センサ装置11bは少なくとも1つのセンサ素子1b及びセンサ素子1bと接続されるセンサ制御装置を搭載する。センサ装置11a及び11bは、いずれか一方でも、又は、3以上で合っても構わない。センサ装置11a及び11bは、橋梁71に設置されたものであるが、橋脚72に設置しても構わない。センサ素子1a及びセンサ素子1bは、上述したセンサ素子1の一例であり、橋梁71又は橋脚72を監視するためのものである。尚、センサ装置11a及び11bの設置場所は、これに限定されず、例えば橋梁71上で車両73及び74の走行に影響を与えない場所等であってもよい。
コンセントレータ20aは、上述したコンセントレータ20の一例であり、センサ装置11a及び11bと管理サーバ30aとの間の無線又有線通信によるデータ転送を制御する。管理サーバ30aは、上述した管理サーバ30の一例であり、コンセントレータ20aからのデータの送受信と、ネットワークNを介したクラウドサービスサーバ51〜5n並びにエンドユーザ端末41〜4mとのデータ送受信を行う。尚、コンセントレータ20aは、ネットワークNを介してクラウドサービスサーバ51〜5n等と通信可能であってもよい。又は、コンセントレータ20aと管理サーバ30aとは一体としてもよい。
センサ装置11a及び11bは同等の構成であるため、以下では代表してセンサ装置11aについて説明する。センサ装置11aが備えるセンサ制御装置は、記憶部と制御部を備える。前記記憶部は、第1のユーザ(例えば、クラウドサービスサーバ51を運営する企業)により提供された第1のユーザプログラムと、第2のユーザ(例えば、クラウドサービスサーバ5nを運営する企業)により提供された第2のユーザプログラムと、第1のユーザプログラム及び第2のユーザプログラムについて異なる実行時間帯が定義された実行定義情報と、センサ装置11aに関する処理を実行する定時処理プログラムと、を記憶する。前記制御部は、前記実行定義情報に基づき前記第1のプログラム又は前記第2のプログラムのいずれかを実行し、定期的に前記定時処理プログラムを実行する。
ここで、前記制御部は、前記第1のプログラムの実行により、前記センサ素子に対して第1の設定値による設定を行い、当該第1の設定値による測定結果を加工し、当該加工結果を前記第1のユーザ宛として前記サーバへ送信する。そして、前記制御部は、前記第1のプログラムの実行終了後、前記第2のプログラムの実行により、前記センサ素子に対して第2の設定値による設定を行い、当該第2の設定値による測定結果を加工し、当該加工結果を前記第2のユーザ宛として前記サーバへ送信する。さらに、前記制御部は、前記第1のプログラム又は前記第2のプログラムの実行中に起動される前記定時処理プログラムにより、前記サーバから所定のメンテナンス情報を受信し、当該メンテナンス情報に基づく処理を実行する
このように、本実施の形態にかかる橋梁監視システム3000は、上述した実施の形態1又は2と同等の効果を奏するものである。
また、本実施の形態3を例にして、実施の形態1及び2を含めた効果について詳述する。現状、橋梁や橋脚の状態監視のために、センサ素子を搭載したセンサ装置が設置されている。この場合、センサ素子として加速度センサを用いることがある。そして、橋の上を車両が通過したときに発生する振動を加速度センサにより測定することで、固有振動数の変化を監視することができる。
ここで、車両の重量により橋梁の振幅は異なるが、周波数は橋の構造により定まる。つまり、橋梁の固有振動数は、橋梁の長さという構造により定まる値である。そのため、仮に橋梁にクラック等のひび割れが発生した場合には構造が変化するため、測定される固有振動数にも変化が生じる。それ故、橋梁についてセンサ素子により振動を測定し、長期間の固有振動数の変化を監視することで、橋梁の異常を検出することができる。
図22は、加速度センサによる橋梁の監視の概念を説明する図である。まず、処理1のセンシングでは、加速度センサにより取得される加速度情報をサンプリングする。つまり、加速度センサにより計測時刻ごとの加速度を測定する。次に、処理2の解析及び検出では、処理1の測定結果に対してフーリエ変換を行い、周波数と強度の関係を導き、強度のピークを検出する。このとき、必要に応じて周波数変換を行う。そして、処理3の比較及び簡易診断では、センサの着目データについて注意レベル又は警告レベルのそれぞれと比較し、強度のピークが注意レベル又は警告レベルのそれぞれを超えているか否かを判定し、超えている場合には、アラーム(注意通知又は警告通知)を行う。
上述のように現状では、橋梁の固有振動数をモニタリングすること、つまり、橋梁又は橋脚の状態監視(健康診断)という目的で、加速度センサというセンサ素子を利用することができる。
また、加速度センサは、橋梁に対して別の目的でも利用できる。例えば、橋を通過する車両の交通情報の取得という目的が挙げられる。ここで、橋は、橋梁耐性の関係で通過する車両の重量制限を行っていることがある。その場合、加速度センサにより橋における揺れの振幅を監視することで、重量制限を超えた車両が通過したか否かを検出することが可能である。尚、重量制限の違反車両(違反ドライバー)を検挙するには、例えば、別途、通過した車両のナンバープレート写真と連携することで実現可能性が高まる。
そのため、橋の健康診断という利用目的と橋の交通情報の取得という利用目的とで、同一の橋梁に設置した同一のセンサ素子を搭載したセンサ装置を共用することが可能と考えられる。
そして、クラウドサービス会社により橋の健康診断や交通情報をビッグデータとして提供することも可能である。但し、現状では、ある会社が橋の健康診断という利用目的で橋梁に加速度センサを備えたセンサ装置を設置し、また、別の会社が同じ橋から交通情報を取得するという利用目的で同じ仕様の異なるセンサ装置を設置するといったことになり得る。ところが、クラウドサービス会社がセンサ装置の設置から保守及びメンテナンスを自前で行うにはコストが高く、このようなクラウドサービスを実現することが困難である。また、各クラウドサービス会社は、センサ装置の機能の一部を利用する必要があるが、全機能を使いこなす必要がないことが多い。そのため、センサ装置を適切に利用できるとは限らず、過剰な投資となり得る。
また、橋の健康診断という利用目的と橋の交通情報の取得という利用目的とでは、情報の買い手である企業、官公庁、自治体等が異なる。
さらに、複数の利用目的で、同一の橋梁に設置した同一のセンサ素子を搭載したセンサ装置を用いるとしても、利用目的ごとにセンサ素子のパラメータ設定(サンプリングレート等)や測定値の加工処理の仕方が異なる。
そこで、本実施の形態3にかかる橋梁監視システム3000を適用することで、同一の橋梁に設置した同一のセンサ素子を搭載したセンサ装置を一定時間、占有して利用できる権利を、各クラウドサービス会社に販売することが可能となる。すなわち、センサ装置を時分割して、単位時間当たりのセンサ素子の占有が保証できるため、時間単位でのセンサ素子及びセンサ制御装置の制御及び測定情報の取得を複数の企業に開放する仕組みを提供する。そのため、測定対象物に設置されたセンサ素子を搭載したセンサ装置を複数の企業(ユーザ)がお互いに干渉することなく、動的にユーザプログラムを管理サーバ経由で書き換えることができ、ユーザが求めるデータを必要な対価を支払うことで利用できる。
また、ビッグデータを創り出すセンサ装置の設置からサービスまで行うビジネスを実現できる。そのために、本実施の形態の実施者は、参画する企業を公募し、必要な個所にセンサ装置を設置し、各企業に情報提供できる。そして、参画する各企業のそれぞれに、センサ素子及びセンサ制御装置を利用するプログラミングのルールを提示し、実行時間帯の占有を保証する認証鍵を提供する。そのため、上述したように、本実施の形態にかかるセンサ装置は、複数の企業ユーザから提供される複数のユーザプログラムを排他的に実行し、他のプログラムに影響を与えずに更新が可能である。そして、本実施の形態の実施者は、センサ装置のメンテナンス(電池交換や故障時対応)を実施し、各企業ユーザは、センサ情報を扱ったビジネスに専念できる。
ここで、橋の健康診断という利用目的は、数年から数10年といった期間で橋の状態監視を行うため、1日に最低1回測定できれば十分である。一方、橋の交通情報は、できるだけ多くの情報を取得できることが望ましいが、1日のうち多少の空き時間を許容することができる。つまり、複数の利用目的の間では、必要とする情報の鮮度が異なる。そのため、仮に、橋の健康診断のために設置したセンサ装置は、1日のほとんどの時間帯で空きがある。そこで、空き時間を、橋の交通情報の取得という利用目的に利用させることで、1台のセンサ装置を効率的に利用することができる。
これらは、橋の健康診断という利用目的のために実装されたユーザプログラムと、橋の交通情報の取得という利用目的のために実装されたユーザプログラムとを本実施の形態にかかるセンサ装置に格納することで、実現できる。特に、各ユーザプログラムは、利用目的ごとにセンサ素子のパラメータ設定や加工処理のアルゴリズムを他のプログラムから独立して実装することができる。そのため、ユーザごとに独自に設計及びプログラムの改修を行うことができる。さらに、本実施の形態では、上述したように、センサ装置上でいずれかのユーザプログラムが占有時間帯に実行中であっても、任意のユーザプログラムの更新を行うことができる。
<その他の実施の形態>
尚、本実施の形態は、上記と関連する別の観点の課題も解決することができる。すなわち、通常、センサ素子の測定結果を加工するためには、有線又は無線通信によりネットワークを介して、サーバ装置へ転送する。そのため、転送するデータ量が増えれば、通信負荷が大きくなる。特に、受信側がマイコンの場合、受信処理速度を上げなければ、通信がボトルネックになってしまう。しかし、受信処理速度を上げれば、マイコンの消費電力が増大してしまう。そのため、送信データ量を減らすために、測定結果の加工をセンサ装置側で行うことが望ましい。
ここで、センサ素子による測定結果を加工することで様々な用途、目的で利用できる。しかし、センサ装置側で測定結果の加工をすると、他の目的で利用し難い。また、そもそも利用目的ごとにセンサ素子の設定値が異なる場合がある。そのため、1つのセンサ素子を複数の利用目的により実装された複数のユーザプログラムで共用すると、他のプログラムに影響を与えずにユーザプログラムを改変することが困難である。そして、影響を減らすために、改変時に他のユーザにアルゴリズムを開示しなければならなくなる。また、センサ素子の設定値をダイナミックに切り替えることができない。特に、設定値をダイナミックに切り替えすると、切り替え時にセンサ情報(測定データ)が欠落し、時系列のデータとして不十分となる。これを回避するためには、予め、消費電力を犠牲にし、複数の利用目的をカバーし得る高いサンプリングレート、高いダイナミックレンジを設定し、高分解能なアナログデジタル変換処理機能をもつ高価なセンサ素子を搭載する必要がある。そのため、センサ装置のコスト上昇を招いてしまう。
尚、センサ装置を設置する場所によっては、センサ装置を動作させる電源が十分ではないため、センサ装置の運転を制限する(=消費電力を低減させる)工夫が必要である。ここで、センサ素子の低消費電力動作は日々進化を遂げている一方で、通信に要する電力は、通信距離や同じ周波数帯域に多数の規格の情報が飛び交っているため、トラフィックの課題を含め電力消費の低下が難しいのが現状である。
そこで、本実施の形態では、各ユーザプログラムにセンサ素子を占有する時間帯を割り当て、各ユーザプログラム内でセンサ素子を独自の設定値に設定し、設定値による測定結果を処理する。但し、ユーザプログラムにセンサ素子を占有する時間帯を隙間なく割り当てると、センサ装置に何らかのメンテナンス処理を行う際に、常にいずれかのユーザプログラムが実行中となり、そのユーザプログラムがメンテナンス処理の影響を受けるおそれがある。そのため、本実施の形態では、ユーザプログラムの実行中に、メンテナンス情報を受け付け、一部のメンテナンス処理を実行するが、影響の大きいメンテナンス処理については、ユーザプログラムが未実行のタイミングに実施するようにしている。これにより、他のユーザプログラムのロジックに依存せず、また、動作に影響を与えずに、ユーザプログラムの更新が行える。そのため、上述したように、時間単位でセンサ素子の利用権を販売できる。
尚、本実施の形態3では、センサ素子による測定対象物の一例として橋梁や橋脚を挙げたが、実施の形態1及び2では、これらに限定されない。例えば、経年劣化の監視用のセンサが設置済みの場合、監視間隔は長く、大半の時間はセンサのリソースに空きがある。そこで、空き時間を他の目的の監視に利用させるというビジネスに適用可能である。
本実施の形態は、例えば、IoT(Internet of Things)化が進むと見込まれるインフラモニタリング、人や動物のヘルスケア分野において、センサ素子を搭載したセンサ装置に適用可能である。
また、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、CPU(Central Processing Unit)にコンピュータプログラムを実行させることにより実現することも可能である。
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、DVD(Digital Versatile Disc)、BD(Blu-ray(登録商標) Disc)、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は既に述べた実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変更が可能であることはいうまでもない。