Layer 1 — HaiQ platform architecture

The five named subsystems of HaiQ. This decomposition underpins everything else: it determines what Hai owns, what the customer owns, and where every interface sits.

   Customer ERP / WMS / MES
            │  orders, inventory master, receipts
            ▼
   ┌─────────────────────┐
   │  WES                │  order & inventory execution
   │  grouping, splitting│  wave rules, heat strategy
   │  workstation config │
   └──────────┬──────────┘
              │  transport tasks
              ▼
   ┌─────────────────────┐        ┌──────────────────────┐
   │  ESS  (a.k.a. RCS)  │◄──────►│  Algorithm Platform  │
   │  fleet + equipment  │        │  order alloc / task  │
   │  task & resource mgmt│       │  alloc / path / charge│
   └──────────┬──────────┘        └──────────────────────┘
              │  motion & pick commands
              ▼
   ACRs · AMRs · HaiPort · conveyors · pick-to-light · e-stops · guard doors
              │
              ▼  telemetry
   ┌─────────────────────┐        ┌──────────────────────┐
   │  Data Platform      │        │ Simulation Platform  │
   │  analytics, viz     │        │ 1:1 pre-deployment   │
   └─────────────────────┘        └──────────────────────┘

Warehouse Execution System (WES)

What it is. A WES sits between planning systems (WMS/ERP) and control systems (WCS/RCS/PLC). Where a WMS answers what should happen — this order is due, this SKU lives here — a WES answers how and in what order it actually executes right now, given live resource state.

Why it matters here. In a goods-to-person system the WES is what converts a flat list of order lines into a sequence of tote-retrieval tasks with a sensible order, batched to minimise robot trips and keep workstations fed. Get this layer wrong and the robots are busy while the pickers are idle.

Fundamentals.

The classic warehouse stack is WMS → WES → WCS → PLC/device. The boundaries are contested in practice; every vendor draws them slightly differently, and a large part of a solutions architect's job is negotiating exactly where they sit on this project.
Order grouping (combining orders that share SKUs so one tote presentation serves several) and order splitting (breaking one order across workstations or zones, then consolidating) are the two fundamental order-shaping levers.
Wave vs. waveless. Wave planning releases work in batches aligned to cutoffs and carrier departures; waveless (continuous) release smooths flow but makes cutoff guarantees harder. Most real systems are hybrid.
Consolidation is the hidden cost of splitting: if one order is picked at three stations, something downstream must reunite it (put wall, buffer, sorter).

How Hai applies it.

"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

"The system features flexible workstation configuration and operation strategies, such as order grouping, order splitting, wave rule and heat strategy." — /solutions/haiq-software

Note what is named: grouping, splitting, wave rule, heat strategy. Those four are Hai's stated order-shaping vocabulary — use their words.

Tradeoffs and pitfalls.

Deep batching raises robot efficiency and lowers order responsiveness. The objective function is a genuine tension, not a free win.
Splitting orders across stations creates a consolidation problem the customer often has not budgeted floor space for.
A WES that duplicates WMS inventory logic creates two sources of truth. The interesting design question is always which system owns inventory state.

Key terms. WMS · WES · WCS · order grouping · order splitting · wave rule · heat strategy · consolidation · cutoff time · order pool.

Equipment Scheduling System (ESS)

What it is. The fleet layer: it holds the live model of every robot and every piece of peripheral equipment, accepts transport tasks from above, and drives the hardware to completion.

Why it matters here. This is the component that makes a hundred independent robots behave like one system. It owns task lifecycle, resource reservation (aisles, workstation slots, charging bays), and recovery when a robot faults.

Fundamentals.

A fleet manager is fundamentally a resource allocator plus a state machine per task. Tasks move through assigned → travelling → picking → delivering → done, with compensation paths at every step for faults.
Resource reservation is what prevents two robots claiming the same aisle segment or workstation slot. Reservation granularity is the central design decision: coarse is safe but throttles throughput; fine is fast but risks deadlock.
Heterogeneous fleets need a capability model — which robot classes can serve which task types — before allocation can be posed at all.
Peripheral equipment (conveyors, pick-to-light, guard doors, e-stops) is not optional detail: safety interlocks must be in the scheduling model, because a guard door opening has to stop robots, not merely raise an alarm.

How Hai applies it.

"Hai Robotics Equipment Scheduling System (ESS) integrates robots, equipment, and physical environment information into a unified management system, including task management, resource management and other functions." — /solutions/haiq-software

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

"Capable of scheduling over 1000 robots." — /solutions/haiq-software

In at least one deployment this layer is referred to as RCS rather than ESS — see integration.

Tradeoffs and pitfalls.

Centralised scheduling is simpler to reason about and optimise globally, but it is a single point of failure and a scaling ceiling. Decentralised is resilient but hard to make globally optimal or even predictable.
"1000 robots" is a scheduling claim, not a claim about one physical site. Real sites in Hai's own case studies run 3–87 robots.

Key terms. fleet management · RCS · task lifecycle · resource reservation · capability model · interlock · heterogeneous fleet.

Algorithm Platform

What it is. Hai's name for the decision layer — the component that answers the optimisation questions the rest of the system poses.

Why it matters here. Every throughput number a customer is promised comes out of this layer's decisions. It is where a solutions architect's design assumptions either hold or fall apart.

Fundamentals. Four decision problems, treated in depth in layer 2:

Order allocation — which orders go to which workstation, and when.
Task allocation — which robot takes which transport task.
Path planning — how it gets there without colliding or deadlocking.
Charging — when a robot leaves service to charge.

These are coupled. Optimising each greedily in isolation is the classic failure: perfect task allocation that ignores charge state strands robots mid-aisle at peak.

How Hai applies it.

"As the intelligent brain of the HAI Q system, the Algorithm Platform is responsible for the analysis, computation and decision-making of various systematic scenarios." — /solutions/haiq-software

Hai names the four algorithm families but publishes no method for any of them. Do not attribute an approach to them.

Tradeoffs and pitfalls.

Real fleet optimisation is an online problem under uncertainty, not a solved offline one. Anyone claiming a global optimum is describing a simulation.
Objective functions here are multi-criteria (timeliness, efficiency, balance). Ask how they are weighted, and whether the weights are tunable per customer.

Key terms. online optimisation · multi-objective · coupled subproblems · decision layer.

Data Platform

What it is. Telemetry aggregation and operational analytics across the stack.

Why it matters here. For an automated warehouse the data platform is how you prove SLA compliance, diagnose a throughput shortfall, and justify the next capacity expansion. It is also the evidence base for tuning the algorithm layer.

Fundamentals.

Three distinct consumers: real-time operations (seconds — is the system healthy?), operational analytics (hours/days — where is the bottleneck?), and strategic (months — do we need more robots?). They want different latencies and retention, and conflating them produces a system that serves none well.
Useful primitives: robot utilisation, workstation idle time, task queue depth, dwell time per tote, pick rate per operator, charge-state distribution.
Workstation idle time is the metric that matters most in GTP: it is the direct measure of whether the robot fleet is keeping up with the humans.

How Hai applies it.

"The Data platform collects and integrates data from various systems, including WES, ESS, and Robots." — /solutions/haiq-software

Tradeoffs and pitfalls. Dashboards that show robot utilisation without workstation idle time flatter the system: busy robots and idle pickers is a failure mode, not a success.

Key terms. telemetry · utilisation · idle time · dwell time · queue depth.

Simulation Platform

What it is. A model of the proposed warehouse, driven by the customer's real map, order profile and inventory, used to verify a design before it is built.

Why it matters here. This is the tool a solutions architect actually drives. It is how you answer "will this hit 1,500 cases/hour?" with evidence rather than a spreadsheet extrapolation — and how you avoid selling a system that cannot.

Fundamentals.

Discrete-event simulation is the standard technique: model the system as events (robot arrives, fork extends, tote delivered) on a timeline, run with realistic stochastic inputs, measure the distribution of outcomes.
Garbage in, garbage out. Simulation quality is bounded by input quality: order profile (lines/order, SKU affinity), demand seasonality and peak shape, SKU velocity distribution (usually heavily Pareto), and the real travel/pick time distributions.
Simulate the peak hour, not the average. A system sized on averages fails on Black Friday, which is exactly when it is being judged.
Report distributions, not point estimates: p95 order cycle time is far more useful to a customer than a mean.

How Hai applies it.

"The Simulation Platform creates a virtual warehouse by inputting map files, order files, inventory files, and demand configurations." — /solutions/haiq-software

"By incorporating the actual customer scenario's demand parameters, the platform conducts a 1:1 simulation." — /solutions/haiq-software

"the project plan is swiftly verified, and strategies and on-site configurations are promptly adjusted" — /solutions/haiq-software

Hai also markets a customer-facing Virtual Warehouse and a Solution Generator. Note the vocabulary: they do not use the term "digital twin" anywhere on the site.

Tradeoffs and pitfalls.

A 1:1 simulation validated against a single order file proves the design works for that day, not for the contract's peak.
Simulation cannot model what it does not represent: operator variability, induction errors, replenishment shortfalls and network faults are commonly omitted and commonly the real bottleneck.

Key terms. discrete-event simulation · order profile · SKU velocity · Pareto/ABC distribution · peak-hour sizing · p95 cycle time · Virtual Warehouse.

Service-oriented, modular architecture

What it is. HaiQ is presented as an in-house, modular, service-oriented platform rather than a monolith or a per-customer fork.

Why it matters here. Warehouse automation is a project business: every customer wants something slightly different. The architecture question is whether variation is absorbed by configuration or by code forks — the latter is how automation vendors accumulate unmaintainable per-customer branches.

Fundamentals.

Configuration over customisation is the survival strategy in project-based software. Every capability expressed as config is one that does not fork.
Modular boundaries should follow the deployment reality: WES, ESS and the algorithm layer have genuinely different change rates and availability needs.
The counter-pressure is real: customers pay for bespoke behaviour, and sales will promise it. The architect's job is to route that pressure into the configuration surface.

How Hai applies it.

"Modular in-house developed software environment easily adapts to any changes in your business" — /solutions/haiq-software

"allowing for flexible field configuration to meet various docking requirements" — /solutions/haiq-software

Tradeoffs and pitfalls. "Service-oriented" on a marketing page says nothing about service granularity, deployment topology, or failure isolation. Nothing in the corpus describes any of these — treat the claim as a positioning statement and ask what it means concretely.

Key terms. SOA · configuration over customisation · variation point · project-based software · fork debt.