Hai Wiki
home / knowledge / 03-integration.md

Layer 3 — Host integration and system boundaries

This is the crux layer for a Software Solutions Architect. Everything else is context for the question that actually decides a deployment: where does the vendor's system stop and the customer's begin, and how is that line defended?

ERP / WMS / MES upstream integration

What it is. Connecting HaiQ to the customer's existing planning systems so that orders flow down and confirmations flow back.

Why it matters here. No warehouse replaces its ERP to install robots. The automation is always the newcomer in an existing system landscape, and it must adapt. Integration effort, not robot capability, is what most often delays a go-live.

Fundamentals.

  • What actually crosses the boundary, in nearly every project:
    • inbound: purchase orders / ASNs, receipts
    • outbound: sales orders, order lines, priorities, cutoffs
    • master data: SKU dimensions, weights, container mapping
    • inventory: stock levels, adjustments, cycle-count results
    • status: task confirmations, exceptions, shortfalls
  • Integration styles, in rough order of modernity: flat-file drop (still very common in logistics), database table polling, SOAP, REST, message queue (AMQP/Kafka/MQTT), and event streaming. Logistics runs older than you expect.
  • Idempotency and replay are non-negotiable. Networks fail mid-order; every message must be safely re-sendable, which means stable business keys and de-duplication on receipt.
  • The inventory-truth question. Two systems both believing they own stock levels is the classic root cause of a failed integration. Decide explicitly: the host owns logical inventory, the automation owns physical location within its own footprint, and reconciliation runs on a defined cadence.
  • Master-data quality is the usual silent killer — wrong SKU dimensions mean totes that do not fit, discovered at go-live.

How Hai applies it.

"We have experience in implementing projects with well-known ERP and WMS vendors, allowing for flexible field configuration to meet various docking requirements." — /solutions/haiq-software

"HaiQ Software integrates with nearly any existing WMS or WES, no matter the complexity." — /solutions/system-features

"Hai Robotics Warehouse Execution System (WES) is a smart system that seamlessly interfaces with upstream systems such as ERP, WMS, MES and supports operations such as outbound, inbound, inventory check, stock consolidation and material handling." — /solutions/haiq-software

MES is named alongside ERP and WMS — that is a manufacturing signal, and it matches the automotive and electronics case studies where the system does line-side delivery rather than order fulfilment.

⚠️ Nothing in 147 pages names a protocol, message format, or API style. "Flexible field configuration" and "docking requirements" is the full extent of what is published. Do not assert REST, MQTT or anything else on their behalf — and do ask about it.

Tradeoffs and pitfalls.

  • "Integrates with nearly any WMS" is a sales claim about possibility, not effort. The architect's question is always: how many days, and who writes the adapter?
  • Field-level configurability without a versioned interface contract produces per-customer configurations nobody can regression-test.

Key terms. ERP · WMS · MES · ASN · idempotency · replay · business key · reconciliation · master data · adapter · interface contract.

RCS / WCS responsibility split

What it is. The division of authority between the customer's warehouse control system and Hai's robot control system.

Why it matters here. This is the single most valuable thing in the entire corpus. One case study states the boundary outright, which gives a concrete, citable integration pattern to reason from.

Fundamentals.

  • Three plausible boundary positions, and the architect's job is to pick one deliberately:

    Pattern Customer owns Hai owns When it fits
    Hai-led ERP/WMS only: orders in, confirmations out WES + ESS: all execution logic Greenfield, no existing WES, customer wants turnkey
    Shared WMS + WCS: task sequencing across all equipment RCS: robot scheduling within its zone Existing automation, multi-vendor floor
    Host-led Everything down to task level Robot motion only Sophisticated integrator, Hai as subsystem

  • The deciding question is who owns the task queue. Whoever sequences tasks owns throughput, and therefore owns the SLA. Never accept accountability for a number you do not control the inputs to.

  • Multi-vendor floors force the shared pattern: if conveyors, sorters and ACRs come from three vendors, something above all of them must sequence.

How Hai applies it.

"HAIPICK robots are scheduled by HAIQ software platform RCS" — /cases/uk-cross-border-ecommerce-warehouse-project

The same sentence continues that tasks are arranged by the customer's WCS — a textbook shared pattern, and the case reports it improved system performance.

"Improved picking accuracy through WMS and WCS coordination" — /cases/premium-beauty-brand

Note also that Hai works through systems integrators — the corpus contains integration-partner cases (Inteq/Invar in the UK, LYL Ingeniería in Spain, Milestone Projects). In those, Hai is a subsystem inside someone else's architecture, which forces the shared or host-led pattern.

Tradeoffs and pitfalls.

  • Splitting the task queue across two systems without a single throughput owner is how projects end in mutual blame. Insist on one accountable party per metric.
  • Latency across the boundary matters: if the customer's WCS sequences tasks, its round-trip time is inside your robot's idle loop.

Key terms. RCS · WCS · task queue ownership · systems integrator · turnkey vs. subsystem · SLA accountability · boundary latency.

Peripheral equipment and PLC-level integration

What it is. Driving and interlocking the non-robot equipment: conveyors, pick-to-light, workstations, guard doors, emergency stops.

Why it matters here. A warehouse is not just robots. The ACR system lands in a building full of existing control-level equipment, and safety devices in particular must be inside the control model.

Fundamentals.

  • PLCs (programmable logic controllers) run deterministic scan cycles and are the standard for machine-level control. They are a different world from application software: ladder logic / structured text, hard real-time, and safety ratings.
  • Safety-rated vs. functional signals. An emergency stop is not an application message; it is a hard-wired or safety-bus signal with a certified integrity level (see safety). Never route a safety function through the same path as a status update.
  • Common protocols at this level: OPC-UA, Modbus, PROFINET, EtherNet/IP. (General knowledge — Hai names none of these.)
  • Handoff points are where most physical integration bugs live: the ACR-to- conveyor transfer, the workstation put wall, line-side delivery to production.

How Hai applies it.

"Integrated with HaiPick, HaiPort, HaiFlex, conveyors, pick to light system, emergency stop switches, guard doors, etc." — /solutions/haiq-software

"Experience with WMS, WCS, PLC (Digitally Operated Electronics) or other control level software preferred." — /join-us/recruitment/solution-engineer

"Knowledge of WMS integration and PLC" — /join-us/recruitment/field-application-engineer

"HaiPick Systems deliver containers for manufacturing, kitting, and other processes through lineside delivery, conveyor systems, or other technology handoff points." — /solutions/system-features

PLC knowledge is named in two separate job descriptions. Take the hint: this is expected of the solutions side, not just the controls engineers.

Tradeoffs and pitfalls.

  • Treating a guard door as an application-level event rather than an interlock is both a safety failure and a certification failure.
  • Conveyor handoff rates must match robot delivery rates or you build a buffer you did not plan for.

Key terms. PLC · interlock · safety circuit · OPC-UA / Modbus / PROFINET · pick-to-light · put wall · line-side delivery · handoff point.

Heterogeneous robot fleet scheduling

What it is. One scheduler driving several robot classes with different capabilities in a shared space.

Why it matters here. HaiPick System 3 is explicitly a two-class design — ACRs for vertical work, AMRs for horizontal transit. Understanding why means reading the physics of the system rather than the marketing.

Fundamentals.

  • Specialisation beats generality when the two motions have different optima. A robot optimised to climb 12 m is heavy and slow horizontally; one optimised for 4 m/s transit cannot climb. Splitting the roles lets each be optimal.
  • The cost is a handoff: every tote now transfers between machines, adding a transfer time and a failure mode that a single-robot design does not have.
  • Scheduling a mixed fleet needs a capability model (which class can do which task) plus rendezvous planning (both machines at the same place at the same time). Rendezvous is genuinely harder than either alone.
  • The economic argument: ACRs are the expensive asset. If a cheap fast AMR does the horizontal running, each ACR spends more of its time doing the thing only it can do. That is a utilisation-of-the-scarce-resource argument, and it is the right way to frame the design.

How Hai applies it.

"HaiPick Robots excel at vertical movement, picking and storing totes up to 12 meters high, in triple-deep configurations, and handling loads up to 50 kg." — /solutions/haipick-system-3

"Companion AMRs excel at horizontal movement, quickly transporting these totes between workstations and racks at speeds of up to 4 m/s." — /solutions/haipick-system-3

"Mixed scheduling of multiple types of AGVs, such as scheduling HaiPick, HaiFlex." — /solutions/haiq-software

"Multiple devices work in parallel to complete related tasks, reducing mutual waiting." — /solutions/haiq-software

That last quote is Hai naming the rendezvous problem in their own words: reducing mutual waiting is exactly the cost of a multi-class design.

Real deployments mix classes explicitly — 32 A42 + 8 A42T at one 3PL site, 30 A42

  • 3 A42T at a retailer.

Tradeoffs and pitfalls.

  • Each handoff is a queue. Two queues in series amplify variability.
  • Mixed fleets complicate spares, training and maintenance — a real operational cost the customer feels but the design review often ignores.

Key terms. heterogeneous fleet · capability model · rendezvous · handoff · scarce-resource utilisation · AGV vs. AMR vs. ACR.