EBUG勉強会/20260228_河豚板IoT

---

河豚板IoT†

精密金属加工を行っている工場で使用されている、河豚板を用いた温度測定システムについてご紹介します。

背景†

この工場では、鉄道・航空関連の工作機械部品の加工を行っており、そのためには厳密な温度管理が求められる。

従来、それらの測定・管理は人手により行っていたが、2019年に河豚板上に構築した温度測定システムを導入し、温度の管理作業を効率化した。

概要と特徴†

システム構成†

河豚板LiveUSB上に以下の各機能を実装した。

• センサからのデータ取得

• 取得したデータの処理

• 処理済みデータの保持と取り出し

• グラフ生成

• ウェブユーザインターフェース

画面構成†

• ダッシュボード
  • センサーセル: 現在値 / トレンド / 取得断 / 最低・最高温度
  • 週間天気 → 今後の生産工程のための参考情報
  • ステータス行

• グラフ表示: 単体 / カスタム
  • グラフ(デフォルト): 生の測定値 / トレンド値
  • カスタムグラフ: 複数表示、表示形式変更など

• 管理・設定画面
  • 全センサの状態を数値で一覧表示
  • 各種パラメータの表示・設定

設計方針†

シンプル & 丈夫で長持ち

• スタンドアロン(オンプレミス対応)
  • サーバは河豚板LiveUSB内で完結
  • 内製のWiFi温度センサはサーバと直接通信
  • 表示端末からサーバへもWiFi経由の直接アクセスが可能

• 低依存
  • 他の複雑なシステムになるべく依存しない
  • OSに同梱の要素で構成

• 低スペック
  • 既存の機器を転用可能に
  • 複雑な機能は入れない。シンプルに保つ

ハードウェア†

データ処理サーバ†

---

メーカー製センサ†

• T&D社のおんどとりシリーズに対応。現場での測定はこれを使用

• 温度および湿度を取得可能

• 各センサがクラウドストレージにデータを送信

• サーバはクラウドストレージからセンサ・取得期間を指定してJSON形式のデータを取得し、処理

• APIが開示されていれば、他メーカーの製品も対応可能

内製(自作)センサ

システムに組み込むセンサのプロトタイプとして２式製作。開発サイトにて継続運用中。

実装条件

• 工場内で使用するため、有線配線は使用不可
  • 電源は内蔵、外部電源は使用しない: 単三×3本
  • 測定値の伝送は、無線を使用: WiFi

構成†

• マイクロコントローラ:
  Espressif社 ESP8266 (CPU: Xtensa, WiFi対応)
  ESP-WOOM-02ブレイクアウトボードを使用

• 温度センサ:
  LM61BIZ(アナログ出力)
  →音声ケーブルで延長可能

• 電源:
  LDO AVR (低損失CMOS三端子レギュレータ) NJU7223F33

開発環境:†

• ラズベリーパイ1B上にArduino IDEをインストール

• Arduino core for ESP8266 WiFi chipを追加。
  (コンパイル時にはGCC/Xtensaが呼び出される)

• コーディングはArduinoスケッチにて行う

• ビルド後の実行ファイルは、シリアルにてESP-WOOM-02に転送

設計上の課題と解決†

動作寿命の延長†

• データ取得間隔は約5分、その間ESP8266をDeepSleepさせる
  • 待機時の電流は約53μA (電池寿命は推定約4ヶ月→実測値も同じ)
  • DeepSleep復帰時は、プログラムは最初から実行。変数の値なども保持されない
    • 電源再投入に近い動作/コーディングに工夫が必要
      → ハードコーディング or Flash保存領域 or RTCメモリ領域
  • センサへの電源も直接供給するのではなく、測定の時だけGPOをONにし、そこから供給している

• 未採用の案
  • 前回と測定値が同じであれば、WiFiでのデータ送信をしない
    → センサ故障・データ取得失敗と区別できない
  • WiFiの送信電力を必要十分な値に低減する
    WiFiのモードを指定できるのであれば、ビットレートは低くてもよいので、より低S/Nで通信できるモードを選択する(802.11bなど)
    → その分送信出力を低減できる(可能なら)
    → そもそもDSSS/FHSSでこの理屈は成立するか？
  • 電源の三端子レギュレータを省略して、乾電池直結にする。この場合の電池はアルカリ単三×２ (3.0V)、ニッケル水素×３ (3.6V)など
    → 電池の電圧変動がセンサの出力電圧に影響を与えるため、センサのVSにレギュレータ(UT7500など)を挿入する。
    → 過電圧保護がないが、大丈夫か？
  • 電池の容量/本数を増加
  • ソーラーパネル+スーパーキャパシタ

測定精度の向上†

• 取得値のばらつきを減らす
  • DeepSleep()から復帰してのAnalogRead()の実行タイミングを一定にする
  • 復帰後、短い間隔を置いてデータを数回取得する → 0.1秒間隔で4回取得 → サーバ側で平準化

• 測定精度はESP8266のADC (10bit)の量子化誤差が支配的
  • 未採用の案
    • センサー出力～ADC間にCRの時定数回路を挿入し、現在の4回サンプリングから電圧勾配を推定し、センサー出力を計算
      → 複雑な計算なので、サーバ側で実施 → ハード的にはCRの追加だけ → 複雑な処理に見合った精度が得られるか？
    • ADCを使わず、I2Cなどを用い、かつ、より精度の高いセンサを使用する
      → I2Cにすることで、センサの消費電力は増大？減少？

ソフトウェア†

データ処理サーバ†

全体の構成

冒頭で紹介したように、

• データの取得と処理

• 処理済みデータの保持・アーカイブと取り出し

• グラフ生成

• ウェブUI

の要素から構成される

データの取得と処理†

データの取得 - enc_*.pl (例: enc_ondotori.pl)

データソースから測定値取得 → 所定のフォーマットに変換した上でUnixドメインソケット経由で decdemux.pl に送る
enc_amedas.plは、気象庁アメダスの気温データを取得するスクリプト。アメダスも「センサーの一種」として定義。

処理の中核 - decdemux.pl

enc_*.plからのデータを受信
・データを内部処理に適した形式に変換(Decode & Demultiplex)
・生データを処理
　・4サンプルの平均化(8266センサの場合)
　・生データ→センサごとの補正値で校正
　・FIR/IIR処理 (トレンド計算・グラフ平準化)
　・Min/Max保持
　・重複受信データのuniq
　・etc...
・各センサは設定ファイルで定義された特性を持つインスタンスとして生成され、上記の値を保持する
・処理後の値はデータ保存部に送られ、persistentな値として記録される

処理の制御 - decdemuxctl.pl

dexdemux.plの制御ユティリティ
・設定ファイルの再読み込み
・全グラフの強制描画
・Min/Max値リセットのトリガ
・ログファイルへの追記 / ステータスラインへの表示
・動作の一時停止・再開 (停止中は受信データをバッファリング)
・データ保持部のファイルの再オープン
・センサーデータの個別書き込み
・decdemux.plの停止
これらの機能も「制御コマンド」としてdecdemux.plに送られる。

計算・統計処理 - enc_calcstat.pl

各センサからのデータを元に計算を行うためのプロセス。計算結果は仮想的なノードの測定値としてdecdemux.plにフィードバックされる

週間天気の処理 - fetch_wkwx.pl

気象庁の予報データを取得し、週間天気のHTMLを生成する
・予報文をパースし天気アイコンを生成
　例:　予報文「曇り」→ アイコン <雲(0)> ... 数字はアイコンサイズ
　　:　予報文「曇り時々雨」→ アイコンの並び <雲(0)><雨(-1)>
　　:　予報文「晴れのち曇り時々雪」→ アイコンの並び <太陽(-1)><→><雲(-1)><雪(-2)>
・最低・最高気温
・日付の色 (土日休祝の計算)

処理済データの保持・アーカイブと取り出し†

• 単純にセンサーごとのファイルに書き込み
  • status/<センサー番号> ... センサーの現在の測定値、計算値、特性(定義ファイルの設定値)など
  • log/<センサー番号> ... センサーの測定値の履歴

• 先月以前のデータは圧縮してアーカイブ

• cron + 河豚板のusbfadm syncで定期的に永続ストレージに保存

グラフ生成†

• gnuplotで生成 (SAG (System Activity Grapher)をベースに作成)

• 表示形式の基本 - 生データとトレンド(FIR or IIRフィルタによる処理値)の２つのグラフを描画

• グラフ描画
  • 単一のセンサのグラフ(デフォルト)
  • 複数のグラフの組み合わせ・表示フォーマットの変更など(カスタム表示)

ウェブUI†

• OpenBSD httpd + PHP_FPMを使用
  • ダッシュボード / 各グラフ / 設定画面を表示
  • ESP8266センサの測定データを受ける。計測データはHTTPのGETパラメータとして渡されるので、access.logからdecdemuxctl.plが読み取り、decdemux.plに渡す。

時間軸の表記法 - dt-syntax†

このシステムでは、ある時点を暦や時刻に沿って指定することが多いので、それを直感的に表現しやすい記法 dt-synax (Day Time Syntax)を考案し、ライブラリも作成した。

文法†

書式

/home/sensor/include/dtparser.pm

説明

Perlモジュールdtparser.pmはISO 8601風の日付・時刻の表記形式dt-syntaxを提供する。dt-syntaxの書式は以下のとおり

<dt-syntax> ::= <日時> | <日時><期間>

<日付>の部分はある時点を表わす。基本的にはYYYY/mm/dd,HH:MM:SS形式の表記となるが、以下の定義に示すように省略表示が可能。また、いくつかのキーワードが定義されている。

<日時> ::= <日付>","<時刻> | <日付> | <時刻> | "thisyear" | "thismonth" | "thisweek" | "today" | "now" | <Unix Epoch>
<日付> ::= <西暦>"/"<月>"/"<日> | <西暦>"/"<月> | <月>"/"<日>
<西暦> ::= <４ケタの符号なし整数>
<月> ::= ＜１～２ケタの符号なし整数>
<日> ::= ＜１～２ケタの符号なし整数>
<時刻> ::= <時>":"<分>":"<秒> | <時>":"<分>
<時> ::= ＜１～２ケタの符号なし整数>
<分> ::= ＜１～２ケタの符号なし整数>
<秒> ::= ＜１～２ケタの符号なし整数>
<Unix Epoch> ::= <符号なし整数>

thisyear, thismonth, thisweek, todayは、今年、今月、今週の日曜、今日、それぞれの最初の秒を表す。
nowはこのモジュールがset_basetime関数で初期化された時点を表している。「パーザが呼び出された今現在」という意味ではないことに注意。これは、dt-syntaxのパーザがある時間間隔を置いて呼び出された場合、その途中で月や日などが変わり、その結果、同じ引数が異なる結果を返してしまうことがないようにするためである。
なお、Unix Epoch以外の表記はこのモジュールが呼び出された環境のローカル時間を表わす。ローカルタイムゾーンの明示的な表記は現時点では定義されていない。

<期間>の部分は、<日付>からある時間だけ離れた時点を表す。

<期間> ::= <オフセット> | <期間><オフセット>
<オフセット> := <数値><期間単位>
<数値> ::= <符号><符号なし整数> | <符号なし整数>
<符号> ::= "+" | "-"
<期間単位> ::= "Y" | "m" | "d" | "V" | "H" | "M" | "S"

<期間単位>はそれぞれ、年、月、日、週、時、分、秒を表わす。Unixのstrftime(3)関数の表記に準拠している。

<符号>は、+が未来方向、-が過去方向を表わす。 上の定義から分かるように、期間はオフセットを１回以上繰り返すことができるがこの場合の符号の意味は以下のようになる。

-1m3V12H は -1m-3V-12H と等価
+1m3V12H は +1m+3V+12H と等価
+1m-3V12H は +1m-3V-12H と等価

つまり、オフセット部の符号が省略された場合は、直前の符号を引き継ぐ。

例

12:3 ... 本日の12時3分0秒

today-1V+15H30M ... 一週間前の日の15時30分0秒

1600788674-2V+15d ... 2020年9月24日 0時31分14秒 (日本標準時)

使用例†

dt-syntaxは、システムの随所で使われているが、手動でグラフを生成するコマンドspangraph.shを例に説明してみる。
spangraph.shは、コマンドライン引数でdt-syntaxを用いて描画期間を指定する。

spangraph.shの書式

spangraph.sh [オプション] 開始日時 終了日時|描画期間 センサ番号[,センサ番号...]

使用例

2020年8月のセンサ15のグラフを生成

$ spangraph.sh 2020/8 2020/9 15
または
$ spangraph.sh 2020/8 1m 15

先々月の初日から一週間分のセンサ7,センサ8のグラフを生成

$ spangraph.sh thismonth-2m 1V 7,8

2020年のセンサ3のグラフを月毎に生成

$ jot 12 | xargs -I % spangraph.sh 2020/% 1m 3

背景色を白色に変更し、測定データとトレンドをプロットする本日分のグラフを生成

$ spangraph.sh -c bg-white -p with-trend today now 15

ファイル名を「年月日,時分」形式に変更して昨日分のグラフを生成

$ spangraph.sh -o %y%m%d,%H%M today -1d 15

ユーザの声†

• 温度を数値だけでなくグラフで傾向をつかめるのは助かっています。

• webインターフェイスを用意してもらったおかげで、現場のおっちゃん達にもテレビやiPadで便利に使わせてもらっております。

• 天気予報がわかるのは空調の強さを検討するために、また納品日を検討するのに地味ですが便利です。

• グラフができればマウスホバーで数値が表示されるようなAJAX的な感じだと良いかな、と思いますが費用がかかるので現状で大丈夫です。（読み取れば良いので）

• 期待した内容を実現していただいたので、現状で満足しております。

• お金に余裕があれば、もう1セット作ってもらいたいと思っていますが、現状工場間で温度計を移動するくらいで足りており、、

終わりに†

このシステムは、2020年の運用開始から、途中、おんどとりクラウドの障害や、気象庁サイトのリニューアルなど、いくつかのイベントがありましたが、現在に至るまで、年一回のOSアップグレードを行いながら、不具合もなく運用できています。

安定した運用ができている要因として、以下のようなこと考えられます:

• シンプル & 丈夫で長持ちな設計方針が、想定した環境や運用規模での運用にフィットしていた

• また、その環境や運用規模が河豚板をベースとした運用にもなじんでいた

• 当初の打ち合わせで仕様を適切に打ち合わせでき、また、その後の細かい使用変更にもスムーズに対応できた

• これには、ユーザの担当窓口の方がシステムの開発事情について肌感覚で理解していただいたことも大きい

クライアントサイドでの高機能化(マウスホバーで数値表示)や、セット増設などの課題も提示していただきましたが、もし、それらを実際に行う際は、基本の設計方針を保ちつつ、機能強化を行ってゆければと思っています。

recent(50)