IoT監視と機器の管理

冷蔵庫、倉庫、店舗、生産設備を、ブラウザから把握する

機器は現場にあり、あなたは事務所にいます。私たちはそこにセンサーを付け、インターネットにつなぎ、指標をブラウザで開く一つの画面へ集めます。温度が正常の範囲を外れた、扉が開いたままになった、電源が落ちた — 責任者は、傷んだ商品を見て朝に知るのではなく、その場で連絡を受け取ります。

システムが行うこと

IoT監視

平たく言えば、機器に小さな装置を付けます。それが大切なことを絶えず測ります — 庫内の温度、扉が開いているか、電気は来ているか、圧縮機は動いているか。一分に一度、その測定値がインターネット経由でサーバーへ送られます。あなたはブラウザを開き、すべての拠点の機器一台ごとの状態を見ます。

IoT は「モノのインターネット」の意味です。要は、人が手帳を持って回って値を書き写すのではなく、機器自身がそれをプログラムへ送るということです。そのために何かをする必要はありません:データは自ら、夜も休日も含めて二十四時間届きます。

数字が並ぶだけの画面との一番の違いは、システムが誰かの視線を待たないことです。あなたがその機器に定めた正常の範囲と、測定値を自ら比べます。範囲を外れれば — その現場の責任者を一覧から見つけ、その人へ連絡します。

例。 倉庫の冷凍庫は−18 °Cまでが正常とします。21:04にセンサーが−16.8 °Cを送ります。その時、画面を見ている人は誰もいません。15分後も温度は上がり続けます — システムは出来事を作り、そこに庫の番号、倉庫の住所、時刻、現在の値を記録し、倉庫の当番へ連絡を送ります。21:33に当番が到着し、前室の扉がきちんと閉まっていないのを見つけます。商品は無事です。

その際、機器を取り替える必要はありません。冷蔵庫、自動販売機、ポンプ、換気設備はそのままで — そこに、それらが持っていないものを足します:センサー、通信の装置、そして機器全体を一つの一覧で見られるプログラムです。

どのプロジェクトも三つの問いから始まります: その機器で物理的に何を測れるのか。データは現場からどうやってインターネットへ出るのか。逸脱に誰が責任を持ち、何分以内に対応すべきなのか。三つ目の答えが出ないうちは、数字の並んだきれいな画面はできても、何かを未然に防ぐシステムにはなりません。

監視と画面上のグラフの違い一つの観点による整理
何が実現されているかそれは何か
指標が画面にリアルタイムで表示される観察
指標が正確な時刻とともに履歴に保存される土台
正常の範囲からの逸脱が、独立した出来事として記録される土台
出来事に、特定の社員と対応の期限がある監視
社員の対応が記録され、出来事が完了する監視

境目は二つのことで決まります:出来事に人がいることと、期限があることです。現在の温度を映す画面は、それ自体では何も救いません — 誰かが調べるよう割り当てられないうちは、逸脱はグラフ上の線のままです。そのため、正常の範囲、責任者、対応の期限、完了の記録は、「お好みで」の設定ではなく、システムの必須の項目です。

オペレーターが、統合パネルで遠隔の冷却設備の状態と逸脱のキューを把握している

実務で何が得られるか

  • すべての機器を一つの一覧に — 別々の住所にある、メーカーの異なる冷蔵庫、自動販売機、設備が、四つのメーカー製プログラムではなく一つの画面に
  • 社員は問題のある場所へ向かう — 全拠点を順に回る代わりに、住所と特定の機器の番号を受け取ります
  • 記憶ではなく記録による検討 — 一か月後でも、逸脱が何時に始まり、どれだけ続き、誰が対応したかが分かります
  • 損失の前の対応 — 温度の上昇は、商品を廃棄せざるを得なくなる数十分前に気づけます
  • 保管条件の証明 — どの庫についても一か月分の温度のグラフを出力でき、検査や取引先に示せます
  • 一部の操作はブラウザから直接 — たとえば、機器のコントローラーがその指示を受け付けるなら、設定温度の変更

できることの境目を決めるのはプログラムではなく、機器そのものです:取得できるのは、機器が測っているものか、センサーで測れるものだけ。変えられるのは、そのコントローラーが許すものだけです。御社の機種で何ができるかは、メーカーの資料をもとに事前調査で明らかにします。

仕組み:センサーから 社員への連絡まで

一つの測定値がたどる道のり全体 — 冷蔵庫の装置から、携帯への連絡まで。以下ではこの六つの環を、それぞれより詳しく説明します。

冷蔵庫が、センサー、コントローラー、サーバーを介してオペレーターの作業の場とつながっている

1. 機器

見守る対象:保冷室、陳列棚、冷凍庫、自動販売機、ポンプ、換気設備、生産ライン。一台ごとにシステムへカードとして登録します — それが何で、どの現場にあり、どのような仕様で、いつ保守したのか。

2. センサーとコントローラー

測る装置です。センサーは一つの量を測る小さな装置です:温度、湿度、圧力、電流、扉が開いているか、電圧があるか。コントローラーは機器自身の「頭脳」です:機種によっては自らの値やエラーの符号を外へ伝えられ、その場合は余計なセンサーは不要です。できない場合は、こちらのセンサーを付けます。

3. データの送信

値がどうやってインターネットへ入るか。現場に小さな通信の装置を置きます:センサーから測定値を集め、インターネットのケーブル、Wi-Fi、またはSIMカードでサーバーへ送ります。インターネットが切れれば — 測定値はその装置の記憶にたまり、通信が戻ったときに送られます。装置が黙っていること自体も、警報として扱われます。

4. クラウドのサーバー

データの居場所です。サーバーは、保護されたデータセンターで二十四時間動く計算機です。「クラウド」とは、それがあなたの事務所にはないという意味です:購入も、冷却も、保守も要らず、プログラムへはどこからでもつながります。サーバーは測定値を受け取り、履歴に保存し、正常の範囲と照らし、逸脱を出来事に変えます。

5. 監視のパネル

あなたが見るプログラムです。パソコンでも携帯でも、ブラウザで利用者名とパスワードから開きます — 何も導入する必要はありません。一つの画面に、現場、機器、現在の指標、未完了の逸脱の一覧が並びます。メーカーの異なる機器も同じ見た目になります。

6. 連絡、レポート、指示

この連なりの結果です:特定の社員への連絡、検討のためのグラフと記録、月次のレポート、そして — コントローラーが許す場合には — パネルから直接、機器の設定を変えること。

一つの測定値の道のり保冷室の温度
  • センサー一分に一度、庫内の温度を測り、正確な時刻とともに値を記録します
  • 通信の装置測定値を集めてインターネットで送ります。通信がなければ — 自分の中に保持し、後から送ります
  • クラウドでの受信サーバーは、どの装置からどの単位で届いたかを確認し、記録を保存します。以前の記録は消しません
  • 正常の範囲との照合値を、その庫の許容される範囲と、温度の変化の速さと照らします
  • イベント範囲を外れた — 記録が作られます:何が起き、どの機器と現場で、いつ始まり、今いくつなのか
  • 連絡その現場の責任者へ送られます。出来事は、誰かが対応して完了させるまで開いたままです

測定の頻度と許容の範囲は、網全体に一つの数字ではなく、機器の種類ごとに個別に定めます。冷凍庫と、調理済み食品の陳列棚と、倉庫の保冷室では、正常な温度も、そこを外れてよい時間も異なります。

冷却設備を

絶えず把握する

冷却は、監視が最も早く見合う分野です。条件の逸脱が目に見えないからです。夜の間わずかに開いた扉に朝まで誰も気づかず、朝にはもう、結論はあなたの代わりに出てしまっています。

例。 金曜の夕方、冷凍庫の圧縮機が止まります。夜のうちに商品が解け、土曜に一部を再び凍らせ、月曜にその一群を廃棄します。監視があれば、故障の連絡は金曜の21:00に届き、話は保守業者を呼ぶだけで済みます。

その際、機器はさまざまです。冷凍庫と調理済み食品の陳列棚では、許される温度も、それを外れる速さも、誤りの代償も一致しません。そのため正常の範囲は網全体に一つではなく、中に何が入っているかを踏まえて機器ごとに定めます。

冷却設備から取得できること:

  • 温度 — 定めた頻度での現在の値を、庫内の一点、または複数の点で
  • 温度の変化の速さ — 「今いくつか」だけでなく「どれだけ速く変わっているか」も:ゆるやかな流れと急な跳ね上がりは、別々の不具合を意味します
  • 扉の開閉 — いつ開き、いつ閉じ、どれだけ開いたままだったか
  • 圧縮機の動作 — 動いているか止まっているか、どのくらいの頻度で、どれだけの時間動くか
  • 電源 — 機器に電圧が来ているか、どの時点で落ちたか
  • コントローラーのエラー — コントローラーが対応していれば、設備自身が伝える不具合の符号
  • 通信の有無 — 装置が時間どおりに通信してきたか、許容より長く黙っているか

何が取れるかは機種によります。標準のコントローラーが値とエラーの符号を外へ出すなら — システムはそれを直接読みます。出さないなら — 温度、扉、電源の外部センサーを付けます。御社の機器で何ができるかは、あらかじめ約束するのではなく、その資料をもとに事前調査で判断します。

業務用冷蔵庫に、温度センサー、扉の監視、テレメトリーの装置が備えられている

なぜ一つの数字では足りないのか

  • 範囲と時間はひと組で — 商品を入れるとき温度は数分上がります。それは正常です。同じ温度が四十分後も続いていれば、それは障害です
  • 変化の速さ — 一時間に一度の上昇と、五分での跳ね上がりでは、必要な対応が違います
  • 扉との関係 — 扉が開いた状態での温度上昇と、閉じた状態でのそれは、別の問題であり、宛先も別です
  • 除霜のサイクル — 通常の除霜では温度は自然に上がります。システムはそれを知っていて、数時間おきに誤った警報を出さないようにしなければなりません
  • 電源の喪失 — 大切なのは事実そのものではなく、庫がどれだけもつのか、どの時点で商品を運び出すべきなのかです

そのため正常の範囲は、機器の種類と中の商品に合わせて設定します。それをしなければ、連絡は絶えず届くようになり、社員はそれを開かなくなります — そしてシステムは空回りします。

どのような冷却設備が 接続できるか

これらのグループで使う装置は、おおむね同じです。違いは、許される条件、誤りの代償、そして連絡の宛先です。仕組みはどれも同じです:機器の一台、現場、指標、正常の範囲、出来事、責任者。

棚、区画ごとのセンサー、外部の産業用コントローラーを備えた冷凍室

マイクロマーケットの冷蔵庫

販売員のいない拠点です:扉が閉まっていないことも、設備が止まったことも、気づく人がそもそもいません。機器はオフィス、工場、コワーキングにあり、社員は数日に一度来ます。ここでは温度と扉の把握が、問題を時機を逃さず知る唯一の方法です。

冷凍庫

深い低温と大きな冷えの蓄えがあります:逸脱はゆっくり進み、発覚するのは一群まるごとが傷んだときです。温度、それが範囲外に留まる時間、圧縮機の動作、除霜を把握します。

冷蔵の陳列棚

売り場では一シフトに何十回も扉が開き、条件は絶えず崩れます。そのため大切なのは範囲を外れたこと自体ではなく、それがどれだけ続き、一日に何度繰り返されるかです。

保冷室

容量が大きく、温度の異なる区画が複数あります:一点の測定では庫を表せません。センサーを複数付け、扉と電源は別に把握します — 庫が止まれば、一つの棚ではなく中身のすべてを失うからです。

倉庫の冷却設備

一つの現場に複数の庫と設備があり、交替制で二十四時間動きます。区画ごとの責任の分担、長い履歴、そして月次または四半期の条件遵守のレポートが必要になります。

店舗の機器

同じ機器を備えた拠点の網です:別々の住所にある何十もの陳列棚と冷凍ケース。ここでの価値は比較にあります — どこで逸脱が繰り返されるのか、どの拠点が慢性的に条件を外れるのか、どの一台が修理の時期なのか。

レストランと工場

原材料と完成品の保管で、条件は便宜ではなく要件です。連絡に加えて、証明できることが必要になります:庫ごとの期間のグラフと、誰がどのように逸脱へ対応したかの記録です。

何も伝えない機器

別の一群として、コントローラーがそもそも外部とのやり取りを想定していない設備があります。それらは外部センサーで接続します:温度、扉、電源、消費電流。「賢い」設備より得られるデータは少なくなりますが、肝心のこと — 条件、扉、電源、圧縮機の動作 — は分かり、そうした一台も共通の一覧に他と並びます。

何を把握し

それがいつ警報になるのか

どの指標もシステムの中で二つの形を持ちます。一つは値そのもので、これは単に履歴に保存されます。もう一つは規則です:どの値のときに、何分続いたら、誰かに知らせるべき逸脱になるのか。

例。 冷凍室の−16 °Cという温度は、毎分、常に保存されます。連絡が送られるのは、それが−18 °Cを超えたまま十五分以上続いた場合だけです。

取得し、把握するものの全一覧:

  • 温度 — 測定点ごとの現在の値を、その機器の種類に定めた頻度で
  • 温度の変化 — どちらへ、どれだけ速く動いているか:上がっているか、下がっているか、正常の範囲で揺れているか
  • 許容値からの逸脱 — その一台に許された範囲より暖かくなったか、冷たくなったか
  • 機器の状態 — 稼働中、停止中、保守中、障害中、通信なし
  • 圧縮機の動作 — 動作中か停止中か、どれだけ動き、どれだけ休むか
  • 扉の開閉 — 開いたという事実、開いた時刻と閉じた時刻
  • 扉が長く開いたまま — 一度の開放が、許容される時間より長く続いている
  • 電源 — 機器に電圧が来ているか
  • 電源の喪失 — いつ落ち、どれだけなく、いつ戻ったか
  • コントローラーのエラー — 機器自身が伝える符号を、その機種の資料に基づいて読み解いたもの
  • 障害の状態 — 最も高い優先度と独自の通知の規則を持つ、別のまとまり
  • 除霜の必要性 — その機器で得られる手がかりから:コントローラーの信号、稼働時間、温度のサイクルの様子
  • 稼働のサイクル — 期間中に設備が何回、どれだけの時間動いたか、合計で何時間稼働したか
  • 通信の途絶 — 装置が許容の間隔より長く通信してこなかった

通信の途絶は些細なことではなく、れっきとした障害です。 黙っている装置は「データがない」ではなく「その現場について何も分からない」を意味します。そこの温度は正常かもしれませんし、もう一時間上がり続けているかもしれません。そのため通信の途絶は、グラフに空白を残すのではなく、温度の障害と同じ出来事を生みます。

産業用コントローラー、ゲートウェイ、センサーが一つの保守用の盤にまとめられている

すべての逸脱が障害ではありません

段階は四つあり、段階によって、誰にどのように知らせるかが変わります:

  • 記録 — 履歴に記録するだけで、誰も煩わせません:扉の短い開放、通常の除霜、商品を入れたときの跳ね上がり
  • 警告 — 逸脱はあるが、対応の時間もある:連絡はその現場の責任者へ送られます
  • 障害 — 条件が崩れた、または機器が使えない:連絡はただちに複数の社員へ送られ、出来事が完了するまで自然に消えることはありません
  • 保守へ — 機器は動いているが、指標は摩耗を示している:作業は当番ではなく、修理の計画へ回ります

誰が連絡を受け取るか

システムでは現場ごとに責任者が定められ、出来事の種類ごとに配信の規則があります。システムはすべてを全員へ送りはしません:どの現場の逸脱で、どの種類で、今何時かを見て、その規則から宛先を選びます。

  • 現場の当番 — そのシフト中の通常の逸脱
  • 部門の責任者 — 障害と、誰も時間内に引き受けなかった出来事
  • 保守の部門 — 保守の作業と、コントローラーのエラーの符号

社員が決められた時間内に出来事を引き受けなければ、それは自動的に次の担当者へ回ります。夜間、休日、祝日は宛先が別でもかまいません — これもあらかじめ設定します。

出来事ごとに記録されること

種類、機器と現場、開始と終了の時刻、発生時点の指標の値、誰にいつ連絡が送られ、誰が引き受け、何をして、どう終わったか。これだけあれば、一か月後でも、シフトの記憶ではなく記録で事案を検討できます。

一つの庫についての規則システムの画面の一場面
条件待機時間イベント
温度が条件の上限を超えている15分警告
温度が上限を超えている45分障害
扉が開いたままになっている5分警告
扉を閉じた状態での温度上昇10分障害
機器に電圧がない1分障害
コントローラーがエラーの符号を返したただちに障害
装置が通信してこない20分障害
圧縮機が一日で通常より長く稼働した一日保守へ

システムの画面の一場面、値は説明用です。「待機時間」の列は、システムが警報を上げる前に待つ時間です。それがなければ、商品の搬入、通常の除霜、売り場の清掃が誤った障害の連続を生み、やがて連絡は読まれなくなります。

六つの場面: 実際の運用ではどう見えるか

どの場面も同じ道のりをたどります:機器で何かが変わった → システムがそれを出来事として記録した → 特定の社員が連絡を受け取った。違うのは原因と宛先だけです。

扉が閉まっていない

何が起きるか: センサーが扉が開いたと伝え、許容の時間を過ぎても閉じたと伝えてきません。 システムが行うこと: 機器の番号、現場の住所、開始時刻を添えて「扉が規定より長く開いている」という出来事を作ります。 誰が知るか: その拠点の社員です — 連絡には、扉がすでにどれだけ開いているかが示されます。出来事そのものは、扉が閉まるまで完了しません。

温度が上がっている

何が起きるか: 測定値が上昇を続けており、扉は閉じています。 システムが行うこと: 現在の値と上昇の速さを添えて逸脱を記録します。 誰が知るか: 現場の責任者が警告を受け取ります — 商品はまだ正常で、対応の時間もあります。上昇が続けば、警告は障害になり、今度は複数の社員へ送られます。

機器が通信しなくなった

何が起きるか: 装置が許容の間隔より長く黙っています。 システムが行うこと: 障害を作ります — 「データがない」ではなく、まさに障害としてです:その現場で何が起きているのか分からないからです。 誰が知るか: 温度の障害のときと同じ社員です。結果として起こり得ることが同じだからです。

コントローラーがエラーを伝えた

何が起きるか: 機器自身が不具合の符号を返します。 システムが行うこと: 符号をそのまま記録し、その機種の資料に基づいて読み解きます。 誰が知るか: エラーは機器のカードに、履歴とともに現れます — 同じ符号がその一台から何回届いているのか。

除霜が必要

何が起きるか: 除霜が必要であることの手がかり — コントローラーの信号、稼働時間、温度のサイクルの様子 — が正常の範囲を外れます。 システムが行うこと: 障害ではなく作業を作ります。 誰が知るか: 担当の社員です — 作業には、どの機器で、どの現場で、いつまでにかが示されます。

電源が落ちた

何が起きるか: 機器に電圧がありません。 システムが行うこと: 落ちた正確な時刻とともに障害を作ります。その間も、通信の装置が自らの電池で動いているうちは温度の記録が続きます。 誰が知るか: 連絡はただちに送られます — それをもとに、修理をいつ呼ぶかではなく、商品を運び出すかどうかを判断します。

一つの逸脱の全体出来事の記録、システムの画面の一場面
  • 21:04 — 変化保冷室2号、倉庫「東」:上限−18.0 °Cに対し温度−16.8 °C、扉は閉
  • 21:04 — 記録逸脱を履歴に記録しました。規則は15分待つため、まだ誰にも連絡は送られません
  • 21:19 — 出来事温度−15.9 °C、上昇が続いています。警告を作成:上限の超過が待機時間を上回りました
  • 21:19 — 連絡倉庫の当番とシフトの責任者へ送信。カードには値、上昇の速さ、開始時刻が見えます
  • 21:33 — 対応当番が出発したことを記録。システムは、誰が何時に出来事を引き受けたかを記録しました
  • 22:10 — 完了温度が正常に戻りました。出来事は「前室の扉がきちんと閉まっていなかった」という理由で完了。逸脱は66分続きました

システムの画面の一場面、数値は説明用です。ここで肝心なのは連絡ではなく、最後の行です:理由と継続時間が、その庫の履歴に入ります。「前室の扉がきちんと閉まっていない」が一か月にあと三回繰り返されれば、それはシフトとともに忘れられるのではなく、レポートに表れます。

冷蔵設備のほかに

どこで使われるか

このシステムは、機器が常時の見守りなしに動き、故障が結果から気づかれるところならどこでも必要です。指標の組み合わせと誤りの代償は変わっても、システムの作りは同じです。

  • 自動販売機 — 離れた拠点の自動販売機:機構の状態、温度、決済モジュール、通信の有無
  • マイクロマーケット — 販売員のいないオフィスや事業所にある陳列棚と冷蔵庫
  • 冷蔵倉庫 — 二十四時間の運転と、保管条件の証明が求められる庫と設備
  • 通常の倉庫 — 室内の温度と湿度、電源、区画への出入り、設備系統の状態
  • 店舗の什器 — 店舗網の売り場にある陳列棚、冷凍ケース、什器
  • 空調設備 — 室内で設定した温度が保たれているか、どれだけ外れているか
  • 換気 — 設備が動いているか、フィルターがどれだけ目詰まりしているか、何時間稼働したか
  • 冷房 — 運転の状態、起動の頻度、実際の温度と設定温度の差
  • 暖房 — 往きと戻りの温度、系統の動作、障害の状態
  • ポンプ — 動いているか止まっているか、消費はどれだけか、どのくらいの頻度で起動し、どれだけ稼働したか
  • 圧縮機 — 運転の状態、サイクルの長さ、稼働時間、障害による停止
  • 電動機 — 消費電流、稼働時間、通常でない運転
  • 生産設備 — 状態、停止、コントローラーのエラー、保守と保守の間の稼働時間
  • 産業機器 — 一つ、または複数の現場にある、メーカーの異なる機器群
  • 電源設備 — 電源があるか、その値はどうか、非常用の電源は入ったか
  • 電子錠 — 開錠、施錠、開けようとした形跡、錠の状態
  • センサー — 温度、湿度、圧力、電流など、その現場で測れる量
冷蔵庫を備えた三つの離れたマイクロマーケットが、中央の監視サーバーにつながっている

これらの場面に共通すること

  • 見守りのない機器 — 社員の訪問の間隔は日単位なのに、故障は数時間で進みます
  • 故障は結果から分かる — 故障そのものではなく、傷んだ商品、止まったライン、水浸しの部屋から分かります
  • 機器がまちまち — 一つの現場に、メーカーも製造年も異なる機器が並びます
  • 現場が多い — 機器全体を手で見て回ることは、思うより早く不可能になります
  • 履歴が必要 — 事案を検討し、保守を計画し、保管条件を証明するために

五つのうち三つでも御社の状況と重なるなら、見合うかどうかは、これまでの期間に実際に起きた損失 — 廃棄した商品、停止、無駄になった出動 — で計算できます。

このうち私たちがすでに手がけたもの

自動販売機とマイクロマーケット:テレメトリーのモジュール、機器上のプログラム、そして出来事の収集 — 販売、機構のエラー、温度、扉の開閉、決済モジュールと通信の状態 — は当社が作り、次の節で説明しています: セルフサービスシステム。一覧の他の分野も、同じ仕組みを別の種類の機器に当てはめたものです。

メーカーの異なる機器を

一つのプログラムで

実際の機器群が均一であることは、ほとんどありません。一つの現場に、製造年もメーカーも異なる機器が並びます:あるものは外へデータを出せるコントローラーを持ち、あるものはコントローラーはあっても「話す」ことができず、また別のものは動力部のほかに何もありません。

そこから、よくある光景が生まれます: 四種類の機器に四つのプログラムがあり、それぞれ別のログイン、別の状態の呼び名、別の通知があります。現場全体の姿はどれにも映らず、メーカーの異なる二台を比べることは、そもそもできません。

そうした状況で私たちが行うこと:

  • 機器の棚卸し — 一台ごとに:機種、製造年、コントローラー、それが何をどの方法で出せるのか、メーカーの資料はあるのか
  • できることの一覧 — どの指標が直接読めるのか、どの指示が受け付けられるのか、何を外部センサーで補うのかを確定します
  • 種類ごとの変換プログラム — コントローラーの種類ごとに、専用のやり取りのモジュールを書きます:その機器からデータを取り出し、共通の一つの形式で先へ渡します。こうしたモジュールをアダプターと呼びます
  • 状態の呼び名を一つに — メーカーごとに異なる呼び名の代わりに、共通の組を用います:稼働中、停止中、警告、障害、通信なし、保守中
  • 実機での検証 — モジュールは説明書ではなく現場で確かめます:資料とコントローラーの実際の振る舞いが食い違うのは、よくあることです

あらかじめ申し上げないこと。 事前調査の前に、特定のメーカーの機器や産業用の通信規格に対応していると表明することはしません。何が読めて何を操作できるかの一覧は、発表資料の一行ではなく、御社の機器の資料を読み、現地で確かめた結果です。完成した開発として確かなのは、自動販売機まわりだけです:MDBとEVA-DTSのドライバーを備えた自社のテレメトリーのモジュールで、次の節で説明しています: セルフサービスシステム.

ポンプ、圧縮機、制御盤が、遠隔診断のセンサーとゲートウェイにつながっている

遠隔診断で何が得られるか

  • 用のある出動 — 技術者は出発の前に何が起きたかを知り、必要な部品を持っていけます
  • 記録による検討 — 故障の前に何が起きていたかが履歴で分かり、オペレーターの話から組み立て直す必要がありません
  • 同型の機器どうしの比較 — 五台のうち一台が他と違う動きをしていれば、一年後の修理の請求書ではなく、まとめの画面で分かります
  • 実際の稼働に基づく保守 — 予定表の日付ではなく、稼働した時間と起動の回数に基づいて
  • 修理後の確認 — 指標が正常に戻ったかどうかを、もう一度出向かずにパネルで確認できます

遠隔からの操作ができるとき

機器の設定をブラウザから変えられるとは限りません。これはプログラムではなく機器自身の性質で、三つの場合があります:

  • コントローラーが外からの指示を受け付ける — パネルから設定温度や運転の状態を変え、設備を入切できます
  • コントローラーは出力しかしない — システムは状態を示しますが、何も変えられません
  • コントローラーがなく、外部センサーを付けている — 操作はまったくできません:センサーは測ることしかできないからです

これはプログラムでは迂回できません。そのため、使える指示の一覧は事前調査の前ではなく、その後にお伝えします。

四つではなく 一つのプログラムで

メーカーのばらつきは現場ではなく、プログラムの中で吸収します:機器の種類ごとに変換のしくみを書き、その先はすべて同じです。そのため新しい種類は、パネルや規則やレポートを作り直すのではなく、モジュールを一つ書くことで接続できます。

さまざまな種類の機器が、アダプターとサーバーを介して一つのオペレーター用パネルに集まっている

1. さまざまなデータの源

外へデータを出せるコントローラー、それができないコントローラー、外部センサー、通信の装置。それぞれに固有の形式、単位、状態の呼び名、送信の頻度があります。

2. 変換のプログラム

源の種類ごとに専用のモジュールを書きます:その機器からデータを取り出す方法を知っていて、それを内部の共通の形式へ変換します。その際、機器は変わりません — 合わせるのはプログラムです。こうしたモジュールをアダプターと呼びます。

3. 形をそろえる

同じ単位、同じ状態の一覧、同じ出来事の書き方に。こうすれば、保冷室もポンプも同じ言葉で表され、正常の範囲の規則も、メーカーごとにではなく、すべてに一度書けば済みます。

4. 統合パネル

機器全体を一つの画面に:現場、機器、指標、未完了の逸脱、履歴、レポート、使える指示。社員は一つのプログラムで働き、四つを切り替えることはありません。

一つの機器群、四つの源システムの画面の一場面
データの源何が読めるか操作状態
データを出せるコントローラー値、運転の状態、エラーの符号一部、資料に基づいて通信中
何も出さないコントローラー外部センサーを介していいえ通信中
通信の装置に付けた外部センサー温度、扉、電源、電流いいえ警告
自動販売機のテレメトリーのモジュール販売、機構のエラー、温度、扉はい通信なし

システムの画面の一場面、構成は説明用です。パネルでは四つの行が同じ見た目になります — 違いは「何が読めるか」と「操作」の列、つまり源が物理的に何を許すかだけに残ります。操作ができるかどうかを決めるのは、プログラムではなく機器のコントローラーです。

監視のパネルで

何が見えるか

パネルはブラウザで、利用者名とパスワードから開きます — 普通のサイトと同じです。何も導入する必要はなく、携帯からも使えます。

最初の画面。 上部に数値:今いくつの装置が通信していて、いくつが黙っていて、いくつの逸脱が今この瞬間に未完了か。その下に現場の一覧があり、それぞれの下にその機器が並び、一台ごとに色分けした状態(正常、警告、障害、通信なし)と現在の値が示されます。

機器のカード は、どの一台をクリックしても開きます。その冷蔵庫や設備について分かっていることが、すべてそこにまとまっています:

  • 現在の指標 — その時点での温度、扉、電源、圧縮機の動作
  • 期間のグラフ — 一日、一週間、一か月で指標がどう変わったか。線上には扉の開放、圧縮機の起動、電源の喪失が示されます
  • 出来事の記録 — その一台のすべての逸脱:いつ生じ、誰へ送られ、誰が引き受け、どう完了したか
  • エラーの記録 — コントローラーが伝えた符号を、読み解きと繰り返しの履歴とともに
  • 測定の履歴 — 保管期間内のすべての測定値を、間引かずに、ファイル出力とともに
  • 仕様と保守 — 機種、設置日、その一台にいつ何をしたか
  • 操作 — 機器のコントローラーが指示を受け付ける場合の、設定温度と運転の状態。変更はすべて、実行者と結果とともに記録されます

設定は一度行えば あとは自ら働きます:機器の種類ごとの正常の範囲と待機時間、現場・出来事の種類・時刻に応じた責任者と連絡の規則、社員の役割 — 誰が何を見て何ができるか、そして現場・地域・機器の種類によるグループと絞り込み。

なぜ履歴を保管するのか。 これはすべての測定値とすべての出来事を、正確な時刻とともに保存し、いつでも参照できるようにしたものです。五つのことのために必要です:

  • あとから事案を検討する — 土曜の未明に庫で何が起きたかが、シフトの記憶ではなく分単位で分かります
  • 保管条件を証明する — 期間のグラフをファイルに出力し、検査や取引先の網に示せます
  • 保守業者と事実に基づいて話す — 修理の後に設備が何回障害に陥ったかが、記録で分かります
  • 保守を計画する — 予定表の日付ではなく、実際の稼働時間と起動の回数に基づいて
  • 摩耗に気づく — 同じ一台が半年前にどう動いていたか、今どう動いているかを比べられます

グラフについて別に一言:これは報告のためではなく、検討のために必要です。温度の線の上に扉の開放、圧縮機の起動、電源の喪失が示されていれば、逸脱の原因はすぐ読み取れます — 四つの別々の画面を突き合わせる必要はありません。

オペレーターが遠隔から圧縮機を診断し、そのコントローラーの許された値を変更している

遠隔の指示はどう作られているか

  • コントローラーが受け付けるものだけ — 使える指示の一覧は機器の機種で決まり、接続の時点で確定します
  • 職務に応じた権限 — 状態はシフト全員が見られますが、設定を変えられるのは限られた社員だけです
  • 結果の確認 — 指示は、送った時点ではなく、機器が応答した時点で実行されたとみなします
  • 記録への書き込み — 誰が、いつ、何を変え、それ以前の値は何で、機器が何を返したか
  • 範囲の制限 — 設定温度は、コントローラーがその指示を受け付けるとしても、その機器の種類に定めた範囲の外へは出せません

コントローラーが指示を受け付けない場合、カードの操作の欄はそもそも表示されません。動かないボタンは置きません — 現場が、ここから機器を操作できると感じないようにするためです。

現場が数十、

数百になったら

冷蔵庫が五台の現場一つなら、どんなやり方でも回ります。手帳でも構いません。違いが出るのは五十台、五百台のときです:一覧が画面に収まらなくなり、連絡は流れになり、すべてに責任を持つ社員は、何一つ具体的に担えなくなります。

例。 夜、ある拠点で停電が起きます。設定がなければ、システムは三十件の障害を別々に送ってきます — 機器一台につき一件で、その流れの中に他のすべてが埋もれます。設定があれば、連絡は一件です:どこそこの現場、電源が落ち、30台が影響を受けている、と。

機器が増えると何が変わるか:

  • 最初の画面にはすべてではなく問題だけを — 一覧の全部ではなく、未完了の逸脱がある装置を、緊急度の順に
  • グループ分け — 現場、地域、機器の種類、責任者ごとに。グループごとに状態のまとめが付きます
  • グループごとの宛先 — 連絡の規則は、一つの共通の宛先一覧ではなく、現場と出来事の種類に結び付きます
  • 同じ出来事のまとめ — 一つの原因が三十件の別々の連絡になりません
  • エスカレーション — 決められた時間内に引き受けられなかった出来事は、自動的に次の担当者へ回ります
  • 同型の機器どうしの比較 — どれが最も頻繁に逸脱し、どれが最も長く逸脱の状態にあり、どれが最も長く稼働しているか
店舗網のまとめシステムの画面の一場面
214通信中の装置
6通信なし
11未完了の逸脱
3障害 対応が必要
  • 冷却設備128
  • 自動販売機54
  • 空調と換気27
  • ポンプと圧縮機11

システムの画面の一場面、数値は説明用です。数字の並びは偶然ではありません:最初に来るのは機器の規模ではなく、今いくつの現場が見えていないかです。黙っている装置が六台とは、何も分かっていない拠点が六つあるということです。

配車担当が、離れた現場の網、機器、未完了の逸脱を把握している

期間ごとのレポート

  • 条件の遵守 — 各機器が正常の範囲の内と外でどれだけの時間を過ごしたかを、日ごとの内訳とともに
  • 原因別の逸脱 — 扉、電源、設備の故障、通信の途絶:どこで同じことが繰り返されているか
  • 対応の速さ — 出来事の発生から引き受けまで、そして完了までにどれだけかかったかを、現場ごと・社員ごとに
  • 機器の稼働時間 — 期間中の稼働時間と起動の回数。計画的な保守の土台です
  • 稼働の割合 — 装置が通信していた時間の割合。これが低ければ、他のすべての数字は意味を失います

レポートはファイルに出力でき、予定に沿って自動で作成できます — たとえば毎月一日に。冷却まわりでは、こうしたレポートがそのまま、その期間の保管条件の証明にもなります。

誰が何を見るか

権限も同じ構造で与えます:拠点の社員は自分の機器だけを、部門の責任者は自分の種類のすべての現場を、配車担当は網全体のまとめを見ます。閲覧、出来事の引き受け、遠隔の操作は分けられており、一括で与えられることはありません。

センサーとコントローラー

クラウドへの送信

統合パネル

連絡とレポート

追加の層としてのAI

データが十分にたまったとき

システムの基本の働きは、単純な規則の上に成り立ちます:この値が何分以上続けば、この人へこの連絡を。障害の場面を押さえるにはこれで十分で、どの導入もここから始まります。

履歴が数か月分たまったら、その上にデータの分析を重ねられます。それは範囲の逸脱ではなく、特定の一台のいつもの振る舞いの変化を探します。

例。 圧縮機は通常、八分で所定の状態に入ります。ここ三週間は十二分かかっています。どの範囲も外れておらず、規則に従えば連絡は一件も出ません — しかしこの設備は明らかに故障へ向かっており、休日に止まる前に保守するほうが得策です。

  • 蓄積された履歴 — 一台ごとの長期間の指標と出来事。修理や交換の記録も含みます
  • 分析 — 指標が普段どう振る舞うか、稼働時間がどう増えるか、同型の機器どうしがどこで違うか
  • いつもとの違いの検出 — サイクルが長くなった、所定の状態に入るまでが延びた、電流の消費が通常と違う
  • 故障の予測の可能性 — 故障の履歴が蓄積されていれば、故障の確からしさをあらかじめ見積もり、停止の前に修理を計画できます

境目ははっきり示します。 故障の予測は、蓄積されたデータの上で可能になるものであって、初日から動く機能ではありません。そのためには指標だけでなく、故障そのものの履歴が必要です:実際の事例がなければ、モデルを学習させる材料がありません。そのためプロジェクトでは、これは最初のリリースの項目ではなく、データの収集が一定期間動いた後の独立した段階です。

隣接する分野が 人工知能の導入 です。同じ考え方を、注文、問い合わせ、書類のデータに当てはめる業務への適用です。

テレメトリーのグラフが、障害のしきい値に達する前の圧縮機の早期の逸脱を示している

分析が規則より早く気づくこと

  • 故障の前の摩耗 — 圧縮機が何週間もかけて長く動くようになっているのに、どの範囲も外れていません
  • 特定の現場の問題 — 五つのうち一つの庫だけ、扉を開けた後に所定の状態へ戻るのが常に遅い
  • 正しく設定されていない正常の範囲 — 同じ現場で毎日作動する規則は、障害を知らせているというより、設定が誤っている可能性が高いです
  • 季節性 — 夏の負荷の増加が機器の摩耗と切り分けられ、無駄な修理を手配せずに済みます

これらのどれも、障害の規則の代わりにはなりません:規則は数分で反応し、分析は数週間の目で働きます。両方の層が必要で、導入の順序もまさにこのとおりです。

導入の 順序

段階はまさにこの順序で進みます。事前調査を飛ばすことが、必要なデータを出せない機器に合わせてシステムを組んでしまう、最も多い原因です。

1. 事前調査

機器の棚卸し:機種、コントローラー、資料、一台ごとに物理的に何が取得できるか、現場にインターネットはあるか。成果は、すぐ得られるものと、外部センサーで補う必要があるものの一覧です。

2. 一つの現場でのパイロット

一つの場所と数台の機器:取り付け、実機のコントローラーでのやり取りの検証、そして資料ではなく機器の実際の振る舞いに基づく正常の範囲と待機時間の設定。

3. 規則と責任者

誰がどの現場に責任を持つか、どの出来事が誰へ届くか、何を障害とみなし、何を単なる記録とするか。ここで、引き継ぎと同じ出来事のまとめも設定します。さもなければ、連絡の流れが一か月でシステムの価値を失わせます。

4. 網への展開

残りの現場を検証済みの手順で、新しい種類の機器は個別のやり取りのモジュールとして。以降は履歴がたまり、期間ごとのレポートとデータの分析が得られます。

御社の機器の監視について話し合いましょう

今すぐご連絡ください

現場にどのような機器が何台あり、今どのような問題を結果からしか知り得ないのかをお書きください。そこから実際に何が取得でき、どこに外部センサーが必要で、何からパイロットを始めるのが妥当かをお答えします。