IO-Link 導入を検討するとき、「通信対応センサーへ交換すればデータが取れる」と考えるだけでは不十分です。センサー値がPLCへ届いても、その値の意味、単位、レンジ、品質、診断、機器版、設定変更の責任が決まっていなければ、MESやクラウドで再利用できる運用資産にはなりません。反対に、IO-Link Device、IO-Link Master、IODD、資産台帳、上位連携、FAT/SATを一つの受入設計にまとめれば、既存設備のセンサー データ収集を段階的に標準化できます。
本稿は、タイを含む製造拠点でIO-LinkのRFP、90日PoC、設備改造、横展開を担当する生産技術、保全、品質、IT/OTチーム向けの実務ガイドです。価格相場や根拠のないROIは示しません。代わりに、ベンダーへ何を要求し、何を試験し、どの証拠を受け取れば「つながった」ではなく「運用できる」と判断できるかを具体化します。
先に結論：IO-Link導入の成果は「点の意味」と「責任境界」で決まる
IO-Linkは、センサーとアクチュエーターのための標準化されたpoint-to-point通信です。IECの製品ページでは、2022年版のIEC 61131-9がSDCI（Single-drop digital communication interface）として、双方向の複雑データ交換、パラメータ転送、識別・診断情報を扱うと説明しています。IO-Link Communityも、双方向通信、拡張診断、パラメータ設定、IODDを主要な特徴として示しています。
しかし、通信仕様が標準でも、工場の運用責任は自動的に標準化されません。導入時は次の二つを同時に固定します。
- 点の意味を固定する：設備ID、センサー位置、測定対象、単位、物理レンジ、工学値変換、正常範囲、警報、診断コード、IODD版、パラメータ基準値、交換履歴を資産台帳に結びます。
- 責任境界を固定する：DeviceからMaster、PLC/Edge、SCADA、Historian、MES、OPC UA、JSON/REST、MQTT、クラウドまで、誰がマッピング、時刻、品質、再送、権限、変更、監視を持つかをFAT/SATで受け入れます。
つまり、IO-Linkの価値は「配線一本で賢いセンサーがつながる」という製品説明だけにはありません。設備の点データを、交換可能で、追跡可能で、上位システムが誤解せずに使える管理対象へ変えることにあります。
IO-Link Master・Device・IODDを一つの管理単位にする
IO-Link Deviceは値だけでなく状態と身元を持つ
IO-Link Deviceは、プロセスデータだけでなく、識別、パラメータ、診断などを双方向に扱えます。温度センサーなら「25.3」という数値だけでなく、単位、スケール、製品識別、通信状態、診断、設定値を管理できる可能性があります。ただし、どのデータが使えるかは機器とIODD、Master、実装範囲に依存します。RFPで「IO-Link対応」とだけ書かず、使用するデータ項目をDevice型式単位で列挙します。
デジタル値であっても意味の誤りは起こります。たとえば、同じ16 bitの値でも符号付きか、0.1単位か、無効値をどのコードで表すか、デバイス診断中の直前値を保持するかで結果は変わります。PLC側で都度ビット演算を手書きすると、ラインごとに解釈が分岐します。IODDの定義とベンダーの実装を照合し、変換ロジックを標準ブロックまたはEdge側モデルに集約します。
IO-Link Masterは単なる変換箱ではない
Masterは、複数のpoint-to-pointポートを上位ネットワークへ接続する境界です。ポート設定、Device認識、診断、パラメータ保管、交換時の復元、上位フィールドネットワークやEthernetへの連携を担います。ただし、Masterが何をどこまで持つかは製品差があります。Web UI、API、JSON、OPC UA、MQTT、クラウド連携の有無は、IO-Link規格そのものと製品機能を分けて確認します。
「MasterにMQTTがあるからMES連携まで完成」とは限りません。MQTT topic、payload schema、timestamp、quality flag、retain、QoS、再接続、証明書、ユーザー権限、データ欠損時の挙動は別の設計です。同様に、JSON/REST APIがあっても、設定変更APIと読取APIの権限分離、レート制限、監査、版管理が必要です。
IODDはファイル置き場ではなく版管理対象
IODDはDeviceのデータとパラメータを機械可読に記述する中核資産です。導入時には、型式に対応するIODDを収集するだけでなく、出所、ファイル名、版、チェックサム、対応ファームウェア、承認日、使用設備、変更理由を記録します。現場PCのダウンロードフォルダーだけに置かず、承認済みリポジトリを用意します。
交換品が同じシリーズでも、ファームウェアやIODD版が違えば、パラメータ項目や診断の表現が変わる可能性があります。自動パラメータ復元は便利ですが、無条件で旧設定を書き込むと危険です。Vendor ID、Device ID、Revision、互換性、対象ポート、基準値の一致を検証し、不一致なら隔離または人の承認へ送るルールを作ります。
点台帳に必要な項目：センサーデータ収集を「意味のあるデータ」にする
既存設備 IoT化では、まず全点を移行しようとせず、停止・品質・保全の判断に使う点から始めます。最低限、次の項目を点台帳へ持たせます。
| 分類 | 必須項目 | 受入の見方 |
|---|---|---|
| 識別 | 工場、ライン、設備、部位、ポート、Vendor ID、Device ID | 現物・図面・Master画面が一致 |
| 意味 | タグ名、測定対象、単位、符号、桁、レンジ | PLC/HMI/MESで同じ意味 |
| 品質 | valid/invalid、欠測、通信断、診断中、代替値 | 異常を正常値として使わない |
| 時刻 | 生成時刻、取得時刻、PLC scan、Edge受信時刻 | どの時刻を正本にするか明記 |
| 設定 | 基準パラメータ、許可範囲、変更者、変更理由 | 未承認変更を検知・復元可能 |
| 版 | IODD、Device firmware、Master firmware、PLC block | FAT証拠と本番構成が一致 |
| 保全 | 診断コード、交換日、交換前後ID、予備品 | MTTR分析と交換追跡に利用 |
| セキュリティ | 読取・設定権限、資格情報、ログ保持 | 汎用管理者を共有しない |
点名は短縮記号だけでなく、設備階層と意味を一意にします。単位は表示用文字列だけでなくデータモデルとして持ち、barとkPa、mm/sとm/s²などの混同を防ぎます。レンジはDeviceの物理範囲、運用範囲、警報範囲を分けます。品質はboolean一個ではなく、通信不成立、Device診断、値域外、設定不一致、保全モードを区別できる設計が望まれます。
責任境界を図面と試験で固定する
責任境界は、契約書の「連携対応」という一語では決まりません。少なくとも次の四層へ分けます。
1. SENSORからIO-LINK MASTER
Device選定、ケーブル、コネクター、ポートClass、供給電源、配線長、環境条件、IODD、ポートモード、サイクル、診断が対象です。現場では油、水、振動、溶接ノイズ、可動部、清掃薬品、温度、コネクター締結を確認します。通信成立だけでなく、断線、短絡、Device交換、誤型式、パラメータ不一致を試します。
2. IO-LINK MASTERからPLC / EDGE
上位プロトコル、GSD/EDS等の構成、タグマッピング、バイト順、データ型、スケール、更新周期、エラー値、通信断時の動作、パラメータ書込権限を決めます。PLCロジックがベンダー固有のアドレスへ密結合しないよう、標準function blockや名前付き構造体で吸収します。
3. PLC / EDGEからMES / CLOUD
設備階層、OPC UA NodeId、情報モデル、JSON schema、MQTT topic、timestamp、quality、store-and-forward、再送、重複排除、TLS証明書、利用者権限を定義します。OPC UA for IO-Link companion modelは、DeviceとMasterを共通情報モデルで表現する基盤になりますが、自社の設備ID、品目、ロット、作業指図との結び付けは別途必要です。
4. 運用・変更・障害対応
保全がDeviceを交換し、生産技術がパラメータを変え、ITが証明書を更新し、ベンダーがMaster firmwareを上げる場面を決めます。誰が変更を申請し、誰が承認し、どの試験を再実施し、どの版へ戻せるかを運用手順にします。障害時の一次切り分けも、センサー、ポート、Master、PLC、Edge、broker、MESのどこから始めるかを決めます。
OPC UA・JSON/MQTT連携をどう選ぶか
上位連携は一つに統一する必要はありません。用途ごとに責任を分けます。
| 方式 | 向く用途 | 設計上の注意 |
|---|---|---|
| PLCフィールドネットワーク | 高速制御、既存PLCロジック | ベンダー依存マッピング、制御と分析の分離 |
| OPC UA | 構造化参照、SCADA/Historian/MES | 情報モデル、NodeId安定性、証明書、権限 |
| JSON/REST | 設定、資産照会、オンデマンド取得 | API版、認証、レート、監査、書込分離 |
| MQTT | イベント、時系列、クラウド/データ基盤 | topic、schema、QoS、retain、再送、重複 |
OPC UAは情報モデルを持つため、Device識別やパラメータ、診断を構造化しやすい選択肢です。OPC UA FX・TSNの導入設計で解説したように、規格名だけで相互運用は保証されず、モデル、証明書、名前空間、受入データを固定する必要があります。
MQTTは疎結合な配信に向きますが、データ意味を自動で作ってくれません。たとえば factory/line1/master3/port4/value だけでは、Device交換後も同じ意味か判断できません。payloadにasset ID、measurement、unit、timestamp、quality、device revision、schema versionを含めるか、別の資産レジストリへ確実に参照できるようにします。
既存ネットワークへMasterを追加する場合は、帯域だけでなくVLAN、IP管理、NTP/PTP、DNS、証明書、firewall、リモート保守を設計します。産業ネットワーク構築の実務を先に整え、制御トラフィックと監視・分析トラフィックの責任を曖昧にしないことが重要です。
Standard・Wireless・Safetyは競合ではなく用途別の選択肢
Standard IO-Linkを基準線にする
固定設備で配線できるなら、まず標準の有線point-to-pointを基準にします。構成が見えやすく、電源と通信を同じ現場接続で扱え、無線共存設計を追加せずに済みます。可動軸、交換治具、回転体、長い配線工数、頻繁な段取り替えなど、有線の制約が明確なときにWirelessを比較します。
IO-Link Wirelessは無線化の理由と条件を試験する
IO-Link Wirelessの公式情報は5 msのcycle timeを示し、profileの設計条件として1 Master当たり最大40 Devices、20 m×20 mの領域で最大3 Masters・120 Devicesという高密度構成を説明しています。これは、任意の工場で常に120台が5 msで安定するという保証ではありません。チャネル計画、同期、障害物、金属反射、他の無線、アンテナ、Device配置、更新データ長、packet error、再送を含む条件付きの上限です。
PoCでは平均通信だけでなく、最悪遅延、packet error、連続欠損、再接続時間、電源/電池、メンテナンス、他無線稼働時、扉開閉、治具移動を測ります。制御ループに使うのか、診断収集に使うのかで許容値は違います。Wirelessは配線を減らす手段であって、電源、機械固定、交換作業、セキュリティ、電波法、サイト標準を消すものではありません。
IO-Link Safetyは通常Deviceを安全機器へ変えるものではない
IO-Link Safetyは、標準IO-Linkをblack channelとして使う機能安全通信で、公式情報ではIEC 61139-2、up to SIL 3 / PL e、標準とSafetyのmixed applicationが示されています。ここで重要なのは「up to」とシステム全体です。通常のIO-Linkセンサーを接続しただけでSIL 3やPL eになるわけではありません。Safety Device、Safety Master、上位安全制御、パラメータ、応答時間、安全機能、配線、診断、検証、証拠の全体が対象です。
Standard、Wireless、Safetyは三者択一の世代交代ではありません。一つのラインで、固定センサーはStandard、可動治具の診断はWireless、安全扉は適切なSafety構成、という混在があり得ます。採否は、用途、リスク評価、性能要求、保守体制、適用規格、現地条件で決めます。
RFPに書くべき12項目
RFPでは「IO-Link対応」「OPC UA対応」のチェック欄だけでなく、供給者が構成と証拠を回答できる形にします。
- 対象点一覧：設備、部位、測定対象、Device候補、点数、更新要求、診断用途。
- Device適合：型式、Vendor/Device ID、IODD版、firmware、環境、コネクター、予備品。
- Master設計：ポート数、Class A/B、電源、保護等級、上位通信、冗長/交換、予備率。
- データ辞書：タグ、型、単位、range、scale、quality、timestamp、診断、無効値。
- パラメータ管理：基準値、許可範囲、バックアップ、交換時復元、承認、監査。
- IODD管理：取得元、版、checksum、互換性、保管、変更通知、rollback。
- 上位連携：PLC、SCADA、Historian、MES、OPC UA、JSON/REST、MQTTの範囲。
- ネットワーク/セキュリティ：zone、VLAN、port、certificate、account、log、remote support。
- Wireless条件：site survey、coexistence、density、latency、packet error、recovery、battery。
- Safety条件：安全機能、required SIL/PL、response time、validation、変更管理、証拠。
- FAT/SAT：正常、異常、交換、通信断、設定不一致、上位連携、証跡の試験表。
- 納入物：as-built図面、点台帳、IODD一式、設定backup、code、license、training、support。
ベンダー回答は「可能」だけでは受け入れません。標準機能か、オプションか、追加gatewayか、個別開発か、誰の責任か、FATで実機確認できるかを回答欄に持たせます。特にnorthbound連携はMasterメーカー、PLC SI、MESベンダーの境界で抜けやすいため、end-to-endの主契約責任者を決めます。
90日PoC：小さくつなぎ、運用証拠まで作る
90日は効果を保証する期間ではなく、受入可能な最小構成を作る計画単位です。対象は一設備または一セル、8〜20点程度など、停止リスクとデータ意味を管理できる範囲に絞ります。この点数は市場標準ではなく、PoCスコープを決めるための例です。
Day 1–30：点と責任を設計する
- 現場ウォークダウン、課題、利用判断、対象点、既存配線、PLC余力を確認
- Device/Master候補とIODDを収集し、データ辞書と資産IDを作る
- Standard/Wireless/Safetyの境界をリスクと用途から決める
- PLC/Edge/MESの責任、変更承認、セキュリティzoneを合意
- FAT/SATの合否、証拠形式、未達時の修正方法を先に承認
Day 31–60：テストベンチとFATを作る
- 実Device、Master、PLC/Edge、上位受信先を接続
- 値、単位、scale、quality、timestamp、diagnostic、Device交換を確認
- IODD/firmware不一致、断線、電源断、ネットワーク断、broker停止を注入
- OPC UA/JSON/MQTTのschema、証明書、権限、再送、重複を試験
- 点台帳、as-built、backup、復元手順、教育資料を更新
Day 61–90：現場SATと運用移管を行う
- 計画停止で取付、配線、network、grounding、environmentを確認
- 実ワーク、実サイクル、清掃、段取り、保全モードで測定
- 上位画面と現物を照合し、alarm/diagnosticから担当者へ通知
- Device交換とパラメータ復元を保全担当者自身が実施
- 未解決事項、例外、残存リスク、横展開条件を承認して引き渡す
PoCの出口は「dashboardが見えた」ではありません。承認済み点台帳、FAT/SAT記録、異常時挙動、復元済みbackup、変更管理、運用責任者、次設備へ再利用できる標準部品がそろった状態です。
FAT/SAT受入表：正常系より異常系で差が出る
| ID | 試験 | FAT合否例 | SAT証拠 |
|---|---|---|---|
| T01 | 正常値 | raw→engineering valueが辞書と一致 | 現物基準との照合記録 |
| T02 | 単位・range | 全層で単位と上下限が一致 | HMI/MES画面capture |
| T03 | Device識別 | Vendor/Device/Revisionを取得 | 現物label・台帳照合 |
| T04 | 断線/短絡 | 値をinvalid化し診断発報 | 復旧時間と履歴 |
| T05 | 誤型式交換 | 自動復元せず拒否/承認待ち | 保全手順の実演 |
| T06 | 同型式交換 | 承認済み条件で設定復元 | 交換前後IDとparameter diff |
| T07 | IODD版不一致 | 警告・隔離・rollback可能 | repository履歴 |
| T08 | Master断 | PLC/Edge/MESでquality悪化 | 通信復旧と欠測範囲 |
| T09 | 上位断 | buffer/store-and-forward動作 | 再送・重複排除log |
| T10 | 権限 | 読取者のparameter書込を拒否 | audit log |
| T11 | 時刻 | 時刻源とtimestamp意味が一致 | NTP/PTP状態とsample |
| T12 | 負荷 | 対象周期・点数で安定 | latency/CPU/network記録 |
| T13 | Wireless | worst-case遅延・欠損が基準内 | surveyとcoexistence test |
| T14 | Safety | safety requirement通りに検証 | validation report |
| T15 | 変更 | firmware/IODD変更で再試験発火 | change ticket |
合否値は案件ごとに決めます。「通信できた」「画面に数字が出た」は合否ではありません。たとえば更新周期100 msが必要なら、測定点、観測時間、最大/percentile、欠損の扱いまで決めます。Wirelessなら公式上限をそのまま合否にせず、現場の許容遅延とpacket errorから基準を作ります。Safetyなら一般通信試験とは別に、適用する安全ライフサイクルで検証します。
既存設備への導入で失敗しやすい七つの点
1. センサーを全部交換してから用途を考える
データが増えても、保全・品質・生産の判断が変わらなければ運用コストだけが増えます。異常停止、交換頻度、品質影響、手作業巡回などの課題と点を対応させます。既存設備IoT化の進め方のように、停止を最小化して段階導入します。
2. IODDをSI担当者のPCだけに置く
引き渡し後にDevice交換やPLC改造ができません。版、checksum、対応型式、承認状態を持つ共有資産にします。
3. PLCへ生データ変換を散在させる
ラインごとにscaleやinvalid判定が違い、上位側で統合できません。標準ブロックとデータ辞書を用い、変更の影響を追跡します。
4. 上位連携を「IT側」とだけ書く
NodeId、topic、schema、timestamp、quality、certificate、retentionの所有者が不在になります。境界表に担当組織と受入証拠を書きます。
5. 自動パラメータ復元を常に有効にする
誤型式や互換性不明のDeviceへ設定を書き込む恐れがあります。識別と互換条件を満たしたときだけ復元します。
6. Wirelessを配線ゼロと誤解する
無線でも電源、取付、保全、電波、セキュリティは残ります。可動部や交換治具など、価値が出る箇所へ限定します。
7. Safetyという名称だけで安全認証済みと判断する
適合するDevice、Master、controller、application、validationの全体が必要です。通常IO-Linkとのmixed運用も、port設定と変更管理を試験します。
タイ拠点で確認する政策・投資の文脈
タイBOIの発表は、2023年から2026年上期の関連する自動化・デジタル化投資の文脈として1,397 projects、146 billion THB超を示しています。これはタイ製造業がmodernizationへ投資している政策背景として参考になりますが、IO-Link市場規模や個別案件の効果を示す数字ではありません。
BOIのsmart and sustainable measuresでは、公開ページにminimum investment 1 million THB、corporate income tax exemption 3 years、原則investmentの50% cap、国内automation machineryが30%以上の場合は100% capという説明があります。ただし、対象事業、対象費用、申請時期、国内調達比率、証拠、承認条件は案件ごとに確認が必要です。IO-Link機器を買えば自動的に優遇されるとは表現できません。投資申請を検討する場合は、BOIと専門家へ最新条件を確認し、技術RFPと税務・投資申請の証拠を整合させます。
運用KPIは機器台数ではなく「判断と復旧」で測る
IO-Link Device数や取得タグ数は進捗指標ですが、成果指標ではありません。運用目的に合わせ、次を測ります。
- 診断から原因候補特定までの時間
- Device交換から正常復帰までの時間
- パラメータ不一致の検知件数と是正時間
- 点台帳と現物の一致率
- invalid/欠測を含むデータ品質率
- 未承認設定変更の件数
- 異常時に上位で正しいqualityが表示された割合
- 再利用できた標準block、schema、試験項目の割合
- 横展開時に新規設計せず適用できた項目数
ROIを算定するなら、自社の停止時間、保全工数、不良、巡回、交換時間、ライセンス、設計、教育、予備品を使います。市場相場の仮定を記事から持ち込まず、現状baselineとPoC実測を比較します。効果と費用の期間、税、為替、稼働率、増産効果を同じ前提で扱い、感度分析を添えます。
FAQ：IO-Link導入でよくある質問
IO-Linkとはフィールドバスですか？
IO-LinkはIEC 61131-9で標準化された、センサーやアクチュエーター向けのpoint-to-point通信です。Masterの上位側では各種フィールドネットワークやEthernet系通信を使えますが、Deviceを共有バスへ直接多点接続する説明は正確ではありません。
IODDがあれば、どのMasterでも完全に同じ動作になりますか？
IODDはDeviceデータとパラメータの共通記述に重要ですが、Masterの対応版、engineering tool、上位mapping、vendor機能、firmware、profile対応は別に確認が必要です。FATで対象型式と版の組合せを固定します。
IO-Link MasterからMESへ直接つなぐべきですか？
用途次第です。制御に使う値はPLC、資産・診断はEdge/OPC UA、イベントはMQTTなど、責任を分ける構成も有効です。直接連携する場合も、MESが現場固有アドレスへ依存しない情報モデル、security、buffer、変更管理が必要です。
OPC UA for IO-Linkを使えばデータモデル設計は不要ですか？
不要にはなりません。Companion modelはDeviceとMasterを表現する共通基盤を提供しますが、工場・ライン・設備・品目・ロット・作業指図との関係、KPI定義、データ保持、権限は自社で設計します。
IO-Link Wirelessは有線IO-Linkをすべて置き換えますか？
いいえ。可動部、交換治具、配線困難箇所などで有力ですが、固定設備では有線が合理的な場合があります。5 msや最大台数はprofileの条件付き設計値であり、現場の電波・共存・最悪遅延を試験して採用します。
IO-Link Safetyなら通常IO-Linkセンサーも安全用途に使えますか？
そのようには判断できません。Safety対応のDevice、Master、上位安全制御と、要求SIL/PLに沿う設計・検証が必要です。通常Deviceは自動的にsafety-ratedにはなりません。
既存設備IoT化で最初に選ぶ点はどれですか？
停止、品質、交換、巡回など明確な業務判断に結び付く点を優先します。現状の故障履歴、手作業、欠測、交換時間を確認し、一設備でend-to-endの受入を完成させてから横展開します。
IO-Link導入の見積では何を分けるべきですか？
Device、Master、ケーブル/電源、network、PLC/Edge engineering、上位integration、IODD/asset governance、FAT/SAT、停止工事、教育、予備品、supportを分けます。標準機能、option、custom developmentを区別すると比較しやすくなります。
まとめ：通信の導入ではなく、点データの運用標準を作る
IO-Link 導入の成否は、対応機器を何台買ったかではなく、各点の意味、単位、range、quality、diagnostic、IODD/firmware版、parameter、交換履歴が追跡できるかで決まります。さらに、IO-Link MasterからPLC/Edge、OPC UA、JSON/MQTT、MES/Cloudまでの責任境界を図面とFAT/SATで固定し、異常系、交換、再送、権限、変更まで受け入れる必要があります。Wirelessは有線が難しい用途の追加選択肢、Safetyは適切な安全chainを構成する追加選択肢であり、標準IO-Linkの自動的な代替ではありません。
タイ工場でIO-LinkのRFP、90日PoC、既存設備への後付け、上位データ統合を検討中であれば、機器選定前の点台帳と受入表づくりの段階からTOMAS TECHへご相談いただけます。一設備の小さな範囲でも、現場・PLC・ネットワーク・MESの責任境界を一緒に整理できます。
参照した一次情報
- IO-Link Community — https://io-link.com/
- IO-Link Technology — https://io-link.com/technology
- IO-Link Wireless — https://io-link.com/technology/wireless
- IO-Link Safety — https://io-link.com/technology/safety
- IEC 61131-9:2022 — https://webstore.iec.ch/en/publication/68534
- OPC UA for IO-Link Devices and IO-Link Masters — https://reference.opcfoundation.org/specs/OPC-30120/4.2.6
- Thailand BOI press release — https://www.boi.go.th/index.php?_module=news&from_page=press_releases2&page=press_releases_detail&topic_id=139138
- Thailand BOI Smart and Sustainable Industry — https://www.boi.go.th/index.php?language=en&page=smart_sustainable
- IO-Link Downloads — https://io-link.com/downloads
- IO-Link Wireless Flyer 2025 — https://io-link.com/fileadmin/user_upload/Downloads/About_IO-Link/IO-Link_Wireless_Flyer_2025_Web.pdf
- IO-Link Safety System Description — https://io-link.com/fileadmin/user_upload/Downloads/About_IO-Link/IO-Link_Safety_System_Description_eng_2018.pdf
