What Should a System Integration Acceptance Test Include?

What should be included in a system integration acceptance test? The answer goes beyond proving that individual components work. A robust acceptance test verifies that PLCs, robots, motion systems, and MES/ERP interfaces operate together against agreed requirements under realistic production conditions. It should cover end-to-end functionality, data integrity, performance, safety interlocks, fault recovery, and documented acceptance criteria.

The difficult part is deciding what counts as proof. A robot completing its programmed path does not prove that the line processes the correct order. A dashboard displaying production totals does not prove that those totals survive a network outage. Acceptance should expose these gaps before they become the plant’s responsibility.

Component tests, FAT, and site acceptance prove different things

Project terminology varies. Some contracts include integrated testing within factory acceptance testing (FAT); others place it inside site acceptance testing (SAT) or define a separate milestone. Agree on the scope rather than relying on the name.

Simulation is useful for early defect discovery, especially when the production MES is unavailable. It is not equivalent to testing the live interface. Record every simulated endpoint and specify which checks must be repeated after the actual connection is available.

Start with a testable acceptance baseline

Before running equipment, define the system boundary. Does acceptance stop at the cell controller, include the line supervisory system, or extend to inventory posting in ERP? Identify utilities and upstream equipment that influence results, even when another supplier owns them.

Each test should connect to a requirement and state its preconditions, inputs, expected behavior, measurable limit, evidence, and witness. “Communication works” is not an acceptance criterion. “The approved recipe reaches the intended controller, its revision is confirmed, and an incompatible revision prevents cycle start” is something a team can test.

Freeze the relevant PLC programs, robot software, drive parameters, application versions, interface mappings, and network configuration. Otherwise, a successful result may describe a system that no longer exists. Also agree on the disposition of deviations: which block acceptance, which permit restricted operation, and who has authority to approve exceptions.

Follow a production order through the entire system

An effective functional test follows the production workflow rather than the supplier equipment list. Start with an authorized order or recipe, verify material identification, observe processing and transfer, and finish with quality disposition and production reporting.

Consider a robot loading a servo-indexed fixture while a pneumatic clamp secures the part. Acceptance must prove more than movement. The correct fixture position must be confirmed, the required clamping condition established, and robot access coordinated with the machine state. Whether pressure monitoring, position sensing, or another method is appropriate depends on the design and risk assessment.

Exercise automatic, manual, setup, and maintenance modes where applicable. Transitions deserve particular attention: switching from manual intervention back to automatic operation can leave stale handshake signals or ambiguous work-in-process status. Test product changeovers, empty buffers, blocked downstream stations, rejected parts, and interrupted cycles.

For each handshake, establish which controller owns the state, how completion is acknowledged, what timeout applies, and how both sides return to a known condition. A successful cycle alone can hide a race condition that appears only when one device responds slowly.

Verify data meaning, not just data movement

A connected interface can still be wrong. Check tag mappings, units, scaling, timestamps, identifiers, recipe revisions, and quality codes at both ends. A value interpreted as millimeters by one system and meters by another is a functional defect, even if communication diagnostics are healthy.

For MES/ERP transactions, examine acknowledgments, retries, duplicate prevention, and reconciliation after interruption. If a completion message is resent, it should not create a second production or inventory record where the specification requires one transaction. Confirm that rejects, rework, and partial orders retain their intended meaning rather than being counted as normal output.

Use traceable test identifiers to compare controller events with application records. Screenshots show what an operator saw; logs and transaction records help establish what actually happened.

Compare peak speed with sustained production performance

A short maximum-speed demonstration answers a different question from a sustained production run. The former may establish achievable cycle time under favorable conditions. The latter tests whether the integrated line maintains agreed output and quality while handling normal variation.

Define the measurement boundary carefully. Does throughput mean attempted cycles or good units? Are replenishment, inspection, routine stops, and changeovers included? If exclusions are allowed, list them before testing. Otherwise, two parties can measure the same run and reach different conclusions.

Use representative materials, tooling, payloads, and product variants. Where relevant, include acceleration limits, settling time, thermal behavior, compressed-air demand, and hydraulic operating conditions. An unloaded motion test cannot establish performance with the intended payload.

Choose test duration according to the behavior being evaluated. A brief run may reveal sequencing errors but miss heat-related drift, buffer accumulation, or software resource growth. There is no universal duration or throughput tolerance: those values belong in the project requirements, supported by the intended production duty.

Safety and recovery require separate evidence

Safety validation is not a checkbox added to a throughput test. Verify the applicable safety functions against the machinery risk assessment and safety requirements, using competent personnel and controlled procedures. Depending on the design, this may involve emergency stops, guards, protective devices, safe motion, and pneumatic or hydraulic energy controls.

ISO 13849-2 addresses validation for safety-related parts of control systems; IEC 62061 addresses machinery functional safety. Their applicability and required evidence depend on the chosen design framework and project obligations. CE marking is not an acceptance-test method and does not replace installation-specific verification.

Check behavior across connected machines. Opening a guard should produce the specified response throughout the affected zone, not merely change a local status bit. Confirm reset conditions, prevention of unexpected restart, and the treatment of stored energy. An emergency stop should not be treated as a substitute for an isolation procedure.

Test failures without creating uncontrolled hazards

Recovery testing should include credible interruptions: loss of a communications link, unavailable MES service, a drive fault, failed sensing, and power interruption where safely practicable. Use approved fault-injection methods; do not bypass protective measures simply to complete a test.

The important questions are practical. Does equipment enter its specified state? Is the alarm actionable? Can an operator identify the affected station? After recovery, does the system know whether a part is unfinished, complete, rejected, or awaiting inspection?

“Restart successful” is insufficient if an unfinished part becomes saleable output. Verify restart permissions, retained state, re-homing where required, and reconciliation of physical work-in-process with digital records. Include backup restoration: possessing a backup is different from demonstrating that it can restore the approved configuration.

Include operational security and usable handover records

For networked automation, test the access controls and connectivity included in the agreed scope. Verify operator, maintenance, and administrator permissions; remote-access approval; relevant event logging; and behavior when external services are unavailable. Security testing that could disrupt production needs separate authorization and a controlled window.

Handover evidence should allow someone outside the original commissioning team to understand and reproduce the result. The acceptance package normally needs:

• Requirement-linked test records showing conditions, expected results, actual results, and witnesses.
• Configuration versions, parameter backups, network drawings, and interface definitions.
• Supporting logs, traces, production records, and measurement details.
• A defect register with severity, ownership, corrective actions, and retest evidence.
• Operating restrictions, recovery instructions, and signed acceptance decisions.

After a software or configuration correction, repeat the failed test and any related regression checks. Changing a shared PLC function can affect stations that previously passed. Close-out should demonstrate that the correction worked without introducing another problem.

Make acceptance a decision, not a demonstration

G-IFA’s cross-sector benchmarking perspective helps frame the distinction: robotics, controls, motion, industrial software, and fluid-power hardware cannot be judged only by isolated specifications. Component benchmarks help screen engineering choices; integrated acceptance establishes whether those choices work together in the installed system.

Conditional acceptance can be reasonable for limited documentation or noncritical usability issues, provided ownership, deadlines, and restrictions are explicit. It should not quietly absorb unresolved safety defects, incorrect production records, or failures against essential contractual requirements.

Before signing, ask one final question: can the available evidence explain what the system does during normal production, during a credible failure, and after recovery? If one of those answers depends on reassurance rather than a recorded result, the acceptance plan still has a gap.