Warehouse Automation: WMS, AS/RS & AMR Integration

Installing robots is the easy part. The awkward part starts when a pallet has to move through several systems that all think they own part of the job.

A barcode is scanned. The WMS allocates a location. A warehouse-control layer creates a movement. An autonomous shuttle or AMR executes it. A PLC runs the conveyor or lift. ERP may already have reserved the material, while MES is waiting for it at a production line. If one acknowledgement is lost, a task is retried, or an operator moves the pallet manually, the warehouse can be physically correct and digitally wrong.

That is becoming a more important engineering problem because warehouse automation investment is accelerating in this region. On 23 September 2026, ST Logistics reported an upgraded Singapore warehouse using 14 autonomous shuttles, with storage capacity increased by more than 20% and throughput above 70 pallets per hour. The company also retrained about 40 workers for new software and robotics-related roles. A week earlier, Schneider Electric announced S$25 million of automation and digital investment at its Tuas logistics hub, including goods-to-person automation, robotics and agentic AI.

Malaysia is moving in the same direction. Jabil’s Penang intelligent logistics hub combines automated material handling, roughly 160 autonomous robots, connected systems and an AI/IoT digital-twin layer. MIDA’s Smart Logistics Complex incentive also explicitly pushes warehouses towards Industry 4.0 technology, requiring qualifying facilities to adopt at least three listed technology elements. Applications remain open until 31 December 2027.

These are useful buyer signals. They do not mean every warehouse needs 160 robots. They do mean that WMS integration, controls, traceability and exception recovery are becoming core automation work rather than back-office IT.

Decide who owns each state before writing interfaces

I would not start an automated-warehouse project by drawing the Wi-Fi coverage or choosing the AMR. I would start by defining ownership.

The names vary between vendors, but the responsibilities usually look something like this:

Layer	What it should normally own	What it should not pretend to own
ERP / planning	Commercial orders, purchasing, stock value, demand and supply commitments	Real-time robot motion or conveyor state
MES	Production orders, WIP, material consumption, genealogy, production status	Detailed storage-path planning
WMS	Inventory identity, storage location, allocation, replenishment, pick and put-away logic	Safety interlocks or low-level motion
WCS / WES	Execution of warehouse movements across conveyors, AS/RS, lifts and other material-handling equipment	Financial inventory ownership
RCS / fleet manager	AMR or AGV dispatching, routing, traffic, charging and vehicle availability	Production scheduling
PLC / safety controller	Deterministic equipment sequencing, sensors, actuators, permissives, interlocks and safe stop behaviour	Enterprise stock allocation

If two systems both think they are the authoritative owner of pallet location, or neither system does, the project will eventually become an exception-management exercise.

This is where an integration layer such as CANiS can be useful. The purpose is not to add another database for the sake of it. It is to make the transactions between ERP, WMS, MES and automation explicit, validated and recoverable instead of building dozens of undocumented point-to-point links.

The difficult cases are not normal moves

A demonstration normally shows the happy path: scan pallet, assign destination, move pallet, confirm complete. The real design work is in everything around it.

A message is delivered twice. The receiving system must recognise the transaction ID and avoid creating a second move.
The robot reports success but the upstream acknowledgement is lost. A retry must not make the pallet move twice.
An operator intervenes manually. Physical location and digital location need a controlled reconciliation path.
A pallet is rejected at a scanner. The system needs a quarantine state and a route that does not silently turn bad identity into good inventory.
An AMR is blocked or unavailable. The WMS should not continue promising material to MES as though transport capacity were infinite.
Power returns after an outage. Every layer needs to know which tasks are complete, incomplete, ambiguous or safe to retry.

I would insist on idempotent commands, unique movement IDs, timestamps, explicit state transitions and an audit trail for manual overrides. Those details are much less glamorous than a robot fleet, but they are what let a warehouse restart cleanly at 3 a.m.

Do not confuse inventory state with equipment state

An AS/RS crane can be healthy while the inventory record is wrong. A pallet can be physically present while the WMS considers it in transit. An AMR can be at the correct station while MES is still waiting for material-release confirmation.

For that reason I prefer to keep three state models separate even when they are displayed on the same dashboard:

inventory state — what item, lot, quantity and owner the business believes exists;
movement state — requested, accepted, executing, completed, failed, cancelled or manually reconciled;
equipment state — available, busy, blocked, faulted, maintenance, charging, isolated or safety-stopped.

Trying to collapse all three into one status field creates brittle logic. It also makes troubleshooting difficult because operations staff cannot tell whether a problem belongs to the WMS, the transport system or the machine.

Where MES belongs in the warehouse conversation

In a factory warehouse, material handling is not separate from production. A component shortage, wrong lot, late transfer or quarantine event can stop the line even when the warehouse itself looks efficient.

The MES should therefore exchange enough information with the WMS to align production demand with material availability, but it should not micromanage every vehicle. Typical interfaces include production-order demand, staging requests, material issue and return, lot or serial genealogy, line-side inventory and completion confirmation.

For plants with a digital-twin or supervisory layer such as CansNEXUS, the useful role is cross-system visibility: show where the order is, where the material is, what the automation is doing, and where the exception sits. A digital twin is valuable when it exposes the real operating state. It is not useful if it simply animates a perfect warehouse while operators are resolving mismatched records in spreadsheets.

AI can optimise the warehouse, but keep authority bounded

Schneider’s Tuas announcement includes agentic AI, and that is a reasonable direction for planning and exception handling. AI can help with slotting, wave planning, congestion prediction, staffing, maintenance prioritisation and investigation of recurring delays.

I would still keep the control boundary clear. A general-purpose AI agent should not write arbitrary commands straight into robot controllers, PLC tags or safety logic. Let it recommend a route change, propose a replenishment action or prepare an exception workflow. Execution should pass through a validated interface with known command types, range checks and machine-state checks.

The same rule applies to autonomous logistics as it does to the factory floor: useful AI is not the same thing as unrestricted authority.

Brownfield warehouses need a staged cutover

Most Malaysian and Singapore sites are not greenfield warehouses. They already have ERP, barcode practices, forklift routes, storage conventions and years of human workarounds. Replacing all of that at once is usually unnecessary.

I would stage the work:

clean up item, lot, location and handling-unit identity;
define authoritative system ownership and message contracts;
connect WMS to ERP and, where relevant, MES;
automate one bounded material flow such as pallet put-away or line replenishment;
prove recovery from scanner faults, blocked routes, cancelled orders and power loss;
expand only after the exception rate is understood.

If a manual forklift process already works safely, there is no engineering prize for replacing it with an AMR before the software side is ready. The automation should remove a real constraint: labour exposure, throughput, storage density, traceability, ergonomics or response time.

What I would put in the acceptance test

For a serious warehouse-automation project, factory acceptance and site acceptance should test more than rated throughput. I would include:

duplicate and delayed messages;
temporary loss of WMS, WCS or fleet-manager connectivity;
unexpected pallet or tote identity;
manual relocation and subsequent reconciliation;
vehicle unavailable, charger unavailable and blocked route scenarios;
restart after power interruption;
safe degraded operation;
auditability of operator overrides;
recovery without editing production databases by hand.

If the only acceptance test is “move 100 pallets per hour”, the system has not really been tested.

CANS integration work

CANS works across industrial automation and SCADA, MES, WMS/ERP integration, machine connectivity and higher-level operational platforms. For warehouse projects, that means we can work across the awkward boundary between software transactions and physical equipment instead of treating them as separate contracts.

Discuss a warehouse automation or WMS integration project with CANS or WhatsApp CANS.

References

Featured image: “Fully automated warehouse model” by Pancho507, via Wikimedia Commons, licensed under CC BY 4.0.

Warehouse Automation in 2026: Integrating WMS, AS/RS and AMRs Without Losing Control