APY PREMIUM GROUPAPY's first large-scale project was not inside a single factory. It was spread across more than 40 sites nationwide — a SCADA and machine monitoring system for Thailand's Rice Department, with Charoen Pokphand Engineering (CPE) as main contractor and APY responsible for the control and monitoring system. This article explains how a multi-site rollout differs from a single-plant project, how we designed for it, and what to prepare before starting one. Commercial details and client-specific data are intentionally withheld.
Project at a glance
| Item | Detail |
|---|---|
| End client | Rice Department (Thailand) |
| Main contractor | Charoen Pokphand Engineering Co., Ltd. (CPE) |
| Year | 2020 — APY's first large-scale project |
| Scope | SCADA and machine monitoring across 40+ sites nationwide |
| Platform | AVEVA Wonderware (AVEVA Edge) with Mitsubishi PLCs |
| APY's role | System design, SCADA application development, testing and on-site commissioning |
The problem: monitoring assets that sit in different provinces
In a single plant, if a screen misbehaves an engineer walks over and looks at it within five minutes. Once the work is spread across dozens of sites, every assumption changes — travel becomes a major cost line, a small fix can consume two days, and inconsistency between sites becomes the real enemy.
What makes multi-site work hard is not SCADA technology. It is reproducing the same quality at every location, within a fixed schedule and budget.
Single plant vs. dozens of sites
| Aspect | Single plant | Dozens of sites |
|---|---|---|
| Screen design | Tailored on site, adjusted as you go | Must be a standard template deployed repeatedly, or maintenance becomes impossible |
| Tag naming | Flexible | A strict naming convention from site one, or cross-site reporting can't be built |
| Network | Stable internal LAN | Upcountry links are unreliable — the design must survive disconnection |
| Troubleshooting | Walk over and look | Requires remote access and readable logs, or travel cost eats the margin |
| Handover | Tested once | Requires a standard commissioning checklist reused at every site |
| Training | One team | Dozens of teams with very different skill levels — the system must be usable with minimal training |
How we designed it
1. Build templates first, then scale
The main reason for working on AVEVA Wonderware (AVEVA Edge) was how quickly a reference project can be built once and reused. We created a single library of standard symbols and equipment screens, then cloned the reference project to the remaining sites, changing only the tag list and site-specific parameters. When something has to change later, you change the reference and roll it out — instead of editing forty screens by hand. That single decision separates a system you can maintain from one that becomes a liability.
2. Lock naming and data structure from site one
Every data point follows the same pattern (site / area / equipment / signal), so data can later be compared across sites without writing translation logic. Projects that skip this step usually end up rebuilding when the client asks for a consolidated report.
3. Design each site to keep running when the link drops
Local systems must continue to operate when the connection to the central server is lost, and must backfill buffered data once connectivity returns. Ignoring this is the most common reason multi-site reports end up full of gaps.
4. Make commissioning identical everywhere
The same test checklist, the same handover forms, the same required site photos. Different crews at different sites then deliver comparable quality, and if an issue surfaces later there is evidence of the as-delivered condition.
A 10-point checklist before starting a multi-site SCADA project
- Site list and grouping — which sites are genuinely identical, and which are exceptions?
- Survey 2–3 representative sites — pick the largest and the oldest; that's where problems live.
- Nameplate photos of PLCs and equipment at every site — brand, model, firmware, available communication ports.
- Define the data points you actually need — tag count multiplies both licence cost and engineering hours.
- Naming standard — agreed and frozen before the first site starts.
- Network path per site — who owns it, who opens the ports, what the security policy is.
- Remote access rights — agreed with IT at the start, not when the system is already down.
- Ownership of data and the central server — on-premise or cloud, and the backup policy.
- Training and documentation plan — dozens of teams need short documents they can use immediately.
- Future expansion — say it up front so the design allows for it without paying for it now.
What we carried forward from this project
This project became the foundation of how APY works. Standard templates, systematic naming and a repeatable handover pack were carried into later work — projects within the CP group, multi-site solar farm monitoring, and industrial Power Monitoring systems.
If your organisation is considering something similar — multiple buildings, branches or provinces — the deciding factor isn't which software brand you pick. It's whether the design makes site number 40 as easy to install as site number 1. See our SCADA & HMI and PLC control systems pages for details.
Summary
A multi-site SCADA project is not a single-plant project multiplied by forty. It is a different kind of work that must be designed for repeatability from the first line. Teams that establish templates, naming standards and a handover pack early get faster with every site. Teams that improvise get slower — and the difference becomes obvious from about site ten onwards.