異常検知 設備PoCの進め方｜タイ工場90日受入基準

「異常検知 設備」のPoCを始めたものの、90日後に残ったのがダッシュボードと大量のアラームだけ——タイ工場では、この失敗を避けるために技術選定より先に受入基準を決める必要があります。本稿では、設備異常検知システムの一般論やセンサー選定を繰り返さず、回転設備を対象とする90日PoCを「合格・条件付き合格・不合格」と判定できる設計に限定します。検知リードタイム、誤報と見逃し、4段階アラーム、通信断・センサー欠測、CMMSの保全ワークオーダー、責任分界、FAT/SAT、終了条件までを一つの受入仕様にまとめます。

本稿に登場する日数、件数、比率、費用は、出典を示した公表値を除き、すべて説明用の「モデルケース（仮定）」です。実際の基準値は設備の故障モード、操業パターン、安全要求、保全体制、ネットワーク品質に合わせて決めてください。

なぜ設備異常検知PoCは「検知できたか」だけでは判定できないのか

状態監視システムは、センサーから値を取ってグラフを描くところまでは比較的早く進みます。しかし工場が購入したい成果はグラフではありません。「計画外停止を避けるために、誰が、いつ、何を判断し、どの作業を起票するか」という保全能力です。したがってPoCの受入対象はアルゴリズム単体ではなく、次の連鎖全体になります。

1. 設備状態が変化する。
2. センサーが有効な信号を取得する。
3. エッジ装置が欠測や通信断を区別しながら処理する。
4. 設備異常検知システムが状態を段階表示する。
5. 担当者へ通知され、妥当性を確認する。
6. CMMSまたは保全管理台帳にワークオーダーが作られる。
7. 点検・補修の結果が異常イベントへ戻される。
8. 誤報、見逃し、検知リードタイムを再計算する。

ISO 17359:2018は、機械の状態監視プログラムを設定する際に考慮すべき一般手順を示し、設備監査、重要度、故障モード、監視方法などを含む枠組みを提供しています。またISO 13374シリーズは、状態監視情報の処理、通信、表示を扱います。これらは特定製品の合格値を与える規格ではありませんが、「センサー精度だけを受け入れて終わり」にせず、情報が意思決定へ届く全体を仕様化する考え方と整合します。

2026年9月2日にNTNが発表した産業設備向けCMSは、同社の説明では振動データを収集・解析し、「正常」「初期損傷」「注意」「警告」の4段階で表示します。NTN製以外の軸受にも対応し、対象設備の調査から実証評価、導入、運用まで支援するとしています。先行した資源リサイクル事業者での6か月の実証評価について、同社はベルトコンベヤー回転軸のクラックなどの兆候を早期検知し、正式導入に至ったと報告しています。これはベンダー自身の製品発表であり、すべての工場で同じ成果を保証するものではありません。ただし「多段階表示」と「実証から運用への接続」を受入設計に含める重要性を示す最近の例です。

同様に、Emersonは2026年9月8日の製品発表で、ターボ機械保護システムから分析基盤への連続データ伝送を強化し、数時間から数日に及ぶ起動・停止の分析を支援すると説明しています。定常運転だけでPoCを評価すると、起動、停止、段取り替え、洗浄、速度変更といった誤報の多い局面を試せません。90日PoCでは「通常運転時にグラフが安定した」ではなく、運転状態をまたいでも判定が成立するかを確認します。

最初の5日で固定する「PoC受入仕様書」

PoC開始後に合格条件を変えると、都合の良い評価になります。Day 1〜5で工場、保全部門、IT/OT部門、システム提供側が受入仕様書を承認し、変更には版管理と理由を残します。最低限、次の項目を1枚のトレーサビリティ表にします。

「精度90%以上」のような一語だけでは受入基準になりません。どのイベントを正解とし、誰がラベルを確定し、分母に何を含め、欠測中をどう扱い、同じ事象から出た連続アラームを1件と数えるかまで書いて初めて比較できます。

対象設備は3〜5台、故障モードは設備ごとに1〜3個へ絞る

以下はモデルケース（仮定）です。タイ工場の90日PoCで、モーター、ポンプ、排気ファン、コンベヤー駆動軸の4台を対象にします。各設備について「何でも異常」ではなく、監視可能な故障モードを限定します。

振動センサーで何が測れ、何が測れないかは、振動センサーによる設備診断の実務ガイドで詳しく解説しています。システム全体のセンサー・収集・診断レイヤーと費用項目は、予知保全システム導入ガイドを参照してください。本稿ではその次の段階、つまり「候補システムをどう受け入れるか」に焦点を当てます。

90日を6フェーズに分ける

PoCを「90日間データをためる」と表現すると、最後の週まで重要な問題が見えません。受入項目に対応する6フェーズに分け、次へ進むゲートを設けます。

Day 61以降に無制限にモデルを調整してはなりません。評価データを見ながら閾値を合わせ続けると、PoC内だけ良く見える過学習になります。調整対象、回数、承認者を決め、Day 80で設定を凍結します。Day 81〜90は「見たことのない期間」として最終判定に使うのが実務的です。

検知リードタイムを設備異常検知システムの中心KPIにする

検知リードタイムは単に「故障の何日前」ではありません。基準となる事象時刻が曖昧だと測定不能です。故障モードごとに、次の3時刻を定義します。

• T_signal: 専門家レビューで、信号に持続的な変化が始まったと判断した時刻。
• T_alert: システムが最初の有効なWatch以上のアラームを生成した時刻。
• T_action: 保全担当が通知を確認し、点検またはワークオーダーを受け付けた時刻。

技術的な検知遅延は T_alert − T_signal、業務上の対応遅延は T_action − T_alert です。一方、実際の補修や停止時刻を T_event とすれば、行動可能な余裕は T_event − T_action です。「早く検知した」だけでは、誤報が早く出ただけかもしれません。保全部品の手配、計画停止への組み込み、二次診断に必要な時間を確保できたかで評価します。

90日間に自然故障が起きる保証はありません。そのため、次の複数の証拠を分けて扱います。

1. 実事象: 実際の劣化・異常を、点検または交換部品で確認したもの。最も強い証拠です。
2. 過去データ再生: 時刻順を守って過去波形を投入し、未来情報を使わず検知したもの。
3. 安全なシナリオ試験: センサー取り外し、入力模擬、通信断、速度変更など、設備を傷めない試験。
4. 解析上の兆候: 専門家が信号変化を認めたが、部品状態を確認できなかったもの。

これらを同じ「検知成功1件」に混ぜないでください。PoC報告では証拠レベル別に結果を示し、実事象がゼロなら「故障予知性能を実証した」とは表現せず、「信号取得・状態判定・運用フローを検証した」と限定します。

リードタイムの合格値は保全プロセスから逆算する

モデルケース（仮定）として、点検手配に4時間、交換部品の確認に1営業日、計画停止の調整に2営業日必要な設備を考えます。この場合、Criticalが停止直前に出るだけでは役に立ちません。WatchまたはCautionに「二次診断を始めるための余裕」を持たせ、Criticalは安全運用手順に従う最終段階として別管理します。

このレベル名は本稿の設計例です。NTN発表の「正常・初期損傷・注意・警告」と概念は近いものの、同社製品の判定ロジックや性能を表すものではありません。工場側の既存アンドンや警報名称と衝突する場合は、名称より「誰が何分以内に何をするか」を優先します。

誤報と見逃しを同じ表で管理する

異常検知では、誤報を減らすと見逃しが増え、見逃しを減らすと誤報が増える場合があります。片方だけを合格条件にすると、設定を極端に寄せられます。最低限、以下をセットで報告します。

• 真陽性（TP）: 正解イベントに対して許容時間内に有効アラームが出た。
• 偽陽性（FP）: 正解イベントがないのに、対応対象のアラームが出た。
• 偽陰性（FN）: 正解イベントがあるのに、許容時間内に有効アラームが出なかった。
• 真陰性（TN）: 評価窓に正解イベントがなく、対応対象アラームもなかった。

ただし連続時系列では「1秒ごと」を件数にするとTNが巨大になり、見かけの正解率がほぼ100%になります。工場PoCでは、イベント単位または設備日単位で分母を定義する方が実用的です。例えば同一設備・同一故障モードで30分以内に連続した通知は1イベントとして束ねる、という抑制規則を事前に置きます。

「正解」はシステム提供者だけで決めない

ラベル確定会議には、現場保全、設備技術、操業担当と、必要に応じて提供側の診断専門家が参加します。システムのスコアを隠した状態で、波形、温度、負荷、点検結果、交換部品、操業記録から正解イベントを決めると、自己採点を避けられます。意見が割れたものは「不確定」として主要KPIから分離し、感度分析に回します。

誤報から除外できる条件も先に決めます。センサー据付直後の慣らし、計画保全中の打撃、設備停止中の工事、速度レンジ外などです。後から「これは特殊運転だった」と除外すると、結果を恣意的に良くできます。逆に、日常的な起動・停止や品種切替は特殊ではありません。Emersonの2026年発表が起動・停止の長時間データに焦点を当てているように、過渡状態を監視設計に含める必要があります。

4段階アラームを「色」ではなく行動に変換する

状態監視画面に緑・黄・赤を並べても、保全フローが変わらなければPoCは成功していません。4段階の各レベルに、判定条件、通知、期限、権限、解除条件を持たせます。

重要なのは、異常検知システムに設備停止を自動決定させないことです。保護系と状態監視系の役割を分け、停止判断は既存の安全設計と権限体系に従います。状態監視アラームが安全計装や保護リレーの代替になると解釈してはいけません。

アラームの昇格・降格にはヒステリシス、持続時間、抑制条件を持たせます。例えば閾値を1回超えただけでCautionにせず、特定の運転状態で一定時間持続した場合に昇格させます。降格は上昇時と同じ境界ではなく、低い復帰閾値と確認時間を使い、行き来を抑えます。この具体値もモデルケースとしてFATで注入試験し、SATで現場信号に合わせて確認します。

通信断とセンサー欠測は「正常」と表示しない

PoCで最も危険な誤解の一つは、データがない時間を異常なしとみなすことです。通信断、センサー故障、電池切れ、ゲートウェイ停止、タグ設定ミス、時刻同期ずれは、設備が正常である証拠ではありません。状態値とは別にデータ品質ステータスを持たせます。

エッジ側のバッファと再送を受け入れる

90日PoCでは、ネットワークを意図的に遮断して次を試します。

1. ゲートウェイが通信断を規定時間内に検出する。
2. エッジ装置がローカルにデータを保持する。
3. ダッシュボードが「Normal」のまま止まらず、遅延または不明を示す。
4. 復旧後、時刻情報を維持してデータを再送する。
5. 重複イベントを作らず、欠損区間を明示する。
6. 通信断中にローカル判定が必要な場合、通知経路の代替が作動する。

モデルケース（仮定）として、1分特徴量を72時間保存する設計なら、FATで容量計算と満杯時動作を確認し、SATで2時間程度の計画遮断と再送を確認します。「72時間」は推奨値ではなく、その工場の復旧目標、通信品質、データ粒度から決めるパラメータです。

SKFは2026年9月8日の発表で、荷重、速度、温度、振動などを軸受内部から取得する同社のInsight bearingと、センシング・処理・通信を統合したハードウェア基盤を説明しています。これはSKFの製品発表として読むべきであり、一般的な性能保証ではありません。一方で、センサー、処理、通信が一体化するほど「どの層で欠測したか」を受入試験で識別する重要性は増します。Telit Cinterionも2026年9月10日の製品発表で、ライブのロボットラインにおけるエッジでの障害検知・復旧デモを予告しています。自動復旧を採用する場合でも、復旧した事実、停止時間、失われたデータ、実行された処置を監査可能にする必要があります。

状態監視を保全ワークオーダーへ接続する

設備診断 IoTがダッシュボードで止まると、現場は別画面を見て手入力することになります。PoCの受入範囲に、Caution以上のイベントからCMMSワークオーダーまたは点検依頼を作成する経路を入れます。完全な自動起票が難しい場合は、承認ボタンから下書きを作る方式でも構いません。

最低限、次の項目を引き継ぎます。

• 工場・ライン・設備の一意ID
• センサーIDと測定位置
• アラームレベル、開始時刻、継続時間
• 対象の故障モード候補と信頼度（ある場合）
• 波形・トレンド・運転条件へのリンク
• 推奨される次の確認（停止指示ではなく点検項目）
• 起票元イベントID
• 担当者、期限、優先度

完了時は、作業結果を逆方向に戻します。「異常なし」「増し締め」「給脂」「軸受交換」「センサー不良」「運転条件による変動」など、管理された結果コードを使い、自由記述だけにしません。この閉ループがなければ、90日後もシステムは誤報から学べず、経営側も回避停止時間や保全効果を説明できません。

ワークオーダー連携の受入シナリオ

責任分界はRACIだけでなく「障害時の最初の一手」まで決める

PoCが止まる典型的な場面は、センサー値が消えたときに、保全、IT、SIer、機器ベンダーの全員が相手待ちになることです。責任分界表には所有者だけでなく、検知、一次切り分け、証跡、復旧目標、エスカレーションを含めます。

サイバーセキュリティ上の異常検知と、設備状態の異常検知も区別します。NIST IR 8219は製造ICSにおける行動ベースのサイバー異常検知を扱い、ネットワークの異常行動を識別する複数の技術を評価しています。本稿の振動・温度による設備診断とは目的が異なります。ただし、OTネットワーク上に監視機器を追加する以上、資産把握、通信経路、ログ、アクセス権、変更管理を受入範囲から外すべきではありません。「設備の異常」と「通信の異常」を同じ赤ランプにまとめず、担当者と対応手順を分けます。

FATで工場に持ち込む前の不具合を落とす

FAT（Factory Acceptance Test）は、現場据付前に模擬入力とテスト環境で行います。センサー実機がなくても、データ再生や信号シミュレーターでかなりの項目を確認できます。

FATチェックリスト

1. タグと単位: 設備ID、測定点、方向、単位、サンプリング条件がデータ辞書と一致する。
2. 時刻: edge、gateway、server、CMMSのタイムゾーンと時刻同期を確認する。画面表示はICT、保存はUTCなどの規則を固定する。
3. 4段階遷移: Normal→Watch→Caution→Critical、および復帰を模擬信号で再現する。
4. ヒステリシス: 境界付近でアラームが振動しない。
5. 欠測: null、固定値、範囲外、時刻逆転を投入し、「不明」またはInvalidになる。
6. 通信断: 切断、バッファ、満杯、復旧、再送、重複排除を確認する。
7. 通知: タイ語・英語・日本語を含む担当者名や設備名が崩れず、宛先と抑制が正しい。
8. CMMS: 作成、更新、失敗、再試行、重複防止、設備マスタ不一致を確認する。
9. 権限: 閲覧、確認、閾値変更、管理者の権限を分離する。
10. 監査: 誰がいつ設定を変え、アラームを確認し、解除したかを追跡できる。
11. 版管理: モデル、ルール、ファームウェア、設定、データ辞書の版を記録する。
12. 輸出ファイル: 生データ、特徴量、イベント、作業結果を合意した形式で取得できる。

FAT合格は「現場で性能が出る」ことではありません。「仕様どおりに試験できる状態で、既知のインターフェース不具合を持ち込まない」ためのゲートです。未解決項目には重大度、回避策、期限、所有者を付け、重大な安全・データ完全性・起票重複の問題があれば据付へ進みません。

SATで現場条件と業務運用を受け入れる

SAT（Site Acceptance Test）は据付後、実設備と実ネットワークで行います。ここではセンサーの取り付け方向、ケーブル、電源、無線、設備ID、回転数、負荷、周囲振動、洗浄、温度など、机上では再現できない条件を確認します。

SATチェックリスト

• センサー位置・方向・締結トルク・識別ラベルを図面と照合する。
• 設備停止中のノイズ床と、代表的な速度・負荷での正常ベースラインを取る。
• 起動、停止、品種切替、清掃、アイドリングを別の運転状態として記録する。
• 現場端末、保全事務所、許可されたリモート接続から画面を確認する。
• 計画通信断を実施し、表示、ローカル保持、復旧、再送を確認する。
• Watch/Cautionの模擬イベントから通知確認、CMMS起票、完了フィードバックまで通す。
• 夜勤・休日の連絡先とエスカレーションをテストする。
• タイ語話者を含む実利用者が、アラーム理由と次の行動を説明できるか確認する。

FATとSATの証跡は、単なるスクリーンショット集にしません。要件ID、試験手順、期待結果、実結果、日時、データファイル、実施者、承認者、不具合IDを紐づけます。ISO 13374-3が状態監視情報のシステム間通信、ISO 13374-4が診断・予後情報や助言の表示を扱うように、データが画面へ届くだけでなく、意味と判断が保たれていることが重要です。

予知保全PoCのモデル試算：費用ではなく意思決定価値を示す

以下は実在顧客の事例ではなく、モデルケース（仮定）です。4台の重要回転設備を90日監視し、導入判断に必要な証拠を集める想定です。金額は契約条件、センサー数、接続方式、現地作業、CMMS仕様で大きく変わるため、ここでは金額を置かず工数と判定構造だけを示します。

効果試算も「停止を1件防いだ」と断定せず、シナリオで示します。

年間期待回避損失 = 対象故障の年間発生回数 × 1回当たり停止影響 × 検知後に回避できる割合

この式の各値にレンジを置き、低位・中位・高位で比較します。PoC中に故障が起きなかった場合でも、検知リードタイムとワークオーダー接続がシナリオ上の必要時間を満たすかを確認できます。ただし、自然故障の実証がない以上、回避割合は仮定であり、投資承認資料に事実として書いてはいけません。

一方、誤報負荷は比較的測りやすい指標です。

月間誤報対応工数 = 監視設備台数 × 1台1日当たりFP × 稼働日 × 1件当たり確認時間

モデルケース（仮定）として、4台、0.1件/設備日、26稼働日、1件15分なら、月2.6時間です。計算は 4 × 0.1 × 26 × 0.25 = 2.6。同じ条件で1.0件/設備日なら月26時間になり、現場定着は難しくなります。精度の小数点より、対応工数へ変換すると運用可否を判断しやすくなります。

PoC終了条件を開始前に決める

90日目に「もう少しデータを集めましょう」と自動延長するのは、PoCではなく未決状態の継続です。開始前に3つの出口を定義します。

Go（本導入へ進む）

• FAT/SATの重大不適合がゼロで、残課題に期限と所有者がある。
• 評価対象の各故障モードについて、合意した証拠レベルで検知結果がある。
• 誤報負荷と見逃しが、事前に合意した範囲内である。
• 通信断・欠測時に「不明」が正しく表示され、復旧と再送が成立する。
• 対象アラームから保全ワークオーダー、作業結果の戻しまで追跡できる。
• 工場側が日常運用を引き継げる。

Conditional Go（条件付き導入）

安全やデータ完全性を損なわない軽微な課題だけが残り、期限、費用負担、再試験、責任者が合意済みの場合です。例えば、特定の非重要設備で設備マスタ表記が未統一、レポートのタイ語表現を修正予定、といった課題です。検知見逃し、データ欠損の隠蔽、重複起票、権限不備を「運用でカバー」として条件付き合格にしません。

No-Go（停止または再設計）

• 監視対象の故障モードと取得信号が合っていない。
• 正常運転と日常的な過渡状態を分離できず、誤報負荷が許容外である。
• 重大イベントの見逃しがあり、原因と是正の再試験が完了していない。
• 通信断を正常表示し、欠測を追跡できない。
• CMMS連携で重複・誤設備起票が防げない。
• 誰が設定変更とアラーム判断を所有するか合意できない。

No-Goは失敗ではありません。対象設備を変える、追加信号を取る、監視方式を巡回測定にする、CMMS連携を先に整えるなど、次の投資を絞り込めたならPoCの役割を果たしています。

調達仕様に入れるべき納品物

予知保全PoCを「センサー貸出＋画面利用」とだけ発注すると、終了時にデータも設定も残らない場合があります。少なくとも次の納品物と利用権を契約前に確認します。

1. 設備・測定点・故障モード一覧
2. センサー据付図、型式、設定、校正情報
3. データ辞書、時刻・単位・欠測コード
4. 生データまたは合意した粒度のエクスポート
5. 特徴量、アラーム、設定変更、確認履歴
6. モデル・ルール・閾値の版と変更理由
7. FAT/SAT手順書と署名済み結果
8. API/CMMS連携仕様、設備ID対応表
9. 障害対応、バックアップ、復旧、サポート境界
10. PoC終了後の撤去、データ保持、アカウント削除手順
11. 本導入時のライセンス、通信、保守、追加設備単価の構造
12. 教育資料と工場側運用手順

ISO 13374-1は状態監視・診断情報のデータ処理、通信、表示に関するソフトウェア仕様の一般指針を示し、同シリーズPart 3はシステム間の情報交換、Part 4は技術分析と意思決定支援のための表示を扱います。規格への適合を安易に宣言するのではなく、データ可搬性、意味の保持、表示、責任者別の情報提供を調達質問へ落とし込むのが実務的です。

FAQ：設備異常検知システムの90日PoC

設備異常検知システムは90日で精度を証明できますか？

故障頻度が低い設備では、90日間に十分な実故障が発生せず、故障予知精度を統計的に証明できないことがあります。90日で確認すべきなのは、信号品質、運転状態の識別、既知データや安全なシナリオでの検知、誤報負荷、欠測処理、通知、CMMS接続、運用責任です。実故障が少ない場合は証拠レベルを明記し、「精度実証」と過大表現しないことが重要です。

状態監視システムの誤報率は何%なら合格ですか？

一律の正解はありません。重大度、監視台数、確認工数、運転パターンで許容値が変わります。比率だけでなく「1設備日当たりの対応対象誤報」と「月間確認工数」に換算し、同時に見逃し件数・重大度を確認します。分母、イベント束ね、除外条件を開始前に固定してください。

設備診断IoTで通信が切れたらどうすべきですか？

最終値をNormalのまま表示せず、Delayed、Missing、Invalidなどデータ品質を別表示し、設備状態を「不明」とします。エッジのバッファ、復旧後の時刻付き再送、重複排除、欠損区間、代替通知をFAT/SATで試験します。必要な保持時間は、復旧目標とデータ量から工場ごとに設計します。

予知保全PoCではFATとSATの両方が必要ですか？

役割が異なります。FATは持込前にタグ、時刻、アラーム遷移、欠測、通信断、CMMS、権限を模擬環境で確認します。SATは現場の据付、負荷、周囲ノイズ、ネットワーク、実利用者、夜勤を含めて確認します。小規模PoCでも試験票を分けると、ソフト不具合と現場条件を切り分けやすくなります。

4段階アラームは多すぎませんか？

各段階に異なる行動がなければ多すぎます。Normal、Watch、Caution、Criticalの例では、観察、二次診断、計画点検、緊急判断を分けます。既存の工場ルールが3段階なら無理に4色へ変える必要はありません。重要なのは状態、データ品質、通知期限、行動、解除条件が一意であることです。

PoCで自然故障が一度も起きなかったら不合格ですか？

必ずしも不合格ではありません。過去データ再生、安全な入力模擬、通信断、センサー欠測、ワークオーダー連携、運用応答は評価できます。ただし「故障予知に成功」とは言えません。本導入を段階化し、実事象が一定数たまった時点で再評価するゲートを設定します。

まとめ：90日PoCは製品デモではなく受入プロジェクト

タイ工場の設備異常検知PoCでは、センサーが値を出すことやAIスコアが表示されることをゴールにしません。Day 1〜5で受入仕様を固定し、検知リードタイム、誤報と見逃し、4段階アラーム、データ品質、通信復旧、CMMSワークオーダー、責任分界を一つの試験体系へ結びます。FATでインターフェースと異常系を落とし、SATで現場条件と人の行動を確認し、Day 80で設定を凍結します。Day 90にはGo、Conditional Go、No-Goのいずれかを、証跡付きで判断します。

自然故障が少ない90日でも、何を実証でき、何を未実証として残すかは明確にできます。よいPoCは「精度が高そう」という感想ではなく、「この設備、この故障モード、この運転条件で、何分前に検知し、誰が何時間以内に動き、どの記録が残るか」を答えられる状態です。

タイ工場で設備異常検知システムの候補比較、90日PoCの受入基準、FAT/SAT試験票、CMMS連携範囲を整理したい段階からご相談いただけます。既存設備と保全フローを確認し、実証できる範囲と未実証として残す範囲を切り分けます。TOMAS TECHへのお問い合わせをご利用ください。

参考情報・出典

• NTN株式会社「産業設備向け状態監視システム(CMS)の提供を開始」（2026-09-02）

https://www.ntn.co.jp/japan/news/new_products/news202600062.html

• Emerson, “Emerson Updates Turbomachinery Protection and Asset Health Monitoring for Safer Operations” (2026-09-08)

https://www.emerson.com/en/corporate/news/2026/emerson-updates-turbomachinery-protection-asset-health

• SKF, “SKF advances Insight bearing technology through collaboration with Sentea” (2026-09-08)

https://news.cision.com/skf/r/skf-advances-insight-bearing-technology-through-collaboration-with-sentea%2Cc4393025

• Telit Cinterion, “deviceWISE to Demonstrate Agentic AI and Automated Fault Detection & Recovery on Live Robotic Lines at IMTS 2026” (2026-09-10)

https://www.telit.com/press/devicewise-to-demonstrate-agentic-ai-robotic-at-imts-2026/

• NIST IR 8219, *Securing Manufacturing Industrial Control Systems: Behavioral Anomaly Detection* (2020)

https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8219.pdf

• ISO 17359:2018, *Condition monitoring and diagnostics of machines — General guidelines*

https://www.iso.org/standard/71194.html

• ISO 13374-1:2003, *Condition monitoring and diagnostics of machines — Data processing, communication and presentation — Part 1: General guidelines*

https://www.iso.org/standard/21832.html

• ISO 13374-3:2012, *Condition monitoring and diagnostics of machines — Data processing, communication and presentation — Part 3: Communication*

https://www.iso.org/standard/37611.html

• ISO 13374-4:2015, *Condition monitoring and diagnostics of machine systems — Data processing, communication and presentation — Part 4: Presentation*

https://www.iso.org/standard/54933.html