Manufacturing IoT Challenges: A 90-Day PoC and RFP Playbook for Thailand

When people research manufacturing IoT challenges, the discussion often starts with sensors, communication protocols, and cloud platforms. In a factory IoT programme in Thailand, however, the transition to live operations is more likely to stall when three questions remain unanswered: who makes which decision, how the factory recovers after a failure, and who takes ownership on site. This article sets out a practical, end-to-end approach for existing equipment, covering a 90-day PoC, RFP requirements, FAT and SAT, OT security, recovery, and the exit criteria for a production-scale rollout.

For a view of what implementation can look like after approval, see our smart factory case study for manufacturing in Thailand. If you are comparing connectivity hardware, read our guide to selecting an industrial IoT gateway for a factory in Thailand. This article serves a different purpose: it focuses on how to decide pass or fail before deployment and what must be true before operational responsibility can be handed over locally.

Manufacturing IoT challenges are more often about decisions than connections

When a PoC dashboard begins displaying live values, the project can appear to have made a major leap forward. Yet if no one has defined who will use those values to change which operational decision, more screens will not change the way the factory is run. A successful connectivity test and a system that can be used reliably in daily operations are two different outcomes.

This distinction is especially important in a plant dominated by legacy equipment. Machine builders, maintenance, production, quality, IT, OT, procurement, regional or global headquarters, and local vendors all have different priorities. The machine builder protects the equipment warranty, production avoids downtime, quality needs traceability, and IT requires identity and network controls. If procurement compares proposals only on price and delivery, responsibility boundaries and recoverability can easily fall outside the contract.

The first question, therefore, is not “Which device should we buy?” It is: “Which decision must be made, using which data, by whom, and by when?” Without an answer, neither the PoC acceptance decision nor the RFP evaluation can be defined.

Failure mode 1: The operational decision has not been defined

“We want visibility” and “We want to collect data” describe means, not outcomes. Even when the target is downtime data, the requirements differ depending on whether the factory wants to reduce daily-report preparation, shorten the initial response to an equipment issue, or change the priority of loss-reduction work. Each objective calls for a different level of detail, latency, retention period, and notification path.

Define the operational decision at least to the following level:

• Decision owner: who makes the final decision
• Decision subject: what is stopped, repaired, changed, or approved
• Decision timing: real time, end of shift, daily, or weekly
• Input data: which machine signals and human inputs are used
• Exception handling: what evidence is used when data is missing or the link is down
• Record: where the decision and supporting evidence are retained

Putting these six points on a one-page use-case sheet turns a generic dashboard request into an operational requirement that can be accepted and tested.

Failure mode 2: Data ownership and tag semantics are unclear

The same label—“running,” for example—can mean a PLC run bit, motor current, a product-passage sensor, or an operator’s production entry. A signal may be on while no good product is flowing because the line is waiting for a changeover or material. Converting a tag name directly into a business KPI can therefore produce a result that conflicts with what operators know happened.

The tag dictionary should record the tag name, meaning, unit, data type, normal range, update condition, machine timestamp, quality flag, transformation formula, and the owner responsible when the equipment changes. It must also identify who approves the definition. The system integrator should not decide the operational meaning alone; agreement among production, maintenance, and quality should be retained as acceptance evidence.

Failure mode 3: Time bases and denominators do not align

In factory data utilization, event order matters. When machine time, gateway time, server receipt time, and operator-entry time are mixed, teams can misread the sequence between a failure and the recovery action. Time zone, synchronization method, treatment of unsynchronized devices, and display rules for sites that observe daylight saving time all belong in the design.

The denominator behind each KPI also has to be fixed. Does “number of stops” include minor stops? Does planned production time exclude breaks and planned maintenance when calculating availability? Is the denominator for defect rate input quantity or completed quantity? KPIs with different denominators cannot support a sound management decision, even when they carry the same label.

Failure mode 4: The network is assumed to be continuously available

If the cloud or headquarters link is lost, the equipment must remain safe and either continue production or move to a safe stop under approved conditions. A design in which loss of remote visibility unintentionally affects machine control should be avoided. The edge layer needs an appropriate buffer, together with defined behaviour for collection during disconnection, replay after reconnection, duplicate handling, and event ordering.

“Tolerates a network outage” is not an acceptance criterion. A test case must specify which connection will be interrupted, which known data will be generated, and what will be reconciled after recovery. The team should also confirm that local manual operations remain viable during the outage and that a large replay backlog does not overwhelm normal traffic when the connection returns.

Failure mode 5: Change and recovery sit outside the project scope

After go-live, an IoT system will be affected by machine modification, PLC programme changes, new product variants, certificate renewal, operating-system updates, and network changes. Accepting only the initial connection does not show that the system can continue to operate after those changes alter the data definition or configuration.

NIST’s OT security guidance explains that performance, reliability, and safety must be taken into account in OT. Its OT Backup Quick Start Guide also prioritizes linking backups to change management, creating and testing them regularly, and reviewing them during recovery exercises. The existence of a backup file does not prove recoverability. It becomes an operational asset only when the restore sequence, required privileges, storage location, and post-restore reconciliation have also been verified.

An IoT small start begins with responsibility across four layers

If an IoT small start is interpreted simply as “connect one machine,” the scope may be small while the responsibility gaps remain. Start small in coverage, not in the set of design concerns. Even in a PoC, separate the physical signal, edge acquisition, transport and security, and business application layers, then assign an owner and acceptance evidence to each.

Physical-signal layer: Confirm meaning without disrupting the machine

For a legacy equipment IoT retrofit, an unused communication port does not by itself mean that a connection is safe or supported. Check the machine builder’s warranty conditions, PLC load, scan-cycle impact, possible conflict with the existing HMI, and effects on the control network. Even when the principle is read-only access, verify that write access is prevented by configuration and permissions rather than by policy alone.

Signal reconciliation should not stop at a desktop review of the tag list. On site, create or observe actual states such as running, stopped, faulted, and changeover, then witness whether the displayed state matches. If a state cannot safely be created, use historical logs or maintenance procedures as alternative evidence and retain the item as unverified. Do not count it as passed; manage it as an open requirement before scale-out.

Edge-acquisition layer: Expose missing data as a quality condition

The gateway does more than forward values. It is a boundary between machine protocols and upstream systems. The design should specify polling intervals, change-of-value transmission, heartbeat monitoring, local buffering, replay, duplicate identifiers, timestamp assignment, and quality codes.

Most importantly, do not replace a missing value with zero. The application then cannot tell whether zero is a valid process value or no value was collected. Pass the source timestamp, receipt timestamp, quality state, and data source along with the value so that plant users can judge whether a chart is reliable enough for the intended decision.

Transport and security layer: Manage each connection path as an asset

Remote maintenance is useful, but the factory must define who may connect, from which endpoint, for what purpose, during which period, and to what scope. Instead of a permanent shared account, combine individual identification, approval, time limits, activity records, and a shutdown procedure.

CISA’s Cross-Sector Cybersecurity Performance Goals are a voluntary baseline for IT and OT owners that prioritizes high-impact practices across Govern, Identify, Protect, Detect, Respond, and Recover. An RFP should therefore ask not only whether a product contains a security function, but also who owns asset identification, detection, response, and recovery as ongoing operations.

NIST SP 1800-45 addresses OT remote access in the water and wastewater sector and should not be presented as a manufacturing standard. It does, however, provide multiple reference designs using commercially available technologies. Manufacturers can cautiously use the architectural lesson: secure remote access should not be reduced to a single VPN feature, but should combine identity, boundaries, monitoring, and operating procedures.

Business-application layer: Accept an action, not merely a screen

An alarm appearing on a screen does not complete the process. Define the recipient, first responder, escalation condition, response deadline, system of record, and substitute when the primary person does not respond. Dashboard acceptance should test not only colours and values, but whether the responsible person can make a decision, record it, and hand it to the next role.

Factories in Thailand may operate in Thai, English, and Japanese. Align alarm names, equipment names, and response SOPs, and have local users confirm that meaning is not distorted by literal translation. If headquarters defines a KPI in Japanese while the shop floor uses a different term, response can be delayed. Put the glossary and screen labels under the same change-control process.

A 90-day IoT PoC roadmap: Build exit criteria, not a success demonstration

A 90-day PoC is not a promise to guarantee a return on investment within 90 days. It is a bounded period for evaluating technology, operational value, supportability, recovery, and scalability, so that management has evidence to stop, extend, or scale. Set the exit criteria before work begins and use unmet criteria as part of the decision.

Before day 1: Agree a one-page PoC charter

The PoC charter should state the target equipment, exclusions, operational decision, owners, available downtime, available signals, network constraints, security review, deliverables, and the date and membership of the exit-gate meeting. Explicit exclusions reduce the risk of requirements expanding midway through the PoC.

The accountable PoC owner should be the customer’s operational leader, not the system supplier. The vendor owns technical implementation and preparation of evidence but should not decide whether the business outcome is accepted. Map production, maintenance, IT/OT, quality, and procurement participants and their approval authority, using RACI or a comparable method.

Days 1–15: Site survey and baseline freeze

The first phase assesses equipment, signals, networks, operations, and change constraints. Inspect wiring, panels, spare ports, power, the installation environment, and permitted equipment downtime. At the same time, record the current manual workload and decision time using definitions that can be compared after the PoC.

Do not select only the easiest machine. Include a target that represents scale-out difficulty—such as a typical older machine, a location where link instability is plausible, or equipment routinely handled by local maintenance. Keep the scope narrow, but select each asset against a risk the PoC is intended to test.

The exit criteria for this phase are that candidate signals have been approved by the equipment owner, unverified points are listed, and both the safe connection method and rollback method have been approved.

Days 16–35: Four-layer design and RFP alignment

Design the tag dictionary, data flow, network boundaries, accounts, certificates, buffering, timestamps, notifications, and KPI formulas. Even if a supplier has already been chosen, documenting the requirements in RFP form helps reveal scope additions and missing responsibilities.

Draft FAT and SAT test cases during this phase, before the build is complete. If testing is postponed until the end, the design may include behaviour that cannot be verified. For example, testing certificate revocation requires both the product and the operating model to support detection, communication refusal, and a controlled recovery process.

Exit when the owner, interface, exception handling, and test evidence for each of the four layers have been agreed, and every material open issue has a deadline and named owner.

Days 36–60: Build, FAT, and abnormal-condition testing

FAT should verify functions and abnormal conditions as far as possible before the solution enters the factory. In addition to normal data display, test input boundaries, missing tags, clock drift, connection loss, buffer limits, replay, duplicates, failed authentication, certificate expiry conditions, log generation, and backup creation.

When production equipment is not available, use a simulator but clearly separate simulated evidence from conditions not yet verified on the actual machine. FAT approval is not a substitute for SAT. Factory-specific networks, electrical noise, downtime limits, and operator actions still require on-site verification.

Exit when critical defects are resolved, residual issues have been formally accepted, and the site installation, rollback, and SAT plans are complete.

Days 61–80: On-site SAT and an operational trial

SAT uses the real equipment, real network, and real users. Verify signal meaning, collection interval, displays, and notifications, but also test—where safely possible—network loss, power loss, gateway restart, upstream application outage, incorrect credentials, a certificate approaching expiry, and backup restoration. Any test with production or safety impact must follow a pre-approved method that gives priority to safe operations and the production plan.

Local personnel should do more than read the manual. Run a drill in which they receive an alert, investigate the cause, escalate, and record the response. If support from outside Thailand is required, test the time-zone overlap, contact hours, language support, and alternative emergency contacts as part of the operating process.

Exit when SAT evidence, training records, unresolved issues, on-call ownership, escalation contacts, backup locations, and the configuration-change method are ready for handover.

Days 81–90: Stop, extend, or scale at the exit gate

The final phase is a decision meeting, not a showcase. Evaluate business KPIs together with data quality, operating workload, security, recoverability, and repeatability on other equipment. Use the remaining time to establish why criteria were not met and what decision follows, rather than to add more visually impressive screens.

“The PoC worked” is not enough for a scale decision. Repeatability means that the next machine can be surveyed using the same method, tag definitions can be approved, devices can be replaced, certificates can be renewed, and operations can recover after a failure.

What to include in an RFP for manufacturing IoT

An RFP is not merely a feature list. It is the document through which the buyer and proposer share the same definition of completion. Responses such as “supported” or “standard feature” do not show the required configuration, licence, custom development, or on-site work. For every requirement, specify the expected answer format, owner, assumptions, exclusions, and acceptance evidence.

Business and data requirements

• Identify the operational decision and users in scope
• For every KPI, specify the formula, denominator, data source, source timestamp, update frequency, and quality flag
• Define the approval process for adding, modifying, and retiring tags
• Define how missing, abnormal, duplicate, and late data are displayed and aggregated
• Name the owner of multilingual labels and the terminology glossary
• State the scope in which data and configuration can be exported through CSV, APIs, or other means

Availability and offline requirements

• Show how loss of the upstream link is prevented from affecting equipment control
• State what is buffered, the capacity, behaviour at the limit, and monitoring method
• Define replay order, duplicate identification, and bandwidth control after reconnection
• Provide the gateway replacement and configuration restoration procedure
• Define quality indication and correction policy when time synchronization fails
• Define the conditions for entering and leaving manual operations

OT security requirements

• Submit an asset inventory, software composition, destinations, ports, and protocols
• Describe individual accounts, role-based permissions, privileged actions, and deactivation after a transfer or departure
• Describe certificate issuance, distribution, trust lists, renewal, revocation, and expiry monitoring
• Describe request, approval, time limits, recording, and emergency shutdown for remote access
• State retention, monitoring, alerting, and timestamps for security logs
• Identify the vulnerability-notification contact and the pre-update impact assessment and rollback process
• Define communication, isolation, investigation evidence, and recovery responsibility during an incident

These requirements do not mean applying every latest update immediately to a control system. OT has to balance change with performance, reliability, and safety. Require a process in which change risk is assessed, tested, approved, and applied with a viable rollback path.

Deliverable and handover requirements

• Current architecture diagram, data flow, IP list, and communication allow-list
• Tag dictionary, KPI calculation specification, and screen and notification specifications
• Device and application configurations, versions, and licence register
• Account and certificate registers with renewal schedules
• Backup scope, creation procedure, storage location, restore procedure, and restore-test records
• FAT and SAT plans, results, issues, and approvals
• SOPs for normal operations, failure response, escalation, and rollback
• Training materials, attendance records, and contacts for local maintenance and headquarters IT/OT
• Methods for returning data, transferring configuration, and terminating access at contract end

Do not treat documentation as a snapshot that expires at delivery. Assign an update owner and authoritative storage location. Documents held only by headquarters or a vendor, and inaccessible to the local team, are not effective operational assets during an emergency.

Abnormal conditions and recovery to verify in FAT and SAT

The value of FAT and SAT lies less in confirming a normal screen than in deliberately breaking design assumptions and observing the response. Any test that could affect equipment safety or production must have its feasibility, alternative method, and rollback approved in advance.

Offline, buffering, and replay testing

MQTT QoS defines delivery semantics. It does not prove that the business application stored the message, incorporated it into a KPI, or caused the responsible person to act. Reconciliation must run end to end through sender, broker, receiver, database, and aggregation process.

Assign each test event a unique identifier, then compare the number generated, source timestamps, number received, number stored, and number included in the aggregation. If the design permits duplicate delivery, show where idempotent processing occurs. If order may change, decide whether the system uses source time and sequence or recalculates historical aggregates when late data arrives.

Behaviour at the buffer limit is equally important. Whether the system discards the oldest data, rejects new data, or retains an aggregation is an operational requirement, not a protocol default. Whichever approach is chosen, the fact and extent of loss must be exposed through monitoring and user displays.

Certificate expiry, revocation, and trust-list testing

OPC UA supports platform-independent information exchange and defines information, message, communication, and conformance models with an integrated security model. Its security model includes mechanisms for certificates and authorization. The existence of these mechanisms, however, does not show that the factory can operate the certificate lifecycle.

The certificate register should include the target device, purpose, issuer, expiry date, renewal owner, renewal procedure, downtime impact, and emergency contact. Tests should confirm that an untrusted certificate is rejected, an approaching expiry can be monitored, the trust list is correctly updated after renewal, and an old certificate can be revoked or removed once transition is complete.

If renewal requires equipment downtime, include it in the maintenance plan. If only the vendor holds the private key or renewal tool, the RFP should address continuity at contract termination, during an emergency, or when the usual vendor engineer is unavailable.

Backup and restore testing

Backup scope extends beyond server data. Gateway settings, the mapping of PLC tags, network-device configuration, certificates and trust lists, application settings, user permissions, dashboards, notification rules, the tag dictionary, KPI formulas, and SOPs depend on one another.

A restore test should assume a clean replacement environment and verify the sequence in which each item is returned. After restoration, reconcile not only connectivity but also configuration versions, tag counts, KPI results, permissions, logs, time, and notifications. If the assigned restorer cannot proceed without asking the original implementer, the documentation and handover are incomplete.

The change record should capture the target, reason, impact, approver, implementer, backup, validation, rollback, and result. Consistent with NIST’s OT backup guidance, connect backup activity to change management, test backups regularly, and review them during recovery exercises.

For factory data utilization, accept KPI definitions before KPI values

KPI targets vary by factory. Rather than importing market averages or another company’s improvement rate, use a baseline taken before the PoC and an action threshold approved by the factory. Every KPI should have an owner, formula, source, source timestamp, denominator, and decision threshold.

The following table is a user-completed template, not an industry benchmark or recommended value.

A KPI calculation specification that traces every number

The KPI calculation specification should include more than the name shown on the dashboard. Record the source tags, filters, product and shift boundaries, exclusions, rounding, recalculation conditions, and version. When a formula changes, set an effective date and determine the historical recalculation range so that values based on different definitions are not silently mixed.

If headquarters and the local factory use different cut-off times, the same calendar date can represent a different reporting period. Preserve the source timestamp and time zone in storage, then convert it for the user’s context at display time. CSV exports and API integrations should retain the time information as well.

Do not make a single ROI number the only PoC gate

Some failures occur too rarely during a short PoC to establish a reliable result, and long-term maintenance effects should not be forced into a short observation period. Assess operational value and implementation readiness separately:

• Business value: did the decision or user action change?
• Data quality: can meaning, time, missing data, and the denominator be explained?
• Technical stability: does the system behave as designed after a disconnection, replay, or restart?
• Operability: can local personnel monitor, change, and perform first-line recovery?
• Security: can the factory operate authentication, authorization, remote access, logs, and certificates?
• Scalability: can the standard procedure be reused on the next machine?

If value is visible but recovery remains incomplete, a limited extension may be more appropriate than rollout. If the technology is stable but the decision owner does not use it, the programme should stop or return to operational design.

Use OPC UA and MQTT according to purpose

Selecting a protocol name does not resolve manufacturing IoT challenges. OPC UA and MQTT are not necessarily competing choices; they may address different roles within one architecture. The decision must begin with the layer and problem each is intended to solve.

OPC UA provides models for information exchange from devices to enterprise systems and can address both information meaning and security. It is useful when equipment data structure and semantics must be carried upstream, but adopting the standard does not automatically correct an ambiguous definition at the physical signal.

MQTT is a lightweight client/server publish-subscribe transport used for M2M and IoT messaging. It can decouple publishers and subscribers, but topic design, payload meaning, authentication, authorization, storage, duplicate handling, and monitoring remain implementation and operating responsibilities. QoS alone should never be accepted as proof that data was correctly reflected in the business application.

The RFP should not compare solutions using only “supports OPC UA” and “supports MQTT” checkboxes. Require the supported version, security configuration, certificate management, connection capacity, disconnection behaviour, logs, configuration export, and interoperability tests.

Moving a legacy equipment IoT retrofit into operations in Thailand

In a factory in Thailand, it is common for headquarters to design the solution, local staff to use it, and vendors from multiple countries to support it. The operating model must account not only for technology, but also for language, time zones, employment and subcontracting arrangements, locally available spares, communication links, and approval authority.

Multilingual alarms and SOPs

Short alarm messages are particularly vulnerable to ambiguous translation. Link each alarm to a code, equipment location, state, priority, first check, and prohibited actions. If the screen is multilingual but the maintenance register uses a different name, the team cannot search consistently. Use equipment IDs and alarm codes as shared keys.

Translation acceptance should confirm not only language accuracy but alignment with the terminology used on the shop floor. Do not simply hand a procedure written at Japanese headquarters to the local team. Have Thai personnel execute it, identify unclear points, and approve the revised instruction.

Headquarters visibility and local maintenance responsibility

Headquarters being able to view every factory does not mean headquarters performs the first response. Decide locally who first receives the notification, checks site safety, touches the equipment, and calls the vendor. Headquarters may provide comparative analysis or specialist support, but it should not be assigned an action that can only be performed safely on site.

For escalation across time zones, document contact hours, holidays, substitutes, working language, and whether interpretation is needed. Do not depend only on a private chat group; maintain contact records and response history as organizational assets.

Design for an unstable link

The route from an overseas site to headquarters or the cloud has dependencies beyond the factory network. Carrier outages, maintenance, name resolution, certificates, and proxies may all affect the path. Put those dependencies on the data-flow diagram and assign monitoring points and service contacts.

Test whether minimum local display and recording remain available during an outage, whether the local team can see that headquarters has lost visibility, and in what order data returns after recovery. If the plant uses paper or a local report while cloud access is unavailable, the SOP should define the switch, reconciliation, and any re-entry of data.

Make vendor remote access time-bound

For remote support by an equipment vendor, consider enabling access only when needed and closing it after the work. Record the person, purpose, target, approver, start and end time, and activity, and make sure the factory can terminate the connection during an emergency.

Set the review frequency and revocation owner so that shared or former-employee accounts do not remain active. If a vendor’s subcontractor connects, require traceability to the actual person performing the work. At contract end, confirm the treatment of accounts, certificates, VPN configuration, and any data taken off site.

Limit personnel data to a defined purpose and scope

Linking machine data with operator IDs may support quality traceability or training, but it can also involve information relating to an individual. Where Thailand’s PDPA may apply, confirm purpose, required fields, access, retention, sharing, and deletion with the company’s legal and information-governance functions. This is not legal advice; it is a practical reminder that data originating from equipment is not automatically unrelated to personal information.

An operating model for handing over responsibility

In production operations, fault isolation crosses layers. No single company may be able to determine immediately whether a problem sits in the sensor, PLC, gateway, network, cloud, or application. Provide one intake route for users while making the investigation owner and escalation path for each layer explicit.

Routine operations

Routine checks should cover data freshness, missing data, time synchronization, buffers, storage, certificate expiry, backup results, failed jobs, and account changes. People do not need to inspect every item manually every day; automate abnormal-condition alerts and test periodically that the alerts themselves still work.

When a local user identifies an implausible value, define where the correction request is submitted, whether historical data is corrected, and whether KPIs are recalculated. Do not close a data-quality issue as an IT fault without tracing possible equipment or operational-definition changes.

Change management

Machine modifications, new product variants, PLC updates, network changes, and application updates can affect one another. Before a change, identify affected components, back up the configuration, and prepare validation and rollback. Afterward, recheck representative tags, timestamps, missing-data behaviour, notifications, KPIs, and permissions.

Do not omit the record for an emergency change. Define a deadline for retrospective approval and document updates. When the actual installation no longer matches the architecture diagram, the next incident may be diagnosed against an incorrect model.

Failure and incident response

Check safety and production impact first. If necessary, isolate the IoT path and move to manual operations. Then preserve logs on a common time base, change history, account activity, and network state. Separate the local recovery role from the investigation role so that the pressure to restore production does not erase the evidence needed to understand the event.

At first response, it may be impossible to determine whether an event is a cyberattack or a device failure. Prepare isolation, communication, backup verification, restoration, and business-continuity procedures that work for either case, and retain enough information to hand the investigation to specialists.

Monthly and quarterly review

Set the frequency according to plant risk and the volume of change, but review assets, accounts, certificates, remote access, backups, unresolved issues, and KPI usage regularly. Screens or notifications that no one uses should be candidates for removal. If the shop floor has returned to a separate report, investigate why.

After scale-out, the PoC exit criteria can be reused as standard audit items. Continue checking whether each new machine conforms to the standard, whether exceptions have been approved, and whether recovery tests are actually being performed.

An RFP evaluation matrix for manufacturing IoT challenges

Proposal comparison should examine unanswered points, assumptions, exclusions, and future changeability—not only feature count and initial cost. The following is a fill-in evaluation framework, not a recommended scoring allocation.

If most answers say “to be discussed” or “to be decided after implementation,” identify the unresolved risk before comparing price. The buyer must also provide the equipment information, permitted downtime, network policy, and approvers needed for an accurate proposal. A good RFP exposes the buyer’s own open actions as well as setting expectations for the vendor.

FAQ: Manufacturing IoT challenges and practical PoC execution

Where should an IoT PoC roadmap begin?

Before selecting hardware, put the operational decision, decision owner, input data, exception handling, and the stop, extend, or scale criteria for day 90 on one page. Then separate the design into physical signal, edge acquisition, transport and security, and business application layers, with an owner and acceptance evidence for each. Approving the exit criteria before work starts prevents the evaluation standard from moving during the PoC.

Is connecting one machine enough for an IoT small start?

Narrowing the equipment scope is useful, but normal data display alone is not enough for a rollout decision. Even for one machine, test network loss, replay, time, permissions, certificates, backups, and local operations. Selecting only an unusual machine that does not represent scale-out difficulty can also give a misleading result. Keep the target small, but do not remove essential design and verification concerns.

What should we confirm with the machine builder for a legacy equipment IoT retrofit?

Beyond the communication specification, confirm the warranty scope, read-access load, usable ports, potential scan-cycle impact, conflict with the existing HMI, allowable downtime, backups, and rollback. Reconcile signal meaning against actual machine states, and retain any tag not verified as an open item rather than treating it as passed.

How should KPIs be defined for factory data utilization?

Work backwards from the factory’s own operational decision instead of copying another company’s improvement rate. For each KPI, define the owner, formula, denominator, data source, source timestamp, quality condition, and action threshold. Take the baseline before the PoC using the same definition, and never treat missing data as zero.

What is the difference between FAT and SAT?

FAT tests functions and abnormal conditions as far as possible before the solution enters the factory. SAT tests under site conditions with the real machine, network, and users. A FAT pass based on a simulator does not replace SAT verification of equipment-specific signals, the local connection, and operational actions.

Should we choose OPC UA or MQTT?

It is not always an either-or decision. OPC UA addresses information models, exchange from devices to upstream systems, and an integrated security model. MQTT is suited to lightweight publish-subscribe message transport. Data semantics, end-to-end storage verification, authentication and authorization, operational ownership, and recovery still have to be designed separately from the protocol name.

Can IT security rules be applied directly to OT security?

Some controls are shared, but OT also has to account for performance, reliability, and safety. Evaluate the production and safety impact of updates or isolation, then combine testing, approval, and rollback. IT and OT owners should jointly design the process from asset identification through protection, detection, response, and recovery.

Is it acceptable to stop rather than scale after the PoC?

Yes. If stop criteria and safe removal are agreed before the PoC, stopping is a valid management decision rather than a hidden failure. If trustworthy signals cannot be obtained, the operational decision does not change, or a critical recovery issue remains unresolved, record the lessons and residual assets and close the PoC. Extend only when evidence is insufficient and the added scope and period can be tightly limited.

References

• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
• NIST SP 1339: Operational Technology Backup Quick Start Guide
• NIST SP 1800-45: Operational Technology Remote Access
• CISA Cross-Sector Cybersecurity Performance Goals
• OPC UA Overview and Concepts
• OPC UA Part 2 Security Model
• OASIS MQTT Version 5.0
• NIST Operational Technology Security Publications

Summary: Work backwards from exit criteria and recovery

Manufacturing IoT is not complete when machine data first appears on a screen. It becomes sustainable only when the operational decision, data meaning, timestamps and denominators, four-layer responsibility model, offline behaviour, remote access, certificates, backups, and local operations form one coherent system. A 90-day PoC should not stage a success; it should use the RFP, FAT, and SAT to test abnormal conditions and assemble the evidence required to stop, extend, or scale. Starting small is sensible, but recovery and handover cannot be treated as small concerns if the solution is to scale across factories in Thailand.

TOMAS TECH can help manufacturers in Thailand structure signal surveys, 90-day PoC exit criteria, RFP requirements, FAT and SAT, OT security, and the division of responsibility for local operations across existing equipment. You are welcome to contact us while you are still assessing options, before a device or supplier has been selected.