「1 分間通信がなければアラート」は作れるか — LTE-M 機の死活監視はサンプリング周期で決まる

前回、IoT ゲートウェイのセッションが Deleted → Created を繰り返す現象を 4 層で切り分ける話を書いた。その続きで、こういう質問をもらった。

SORACOM 側で、1 分間 SmartFitPRO から通信がなかったらアラートを出す、ということはできますか？

答えは「できる。そして電源方式によって、妥当な設計かどうかが逆転する」だ。

閾値を決めているのは SORACOM 側ではなく、デバイスのサンプリング周期という 1 個のパラメータである。SmartFitPRO はこれが出荷時 10 秒に設定されていて、USB / DC 給電ならそのままでよく、1 分の死活監視は周期の 6 倍という妥当な比率になる。一方で電池運用に切り替えると、10 秒のままでは約 33 分で電池が終わるため周期を延ばすしかなく、延ばした結果として前回の記事で書いた Deleted → Created が必ず出るようになる。

同じ「1 分」という数字が、片方では良い設計で、片方では成立しない。その分かれ目を数字で追う。

SORACOM 側は「データが来ない」をアラートにできる

まず SORACOM 側の話から。SORACOM Lagoon 3 の Alert rule には、データが存在しない場合の扱いを決める設定項目がある。名前は Alert state if no data or all values are null で、ここを Alerting にすれば「データが来ていない」がそのまま発火条件になる。

Alert rule の主な設定項目はこうなっている。

Evaluate every は 10 秒の倍数なので 1m は指定できる。ここだけ見れば「1 分間データが来なければアラート」は作れる。

ただし落とし穴が 1 つある。Lagoon は指定間隔で Harvest Data からデータを取得しており、その取得間隔がプランごとに違う。

評価範囲を取得間隔より now に近く取ると、Lagoon がまだデータを取得しておらず No data と判定されてしまう。Free プラン（取得間隔 60 秒）で now-1m を評価範囲にするのは、ちょうどこの境界を踏む設定だ。1 分でやるなら Maker 以上にするか、評価範囲を少し広げる。

なお、イベントハンドラーでは 1 分はできない。 ルールタイプに SimSessionStatusRule があり Created / Deleted を拾えるが、Deleted が出るのは無通信タイマーが満了した後だ。この時間は 1 分ではない。

閾値を決めるのはデバイス側の「サンプリング周期」

SORACOM 側は好きな閾値を設定できてしまうので、妥当性はデバイス側が決める。SmartFitPRO には旭光電機が公開しているパラメータ設定手順書があり、変更できるパラメータが表になっている。

変更は Windows PC 上の設定ツールから行う。USB で接続して設定モードに入ると、USB 横の状態表示用 LED が 500ms 周期で緑点滅する。設定ツールは旭光電機の資料ダウンロードページで配布されている「設定ファイル_SmartFitPRO_〜」の zip に同梱されている。

1 点注意があって、手順書には「一部パラメータはキーワードで保護されています。変更が必要な場合はお問い合わせください」という注記がある。取扱説明書側にも定期送信について「※定期送信時間を変更されたい場合はお問い合わせ願います」とあるので、手元でどこまで変えられるかは実機で確認したほうがいい。サンプリング周期は変更可能パラメータ一覧に載っている項目だが、保護対象かどうかは実物のツールを開くのが確実だ。

出荷時 10 秒が意味すること

サンプリング周期が決まると、そこから連鎖的に 4 つのことが決まる。

USB / DC 給電なら、1 分アラートは妥当な設計

出荷時の 10 秒周期に対して、閾値 1 分は周期の 6 倍にあたる。死活監視の閾値は周期の 2〜3 倍以上に置くのがセオリー（1 回の取りこぼしで鳴らすと電波の揺らぎで誤報を量産する）なので、6 倍は十分な余裕がある。1 分以内に 6 回来るはずのデータが 1 度も来ていない、というのは強いシグナルだ。

さらに副次的な効果として、セッションが張られ続ける。plan-D の無通信タイマーは 1 時間で、10 秒周期はそこに到達しない。つまり前回の記事で扱った Deleted → Created の churn は起きない。

これは裏を返すと診断に使える。USB 給電でサンプリング周期が数十秒のまま Deleted → Created が出ているなら、それは無通信タイマー満了ではない。 前回書いた「送信周期と一致する Deleted」という正常パターンには当てはまらないので、4 層の切り分けフローに戻って、無線区間・コア網・デバイス側の電源を疑う番になる。セル ID が変わっているか、device_state がエラーを示していないか、というあたりだ。

考慮すべきは電池ではなくデータ量になる。10 秒周期は 1 日 8,640 回で、1 時間周期の 360 倍だ。1 回のペイロードは小さいが、plan-D は従量課金なので、周期を詰めるほど通信量が増える。1 分周期（1 日 1,440 回）でも死活監視の閾値を 3 分に置けば十分機能するので、10 秒のままにする必要が本当にあるかは検討の余地がある。

電池運用に切り替えると、話が反転する

一方、電池で動かす場合。SmartFitPRO Basic の電気仕様を取扱説明書から引くと、こうなっている。

連続稼働時間が日数ではなく送信回数で書かれている点に注目したい。これは表記の都合ではなく、この機器の電池寿命が経過時間ではなく送信回数で決まることを意味している。待機時 100μA は、置いておくだけならほとんど減らない水準だ。電池を食うのは LTE の起動・送信・切断を 1 回やること自体である。

つまり 200 回という送信予算があり、サンプリング周期を決めた瞬間に稼働日数が決まる。そして出荷時の 10 秒をそのままにすると、200 回 × 10 秒 = 約 33 分で電池が終わる。電池運用では周期の変更が必須になる。

ここで前回の記事と話がつながる。plan-D の無通信タイマーは 1 時間だ（SORACOM のサブスクリプション一覧に明記されている。plan01s や planX3 は「1 時間または 4 時間」で、ランデブーポイントがフランクフルトかシドニーなら 1 時間、それ以外は 4 時間という条件付き。なお「セッションの無通信タイマーは予告なく変更される可能性があります」という注記も付いている）。

電池で実用になる周期は、上の表のとおり数時間から 1 日だ。そしてそれは必ず 1 時間より長い。したがって、

• 送信 → セッション確立
• 1 時間の無通信で Deleted
• 次の送信タイミングで Created

が毎周期繰り返される。電池運用を選んだ時点で、ログに Deleted → Created が並ぶことは確定している。 これは異常ではなく、前回書いた正常パターンそのものだ。

給電モデルを選ぶ場合、待機電流が桁で違う点も押さえておきたい。

Basic の待機 100μA に対し Standard は 35mA で、350 倍ある。この差が「電池で動くかどうか」を決めていて、逆に言えば Standard / Advance は常時給電が前提なので周期を詰めても電池の心配はない。無線モジュールは Basic / Standard / Advance すべて LTE-M（Cat.M1）が選べ、Advance だけ LTE（Cat.1）も選べる。

異常検知と死活監視は別のアラートにする

どちらの電源方式でも共通して効くのが、送信契機の区別だ。

SmartFitPRO が Harvest Data に送る JSON には message_type が入っていて、3 つの契機を区別できる。

送信データは JSON で、ほかに Devicetype、fw_ver、Timestamp（UNIX エポック秒）、device_state（正常 0 / エラーあり 1）、di0（0: 開 / 1: 閉）が入る。

重要なのは 0003 の接点変化送信が、変化した時点で飛ぶことだ。サンプリング周期を待たない。つまり「異常を早く知りたい」という要求は、死活監視の閾値とは無関係に満たされている。

分けて組むとこうなる。

• Alert rule ①（異常検知） — di0 の変化を条件にする。接点変化は即時に飛ぶので、検知はサンプリング周期に依存しない。for: 0 で 1 回で鳴らしてよい
• Alert rule ②（死活監視） — Alert state if no data or all values are null を Alerting にし、評価範囲を now-(サンプリング周期 × 2〜6) にする。ここは遅くて構わない

1 本のアラートで両方を兼ねようとすると壊れる。 たとえばサンプリング周期を 6 時間に延ばした電池運用で「1 分データが来なければ鳴らす」を残していると、常時発火する。異常が起きていなくても鳴り続けるので、本当の異常が埋もれる。アラートは「異常が起きたら鳴る」ではなく「異常が起きていないときは鳴らない」を満たすように設計する。この観点はSLI/SLO の設計と同じで、監視対象の正常な挙動を先に定義しないと閾値は決まらない。

死活監視の閾値を決める手順

一般化するとこうなる。LTE-M / LPWA 機に限らず、周期送信するデバイス全般に使える。

1. 電源方式を確認する — ここが最初。給電なら送信予算に制約はなく、電池なら総送信回数が上限になる。仕様が「回数」で書かれていたら、寿命は時間ではなく回数で決まっている
2. サンプリング周期を決める — 給電なら要求する検知遅延から決められる。電池なら「総送信回数 ÷ 必要稼働日数」で決まってしまう。順番が逆にならないように
3. 周期を無通信タイマーと比べる — 周期のほうが長ければ、Deleted → Created が毎周期出るのが正常な状態になる。plan-D なら 1 時間が境界
4. 閾値を周期の 2〜6 倍に置く — 絶対時間ではなく倍数で決める。1 回の取りこぼしで鳴らさない。検知遅延はここで確定し、原理的に周期より短くはできない
5. その遅延で困る要求を、別のアラートに分離する — 即時性が要るものは、周期送信ではなくイベント駆動の送信（接点変化など）で拾う

「1 分ごとに知りたい」という要求から出発すると、デバイスが選べなくなる。電源方式 → 周期 → 閾値 → 検知遅延の順に決めて、足りない部分だけをイベント駆動で埋めるというのが素直な組み立てだ。

まとめ

• Lagoon 3 の Alert state if no data or all values are null で「データが来ない」はアラートにできる。Evaluate every は 10 秒の倍数
• ただし評価範囲をプランのデータ取得間隔（Free 60 秒 / Maker 30 秒 / Pro 5 秒）より now に近く取ると No data 判定になる
• 妥当な閾値を決めているのはデバイス側の サンプリング周期。SmartFitPRO は出荷時 10 秒（設定ツールで変更可、ただし一部パラメータはキーワード保護あり）
• USB / DC 給電なら 1 分アラートは妥当。周期の 6 倍で余裕があり、セッションも張られ続けるので前回の Deleted → Created は起きない。逆にこの構成で出ているなら別の原因を疑う
• 電池運用では周期を延ばすしかない。出荷時 10 秒のままでは約 33 分。実用域は必ず plan-D の無通信タイマー 1 時間を超えるので、Deleted → Created が毎周期出るのは正常
• 異常検知（0003 接点変化・即時）と死活監視（0002 周期・遅い）は別の Alert rule にする

「1 分間通信がなかったら」という要求は、たいていの場合「異常を 1 分以内に知りたい」の言い換えだ。給電構成ならそれは素直に実現できるし、そうでなくても接点変化送信を使えば死活監視を 1 分にしなくても満たせる。要求を実装に翻訳する前に、要求そのものを分解したほうが早い。

参考リンク

• Alert を管理する: Alert rule を設定する | SORACOM Lagoon 3
• はじめに: SORACOM Lagoon 3 のプランとライセンスパック | SORACOM Lagoon 3
• はじめに: サブスクリプションの種類 | SORACOM Air for セルラー
• リファレンス: ルールタイプ一覧 | イベントハンドラー
• SmartFitPRO パラメータ設定手順書（旭光電機）
• SmartFitPRO 取扱説明書（旭光電機）
• SmartFitPRO | 旭光電機株式会社
• IoT ゲートウェイ SmartFitPRO Basic スターターキット | SORACOM IoT ストア