-
-
Notifications
You must be signed in to change notification settings - Fork 0
Reporting
Reporting is its own collapsible section in the sidebar. Reports are grouped by operational domain. History accumulates from the deployment day (daily counters/snapshots); time windows fill progressively.
Covers scan-point quality and conveyor traffic.
| Report | Detail |
|---|---|
| Scan quality | Scans, no-reads, and unknowns per scan point per day. Scan points with historically high error rates are flagged automatically. Live — GET /api/flow/reports/scan-quality. |
| Traffic heatmap | Conveyor edge traffic overlaid on the live 3D topology scene (edges coloured by relative throughput). Live — GET /api/flow/reports/traffic. |
| Throughput per scan point | Current and historical pieces per hour per scan point. |
| Transit-time distribution | p50 / p95 induct-to-arrival per day, derived from the HU transport trace. Live — GET /api/flow/reports/transit-times. |
| Recirculation rate | Per sorter / divert per day — percentage of totes that loop back rather than leaving the zone. |
Covers device-level workload and utilisation across all equipment families.
| Report | Detail |
|---|---|
| Task throughput + failure rate | Completed vs. failed tasks per equipment per day. Live — GET /api/flow/reports/device-movements. |
| Utilisation proxy | Active-task time share per equipment family (conveyor, shuttle, crane, AMR, etc.). |
Covers automated storage density, movement history, and device-level throughput.
| Report | Detail |
|---|---|
| Storage density | Occupied vs. total slots in figures and %, with 90-day history and a 14-day dashed forecast. |
| Movement heatmap | Rack cells coloured by movement count overlaid on the 3D twin scene; history and forecast view. STORE/RETRIEVE completions per storage location per day — GET /api/flow/reports/storage-movements. |
| Movements per device | Put / retrieve counts per shuttle, crane, or equivalent ASRS device per day. |
Forecasts use a weekday-seasonal moving average (simple and explainable); they appear as a dashed continuation of the history line.
| Report | Detail |
|---|---|
| Stock per SKU | Single-quantity view per SKU split into available, allocated, and unavailable. |
Related: Inbound and Inventory.
| Report | Detail |
|---|---|
| Expected inbound | Orders received by the host but not yet physically in stock. |
| Active inbound | Started vs. in-progress ASNs. |
| 90-day history | Total inbound quantity per day for the trailing 90 days. |
| Peak profile | Last 90 days compiled into an hour-of-day heat strip to expose recurring arrival peaks. |
| Report | Detail |
|---|---|
| Expected outbound | Orders received but not yet released for picking. |
| Active outbound | Released orders: started vs. in-progress. |
| 90-day history | Total outbound quantity per day for the trailing 90 days. |
| Peak profile | Last 90 days compiled into an hour-of-day heat strip to expose recurring dispatch peaks. |
| Report | Detail |
|---|---|
| Station throughput | Cycles and puts per hour per GTP station. |
| Queue depth over time | Pending presentations queued at each station. |
Related: Goods-to-Person Stations.
- History window — counters and daily snapshots accumulate from the deployment date; 90-day windows fill progressively and show whatever data is available until the window is complete.
- Forecasting — 14-day outlook uses a weekday-seasonal moving average; rendered as a dashed line continuing the history series. Method is intentionally simple and explainable to operators.
- Heatmaps — reuse the existing 3D digital-twin scene: conveyor edges are coloured by traffic intensity, ASRS rack cells by movement count. See Hardware Visualisation.
-
Live reporting counters —
scan_stat(scans / no-reads / unknowns per scan-point + day) andedge_traffic(ROUTE answers per directed edge + day) are written by an atomicINSERT … ON CONFLICTupsert insideRoutingService.decide(); a counter failure warns and never breaks the scan answer. Storage movements (completed STORE/RETRIEVE perlocationId) and device-task throughput/failures aggregate fromdevice_taskon request. Transit times derive from INDUCTED → ARRIVED pairs inhu_transport_tracewith p50/p95 computed in Java. All five endpoints requireDEVICE_VIEW; query params:warehouseId(required) +days(default 90, max 180).
Related: Transport Overview · Hardware Visualisation · Inbound and Inventory · Outbound Flow.
openWCS — open-source Warehouse Control System · summarized from build.md & docs/AS-BUILT.md (the repo docs are authoritative).
Design
Flows
- Areas
- Inbound and Inventory
- Slotting and Replenishment
- Goods-to-Person Stations
- Outbound Flow
- Equipment Integration
- Transport Overview
- Process Designer
- Mobile Process Designer
- Hardware Visualisation
- Host Integration
Reporting & Dashboards
Operations