For a Thai manufacturer planning OPC UA cloud integration, getting a signal into a dashboard is only the beginning. The harder questions are whether an assembly event retains its meaning across systems, whether a missing record can be explained, and whether another supplier can maintain the solution later. In September 2026, the OPC Foundation released its open-source Cloud Initiative Reference Solution. It is a useful common test bench for an edge-to-cloud pilot. It is not a certified, production-ready system for a particular plant. This guide turns the reference implementation into a focused procurement and 90-day acceptance plan.
What the OPC Foundation released in 2026
The Foundation describes the Cloud Initiative Reference Solution as a working implementation of concepts in its Cloud Reference Architecture. The public repository includes K3s manifests named edge.yaml and cloud.yaml, a simulated production line, setup instructions, tutorials, a security analysis, and production-hardening recommendations. Its architecture combines open standards and open-source components so that individual parts can be examined and, in principle, replaced. A buyer still has to validate the chosen versions, factory network, equipment, availability, security, support, and data governance before production deployment.
The example brings several tasks into one observable flow. UA Edge Translator brings in industrial assets, including a documented example of a simulated Modbus TCP device described with a W3C Web of Things Thing Description. UA Cloud Publisher moves OPC UA PubSub JSON data and metadata through messaging infrastructure. The example adds a broker, time-series storage, and dashboards. UA Cloud Library addresses information-model management; UA Cloud Commander illustrates a request-and-response command path. These are components to evaluate against a use case, not a shopping list that every factory must deploy.
How this differs from field-level OPC UA FX and from a data fabric
Our guide to OPC UA FX and TSN implementation in Thailand concerns field-level communication, timing, and control. The present article concerns the higher-level path from equipment data and its semantics to edge and cloud applications. Do not treat an MQTT telemetry path as a substitute for a deterministic control or safety loop. Keep those responsibilities with the established PLC and safety design, and begin the cloud evaluation with read-only data.
Our manufacturing data-fabric guide addresses discovery, governance, and integration across systems. Here the narrower problem is obtaining trustworthy, meaningful equipment data to feed such a platform. The two discussions concern different layers of the architecture.
Define the first use case before selecting software
A plant may have equipment from several generations, corporate IT standards, and local maintenance contracts. These circumstances vary by site and are not a statistical claim about Thailand. Bring production, maintenance, quality, IT, security, and procurement together to answer one question: what evidence would justify expanding the investment after 90 days? If the pilot simply adds more connected machines, it may leave little data that supports a decision.
Choose one initial use case: assembly-line downtime and output; inspection results linked to lots; or packaging-machine state and changeover time. For traceability, a temperature chart alone is insufficient. Define which workpiece or lot passed which station, when, and under which recipe. Agree on equipment, process, product and lot identifiers, timestamps, event boundaries, and owners. Leave live equipment write commands out of the first scope unless a separate safety and authorization assessment expressly includes them.
Connected tags are not an acceptance criterion
Even a large tag list has little value if units, measurement points, update rates, time sources, invalid values, and gaps are ambiguous. For each signal, document the asset and process, data type, engineering unit, sampling rule, timestamp source, normal range, quality code, retention, and accountable department. “Temperature” could mean setpoint, measured process temperature, or ambient temperature. Verify the mapping with the process owner.
OPC UA information models and relevant Companion Specifications can help preserve semantics. Check whether an applicable model exists and record any local naming rules when it does not. Model adoption by itself is not the outcome. The acceptance test is whether a user can interpret a value correctly and whether a software change or machine replacement leaves a traceable model version.
Review five architecture boundaries
Equipment to edge. For a device with an OPC UA server, review the endpoint, namespace, certificate, and least-privilege read account. For an older device, verify the actual southbound protocol, source value, error behaviour, and supplier warranty. The reference repository demonstrates a simulated Modbus TCP device; that demonstration does not guarantee automatic connection to every legacy PLC or proprietary device. Require a test on the target machine.
Normalization within the edge. Map values to asset hierarchy, units, state, timestamp, and quality. Distinguish raw from calculated values; version the formulas. Keep configuration and change history as deliverables, rather than leaving the only mapping on an engineer’s laptop. Have the factory approve the meaning of each critical event.
Messaging. The UA Cloud Publisher repository describes a reference implementation using OPC UA PubSub over MQTT or Kafka; the Cloud Initiative example uses MQTT. Test disconnection, reconnection, duplicates, ordering, latency, and consistency between data and metadata. A successful publish call does not prove that a business record is complete. Specify where failures appear, who receives an alert, and how recovery is evidenced.
Storage and applications. The example includes a broker, storage, and dashboards; the production choice must fit the plant’s MES, quality system, data platform, and operational rules. Set retention, backup, access, data classification, and restoration requirements. Separate analytical extracts from records needed for audit. If data crosses borders or goes to headquarters, review the company’s policies and contracts before enabling transfer.
Cloud-to-floor actions. UA Cloud Commander illustrates requests to read, write, call methods, or retrieve history from on-premises OPC UA servers. The technical route does not authorize remote control. Safety independence, local confirmation, separation of duties, access control, audit logs, loss-of-network behaviour, and emergency procedures need separate review. For an initial pilot, use read-only operation on real assets and test writes on simulation equipment only.
A practical 90-day procurement and acceptance sequence
Days 0–15: Establish scope and contract evidence
Select one line, a small number of critical machines, and one user department. Two or three machines can be a manageable illustration, not a universal standard. Inventory PLC, SCADA and MES interfaces, tags, time synchronization, maintenance windows, and the network path. Ask bidders for evidence on the actual models, not merely a long protocol compatibility list. Document the network segments, destinations, certificate issuer and renewal owner, and support boundaries.
Expected outputs are a machine-by-machine connection matrix, first data dictionary, test topology, and a list of security and operational responsibilities. The repository’s simulated line can help a team explore data flow without taking down production. Its quick-start timing describes that demo environment; it is not a promise about security approval, patching, factory installation, or staff training.
Days 16–35: Build a small, read-only connection
Get maintenance and equipment-maker approval before connecting to live controls. Apply minimal read privileges. Where translation is needed, record source and normalized values together. Compare an event such as cycle start or completion across the PLC interface, edge log, and downstream record on one time axis. Simulate a communications outage and show that the control process stays independent and that the missing interval is visible after recovery.
Deliver a reproducible tag-to-record mapping, test steps, and log location, not just screenshots. A pipeline diagnostics dashboard can show transport health while the actual business value remains wrong. Investigate mismatches by checking unit conversion, rounding, sampling, timestamps, stale PLC values, and transformation rules.
Days 36–60: Validate meaning and business events
Translate signals into the event definitions people use. Downtime may require distinct records for stop, restart, assigned reason, and operator correction. Inspection traceability may need workpiece ID, lot, inspector station, recipe revision, decision, and retest relation. Ask production or quality users whether those meanings match their MES fields and work instructions. A well-structured information model is useful only if the data leads to a valid business interpretation.
Include abnormal cases in test data: missing values, duplicates, clock drift, machine exchange, tag renaming, restarts, and network loss. Verify that a planned-stop zero is distinguishable from “no value because communication failed.” These are proposed test cases; set numeric pass thresholds from the line’s measured baseline and risk. The key is the ability to detect, explain, and correct an anomaly, not a single attractive average-latency figure.
Days 61–90: Operate, recover, and sign off
Observe the solution through ordinary shifts. Have a substitute operator renew a certificate, replace and restore an edge device, recover stored data, and follow a documented escalation. Test model and tag changes from request through impact assessment, staging, and rollback. Identify first responders and supplier contacts for Thailand’s working hours and holidays; provide Thai-language operating material if the local team needs it.
At acceptance, demonstrate how a quality user traces one lot, a maintenance user reconciles downtime events and signals, and IT investigates a gap or failed backup. The proof should be detailed enough for factory and IT owners to sign. Connection counts and dashboard counts do not show that the system supports a decision.
Put testable requirements in the RFQ and acceptance sheet
| Area | Evidence requested at procurement | Example acceptance check |
|---|---|---|
| Connectivity | Target model, version, protocol, read method | Normal, fault and restart records from a real machine |
| Meaning | Data dictionary, units, timestamps, model version | Trace a source value through transformation and display |
| Delivery | Broker settings, replay and gap policy | Outage and recovery logs; duplicate handling |
| Security | Certificates, roles, network boundaries | Revocation, renewal and access audit |
| Operations | Monitoring, backup, patch plan, contacts | Device replacement and restore exercise |
| Portability | Configuration, model and data handover | Reproduce deployment in another test environment |
| Cost | Hardware, engineering, communication, cloud, support | Annual cost assumptions and change conditions |
Open-source code does not remove engineering, installation, monitoring, security, training, or support costs. Confirm the licenses of the selected component versions during procurement. Compare total cost against the actual equipment, downtime exposure, and internal versus external support responsibilities; do not assume a universal price per tag. Define what must be portable: dictionary, model references, configuration, certificate procedures, export format, dashboard definitions, and incident records. Verify migration in a test environment. Open interfaces reduce one kind of dependency but do not make change free.
Avoid acceptance phrases such as “real time” or “99.9%” without a measurement definition. Specify the event population, gap definition, allowed delay, clock synchronization, retention, and whether planned maintenance is excluded. Choose thresholds from the process risk and measured baseline, not a supplier brochure. Keep source logs alongside summaries so unexplained gaps cannot be counted as success.
Security, availability, and the limits of a reference implementation
The public repository discusses GDS Server Push for certificate provisioning, TLS configuration, a STRIDE threat assessment, and production-hardening recommendations. They are valuable design inputs, not a certification of a buyer’s deployment. Review demo defaults, exposed web interfaces, credentials, image updates, and network paths before production use. Document allowed communication directions and destinations; do not expose the equipment network for convenience.
Treat read, historical read, write, and method call as different risk classes. A command route should require a separate safety approval. Audit the request and result, use least privilege and, where necessary, dual authorization. Confirm that a cloud or network failure cannot stop the independent local control and safety system.
Test the edge computer, plant network, broker, storage, and dashboard separately. A replacement gateway is not a recovery plan if its configuration cannot be restored promptly. A dashboard outage should not stop production control. Test backup restoration in an isolated environment and record the evidence.
Allocate responsibility between the Thai plant and headquarters
The factory should own permission to connect to equipment, the meaning of signals, operating procedures, and shutdown decisions. IT should own endpoint and network management, identity, logs, and backups. Data users should define events and quality needs. The integrator and equipment maker should state which versions and behaviours they support. Assign named owners for the dictionary, certificates, first response, model changes, and substitutes during leave. If field training must be in Thai, include that time in the plan.
Separate factory and site acceptance tests
In the factory acceptance test (FAT), use simulated equipment and an isolated network to test the data path and reproducibility of the configuration. Do not only watch a supplier-prepared dashboard. Inject buyer-specified normal, duplicate, clock-shifted, and missing-value events. Trace the same event identifier from the simulated PLC through edge, broker, storage and display. Require a quality code or gap record for data that does not arrive; it must not disappear silently. Restore the configuration on another device and repeat the tests. Record software versions, input, expected and observed results, unresolved items, and the owner and date of each retest.
The site acceptance test (SAT) repeats the scenarios on the target line and actual network. Where production cannot stop, observe real events in read-only mode and schedule an approved maintenance window for disconnection tests. After a device restart, check that one workpiece is not counted twice. Ask quality to trace a lot from screen back to source, maintenance to distinguish a real stop from a communications gap, and IT to demonstrate certificate revocation, rejection of a removed user, and recovery from storage failure. Define when the machine maker and integrator will attend before testing starts.
Passing FAT does not imply passing SAT. Factory clock settings, wireless links, switches and operator actions may differ from the lab. If SAT fails, use logs to locate the change among equipment signal, network, timestamp, transformation and storage rather than assuming the software is the only cause. For every conditional acceptance item, record business impact, temporary workaround, permanent correction, and retest date so that open defects do not disappear during handover.
Keep an evidence register rather than relying on a meeting slide. Link each test case to source logs, screen records, configuration, measurement conditions, and the person and date of review. Even a “not reproduced” result is hard to assess later without the test duration, input, and equipment state. Mark what was tested on simulation, what was tested on a real machine, and what could not be tested because a network outage required a maintenance window. An untested item is not a pass; carry its owner and test date forward. This register helps compare supplier proposals on the same basis and reuse tests on the next line.
Deciding whether to expand after the pilot
A successful first line does not mean the configuration is portable without testing. Even machines of the same brand may differ in PLC revision, tag naming, network path, and operating practice. Split the delivered design into common rules—asset hierarchy, time, quality codes, logging, certificates and monitoring—and line-specific mappings, thresholds, safety constraints, and support contacts. Otherwise a pilot exception can silently become a template.
Ask three questions before adding lines. Did a user change a real decision using the data? Can the team detect and repair missing or misleading records during operation? Can different staff and suppliers restore and update the deployment? If any answer is no, fix the design before increasing connection counts. Ask bidders to show real-machine evidence of tag permissions, certificate renewal, restart gaps, model-change notifications, data export, and first-response arrangements.
Frequently asked questions
What does OPC UA cloud integration cost?
There is no universal price. It depends on equipment protocol, machine count, existing network, gateway, data volume, communications, monitoring, support, and security review. The reference code can help examine license assumptions but does not make engineering and operations free. Estimate capital and annual costs for one defined use case.
Can a legacy machine without OPC UA be connected?
Sometimes. The reference solution includes translation examples and a simulated Modbus TCP tutorial. Actual feasibility depends on the machine’s interface, supplier warranty, maintenance contract, and safety limits. Include source-to-normalized-value comparison in acceptance.
Can the cloud operate the PLC?
The UA Cloud Commander repository illustrates a command path. That is not permission to operate a production PLC remotely. Keep the first pilot read-only and use simulation for write tests. Any live write requires separate equipment-safety, access, audit, and failure-mode approval.
Is the reference solution a certified production product?
The Foundation presents it as an open-source reference solution. Do not assume certification or fitness for a particular plant. Review its security and hardening guidance, then test the versions and architecture you actually intend to support.
Can an entire factory be rolled out in 90 days?
This 90-day plan is a proposal for producing evidence on a narrow scope, not a rollout guarantee. Decide the next scope and budget after validating meaning, gaps, security and support on the first line.
Conclusion
The OPC Foundation’s new reference solution makes the edge-to-cloud chain visible: industrial connection, OPC UA information models, PubSub delivery, storage, dashboards, and optional command patterns. A Thai factory can use it to make procurement more specific. Select one use case, define evidence for data meaning and gaps, test security and recovery, and have plant and IT owners accept the same measurable result. Treat the public implementation as a starting point for evaluation and engineering, with production fitness to be proven for the chosen site.
If your team is defining an OPC UA cloud integration pilot or a 90-day acceptance scope for a Thai factory, contact TOMAS TECH to discuss the equipment, data and operating conditions at an early stage.
