Integrating a robot with the software you already run: patterns, lock-in and what to demand from the manufacturer

Because the people who act on a robot’s observations do not sit in the robot’s app. A security control room watches a video management system. A maintenance team works from a planned maintenance or asset management system. A site manager reads an incident log and a dashboard. If the robot’s detections, footage and readings live in a separate application that only the vendor’s engineer can read, then every alert needs a person to notice it in one place and re-enter it in another, and within a few months the robot is a demonstration nobody watches. The pilots that turn into deployments are the ones where the robot’s output arrived where the team already looked, in the format the team already used, from day one.

The second reason is ownership. A robot integrated only through the manufacturer’s cloud is a robot the business can lose: to a subscription change, to a firmware update that removes a feature, to the manufacturer leaving the market, or to a network policy that will not allow an outbound connection from an operational site. The integration path is where the business decides whether it owns the deployment or rents it.

Every robot on the market is integrated by one of four patterns, and a manufacturer’s tier or price often decides which you get. The table compares them on the questions that matter over a five-year deployment rather than a two-week pilot.

It should be the one piece of the deployment that does not change when the robot does. Concretely, an integration layer sits between the robot’s SDK and the systems the business runs, and does seven things.

Built that way, the robot is replaceable and the operation is not. That is the architecture we design for, and it is the reason Forge’s engineering team spends more time on SDKs and interfaces than on any single robot.

The integration pattern you end up with is largely decided by the manufacturer’s terms, and those are far easier to change before a purchase than after. Six terms belong in every robot procurement, and a manufacturer’s answer to each tells you which pattern you are really being sold.

The robotics and industrial worlds already have the interfaces; the work is using them rather than a vendor’s private ones. ROS 2 is the common framework robotics engineers integrate against, and the makers with real developer access publish ROS 2 packages or message definitions. OPC UA and MQTT are the standard ways industrial data reaches historians, SCADA and dashboards, and a robot’s readings belong on the same bus as everything else in the plant. ONVIF is how cameras talk to video management systems, and a robot’s camera should present to the VMS like any other camera rather than through a separate window. A documented REST or gRPC API covers what is left. Every one of those is something your own engineers, or any competent integrator, can work with after the original supplier has gone, and that is the test.

Write the destination first. Before a platform is chosen, list the systems the robot’s output must reach, the format each expects, and the person who will act on it; then choose a platform whose tier gives the access to make that happen, and confirm the terms above in the quotation. In the pilot itself, measure integration as a first-class result: did the detection reach the VMS with the clip attached, did the reading create the work order, did the alert land in the incident log with route, time and evidence, and did the robot keep recording and catch up when the link dropped? A pilot that ends with a separate app that only the vendor’s engineer can read has not tested integration; it has postponed it. That is how we structure a pilot programme, and where engineering delivery needs scale we work through our engineering delivery partnership.