御社の機器を 拝見し そのうえで、 そこから実際に何が取得できるかをお伝えします
コントローラーの資料と機器の構成に基づいて:どの指標がすぐ得られるか、どこにセンサーを付ける必要があるか、どの設定を遠隔で操作できるか。
機器は現場にあり、あなたは事務所にいます。私たちはそこにセンサーを付け、インターネットにつなぎ、指標をブラウザで開く一つの画面へ集めます。温度が正常の範囲を外れた、扉が開いたままになった、電源が落ちた — 責任者は、傷んだ商品を見て朝に知るのではなく、その場で連絡を受け取ります。
平たく言えば、機器に小さな装置を付けます。それが大切なことを絶えず測ります — 庫内の温度、扉が開いているか、電気は来ているか、圧縮機は動いているか。一分に一度、その測定値がインターネット経由でサーバーへ送られます。あなたはブラウザを開き、すべての拠点の機器一台ごとの状態を見ます。
IoT は「モノのインターネット」の意味です。要は、人が手帳を持って回って値を書き写すのではなく、機器自身がそれをプログラムへ送るということです。そのために何かをする必要はありません:データは自ら、夜も休日も含めて二十四時間届きます。
数字が並ぶだけの画面との一番の違いは、システムが誰かの視線を待たないことです。あなたがその機器に定めた正常の範囲と、測定値を自ら比べます。範囲を外れれば — その現場の責任者を一覧から見つけ、その人へ連絡します。
例。 倉庫の冷凍庫は−18 °Cまでが正常とします。21:04にセンサーが−16.8 °Cを送ります。その時、画面を見ている人は誰もいません。15分後も温度は上がり続けます — システムは出来事を作り、そこに庫の番号、倉庫の住所、時刻、現在の値を記録し、倉庫の当番へ連絡を送ります。21:33に当番が到着し、前室の扉がきちんと閉まっていないのを見つけます。商品は無事です。
その際、機器を取り替える必要はありません。冷蔵庫、自動販売機、ポンプ、換気設備はそのままで — そこに、それらが持っていないものを足します:センサー、通信の装置、そして機器全体を一つの一覧で見られるプログラムです。
どのプロジェクトも三つの問いから始まります: その機器で物理的に何を測れるのか。データは現場からどうやってインターネットへ出るのか。逸脱に誰が責任を持ち、何分以内に対応すべきなのか。三つ目の答えが出ないうちは、数字の並んだきれいな画面はできても、何かを未然に防ぐシステムにはなりません。
| 何が実現されているか | それは何か |
|---|---|
| 指標が画面にリアルタイムで表示される | 観察 |
| 指標が正確な時刻とともに履歴に保存される | 土台 |
| 正常の範囲からの逸脱が、独立した出来事として記録される | 土台 |
| 出来事に、特定の社員と対応の期限がある | 監視 |
| 社員の対応が記録され、出来事が完了する | 監視 |
境目は二つのことで決まります:出来事に人がいることと、期限があることです。現在の温度を映す画面は、それ自体では何も救いません — 誰かが調べるよう割り当てられないうちは、逸脱はグラフ上の線のままです。そのため、正常の範囲、責任者、対応の期限、完了の記録は、「お好みで」の設定ではなく、システムの必須の項目です。

できることの境目を決めるのはプログラムではなく、機器そのものです:取得できるのは、機器が測っているものか、センサーで測れるものだけ。変えられるのは、そのコントローラーが許すものだけです。御社の機種で何ができるかは、メーカーの資料をもとに事前調査で明らかにします。
一つの測定値がたどる道のり全体 — 冷蔵庫の装置から、携帯への連絡まで。以下ではこの六つの環を、それぞれより詳しく説明します。

見守る対象:保冷室、陳列棚、冷凍庫、自動販売機、ポンプ、換気設備、生産ライン。一台ごとにシステムへカードとして登録します — それが何で、どの現場にあり、どのような仕様で、いつ保守したのか。
測る装置です。センサーは一つの量を測る小さな装置です:温度、湿度、圧力、電流、扉が開いているか、電圧があるか。コントローラーは機器自身の「頭脳」です:機種によっては自らの値やエラーの符号を外へ伝えられ、その場合は余計なセンサーは不要です。できない場合は、こちらのセンサーを付けます。
値がどうやってインターネットへ入るか。現場に小さな通信の装置を置きます:センサーから測定値を集め、インターネットのケーブル、Wi-Fi、またはSIMカードでサーバーへ送ります。インターネットが切れれば — 測定値はその装置の記憶にたまり、通信が戻ったときに送られます。装置が黙っていること自体も、警報として扱われます。
データの居場所です。サーバーは、保護されたデータセンターで二十四時間動く計算機です。「クラウド」とは、それがあなたの事務所にはないという意味です:購入も、冷却も、保守も要らず、プログラムへはどこからでもつながります。サーバーは測定値を受け取り、履歴に保存し、正常の範囲と照らし、逸脱を出来事に変えます。
あなたが見るプログラムです。パソコンでも携帯でも、ブラウザで利用者名とパスワードから開きます — 何も導入する必要はありません。一つの画面に、現場、機器、現在の指標、未完了の逸脱の一覧が並びます。メーカーの異なる機器も同じ見た目になります。
この連なりの結果です:特定の社員への連絡、検討のためのグラフと記録、月次のレポート、そして — コントローラーが許す場合には — パネルから直接、機器の設定を変えること。
測定の頻度と許容の範囲は、網全体に一つの数字ではなく、機器の種類ごとに個別に定めます。冷凍庫と、調理済み食品の陳列棚と、倉庫の保冷室では、正常な温度も、そこを外れてよい時間も異なります。
冷却は、監視が最も早く見合う分野です。条件の逸脱が目に見えないからです。夜の間わずかに開いた扉に朝まで誰も気づかず、朝にはもう、結論はあなたの代わりに出てしまっています。
例。 金曜の夕方、冷凍庫の圧縮機が止まります。夜のうちに商品が解け、土曜に一部を再び凍らせ、月曜にその一群を廃棄します。監視があれば、故障の連絡は金曜の21:00に届き、話は保守業者を呼ぶだけで済みます。
その際、機器はさまざまです。冷凍庫と調理済み食品の陳列棚では、許される温度も、それを外れる速さも、誤りの代償も一致しません。そのため正常の範囲は網全体に一つではなく、中に何が入っているかを踏まえて機器ごとに定めます。
冷却設備から取得できること:
何が取れるかは機種によります。標準のコントローラーが値とエラーの符号を外へ出すなら — システムはそれを直接読みます。出さないなら — 温度、扉、電源の外部センサーを付けます。御社の機器で何ができるかは、あらかじめ約束するのではなく、その資料をもとに事前調査で判断します。

そのため正常の範囲は、機器の種類と中の商品に合わせて設定します。それをしなければ、連絡は絶えず届くようになり、社員はそれを開かなくなります — そしてシステムは空回りします。
これらのグループで使う装置は、おおむね同じです。違いは、許される条件、誤りの代償、そして連絡の宛先です。仕組みはどれも同じです:機器の一台、現場、指標、正常の範囲、出来事、責任者。

販売員のいない拠点です:扉が閉まっていないことも、設備が止まったことも、気づく人がそもそもいません。機器はオフィス、工場、コワーキングにあり、社員は数日に一度来ます。ここでは温度と扉の把握が、問題を時機を逃さず知る唯一の方法です。
深い低温と大きな冷えの蓄えがあります:逸脱はゆっくり進み、発覚するのは一群まるごとが傷んだときです。温度、それが範囲外に留まる時間、圧縮機の動作、除霜を把握します。
売り場では一シフトに何十回も扉が開き、条件は絶えず崩れます。そのため大切なのは範囲を外れたこと自体ではなく、それがどれだけ続き、一日に何度繰り返されるかです。
容量が大きく、温度の異なる区画が複数あります:一点の測定では庫を表せません。センサーを複数付け、扉と電源は別に把握します — 庫が止まれば、一つの棚ではなく中身のすべてを失うからです。
一つの現場に複数の庫と設備があり、交替制で二十四時間動きます。区画ごとの責任の分担、長い履歴、そして月次または四半期の条件遵守のレポートが必要になります。
同じ機器を備えた拠点の網です:別々の住所にある何十もの陳列棚と冷凍ケース。ここでの価値は比較にあります — どこで逸脱が繰り返されるのか、どの拠点が慢性的に条件を外れるのか、どの一台が修理の時期なのか。
原材料と完成品の保管で、条件は便宜ではなく要件です。連絡に加えて、証明できることが必要になります:庫ごとの期間のグラフと、誰がどのように逸脱へ対応したかの記録です。
別の一群として、コントローラーがそもそも外部とのやり取りを想定していない設備があります。それらは外部センサーで接続します:温度、扉、電源、消費電流。「賢い」設備より得られるデータは少なくなりますが、肝心のこと — 条件、扉、電源、圧縮機の動作 — は分かり、そうした一台も共通の一覧に他と並びます。
どの指標もシステムの中で二つの形を持ちます。一つは値そのもので、これは単に履歴に保存されます。もう一つは規則です:どの値のときに、何分続いたら、誰かに知らせるべき逸脱になるのか。
例。 冷凍室の−16 °Cという温度は、毎分、常に保存されます。連絡が送られるのは、それが−18 °Cを超えたまま十五分以上続いた場合だけです。
取得し、把握するものの全一覧:
通信の途絶は些細なことではなく、れっきとした障害です。 黙っている装置は「データがない」ではなく「その現場について何も分からない」を意味します。そこの温度は正常かもしれませんし、もう一時間上がり続けているかもしれません。そのため通信の途絶は、グラフに空白を残すのではなく、温度の障害と同じ出来事を生みます。

段階は四つあり、段階によって、誰にどのように知らせるかが変わります:
システムでは現場ごとに責任者が定められ、出来事の種類ごとに配信の規則があります。システムはすべてを全員へ送りはしません:どの現場の逸脱で、どの種類で、今何時かを見て、その規則から宛先を選びます。
社員が決められた時間内に出来事を引き受けなければ、それは自動的に次の担当者へ回ります。夜間、休日、祝日は宛先が別でもかまいません — これもあらかじめ設定します。
種類、機器と現場、開始と終了の時刻、発生時点の指標の値、誰にいつ連絡が送られ、誰が引き受け、何をして、どう終わったか。これだけあれば、一か月後でも、シフトの記憶ではなく記録で事案を検討できます。
| 条件 | 待機時間 | イベント |
|---|---|---|
| 温度が条件の上限を超えている | 15分 | 警告 |
| 温度が上限を超えている | 45分 | 障害 |
| 扉が開いたままになっている | 5分 | 警告 |
| 扉を閉じた状態での温度上昇 | 10分 | 障害 |
| 機器に電圧がない | 1分 | 障害 |
| コントローラーがエラーの符号を返した | ただちに | 障害 |
| 装置が通信してこない | 20分 | 障害 |
| 圧縮機が一日で通常より長く稼働した | 一日 | 保守へ |
システムの画面の一場面、値は説明用です。「待機時間」の列は、システムが警報を上げる前に待つ時間です。それがなければ、商品の搬入、通常の除霜、売り場の清掃が誤った障害の連続を生み、やがて連絡は読まれなくなります。
どの場面も同じ道のりをたどります:機器で何かが変わった → システムがそれを出来事として記録した → 特定の社員が連絡を受け取った。違うのは原因と宛先だけです。
何が起きるか: センサーが扉が開いたと伝え、許容の時間を過ぎても閉じたと伝えてきません。 システムが行うこと: 機器の番号、現場の住所、開始時刻を添えて「扉が規定より長く開いている」という出来事を作ります。 誰が知るか: その拠点の社員です — 連絡には、扉がすでにどれだけ開いているかが示されます。出来事そのものは、扉が閉まるまで完了しません。
何が起きるか: 測定値が上昇を続けており、扉は閉じています。 システムが行うこと: 現在の値と上昇の速さを添えて逸脱を記録します。 誰が知るか: 現場の責任者が警告を受け取ります — 商品はまだ正常で、対応の時間もあります。上昇が続けば、警告は障害になり、今度は複数の社員へ送られます。
何が起きるか: 装置が許容の間隔より長く黙っています。 システムが行うこと: 障害を作ります — 「データがない」ではなく、まさに障害としてです:その現場で何が起きているのか分からないからです。 誰が知るか: 温度の障害のときと同じ社員です。結果として起こり得ることが同じだからです。
何が起きるか: 機器自身が不具合の符号を返します。 システムが行うこと: 符号をそのまま記録し、その機種の資料に基づいて読み解きます。 誰が知るか: エラーは機器のカードに、履歴とともに現れます — 同じ符号がその一台から何回届いているのか。
何が起きるか: 除霜が必要であることの手がかり — コントローラーの信号、稼働時間、温度のサイクルの様子 — が正常の範囲を外れます。 システムが行うこと: 障害ではなく作業を作ります。 誰が知るか: 担当の社員です — 作業には、どの機器で、どの現場で、いつまでにかが示されます。
何が起きるか: 機器に電圧がありません。 システムが行うこと: 落ちた正確な時刻とともに障害を作ります。その間も、通信の装置が自らの電池で動いているうちは温度の記録が続きます。 誰が知るか: 連絡はただちに送られます — それをもとに、修理をいつ呼ぶかではなく、商品を運び出すかどうかを判断します。
システムの画面の一場面、数値は説明用です。ここで肝心なのは連絡ではなく、最後の行です:理由と継続時間が、その庫の履歴に入ります。「前室の扉がきちんと閉まっていない」が一か月にあと三回繰り返されれば、それはシフトとともに忘れられるのではなく、レポートに表れます。
このシステムは、機器が常時の見守りなしに動き、故障が結果から気づかれるところならどこでも必要です。指標の組み合わせと誤りの代償は変わっても、システムの作りは同じです。

五つのうち三つでも御社の状況と重なるなら、見合うかどうかは、これまでの期間に実際に起きた損失 — 廃棄した商品、停止、無駄になった出動 — で計算できます。
自動販売機とマイクロマーケット:テレメトリーのモジュール、機器上のプログラム、そして出来事の収集 — 販売、機構のエラー、温度、扉の開閉、決済モジュールと通信の状態 — は当社が作り、次の節で説明しています: セルフサービスシステム。一覧の他の分野も、同じ仕組みを別の種類の機器に当てはめたものです。
実際の機器群が均一であることは、ほとんどありません。一つの現場に、製造年もメーカーも異なる機器が並びます:あるものは外へデータを出せるコントローラーを持ち、あるものはコントローラーはあっても「話す」ことができず、また別のものは動力部のほかに何もありません。
そこから、よくある光景が生まれます: 四種類の機器に四つのプログラムがあり、それぞれ別のログイン、別の状態の呼び名、別の通知があります。現場全体の姿はどれにも映らず、メーカーの異なる二台を比べることは、そもそもできません。
そうした状況で私たちが行うこと:
あらかじめ申し上げないこと。 事前調査の前に、特定のメーカーの機器や産業用の通信規格に対応していると表明することはしません。何が読めて何を操作できるかの一覧は、発表資料の一行ではなく、御社の機器の資料を読み、現地で確かめた結果です。完成した開発として確かなのは、自動販売機まわりだけです:MDBとEVA-DTSのドライバーを備えた自社のテレメトリーのモジュールで、次の節で説明しています: セルフサービスシステム.

機器の設定をブラウザから変えられるとは限りません。これはプログラムではなく機器自身の性質で、三つの場合があります:
これはプログラムでは迂回できません。そのため、使える指示の一覧は事前調査の前ではなく、その後にお伝えします。
メーカーのばらつきは現場ではなく、プログラムの中で吸収します:機器の種類ごとに変換のしくみを書き、その先はすべて同じです。そのため新しい種類は、パネルや規則やレポートを作り直すのではなく、モジュールを一つ書くことで接続できます。

外へデータを出せるコントローラー、それができないコントローラー、外部センサー、通信の装置。それぞれに固有の形式、単位、状態の呼び名、送信の頻度があります。
源の種類ごとに専用のモジュールを書きます:その機器からデータを取り出す方法を知っていて、それを内部の共通の形式へ変換します。その際、機器は変わりません — 合わせるのはプログラムです。こうしたモジュールをアダプターと呼びます。
同じ単位、同じ状態の一覧、同じ出来事の書き方に。こうすれば、保冷室もポンプも同じ言葉で表され、正常の範囲の規則も、メーカーごとにではなく、すべてに一度書けば済みます。
機器全体を一つの画面に:現場、機器、指標、未完了の逸脱、履歴、レポート、使える指示。社員は一つのプログラムで働き、四つを切り替えることはありません。
| データの源 | 何が読めるか | 操作 | 状態 |
|---|---|---|---|
| データを出せるコントローラー | 値、運転の状態、エラーの符号 | 一部、資料に基づいて | 通信中 |
| 何も出さないコントローラー | 外部センサーを介して | いいえ | 通信中 |
| 通信の装置に付けた外部センサー | 温度、扉、電源、電流 | いいえ | 警告 |
| 自動販売機のテレメトリーのモジュール | 販売、機構のエラー、温度、扉 | はい | 通信なし |
システムの画面の一場面、構成は説明用です。パネルでは四つの行が同じ見た目になります — 違いは「何が読めるか」と「操作」の列、つまり源が物理的に何を許すかだけに残ります。操作ができるかどうかを決めるのは、プログラムではなく機器のコントローラーです。
パネルはブラウザで、利用者名とパスワードから開きます — 普通のサイトと同じです。何も導入する必要はなく、携帯からも使えます。
最初の画面。 上部に数値:今いくつの装置が通信していて、いくつが黙っていて、いくつの逸脱が今この瞬間に未完了か。その下に現場の一覧があり、それぞれの下にその機器が並び、一台ごとに色分けした状態(正常、警告、障害、通信なし)と現在の値が示されます。
機器のカード は、どの一台をクリックしても開きます。その冷蔵庫や設備について分かっていることが、すべてそこにまとまっています:
設定は一度行えば あとは自ら働きます:機器の種類ごとの正常の範囲と待機時間、現場・出来事の種類・時刻に応じた責任者と連絡の規則、社員の役割 — 誰が何を見て何ができるか、そして現場・地域・機器の種類によるグループと絞り込み。
なぜ履歴を保管するのか。 これはすべての測定値とすべての出来事を、正確な時刻とともに保存し、いつでも参照できるようにしたものです。五つのことのために必要です:
グラフについて別に一言:これは報告のためではなく、検討のために必要です。温度の線の上に扉の開放、圧縮機の起動、電源の喪失が示されていれば、逸脱の原因はすぐ読み取れます — 四つの別々の画面を突き合わせる必要はありません。

コントローラーが指示を受け付けない場合、カードの操作の欄はそもそも表示されません。動かないボタンは置きません — 現場が、ここから機器を操作できると感じないようにするためです。
冷蔵庫が五台の現場一つなら、どんなやり方でも回ります。手帳でも構いません。違いが出るのは五十台、五百台のときです:一覧が画面に収まらなくなり、連絡は流れになり、すべてに責任を持つ社員は、何一つ具体的に担えなくなります。
例。 夜、ある拠点で停電が起きます。設定がなければ、システムは三十件の障害を別々に送ってきます — 機器一台につき一件で、その流れの中に他のすべてが埋もれます。設定があれば、連絡は一件です:どこそこの現場、電源が落ち、30台が影響を受けている、と。
機器が増えると何が変わるか:
システムの画面の一場面、数値は説明用です。数字の並びは偶然ではありません:最初に来るのは機器の規模ではなく、今いくつの現場が見えていないかです。黙っている装置が六台とは、何も分かっていない拠点が六つあるということです。

レポートはファイルに出力でき、予定に沿って自動で作成できます — たとえば毎月一日に。冷却まわりでは、こうしたレポートがそのまま、その期間の保管条件の証明にもなります。
権限も同じ構造で与えます:拠点の社員は自分の機器だけを、部門の責任者は自分の種類のすべての現場を、配車担当は網全体のまとめを見ます。閲覧、出来事の引き受け、遠隔の操作は分けられており、一括で与えられることはありません。
センサーとコントローラー
クラウドへの送信
統合パネル
連絡とレポート
システムの基本の働きは、単純な規則の上に成り立ちます:この値が何分以上続けば、この人へこの連絡を。障害の場面を押さえるにはこれで十分で、どの導入もここから始まります。
履歴が数か月分たまったら、その上にデータの分析を重ねられます。それは範囲の逸脱ではなく、特定の一台のいつもの振る舞いの変化を探します。
例。 圧縮機は通常、八分で所定の状態に入ります。ここ三週間は十二分かかっています。どの範囲も外れておらず、規則に従えば連絡は一件も出ません — しかしこの設備は明らかに故障へ向かっており、休日に止まる前に保守するほうが得策です。
境目ははっきり示します。 故障の予測は、蓄積されたデータの上で可能になるものであって、初日から動く機能ではありません。そのためには指標だけでなく、故障そのものの履歴が必要です:実際の事例がなければ、モデルを学習させる材料がありません。そのためプロジェクトでは、これは最初のリリースの項目ではなく、データの収集が一定期間動いた後の独立した段階です。
隣接する分野が 人工知能の導入 です。同じ考え方を、注文、問い合わせ、書類のデータに当てはめる業務への適用です。

これらのどれも、障害の規則の代わりにはなりません:規則は数分で反応し、分析は数週間の目で働きます。両方の層が必要で、導入の順序もまさにこのとおりです。
段階はまさにこの順序で進みます。事前調査を飛ばすことが、必要なデータを出せない機器に合わせてシステムを組んでしまう、最も多い原因です。
機器の棚卸し:機種、コントローラー、資料、一台ごとに物理的に何が取得できるか、現場にインターネットはあるか。成果は、すぐ得られるものと、外部センサーで補う必要があるものの一覧です。
一つの場所と数台の機器:取り付け、実機のコントローラーでのやり取りの検証、そして資料ではなく機器の実際の振る舞いに基づく正常の範囲と待機時間の設定。
誰がどの現場に責任を持つか、どの出来事が誰へ届くか、何を障害とみなし、何を単なる記録とするか。ここで、引き継ぎと同じ出来事のまとめも設定します。さもなければ、連絡の流れが一か月でシステムの価値を失わせます。
残りの現場を検証済みの手順で、新しい種類の機器は個別のやり取りのモジュールとして。以降は履歴がたまり、期間ごとのレポートとデータの分析が得られます。
現場にどのような機器が何台あり、今どのような問題を結果からしか知り得ないのかをお書きください。そこから実際に何が取得でき、どこに外部センサーが必要で、何からパイロットを始めるのが妥当かをお答えします。