TIS 30162 産業用IoT 互換性を調べる担当者が本当に知りたいのは、規格番号の意味だけではありません。異なるメーカーのセンサー、PLC、ゲートウェイ、SCADA、データ基盤をどう比較し、「つながる」という提案をどの証拠で受け入れるかが実務の論点です。本稿では、タイの一般規格TIS 30162-2568を、マルチベンダーIIoTのRFP、相互運用マトリクス、PoC、FAT/SATへ変換する方法を解説します。
結論：TIS 30162は認証ラベルではなく、相互運用の抜けを探す地図として使う
TISIの公式記録によると、TIS 30162-2568はISO/IEC 30162:2022を英語原文に基づいて同一内容で再印刷した一般規格で、開始日は2026年3月13日です。対象は、IIoT接続のネットワークモデル、データ伝送プロトコル間の相互作用、分散データの相互運用と管理、接続フレームワーク、接続トランスポート、接続ネットワーク、ベストプラクティスとガイダンスです。
ここで重要な留保があります。TISIはこの規格を「一般規格」と表示しています。本稿は、すべてのIIoT機器や工場システムにTIS 30162の取得・認証義務があるとは説明しません。また、規格を参照したこと、あるいはベンダーが「対応」と回答したことだけで、製品適合や組み合わせの相互運用性が証明されるわけでもありません。適用法令、調達条件、顧客要求、認証要否は対象製品と用途について所管機関や適切な専門家へ確認してください。
実務では、TIS 30162を「適合／非適合」の一列チェックに縮めず、次の四つへ展開します。
- 何と何を相互運用させるかを示すシステム境界図。
- プロトコル、プロファイル、情報モデル、ID、時刻、単位、品質、セキュリティを並べる相互運用マトリクス。
- ベンダーが提出する設定、サンプル、ログ、エクスポート、ライフサイクル手順。
- 異常系を含むFAT/SATの操作、期待結果、合否証跡。
購入前の機器・インターフェース棚卸しや、RFPを確定する前の受入条件づくりから支援が必要な場合は、TOMAS TECHへお問い合わせください。製品指名が固まっていない段階でも、既存設備を含む最小PoC範囲と証拠設計を整理できます。
TIS 30162-2568とISO/IEC 30162:2022で確認できること
ISOの公式カタログでは、ISO/IEC 30162:2022は2022年2月発行の第1版、44ページ、状態はPublishedとされています。TISIの公式ページは、タイ規格がこのISO/IEC規格のidentical reprintであることを明記しています。したがって、調達側はタイ語の規格名称だけでなく、国際規格側の書誌情報と抽象範囲を同じ基準として会話できます。
公式要約が示す六つの範囲は、調達質問へ次のように変換できます。
| 規格要約の領域 | RFPで問うこと | FAT/SATで残す証拠 |
|---|---|---|
| データ伝送プロトコルの相互作用 | どのプロトコル、版、プロファイル、役割、変換境界を使うか | 構成export、接続ログ、異版・未対応profileの拒否結果 |
| 分散データの相互運用・管理 | ID、型、単位、時刻、品質、意味、訂正をどう統一するか | sample payload、schema検証、期待値との照合、replay結果 |
| connectivity framework | device、edge、broker、SCADA、cloudの責任はどこか | 境界図、port/flow一覧、責任分担、障害時状態 |
| connectivity transport | Ethernet、Wi-Fi、LPWAN、MQTT等の条件は何か | 遅延、損失、切断、再接続、buffer試験 |
| connectivity network | address、routing、segmentation、name、QoSをどう管理するか | network設定、許可flow、監視、誤経路遮断 |
| best practices / guidance | 導入、監視、変更、更新、退出を誰が維持するか | runbook、version台帳、backup/restore、更新・撤去記録 |
この表は規格本文の代替ではありません。規格の各要求を自社用途へ適用するときの調達用索引です。規格を購入・参照する場合は正式版の適用範囲、用語、要求レベルを確認し、RFPには自社の観察可能な条件を書きます。
「接続できる」と「相互運用できる」は違う
pingが通る、MQTT brokerへpublishできる、OPC UA serverをbrowseできる。この三つは接続の重要な段階ですが、工場が必要とする相互運用の完成ではありません。受信側が値の意味を誤解せず、正しい設備・製品・時刻へ結び付け、通信断後も欠落や二重計上を起こさず、変更後も保守できて初めて業務はつながります。
例えば二社のゲートウェイがMQTT 5.0を使っても、topicがplant/line1/tempとsite/A/asset/27/valueで異なり、payloadの単位、timestamp、quality、設備IDが定義されていなければ、交換可能とは言えません。同じOPC UAでも、NodeIdの設計、namespace、Companion Specification、EngineeringUnits、status code、証明書運用が異なれば、上位システムの設定と試験が必要です。
相互運用性は少なくとも五層に分けて評価します。
| 層 | 合意する対象 | 失敗例 |
|---|---|---|
| 物理・接続 | 媒体、電源、port、radio、帯域、到達性 | 現場盤にportがない、電波が届かない |
| transport / protocol | version、profile、role、encoding、session、QoS | publishはするがretain/retry条件が不一致 |
| syntax / model | schema、datatype、namespace、topic、API | floatと文字列、配列構造、必須項目が不一致 |
| semantics | asset ID、単位、時刻、quality、状態、eventの意味 | 1がRUNか正常か、温度が℃か°Fか不明 |
| operation / lifecycle | onboarding、trust、監視、更新、backup、decommission | 証明書期限で停止、firmware更新でmappingが崩れる |
この五層のどれか一つでも未定なら、「標準プロトコル対応」は条件付きの主張です。ベンダーへ単純なYes/Noを求めるのではなく、対応版、制約、必要option、検証済み相手、未検証範囲、回避策を記入させます。
マルチベンダーIoTの境界を一枚に描く
最初の成果物は製品比較表ではなく、対象境界図です。センサーや計測器、PLC、edge gateway、industrial switch、broker、SCADA、historian、MESやanalyticsを左から右へ置き、各矢印に媒体、protocol、profile、direction、data owner、security boundaryを書きます。クラウド接続があってもなくても、誰がraw dataを持ち、誰がcanonical dataへ変換し、誰が業務イベントとして確定するかを示します。
境界図には「変換点」を目立たせます。Modbus registerから工学値への変換、vendor tagから共通asset modelへのmapping、LoRaWAN payloadから意味付きデータへのdecode、OPC UAからMQTTへのpublishなどです。変換点は価値を生む一方、単位、符号、byte order、欠測、時刻、qualityを誤る場所でもあります。変換ルールにはowner、version、test case、rollbackを付けます。
既存設備から信号を取得する方法そのものが未確定なら、老朽設備のIoTレトロフィット実務を先に確認してください。SCADAの役割や製品選定が主論点なら、タイ工場のSCADA選定ガイドが補完します。本稿はそれらの上で、複数製品間の互換性を発注・受入可能にする範囲へ集中します。
IIoT機器RFPに添付する相互運用マトリクス
相互運用マトリクスは、行にinterfaceを、列に要求と証拠を置きます。「OPC UA対応」「MQTT対応」の二列だけにしません。最低でも次の項目を機器またはinterfaceごとに記録します。
| 項目 | ベンダー回答に求める内容 | 購入側の確認 |
|---|---|---|
| Product / firmware | 型式、hardware revision、firmware、license、option | 見積・納品・試験機の一致 |
| Interface role | client/server、publisher/subscriber、gateway | 組合せに役割衝突がない |
| Standard / version | 規格番号、版、profile、必須／任意機能 | 「対応」の対象が具体的 |
| Data model | namespace、schema、Companion Spec、topic、payload | machine-readableな定義を受領 |
| Identity | device、asset、line、tag、lotの識別と重複規則 | ERP/MES/SCADA IDへ一意mapping |
| Value semantics | datatype、unit、scale、range、quality、null | 境界値・異常値で一致 |
| Time | clock source、timezone、timestamp位置、precision | NTP/PTP断や時刻ずれの扱い |
| Delivery | QoS、buffer、retry、ordering、deduplication | 欠落・重複・逆転の試験 |
| Security | identity、certificate、key、cipher、port、trust | provisioningと更新責任を確認 |
| Operations | health、log、metric、backup、remote support | 故障と通信断を判別できる |
| Change / exit | update、compatibility window、export、reset、EOL | 変更と撤去を試験可能にする |
回答欄には、Supported / Configurable / Requires gateway / Custom development / Not supported / Not testedのような選択肢を設けます。Supportedを選ぶ場合も、該当manual、設定export、sample payload、試験reportの参照を必須にします。「将来対応予定」は現行対応と混ぜず、対象version、責任者、契約上の扱いを分けます。
適合宣言より組合せ証拠を求める
製品AとBがそれぞれ同じ規格を参照していても、任意profile、version差、vendor extension、default security policyにより組合せ試験が必要です。RFPでは「製品が標準に適合するか」だけでなく、「提示したA–B–C構成で、指定scenarioを実行した証拠を提出できるか」と質問します。
認証書や試験報告がある場合は、scope、対象型式、firmware、試験profile、発行者、有効期間を確認します。書類の存在は有益ですが、自社のnetwork、asset model、負荷、断続条件を代替しません。FATでベンダー構成を確認し、SATで現地配線、VLAN、radio環境、時刻源、上位連携を含めて再確認します。
OPC UA相互運用性をRFPに書く方法
OPC UAは、Client/ServerとPubSub、情報モデル、security、discoveryなどを含む広い体系です。「OPC UAあり」という一言では比較できません。Client/Serverならserver/client role、endpoint、security policy、user identity、subscription、sampling、monitored item、history、method、eventなどの使用範囲を特定します。PubSubならmessage mapping、encoding、transport、broker有無、topic、metadata、security、PublisherId、DataSetWriterを特定します。
OPC FoundationのPart 14公式情報は、PubSubがUDP、MQTT、AMQP等へのmappingを扱うことを示します。ここから導ける調達上の教訓は、「MQTTを使う」だけではOPC UA PubSubのどのprofileとencodingを使うか分からないということです。逆に、独自MQTT payloadが直ちに悪いわけでもありません。schema、semantics、versioning、security、replayが十分に定義され、要求を満たすなら候補になります。標準採用の価値は、変換と再試験の範囲を減らせるかで評価します。
情報モデルでは、NodeIdだけでなくBrowseName、DisplayName、DataType、EngineeringUnits、EURange、status、source timestamp、server timestamp、asset hierarchyを確認します。Companion Specificationを使う場合は名称とversion、使用subset、vendor extensionを一覧にします。自由tagを使う場合は、canonical modelへmappingする責任とテストを置きます。
MQTTは運搬路、topicとpayloadはデータ契約
OASISのMQTT 5.0はpublish/subscribe messagingの標準です。しかしMQTT brokerへ接続できることは、factory dataの意味が一致することを保証しません。RFPでは、broker productだけでなく、client identifier、topic naming、wildcard、QoS、retained message、session expiry、will、message expiry、user properties、maximum packet size、authorization、TLS、certificate rotationを対象にします。
topicとpayloadにはversionを持たせます。例えばv1/site/{site}/asset/{asset}/telemetryとし、payload schemaでeventTime、sequence、value、unit、quality、sourceを定義します。ただしこれは設計例であり、TIS 30162の必須topicではありません。工場の規模、broker、既存システム、security policyに応じて決めます。
QoS 1や2を選んでも、application側のexactly-once業務処理が自動的に完成するとは限りません。再接続、broker failover、consumer再起動、DB commit失敗の境界で重複が起き得るため、event ID、sequence、idempotency、再処理手順を確認します。retained messageも、最新状態の配布には便利ですが、過去eventとの混同や古いcommandの再実行を避ける設計が必要です。
LoRaWANからOPC UAへのmapping動向をどう読むか
OPC FoundationとLoRa Allianceは、LoRaWANからOPC UA information modelへのmappingに関する共同working groupを2026年5月13日に正式発足させました。これは、低消費電力のedge connectivityと、意味を持つ標準化されたindustrial data modelの橋渡しを目指す動向として注目できます。
ただし、発表は「すべてのLoRaWAN機器がすでにOPC UAと自動相互運用する」ことを意味しません。調達時点では、device profile、payload codec、measurement unit、asset identity、gateway/network serverの責任、uplink/downlink、confirmed message、offline behaviour、mapping versionを個別に確認します。共同仕様や実装が更新された場合も、自社が採るversionと試験結果をbaseline化します。
LPWANを使う設備監視では、低頻度telemetryと制御を区別してください。遅延、duty cycle、coverage、battery、再送、downlink制約を確認せず、リアルタイム制御の代替として扱ってはいけません。相互運用性の高いモデル化は、通信媒体の物理的制約を消すものではありません。
secure onboardingと情報モデルを分けずに設計する
OPC Foundation Cloud Initiativeの2026年6月記事は、northbound interfaceとしてOPC UA Client/ServerまたはOPC UA PubSub over MQTTを使い、structured information modelとsemantic onboardingを重視する方向を説明しています。ここでの価値は、protocol変換だけでなく、assetの意味を保ったonboardingを一体で考える点にあります。証明書、buffer、監視、remote lifecycleの具体的な要件は、この記事だけから一律に導かず、対象製品と工場のRFPで別途定義します。
RFPでは、初回onboardingをデモさせます。箱を開けたdeviceがどのidentityを持ち、誰が所有権を確認し、どのCAやtrust listへ登録し、正しいasset recordと結び付け、失敗時にどこへquarantineされるかを観察します。出荷時default password、共有certificate、無期限token、手作業での秘密情報コピーに依存しないかを確認します。
W3C Web of Things Thing Description 1.1のようなmachine-readable descriptionは、metadataやinterfaceを記述し、onboardingを補助できます。しかし記述があるだけで、工場のasset hierarchy、品質ルール、保全責任まで確定するわけではありません。descriptionの生成者、署名・信頼、version、更新通知、canonical modelへのmapping、廃止時処理をRFPへ含めます。
分散データ相互運用で固定すべき七つの意味
分散データを統合する際は、payloadのfield名より先に次の七つを固定します。
- Identity：device serial、asset ID、line、station、tag、product、lotの関係。
- Time：event time、source timestamp、ingest time、timezone、clock source、精度。
- Value：datatype、scale、precision、range、unit、conversion、丸め。
- Quality：good/bad/uncertain、sensor fault、stale、manual、estimated、missing。
- Context：運転mode、recipe、work order、tool、operator、changeoverとの関係。
- Lineage：raw、decoded、converted、aggregated、correctedの変換履歴。
- Version：schema、mapping、firmware、configuration、masterの適用版。
例えば温度30.0だけでは不足です。℃か°Fか、sensorで測った時刻はいつか、gateway受信時刻か、校正外か、欠測補間か、どのassetに付くか、mapping versionはいくつかを受信側が判断できなければなりません。quality=goodもvendorごとに意味が違う可能性があるため、canonical qualityへのmapping表とnegative testを用意します。
データ収集全体のRFP・PoCを先に組み立てたい場合は、タイ製造データ収集システムのPoC・RFPガイドを参照してください。本稿の相互運用マトリクスは、そのinterface受入部分を深掘りするものです。
FAT/SATは「つながった画面」ではなく、壊れ方と復旧を受け入れる
FATでは供給者側の再現可能な構成で、機器、gateway、broker、OPC UA server/client、上位applicationの組合せを確認します。SATでは現地の電源、配線、switch、VLAN、firewall、radio、DNS/NTP、certificate、SCADA/MESを含めます。正常値が画面に出るだけでなく、異常を注入し、どこで検知され、どの状態へ遷移し、どう復旧するかを証拠化します。
| 試験 | 操作 | 合格条件の例 | 必須証拠 |
|---|---|---|---|
| Version/profile | 未対応版・任意profileを接続 | 黙って誤解せず、拒否または明示的に縮退 | negotiation log、alarm、設定 |
| Unit/type | ℃/°F、int/float、range外を投入 | mappingどおり変換し、不正値をquarantine | payload、変換表、受信値 |
| Time/quality | 時刻ずれ、stale、bad qualityを注入 | 誤った最新値として確定しない | source/ingest時刻、quality履歴 |
| Disconnect | linkまたはbrokerを30分停止 | 合意どおりbufferし、容量と状態を表示 | buffer件数、alarm、復旧log |
| Replay | 復旧後にeventを再送 | 欠落なく、重複計上なく、順序規則を維持 | event ID、sequence、DB照合 |
| Certificate | 期限切れ・未信頼certificateを使用 | 接続拒否、原因通知、監査log保持 | trust store、error、renewal記録 |
| Failover | gateway/broker/applicationを切替 | 合意時間内に復旧し、data整合を維持 | timeline、health metric、件数照合 |
| Change | firmware/schema/mappingを更新 | 影響を検知し、互換期間またはrollback可能 | version差分、test、承認、rollback |
| Export/exit | data・設定を一括export | 文書化されたmachine-readable形式で再利用可 | export file、schema、再import結果 |
表中の30分は説明用の例で、TIS 30162の一律要求ではありません。対象設備の許容停止、event rate、buffer容量、通信品質から時間と件数を決めます。重要なのは、合格条件を試験前に数値・状態・証拠で定義することです。
zero data lossという言葉を分解する
ベンダーがzero data lossを掲げる場合、どの境界と障害を含むか確認します。sensor自体がofflineなら測定値は存在しないかもしれません。gateway bufferは残っても電源断で消えるかもしれません。brokerが受け取ってもconsumer DBのtransaction前に落ちれば再配送が必要です。
したがって、source measurement、edge acquisition、local queue、transport acknowledgement、broker persistence、consumer processing、database commitの各点で、責任とsequenceを描きます。「損失なし」は、対象event、保持時間、最大rate、耐える障害、除外条件、検証方法が定義されて初めて受入可能な主張になります。
工場ネットワークとセキュリティのRFP条件
互換性を高めるためにportを広く開けたり、同じcredentialを全機器へ配ったりしてはいけません。接続可能性と最小権限を同時に設計します。asset inventory、zone/conduit、許可flow、identity、certificate、鍵更新、remote access、logging、backup、vulnerability notificationをinterface要件へ結び付けます。
機器のcertificate更新には、初期発行、失効、期限前通知、更新、trust list配布、時刻ずれ、交換機故障、factory resetを含めます。納品時に接続できても、12か月後の期限切れで停止するなら運用互換性は未完成です。supplier remote supportは、申請、承認、時間制限、MFA、session記録、終了確認を要求します。
security機能の有無だけでなく、誰が安全に運用できるかを確認します。deviceごとのbackup範囲、暗号化された設定export、restore先firmwareの制約、secretsの扱い、交換時のidentity引継ぎを試験します。factory reset後に古いcertificateやbroker credentialが残らないことも撤去試験へ含めます。
90日PoCでマルチベンダー構成を絞り込む
全工場・全設備をPoCへ入れる必要はありません。しかし、同じベンダーの機器だけで「マルチベンダー」を証明しても意味がありません。最小でも、異なるdeviceまたはPLC、edge gateway、network/broker、上位consumerを組み合わせ、実際に問題になりやすい一つの変換点を含めます。
1〜15日：境界と既存条件を固定
対象設備、信号、network、上位利用、停止窓、security ownerを確認します。device/interface台帳と現状data flowを作り、未確認情報を推測で埋めません。候補規格・versionと、現場で変更できない制約を分けます。
16〜30日：相互運用マトリクスとdata contract
ベンダー回答を同じ列で収集し、identity、time、unit、quality、schema、security、bufferを合意します。sample payloadと設定exportを入手し、自動validationと手動業務確認の両方を準備します。
31〜60日：正常系と意味の一致
sensorから上位画面・DBまで値を通し、rawとcanonicalを照合します。製品切替、運転／停止、sensor fault、manual overrideなどのcontextも確認します。画面が似ていることではなく、期待値集合との一致で判定します。
61〜75日：断続・異版・security・復旧
network断、broker停止、gateway再起動、certificate異常、時刻ずれ、schema変更、duplicate、out-of-orderを注入します。復旧中のbuffer、alarm、replay、operator操作を記録し、曖昧な手修正を禁止します。
76〜90日：SAT案、TCO、Go/No-Go
未解決gapをproduct、configuration、gateway、custom development、operationで分類します。5年TCOにはlicense、gateway、engineering、certificate運用、monitoring、upgrade、再試験、EOL移行を含めます。最終判断では、機能点数だけでなく、組合せの証拠、現地support、変更耐性、退出性を評価します。
IIoT機器RFPの評価配点例
以下は説明用の100点例であり、規格が定める配点ではありません。安全、品質、顧客要求に応じて必須条件と重みを調整してください。
| 評価軸 | 点 | 主な証拠 |
|---|---|---|
| Protocol/profile相互運用 | 15 | version、profile、組合せtest、設定export |
| 情報モデル・意味 | 20 | schema、namespace、unit、quality、ID mapping |
| 断続・buffer・replay | 15 | capacity、sequence、dedup、復旧test |
| Security・onboarding | 15 | identity、certificate、trust、remote access test |
| 監視・保守・変更 | 15 | health、log、backup、upgrade、rollback、EOL |
| 現場適合・performance | 10 | latency、rate、environment、local support |
| TCO・data portability | 10 | 5年費用、export、exit test、license条件 |
| 合計 | 100 |
mandatory gateとして、未承認default credential禁止、必要な暗号方式、machine-readable export、監査log、通信断時の安全状態、合意したdata loss/replay条件などを別に置きます。必須条件を満たさない候補は、便利なdashboardがあっても採用判断を保留します。
よくある失敗と契約での防止策
第一の失敗は、protocol名だけで互換と判断することです。契約にはversion、profile、role、encoding、security policy、information model、optionを記載します。第二は、gatewayにすべての変換責任を隠すことです。mapping source、target、unit、quality、time、owner、version、testを納品物にします。
第三は、PoCを安定したlab networkだけで終えることです。SATでは現場のswitch、firewall、wireless、NTP/DNS、電源、接地、環境条件、既存trafficを含めます。第四は、初回接続だけを受け入れ、更新と期限切れを試さないことです。firmware、certificate、schema、broker、上位applicationの変更シナリオを契約へ入れます。
第五は、data ownershipとexitを後回しにすることです。raw/canonical/aggregated data、configuration、mapping、logを誰が所有し、どの形式で、どの頻度で、追加費用なくexportできるかを決めます。system終了時はcredential失効、device reset、certificate廃止、cloud copy削除、replacement systemへの再importを確認します。
調達から運用までの成果物一覧
| Gate | 購入側成果物 | ベンダー提出物 | 承認者 |
|---|---|---|---|
| Concept | boundary図、use case、制約、risk | 可能構成、前提、未対応 | 製造・IT/OT |
| RFP | interoperability matrix、data contract案、試験案 | compliance matrix、evidence、費用 | 調達・技術 |
| Design | ID/model/time/security設計、責任分担 | 詳細設定、mapping、port/flow、runbook | design authority |
| FAT | test case、期待値、severity | 実行log、export、差異、修正 | FAT責任者 |
| SAT/UAT | 現地条件、業務scenario、合否 | 現地結果、教育、as-built | 工場owner |
| Operate | KPI、監視、変更、backup、incident | support、patch、EOL通知 | service owner |
| Exit | export/reimport、失効、削除、交換 | data/config、証跡、引継ぎ | data owner |
この成果物をRFP番号、design decision、test IDへ連結します。質問への回答が「可能です」で終わらず、どの設定・製品版・license・追加開発・証拠に基づくかを追跡できます。差異は欠陥、許容差、将来改善、対象外に分類し、誰がいつ判断したかを残します。
FAQ：TIS 30162と産業用IoT相互運用性
TIS 30162-2568はタイのIIoT機器に必須の認証ですか？
TISI公式ページはTIS 30162-2568を一般規格と表示しています。本稿は、すべてのIIoT機器、輸入、工場導入に一律の取得・認証義務があるとは述べません。対象製品・用途の強制規格、通信規制、顧客要求、契約条件は個別に確認してください。
TIS 30162への「対応」をRFPでどう確認しますか？
Yes/Noだけでなく、対象型式、firmware、参照版、対象scope、実装profile、除外、試験報告を求めます。さらに自社構成の相互運用マトリクスとFAT/SATで、データ意味、断続、security、変更を実証します。
OPC UA対応ならマルチベンダーIoTは自動でつながりますか？
自動ではありません。role、profile、version、information model、namespace、unit、quality、certificate、運用条件を合わせる必要があります。標準は共通土台を増やしますが、組合せ証拠は残ります。
MQTT 5.0ならデータ欠落は起きませんか？
保証されません。QoSはdeliveryの一部を扱いますが、sensor、gateway、broker、consumer、databaseの全境界を自動的に保証しません。buffer、persistence、event ID、deduplication、replay、監視を設計・試験します。
IIoT機器RFPで最も重要な添付資料は何ですか？
対象境界図、interface台帳、相互運用マトリクス、data contract、FAT/SAT test caseです。これらがあれば、異なるベンダーの「対応」という言葉を同じ証拠で比較できます。
FATとSATの両方が必要ですか？
役割が異なります。FATは制御しやすい供給者環境で組合せと異常系を反復し、SATは現地の配線、network、radio、時刻、証明書、上位systemを含めて確認します。riskに応じて範囲を決めます。
まとめ：規格番号を、比較可能な証拠へ変える
TIS 30162-2568は、ISO/IEC 30162:2022と同一内容で、IIoTのprotocol interaction、distributed data interoperability、connectivity framework・transport・network、best practicesを扱う一般規格です。これを認証ラベルとして短絡せず、抜けを探す構造として使うと、マルチベンダーIoTの調達品質を高められます。
境界図で変換点を見つけ、相互運用マトリクスでversion、profile、model、ID、time、unit、quality、security、lifecycleを固定します。OPC UA、MQTT、LoRaWAN、WoT TDは有力な構成要素ですが、採用名ではなく組合せの動作で評価します。FAT/SATでは正常表示だけでなく、異版、欠測、時刻ずれ、通信断、replay、certificate、update、exportを試し、設定、payload、log、照合結果を受入証拠として残してください。
TIS 30162の六領域を自社のinterface一覧へ対応付け、ベンダー間で比較できるRFPと受入証拠を作りたい段階でもご相談いただけます。TOMAS TECHへのお問い合わせから、現状構成と未確定の接続範囲をお知らせください。
リサーチソース
- TISI, TIS 30162-2568 official record: https://a.tisi.go.th/t/?n=9612
- ISO, ISO/IEC 30162:2022: https://www.iso.org/standard/53282.html
- OPC Foundation / LoRa Alliance joint mapping activity: https://opcconnect.opcfoundation.org/2026/06/opc-foundation-and-lora-alliance-join-forces-to-map-lorawan-to-opc-ua/
- OPC Foundation Cloud Initiative, Cloud Corner June 2026: https://opcconnect.opcfoundation.org/2026/06/cloud-corner-june-2026/
- OPC Foundation, OPC UA Part 14 PubSub: https://profiles.opcfoundation.org/document/15
- W3C, Web of Things Thing Description 1.1: https://www.w3.org/TR/wot-thing-description11/
- OASIS, MQTT Version 5.0: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
※2026年9月に上記一次情報を確認しました。本稿は一般的な技術・調達情報であり、法務、規制、認証の助言ではありません。適用要件はTISI等の所管機関、顧客仕様、契約、対象製品について個別に確認してください。
