How Do You Verify an Automation System Integrator’s Capabilities?

Verify an automation system integrator’s capability by tracing its claims to evidence: comparable completed projects, technical work produced by the proposed team, realistic equipment demonstrations, documented safety engineering, and measurable acceptance tests. The strongest evidence shows how a system performs during production interruptions, product changes, and recovery from faults.

A polished demonstration proves only what happened under its test conditions. Before committing, establish whether those conditions match your application and whether the same engineering team will deliver the project. An integrator with excellent robot programming skills still needs to demonstrate competence in tooling, controls, machine interfaces, commissioning, and support wherever those responsibilities fall within its scope.

Which previous projects actually demonstrate relevant experience?

Ask for projects with similar technical constraints. A familiar industry label provides limited evidence on its own. Handling rigid metal blanks differs substantially from handling flexible packaging, even when both applications use the same robot model. Likewise, tending a CNC machine involves more than loading parts: door sequencing, chuck confirmation, chip contamination, and recovery after interrupted machining affect reliability.

Compare the reference application against the difficult parts of your project. Relevant similarities include part variation, required positioning accuracy, production mix, environmental conditions, machine communication, and the consequences of a failed operation. Establish exactly what the integrator delivered. Supplying a robot program within another contractor’s cell does not demonstrate responsibility for the complete line.

Request a reference conversation with someone familiar with commissioning and ongoing production. Useful questions include:

• What remained unresolved when the equipment first entered production, and how was it closed out?
• Did throughput remain stable across the agreed product range, or did certain variants require frequent intervention?
• Describe a significant breakdown or integration problem. Who diagnosed it, and what access or spare parts were needed?
• Were drawings, software backups, training, and maintenance instructions usable after handover?

Confidentiality can restrict access to customer information. An anonymized technical review, a redacted acceptance record, or a controlled reference call offers alternative evidence. When none is available, record the capability as unverified and address it through a demonstration or feasibility study before awarding the full scope.

Ask the proposed engineers to explain the difficult interfaces

Arrange a technical review with the people assigned to design and commission the system. Give them a representative operating sequence and ask them to explain the architecture, signals, timing, and fault handling. This reveals whether knowledge sits with the delivery team or only with the person presenting the proposal.

For a robot serving a CNC machine, follow one complete transaction: machine ready, loading permission, door access, workholding release, part exchange, clamping confirmation, robot withdrawal, and cycle start. Then interrupt that sequence. Ask what happens if communication fails after the part enters the fixture but before clamping is confirmed.

A credible explanation identifies how physical conditions are confirmed, which controller owns each state, how stale signals are rejected, and what permits a restart. Simply naming an industrial network does not explain the interface. Message meaning, timeout behavior, and responsibility for recovery determine whether connected equipment works together reliably.

For vision-guided handling, ask how calibration, lighting changes, uncertain detections, and unsuccessful picks are managed. For traceability, examine how part identity survives rework or a network outage. These questions expose engineering depth without requiring disclosure of proprietary source code.

What should a capability demonstration prove?

Build the demonstration around the application’s largest unresolved uncertainty. If grasping oily components is the concern, a dry sample proves little. If reflective surfaces affect inspection, include the expected finish variation. For an existing production line, interface simulation can establish sequence logic, but it leaves physical access and actual machine response unproven.

Agree on the sample set, operating conditions, measurements, and failure criteria before testing. Include representative variation rather than allowing only ideal parts. Document manual assistance, retries, rejected parts, and adjustments during the run; otherwise, a successful presentation can conceal work that production will have to absorb.

Distinguish measured results from estimates. A simulation supports reach, collision, and sequence analysis, but physical behavior still requires appropriate validation. Cable routing, gripper compliance, settling time, process forces, and sensor response can change the result. Where a critical assumption remains untested, define the next verification step and the consequence if the assumption fails.

Separate cycle-time claims from usable production output

Ask exactly where a quoted cycle starts and ends. Robot movement time excludes activities such as replenishment, inspection, machine processing, rejected-part handling, and scheduled tooling changes unless they are explicitly included. An impressive movement sequence can coexist with a production bottleneck elsewhere in the cell.

Throughput evidence should state the product variant, quality criteria, staffing assumptions, and duration of observation. A short run establishes sequence feasibility; a longer production-representative run reveals accumulation problems, thermal effects, contamination, and intermittent faults. The appropriate duration follows the process risks and operating pattern.

How can safety engineering competence be verified?

Request examples showing how hazards led to design decisions and how the resulting protective functions were validated. Relevant evidence includes a risk assessment, safety requirements, circuit documentation, validation records, and controlled procedures for testing. Certificates for individual components do not establish the safety of the assembled system.

Discuss actual tasks: clearing a jam, teaching a position, replacing tooling, entering a guarded area, and restarting after maintenance. A capable integrator explains how access, stored energy, unexpected motion, and restart permissions are addressed for each task. A collaborative robot application still requires assessment of the complete installation, including the tool, workpiece, surrounding equipment, and possible trapping points.

Clarify who owns the overall safety assessment when several contractors contribute equipment. Gaps often occur at interfaces, such as a conveyor passing through guarding or an upstream machine that continues feeding material after a downstream stop. Applicable requirements depend on the installation and jurisdiction; the proposal should identify the basis of the safety work and the required deliverables.

Use acceptance testing to make capability contractual

Convert important promises into observable pass conditions before detailed design advances. Factory acceptance testing establishes performance at the integrator’s facility under agreed conditions. Site acceptance testing addresses the installed system, including utilities, actual interfaces, material flow, and the production environment. Neither test automatically substitutes for the other.

Acceptance criteria need a defined product range, measurement method, test conditions, and treatment of interruptions. “Runs successfully” leaves too much unresolved. Specify how acceptable output is counted, which defects invalidate a result, and how downtime is attributed. Separate failures caused by the delivered system from interruptions caused by unavailable upstream equipment, while retaining visibility of both.

Include recovery tests alongside normal production. Representative challenges include a missing part, a sensor fault, communication loss, an emergency stop, and restoration of power. Each test needs an expected safe state and an agreed path back to production. Conduct fault tests through controlled procedures that preserve the installation’s safety protections.

Record deviations, corrective actions, retest requirements, and responsibility for closure. Any accepted limitation should appear in the handover record with its operating consequences. This prevents a temporary workaround from quietly becoming the final operating method.

Can the assigned team deliver the work?

Review staffing against the actual scope. Identify the people responsible for mechanical design, electrical design, controls, safety, process validation, and commissioning. Smaller integrators can deliver complex projects successfully, but concentrated knowledge creates a continuity question: who takes over if the lead programmer becomes unavailable?

Ask which work is subcontracted and how those interfaces are managed. A specialist subcontractor is useful when responsibilities, design review, and final acceptance remain clear. Unnamed subcontractors or unresolved ownership of tooling and machine modifications make the delivery plan difficult to assess.

Examine an example of requirements tracking and engineering change control. A late part revision can affect gripping, fixtures, inspection, and cycle time simultaneously. The integrator should show how such a change is assessed, approved, incorporated into documentation, and tested. A schedule is more credible when it identifies dependencies such as sample availability, machine access, and design approvals.

What evidence establishes support after handover?

Ask to see a sample handover package. It should make the installation maintainable through current drawings, equipment lists, software and configuration backups, recovery instructions, and documented access arrangements. Establish which editable files, licenses, passwords, and engineering tools are included, and identify any contractual restrictions before award.

Support capability becomes clearer through a fault scenario. If a controller fails outside normal working hours, how is assistance requested, what information is required, and who can restore the system? Distinguish response time from restoration time. Remote access helps only when connectivity, authorization, diagnostic visibility, and site access arrangements support it.

Training should include recovery and maintenance tasks relevant to the installation. Ask for a practical handover exercise in which designated site personnel restore a backup or recover from a representative fault using the supplied instructions. That exercise tests both documentation quality and knowledge transfer.

When is there enough evidence to proceed?

Judge capability against the project’s hardest requirements. Strong references support delivery credibility; a representative demonstration supports process feasibility; technical reviews establish engineering depth; and agreed acceptance criteria make performance verifiable. None of these alone resolves every uncertainty.

A useful decision record links each critical requirement to evidence, names any remaining assumption, and defines how it will be closed. Where an unproven assumption could force major redesign, resolve it through a bounded feasibility phase before committing to the full installation. The resulting scope should make clear what has been demonstrated, what remains to be tested, and who owns that work.