When a factory team searches for TIS 30162 industrial IoT interoperability, it rarely needs another list of protocol names. It needs to know how to compare sensors, PLCs, gateways, SCADA platforms and data services from different suppliers—and what evidence proves that “they connect” under real operating conditions. This guide turns Thailand’s TIS 30162-2568 into practical requirements for a multi-vendor IIoT RFP, an interoperability matrix, a proof of concept, and FAT/SAT acceptance.
The conclusion: use TIS 30162 as a gap map, not as a certification sticker
The official Thai Industrial Standards Institute record describes TIS 30162-2568 as a general standard, effective from 13 March 2026, and an identical reprint of ISO/IEC 30162:2022 based on the English text. Its scope covers network models for IIoT connectivity, interaction between data-transmission protocols, distributed-data interoperability and management, the connectivity framework, transport, network, and best-practice guidance.
That wording requires an important boundary. TISI labels this a general standard. This article does not claim that every IIoT device, import or factory system must obtain TIS 30162 certification. Referencing the standard, or receiving a vendor’s “compliant” answer, does not by itself prove product conformity or interoperability of a particular combination. Confirm mandatory requirements, customer specifications and certification obligations for the actual product and use case with the relevant authority or qualified adviser.
For procurement, expand the standard into four deliverables:
- A boundary diagram that identifies exactly what must interoperate.
- A matrix covering protocols, profiles, models, identity, time, units, quality and security.
- Vendor evidence: configurations, samples, logs, exports and lifecycle procedures.
- FAT/SAT test steps, expected results and objective acceptance records—including failures.
If you are still inventorying interfaces or have not fixed the RFP, contact TOMAS TECH. We can help define a minimum multi-vendor PoC and acceptance evidence before a product shortlist becomes difficult to change.
What TIS 30162-2568 and ISO/IEC 30162:2022 establish
ISO’s official catalogue lists ISO/IEC 30162:2022 as Edition 1, published in February 2022, with Published status and 44 pages. TISI states that the Thai standard is an identical reprint. A Thailand project can therefore align its vocabulary with the international publication rather than treating the Thai title as an unrelated local document.
The six scope areas in the official abstracts become procurement questions as follows.
| Scope area | Question for the RFP | FAT/SAT evidence |
|---|---|---|
| Protocol interaction | Which protocol, version, profile, role and conversion boundary apply? | Configuration export, connection log, unsupported-profile result |
| Distributed-data interoperability | How are IDs, types, units, time, quality, meaning and corrections aligned? | Payload, schema result, expected-value comparison, replay |
| Connectivity framework | Where do device, edge, broker, SCADA and cloud responsibilities start and end? | Boundary drawing, port/flow list, RACI, failure state |
| Connectivity transport | What Ethernet, Wi-Fi, LPWAN or messaging conditions apply? | Latency, loss, disconnect, reconnect and buffer test |
| Connectivity network | How are addressing, routing, segmentation, naming and QoS governed? | Network export, allowed flows, monitoring, blocked-flow test |
| Best practices and guidance | Who maintains onboarding, monitoring, changes, updates and exit? | Runbook, version register, restore and decommission records |
This table is not a substitute for the standard. It is a buyer’s index for converting broad coverage into observable conditions for a specific factory.
Connection is not interoperability
A successful ping, an MQTT publish, or browsing an OPC UA server is a valuable milestone. It is not the end of factory interoperability. The consumer must interpret the value correctly, bind it to the correct asset and time, avoid loss or double counting after a disruption, and remain supportable after certificates, firmware and schemas change.
Two gateways may both support MQTT 5.0 while using incompatible topic structures and undefined payload units, timestamps, quality and asset identifiers. Two OPC UA products may still require engineering because NodeIds, namespaces, Companion Specifications, EngineeringUnits, status handling and certificate operations differ.
Evaluate at least five layers.
| Layer | What must agree | Typical failure |
|---|---|---|
| Physical/connectivity | Medium, power, port, radio, bandwidth, reachability | No cabinet port or insufficient coverage |
| Transport/protocol | Version, profile, role, encoding, session, QoS | Retain or retry behaviour differs |
| Syntax/model | Schema, datatype, namespace, topic, API | String versus float or missing mandatory field |
| Semantics | Asset ID, unit, time, quality, state and event meaning | 1 means RUN to one vendor and HEALTHY to another |
| Operations/lifecycle | Onboarding, trust, monitoring, update, backup and exit | Certificate expiry or firmware breaks mapping |
If any layer is undefined, “standard protocol supported” remains a conditional statement. Require the supported version, constraints, options, tested peers, untested areas and workaround—not only Yes or No.
Draw the multi-vendor IoT boundary first
Place sensors and instruments, PLCs, edge gateways, industrial switches, brokers, SCADA/historian and MES or analytics from left to right. Label each arrow with medium, protocol, profile, direction, data owner and security boundary. Whether the design uses cloud or stays on premises, identify who owns raw data, who converts it to a canonical model, and who confirms the business event.
Highlight every conversion: Modbus register to engineering value, vendor tag to asset model, LoRaWAN payload decode, or OPC UA to MQTT publication. Conversions add value but are also where byte order, sign, scale, unit, missing-data, time and quality errors enter. Each mapping needs an owner, version, test cases and rollback method.
If the unresolved issue is how to acquire signals from older machines, see our aging-equipment IoT retrofit guide. If the primary decision is the supervisory platform, use the SCADA selection guide for Thailand factories. This article addresses the next problem: making the resulting multi-vendor interfaces contractible and testable.
Build an interoperability matrix for the IIoT device RFP
Use one row per device or interface. Do not stop at columns named “OPC UA” and “MQTT.”
| Matrix field | Vendor answer required | Buyer check |
|---|---|---|
| Product/firmware | Model, hardware revision, firmware, licence and option | Quotation, delivery and test unit match |
| Interface role | Client/server, publisher/subscriber, gateway | No role conflict in the combination |
| Standard/version | Standard, edition, profile, mandatory/optional functions | Scope of “support” is explicit |
| Data model | Namespace, schema, Companion Spec, topic and payload | Machine-readable definition delivered |
| Identity | Device, asset, line, tag and lot identifiers | Unique mapping to SCADA/MES/ERP IDs |
| Value semantics | Datatype, unit, scale, range, quality and null | Boundary and bad-value tests pass |
| Time | Clock source, timezone, timestamp location and precision | Clock-loss and skew behaviour known |
| Delivery | QoS, buffer, retry, order and deduplication | Loss, duplication and inversion tested |
| Security | Identity, certificate, key, cipher, port and trust | Provisioning and renewal ownership clear |
| Operations | Health, log, metric, backup and remote support | Fault can be distinguished from disconnect |
| Change/exit | Update, compatibility window, export, reset and EOL | Upgrade and decommission can be tested |
Use answer classes such as Supported, Configurable, Requires gateway, Custom development, Not supported, and Not tested. “Supported” should still cite a manual, configuration export, sample payload or test report. Keep roadmap promises separate from currently available functionality.
Ask for combination evidence, not a logo alone
Products A and B may each reference the same standard yet select different optional profiles, versions, extensions or security defaults. Ask whether the proposed A–B–C combination can execute the named scenario, and what evidence will be delivered.
If a certificate or external report exists, verify its scope, model, firmware, tested profile, issuer and validity. It may be useful evidence, but it does not replace the site’s network, asset model, load and disruption tests. Confirm the supplier configuration in FAT, then repeat the site-dependent parts with VLANs, wireless conditions, time sources and upper systems in SAT.
Write OPC UA interoperability as specific requirements
OPC UA spans Client/Server, PubSub, information models, security and discovery. “OPC UA available” is too broad for comparison. For Client/Server, name roles, endpoints, policies, identities, subscriptions, sampling, monitored items, history, methods and events in scope. For PubSub, identify message mapping, encoding, transport, broker use, topics, metadata, security, PublisherId and DataSetWriter.
The OPC Foundation’s official Part 14 information lists mappings including UDP, MQTT and AMQP. A requirement that merely says “use MQTT” therefore does not identify the OPC UA PubSub profile or encoding. Conversely, a proprietary MQTT payload is not automatically unacceptable. If its schema, semantics, versioning, security and replay behaviour are precise and meet the use case, it may be viable. Measure the value of standards by how much mapping and re-testing they remove.
For the information model, check BrowseName, DataType, EngineeringUnits, range, status, source timestamp, server timestamp and asset hierarchy—not only NodeId. Name the Companion Specification and version, the subset in use and vendor extensions. When free-form tags remain, assign ownership and tests for mapping to the canonical model.
MQTT is the delivery path; topics and payloads are the data contract
OASIS MQTT 5.0 standardizes publish/subscribe messaging. Broker connectivity alone does not standardize factory meaning. Include client identifiers, topic naming, wildcards, QoS, retained messages, session expiry, will messages, message expiry, user properties, packet limits, authorization, TLS and certificate rotation in the RFP.
Version the topic and payload contract. An illustrative design might use v1/site/{site}/asset/{asset}/telemetry and require eventTime, sequence, value, unit, quality and source. This is an example—not a topic required by TIS 30162. Select rules for the actual estate and security architecture.
QoS 1 or 2 does not automatically provide exactly-once business processing across gateway, broker, consumer and database transactions. Define event IDs, sequences, idempotency and reprocessing. Retained messages help distribute state, but tests must prevent stale state or an old command from being mistaken for a new event.
How to interpret the LoRaWAN-to-OPC UA mapping activity
The OPC Foundation and LoRa Alliance formally launched their joint working group to map LoRaWAN to OPC UA information models on 13 May 2026. The direction is relevant: combine efficient edge connectivity with semantically structured industrial information.
It is not evidence that every LoRaWAN device already interoperates automatically with OPC UA. At procurement time, still verify device profiles, payload codecs, units, asset identity, gateway and network-server responsibility, uplink/downlink, confirmed messaging, offline behaviour and mapping version. When joint specifications and products mature, baseline the exact version and site test.
Separate low-rate monitoring from control. Latency, duty cycle, coverage, battery, retry and downlink constraints do not disappear because the data is mapped into a strong information model.
Design secure onboarding with semantics and lifecycle
The OPC Foundation Cloud Initiative’s June 2026 article describes OPC UA Client/Server or OPC UA PubSub over MQTT as a northbound interface and emphasises structured information models and semantic onboarding. The practical point is to design protocol conversion and asset meaning together. Do not derive universal certificate, buffering, monitoring or remote-lifecycle requirements from that page alone; define them separately for the proposed product and factory.
Require an onboarding demonstration. Observe how a new device proves identity, how ownership is approved, how trust is established, how it is linked to the correct asset record, and where failed devices are quarantined. Look for dependence on default passwords, shared certificates, permanent tokens or manual copying of secrets.
W3C Web of Things Thing Description 1.1 can provide machine-readable metadata and interfaces. A description alone does not establish the plant’s hierarchy, quality rules or maintenance owner. Include who creates and trusts it, versioning, update notification, mapping and retirement.
Fix seven meanings for distributed data interoperability
- Identity: relation among serial, asset, line, station, tag, product and lot.
- Time: event time, source time, ingest time, timezone, clock source and precision.
- Value: datatype, scale, precision, range, unit, conversion and rounding.
- Quality: good/bad/uncertain, sensor fault, stale, manual, estimated and missing.
- Context: operating mode, recipe, work order, tool, operator and changeover.
- Lineage: raw, decoded, converted, aggregated and corrected transformations.
- Version: schema, mapping, firmware, configuration and master-data versions.
A temperature value of 30.0 is insufficient without unit, source time, quality, asset and mapping version. Even quality=good may have vendor-specific meaning, so define canonical mapping and negative tests.
For the broader acquisition and platform RFP, see our Thailand manufacturing data-collection PoC and RFP guide. The matrix here deepens its interface-acceptance section.
FAT/SAT must accept failure and recovery—not just a connected screen
FAT verifies the reproducible supplier combination. SAT adds the site’s power, cabling, switches, VLANs, firewall, radio environment, DNS/NTP, certificates and upper systems. Inject failures and record detection, state change and recovery.
| Test | Action | Example acceptance | Required record |
|---|---|---|---|
| Version/profile | Connect unsupported edition/profile | Reject or explicitly degrade; never silently misread | Negotiation log, alarm, configuration |
| Unit/type | Inject °C/°F, int/float and out-of-range | Convert as specified; quarantine invalid values | Payload, mapping, received value |
| Time/quality | Inject clock skew, stale and bad quality | Do not confirm as a valid latest value | Source/ingest time, quality history |
| Disconnect | Stop link or broker for 30 minutes | Buffer as agreed and expose capacity/state | Buffer count, alarm, recovery log |
| Replay | Resend after recovery | No loss or double count; ordering rule maintained | Event ID, sequence, database reconciliation |
| Certificate | Use expired or untrusted certificate | Reject, explain and audit | Trust store, error, renewal record |
| Failover | Switch gateway/broker/application | Recover within agreed time with consistent data | Timeline, health metric, counts |
| Change | Update firmware/schema/mapping | Detect impact; support compatibility or rollback | Version diff, test, approval, rollback |
| Export/exit | Export data and configuration | Reusable documented machine-readable output | Files, schemas and re-import result |
Thirty minutes is illustrative, not a TIS 30162 requirement. Derive time and volume from the process tolerance, event rate, buffer and communications.
Decompose “zero data loss”
Ask which boundary and faults the statement covers. A sensor that loses power may never create a measurement. An edge buffer may be volatile. A broker may persist a message while the consumer fails before database commit.
Draw source measurement, acquisition, local queue, transport acknowledgement, broker persistence, consumer processing and database commit. “No loss” becomes acceptable only when event scope, retention time, peak rate, tolerated faults, exclusions and verification are named.
Network, security and maintainability requirements
Do not create interoperability by opening broad ports or distributing one credential to every device. Join the asset inventory, zones/conduits, permitted flows, identity, certificate lifecycle, remote access, logs, backups and vulnerability notifications to the interface requirements.
Certificate operations must cover issuance, revocation, expiry alerts, renewal, trust-list distribution, clock errors, replacement hardware and factory reset. A solution that connects on delivery but fails at the first annual renewal is not operationally interoperable. Remote support should be requested, approved, time-limited, MFA-protected, recorded and closed.
Test encrypted configuration backup, restoration across supported firmware, treatment of secrets and replacement-device identity. Decommissioning should remove old certificates and broker credentials.
A 90-day multi-vendor PoC
Use at least one real conversion point and different device/PLC, edge, network/broker and upper consumer products.
Days 1–15: fix boundaries and constraints
Inventory assets, signals, network, upper use, outage windows and security owners. Mark unknown facts as unknown rather than assuming support.
Days 16–30: matrix and data contract
Collect comparable vendor answers. Agree identity, time, units, quality, schema, security and buffers. Obtain sample payloads and configuration exports.
Days 31–60: normal flow and semantic agreement
Trace values from sensor to screen and database. Compare raw and canonical values, including mode, product change, sensor fault and manual override.
Days 61–75: disruption, version, security and recovery
Inject network outage, broker stop, gateway reboot, certificate failure, clock skew, schema change, duplicates and out-of-order messages. Record buffers, alarms, replay and operator actions.
Days 76–90: SAT plan, TCO and decision
Classify gaps as product, configuration, gateway, custom development or operation. Include licences, gateway engineering, certificate operation, monitoring, upgrade re-test and EOL migration in five-year TCO.
Example RFP scoring
This 100-point model is illustrative and is not specified by TIS 30162.
| Evaluation | Points | Evidence |
|---|---|---|
| Protocol/profile interoperability | 15 | Versions, profiles, combination test, export |
| Information model and semantics | 20 | Schema, namespace, units, quality, ID mapping |
| Disruption, buffer and replay | 15 | Capacity, sequence, deduplication, recovery |
| Security and onboarding | 15 | Identity, certificate, trust and access tests |
| Monitoring, maintenance and change | 15 | Health, logs, backup, upgrade, rollback, EOL |
| Site fit and performance | 10 | Latency, rate, environment, local support |
| TCO and portability | 10 | Five-year cost, export, exit and licence terms |
| Total | 100 |
Place mandatory gates outside the score: no unapproved default credentials, required encryption, machine-readable export, audit logs, safe disconnected state and agreed loss/replay behaviour.
Frequent failures and contractual controls
Do not accept a protocol name without version, profile, role, encoding, policy and model. Do not hide all transformation inside an undocumented gateway; require source/target mappings, units, quality, time, ownership and tests. Do not finish the PoC on a clean lab network; repeat site-dependent conditions in SAT. Do not accept initial connection without testing certificates, firmware, schemas and application changes.
Finally, define ownership and exit. State who owns raw, canonical and aggregated data, configuration, mappings and logs; the format and frequency of export; and any charge. The exit test should revoke credentials, reset devices, retire certificates, address cloud copies and re-import into a replacement environment.
Deliverables from concept to exit
| Gate | Buyer deliverable | Supplier deliverable | Approver |
|---|---|---|---|
| Concept | Boundary, use case, constraints, risks | Options, assumptions, unsupported items | Production and IT/OT |
| RFP | Matrix, draft data contract, tests | Compliance, evidence and cost | Procurement and technical |
| Design | ID/model/time/security design, RACI | Configuration, mapping, flows, runbook | Design authority |
| FAT | Cases, expected values, severity | Logs, exports, deviations, corrections | FAT owner |
| SAT/UAT | Site conditions and business scenarios | Site result, training, as-built | Factory owner |
| Operate | KPIs, monitoring, change, backup, incident | Support, patches and EOL notices | Service owner |
| Exit | Export/re-import, revoke, erase and replace | Data/configuration and handover evidence | Data owner |
Link every answer to an RFP number, design decision and test ID. “Possible” then becomes traceable to a configuration, version, licence, development item and acceptance record.
FAQ: TIS 30162 and industrial IoT interoperability
Is TIS 30162-2568 mandatory certification for all IIoT equipment in Thailand?
TISI’s official record labels it a general standard. This article does not claim a universal certification duty. Check the specific product, radio/communications rules, customer contract and use case.
How should an RFP verify a vendor’s TIS 30162 claim?
Request model, firmware, referenced edition, scope, profiles, exclusions and reports. Then test the proposed combination’s semantics, disruption, security and changes in FAT/SAT.
Does OPC UA guarantee plug-and-play multi-vendor IoT?
No. Align roles, profiles, versions, models, namespaces, units, quality, certificates and operations. Standards improve the shared foundation but do not eliminate combination testing.
Does MQTT 5.0 guarantee no data loss?
No. QoS covers part of message delivery. Sensor, edge, broker, consumer and database boundaries still require buffers, persistence, IDs, deduplication, replay and monitoring.
What are the most important IIoT RFP attachments?
The boundary diagram, interface inventory, interoperability matrix, data contract and FAT/SAT test cases make supplier claims comparable.
Are both FAT and SAT necessary?
They serve different purposes. FAT repeatedly verifies the proposed combination and failure cases in a controlled supplier environment. SAT verifies site-dependent power, cabling, network, radio, time sources, certificates and upper-system integration. Set the scope of each according to the project risk; do not assume one automatically substitutes for the other.
Summary: turn a standard number into comparable evidence
TIS 30162-2568 is an identical reprint of ISO/IEC 30162:2022 and a general standard covering protocol interaction, distributed-data interoperability, connectivity framework, transport, network and guidance. Use it to expose missing decisions—not as a shortcut to claim certification.
Map conversion boundaries; fix versions, profiles, models, identity, time, units, quality, security and lifecycle; then test the proposed OPC UA, MQTT, LoRaWAN or WoT building blocks as a combination. FAT/SAT should inject unsupported versions, bad values, clock skew, outages, replay, certificate failure, updates and export. Preserve configuration, payloads, logs and reconciliation as the evidence that procurement can actually accept.
If you want to map the six TIS 30162 areas to your interface list and turn them into comparable RFP and acceptance evidence, contact TOMAS TECH while the architecture and vendor shortlist are still open.
Research sources
- 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 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: https://opcconnect.opcfoundation.org/2026/06/cloud-corner-june-2026/
- OPC Foundation, OPC UA Part 14 PubSub: https://profiles.opcfoundation.org/document/15
- W3C, WoT 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
Sources were checked in September 2026. This is general technical and procurement information, not legal, regulatory or certification advice. Confirm the requirements applicable to the product, contract and site.
