A pilot plant control system runs a scaled-down version of a chemical or industrial process so engineers can prove it, optimize it and gather the data needed to design the production plant. It does the same jobs as a production control system, regulating loops, sequencing steps, alarming and interlocking, but it is built for flexibility and data: setpoints, recipes and even equipment change from run to run, and every run must be logged in enough detail to support scale-up.
This article is part of our guide to industrial process control. Here we cover how pilot plant control differs from production control, a typical architecture, how much data to log, safety, and how to design a pilot system whose work carries into the production plant.
Pilot plant software typically combines data acquisition, control loops and data logging, and is often written in LabVIEW on NI hardware.
What a pilot plant control system has to do
- Regulate the process: temperature, pressure, flow, level and feed loops on reactors, columns, dryers or furnaces.
- Run sequences and recipes: start-up, charging, heat-up, reaction, hold, cool-down and shutdown, with parameters engineers can edit between runs.
- Protect people and equipment: interlocks and trips that act independently of the control software.
- Capture data: every process value, setpoint, alarm and operator action, time-stamped and tied to a run or batch ID.
- Support experiments: design-of-experiment runs, step tests, analyzer and sample integration, and fast changes without reprogramming.
Pilot plant vs production plant control
The two share the same physics and hazards but have opposite priorities. The pilot plant exists to learn; the production plant exists to repeat.
| Pilot plant | Production plant | |
|---|---|---|
| Main goal | Develop, prove and scale up the process | Make specified product at rate, every time |
| Recipes and setpoints | Changed often by engineers | Locked and change-controlled |
| Equipment | Reconfigured between campaigns | Fixed for years |
| Instrumentation | Extra sensors, analyzers and sample points | Only what is needed to control and protect |
| Data | High-rate logging of everything; data is a key output | Historian, batch records and KPIs |
| Operators | Engineers and technicians, often on short campaigns | Trained shift operators, 24/7 |
| Typical platform | PC-based real-time or PLC with flexible supervisory software | DCS or PLC/SCADA |
A typical pilot plant control architecture
Most successful pilot plant systems separate the layers by what each must guarantee:
- Safety layer. Hard-wired trips or a safety PLC for high temperature, high pressure, loss of cooling and emergency stop. It works even if the control computer is off.
- Control layer. A real-time controller or PLC runs the PID loops and fast interlocks at a fixed rate, independent of the operator PC.
- Supervisory layer. The operator application: P&ID-style screens, recipe editor, sequence execution, alarms and live trends.
- Data layer. High-rate logging, run and batch records, exports for process engineers and links to lab or analyzer data.
The control layer is often PC-based real-time hardware, such as NI CompactRIO programmed in LabVIEW for process control, because it handles analyzers, custom algorithms and high-speed data well. A PLC is a good choice where the process is fixed and the plant’s maintenance team already supports one. Our DCS vs PLC vs SCADA article compares the options.
Designing for flexibility without losing control
- Recipes as data, not code. Engineers change setpoints, ramp rates and hold times in a recipe editor with permissions and a change log, not by editing the program.
- Configurable sequences. Build sequences from tested phases (charge, heat, hold, cool) that can be reordered, following the ISA-88 model described in batch control systems.
- Consistent tag names. Use ISA-5.1 style tags (TIC-101, FV-203) that match the P&ID, so data, screens and documents agree.
- Simulation mode. Run sequences against simulated I/O to check a new recipe before charging real material.
- Spare I/O and expansion. Leave 20–30% spare channels and room in the cabinet; pilot plants always grow.
How much data should a pilot plant log?
Log everything at a modest rate, and log fast signals only when they matter. The arithmetic shows why.
Worked example: pilot plant data volume
Slow channels. 200 process values logged once a second as 8-byte values: 200 × 1 × 8 = 1,600 bytes per second. Over a day that is 1,600 × 86,400 = 138 MB; over a 30-day campaign about 4.1 GB. That is easy to store and query.
Fast channels. 20 pressure or vibration signals at 1 kHz as 4-byte values: 20 × 1,000 × 4 = 80,000 bytes per second, or 6.9 GB per day. Logged continuously, they dwarf everything else.
The fix. Keep a short rolling buffer of fast data and save it around events, such as a trip, an alarm or a step test, plus a 1-second summary (minimum, maximum and mean) the rest of the time.
For more on trending, alarms and historians, see real-time process monitoring.
Safety in pilot plants
A pilot plant carries the same chemical hazards as production, often with less experience of the process. Good practice:
- Run a hazard review, such as a HAZOP, on the pilot design and repeat it when the process or equipment changes.
- Keep trips and interlocks independent of the control and supervisory software.
- Define a safe state for every failure: loss of power, loss of communication, sensor failure.
- Control who can change recipes, limits and interlock bypasses, and log every change.
- Test interlocks before each campaign, not only at commissioning.
Designing the pilot system for scale-up
The control platform often changes between pilot and production, but much of the engineering can carry over:
- The loop structure, including which cascades and feedforwards proved necessary.
- Tuning data and step-test results, which predict how the larger plant will respond.
- Sequences and recipes, written as ISA-88 phases.
- Alarm limits and philosophy, refined during pilot runs.
- The data model and tag names, so pilot and production data can be compared directly.
Common pilot plant control mistakes
- Building it like a production system, so every recipe change needs a programmer.
- Building it like a lab setup, with no independent safety layer and poor documentation.
- Running PID loops on the operator PC, where a frozen screen can stop control.
- Logging fast data continuously and filling disks, or logging too slowly to see what happened.
- No run IDs, so data cannot be matched to operating conditions afterwards.
Planning a pilot plant control system?
Sciotex has built pilot plant control and data systems, including SCADA for an ethylene oxide pilot plant on NI real-time hardware, designed, programmed and supported in the US since 1997.
Frequently asked questions
A pilot plant is a small-scale version of a process plant, between laboratory and full production, used to prove a process, optimize conditions and collect the data needed to design the production plant.
Pilot plants usually need flexibility and high-rate data more than a production plant does, so a PC-based real-time system or a PLC with flexible supervisory software is common. Large DCS platforms are used when the pilot plant is part of a site that already runs one.
Pilot plant control is built to change: recipes, setpoints and equipment change between runs and data is a key output. Production control is built to repeat a fixed process reliably with formal change control.
Yes. Pilot plants handle the same chemicals and hazards as production plants, so trips for high temperature, high pressure and loss of cooling should be independent of the control software.
The hardware rarely is, but the loop structure, tuning data, sequences, alarm limits and data model can carry into the production design and shorten its commissioning.
