IoT — 42 個の冷凍庫センサーによるコールドチェーンモニタリング

25 分。2 つの CSV。コールドチェーン倉庫の夜間 ops マネージャを演じ、温度がスパイクしている冷凍庫を見つける。

更新 2026-04-17

業界: IoT / コールドチェーン 難易度: 中級 時間: 25 分 プラン: ライブ MQTT は Pro 以上

シナリオ

あなたは NorthChain Warehouse の夜間 ops マネージャ、40+ ブランドの冷凍商品を保管するコールドチェーン 3PL。4 部屋にまたがる 42 冷凍庫、各々が 5 分ごとに温度をパブリッシュ。任意の冷凍庫が −15°C を 30 分以上超えると、顧客の商品がリスクにさらされ、契約に金銭ペナルティがあります。

今モニタリングがありません — 毎朝スプレッドシートエクスポートをチェックする人がいます。その人があなたで、疲れています。

このチュートリアルは CSV エクスポートを開始点として使用。動作したらライブ MQTT に切り替えます(次のステップを参照)。

4 つの質問:

  1. 今、仕様外の冷凍庫はあるか? — 現在状態チェック。
  2. どの冷凍庫が温暖化トレンドか — まだ壊れていないが、その方向に向かっている?
  3. 死んでいるセンサーはあるか — 直近 1 時間に読み取りなし?
  4. 3 つすべてにアラートできるか — 24/7、Slack + 深夜 SMS にルーティング?

サンプルデータのダウンロード

約 169,000 行 · 14 日
telemetry.csv
冷凍庫ごとの 5 分間隔の温度。door_open フラグを含み、データに 3 つの現実的な問題が隠されています。
42 行
freezers.csv
冷凍庫メタデータ — 部屋位置、目標温度、アラーム閾値、設置日。

両方をチャットにドロップ。Free プランで telemetry.csv(約 8 MB)は 1 分未満でインポート。

01

今、仕様外のものはあるか?

冷凍庫ごとの最新読み取り vs アラーム閾値。
プロンプト
各冷凍庫について、最新読み取りのタイムスタンプと温度を見せて。freezers.csv と JOIN してアラーム閾値を取得。閾値を現在超えている冷凍庫、または最新読み取りが 30 分以上古い冷凍庫(センサーが死んでいる可能性)をフラグ。
northchain · 冷凍庫ステータス
ステップ 1 · 期待される答え
Tablize
sql.query · latest reading per freezer × alarm threshold join 312 ms
42 冷凍庫のうち 2 つに注意が必要。F-0032 は 18 時間読み取りなし — センサーがオフラインの可能性。F-0017 は現在 -14.8°C、-15°C 閾値を超過。
冷凍庫部屋最終読み取り温度ステータス
F-0032cold-room-218 時間前センサーオフライン
F-0017cold-room-21 分前-14.8°C閾値超過
F-0001 …cold-room-1約 1〜5 分前約 -18°Cok(40 冷凍庫)
· ステップ 1 — F-0032 オフライン、F-0017 現在違反中
02

温暖化トレンドの冷凍庫

早期警告 — 直近 72 時間で温度が上昇している冷凍庫、まだアラーム未満でも。
プロンプト
各冷凍庫について、直近 3 日の各日の 24 時間ローリング平均温度を計算。ローリング平均がその期間に 1°C 以上上方ドリフトした冷凍庫をフラグ。

Agent が浮かび上がらせる: F-0017 は 3 日間 -15°C を断続的に超えてスパイク — 「最新読み取り」ビューで一貫して表示するには十分でないが、トレンドを見ると明らかに病的。コンプレッサ故障またはデフロストサイクルバグの可能性。激しく故障する前にメンテナンスをスケジュールする価値あり。

保存: + 日次 Report として保存 — 朝、その週の温暖化トレンドリストを受け取ります。

03

センサーヘルスチェック

死んだセンサーは死んだ冷凍庫と同じくらい悪い — 見えないものはモニタリングできない。
プロンプト
各冷凍庫について、直近 24 時間の期待読み取り数を計算(5 分ごとに 1 = 288)。実際のカウントを見せて。250 未満の冷凍庫をフラグ — それはセンサーまたはネットワーク問題。

Agent が 42 冷凍庫すべてを読み取りカウント不足でランク付け。F-0032 は直近 18 時間で 0 読み取りを示し、これはステップ 1 ですでに捕まえられました — ただしこのクエリは部分的停電(例: 5 分ごとではなく 15 分ごとの読み取り)も捕まえます。

保存: + Script として保存 — 再利用可能な週次センサーヘルス監査。

04

深夜 Watch をセットアップ

3 つの故障モードすべてをカバーする 1 つのアラームルール。重大度でルーティング。
プロンプト
5 分ごとに走る always-on Watch を作成。アラート: (a) 任意の冷凍庫の最新読み取りが閾値を 30 分以上超えている(critical — Slack + SMS)、または (b) 任意の冷凍庫のローリング 24h 平均が 72h で 1°C 以上上昇した(warning — Slack のみ)、または (c) 任意の冷凍庫に 60 分間読み取りがない(センサー問題 — Slack のみ)。クワイエットアワーは適用しない。

Agent が 3 つのサブ条件を持つ Watch を作成、各々を異なるルーティング。一度テスト発火 — テストで F-0017 と F-0032 がトリガー。

保存: + Dashboard を構築 — 部屋で色分けされた冷凍庫ごとのライブ温度を表示するショップフロアスクリーン。コントロールルーム TV で全画面で開く。

25 分で構築したもの

  • 1 Report — 日次温暖化トレンドウォッチ。
  • 1 Script — センサーヘルス監査、週次。
  • 1 Watch — 三方向アラーム(critical / warning / センサー問題)、重大度ルーティング付き。
  • 1 Dashboard — ライブショップフロアスクリーン。

24/7 コールドチェーンモニタリングを得ました。夜シフトはスプレッドシートをチェックしません。何かおかしいときだけ Slack 通知を得ます。センサーオフラインケースは捕まえるのに数時間かかりましたが、今は 60 分以内に Slack に届きます。

次のステップ: CSV からライブ MQTT へ切り替え

このチュートリアルの CSV 版は静的データパス。ライブで動かすには:

  • デバイスを Tablize の MQTT ブローカーに向ける。 IoT、MQTT、カメラ を参照 — 認証情報、トピックフォーマット、QoS。
  • ライブテーブルとして再取り込み。 デバイスがパブリッシュすると telemetry テーブルが埋まり始めます。CSV で構築したすべての Report / Watch は動作を続けます — 同じテーブル名をクエリします。
  • Dashboard でプッシュを有効化。 5 秒リフレッシュを MQTT プッシュにスワップ — コントロールルームスクリーンでサブ秒更新。
  • Spatial UI を追加。 Space → 部屋 → 冷凍庫 → 温度 Point。Tablize の Asset Graph が、ライブ状態、タイムトラベルスライダー、カメラを配線すればカメラオーバーレイを持つすべての冷凍庫のクリック可能マップを提供。

シミュレータ — 実ハードウェアなしで MQTT フローをテストしたい場合、scripts/docs-samples/iot-simulator.py(近日公開)が telemetry.csv データをローカル MQTT ブローカーにリアルタイム速度で再生します。

この業界の次のステップ

  • IoT、MQTT、カメラ を読む — カメラフィードと時間再生を含むフルリファレンス。
  • 製造チュートリアル を読む — 工場設定の IoT、同じプリミティブ、異なるユースケース。
  • Federation を探索 — 複数倉庫を運用している場合、各ワークスペースが自分のデータを所有。フェデレーションが単一ロールアップビューを提供。

近隣のチュートリアル

  • 製造 — 工場の機械テレメトリ。
  • 物流 — 保管するものが出荷される必要があるとき。