Who Is Responsible When Robotic Automation Fails but the Robot Is Not at Fault?

When a robotic automation system fails, the robot is not automatically the cause. A production cell can miss its cycle-time, quality or availability targets even when the industrial robot performs within its documented payload, reach, repeatability and duty-cycle specifications.

The actual failure may originate in PLC sequencing, tooling, fixtures, safety logic, material flow, software interfaces, production data or assumptions made during system design. Technical responsibility should therefore follow the verified root cause and the contractual scope of the party that controlled the failed subsystem.

Legal liability depends on the applicable contract and jurisdiction. From an engineering perspective, however, responsibility can usually be clarified by separating four areas: robot supply, system integration, process ownership and plant operation.

Technical scope: this article explains engineering responsibility and root-cause analysis in robotic automation projects. It does not constitute legal advice.

Who is responsible when robotic automation fails?

The responsible party is normally the organisation that specified, designed, supplied, programmed, modified or operated the element that caused the failure. In complex projects, responsibility may be shared because several parties contributed decisions or assumptions that shaped the final system.

• The robot manufacturer or supplier is responsible for the robot meeting its agreed technical condition and documented specifications.
• The system integrator is responsible for the engineering, programming, coordination and commissioning work included in its contractual scope.
• The tooling or peripheral supplier is responsible for its equipment meeting the agreed performance and interface requirements.
• The customer or process owner is responsible for supplying accurate requirements, approving technical assumptions and operating the system within the validated conditions.
• Software and infrastructure providers may be responsible when the failure originates in their applications, networks or interfaces.

The robot should not become the default explanation simply because it is the most visible component in the cell.

Why a functioning robot can still belong to an underperforming system

An industrial robot operates inside a wider technical architecture. The complete cell may include a robot controller, PLC, safety PLC, spindle or gripper, fixtures, sensors, conveyors, external axes, machine vision, process equipment, industrial networks, MES connections and operator interfaces.

Each component may work correctly in isolation while the combined system performs poorly. A robot can execute every programmed movement accurately and still spend excessive time waiting for a conveyor, a vision result, a PLC handshake or permission from an upstream machine.

The robot may also follow the required trajectory while the finished part fails inspection because the fixture deflects, the tool is unstable, the material varies or the selected process parameters are unsuitable.

Robot motion performance and production-system performance are different engineering questions.

Typical responsibility boundaries in a robotic cell

Important: the table identifies likely technical ownership. Contractual or legal liability depends on the agreed scope, applicable law and the evidence available for the specific project.

What the robot supplier is responsible for

The robot supplier is responsible for delivering the equipment described in the technical and commercial agreement. Depending on the transaction, this may include the robot arm, controller, teach pendant, software options, cables, documentation and agreed test records.

For a new robot, conformity is generally assessed against the manufacturer’s published specifications and the ordered configuration. For a refurbished robot, the supplier should define exactly what inspection, repair, replacement and operational testing have been completed.

Relevant supplier responsibilities may include:

• correct identification of the robot and controller;
• delivery of the agreed payload, reach and configuration;
• disclosure of technical condition and known limitations;
• verification of installed software and options;
• operational testing within the agreed scope;
• documentation required for installation and integration.

If the robot meets these commitments, unrelated engineering decisions made during cell design should not automatically become the supplier’s responsibility.

Companies evaluating existing equipment can review RHTS resources on refurbished industrial robots and available new and refurbished robot systems.

What the system integrator is responsible for

The system integrator converts individual components into a working production cell. Its exact obligations depend on the contract, but they may include robot selection, simulation, tooling, fixtures, controls, safety, programming, interfaces, commissioning and performance validation.

A competent integrator must evaluate whether the proposed architecture can achieve the required cycle time, quality, availability and process stability. Confirming nominal robot payload and reach is not enough.

The integration scope may need to validate:

• whether the robot reaches all process points in stable configurations;
• whether tooling and fixtures remain rigid under operating loads;
• whether PLC and robot sequences meet the target cycle time;
• whether sensors and vision systems handle normal production variation;
• whether the safety concept supports production and operator access;
• whether third-party machines and software exchange data reliably;
• whether faults can be diagnosed and recovered efficiently.

If these elements were part of the integration scope and were not engineered or validated correctly, the failure belongs to system integration rather than to the robot hardware.

What the customer and process owner are responsible for

The customer also determines whether the project succeeds. An integrator cannot design a reliable system around incomplete production data, unrealistic targets or requirements that change after approval without formal reassessment.

The process owner should provide accurate information about:

• part dimensions, weight and expected variation;
• materials and operating conditions;
• required cycle time and production volume;
• quality and tolerance requirements;
• upstream and downstream equipment;
• available utilities, floor space and network infrastructure;
• operator involvement and maintenance capabilities.

After commissioning, the plant must also follow the agreed operating, maintenance and change-control procedures. Unapproved tooling changes, modified PLC logic, neglected calibration or operation outside the validated process window can shift responsibility away from the original supplier or integrator.

When responsibility is shared

Many robotic automation failures do not have a single owner. A customer may define an aggressive cycle-time target, an integrator may accept it without sufficient validation and a tooling supplier may later provide an end effector that is heavier or slower than the original assumption.

In this situation, the final failure is architectural. Several decisions contributed to it, so responsibility may be distributed across several parties.

Shared responsibility is common when:

• requirements were incomplete but formally approved;
• performance targets were accepted without representative testing;
• an interface was changed without notifying the other suppliers;
• production materials differed from the test materials;
• the customer selected equipment that the integrator advised against;
• several suppliers commissioned their systems independently without validating the complete sequence.

How to determine whether the robot or the architecture caused the failure

1. Define the failed requirement

“The system does not work” is not a measurable failure statement. The team must identify whether the issue concerns cycle time, accuracy, availability, safety interruptions, scrap, tool life, communication faults or another agreed requirement.

2. Compare actual performance with the approved specification

The investigation should use the technical offer, functional specification, simulation assumptions and acceptance criteria. Expectations introduced after commissioning should be treated as new requirements, not as proof that the original system failed.

3. Test the robot independently

Check alarms, mastering, calibration, payload configuration, repeatability and basic motion behaviour under controlled conditions. If the robot performs correctly, the investigation should move to tooling, process conditions and system interfaces.

4. Break the cycle into measurable states

Measure robot motion, process time, PLC waiting, material transfer, sensor confirmation, safety recovery and operator intervention separately. The largest production loss may occur while the robot is stationary.

5. Review interfaces and change history

Examine PLC handshakes, network traffic, software versions, product changes, tooling modifications, maintenance actions and operator procedures. Many failures begin after a change that was never validated across the full system.

6. Reproduce the failure with evidence

The issue should be reproduced under documented conditions using logs, timestamps, measurements, video, part-inspection data and equipment diagnostics. Responsibility cannot be assigned reliably from isolated observations.

Warning signs that the problem is architectural

• The robot completes its motion correctly during isolated testing.
• Most cycle-time loss occurs in waiting states.
• Quality changes with tooling, material or workpiece position.
• Faults occur at interfaces between independent systems.
• The cell performs well on demonstration parts but poorly across normal production variation.
• Safety interruptions are caused by layout or access requirements.
• Performance deteriorates after software, product or process changes.

These signs do not prove responsibility by themselves, but they direct the investigation toward system architecture and process integration.

How to prevent responsibility disputes before commissioning

Define measurable acceptance criteria

Cycle time, output, quality, availability, changeover time and fault recovery must be expressed as measurable requirements. Terms such as “fast,” “high precision” or “production-ready” are not sufficient.

Create a responsibility matrix

Document who specifies, supplies, programs, validates and supports every subsystem, including the robot, PLC, tooling, safety system, vision equipment, external machines and production software.

Document technical assumptions

Record payload, product variation, material properties, incoming-part accuracy, operator involvement, network availability and every condition used to size or simulate the cell.

Separate FAT and SAT

A factory acceptance test verifies the system under supplier test conditions. A site acceptance test verifies performance after installation in the customer’s production environment. Both require documented procedures and pass criteria.

Control changes formally

Changes to products, tooling, software, cycle targets or interfaces should be reviewed before implementation. Informal changes create responsibility gaps because the operating system may no longer match the approved design.

Require usable diagnostic data

Alarm histories, cycle-state timestamps, quality records and interface logs make root-cause analysis possible. A system that cannot explain why it stopped will be difficult to maintain and equally difficult to assess contractually.

What information is needed for a technical assessment?

A useful investigation normally requires:

• robot and controller model;
• complete cell layout and equipment list;
• functional specification and accepted scope;
• cycle-time requirement and actual cycle breakdown;
• robot, PLC and safety logs;
• payload and tooling configuration;
• quality measurements and rejected-part data;
• FAT and SAT protocols;
• maintenance and calibration history;
• records of changes made after commissioning.

Without these records, responsibility discussions tend to rely on perception rather than engineering evidence.

Frequently asked questions

Is the robot supplier responsible if the cell misses cycle time?

Only when the cause falls within the supplier’s agreed scope or the robot fails to meet its documented performance. Cycle-time losses may also originate in PLC logic, process equipment, tooling, safety interruptions, sensors or material flow.

Can the integrator be responsible when every component works correctly?

Yes. Integration concerns how components operate together. Individually functional equipment can still create an underperforming system when interfaces, sequences, layout or process assumptions are poorly designed.

Who is responsible when the customer supplied the process requirements?

Responsibility depends on whether the information was accurate and whether the integrator was contracted to validate it. If both parties approved unverified assumptions, responsibility may be shared.

Does using a refurbished robot change the responsibility model?

The same principle applies. The refurbisher is responsible for the agreed condition and configuration of the robot. The integrator remains responsible for the engineering and commissioning work included in its scope.

Which documents are most important for preventing disputes?

A functional specification, responsibility matrix, interface definitions and measurable FAT and SAT criteria create the clearest basis for technical accountability.

How to assign responsibility without blaming the wrong component

When a robotic automation cell underperforms, the investigation should answer three questions:

If the robot meets its documented specifications, replacing or blaming it will not correct a failure caused by PLC sequencing, tooling, fixtures, safety architecture, material flow or software interfaces.

Engineering evidence identifies where the failure originated. The contractual scope determines which party was responsible for that area. Legal liability is then assessed under the applicable agreement and law.

Before requesting a technical review, prepare the robot and controller model, cell layout, acceptance criteria, actual cycle-time breakdown, alarm and PLC logs, tooling configuration, maintenance history and records of changes made after commissioning.

RHTS evaluates industrial robots within the context of the complete production system. Review available new and refurbished industrial robots, or contact RHTS with the application data and current failure evidence for an initial technical assessment.