Why Manufacturing Automation Software Outlives Your Robots

A new palletizing cell goes in beside a conveyor line that predates it. The cell arrives with its own vendor console, and the only thing joining it to the conveyor’s PLC is a supervisor watching two screens.

That supervisor is your manufacturing automation software. Everything the floor knows about sequencing lives in one person’s head and on a whiteboard by the door: which order jumps the queue when a customer calls, what happens to a half-finished batch when a cell faults, whether the second shift inherits a clean state. The robots were the capital line item. Coordination came free, so nobody scoped it.

Then a second cell arrives from a different vendor, and free stops being the price.

What a robot vendor’s quote leaves out

Arms, AMRs, vision and sortation are heading toward commodity as Chinese suppliers scale the hardware cost curve down, and the hardware quote is the one part of the project you can compare on a spreadsheet.

What none of them hands you is a floor. Each vendor ships a console that manages its own equipment well and treats everything else as out of scope. Two vendors mean two definitions of a job and two audit trails that cannot be laid over each other. Whoever reconciles them is doing integration work by hand, mid-shift.

That cost never reaches a capex sheet because nobody invoices it. It gets paid in the gap between the rate the equipment could run at and the rate it does: the pause at every changeover while a person works out what goes where.

Who owns sequencing when the second vendor arrives

Either one vendor’s system becomes the master and the other machines get driven through its API, or you own a thin coordination layer above all of them.

The first is faster to stand up and hands one supplier a veto over your roadmap. Add a machine they don’t support, or try to renegotiate, and the switching cost is your entire floor logic. That is the general platform-versus-custom question, and on sequencing the layer is the side to own, because those rules are the part of the operation that is genuinely yours.

The read path comes first. Most equipment already speaks OPC UA, MTConnect, MQTT or Modbus TCP, so job state and fault codes can land in one event stream, in a schema you defined rather than the one your largest vendor happened to pick. Above that sits a single job model, so a unit of work carries one identity from order release to pallet, plus a single priority record: one place where sequence is set, one where it can be overridden, and every override attributed to a named person.

Deciding what runs next and commanding a machine to run it are separate scopes. The layer holds the decision and the record; the command goes through the equipment’s own controller, or through the MES that already owns dispatch. Actuation carries a safety case that belongs in its own project, priced separately. Anything the layer is unsure about stops and escalates to the supervisor on shift, because a bad sequence moves physical material and someone has to move it back.

AI automation earns its place in the messy inputs around that decision rather than in the decision itself. A maintenance email that changes tomorrow’s capacity, or a quality hold buried in a customer PDF, gets extracted and filed against the affected work order.

If the machines are not networked and no historian is collecting off them, that work comes first: a coordination layer with nothing to read is an empty screen. And if an MES already covers dispatch and your team genuinely uses it, extend that instead. Rule both out before you commission a build.

What manufacturing automation software costs to build

Work of this shape prices as an integration layer, because that is what it is. Tier 3 in our API integration cost guide, ₹14L to ₹24L, covers a layer that fronts several systems with its own data model and its own reconciliation, which is what coordinating across vendor consoles amounts to. Below that tier you are buying point-to-point connections, which are the right call while there is exactly one pairing to make.

Which is why the first cell is the wrong moment to build: a layer over a single vendor is architecture you maintain for no return. The build starts earning at the second vendor, or the first time two cells contend for the same operator. A cell gets replaced or resold when the product changes; the rules about what runs next survive it.

Running cost recurs. The layer holds state, so it needs monitoring like any other production service, and every vendor firmware update is an interface you re-verify. Cloud and license fees sit outside the build price. Budget firmware drift as recurring work.

Ask these before you sign for the next cell

Get one thing in writing before the deposit clears. Ask whether an external system can read every fault code and job state off the equipment over a standard protocol, and change a job’s priority through a documented API, with nobody touching the vendor’s console. A yes with sample payloads means you can keep buying machines on merit, and the manufacturing software above them stays yours to change. A no, or a yes that turns out to require their middleware license, means this purchase order has quietly bought you a master system as well as a robot.

Put that question in the RFQ for the next cell, before the order is signed, because that is the only point where you can make the answer a condition of the sale.