SCADA Selection for Thailand Factories: RFP, FAT/SAT and TCO

SCADA is the supervisory control and data acquisition foundation used to collect and monitor plant or infrastructure data and to support authorized supervisory actions. A modernization project fails when it is reduced to “replace the old screens.” Tag meaning, alarms, history, controller communications, MES integration, backup and OT security are the real system. This guide gives factories in Thailand a practical framework for SCADA requirements, RFPs, FAT/SAT, a 90-day assessment, transparent TCO and decision gates.

A new 2026 reference point for SCADA selection

On 24 February 2026, the International Society of Automation announced ANSI/ISA-112.00.01-2025, SCADA Systems – Part 1: SCADA Lifecycle, Diagrams and Terminology. ISA describes Part 1 as a vendor-neutral, technology-independent framework for both new systems and brownfield modernization, covering lifecycle concepts, diagrams and terminology.

Its status matters. ISA calls it an ANSI-approved American National Standard. The announcement says the framework can be applied across industries and locations, but it does not call ISA-112 an IEC standard or a legally mandatory global standard. Do not transfer the international status of ISA-95/IEC 62264 to ISA-112. At the time of the announcement, additional ISA-112 parts on lifecycle review processes and architecture were planned. Part 1 alone is therefore not a product certification or a detailed cybersecurity compliance claim.

The practical value is still substantial. It encourages owners to manage SCADA through design, build, operation, maintenance, expansion and audit, rather than as a one-off visualization project. An RFP can ask who owns each lifecycle deliverable and what evidence permits the project to cross its next gate. Vendors can be compared on recoverability, maintainability, interoperability and supportability—not only on demo appearance.

Decide the operating model before comparing products

Answer these questions before making a shortlist:

Does the scope cover one line, one plant or multiple sites?
Which functions cannot stop, and what outage windows are genuinely available?
Which PLCs, DCSs, RTUs, instruments, networks and time sources must remain?
Which decisions depend on alarms, events, trends and batch records?
What data is exchanged with MES, ERP, quality, maintenance and energy systems, and who owns it?
After a fault, cyber incident, vendor exit or OS end-of-support, how much recovery must the owner perform without the original integrator?

If these answers are unclear, a feature-rich product is not automatically the right product. SCADA selection is the choice of an operating model that continuously supplies defined information and authorized control without putting the physical process at unacceptable risk.

What is SCADA? Boundaries with HMI, PLC and MES

SCADA stands for Supervisory Control and Data Acquisition. It collects data from controllers and remote devices, visualizes status, manages alarms and history, and supports permitted supervisory operations. Product boundaries vary: one suite may include HMI, historian, reporting, redundancy and gateway functions, while another solution combines separate products. Define responsibility, not labels.

Component	Primary responsibility	Boundary question during modernization
Sensors and actuators	Sense physical values and act on equipment	Who owns calibration, fault values and fail-safe behavior?
PLC, DCS and RTU	Real-time control, interlocks and sequences	Can safe and stable control continue if SCADA communications fail?
HMI	Local or process-specific operator interaction	Which command source has priority?
SCADA	Multi-equipment supervision, collection, alarms and supervisory action	Who governs tags, access, time, history and communication quality?
Historian	Store, compress and retrieve time-series data	Which raw values, aggregates, quality flags and retention periods are required?
MES/MOM	Production dispatch, execution, WIP, quality and labor workflows	How does equipment data gain production context?
ERP	Orders, planning, inventory, costing and procurement	Which information crosses the boundary without creating direct control dependency?

ISA-95 organizes enterprise-control integration by activities and interfaces. A product may provide functions across several levels, so arguing about the “level” of a brand is less useful than defining data ownership, decision authority, acceptable latency and change rights. For a deeper division of work, see our MES implementation guide for factories in Thailand.

Do not make SCADA a substitute for PLC control

SCADA servers and networks can fail. Safety interlocks, high-speed loops and equipment protection should not be moved into screen scripts merely because a platform can execute logic. Locate control according to the process hazard and equipment requirements, then test the state retained by local control when SCADA is unavailable.

Nor should SCADA quietly become the master for MES transactions. A screen may display orders or quality status, but lot identity, consumption, approvals and rework need an explicit system of record. “The platform can do it” is not a responsibility model.

Start brownfield SCADA modernization with discovery

In a running factory, the installed system often differs from the latest drawing. Maintenance may have added logic, tags marked as retired may still be active, a driver may exist only on one old PC, and clocks may disagree. Observe and inventory before connecting a new SCADA platform.

CISA’s 2025 joint guidance treats OT asset inventory as a cybersecurity foundation. For modernization, maintain at least the following with evidence and an accountable owner:

Asset ID, location, process, owning department and operator
Manufacturer, model, firmware, OS and support status
Network zone, IP, peers, protocols, ports and direction of data flow
PLC/RTU addresses, OPC connections, proprietary drivers and serial converters
Tag classifications: active, unused, calculated, alarming, historical or writable
Users, service accounts, certificates and remote maintenance paths
Backup location, capture date, restore procedure and last verified restore
Time source, time zone, synchronization status and disconnected behavior
Dependencies on production, quality, maintenance, energy and reporting
Spares, licenses, support agreements and vendor-specific engineering tools

Do not rely on a self-declared spreadsheet. Reconcile configuration, controller programs, network evidence, cabinets and maintenance records. Equally, do not apply unplanned active scanning to running OT. Use vendor constraints, approved windows, test environments and risk assessment; begin with passive observation and configuration exports where appropriate.

Preserve a recoverable baseline

Save more than screenshots. Preserve the SCADA project, controller communication settings, tag database, alarm configuration, scripts, recipes, reports, users and roles, certificates, historian schema, installers, licenses, OS image and restore runbook. A backup file is not proof of recovery. Restore in an isolated environment and verify startup, login, communications and historical retrieval.

When legacy protocols and serial equipment require staged connectivity, our industrial IoT gateway selection guide for Thailand explains why buffering, timestamps, quality, certificates, updates and failure behavior matter as much as protocol conversion.

Write SCADA requirements and RFPs as scenarios

Words such as “user-friendly,” “high performance,” “secure” and “scalable” allow every supplier to answer yes. Convert them into scenarios containing an initial state, actor, action, expected result, time, quality, evidence and failure behavior.

For example, “monitor communication loss” can become:

When communications to an operating PLC are interrupted, affected tag quality becomes bad and one representative alarm is generated after the approved delay. The display must not present a stale value as healthy and must show the last good acquisition time. After recovery, reconnection follows the approved sequence and the alarm, audit record and missing-data interval remain traceable. PLC control continues in its defined safe state. FAT uses a simulator; SAT uses the real controller in an approved window.

Requirement domain	What to specify	Acceptance evidence
Function	Displays, commands, alarms, trends, reports, language	Approved scenario demonstration and operation record
Performance	Tag update, display response, concurrent users, history query	Measurements under an agreed load
Availability	Redundancy, switchover, buffering, resynchronization, degraded mode	Node, communication and power-failure tests
Integration	PLC, OPC UA, historian, MES and APIs	Data contract and abnormal/retry tests
Security	Identity, roles, certificates, logs, updates, remote access	Configuration export, logs and restore test
Migration	Parallel run, tag conversion, history movement and rollback	Rehearsal result and reconciliation sheet
Operations	Monitoring, backup, change, support and service levels	Runbooks, training and named-owner approval
Lifecycle	Versions, end-of-support, spares, licenses and exit	Roadmap, data return and decommission procedure

Prioritize requirements as Must, Should and Could, but never let a supplier’s self-score close a Must. Every Must needs a test method and evidence.

Make the tag model a core SCADA deliverable

SCADA Selection for Thailand Factories: RFP, FAT/SAT and TCO - figure 1

Drawing screens first and connecting tags later concentrates semantic defects just before commissioning. The tag model is the information contract between controllers, SCADA, historian, MES and analytics. Govern it as a versioned deliverable independent of displays.

Each tag should have a stable ID, display names, description, data type, engineering unit, range, source, controller address, update method, expected interval, quality, source timestamp, calculation, write permission, alarm reference, history policy, owner and change history. Avoid encoding every meaning in a long name; use searchable hierarchy and attributes for site, area, line, equipment and function.

Value, time and quality belong together. A temperature of 80 is unusable when the unit, freshness and timestamp origin are unknown. If the last value remains visible during a communication loss, show bad quality and last-good time. Where possible, preserve quality and source time in the historian as well as the value.

Separate stable IDs from multilingual labels

Thai factories may use Thai, English and Japanese. Translating internal IDs makes mappings fragile. Keep language-neutral IDs stable and manage display names and explanations as localized resources. Approve a glossary for units, abbreviations, equipment names and alarm wording.

For changes, show which displays, alarms, history, MES interfaces and reports are affected by a tag addition, deletion, type change, scaling change or write-permission change. Record the release and rollback point before production deployment.

Specify OPC UA correctly for SCADA integration

OPC UA is a platform-independent standard for information exchange from devices through MES and enterprise applications. OPC Foundation Part 1 describes information, message, communication and conformance models, as well as Client/Server, PubSub, current data, history, alarms and events. Yet a one-line requirement saying “supports OPC UA” proves neither interoperability nor secure deployment.

Specify client/server roles, required profiles, transport and encoding, endpoints, SecurityPolicy, MessageSecurityMode, user authentication, application certificates, trust lists, revocation and renewal, namespaces, information models, sampling, queues, deadband, history, alarms, redundancy and audit. Test the real combination of different vendors for connect, reconnect, certificate exchange, expiry, rejection, load, data types, quality and source timestamps.

OPC UA Part 2 covers concepts such as application identity, certificates, SecureChannel, authentication, authorization and auditing. Having these mechanisms is not the same as operating them safely. Routine unencrypted endpoints, trust-all clients, shared administrators, expired certificates, clock drift and missing revocation procedures can defeat the design.

Essential OPC UA failure tests

Reject an untrusted client certificate and record the event
Recover with an approved reconnection process after certificate renewal
Handle duplicate, missing or reordered data after a communication interruption as designed
Rebuild subscriptions and monitored items after server restart
Safely process a wrong type, out-of-range value, bad quality and stale timestamp
Prevent a read-only user from writing or calling a restricted method
Demonstrate that high information load does not create an unacceptable control impact

Do not treat alarms and the historian as add-ons

An alarm is not every condition that becomes true. It indicates an abnormal condition requiring operator response. Separate alarms from events, diagnostics, maintenance notifications and quality deviations so that important conditions are not buried in noise.

The ISA-18 series treats alarm management as a lifecycle: philosophy, identification, rationalization, design, implementation, operation, maintenance, monitoring, change and audit. Before bulk-importing legacy alarms, document cause, consequence, operator response, available response time, priority, setting, delay and suppression condition. Remove expected shutdown alarms, cascades from a common cause and chattering inputs.

The historian also needs an information policy. Define raw versus aggregate values, periodic versus exception collection, deadband, quality, source time, compression, retention, archive, query performance and applicable customer or regulatory needs. High-speed troubleshooting data and monthly KPI aggregates do not require identical retention.

Test time as shared infrastructure

Clock disagreement among PLC, SCADA, historian, MES, domain and gateway can reverse apparent cause and effect. Define UTC storage, local display, cross-site daylight-saving handling, NTP/PTP, loss of time source, step versus gradual correction, and the relationship between source and server-receive timestamps. Inject controlled drift in FAT and verify the real source and monitoring in SAT.

Design SCADA security with availability and safety

NIST SP 800-82 Rev.3 provides OT security guidance that explicitly considers performance, reliability and safety. For SCADA, avoid both blindly applying IT controls that interrupt the physical process and leaving systems exposed in the name of availability. Identify assets, communications, threats, impacts and recovery capability, then make controls testable.

In January 2026, NIST started the Rev.4 revision process. Its page is an Initial Preliminary Draft/Pre-Draft call for input, not final guidance. Proposed areas include AI, digital twins, cloud, 5G, zero trust and changes in the OT threat landscape. Do not claim “Rev.4 compliance” in an RFP; instead define how the project will review relevant changes when the revision matures.

Ask for OT security evidence in the RFP

CISA’s joint Secure by Demand guidance helps OT buyers request evidence of secure defaults, vulnerability handling, logging, updates and supplier lifecycle performance. It is procurement guidance, not a CISA certification of a product.

Ask for evidence covering:

Individual identity, role-based access, separation of privileged actions and controlled emergency access
Secure baseline, disabled unnecessary services and configuration-drift review
Network zones, permitted flows, management paths, jump access and approved remote support
Application signing, certificates, secrets storage and renewal
Security and operator audit logs, synchronized time and log-forwarding failure behavior
Vulnerability notice, impact assessment, fixes, mitigations and support dates
Pre-update testing, rollback and compatibility with controllers and drivers
Offline-verifiable backup, restoration and alternative operation
Return of configurations, data, licenses and administrative control at vendor exit

“Antivirus installed” or “a firewall exists” is not sufficient. Confirm who monitors alerts, whether updates affect dormant equipment, how isolation affects safe operation, and whether the owner possesses the keys, media and permissions required for recovery.

Separate SCADA FAT, SAT and operational proving

FAT verifies design and implementation in a supplier or controlled environment before site deployment. SAT verifies the installed solution with real equipment, network, power, time, users and environmental constraints. Neither replaces the other.

FAT should combine simulators and representative hardware, then test normal and failed communications, invalid values, stale time, alarm bursts, server loss, redundancy switchover, storage pressure, backup restoration and access violation. Record expected result, actual result, logs, screenshots, defect and retest.

SAT verifies construction, cabinets, real I/O, local HMI, time sources, authentication, redundant paths, UPS and operating procedures. Physical tests require hazard review, permits, witnesses, stop conditions and recovery instructions. If a fault cannot safely be injected, approve substitute evidence and the residual risk.

Cut over only while rollback remains possible

Define rollback conditions as carefully as cutover conditions. Plan the parallel period, dual collection, command-authority transfer, history migration, accepted defects, Go/No-Go authority, communications, spares, supplier coverage and recovery time. Retain the legacy system until an agreed stable-operation period has produced evidence.

SAT approval is not the end. During operational proving across shifts, monitor alarm load, support requests, communication quality, missing historian data, backup success, resource utilization, redundancy, and report timestamps. Handover only when trained operations, maintenance and IT/OT staff can execute the runbooks.

Build a SCADA decision package in 90 days

SCADA Selection for Thailand Factories: RFP, FAT/SAT and TCO - figure 2

A 90-day assessment does not promise production deployment in 90 days. It is an example for bringing the baseline, requirements, alternatives, risk, cost inputs and PoC scope to a decision-ready level. Adjust it to shutdown and procurement constraints.

Days 1–30: baseline and critical scenarios

Inventory equipment, assets, network, SCADA configuration, interfaces and users
Preserve backups and verify restoration for a representative configuration
Assess safety, production, quality, environmental and customer impacts
Interview operations, maintenance, engineering, IT, quality, management and procurement
Approve the highest-priority operating and failure scenarios
Record current problems as business impact plus evidence, not brand frustration

Deliver a current-state diagram, asset and interface inventory, issue log, scenarios, outage constraints and draft responsibilities.

Days 31–60: comparable requirements and options

Draft tag model, alarm philosophy, history policy and time policy
Develop target architecture and staged migration options
Create RFP requirements with priority, test and required evidence
Give shortlisted suppliers the same questionnaire and demo scenarios
Build input sheets for licensing, infrastructure, migration, training, support and retirement
Assess OT security, support life, lock-in and operating capability

Use your failure scenarios in every demo, including communication loss, bad quality, certificate expiry, alarm burst, history query and unauthorized action.

Days 61–90: evidence and decision

Run a focused PoC with representative controller, OPC UA, historian and MES connections
Test recovery, reconnect, missing data, time, authorization and logging failures
Draft FAT/SAT, migration rehearsal and rollback criteria
Document TCO sources, uncertainty and sensitivity
Record residual risks, assumptions, exclusions and contract conditions
Compare Go, conditional Go, hold and life-extension options

The outcome is a decision package: scope, evidence, cost model, risk, open items, staged plan, named owners and the next gate—not merely a product recommendation.

Compare SCADA TCO with transparent inputs

Software price alone is not comparable because licensing units vary by tag, client, server, redundancy, historian, engineering tool, driver, user and support. Migration, validation, outage, training, certificates, backups, future change and retirement also matter.

Use this as an input template, not a market benchmark:

Evaluation-period TCO = acquisition + design/integration/migration + infrastructure + security implementation + training/start-up + support and licenses + planned change + expected outage exposure + retirement/exit − agreed residual value

For outage exposure, use the owner’s own scenarios: probability, duration, contribution loss or incremental cost, scrap and recovery. If probability is unreliable, compare low/base/high cases and record each source and approver.

Illustrative calculation only

The following fictional units demonstrate arithmetic; they are not Thai market prices or typical SCADA values.

Candidate A inputs: acquisition 100, migration 80, infrastructure 30, security 20, training 15, support 60, change 30, outage exposure 40, exit 10, residual value 5
TCO: 100 + 80 + 30 + 20 + 15 + 60 + 30 + 40 + 10 - 5 = 380 fictional units

Show uncertainty as well as total. If migration dominates, test tag conversion and display reuse in the PoC. If outage dominates, invest in parallel operation and rollback rather than hiding the risk in a contingency percentage.

Use SCADA acceptance gates that can stop the project

SCADA Selection for Thailand Factories: RFP, FAT/SAT and TCO - figure 3

A useful gate is not a calendar meeting. It can stop work when evidence is missing. Define approvers, deliverables, pass criteria, exception process and the budget released by each gate.

Scope baseline: approved assets, outage constraints, scenarios and responsibility boundaries.
Architecture fit: consistent PLC/SCADA/MES/ERP, network, time and system-of-record design.
Security evidence: assets, access, certificates, updates, logs, remote support and recovery.
FAT: Must requirements pass under normal and failure conditions; critical defects are closed.
SAT: safe success with site equipment, network and users, with viable rollback.
Operational readiness: runbooks, training, monitoring, backups, contacts, spares and support are active.
Lifecycle ownership: change, audit, end-of-support, expansion and exit have owners and funding.

Do not let a low price compensate for missing mandatory evidence. If an exception is accepted, record residual risk, deadline, interim control and accountable owner.

Common SCADA implementation failures

Counting screens as progress

Finished screens do not prove tag quality, alarms, access or recovery. Measure the percentage of approved scenarios that pass with required evidence.

Cloning the legacy system

Bulk migration also clones unused tags, nuisance alarms, shared IDs, old protocols and unmaintainable scripts. Separate valuable operating knowledge from technical debt.

Assuming OPC UA means automatic interoperability

Connection is not semantic agreement. Specify profiles, models, certificates, types, quality and time; test different vendors together.

Adding security just before SAT

Identity, zones, certificates, logs and update design affect architecture and effort. Include them from the start and test failures in FAT.

Treating go-live as the success criterion

A working display immediately after cutover does not prove sustainable recovery and operation. Use an operational proving period and verify restores, alarm load, time, missing data, support and change control.

Frequently asked questions about SCADA

What is SCADA?

SCADA collects industrial data, supervises equipment status, alarms and history, and supports authorized supervisory actions. Its responsibility differs from PLC/DCS real-time and safety control, MES production operations and ERP business processes. Define boundaries by system of record, authority, latency and failure behavior.

What is OT, and how does it relate to SCADA?

Operational technology includes programmable systems and devices that interact with the physical environment. SCADA, PLC, DCS and RTU are common examples. OT decisions must combine cybersecurity with safety, availability, real-time needs, long asset life and limited shutdown windows.

Does OPC UA eliminate vendor lock-in?

It can improve interoperability but does not automatically remove lock-in. Specify and test profiles, information models, namespaces, types, certificate operations, history, alarms and redundancy. Contract exit conditions for scripts, historian data, drivers, backups and licenses.

What is the first SCADA security action?

Establish assets, communications, accounts, remote paths, backups and support status, then identify critical operating scenarios and impacts. Design zones, least privilege, secure configuration, logging, update and recovery around that evidence.

How should SCADA costs be compared?

Compare acquisition, design, integration, migration, infrastructure, security, training, support, change, outage exposure and exit over the same period. Use owner inputs and uncertainty, not an assumed market average, and validate dominant assumptions in a PoC.

What is the difference between FAT and SAT?

FAT tests design and implementation in a controlled environment before site deployment. SAT tests real equipment, network, power, time and users. Allocate communication failure, invalid values, access violations, failover and restore tests appropriately across both.

Is ANSI/ISA-112.00.01-2025 an international standard?

ISA’s 24 February 2026 announcement identifies it as an ANSI-approved American National Standard. It provides a vendor-neutral, technology-independent framework with broad applicability across industries and locations, but the announcement does not describe it as an IEC or universally mandatory global standard. Assess regulatory and contractual applicability for each project.

Conclusion: select SCADA through lifecycle evidence

SCADA modernization succeeds when the plant can continuously operate meaningful data, actionable alarms, auditable commands and recoverable configurations without compromising local control. ANSI/ISA-112.00.01-2025 is a useful new lifecycle reference point, but its status must not be overstated. Combine it for the right purposes with ISA-95, ISA-18, NIST SP 800-82, OPC UA and procurement-oriented security guidance.

Inventory the brownfield system, translate critical scenarios into the RFP, and test the tag model, alarms, historian, OPC UA and security under one acceptance strategy. Use the 90-day assessment to build a decision package, expose TCO inputs and uncertainty, and require evidence at FAT, SAT, operational readiness and lifecycle ownership gates.

If your Thailand factory is still at the discovery or RFP stage, TOMAS TECH can help define the boundary between existing PLC/HMI assets, SCADA, MES, OPC UA and phased migration. You can contact TOMAS TECH before selecting a product.