JP2017053165A - センサ制御装置、センサシステム、及び、橋梁監視システム - Google Patents

Abstract

【課題】センサ素子を複数の目的で利用することができるセンサ制御装置、センサシステム、及び、橋梁監視システムを提供する。
【解決手段】センサ制御装置１０は、少なくとも１以上のセンサ素子１と接続され、センサ素子１に対して所定の設定を行い、当該設定に基づく測定結果を加工し、当該加工結果を外部装置２へ送信する一連の処理について、それぞれ実装された複数のプログラムと、複数のプログラムの間でそれぞれ異なる実行時間帯が定義された実行定義情報１１１０と、を記憶する記憶部１１００と、実行定義情報１１１０に基づき複数のプログラムのうち第１のプログラムの実行中に、外部装置２から所定のメンテナンス情報を受信し、当該メンテナンス情報に基づく処理を実行する制御部１２００と、を備える。
【選択図】図１

Description

本発明は、センサ制御装置、センサシステム、及び、橋梁監視システムに関し、例えばセンサ素子による測定値を処理するセンサ制御装置、センサシステム、及び、橋梁監視システムに関する。

特許文献１には、橋梁等の大型建造物の診断データ収集システムに関する技術が開示されている。特許文献１にかかる診断データ収集システムは、無線付橋梁センサと、データ記録装置と、走行車両に搭載されたデータ収集装置と、橋梁診断装置とを備える。無線付橋梁センサは、定期的にセンサ情報を計測し、計測結果を無線経由でデータ記録装置に格納する。データ収集装置は、データ記録装置に格納された計測結果を収集する。橋梁診断装置は、走行車両の移動によりデータ収集装置と有線又は無線による通信が可能となった際に、データ収集装置から測定結果を入力し、橋梁の劣化及び健全度の診断を行う。

特開２００８‐２５５５７０号公報

ここで、測定対象物に対して測定を行うセンサ素子の維持管理を効率化するために、１つのセンサ素子を複数の目的（又は事業体）等で共用し、その測定結果を各目的に基づき解析して利用することが考えられる。しかしながら、センサ素子の測定用の設定値を各目的で共用できるように調整する必要があり、煩雑である。そして、同一の設定値により測定された測定値を複数の利用目的で解析するため、ある利用目的のための解析ロジックの変更が他の利用目的にも影響を与えるおそれがあり、解析ロジックを変更する際の制約が大きい。そのため、センサ素子を複数の目的で利用することは困難であるという問題がある。尚、上述した特許文献１でもこのような問題を解決することはできない。

その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

一実施の形態によれば、センサ制御装置は、異なる目的の各ユーザプログラムについて時間帯ごとにセンサ素子を占有させ、当該ユーザプログラムの実行中にメンテナンス情報を受け付けるものである。

前記一実施の形態によれば、対象物を測定するセンサ素子を複数の目的で効率的に利用することができる。

実施の形態１にかかるセンサシステムの概要構成を示すブロック図である。 実施の形態１にかかるセンサシステムの全体構成を示すブロック図である。 実施の形態１にかかるセンサ装置の構成を示すブロック図である。 実施の形態１にかかるセンサ装置のハードウェア構成を示すブロック図である。 実施の形態１にかかるコンセントレータの構成を示すブロック図である。 実施の形態１にかかる管理サーバの構成を示すブロック図である。 実施の形態１にかかるセンサ装置における１日の動作スケジュールの概念を示す図である。 実施の形態１にかかる登録プログラムリストの例を示す図である。 実施の形態１にかかるユーザプログラムの記載例を示す図である。 実施の形態１にかかるセンサ装置の起動後の状態遷移図である。 実施の形態１にかかる定時処理プログラムの処理を示すフローチャートである。 実施の形態１にかかるセンサ装置側のメンテナンスモードの処理を示すフローチャートである。 実施の形態１にかかる管理サーバ側のメンテナンスモードの処理を示すフローチャートである。 実施の形態１にかかるタスクマネージャによるユーザプログラムと定時処理プログラムの並列実行処理を示すフローチャートである。 実施の形態１にかかるユーザプログラムの起動処理を示すフローチャートである。 実施の形態１にかかるユーザプログラムの処理を示すフローチャートである。 実施の形態１にかかるセンサ素子のドライバプログラムの処理を示すフローチャートである。 実施の形態１にかかるセンサシステムの情報の流れの概略を示す図である。 実施の形態２にかかるセンサシステムの全体構成を示すブロック図である。 実施の形態２にかかるセンサシステムの情報の流れの概略を示す図である。 実施の形態３にかかる橋梁監視システムの全体構成を示すブロック図である。 加速度センサによる橋梁の監視の概念を説明する図である。

以下では、上述した課題を解決するための手段を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。

以下の実施の形態においては便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明するが、特に明示した場合を除き、それらはお互いに無関係なものではなく、一方は他方の一部または全部の変形例、応用例、詳細説明、補足説明等の関係にある。また、以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。

さらに、以下の実施の形態において、その構成要素（動作ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではない。同様に、以下の実施の形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。このことは、上記数等（個数、数値、量、範囲等を含む）についても同様である。

＜実施の形態１＞
図１は、実施の形態１にかかるセンサシステム１０００の概要構成を示すブロック図である。センサシステム１０００は、センサ装置１１と、外部装置２とを備える。センサ装置１１は、センサ素子１と、センサ制御装置１０とを備える。センサ素子１は、測定対象物に対して設定値に基づく測定を行う。ここで、測定対象物とは、例えば、橋梁、橋脚、道路又はビル等の大型建造物が挙げられるが、これらに限定されない。そして、センサ素子１は、例えば、加速度センサ、温度センサ、バッテリ、MEMS（Micro Electro Mechanical Systems）等が挙げられるが、これらに限定されない。また、設定値とは、例えば、加速度センサにおけるサンプリングレート、測定レンジ、１回の測定数等である。また、温度センサにおけるサンプリングレート、アラームの上限及び下限等である。または、バッテリにおけるサンプリングレート、アラームの上限及び下限等である。そして、センサ素子１による測定結果は、例えば、橋脚における振動等である。

センサ制御装置１０は、少なくとも１以上のセンサ素子１と接続される。そのため、センサ装置１１は、センサ素子１を搭載したものといえる。センサ制御装置１０は、記憶部１１００と、制御部１２００とを備える。記憶部１１００は、複数のユーザプログラム１１０１、１１０２、・・・と、実行定義情報１１１０と、定時処理プログラム１１２０とを記憶する。

ユーザプログラム１１０１等のそれぞれは、センサ素子１に対して所定の設定を行い、当該設定に基づく測定結果を加工し、当該加工結果を外部装置２へ送信する一連の処理が実装されたコンピュータプログラムである。つまり、ユーザプログラム１１０１にはある一連の処理が実装され、ユーザプログラム１１０２には、ユーザプログラム１１０１とは異なる一連の処理が実装されていることになる。

実行定義情報１１１０は、複数のユーザプログラム１１０１等の間でそれぞれ異なる実行時間帯が定義された情報である。つまり、各実行時間帯の間で重複がないものとする。定時処理プログラム１１２０は、外部装置２から所定のメンテナンス情報を受信する処理と、当該メンテナンス情報に基づく処理とが実装されたコンピュータプログラムである。ここで、メンテナンス情報とは、センサ装置１１に所定のメンテナンス処理を行うために用いられる情報である。メンテナンス情報としては、例えば、センサ装置１１の起動時の初期設定の変更に関する情報、ファームウェアの更新プログラム、ユーザプログラムの更新プログラム等が挙げられるが、これらに限定されない。そして、メンテナンス情報に基づく処理とは、例えば、センサ装置１１の初期設定の変更処理、ファームウェアの更新処理、ユーザプログラムの更新処理等である。

制御部１２００は、実行定義情報１１１０に基づき、複数のユーザプログラム１１０１の中から実行時間帯の開始時刻が現在時刻となったユーザプログラムの実行を開始する。また、制御部１２００は、実行定義情報１１１０に基づき複数のユーザプログラム１１０１等のうち第１のプログラムの実行中に、外部装置２から所定のメンテナンス情報を受信し、当該メンテナンス情報に基づく処理を実行する。すなわち、制御部１２００は、第１のプログラムの実行中に、定時処理プログラム１１２０を並列実行する。

外部装置２は、ネットワーク等を介してセンサ装置１１と通信可能なコンピュータ装置であるサーバ又はコンセントレータ等である。尚、本実施形態にかかるサーバやコンセントレータについては、後述する。

このように、本実施の形態では、１つのセンサ素子に対する設定、測定値の加工及び加工結果の送信までの一連の処理を１つのユーザプログラムに実装させ、センサ素子の利用目的ごとに異なる実装をさせた複数のユーザプログラムを用いる。そして、各ユーザプログラムには、異なる実行時間帯が定義されており、ある時刻においては２以上のユーザプログラムが実行されることはない。そのため、各ユーザプログラムはそれぞれ、センサ素子を占有することができる。つまり、各ユーザプログラムは実行時にセンサ素子に対する独自の設定を行い、その設定による測定結果に対して独自の加工を行い、加工結果を独自の送信先へ送信することができる。よって、他のユーザプログラムの設定やアルゴリズムの影響を受けずに、ユーザプログラムの実装内容を変更することができる。それ故、センサ素子を複数の目的で効率的に利用することができる。

図２は、実施の形態１にかかるセンサシステム１０００の全体構成を示すブロック図である。尚、図２は、上述した図１の構成を含めて具体化したものである。センサシステム１０００は、センサ装置１１、１２及び１３と、コンセントレータ２０と、センサ装置管理サーバ３０と、エンドユーザ端末４１、・・・４ｍ（ｍは２以上の整数。）と、クラウドサービスサーバ５１、・・・５ｎ（ｎは２以上の整数。）とを備える。

センサ装置１１〜１３のそれぞれは、異なるセンサ素子が搭載され、有線又は無線によりコンセントレータ２０と通信可能なコンピュータ装置である。尚、センサ装置１１〜１３は、少なくとも１以上であればよい。コンセントレータ２０は、センサ装置１１〜１３と管理サーバ３０との間のデータの転送を中継するコンピュータ装置である。コンセントレータ２０は、クラウド接続可能な有線又は無線機器を内蔵しており、ネットワークＮを介して管理サーバ３０と通信が可能である。ここで、ネットワークＮは、一般的なネットワークインフラ回線であり、例えば、インターネット等である。尚、コンセントレータ２０は１つである必要はなく、センサ装置１１等の設置の利用条件に合わせて複数のコンセントレータを用いてもよい。

管理サーバ３０は、センサ装置１１〜１３並びにコンセントレータ２０を管理するコンピュータ装置である。管理サーバ３０は、ネットワークＮを介してコンセントレータ２０と、エンドユーザ端末４１〜４ｍ及びクラウドサービスサーバ５１〜５ｎと通信を行う。尚、コンセントレータ２０又はセンサ装置管理サーバ３０は、上述した外部装置２に相当する。

ここで、センサ装置１１〜１３、コンセントレータ２０及び管理サーバ３０を管理及び運用する会社を管理会社とする。クラウドサービスサーバ５１〜５ｎを運用する企業Ｘ１〜Ｘｎのそれぞれは、管理会社と事前に契約し、管理会社から配布された認証鍵を受領済みとする。認証鍵は、例えば、１日のうちセンサ装置１１等を占有できる時間帯（例えば、１時間単位）ごとに割り当てられた一意な情報である。そして、企業Ｘ１〜Ｘｎのそれぞれは、センサ装置１１〜１３に搭載されたセンサ素子に対する自社の利用目的に基づいて、測定用の設定値、測定結果の加工処理、加工結果の自社サーバを宛先とした送信処理等を実装したユーザプログラムを開発させる。尚、認証鍵は、時間帯に限らず、ファームウェアや、初期設定の変更情報等にも割り当てられている。

その後、クラウドサービスサーバ５１〜５ｎのそれぞれは、自社に配布された認証鍵及び時間帯（開始時刻）を付加した各ユーザプログラムを、管理サーバ３０に対して送信、つまり、アップロードする。管理サーバ３０は、クラウドサービスサーバ５１〜５ｎのそれぞれから受信したユーザプログラムに付加された認証鍵と時間帯の組合せが適正か否かを判定する。そして、適正と判定した場合、管理サーバ３０は、受信したユーザプログラム内に付加された認証鍵と時間帯の組合せを所定の記載方法で追記する。所定の記載方法とは、例えば、ユーザプログラムのプログラムコードの先頭に注釈行と解釈されるように、開始時刻と認証鍵を記載し、また、対象時刻外の認証鍵を空白として記載することが挙げられる。その後、管理サーバ３０は、ユーザプログラムを、コンセントレータ２０に転送する。コンセントレータ２０は、転送されたユーザプログラムをセンサ装置１１〜１３に転送する。センサ装置１１〜１３のそれぞれは、転送されたユーザプログラムを記憶部に保存し、実行定義情報の一例である登録プログラムリスト内の、付加された開始時刻に対応する時間帯に、プログラムの保存先のアドレスを記入する。また、クラウドサービスサーバ５１〜５ｎのそれぞれは、コンセントレータ２０及び管理サーバ３０を介して、センサ装置１１等に関する各種情報を受信する。尚、管理サーバ３０は、セキュリティ確保のため定期的又は不定期に認証鍵を更新する。その際、管理サーバ３０は、クラウドサービスサーバ５１〜５ｎのそれぞれに対して、契約した時間帯に対応する更新後の認証鍵を通知する。また、管理サーバ３０は、各センサ装置に対して更新後の認証鍵を送信し、ユーザプログラム内の認証鍵の記載の書換え処理と、登録プログラムリスト内の認証鍵の記載の書換え処理とを指示する。

エンドユーザ端末４１〜４ｍは、エンドユーザが操作する端末装置である。エンドユーザ端末４１〜４ｍは、例えば、パーソナルコンピュータ、タブレット端末、又は、スマートフォン等が挙げられるが、これらに限定されない。また、エンドユーザは、企業Ｘ１〜Ｘｎから提供される、センサ装置１１等の測定結果からの加工結果（解析結果）に対して、対価を支払う企業又は個人である。エンドユーザ端末４１〜４ｍは、クラウドサービスサーバ５１〜５ｎから付与されたアクセス権限に基づき、管理サーバ３０にアクセスし、各企業により提供されるデータの閲覧や、自社や個人の記憶媒体（ハードディスクドライブなど）にデータをダウンロードする。

図３は、実施の形態１にかかるセンサ装置１１の構成を示すブロック図である。尚、センサ装置１２及び１３の構成は図３と同等であるため、図示及び説明を省略する。センサ装置１１は、ソフトウェア層１１０とハードウェア層１２０の２階層に分けて説明できる。ハードウェア層１２０は、ＣＰＵ（Central Processing Unit）１２１、ＲＡＭ（Random Access Memory）１２２、ＲＯＭ（Read Only Memory）１２３、シリアルＩ／Ｆ（InterFace）１２４１及び１２４２、ＡＤＣ（Analog-to-Digital Converter）１２５、セキュアＩＰ（Internet Protocol）１２６、ＲＦ（Radio Frequency）１２７、ＭＥＭＳ１２８及びアナログセンサ１２９を備える。ここで、ＲＦ１２７はシリアルＩ／Ｆ１２４１により、ＭＥＭＳ１２８はシリアルＩ／Ｆ１２４２により、アナログセンサ１２９はＡＤＣ１２５により、それぞれセンサ装置１１の本体と接続される。尚、接続されるセンサ素子は、測定対象物に応じて変更することができる。また、アナログセンサ１２９は、抵抗（Ｒ）や容量（Ｃ）の変化を出力するセンサ素子の一例である。

ソフトウェア層１１０は、ハードウェア層１２０の上層であり、オペレーティングシステム（Operating System）１１１、デバイスドライバ（Device Driver）１１２、パワーマネージャ（Power Manager）１１３、タスクマネージャ（Task Manager）１１４、セキュリティマネージャ（Security Manager）１１５、アプリケーション設定プログラム（Application set-up Program）１１６１、ネットワーク初期化プログラム（Network Initialization Program）１１６２、定時処理プログラム（Periodic Program）１１６３、ミドルウェア（Middleware）／インタプリタ（interpreter）１１６４、ユーザプログラム（User Program）１１６５１、１１６５２〜１１６５ｎを備える。デバイスドライバ１１２は、ＣＰＵ１２１によりデバイスを制御するためのドライバである。デバイスドライバ１１２は、制御対象のセンサ素子により測定されたデータの取得処理、センサ素子の故障検出処理、センサ素子に対する設定値の設定処理等が実装されている。パワーマネージャ１１３、タスクマネージャ１１４及びセキュリティマネージャ１１５は、マネジメント処理層といえる。タスクマネージャ１１４やオペレーティングシステム１１１は、アプリケーション設定プログラム１１６１、ネットワーク初期化プログラム１１６２、定時処理プログラム１１６３及びミドルウェア／インタプリタ１１６４の実行を制御する。特に、タスクマネージャ１１４は、内蔵の時計により定期的に定時処理プログラム１１６３の実行を開始し、また、定期的に実行定義情報１１１０を参照して、ミドルウェア／インタプリタ１１６４上で実行するためのユーザプログラム１１６５１〜１１６５ｎの選択及び実行の開始及び終了を行う。アプリケーション設定プログラム１１６１は、センサ装置１１の起動時の初期設定等が実装されたプログラムである。アプリケーション設定プログラム１１６１は、装置セットアッププログラムと呼んでもよい。ネットワーク初期化プログラム１１６２は、センサ装置１１がコンセントレータ２０とのネットワークを確立するための処理等が実装されたプログラムである。定時処理プログラム１１６３は、上述した定時処理プログラム１１２０に相当する。具体的には、定時処理プログラム１１６３は、コンセントレータ２０を介した管理サーバ３０との時刻同期処理、センサ装置１１の情報変更の有無の確認処理等が実装されている。ミドルウェア／インタプリタ１１６４は、ユーザプログラム１１６５１〜１１６５ｎの実行を支援し、インタプリタ型の言語処理を行う。ユーザプログラム１１６５１〜１１６５ｎのそれぞれは、最上層のアプリケーション層といえ、クラウドサービス企業が設計したセンサ装置の具体的な運用方法を記述したプログラムである。すなわち、ユーザプログラム１１６５１〜１１６５ｎのそれぞれは、センサ素子に対する測定用の設定値の定義、センサ素子による測定結果の受信処理、測定結果（センサ情報）の加工処理（センサ情報の演算に必要な数値演算処理等）、通信フォーマットの定義、センサ情報を通信フォーマットに基づき変換して通信データを生成する処理等が、インタプリタ型の言語により実装されている。このように、ユーザプログラムをインタプリタ型とすることにより、ＣＰＵのアーキテクチャ依存性を無くし、複数のユーザプログラムがお互いに干渉しないように動作保障し、クラウドサービス会社のソフトウェア開発に対する開発環境の整備及びプログラミングスキル等に係る費用と時間を短縮することができる。

図４は、実施の形態１にかかるセンサ装置１１のハードウェア構成を示すブロック図である。図４では電源線を明記している。センサ装置１１は、センサ制御装置１０の一例であるＭＣＵ（Micro Control Unit）１００を備える。ＭＣＵ１００は、タイマ（Timer）１０１、セキュアＩＰ１２６、リセット制御（Reset Control）１０２、ウォッチドッグタイマ（Watch Dog Timer）１０３、システム制御（System Control）１０４、インタラプト制御（Interrupt Control）１０５、データ転送制御（Data Transfer Control）１０６、ＲＡＭ１２２、データメモリ（Data Memory）１２３１、ＣＰＵ１２１、コードメモリ（Code Memory）１２３２、ＤＳＰ（Digital Signal Processor）１０７、シリアルＩ／Ｆ１２４２、ＧＰＩＯ（General Purpose Input/Output）１０９１、ＡＤＣ１２５、ＧＰＩＯ１０９２、シリアルＩ／Ｆ１２４１を備える。ここで、ＭＥＭＳ１２８はシリアルＩ／Ｆ１２４２により、センサ（Sensors）１２９１はＧＰＩＯ１０９１及びＡＤＣ１２５により、バッテリ（Battery）１２９２はＡＤＣ１２５により、電圧レギュレータ（Voltage Regulator）１２９３はＧＰＩＯ１０９２により、ＲＦ１２７はシリアルＩ／Ｆ１２４１により、それぞれＭＣＵ１００と接続される。

ＭＥＭＳ１２８やアナログのセンサ１２９１は消費電力が小さいため、ＭＣＵ１００のＧＰＩＯ１０９１ポートから電源供給が可能である。ＧＰＩＯ１０９１から直接電源を供給することで、センサ１２９１の電源ＯＮ／ＯＦＦを任意のタイミングで実施することができる。そのため、センサ装置１１の低消費電力化が実現できる。一方で、電源供給能力の不足が懸念されるＲＦ１２７に対しては、レギュレータの動作制御端子をＭＣＵ１００から制御することを行い、センサ１２９１と同様に、不要なときにはＯＦＦとすることを実施する。

図５は、実施の形態１にかかるコンセントレータ２０の構成を示すブロック図である。コンセントレータ２０は、ソフトウェア層２１０とハードウェア層２２０の２階層に分けて説明できる。ハードウェア層２２０は、ＣＰＵ２２１、ＲＡＭ／ＲＯＭ２２２、シリアルＩ／Ｆ２２４１及び２２４２、Ｅｔｈｅｒ２２５、セキュアＩＰ２２６、ＲＦ２２７１及び２２７２を備える。ここで、ＲＦ２２７１及び２２７２はシリアルＩ／Ｆ２２４１及び２２４２により、それぞれコンセントレータ２０の本体と接続される。尚、ＲＦ２２７１及び２２７２は、無線機器の一例であり、少なくとも１以上であればよい。

ソフトウェア層２１０は、ハードウェア層２２０の上層であり、デバイスドライバ２１１、オペレーティングシステム２１２、ミドルウェア２１３、センサネットワーク管理及び伝送アプリ２１４を備える。オペレーティングシステム２１２、ミドルウェア２１３、並びに、センサネットワーク管理及び伝送アプリ２１４は、Ｅｔｈｅｒ２２５によるネットワークＮとの接続（例えば、インターネット接続）を可能とする複数の通信ネットワーク間のブリッジ機能を実現する。尚、当該ブリッジ機能には、それぞれの通信ネットワークに対して高い応答性が求められることから、ＣＰＵ２２１はマルチＣＰＵ構成であってもよい。

図６は、実施の形態１にかかる管理サーバ３０の構成を示すブロック図である。管理サーバ３０は、ソフトウェア層３１０とハードウェア層３２０の２階層に分けて説明できる。ハードウェア層３２０は、ＣＰＵ３２１、ＲＡＭ／ＲＯＭ３２２、Ｅｔｈｅｒ３２３、シリアルＩ／Ｆ３２４、セキュアＩＰ３２５、Ｓ−ＡＴＡ（Serial ATA）３２６、ストレージ（Storage）３２７を備える。ここで、ストレージ３２７はＳ−ＡＴＡ３２６により管理サーバ３０の本体と接続される。セキュアＩＰ３２５は、クラウドサービスサーバ５１等から送信される情報に付加される認証鍵が適正なものかを判定及び支援する。

ソフトウェア層３１０は、ハードウェア層３２０の上層であり、デバイスドライバ３１１、オペレーティングシステム３１２、ミドルウェア３１３、センサ管理３１４１、ユーザ管理３１４２、・・・保守アプリ３１４３を備える。特に、センサ管理３１４１、ユーザ管理３１４２は、クラウドサービス企業とのやり取りを支援するためのアプリケーションソフトウェアである。また、保守アプリ３１４３は、管理会社がメンテナンスするための保守用ソフトウェアである。

図７は、実施の形態１にかかるセンサ装置１１における１日の動作スケジュールの概念を示す図である。すなわち、図７は、上述した実行定義情報１１１０の定義内容の一例を概念的に示したものである。まず、定時処理プログラム１１２０は、毎日、０時０分０秒から２３時０分０秒まで１時間おきに、つまり１日２４回起動するようにスケジュールされている。尚、センサ装置１１における定時処理プログラム１１２０の１回当たりの実行時間は１時間未満であるものとする。また、ユーザプログラム１１０１、１１０２、１１０３及び１１０４のそれぞれは、Ｘ１社の処理１、Ｘ２社の処理２、Ｘ３社の処理３及びＸ４社の処理４がそれぞれ実装されたプログラムである。そして、ユーザプログラム１１０１は毎日０時０分０秒に起動し、ユーザプログラム１１０２は毎日６時０分０秒に起動し、ユーザプログラム１１０３は毎日１５時０分０秒に起動し、ユーザプログラム１１０４は毎日１８時０分０秒に起動するようにスケジュールされている。つまり、ユーザプログラム１１０１は毎日０時から５時５９分５９秒までの実行時間帯、ユーザプログラム１１０２は毎日６時から１４時５９分５９秒までの実行時間帯、ユーザプログラム１１０３は毎日１５時から１７時５９分５９秒までの実行時間帯、ユーザプログラム１１０４は毎日１８時から２３時５９分５９秒までの実行時間帯が、それぞれ割り当てられている。言い換えると、ユーザプログラム１１０１〜１１０４のそれぞれは、割り当てられた実行時間帯において、他のユーザプログラムに対して排他的な実行が保証される。そして、各ユーザプログラムは、センサ制御装置１０に接続されたセンサ素子の設定及び測定結果と、センサ制御装置１０の通信機器のリソースを占有することができる。そして、リソースの占有により、センサ素子から時系列で連続した測定結果を漏れなく取得できる。

図８は、実施の形態１にかかる登録プログラムリストの例を示す図である。尚、登録プログラムリストは、実行定義情報１１１０の一実施例である。登録プログラムリストは、ユーザプログラムの開始時刻、認証鍵及び実行アドレスを１つの組合せとして、０時から２３時まで２４回分が定義されている。尚、開始時刻は、「時間」のみで表現し、「分」及び「秒」は０分０秒で固定のため、省略している。認証鍵は、上述した認証情報の一例である。つまり、認証鍵は時間ごとに異なる値である。実行アドレスはセンサ制御装置１０の記憶部内で各ユーザプログラムが保存されている保存先のアドレス情報である。尚、登録プログラムリストは、これに限定されない。つまり、開始時刻は時間単位である必要はなく、年月日を含む定義であっても、時分秒を含む定義であっても、開始時刻と終了時刻の対で定義しても構わない。但し、特定の時刻においては１つのユーザプログラムのみが定義されているものとする。

図９は、実施の形態１にかかるユーザプログラムの記載例を示す図である。まず、コード部Ｐ３２は、センサ装置のユーザである企業等が実装するユーザプログラムの実装内容である。そして、コード部Ｐ３１は、企業等からユーザプログラムを受け付けた管理サーバが適正と判断した場合に、管理サーバにより追記される内容である。コード部Ｐ３１は、インタプリタ言語における注釈として記載される。この例では、コード部Ｐ３１の各行の行頭に注釈として解釈される記号が記載され、続けて、開始時刻と認証鍵のペアを区切り記号（本例では<>）で囲って記載されていることを示す。尚、コード部Ｐ３１の行数に制限はなく、当該ユーザプログラムの実行対象外の時間帯における認証鍵は無記入とされる。仮に、実行対象外の時間帯に不適正な認証鍵が記載されたとしても、適正な文字でないとしてエラー扱いとなり、センサ装置には登録されない。

図１０は、実施の形態１にかかるセンサ装置１１の起動後の状態遷移図である。図１０を用いてセンサ装置１１の動作について、起動から順を追って説明する。まず、センサ装置１１はスイッチ（不図示）を搭載しており、ユーザがスイッチを切り替えることにより２つの起動モードのいずれかに設定される。スイッチは、例えば、メカニカルなスイッチであるディップスイッチや電気信号線を切り替えるジャンパースイッチなどを用いることができる。そして、２つの起動モードとしては、初期設定モードと、ネットワーク確立モードがある。初期設定モードは、センサ装置１１が測定対象物に設置される前に設定される。一方、ネットワーク確立モードは、センサ装置１１が実際に測定対象物に設置された後に設定される。まず、スイッチが初期設定モードに設定されている場合について説明する。

センサ装置１１は、装置起動６１によりスイッチの設定から起動モードを判定する。起動モードが初期設定モードの場合、センサ装置１１は初期設定モード６２１へ移行し、アプリケーション設定プログラム１１６１（装置セットアッププログラムＰ１）を起動する。初期設定モード６２１において、センサ装置１１は、センサ装置１１を運用する際に必要なネットワーク情報やセンサ装置の初期設定、搭載ファームウェアのアップデートを行う。その後、センサ装置１１は、装置テストモード６２２に移行する。装置テストモード６２２において、センサ装置１１は、装置の設定が正しく行われたかを確認するため、疑似環境上にあるサーバと有線又は無線にて接続し、装置のテストを実施する。この場合、設定の正常系に対する試験のみならず、ネットワークがハッキングされた場合を想定し、無効な接続に対して排除又は無視する動作が正しく実行されるかを確認することができる。ネットワークがハッキングされた場合を想定した一連の動作は、サーバ側の端末からコマンド等を送信し人手を介して行ってもよい。または、テストプログラムにより一連の確認動作が自動で行われてもよい。装置テストモード６２２におけるテストに合格した場合、センサ装置１１は装置停止モード６２３に移行し、センサ装置１１を停止する。テストに不合格の場合、センサ装置１１は不合格となった項目を通信ログデータと共にサーバへ送信する。これにより、メーカへの連絡用情報として扱うことができる。尚、センサ装置１１は、サーバからのコマンドにより、初期設定モード６２１から装置テストモード６２２、そして、装置停止６２３へ移行してもよい。

一方、スイッチがネットワーク確立モードに設定されている場合、センサ装置１１は、装置起動６１により起動モードがネットワーク確立モードと判定し、ネットワーク確立モード６３へ移行する。ネットワーク確立モード６３において、センサ装置１１は、ネットワーク初期化プログラム１１６２を起動する。そして、センサ装置１１は、初期設定モード６２１にて設定されたネットワーク情報に基づいてネットワークに参加する手続きを行う。ネットワーク確立後、センサ装置１１は、装置内の時計を設定するための時刻同期モード６４１に移行する。

センサ装置１１は、起動後にタスクマネージャ１１４が実行され、各モードへの移行と、プログラムの起動を制御する。

図１１は、実施の形態１にかかる定時処理プログラムの処理を示すフローチャートである。まず、時刻同期モード６４１において、センサ装置１１は、定時処理プログラムＰ２を起動する（Ｓ１１１）。次に、センサ装置１１は、ユーザプログラムが実行中の場合に、ユーザプログラムがコンセントレータ２０と通信中又はセンサ素子が測定中であるかを判定する（Ｓ１１２）。通信中又は測定中である場合、センサ装置１１は、一定時間待機し、再度ステップＳ１１２の判定を実行する。いずれのユーザプログラムも未実行であるか、通信中ではなく、かつ、測定中でもない場合に、ステップＳ１１３へ進む。尚、センサ装置１１がネットワーク確立モード６３から移行した場合には、いずれのユーザプログラムも未実行となる。また、ユーザプログラムが実行中であっても、測定結果の加工処理中等である場合には通信中ではなく、かつ、測定中でもない場合に該当する。

続いて、センサ装置１１は、コンセントレータ２０を介して管理サーバ３０へ時刻問合せ要求を送信する（Ｓ１１３）。そして、センサ装置１１は、管理サーバ３０からコンセントレータ２０を介して、管理サーバ３０における現在の時刻情報と、場合によりメンテナンスモードへの移行指示とを含む応答メッセージを受信する。これにより、センサ装置１１は、受信した時刻情報を内部の時計に設定し、管理サーバ３０と時刻同期を行う。すなわち、前記制御部は、前記第１のプログラムの実行中において、前記センサ素子の動作中又は前記外部装置への送信中でない場合に、前記外部装置との間で時刻同期を行う。これにより、測定結果の測定時刻と加工結果の送信処理に影響を与えずに、センサ装置の時刻を正確にすることができる。

そして、センサ装置１１は、受信した応答メッセージにメンテナンスモードへの移行指示が含まれるか否かを判定する（Ｓ１１４）。具体的には、応答メッセージ内にメンテナンスモードへの移行指示の有無を示すフラグ又はコマンドが含まれているものとする。移動指示が含まれる場合、センサ装置１１は、メンテナンスモード６４２へ移行する。メンテナンスモード６４２での処理が終了した後、センサ装置１１は、定時処理プログラムＰ２の実行を終了する（Ｓ１１７）。また、ステップＳ１１４において移動指示が含まれない場合、センサ装置１１は、スケジューラモード６５へ移行し（Ｓ１１６）、定時処理プログラムＰ２の実行を終了する（Ｓ１１７）。

メンテナンスモード６４２において、センサ装置１１は、管理サーバ３０から受信したメンテナンス情報に応じて、初期設定モードで設定された設定情報の変更、ユーザプログラムの更新、又は、センサ装置のファームウェアの更新等のメンテナンス処理を実行する。特に、メンテナンス情報には認証鍵が含まれており、センサ装置１１は、メンテナンス情報を受信した場合に、管理サーバ３０において検証させるために当該メンテナンス情報を管理サーバ３０へ送り返し、管理サーバ３０におけるメンテナンス情報の検証結果が正常である場合に、当該メンテナンス情報に基づく処理を実行する。これにより、ユーザプログラムの実行中であっても、検証されたメンテナンス情報に基づく処理を安全に並列実行することができる。以下、具体的に説明する。

図１２は、実施の形態１にかかるセンサ装置側のメンテナンスモードの処理を示すフローチャートである。また、図１３は、実施の形態１にかかる管理サーバ側のメンテナンスモードの処理を示すフローチャートである。以下では適宜、図１２及び図１３を参照して説明を行う。尚、以下の説明において、センサ装置１１と管理サーバ３０との送受信については、コンセントレータ２０を経由する旨の記載は省略するものとする。

まず、センサ装置１１は、メンテナンス情報の受信待ち状態である旨を示す受信待ちコードを管理サーバ３０に対して送信する（Ｓ２１１）。尚、２回目以降のステップＳ２１１では、センサ装置１１は、受信待ちコードに加えて、後述するステップＳ２１９の判定結果やステップＳ２２０のメンテナンス処理の正常終了通知である処理済みメンテナンスコード等を含めて、管理サーバ３０へ送信してもよい。そして、センサ装置１１は、一定時間、待機して、管理サーバ３０からのメンテナンス情報の受信を待ち受ける（Ｓ２１２）。

また、図１３において、管理サーバ３０は、ステップＳ２１１に応じて、センサ装置１１から受信待ちコードを受信する（Ｓ２３１）。そして、管理サーバ３０は、センサ装置１１がメンテナンス終了状態か否かを判定する（Ｓ２３２）。メンテナンス終了状態である場合には、ステップＳ２３２へ進み、センサ装置１１にメンテナンスが必要であればステップＳ２３３へ進む。

この時点では、メンテナンス情報が未送信のため、管理サーバ３０は、未処理のメンテナンス処理を抽出する（Ｓ２３３）。そして、管理サーバ３０は、メンテナンス事項が存在するか否かを判定する（Ｓ２３４）。例えば、管理会社においてセンサ装置１１の初期設定の変更内容やファームウェアの更新プログラムの登録がされていた場合、企業Ｘ１等からユーザプログラムの更新プログラムが登録されている場合、又は、更新用の認証鍵が登録されている場合には、メンテナンス事項が存在することになる。メンテナンス事項が存在する場合、管理サーバ３０は、抽出されたメンテナンス処理データをメンテナンス情報としてセンサ装置１１へ送信する（Ｓ２３５）。このとき、送信されるメンテナンス情報には、認証鍵が含まれていることになる。特に、メンテナンス情報がユーザプログラムの更新プログラムである場合には、該当する複数の開始時刻及び各開始時刻に対応する複数の認証鍵の組合せが、上述の通りユーザプログラム内の所定の領域に記載されている。

図１２のセンサ装置１１の処理に戻り、センサ装置１１は、管理サーバ３０からデータを受信したか否かを判定する（Ｓ２１２）。受信していない場合、センサ装置１１は、待機時間が一定時間を超えたか、つまり、メンテナンスモードのタイムアップか否かを判定する（Ｓ２１３）。尚、待機時間の上限値は、例えば５分間である。但し、ネットワークの管理や設定環境や同一ネットワーク上のセンサ装置の個数等の理由によるユーザからの指示等により、センサ装置１１は、初期設定やメンテナンスモードにて待機時間の上限値を変更できるものとする。タイムアップではない場合、ステップＳ２１２へ戻る。タイムアップである場合、センサ装置１１は、タイムアップが３回連続か否かを判定する（Ｓ２１４）。つまり、センサ装置１１は、ステップＳ２１２でデータ受信をせずに、ステップＳ２１１が３回連続で実行され、都度、ステップＳ２１３でタイムアップとなったかを判定する。タイムアップが１回又は２回連続までの場合、ステップＳ２１１へ戻る。一方、タイムアップが３回連続である場合、ステップＳ２２１へ進む。

また、ステップＳ２１２において、管理サーバ３０からメンテナンス情報を受信した場合、センサ装置１１は、受信したデータの内容分析を行い（Ｓ２１５）、受信したデータがメンテナンス終了指示であるか否かを判定する（Ｓ２１６）。メンテナンス終了指示である場合、ステップＳ２２１へ進む。尚、メンテナンス終了指示は、スケジューラモードへの移行指示であってもよい。

一方、メンテナンス終了指示でない場合、センサ装置１１は、受信したデータのエコーバックを行う（Ｓ２１７）。つまり、センサ装置１１は、受信したメンテナンス情報をそのまま管理サーバ３０へ送り返す。

そして、図１３において管理サーバ３０は、エコーバックデータを受信し、エコーバックデータのベリファイを行い（Ｓ２３６）、ベリファイ結果が適正か否かを判定する（Ｓ２３７）。ベリファイ結果が不適正である場合、管理サーバ３０は、センサ装置１１へ不適正通知を送信する（Ｓ２３８）。一方、ベリファイ結果が適正である場合、管理サーバ３０は、センサ装置１１へ適正通知を送信し（Ｓ２３９）、当該メンテナンス事項を未処理のメンテナンス処理から削除する（Ｓ２４０）。ステップＳ２３８又はＳ２４０の後、ステップＳ２３１へ戻る。また、図１２においてセンサ装置１１は、管理サーバ３０からベリファイ結果を受信し（Ｓ２１８）、ベリファイ結果が適正か否かを判定する（Ｓ２１９）。ベリファイ結果が適正である場合、センサ装置１１は、メンテナンス処理を実行する（Ｓ２２０）。尚、メンテナンス処理については、後述する。

ステップＳ２１９でベリファイ結果が不適正である場合、又は、ステップＳ２２０の後、ステップＳ２１１へ戻り、センサ装置１１は、再度、受信待ちコードを管理サーバ３０へ送信する。ここでは、２回目のステップＳ２１１であるため、センサ装置１１は、上述したように受信待ちコードに加えて、ステップＳ２１９の判定結果やステップＳ２２０のメンテナンス処理の正常終了通知である処理済みメンテナンスコード等を含めて、管理サーバ３０へ送信してもよい。

そして、図１３のステップＳ２３２でメンテナンス終了状態ではなく、メンテナンス事項がある場合（Ｓ２３４でＹＥＳ）には、管理サーバ３０は、別のメンテナンス情報をセンサ装置１１へ送信し、上述の通り以降の処理を実行する。そして、センサ装置１１は、別のメンテナンス情報を受信した場合には、続けてメンテナンス処理を実行する。一方、管理サーバ３０においてメンテナンス事項がない場合（Ｓ２３４でＮＯ）、又は、ステップＳ２３２でメンテナンス終了状態である場合、センサ装置１１に対してメンテナンスモード終了コードを送信する（Ｓ２４１）。そして、図１２においてセンサ装置１１は、メンテナンスモード終了コードを受信し（Ｓ２１２でＹＥＳ）、メンテナンス終了指示であると判定し（Ｓ２１６でＹＥＳ）、ステップＳ２２１へ進む。そして、センサ装置１１は、メンテナンスモード終了通知を管理サーバ３０へ送信する（Ｓ２２１）。そして、センサ装置１１は、メンテナンスモード処理を終了し、スケジューラモード６５へ移行する。また、図１３において管理サーバ３０は、センサ装置１１からメンテナンスモード終了通知を受信し（Ｓ２４２でＹＥＳ）、メンテナンスモードを終了する。但し、ステップＳ２４２において管理サーバ３０は、メンテナンスモード終了通知を受信できない場合、タイムアップか否かを判定し（Ｓ２４３）、タイムアップではない場合、ステップＳ２４１へ戻る。タイムアップである場合、管理サーバ３０は、タイムアップが３回連続か否かを判定し（Ｓ２４４）、タイムアップが１回又は２回連続までの場合、ステップＳ２４１へ戻る。一方、タイムアップが３回連続である場合、管理サーバ３０は、メンテナンスモードを終了する。

ここで、上述したメンテナンス処理は、上述した「メンテナンス情報に基づく処理」に相当し、例えば、センサ装置１１の初期設定の変更処理、ファームウェアの更新処理、ユーザプログラムの更新処理、認証鍵の変更処理等である。まず、メンテナンス処理がセンサ装置１１の初期設定の変更処理の場合、メンテナンス情報には、センサ装置１１の初期設定の変更内容が含まれている。そして、センサ装置１１は、変更処理が実行可能な場合に、初期設定の値を変更内容へ更新する。そして、必要に応じて、センサ装置１１は、装置テストやネットワーク確立等を行う。そのため、当該変更処理には、アプリケーション設定プログラム１１６１及びネットワーク初期化プログラム１１６２の一部を用いても構わない。

また、メンテナンス処理がファームウェアの更新処理の場合、メンテナンス情報には、ファームウェアの更新プログラムが含まれている。そして、センサ装置１１は、現在のファームウェアとは別の記憶領域に更新プログラムを保存する。センサ装置１１は、ファームウェアの更新処理が実行可能な場合に、現在のファームウェアを更新プログラムに差し替えて実行させる。

また、メンテナンス処理が認証鍵の変更処理の場合、メンテナンス情報には、変更用の認証鍵と開始時刻の組合せが含まれている。そして、センサ装置１１は、登録プログラムリスト内の該当する開始時刻に対応付けて記載されている認証鍵をメンテナンス情報に含まれる変更用の認証鍵に書き換える。併せて、センサ装置１１は、登録プログラムリスト内の該当する開始時刻に対応付けて記載されている実行アドレスに格納されているユーザプログラム内の該当する開始時刻に対応付けて記載されている認証鍵も変更用の認証鍵に書き換える。

また、メンテナンス処理がユーザプログラムの更新処理である場合、メンテナンス情報には、ユーザプログラムの更新プログラムが含まれている。そして、更新プログラム内の所定の領域に開始時刻及び認証鍵の組合せが記載されている。そして、センサ装置１１は、既存のユーザプログラムとは別の記憶領域に更新プログラムを保存する。そして、センサ装置１１は、登録プログラムリスト内から、更新プログラム内の開始時刻及び認証鍵の組合せと一致する開始時刻及び認証鍵の組合せを検索する。その後、センサ装置１１は、登録プログラムリスト内で検索された開始時刻及び認証鍵の組合せに対応する実行アドレスを、当該更新プログラムの保存先のアドレスに書き換える。尚、この場合、センサ装置１１は、プログラム更新モード６４３に移行し、更新後にメンテナンスモード６４２へ戻る。

言い換えると、前記制御部は、第１のプログラムの実行中に、複数のプログラムのうち第２のプログラムに対する更新プログラムをメンテナンス情報として管理サーバ３０から受信し、当該更新プログラムを記憶部に追加して格納し、前記実行定義情報に基づく前記第２のプログラムの実行開始時に、当該第２のプログラムの代わりに前記更新プログラムの実行を開始する。これにより、ユーザプログラムの実行中であっても、他のユーザプログラムの更新を安全に行い、更新プログラムを適切に実行することができる。

そして、前記実行定義情報は、前記記憶部内の各プログラムの保存先を実行アドレスとして含み、前記制御部は、前記複数のプログラムのそれぞれの前記実行時間帯の開始時刻に、各開始時刻に対応する前記実行アドレスに保存されたプログラムの実行を開始し、前記実行定義情報内の前記第２のプログラムにおける実行アドレスを前記更新プログラムの保存先に書き換え、前記第２のプログラムにおける前記実行時間帯の開始時刻において、前記実行定義情報を参照して、前記第２のプログラムにおける実行アドレスから前記更新プログラムを読み出して実行を開始するとよい。これにより、実行中のユーザプログラムに影響を与えずに、他のユーザプログラムの参照先を適切に更新することができる。

または、前記制御部は、前記第１のプログラムの実行中に、前記第１のプログラムに対する更新プログラムを前記メンテナンス情報として前記外部装置から受信し、当該更新プログラムを前記記憶部内の前記第１のプログラム以外の保存先に保存し、前記第１のプログラムの実行終了後、前記実行定義情報に基づき再実行を開始する際に、当該第１のプログラムの代わりに前記更新プログラムの実行を開始する。これにより、実行中のユーザプログラムの更新プログラムを受信したとしても、安全に受け付けて、次回の実行時には、適切に更新プログラムを実行することができる。

ここで、現在のメンテナンスモード６４２が後述するスケジューラモード６５に移行する前である場合、つまり、ネットワーク確立モード６３から（時刻同期モード６４１を経由して）移行しただけである場合には、この時点ではユーザプログラムが未実行である。また、現在のメンテナンスモード６４２がスケジューラモード６５から（時刻同期モード６４１を経由して）移行してきた場合には、ユーザプログラムが実行中である。そこで、ユーザプログラムが未実行であれば、上述した「変更処理」又は「ファームウェアの更新処理」が「実行可能な場合」に相当し、メンテナンス処理としては、初期設定の変更処理、ファームウェアの更新処理、認証鍵の変更処理、ユーザプログラムの更新処理のいずれも実行可能である。

一方、ユーザプログラムが実行中であれば、初期設定の変更処理及びファームウェアの更新処理は保留し、センサ装置１１の再起動を行う。例えば、現在実行中のユーザプログラムが終了するまで待機し、終了後にセンサ装置１１を再起動する。そのため、次のようにしてもよい。すなわち、前記メンテナンス情報は、前記センサ制御装置の設定情報を含み、前記制御部は、前記記憶部内の前記センサ制御装置の再起動時に初期設定として読み出される領域に、前記受信したメンテナンス情報を保存するようにしてもよい。または、前記メンテナンス情報は、前記センサ制御装置のファームウェアの更新プログラムを含み、前記制御部は、前記記憶部内の前記センサ装置の前記ファームウェアの更新領域に、前記受信した更新プログラムを保存し、前記センサ制御装置の再起動時に、前記更新領域に保存された更新プログラムにより前記ファームウェアを更新するようにしてもよい。これらにより、実行中のユーザプログラムの動作に影響を与えずに、安全にメンテナンス処理を実行できる。

続いて、スケジューラモード６５について説明する。まず、センサ装置１１は、時刻同期モード６４１又はメンテナンスモード６４２からスケジューラモード６５に移行する。そして、センサ装置１１は、定期的に定時処理プログラムＰ２を起動して時刻同期モード６４１へ移行し、並行して、実行定義情報１１１０に基づいてユーザプログラムＰ３を起動してユーザプログラム実行モード６６へ移行する。これらの制御は、上述の通りタスクマネージャ１１４により行われる。

言い換えると、前記記憶部は、前記外部装置から前記所定のメンテナンス情報を受信する処理と、当該メンテナンス情報に基づく処理とが実装された定時処理プログラムをさらに記憶し、前記制御部は、前記実行定義情報に基づき前記複数のプログラムのいずれかの実行を開始すると共に、所定の間隔で前記定時処理プログラムの実行を開始する。これにより、センサ素子による測定やユーザプログラムの加工処理等を停止することなく、メンテナンス処理を実行できる。

図１４は、実施の形態１にかかるタスクマネージャによるユーザプログラムと定時処理プログラムの並列実行処理を示すフローチャートである。まず、タスクマネージャ１１４は、定時であるか否かを判定する（Ｓ１１）。例えば、タスクマネージャ１１４は、内蔵のタイマにより現在時刻が任意の時間の０分０秒となったか否かを判定する。定時である場合、タスクマネージャ１１４は、定時処理プログラムＰ２の起動処理を行う（Ｓ１２）。具体的には、上述した図１１の処理を実行する。

これと並行して、タスクマネージャ１１４は、実行定義情報１１１０を参照し、現在時刻が開始時刻として登録されているか否かを判定する（Ｓ１３）。具体的には、登録プログラムリストには上述したように開始時間のみが登録されているため、タスクマネージャ１１４は、内蔵のタイマにより現在時刻が任意の時間の０分０秒であり、該当する時間が登録プログラムリストに存在するか否かを判定する。開始時刻である場合、タスクマネージャ１１４は、現在時刻に該当するユーザプログラムＰ３の起動処理を行う（Ｓ１４）。具体的には、以下の図１５の処理を行う。

図１５は、実施の形態１にかかるユーザプログラムの起動処理を示すフローチャートである。まず、タスクマネージャ１１４は、登録プログラムリストの該当する時間に対応して記載された認証鍵が適正であるか否かを判定する（Ｓ３１１）。例えば、センサ装置１１は、登録プログラムリスト内の該当する開始時刻と認証鍵の組合せと、対応する実行アドレスに存在するユーザプログラム内の開始時刻と認証鍵の組合せとの照合を行うことで判定する。認証鍵が不適正である場合、タスクマネージャ１１４は、登録プログラムリストの該当する開始時刻及び認証鍵に対応して記載された実行アドレスを削除し（Ｓ３１４）、スタンバイモードへ移行する（Ｓ３１５）。尚、ステップＳ３１７において、センサ装置１１は、内部の各デバイスへの電力の供給を停止し、ＭＣＵ１００は、待機電力を抑えたスタンバイモードへ移行する。スタンバイモードへ移行後、定時刻となった場合に、センサ装置１１は、スケジューラモード６５へ移行する。

ステップＳ３１１で認証鍵が適正と判定した場合、タスクマネージャ１１４は、登録プログラムリストの該当する開始時刻に対応して記載された実行アドレスに保存されたユーザプログラムを、データメモリ１２３１から読み出して実行を開始する（Ｓ３１２）。その後、センサ装置１１は、スケジューラモード６５へ移行する（Ｓ３１３）。

上述したことから、前記実行定義情報には、前記複数のプログラムの各実行時間帯に対応する認証情報が含まれ、前記制御部は、前記複数のプログラムのそれぞれの前記実行時間帯の開始時刻に、対応する前記認証情報の検証を行い、検証結果が正常である場合に、当該開始時刻におけるプログラムの実行を開始する、といえる。これにより、センサ装置に更新プログラムが登録後に、改竄等された場合でも、検出して不正なプログラムの実行を排除できる。

ここで、上述したように各ユーザプログラムはインタプリタ言語で記述され、ミドルウェア／インタプリタ１１６４によりユーザプログラムの先頭から順次解釈されて実行される。ここで、ユーザプログラムには、（１）センサ素子に対する測定レンジやサンプリングレート、１回の測定数、アラームの上限値又は下限値などのパラメータ情報の定義、（２）センサ素子の測定結果を取得する処理、（３）測定結果の演算及び比較等の加工処理等、（４）通信フォーマットの定義、（５）加工結果を通信フォーマットに基づき変換して通信データを生成する処理、（６）通信データを管理サーバ３０へ送信する処理等が実装されている。尚、上記（１）には、センサ制御装置１０における確保すべきメモリ領域、データベース領域の指定値をさらに含めてもよい。

図１６は、実施の形態１にかかるユーザプログラムの処理を示すフローチャートである。まず、センサ装置１１は、デバイスドライバ１１２によりユーザプログラムに定義されたパラメータ情報をセンサ素子に設定する（Ｓ４１０）。次に、センサ装置１１は、現在時刻が本ユーザプログラムの終了時刻に達したか否かを判定する（Ｓ４１１）。すなわち、センサ装置１１は、タイマから現在時刻を取得し、登録プログラムリスト内の開始時刻のうち現在時刻に該当する時刻の実行アドレスを特定し、特定した実行アドレスと本ユーザプログラムの実行アドレスとが異なる場合には、次の実行時間帯に他のユーザプログラムが定義されているため、本ユーザプログラムの終了時刻に達したと判定する。その場合、センサ装置１１は、本ユーザプログラムの実行を終了する。そして、センサ装置１１は、スケジューラモード６５へ移行する。

一方、本ユーザプログラムの終了時刻に達していない場合、センサ装置１１は、センサ素子による測定データが存在するか否かを判定する（Ｓ４１２）。ここで、センサ素子は、ステップＳ４１０のパラメータ設定により測定を行い、測定データを内部のメモリ等に保持する。そして、センサ装置１１は、センサ素子の測定データの有無を確認する。尚、パラメータ設定には、測定間隔も含まれる。よって、測定間隔次第では、ステップＳ４１２で測定データが存在しない場合がある（Ｓ４１２でＮＯ）。その場合、一定時間、待機後、再度、ステップＳ４１２を実行する。特に、複数の時刻の測定データをまとめて解析及び加工を行う場合には、必要な量の測定データが蓄積されるまで、ステップＳ４１０後から一定時間を要する。

ステップＳ４１２で必要な量の測定データが蓄積されたと判定した場合、センサ装置１１は、センサ素子のドライバプログラム（デバイスドライバ１１２）を呼び出して、測定データを取得し、記憶領域に保存する（Ｓ４１３）。

図１７は、実施の形態１にかかるセンサ素子のドライバプログラムの処理を示すフローチャートである。まず、センサ装置１１は、ユーザプログラムからの呼び出しに応じてドライバプログラムを起動する（Ｓ４２１）。そして、センサ装置１１は、ドライバプログラムによりセンサ素子から測定データを取得する（Ｓ４２２）。続いて、センサ装置１１は、ドライバプログラムによりセンサ素子の状態を確認する（Ｓ４２３）。例えば、センサ装置１１は、取得した測定データの最大及び最小値の比較処理や、連続して同値が存在するかの検査処理等をドライバプログラムにより実行する。そして、ドライバプログラムにより異常が検出された場合、センサ装置１１は、宛先アドレスを管理サーバ３０として異常を検出した情報を送信し、管理会社へ通達する。一方、ステップＳ４２３によりセンサ素子の状態が正常であると確認できた場合には、センサ装置１１は、ドライバプログラムにより呼び出し元のユーザプログラムへ測定データを転送する（Ｓ４２４）。

図１６に戻り説明を続ける。センサ装置１１は、取得した測定データに対して所定の加工処理を行う（Ｓ４１４）。所定の加工処理としては、例えば、数値演算、周波数変換、ピーク検出、比較処理等である。そして、センサ装置１１は、加工処理の結果、送信の必要性があるか否かを判定する（Ｓ４１５）。送信の必要性がある場合、センサ装置１１は、ユーザプログラム内に定義した通信フォーマットに基づいて、加工結果を変換して通信データを生成する（Ｓ４１６）。そして、センサ装置１１は、生成した通信データを管理サーバ３０に向けて送信する（Ｓ４１７）。ステップＳ４１７の後、又は、ステップＳ４１５にて送信の必要性がない場合、ステップＳ４１０へ戻る。

このように、本実施の形態では、１つのセンサ装置内で同じ時間帯に動作するユーザプログラムは、スケジューラ（例えば、タスクマネージャ１１４）によりただ１つ選択される。また、ユーザ（企業Ｘ１等）がセンサ素子の利用のために割り当てられている時間帯における測定用のパラメータは、当該ユーザが作成するユーザプログラムにより任意に設定可能であり、他のユーザプログラムの設定には依存しない。さらに、実行中のユーザプログラムは、終了時刻に達するまで停止されることがないため、その間のセンサ素子からの情報取得や加工結果の通信処理は止まることなく継続することができる。

ここで、ステップＳ４２３のセンサデイバスの状態確認処理について補足する。特に、センサ素子が故障した場合には、特徴的なデータ出力がある。例えば、同一の値又は周期性をもって同じ値が繰り返し出力される場合がある。ここで、センサ素子はデジタル値を出力するものが増えてきたが、センサ素子の内部ではアナログの出力である。そのため、センサ素子から出力されるデジタル値は、アナログデジタル変換された情報に過ぎない。よって、測定データがある周期をもって同じ値が繰り返されるというのは現実的ではないといえる。

また、センサ素子の故障を判定するためには、最大値及び最小値を監視することも有効な手段である。設定した測定レンジに対して最大値が上回ること、もしくは、最小値を下回ること、または、上限値以下にならない、もしくは、下限値以上にならないなどは異常と判断しても良い場合が多い。本実施形態にかかるセンサ装置の故障検出は、センサ素子とのインターフェイスのドライバプログラムにより実現される。これにより、ユーザプログラムの動作への影響を排除できる。

続いて、図１８を用いてコンセントレータ２０及び管理サーバ３０の役割を説明する。図１８は、実施の形態１にかかるセンサシステム１０００の情報の流れの概略を示す図である。コンセントレータ２０は、図１８に示すように次の３つの役割がある。
（１−１）管理サーバ３０から各センサ装置１１〜１３への情報の転送制御
（１−２）センサ装置１１〜１３からクラウドサービスサーバ５１〜５ｎへの情報の転送制御
（１−３）センサ装置１１〜１３から管理サーバ３０へセンサ素子の異常通知の転送制御
尚、それぞれの転送において、ネットワークＮのマルチホッピングや送信に対する応答メッセージの流れは省略する。

（１−１）センサ装置１１〜１３への情報の転送制御においては、コンセントレータ２０は、管理サーバ３０から各センサ装置への指示を一時的に保存する。また、コンセントレータ２０は、各センサ装置から定時処理としての時刻問い合わせ要求を受信した場合、前記一時的に保存された指示を要求元のセンサ装置へ返信する。尚、コンセントレータ２０は、センサ装置に情報を転送する前に同一センサ装置への転送情報の内容が更新された場合、古いものは破棄し、新しいものだけを転送する。

（１−２）センサ装置１１〜１３からクラウドサービスサーバ５１〜５ｎへの情報（通信データ）の転送制御においては、コンセントレータ２０は、各センサ装置が測定結果の加工及び圧縮等を行った通信データを受信し、通信データに指定された宛先アドレスを参照して宛先のクラウドサービスサーバを特定し、特定したクラウドサービスサーバへ通信データを転送する。

（１−３）センサ装置１１〜１３から管理サーバ３０へセンサ素子の異常通知の転送制御においては、コンセントレータ２０は、各センサ装置からセンサ素子やセンサ装置の異常通知を受信した場合に、管理サーバ３０へ当該異常通知を転送する。

管理サーバ３０は、図１８に示すように次の３つの役割がある。
（２−１）ユーザであるクラウドサービス企業からユーザプログラムを受付
（２−２）コンセントレータ２０を介してセンサ装置１１〜１３にユーザプログラムを配信
（２−３）センサ装置１１〜１３から異常通知を受け付け、管理会社へ通達

（２−１）ユーザプログラムは、センサ制御装置及びセンサ素子の制御用プログラムである。管理サーバ３０は、例えば、企業Ｘ１のクラウドサービスサーバ５１から企業Ｘ１の利用目的のために開発されたユーザプログラムをネットワークＮを介して受信する。ここで、管理サーバ３０は、センサ素子の利用を占有できる時間帯に対応する認証鍵を、企業Ｘ１に対して事前に配布済みである。そのため、クラウドサービスサーバ５１は、送信対象のユーザプログラムに認証鍵及び利用する時間帯（開始時刻等）を付加して管理サーバ３０へ送信する。管理サーバ３０は、受信したユーザプログラムに付加された開始時刻における認証鍵の検証及びユーザプログラムの動作の妥当性の検証を実施する。そして、受信したユーザプログラムが不正又は不適切である場合には、管理サーバ３０は、受信したユーザプログラムを破棄する。また、受信したユーザプログラムが適正である場合、管理サーバ３０は、受信したユーザプログラムの所定の領域に、付加された開始時刻及び認証鍵の組合せを書き込む。

（２−２）管理サーバ３０は、コンセントレータ２０を介してセンサ装置１１〜１３にユーザプログラムを配信する。但し、配信時にコンセントレータ２０が通信データの転送中であるか、異常通知の転送中等である場合には、管理サーバ３０は、ユーザプログラムの配信を待機し、コンセントレータ２０における転送処理を優先させる。また、センサ装置１１〜１３に配信したユーザプログラムがエコーバックのために送り返された場合、管理サーバ３０は、当該ユーザプログラム内に記載された開始時刻における認証鍵のベリファイを行い、ベリファイ結果を返信する。これにより、ベリファイ結果が不適正な場合、占有時間外の認証鍵によるユーザプログラムをセンサ装置１１等から削除させることができる。

（２−３）センサ装置１１等からコンセントレータ２０を介して異常通知を受け付けた場合、管理サーバ３０は、自身のメール機能等を用いて管理会社の特定の管理者又はメーリングリストへメール配信し、異常を通知する。また、管理サーバ３０は、異常通知の内容をウェブブラウザ上で閲覧させることも可能とする。これにより、管理者による異常状態の把握を支援できる。

これらにより、クラウドサービスを提供する各企業は、従来のサービス内容を変えることなく、最終受益者であるエンドユーザに対してデータの閲覧やダウンロードサービスを提供することができる。

このように、本実施の形態では、クラウドサービスを提供する企業のサーバとは別に、センサ装置を管理するための管理サーバを設けることと、センサ装置のスケジューラモードにて管理サーバとの連携により定時処理の実施、センサ装置の設定やプログラム更新及び不正排除機能、ユーザプログラムを排他的に実行する機能を持たせたものである。

これらの構成により、複数の利用目的によるユーザプログラムを共存することができ、上述した課題を解決可能となる。さらに、他のユーザプログラムに影響を与えることなく、センサ装置上のユーザプログラムの書き換えが可能である。また、測定データの加工処理のアルゴリズムを他のユーザに対して非公開にできる。さらに、低コストと低消費電力を両立し、センサデバイスにおける測定データの欠損がなく情報を取得して、データの加工が可能となる。

＜実施の形態２＞
本実施の形態２は、上述した実施の形態１の変形例である。図１９は、実施の形態２にかかるセンサシステム２０００の全体構成を示すブロック図である。センサシステム２０００は、上述したセンサシステム１０００全体においてコンセントレータ２０が１台のみである場合に、管理サーバ３０とコンセントレータ２０と一体型としたコンセントレータ兼管理サーバ６０に置き換えたものである。その他の構成及びセンサ装置１１等の動作については、実施の形態１と同様であるため説明を省略する。

図２０は、実施の形態２にかかるセンサシステム２０００の情報の流れの概略を示す図である。コンセントレータ兼管理サーバ６０は、図２０に示すように次の４つの役割がある。
（３−１）ユーザであるクラウドサービス企業からユーザプログラムを受付
（３−２）センサ装置１１〜１３にユーザプログラムを配信
（３−３）センサ装置１１〜１３からクラウドサービスサーバ５１〜５ｎへの情報の転送制御
（３−４）センサ装置１１〜１３から異常通知を受け付け、管理会社へ通達
ここで、上述した実施の形態１と同様に、それぞれの転送において、ネットワークＮのマルチホッピングや送信に対する応答メッセージの流れは省略する。

（３−１）コンセントレータ兼管理サーバ６０は、上記（２−１）と同様に、各企業のクラウドサービスサーバ５１〜５ｎから、各企業のユーザプログラム及び認証鍵及び開始時刻を受け付け、各種検証を行い、不正又は不適切な場合には、受信したユーザプログラムを破棄する。また、受信したユーザプログラムが適正である場合、コンセントレータ兼管理サーバ６０は、受信したユーザプログラムの所定の領域に、付加された開始時刻及び認証鍵の組合せを書き込む。
（３−２）コンセントレータ兼管理サーバ６０は、上記（２−２）及び（１−１）をまとめて実現すべく、直接、センサ装置１１〜１３へユーザプログラムを配信する。
（３−３）コンセントレータ兼管理サーバ６０は、上記（１−２）と同様に、宛先のクラウドサービスサーバへ通信データを転送する。
（３−４）コンセントレータ兼管理サーバ６０は、上記（２−３）及び（１−３）をまとめて実現すべく、直接、特定の管理者又はメーリングリストへメール配信する。

これらにより、本実施の形態２は、上述した実施の形態１と同様の効果に加え、システム運用の簡素化、並びに、設置費用及び運転費用を抑制するという効果を奏する。

＜実施の形態３＞
本実施の形態３は、上述した実施の形態１又は２の一実施例であり、橋梁監視システムに関するものである。図２１は、実施の形態３にかかる橋梁監視システム３０００の全体構成を示すブロック図である。橋梁監視システム３０００は、橋梁７１及び橋脚７２と、橋梁７１を通過する車両７３及び７４を監視するための情報システムである。橋梁監視システム３０００は、センサ装置１１ａ及び１１ｂと、コンセントレータ２０ａと、管理サーバ３０ａとを備える。

センサ装置１１ａ及び１１ｂは、上述したセンサ装置１１等の一例である。センサ装置１１ａは少なくとも１つのセンサ素子１ａ及びセンサ素子１ａと接続されるセンサ制御装置を搭載し、センサ装置１１ｂは少なくとも１つのセンサ素子１ｂ及びセンサ素子１ｂと接続されるセンサ制御装置を搭載する。センサ装置１１ａ及び１１ｂは、いずれか一方でも、又は、３以上で合っても構わない。センサ装置１１ａ及び１１ｂは、橋梁７１に設置されたものであるが、橋脚７２に設置しても構わない。センサ素子１ａ及びセンサ素子１ｂは、上述したセンサ素子１の一例であり、橋梁７１又は橋脚７２を監視するためのものである。尚、センサ装置１１ａ及び１１ｂの設置場所は、これに限定されず、例えば橋梁７１上で車両７３及び７４の走行に影響を与えない場所等であってもよい。

コンセントレータ２０ａは、上述したコンセントレータ２０の一例であり、センサ装置１１ａ及び１１ｂと管理サーバ３０ａとの間の無線又有線通信によるデータ転送を制御する。管理サーバ３０ａは、上述した管理サーバ３０の一例であり、コンセントレータ２０ａからのデータの送受信と、ネットワークＮを介したクラウドサービスサーバ５１〜５ｎ並びにエンドユーザ端末４１〜４ｍとのデータ送受信を行う。尚、コンセントレータ２０ａは、ネットワークＮを介してクラウドサービスサーバ５１〜５ｎ等と通信可能であってもよい。又は、コンセントレータ２０ａと管理サーバ３０ａとは一体としてもよい。

センサ装置１１ａ及び１１ｂは同等の構成であるため、以下では代表してセンサ装置１１ａについて説明する。センサ装置１１ａが備えるセンサ制御装置は、記憶部と制御部を備える。前記記憶部は、第１のユーザ（例えば、クラウドサービスサーバ５１を運営する企業）により提供された第１のユーザプログラムと、第２のユーザ（例えば、クラウドサービスサーバ５ｎを運営する企業）により提供された第２のユーザプログラムと、第１のユーザプログラム及び第２のユーザプログラムについて異なる実行時間帯が定義された実行定義情報と、センサ装置１１ａに関する処理を実行する定時処理プログラムと、を記憶する。前記制御部は、前記実行定義情報に基づき前記第１のプログラム又は前記第２のプログラムのいずれかを実行し、定期的に前記定時処理プログラムを実行する。

ここで、前記制御部は、前記第１のプログラムの実行により、前記センサ素子に対して第１の設定値による設定を行い、当該第１の設定値による測定結果を加工し、当該加工結果を前記第１のユーザ宛として前記サーバへ送信する。そして、前記制御部は、前記第１のプログラムの実行終了後、前記第２のプログラムの実行により、前記センサ素子に対して第２の設定値による設定を行い、当該第２の設定値による測定結果を加工し、当該加工結果を前記第２のユーザ宛として前記サーバへ送信する。さらに、前記制御部は、前記第１のプログラム又は前記第２のプログラムの実行中に起動される前記定時処理プログラムにより、前記サーバから所定のメンテナンス情報を受信し、当該メンテナンス情報に基づく処理を実行する

このように、本実施の形態にかかる橋梁監視システム３０００は、上述した実施の形態１又は２と同等の効果を奏するものである。

また、本実施の形態３を例にして、実施の形態１及び２を含めた効果について詳述する。現状、橋梁や橋脚の状態監視のために、センサ素子を搭載したセンサ装置が設置されている。この場合、センサ素子として加速度センサを用いることがある。そして、橋の上を車両が通過したときに発生する振動を加速度センサにより測定することで、固有振動数の変化を監視することができる。

ここで、車両の重量により橋梁の振幅は異なるが、周波数は橋の構造により定まる。つまり、橋梁の固有振動数は、橋梁の長さという構造により定まる値である。そのため、仮に橋梁にクラック等のひび割れが発生した場合には構造が変化するため、測定される固有振動数にも変化が生じる。それ故、橋梁についてセンサ素子により振動を測定し、長期間の固有振動数の変化を監視することで、橋梁の異常を検出することができる。

図２２は、加速度センサによる橋梁の監視の概念を説明する図である。まず、処理１のセンシングでは、加速度センサにより取得される加速度情報をサンプリングする。つまり、加速度センサにより計測時刻ごとの加速度を測定する。次に、処理２の解析及び検出では、処理１の測定結果に対してフーリエ変換を行い、周波数と強度の関係を導き、強度のピークを検出する。このとき、必要に応じて周波数変換を行う。そして、処理３の比較及び簡易診断では、センサの着目データについて注意レベル又は警告レベルのそれぞれと比較し、強度のピークが注意レベル又は警告レベルのそれぞれを超えているか否かを判定し、超えている場合には、アラーム（注意通知又は警告通知）を行う。

上述のように現状では、橋梁の固有振動数をモニタリングすること、つまり、橋梁又は橋脚の状態監視（健康診断）という目的で、加速度センサというセンサ素子を利用することができる。

また、加速度センサは、橋梁に対して別の目的でも利用できる。例えば、橋を通過する車両の交通情報の取得という目的が挙げられる。ここで、橋は、橋梁耐性の関係で通過する車両の重量制限を行っていることがある。その場合、加速度センサにより橋における揺れの振幅を監視することで、重量制限を超えた車両が通過したか否かを検出することが可能である。尚、重量制限の違反車両（違反ドライバー）を検挙するには、例えば、別途、通過した車両のナンバープレート写真と連携することで実現可能性が高まる。

そのため、橋の健康診断という利用目的と橋の交通情報の取得という利用目的とで、同一の橋梁に設置した同一のセンサ素子を搭載したセンサ装置を共用することが可能と考えられる。

そして、クラウドサービス会社により橋の健康診断や交通情報をビッグデータとして提供することも可能である。但し、現状では、ある会社が橋の健康診断という利用目的で橋梁に加速度センサを備えたセンサ装置を設置し、また、別の会社が同じ橋から交通情報を取得するという利用目的で同じ仕様の異なるセンサ装置を設置するといったことになり得る。ところが、クラウドサービス会社がセンサ装置の設置から保守及びメンテナンスを自前で行うにはコストが高く、このようなクラウドサービスを実現することが困難である。また、各クラウドサービス会社は、センサ装置の機能の一部を利用する必要があるが、全機能を使いこなす必要がないことが多い。そのため、センサ装置を適切に利用できるとは限らず、過剰な投資となり得る。

また、橋の健康診断という利用目的と橋の交通情報の取得という利用目的とでは、情報の買い手である企業、官公庁、自治体等が異なる。

さらに、複数の利用目的で、同一の橋梁に設置した同一のセンサ素子を搭載したセンサ装置を用いるとしても、利用目的ごとにセンサ素子のパラメータ設定（サンプリングレート等）や測定値の加工処理の仕方が異なる。

そこで、本実施の形態３にかかる橋梁監視システム３０００を適用することで、同一の橋梁に設置した同一のセンサ素子を搭載したセンサ装置を一定時間、占有して利用できる権利を、各クラウドサービス会社に販売することが可能となる。すなわち、センサ装置を時分割して、単位時間当たりのセンサ素子の占有が保証できるため、時間単位でのセンサ素子及びセンサ制御装置の制御及び測定情報の取得を複数の企業に開放する仕組みを提供する。そのため、測定対象物に設置されたセンサ素子を搭載したセンサ装置を複数の企業（ユーザ）がお互いに干渉することなく、動的にユーザプログラムを管理サーバ経由で書き換えることができ、ユーザが求めるデータを必要な対価を支払うことで利用できる。

また、ビッグデータを創り出すセンサ装置の設置からサービスまで行うビジネスを実現できる。そのために、本実施の形態の実施者は、参画する企業を公募し、必要な個所にセンサ装置を設置し、各企業に情報提供できる。そして、参画する各企業のそれぞれに、センサ素子及びセンサ制御装置を利用するプログラミングのルールを提示し、実行時間帯の占有を保証する認証鍵を提供する。そのため、上述したように、本実施の形態にかかるセンサ装置は、複数の企業ユーザから提供される複数のユーザプログラムを排他的に実行し、他のプログラムに影響を与えずに更新が可能である。そして、本実施の形態の実施者は、センサ装置のメンテナンス（電池交換や故障時対応）を実施し、各企業ユーザは、センサ情報を扱ったビジネスに専念できる。

ここで、橋の健康診断という利用目的は、数年から数１０年といった期間で橋の状態監視を行うため、１日に最低１回測定できれば十分である。一方、橋の交通情報は、できるだけ多くの情報を取得できることが望ましいが、１日のうち多少の空き時間を許容することができる。つまり、複数の利用目的の間では、必要とする情報の鮮度が異なる。そのため、仮に、橋の健康診断のために設置したセンサ装置は、１日のほとんどの時間帯で空きがある。そこで、空き時間を、橋の交通情報の取得という利用目的に利用させることで、１台のセンサ装置を効率的に利用することができる。

これらは、橋の健康診断という利用目的のために実装されたユーザプログラムと、橋の交通情報の取得という利用目的のために実装されたユーザプログラムとを本実施の形態にかかるセンサ装置に格納することで、実現できる。特に、各ユーザプログラムは、利用目的ごとにセンサ素子のパラメータ設定や加工処理のアルゴリズムを他のプログラムから独立して実装することができる。そのため、ユーザごとに独自に設計及びプログラムの改修を行うことができる。さらに、本実施の形態では、上述したように、センサ装置上でいずれかのユーザプログラムが占有時間帯に実行中であっても、任意のユーザプログラムの更新を行うことができる。

＜その他の実施の形態＞
尚、本実施の形態は、上記と関連する別の観点の課題も解決することができる。すなわち、通常、センサ素子の測定結果を加工するためには、有線又は無線通信によりネットワークを介して、サーバ装置へ転送する。そのため、転送するデータ量が増えれば、通信負荷が大きくなる。特に、受信側がマイコンの場合、受信処理速度を上げなければ、通信がボトルネックになってしまう。しかし、受信処理速度を上げれば、マイコンの消費電力が増大してしまう。そのため、送信データ量を減らすために、測定結果の加工をセンサ装置側で行うことが望ましい。

ここで、センサ素子による測定結果を加工することで様々な用途、目的で利用できる。しかし、センサ装置側で測定結果の加工をすると、他の目的で利用し難い。また、そもそも利用目的ごとにセンサ素子の設定値が異なる場合がある。そのため、１つのセンサ素子を複数の利用目的により実装された複数のユーザプログラムで共用すると、他のプログラムに影響を与えずにユーザプログラムを改変することが困難である。そして、影響を減らすために、改変時に他のユーザにアルゴリズムを開示しなければならなくなる。また、センサ素子の設定値をダイナミックに切り替えることができない。特に、設定値をダイナミックに切り替えすると、切り替え時にセンサ情報（測定データ）が欠落し、時系列のデータとして不十分となる。これを回避するためには、予め、消費電力を犠牲にし、複数の利用目的をカバーし得る高いサンプリングレート、高いダイナミックレンジを設定し、高分解能なアナログデジタル変換処理機能をもつ高価なセンサ素子を搭載する必要がある。そのため、センサ装置のコスト上昇を招いてしまう。

尚、センサ装置を設置する場所によっては、センサ装置を動作させる電源が十分ではないため、センサ装置の運転を制限する（＝消費電力を低減させる）工夫が必要である。ここで、センサ素子の低消費電力動作は日々進化を遂げている一方で、通信に要する電力は、通信距離や同じ周波数帯域に多数の規格の情報が飛び交っているため、トラフィックの課題を含め電力消費の低下が難しいのが現状である。

そこで、本実施の形態では、各ユーザプログラムにセンサ素子を占有する時間帯を割り当て、各ユーザプログラム内でセンサ素子を独自の設定値に設定し、設定値による測定結果を処理する。但し、ユーザプログラムにセンサ素子を占有する時間帯を隙間なく割り当てると、センサ装置に何らかのメンテナンス処理を行う際に、常にいずれかのユーザプログラムが実行中となり、そのユーザプログラムがメンテナンス処理の影響を受けるおそれがある。そのため、本実施の形態では、ユーザプログラムの実行中に、メンテナンス情報を受け付け、一部のメンテナンス処理を実行するが、影響の大きいメンテナンス処理については、ユーザプログラムが未実行のタイミングに実施するようにしている。これにより、他のユーザプログラムのロジックに依存せず、また、動作に影響を与えずに、ユーザプログラムの更新が行える。そのため、上述したように、時間単位でセンサ素子の利用権を販売できる。

尚、本実施の形態３では、センサ素子による測定対象物の一例として橋梁や橋脚を挙げたが、実施の形態１及び２では、これらに限定されない。例えば、経年劣化の監視用のセンサが設置済みの場合、監視間隔は長く、大半の時間はセンサのリソースに空きがある。そこで、空き時間を他の目的の監視に利用させるというビジネスに適用可能である。

本実施の形態は、例えば、ＩｏＴ（Internet of Things）化が進むと見込まれるインフラモニタリング、人や動物のヘルスケア分野において、センサ素子を搭載したセンサ装置に適用可能である。

また、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、ＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は既に述べた実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変更が可能であることはいうまでもない。

１０００ センサシステム
１ センサ素子
１０ センサ制御装置
１１ センサ装置
１２ センサ装置
１３ センサ装置
１１００ 記憶部
１１０１ ユーザプログラム
１１０２ ユーザプログラム
１１０３ ユーザプログラム
１１０４ ユーザプログラム
１１１０ 実行定義情報
１１２０ 定時処理プログラム
１２００ 制御部
２ 外部装置
２０ コンセントレータ
３０ 管理サーバ
４１ エンドユーザ端末
４ｍ エンドユーザ端末
５１ クラウドサービスサーバ
５ｎ クラウドサービスサーバ
Ｎ ネットワーク
１１０ ソフトウェア層
１１１ オペレーティングシステム
１１２ デバイスドライバ
１１３ パワーマネージャ
１１４ タスクマネージャ
１１５ セキュリティマネージャ
１１６１ アプリケーション設定プログラム
１１６２ ネットワーク初期化プログラム
１１６３ 定時処理プログラム
１１６４ ミドルウェア／インタプリタ
１１６５１ ユーザプログラム
１１６５２ ユーザプログラム
１１６５ｎ ユーザプログラム
１２０ ハードウェア層
１２１ ＣＰＵ
１２２ ＲＡＭ
１２３ ＲＯＭ
１２４１ シリアルＩ／Ｆ
１２４２ シリアルＩ／Ｆ
１２５ ＡＤＣ
１２６ セキュアＩＰ
１２７ ＲＦ
１２８ ＭＥＭＳ
１２９ アナログセンサ
１００ ＭＣＵ
１０１ タイマ
１０２ リセット制御
１０３ ウォッチドッグタイマ
１０４ システム制御
１０５ インタラプト制御
１０６ データ転送制御
１２３１ データメモリ
１２３２ コードメモリ
１０７ ＤＳＰ
１０９１ ＧＰＩＯ
１０９２ ＧＰＩＯ
１２９１ センサ
１２９２ バッテリ
１２９３ 電圧レギュレータ
２１０ ソフトウェア層
２１１ デバイスドライバ
２１２ オペレーティングシステム
２１３ ミドルウェア
２１４ センサネットワーク管理及び伝送アプリ
２２０ ハードウェア層
２２１ ＣＰＵ
２２２ ＲＡＭ／ＲＯＭ
２２４１ シリアルＩ／Ｆ
２２４２ シリアルＩ／Ｆ
２２５ Ｅｔｈｅｒ
２２６ セキュアＩＰ
２２７１ ＲＦ
２２７２ ＲＦ
３１０ ソフトウェア層
３１１ デバイスドライバ
３１２ オペレーティングシステム
３１３ ミドルウェア
３１４１ センサ管理
３１４２ ユーザ管理
３１４３ 保守アプリ
３２０ ハードウェア層
３２１ ＣＰＵ
３２２ ＲＡＭ／ＲＯＭ
３２３ Ｅｔｈｅｒ
３２４ シリアルＩ／Ｆ
３２５ セキュアＩＰ
３２６ Ｓ−ＡＴＡ
３２７ ストレージ
６１ 装置起動
６２１ 初期設定モード
６２２ 装置テストモード
６２３ 装置停止モード
６３ ネットワーク確立モード
６４１ 時刻同期モード
６４２ メンテナンスモード
６４３ プログラム更新モード
６５ スケジューラモード
６６ ユーザプログラム実行モード
Ｐ１ 装置セットアッププログラム
Ｐ２ 定時処理プログラム
Ｐ３ ユーザプログラム
Ｐ３１ コード部
Ｐ３２ コード部
２０００ センサシステム
６０ コンセントレータ兼管理サーバ
３０００ 橋梁監視システム
７１ 橋梁
７２ 橋脚
７３ 車両
７４ 車両
１ａ センサ素子
１ｂ センサ素子
１１ａ センサ装置
１１ｂ センサ装置
２０ａ コンセントレータ
３０ａ 管理サーバ

Claims (13)

1. 少なくとも１以上のセンサ素子と接続されるセンサ制御装置であって、
   前記センサ素子に対して所定の設定を行い、当該設定に基づく測定結果を加工し、当該加工結果を外部装置へ送信する一連の処理について、それぞれ実装された複数のプログラムと、
   前記複数のプログラムの間でそれぞれ異なる実行時間帯が定義された実行定義情報と、
   を記憶する記憶部と、
   前記実行定義情報に基づき前記複数のプログラムのうち第１のプログラムの実行中に、前記外部装置から所定のメンテナンス情報を受信し、当該メンテナンス情報に基づく処理を実行する制御部と、
   を備えるセンサ制御装置。
2. 前記所定のメンテナンス情報には、認証情報が含まれ、
   前記制御部は、
   前記所定のメンテナンス情報を受信した場合に、前記外部装置において検証させるために当該メンテナンス情報を当該外部装置へ送り返し、
   前記外部装置における前記メンテナンス情報の検証結果が正常である場合に、当該メンテナンス情報に基づく処理を実行する
   請求項１に記載のセンサ制御装置。
3. 前記制御部は、
   前記第１のプログラムの実行中に、前記複数のプログラムのうち第２のプログラムに対する更新プログラムを前記メンテナンス情報として前記外部装置から受信し、当該更新プログラムを前記記憶部に追加して格納し、
   前記実行定義情報に基づく前記第２のプログラムの実行開始時に、当該第２のプログラムの代わりに前記更新プログラムの実行を開始する
   請求項１に記載のセンサ制御装置。
4. 前記実行定義情報は、前記記憶部内の各プログラムの保存先を実行アドレスとして含み、
   前記制御部は、
   前記複数のプログラムのそれぞれの前記実行時間帯の開始時刻に、各開始時刻に対応する前記実行アドレスに保存されたプログラムの実行を開始し、
   前記実行定義情報内の前記第２のプログラムにおける実行アドレスを前記更新プログラムの保存先に書き換え、
   前記第２のプログラムにおける前記実行時間帯の開始時刻において、前記実行定義情報を参照して、前記第２のプログラムにおける実行アドレスから前記更新プログラムを読み出して実行を開始する
   請求項３に記載のセンサ制御装置。
5. 前記制御部は、
   前記第１のプログラムの実行中に、前記第１のプログラムに対する更新プログラムを前記メンテナンス情報として前記外部装置から受信し、当該更新プログラムを前記記憶部内の前記第１のプログラム以外の保存先に保存し、
   前記第１のプログラムの実行終了後、前記実行定義情報に基づき再実行を開始する際に、当該第１のプログラムの代わりに前記更新プログラムの実行を開始する
   請求項１に記載のセンサ制御装置。
6. 前記実行定義情報には、前記複数のプログラムの各実行時間帯に対応する認証情報が含まれ、
   前記制御部は、
   前記複数のプログラムのそれぞれの前記実行時間帯の開始時刻に、対応する前記認証情報の検証を行い、検証結果が正常である場合に、当該開始時刻におけるプログラムの実行を開始する
   請求項１に記載のセンサ制御装置。
7. 前記記憶部は、
   前記外部装置から前記所定のメンテナンス情報を受信する処理と、当該メンテナンス情報に基づく処理とが実装された定時処理プログラムをさらに記憶し、
   前記制御部は、
   前記実行定義情報に基づき前記複数のプログラムのいずれかの実行を開始すると共に、所定の間隔で前記定時処理プログラムの実行を開始する
   請求項１に記載のセンサ制御装置。
8. 前記メンテナンス情報は、前記センサ制御装置の設定情報を含み、
   前記制御部は、
   前記記憶部内の前記センサ制御装置の再起動時に初期設定として読み出される領域に、前記受信したメンテナンス情報を保存する
   請求項１に記載のセンサ制御装置。
9. 前記メンテナンス情報は、前記センサ制御装置のファームウェアの更新プログラムを含み、
   前記制御部は、
   前記記憶部内の前記センサ制御装置の前記ファームウェアの更新領域に、前記受信した更新プログラムを保存し、
   前記センサ制御装置の再起動時に、前記更新領域に保存された更新プログラムにより前記ファームウェアを更新する
   請求項１に記載のセンサ制御装置。
10. 前記制御部は、
    前記第１のプログラムの実行中において、前記センサ素子の動作中又は前記外部装置への送信中でない場合に、前記外部装置との間で時刻同期を行う
    請求項１に記載のセンサ制御装置。
11. 少なくとも１以上のセンサ素子と接続されるセンサ制御装置と、当該センサ制御装置と通信可能なサーバとを備えるセンサシステムであって、
    前記センサ制御装置は、
    前記センサ素子に対して所定の設定を行い、当該設定に基づく測定結果を加工し、当該加工結果を前記サーバへ送信する一連の処理について、それぞれ実装された複数のプログラムと、前記複数のプログラムの間でそれぞれ異なる実行時間帯が定義された実行定義情報と、を記憶する記憶部と、
    前記実行定義情報に基づき前記複数のプログラムのうち第１のプログラムの実行中に、前記サーバから所定のメンテナンス情報を受信し、当該メンテナンス情報に基づく処理を実行する制御部と、
    を備える
    センサシステム。
12. 前記サーバは、
    前記実行時間帯ごとに対応する認証情報を予め保持し、
    外部から更新プログラムと前記認証情報とを受信し、当該認証情報が妥当な場合に、当該認証情報と当該更新プログラムとを前記メンテナンス情報として前記センサ制御装置へ送信し、
    前記センサ制御装置は、
    前記サーバから前記メンテナンス情報を受信した場合に、当該メンテナンス情報を前記サーバへ送り返し、
    前記サーバは、
    前記センサ制御装置から送り返されたメンテナンス情報に含まれる認証情報を検証し、検証結果を前記センサ制御装置へ送信し、
    前記センサ制御装置は、
    前記検証結果が正常である場合に、当該メンテナンス情報に基づく処理を実行する
    請求項１１に記載のセンサシステム。
13. 橋梁を監視するために設置された少なくとも１つ以上のセンサ素子を搭載したセンサ装置と、
    前記センサ装置と通信可能なサーバと、
    を備える橋梁監視システムであって、
    前記センサ装置は、
    第１のユーザにより提供された第１のユーザプログラムと、第２のユーザにより提供された第２のユーザプログラムと、前記第１のユーザプログラム及び前記第２のユーザプログラムについて異なる実行時間帯が定義された実行定義情報と、前記センサ装置に関する処理を実行する定時処理プログラムと、を記憶する記憶部と、
    前記実行定義情報に基づき前記第１のプログラム又は前記第２のプログラムのいずれかを実行し、定期的に前記定時処理プログラムを実行する制御部と、を備え、
    前記制御部は、
    前記第１のプログラムの実行により、前記センサ素子に対して第１の設定値による設定を行い、当該第１の設定値による測定結果を加工し、当該加工結果を前記第１のユーザ宛として前記サーバへ送信し、
    前記第１のプログラムの実行終了後、前記第２のプログラムの実行により、前記センサ素子に対して第２の設定値による設定を行い、当該第２の設定値による測定結果を加工し、当該加工結果を前記第２のユーザ宛として前記サーバへ送信し、
    前記第１のプログラム又は前記第２のプログラムの実行中に起動される前記定時処理プログラムにより、前記サーバから所定のメンテナンス情報を受信し、当該メンテナンス情報に基づく処理を実行する
    橋梁監視システム。

Images