A SCADA system can look complete on a computer screen and still fail to deliver reliable information on the factory floor. Production values may be incorrect, alarms may not appear when equipment develops a fault, and reports may show figures that do not match actual output. These problems often surface during commissioning, when the new system must work with real equipment, existing PLCs, industrial networks and daily production activities.
The main reason SCADA integration projects struggle at this stage is that individual components may work correctly on their own, yet the connections between them have not been fully verified. Experienced SCADA integrators address this risk by testing the complete path from field signals and PLC logic to operator screens, alarms, historical records and reports. Manufacturers can prevent many delays by agreeing on measurable acceptance criteria early, testing realistic operating conditions and keeping clear records of every outstanding issue.
The commissioning gap: Why a working SCADA screen is not enough
Commissioning is the stage when engineers verify that the installed control and monitoring system performs as required in its actual operating environment. It involves more than launching the SCADA application and confirming that equipment names appear on screen. The team must establish that the system receives the correct values, presents the right status, responds to expected events and records information accurately.
Consider a manufacturer installing SCADA software to monitor a mixing process. The operator can see the tank temperature, mixer status and batch progress, but the displayed temperature comes from the wrong PLC tag. The screen appears normal, yet the operator is making decisions from incorrect information. A similar problem can occur when an alarm displays correctly during a basic test but fails to activate at the required process limit.
The difference between a completed installation and a verified system lies in evidence. The project team needs test records showing that the expected behaviour matches the actual result, including faults and abnormal operating conditions. The international standard IEC 62381:2024 describes structured factory acceptance testing, site acceptance testing and site integration testing for process automation projects, with defined test scopes and responsibilities.
Where SCADA integration problems usually begin
PLC communication works, but the data is not reliable
SCADA depends on dependable communication with PLCs, remote input and output devices, instruments and other connected systems. A communication link may appear active while individual values update slowly, drop out intermittently or arrive in a format the SCADA application does not interpret correctly. Differences in network settings, communication drivers, device configuration and data types can all create problems during commissioning.
A useful test goes beyond checking the connection status. The engineer should compare selected SCADA values against the source PLC data, confirm that updates occur at the required rate and verify how the application responds when communication is interrupted. The test should also establish that the display clearly identifies stale or unavailable data rather than presenting an old reading as a current measurement.
Tag mapping and engineering units do not match
A tag is an identifier used to refer to a process value, equipment status or control point. During industrial SCADA integration, the PLC and SCADA application must agree on which tag represents each measurement and how that value should be interpreted. A mismatch can cause a temperature to appear under the wrong equipment name, a production counter to show an incorrect total or an analogue signal to display the wrong engineering units.
For example, a PLC may store a value in one format while the SCADA screen expects another. The displayed figure might look plausible, making the error difficult to spot during a quick inspection. The commissioning team should therefore compare tag names, data types, scaling, units, status indications and expected value ranges against the approved control documentation.
Alarms do not reflect the actual process condition
An alarm is useful only when it identifies a condition that requires an operator’s attention. Incorrect trigger limits, unsuitable alarm priorities, missing PLC status signals or incomplete configuration can cause alarms to appear too late, appear unnecessarily or fail to activate. Operators may then lose confidence in the system and revert to manual checks.
Testing should cover normal conditions, alarm thresholds, recovery after a fault and the expected operator response. The team should verify the displayed message, priority, timestamp and acknowledgement behaviour, along with any required reset conditions. Tests involving actual equipment must follow the site’s approved safety procedures, particularly when a fault could affect people, product quality or machinery.
Historical records and production reports contain errors
A SCADA screen can display live values correctly while its historical records remain unreliable. Incorrect timestamps, inconsistent units, missing samples, unexpected counter resets or poor historian configuration can distort production reports. The issue may not become apparent until a supervisor compares shift output, batch records or downtime figures with the values recorded by the SCADA system.
The integrator should verify how data moves from the PLC into the historian or reporting database, then compare stored records with known events and independent production records. The test should cover the required sampling interval, timestamp source, data gaps, counter behaviour and report calculations. Manufacturers should also confirm that the reporting period matches their operational requirements, including shift boundaries and batch completion times.
A commissioning test should prove the entire process, not just the software
A reliable SCADA system depends on several connected layers. A field instrument measures a process condition, the PLC processes the signal, the communication network carries the data, the SCADA application displays it and the historian may store it for reporting. A failure at any point can affect the information seen by operators.
The commissioning team should trace selected signals through this complete path. For a temperature measurement, for example, the team would check the instrument reading, corresponding PLC value, SCADA display, alarm response at the approved limit and historical record. This method helps identify the exact point where an incorrect value, delayed update or missing event enters the system.
The same process applies to operator commands. When a user starts a permitted operation from an HMI or SCADA screen, the test should verify that the command reaches the intended control logic, that required interlocks remain effective and that the screen shows the actual equipment response. A command appearing on the screen is not proof that the equipment received or completed it.
FAT, SAT and site integration testing have different jobs
Factory acceptance testing and site acceptance testing are often discussed together, but they prove different parts of the project. Manufacturers should agree on the purpose, test conditions, responsibilities and acceptance criteria for each stage before commissioning work begins. IEC 62381:2024 provides a framework for these test stages and site integration testing in process automation projects.
Test stage | What it should verify | Evidence the buyer should receive |
Factory acceptance test (FAT) | The configured system meets the agreed requirements in the factory or an appropriate test environment | Completed test cases, recorded results, defects and outstanding items |
Site acceptance test (SAT) | The installed equipment and software operate correctly with the site infrastructure and available field devices | Site test records, communication checks, field verification results and defect status |
Site integration test (SIT) | Connected systems and subsystems work together as specified | Interface test results, integrated operating scenarios and agreed completion records |
A factory test can identify configuration errors before the equipment reaches the plant, reducing the number of issues that must be resolved during a production shutdown. However, a successful FAT cannot prove every aspect of site performance because the final installation, field wiring, network conditions and connected equipment may not yet be available. Site testing must address those conditions directly, along with any additional checks required by the project.
Manufacturers should also confirm how loop checks, safety validation and process specific testing will be completed. These activities have distinct requirements and should not be assumed to be covered by a general SCADA test. A written test plan helps the buyer see what has been verified, what remains outstanding and which party is responsible for each item.
How to validate production data before go live
Data validation deserves its own review because incorrect values can pass a visual inspection. An operator may see a number on screen and assume that it represents the actual process, particularly when the number falls within a plausible range. The project team must verify the value against an independent reference and confirm that it behaves correctly across the required operating range.
A practical validation exercise should select representative measurements, such as temperature, pressure, tank level, motor status or batch count. For each point, compare the source measurement with the PLC value and SCADA display, then check the historical record where applicable. The test should include normal operation and planned test conditions that expose scaling errors, communication loss and incorrect state changes.
Use a simple record like this during testing:
Data point | Verification | Acceptance evidence |
Temperature or pressure | Compare the instrument, PLC and SCADA readings | Values agree within the approved tolerance |
Tank level | Check scaling, engineering units and operating range | Display matches the verified level signal |
Equipment status | Test the agreed running, stopped and fault states | Screen reflects the actual status |
Production counter | Compare PLC count with verified production events | Total and reset behaviour meet the specification |
Historical trend | Compare recorded values and timestamps with known events | Required values and event times are recorded correctly |
The project specification should define acceptable tolerances and update rates rather than leaving the commissioning team to decide them during testing. Some measurements require tighter accuracy than others, and the correct limits depend on the instrument, process and intended use. Any failure should be documented, corrected and retested before the affected function is accepted.
Prevent delays by settling responsibilities before commissioning
Commissioning delays do not always come from a software defect. Work can stall when the plant has not confirmed its shutdown window, the necessary personnel are unavailable, network access has not been approved or another contractor still needs to complete wiring. Missing PLC documentation and late changes to process requirements can create further rework.
Before the commissioning date, the manufacturer and integrator should confirm that the following arrangements are in place:
- The approved functional specification, tag list, alarm list and relevant drawings are available.
- PLCs, instruments, network connections, servers and operator workstations are ready for the planned tests.
- Required access, software licences, backups and approved remote or local connections are available.
- Production, maintenance, electrical and automation personnel know their responsibilities and availability.
- Test procedures, acceptance criteria, issue tracking and escalation contacts have been agreed.
- The plant has approved the operating conditions and safety controls required for testing.
PRO TIP: Ask the SCADA integrator to issue a readiness review before the production shutdown begins. Each outstanding requirement should have an owner and a planned completion date. This gives the plant time to resolve missing access, drawings, network configuration or equipment readiness before those issues consume the commissioning window.
What should a manufacturer receive at handover?
A successful go live is not the end of the project. The maintenance team needs enough information to diagnose faults, manage future changes and maintain the SCADA system after the commissioning engineers leave. A system that works on the first day but has poor documentation can become difficult to support as equipment, operators and production requirements change.
The handover package should reflect the scope agreed in the contract. It will normally include the final system configuration, approved PLC and SCADA backups, updated tag and alarm lists, network and interface details, test records, known limitations and a register of outstanding work. The manufacturer should also receive operating instructions, maintenance information, user access guidance and training relevant to the system delivered.
Training should include more than navigating the screens. Operators need to know how to interpret status indicators, respond to alarms and report abnormal behaviour. Maintenance personnel should know how to find relevant diagnostic information, restore approved backups and escalate faults that require specialist support. Changes to control logic, alarm settings or communication configuration must follow the plant’s established authorization and change control process.
A practical commissioning readiness review for buyers
Before approving go live, ask the project team to demonstrate the system against the agreed requirements. A checklist is useful, but the important part is the evidence behind each answer. A box marked complete is not enough when a critical process value, alarm or control command has not been tested under the relevant conditions.
Use the following review with your integrator and plant team.
Review question | Evidence to request |
Are all required PLC tags mapped correctly? | Approved tag list and recorded comparison tests |
Have communication failures been tested? | Test results showing detection, recovery and display behaviour |
Have critical alarms been verified? | Alarm test records and approved trigger conditions |
Are production reports accurate? | Comparison against validated source data and known production events |
Have the required operating scenarios been tested? | Completed FAT, SAT and integration test records, as applicable |
Are outstanding defects recorded? | Issue register with owners, priorities and agreed resolution dates |
Is the plant ready to operate the system? | Handover documents, trained personnel and an agreed support process |
Not every open item has the same level of risk. A minor display formatting issue may be suitable for a documented follow up, while an incorrect process measurement or failed critical alarm may prevent safe or reliable operation. The manufacturer and integrator should agree on which defects block acceptance and should not approve production use until critical requirements have been met.
What to do when a newly installed SCADA system does not work as expected
When problems appear after installation, resist the urge to make several unrecorded changes at once. Start by capturing the time of the event, the affected equipment, the displayed value or alarm, and any related PLC or communication diagnostics. Compare the current behaviour with the approved test records and identify which layer first shows an unexpected result.
The plant should follow its approved operating and fault response procedures while the technical team investigates. Do not bypass safety interlocks, force PLC signals or change control logic simply to make a screen appear normal. Such changes can mask the underlying fault and create additional risk for operators and equipment.
Next, record each problem in the project issue register and assign it to the responsible party. Ask the integrator to state the likely cause, corrective action, retest method and evidence required for closure. When the defect is corrected, repeat the relevant test under controlled conditions and update the documentation before the issue is marked complete.
How ControlSoft approaches control system verification
ControlSoft Canada’s published project work illustrates the value of joining process requirements, PLC programming, SCADA development, testing and operator handover within a defined engineering scope. In an Ontario colour and chemical processing project, the team documented the proposed process control requirements, prepared electrical and control drawings, developed PLC and SCADA programming, and carried out testing using FAT and SAT documentation. The project also included site commissioning, go live support, and training manuals for operators and maintenance personnel.
This project involved replacing a long serving manual batching and mixing setup with a PLC based control system. Its relevance to SCADA commissioning is the disciplined connection between documented requirements, control logic, testing and the people who will operate and maintain the system. Those steps help establish what the system should do before the team verifies that it does so at the plant.
For manufacturers planning a new installation, a modernization project or an upgrade to an existing control environment, SCADA integration services should include a clear explanation of test scope, acceptance criteria, site readiness and handover. ControlSoft Canada provides PLC, HMI, SCADA and industrial automation engineering services for manufacturing and industrial facilities. A discussion with the engineering team can help define the system interfaces, required tests and support arrangements for a specific project.
Frequently asked questions
Why do SCADA integration projects fail during commissioning?
SCADA integration projects commonly encounter problems when communication settings, PLC tag mapping, alarm configuration, historical data or site interfaces have not been fully verified. Gaps in requirements, incomplete testing and unclear responsibilities can also delay acceptance. A documented test plan with measurable acceptance criteria helps identify these issues before production use.
What should SCADA testing include?
SCADA testing should cover the functions defined in the project specification, including communication with PLCs, tag values, equipment status, operator commands, alarms, trends, historical records, reports and user permissions as applicable. The scope should also address expected behaviour during communication loss and recovery. Test results, defects and retest evidence should be recorded.
What is the difference between FAT and SAT?
A factory acceptance test checks the configured system against the agreed requirements before delivery or site installation. A site acceptance test verifies the installed system under the site conditions and interfaces relevant to the project. Site integration testing checks that connected systems work together as specified. The precise test scope should be agreed by the buyer and integrator in advance.
How can a manufacturer verify that SCADA production data is accurate?
Compare representative SCADA values with the corresponding PLC values and a verified source measurement or production record. Check scaling, engineering units, timestamps, counter behaviour and missing data. The project specification should state the acceptable tolerances and required update rates for each measurement.
What documentation should SCADA integrators provide at handover?
The agreed handover package should include current system configuration and backups, tag and alarm information, relevant drawings, interface details, test records, operating instructions and a list of outstanding items. Operator and maintenance training should also cover system operation, basic diagnosis and the process for requesting controlled changes. The required documents should be stated in the project scope.
What should a plant manager do when the new SCADA system does not work correctly?
Follow the plant’s approved operating procedures, capture the event details and identify the affected equipment or data points. Record the problem, ask the responsible engineer to diagnose it and agree on a controlled retest. Do not bypass interlocks or make unapproved control changes to hide the fault.
Can commissioning problems be prevented completely?
No commissioning plan can guarantee that every issue will be identified before startup, particularly when the site includes legacy equipment or interfaces with limited documentation. However, clear specifications, early readiness reviews, realistic tests and documented defect closure can reduce avoidable delays. The remaining risk should be managed through an agreed acceptance process and a defined support arrangement.
Reliable commissioning starts before the system reaches the plant
A SCADA project should not be judged by how polished the operator screens look or how quickly the software launches. Its value depends on the accuracy of the information, the reliability of communication, the response to alarms and commands, and the quality of the records used by production and maintenance teams. These functions need to be tested against agreed requirements and proven under the operating conditions that matter to the plant.
For manufacturers working with SCADA integrators, the best protection against costly delays is a clear plan that connects requirements, testing, site readiness and handover. Ask for evidence, keep a record of unresolved issues and define the conditions for accepting the system before commissioning begins. These practices give the project team a clearer route to go live and help the plant maintain confidence in the control system after installation is complete.
