Choosing a Robotic Integrator: Cells, Cobots, and End-of-Arm Tooling

01. What actually separates integrators

Every integrator will show you successful installations. That tells you they have delivered projects, not how they will handle yours. Six things distinguish them, and all six can be checked before award.

• How they treat part variation. An integrator who asks for your worst parts, not your best, is designing for what will actually arrive. One who quotes from a drawing has designed for a part that exists in CAD.
• How they build a safety case. There is a difference between performing a risk assessment that drives the design and selecting safety components that satisfy a design already fixed. The first produces a defensible cell; the second produces a cell with safety devices.
• How they define the scope boundary. Precision here is a proxy for experience, because integrators who have caught the gaps before are specific about them.
• What they will commit to at acceptance, and how early they will agree the criteria. An integrator confident in their design will define acceptance in the contract. One who wants to define it later is preserving room for later.
• Whether they have done your process, as distinct from your industry, palletizing experience does not transfer to deburring, and a reference list sorted by sector tells you less than one sorted by process.
• What they hand over. Documentation, source code or program access, training, and spares determine whether you can maintain the cell or are permanently dependent on the integrator to make any changes.

All six are testable during a proposal review, which makes them more useful than a reference list sorted by sector.

02. Before you talk to anyone: define the application

An integrator cannot design what you have not described, and the gaps here become assumptions in the quotation.

• The process itself, stated in terms of what has to happen to the part rather than what the robot should do. Describing the outcome leaves the integrator room to propose a better method than the one you had in mind.
• Rate: parts per hour or cycle time, and whether that is an average or a peak. State the difference, because a cell designed for an average will not run at a peak.
• The parts, in full. Every variant, its dimensions and weight, how much it varies, and which variants make up what share of the volume. This is the single most valuable thing you can supply.
• How parts arrive and how they leave: in bins, on a conveyor, in fixtures, oriented or random, and whether that presentation is fixed or could change.
• Product changeover: how many changeovers per shift or week, who performs them, and how long is acceptable.
• Quality requirement: what the cell has to achieve, how it is measured, and what happens to a part that fails.
• The people: who operates the cell, who maintains it, what their existing skills are, and what shift pattern they work.
• The space, including what is above and below, floor loading, services available, and how equipment will be brought in.
• The rest of the line: what feeds the cell, what it feeds, and how those interact when either stops.

Supply real parts, and supply the bad ones

The most useful thing a buyer can do is hand over a representative sample of actual production parts, deliberately including the ones at the edges of tolerance, the variants nobody likes, and any that have historically caused problems. An integrator who tests tooling against your good parts will design for good parts. Cells fail at the margins, and the margins are what the sample should represent.

Turn the parts into a variation envelope

Sending worst-case parts is necessary and, on its own, it cuts both ways. An integrator designing from CAD has designed for a part that does not exist. But a buyer cannot reasonably ask an integrator to automate a statistically undefined process with arbitrarily bad input either, and without an agreed envelope every miss later gets attributed to part variation. Define the physical world the cell has to handle.

• The variation envelope itself: dimensional tolerances, mass range, surface finish and contamination, color and reflectivity where vision is involved, burrs, warp, orientation, temperature, any oil or moisture, packaging state, and the known defect modes.
• Evidence rather than anecdote. How many parts the sample represents, where the worst-case examples came from, and any historical quality data. Where a dimension drives gripping or vision, whether your measurement of it is capable.
• The automation-ready condition is stated in three parts: which presentations and defects the cell must accept and run; which it must detect and reject; and which must be prevented upstream by fixturing, singulation, orientation, cleaning, or operator preparation. That third category is a commitment you are making, not one the integrator is.
• Stated guarantees on part presentation, since this is shared responsibility: conveyor stability, fixture repeatability, bin fill level, lighting conditions, readability where codes are scanned, and the handshakes with equipment upstream and downstream.
• A change rule. If a new part number, a new supplier, a packaging format, or an upstream process change moves the envelope, that is a controlled scope change rather than capability the cell was assumed to have.

03. Scope and where the boundaries fall

Robotic cell projects fail at their edges more often than at their center. The robot works. The gripper works. The cell does not run because the upstream part presentation was outside the integrator's scope, and the electrical supply was the customer's responsibility. It arrived late, or communication with the existing line controller was assumed by both parties to be the other's responsibility.

What to establish in writing

• Where the scope starts and stops physically, meaning the exact point on the floor and in the process where the integrator's responsibility begins and ends.
• Part presentation: who supplies it, who guarantees it works, and what happens if the presentation turns out to be the constraint on rate.
• Controls integration with the wider line: who writes the interface, who tests it, and against what.
• Utilities: power, air, network, and who brings each to the cell.
• Civil work: foundations, floor preparation, anchoring, and access for installation.
• Programming: who writes it, who owns it afterward, and whether you receive source or only a compiled application.
• Existing equipment: what the integrator is expected to interface with, and who is responsible if that equipment turns out not to behave as documented.
• Decommissioning and removal of whatever the cell replaces.

The diagnostic question here is simple: ask an integrator to state what is excluded from their scope. A precise, specific list is a sign of experience. A short list, or a vague one, means either that they have not thought about it or that they intend the boundary to be flexible in their direction. This is the single most informative question in a proposal review.

04. The safety case, and who owns it

Where responsibility actually sits

A robot supplier will state that the arm and its controller conform to the robot standard. However, what stands behind that statement varies: it may be a third-party listing, a manufacturer's own declaration, or a conformity claim under a regional regime, and these are not interchangeable. Establish which one you are being offered. That certificate covers the arm and its controller. It does not cover your cell, your tooling, your part, or your operators, and a risk assessment of that application establishes the safety of the complete application. In most arrangements, the integrator performs that assessment, and the end user retains obligations for how the cell is used after handover. Explicitly establish who performs the risk assessment, who signs it, to which standard it is performed, and what the end user is being asked to accept.

This is the most consequential part of the guide because it is the area where an unclear boundary has legal and physical consequences rather than commercial ones.

The standards have moved, and it matters to your paperwork

Robot safety standards were revised recently and substantially. The most significant change for a buyer is structural: the requirements for collaborative applications, which previously sat in a separate technical specification, now sit inside the robot systems and integration standard itself. Functional safety requirements were made explicit rather than implied; guidance on end effectors and on manual load and unload was drawn from separate technical reports; and the North American adoption has been revised to follow suit, with an additional part addressing end-user responsibilities that has no international equivalent.

Two practical consequences. First, documentation still circulating cites the previous baseline, so ask which edition your integrator is designing to and which edition your robot supplier certifies to, and expect them to answer without hesitation. Second, a cell documented against the older baseline is not automatically unsafe. Still, as adoption settles, it is reasonable to expect that auditors, insurers, and your own customers may begin asking about the current one. That is a question worth raising now rather than at the first audit.

Collaborative is a property of the application

The revision made explicit something that was always true and frequently misunderstood: a robot is not collaborative, an application is. A robot designed for collaborative use, fitted with a sharp tool, moving a heavy part, at speed, in a layout that traps an operator, is not a collaborative application, and no amount of branding changes that. The risk assessment determines whether human and robot can share the space, and the tooling and the part are part of that assessment.

The standards define four ways a human and a robot may share a workspace. In the first, the robot comes to a monitored standstill when a person is present and remains stationary while they are there. In the second, the operator moves the robot directly by hand using a hand-guiding device. In the third, the robot monitors the separation distance to the person and slows or stops as they approach. In the fourth, the robot is limited in the force and pressure it can exert in contact, so that contact, if it happens, stays below the limits established for the body region that could be contacted. That is an application-specific assessment rather than a single test: the tooling geometry, the workpiece being carried, the trajectory, and any trapping or crushing hazard in the layout all bear on whether the limits are actually met in your cell.

The re-assessment trigger nobody schedules

A cell assessed as safe for one part, one gripper, and one layout is not automatically safe after any of those changes. Changing the end-of-arm tooling, running a different part, altering the layout, or changing the speed can all invalidate the assessment. Establish before award who is responsible for re-assessment, what triggers it, and whether the integrator will support it later or whether you will need that capability in-house. High-mix operations should build this into the changeover procedure rather than treating it as a project activity.

05. Cell or collaborative application

The choice between a guarded cell and a collaborative application is usually made on the wrong basis: that collaborative applications sound simpler and cheaper because they appear to remove the fencing.

What a guarded cell buys

Speed. A robot behind fixed guarding with interlocked access can run at full speed, carry heavy payloads, and use whatever tooling the process needs, because no person is present while it moves. Where cycle time drives the business case, this is usually the right answer and the guarding is a modest fraction of the project.

What a collaborative application buys

Space and flexibility. Removing or reducing fencing saves floor area, allows an operator to work adjacent to the robot, and makes the cell easier to redeploy. That suits low-volume, high-mix processes where a human does part of the task.

What a collaborative application costs

• Speed. Force and pressure limits, or separation monitoring that slows the robot as an operator approaches, both reduce throughput, sometimes dramatically. A collaborative cell that has to meet an aggressive cycle time frequently ends up fenced anyway.
• Payload, since the limits constrain what can be moved and how fast it can be moved.
• Tooling constraints. Sharp edges, pinch points, hot surfaces, and heavy parts all count against a collaborative assessment regardless of the robot.
• Assessment effort. Demonstrating that contact stays within limits is real work, and it has to be redone when things change.

The honest framing is that collaborative operation removes a fence and adds a constraint. Where the constraint suits the process, it is an excellent answer. Where the cycle time is aggressive, or the tooling is inherently hazardous, the fence was the cheaper solution. Ask an integrator proposing a collaborative application what the cycle time is with the safety functions active, not with them bypassed for demonstration.

06. End-of-arm tooling and part presentation

End-of-arm tooling is where integration risk concentrates. It is the only part of the cell that touches your product; it has to absorb every variation in that product, and it is frequently the last thing designed and the first thing to cause trouble.

What to establish

• How the tooling handles the full range of your parts, including the variants and the tolerance extremes, and whether one tool covers them or a changeover is required.
• What happens when it does not grip: whether a failed pick is detected, what the cell does about it, and whether a dropped part stops the line or is simply lost.
• Cycle contribution: gripping and releasing take time, and tool changes take longer, and these are frequently omitted from a cycle time estimate.
• Whether a tool changer is needed, what it costs in cycle time and repeatability, and how many tools the changeover requires.
• Consumables and wear: vacuum cups, seals, jaws and their expected life, availability and cost, because these are the items you buy repeatedly.
• Weight, since tooling counts against payload and heavy tooling can force a larger robot than the part alone would require.
• Utilities at the tool: air, electrical, signals, and how they are routed and protected through the robot's motion.

Part presentation is half the problem

A robot can only pick what it can find. How parts arrive determines whether the cell needs vision, what kind it needs, and how reliable the whole arrangement will be. Parts in fixtures are the most reliable and least flexible. Parts on a conveyor need location, usually vision. Parts in a bin require three-dimensional vision and pose estimation, and bin picking is substantially harder than it looks in a demonstration where the bin is well-lit and half-empty.

Where an integrator proposes vision, do not settle for whether it is included. Agree on what it has to achieve in numbers; you can test at acceptance.

• Detection rate on your actual parts, and separately the false-accept and false-reject rates, since those cost you differently: one ships a bad part, and the other stops the cell.
• The cycle time vision contributes, acquisition and processing stated separately from robot motion.
• Tolerance to the conditions that will actually vary: ambient lighting through the day, reflective or dark surfaces, occlusion in a bin, and part-to-part surface variation.
• Calibration frequency, who performs it, and what triggers a recalibration.
• The manual recovery path when it fails to find a part, and how often that is expected to occur. A cell that needs operator intervention every few hundred cycles carries a labor cost that nobody included in the business case.

07. Acceptance: how you will prove it works

Acceptance is the buyer's main leverage, and it is routinely given away by leaving the criteria until installation. Define them in the contract.

Define the outcome, not just the rate

Acceptance is the buyer's primary leverage, and a rate alone does not secure it. A cell can meet an agreed-upon cycle time and still deliver fewer good parts than promised because of vision retries, failed picks, false rejects, replenishment delays, tool changes, nuisance trips, and interventions that someone later classifies as outside scope. Specify the commercial outcome instead.

• Good parts per hour or per shift, which is the number the business case was built on, rather than cycle time, which is the number the cell can hit while missing it.
• First-pass yield and, separately, allowable scrap and rework.
• Availability or overall equipment effectiveness, defined so both parties compute it the same way.
• The maximum number of operator interventions per shift that still counts as passing, since a cell that runs only because someone stands beside it has not passed.
• Changeover duration, performed by your people rather than by an engineer who has done it fifty times.
• Mean time to recover from the common faults, which matters more to a line than mean time between them.

Agree the downtime taxonomy before award

This is the clause that decides whether an acceptance test can be settled or only argued. A rate without a loss-accounting model is still a negotiation. Before award, agree in writing which stoppages count against the integrator, which are yours, how root cause is determined and by whom, and whether repeated short recovery events count at all. That last one matters: a cell stopping for twenty seconds every fifteen minutes may never register as downtime under a naive definition and will still destroy the rate.

Also agree on the remedy. What the correction plan looks like and how long the integrator has; what retest rights you hold; what payment is held back until the cell passes; and what happens if the cell cannot reach the rate because the technical premise was wrong rather than because something needs adjusting. That last case is the one nobody writes down and the one that turns into a dispute.

The stages

• Design review before build, where the layout, safety concept, tooling approach, and interfaces are agreed. This is the cheapest point to change anything.
• Factory acceptance, at the integrator's site, where the cell is run on your parts before it is shipped. Send real parts and attend.
• Site acceptance, after installation, confirming the cell works in your environment and with your services and line connections.
• Production demonstration, where the cell runs at rate on real parts for a defined period under your operators rather than the integrator's engineers.

What each stage has to specify

• What is being demonstrated: rate, quality, uptime, changeover time, or all of them.
• On what parts: how many, which variants, and drawn from where.
• For how long, and over how many shifts, since a cell can pass a two-hour demonstration and fail a two-day one.
• What counts as a failure, who adjudicates, and what happens to time lost to causes outside the cell.
• What the consequence of not passing is, and how many attempts are allowed before something changes commercially.
• An itemized cycle time model rather than a single figure, breaking out robot motion, grip and release, vision acquisition and processing, conveyor or indexing time, safety-related speed reduction, tool change, controller handshakes, inspection and part presentation. This is what lets you see where a claimed rate is optimistic, and it is the document to ask for at design review rather than after the cell is built.
• The conditions the demonstration runs under: consecutive shifts rather than hours; the real-part mix, including the awkward variant and its actual volume share; bins run down to empty rather than kept full; and normal interaction with whatever feeds and follows the cell.
• Who is present. The demonstration should run with your operators, on your shift pattern, with the integrator available but not intervening.

The production demonstration is the one that matters and the one most often omitted. A cell running well with the integrator's engineer standing beside it is not the same as a cell running well on night shift with your operators. Specify that your people run the demonstration, because the difference between those two situations is the training and documentation you are also buying.

08. Support, spares and what happens after buy-off

The cell will run for years, and the project ends in months. What you agree about the period after buy-off determines how much of that time you spend waiting.

• Documentation: electrical drawings, pneumatic schematics, the safety assessment and its supporting documents, the operating manual, and the maintenance schedule. Establish what you receive and in what format.
• Training: for operators, for maintenance, and for whoever will make program changes, delivered when the cell is installed rather than during the build.
• Spares: what the integrator recommends holding, what lead times apply to the items that stop the cell, and which parts are proprietary to the integrator rather than commercially available.
• Support response: what response time is committed, during what hours, remote or on site, and what it costs after the warranty period.
• Warranty scope: what it covers, what voids it, and whether it covers the cell as a system or only the components the integrator built.
• Change support: what it costs to add a part variant or modify the cell later, and whether the integrator will quote that now rather than when you have no alternative.

That last point deserves emphasis. An integrator who has your program in a form only they can edit, with no committed rate for changes, holds a position that becomes more valuable to them as your cell becomes more important to you. Settle it before award.

The digital handover, which is more than the programs

Receiving source code is necessary and not sufficient. A buyer can hold every program and still be unable to restore, modify, or secure the cell because something else remains under the integrator's control. Specify the complete package.

• Files: robot programs, controller source, safety controller project, operator interface project, vision recipes and calibration files, drive and motion parameters, fieldbus and device configuration, network architecture, electrical drawings, input and output lists, the tag database, a software and firmware version list, and a verified restore backup of the whole cell.
• Access and ownership: administrator passwords; license ownership and who renews them; transfer of any vendor accounts; the remote access method and who may use it; and a record of every component that connects to anything outside the cell.
• Change control: which edits require a safety review, revalidation, re-teaching, vision recalibration or re-acceptance, who is permitted to make them, and how the approved state of the machine is recorded so that you can prove what it is.

Recovery: what an operator handles, and what needs a technician

Establish what an operator does, and what requires a technician, for each of the events that will actually happen: a failed pick, a vision no-find, a safety trip, a dropped part, a communication loss, a power interruption, a tool change error, and a stop upstream or downstream. Ask for the recovery procedures as documents, and ask which of them your operators will be trained on. A cell whose every fault requires a call is a cell that runs one shift.

Cybersecurity and obsolescence

• Network segmentation, how remote access is approved and logged, account management, backup and restore procedure, and who is responsible for firmware and operating system updates over the life of the cell.
• Lifecycle horizons for the controller, any industrial computer or camera, and the safety devices, together with end-of-life notice arrangements and what a migration path would look like.

09. What good and poor answers sound like

The following are real distinctions, drawn from the criteria above. They are worth reading before a proposal review, because the difference is usually audible in the first conversation.

On your parts

Good: Asks for physical samples early, specifically requests the difficult variants, and tests the tooling concept before quoting a firm price.

Poor: Quotes from drawings, or accepts the parts you offered without asking what else runs on the line.

On rate

Good: States the cycle time with the safety functions active, breaks it down into its elements, and identifies which element is the constraint.

Poor: Quotes a robot cycle time without the tooling, the part presentation, or the safety-related speed reductions included.

On safety

Good: Describes the risk assessment as the thing that determines the design, names the standard and edition they work to, and can say what would trigger a re-assessment.

Poor: Lists the safety components they will fit, or describes the robot as collaborative as though that settles the question.

On scope

Good: Provides a specific written list of exclusions, and raises the boundary items you had not thought of, such as who owns the interface to your existing line controller.

Poor: Says the scope is turnkey without defining where it starts and ends, or produces a short exclusions list that grows after award.

On acceptance

Good: Proposes acceptance criteria in the proposal, including a production demonstration run by your operators, and is comfortable putting a rate and a duration in the contract.

Poor: Prefers to agree acceptance criteria closer to installation, or resists a demonstration period longer than a few hours.

On handover

Good: Confirms what documentation and program access you receive, quotes training explicitly, and provides a recommended spares list with lead times.

Poor: Treats documentation and training as items to be discussed later, or is unclear about whether you can modify the program.

On what could go wrong

Good: Answers the disappearance test concretely: shows the controlled file set, the restore procedure and evidence it has been tested, who holds which access rights, the documented recovery paths, and how you would prove the restored cell is still in its approved safety state.

Poor: Says you will have the programs, or treats restoration as something they would come back and do.