AuraBoot
Start free
English简体中文

Manufacturing

Why this is a runtime problem, not a CRUD problem

A manufacturing operation has to coordinate planning, material procurement, scheduling, shop-floor execution, equipment maintenance and quality tracking — often across multiple lines, shifts and product families. Each transition (plan confirmed, BOM exploded, picking issued, work order started, operation reported, finished goods received) is a contract between teams: it has to be permissioned, audited, validated against the routing in effect, and survive engineering changes that arrive mid-shift.

A data-app builder gives you a screen for each table but leaves the cross-step bookkeeping to humans and spreadsheets. A packaged business suite has the modules but treats the BOM resolver, the MRP horizon and the MES dispatch rules as configuration knobs, not as commands you can extend. AuraBoot is the third path: every state transition is a command with declared inputs, permissions and side effects; BOM explosion, material issue and goods receipt are Java handlers attached to those transitions; the same commands are reachable from the UI, from automation, from BPM tasks and — selectively — from agents.

Data model summary

The solution ships as two cooperating plugins. Production (prd namespace) covers the basic order-tracking spine; PCBA Manufacturing (pe_mfg namespace) adds MRP, APS, MES, equipment and IoT. Both depend on product-catalog, inventory and org-management.

  • prd_work_center — machine, manual, assembly or testing station with capacity and cost rate.
  • prd_routing + prd_routing_operation — multi-step operation sequence with setup/run time per work center.
  • prd_production_order — order with full status workflow and auto-generated code PO-{yyyyMMdd}-{seq}; states planned → released → in_progress → completed/cancelled.
  • prd_shop_floor_log — start/stop/output/scrap/downtime/changeover events.
  • pe_production_plan + pe_production_line — plan with BOM reference, quantity and status workflow.
  • pe_material_requirement — MRP-expanded materials with required, available and shortage quantities.
  • pe_mrp_run, pe_planned_order, pe_mrp_exception — MRP execution record, suggestions and warnings.
  • pe_resource + pe_resource_calendar + pe_schedule_result — APS inputs and output schedules.
  • pe_work_order_op + pe_work_report — MES operation instances and operator reporting.
  • pe_equipment, pe_equipment_maintenance, pe_spare_part, pe_eq_downtime — equipment master, maintenance log, spares and downtime tracking.
  • pe_workstation + pe_workstation_assignment — binds operator–shift–line for MES dispatch.
  • pe_production_version — links product to a specific BOM + routing with validity range.
  • pe_iot_device + pe_iot_data_point — sensor, PLC, gateway registry with protocol and thresholds.

Plugins declare their dependencies in plugin.json; the resolver refuses to install pcba-manufacturing without inventory because the start/complete handlers write inbound and outbound documents.

Key commands

The two plugins define roughly 60 commands. Six representative ones cover the command shapes used downstream:

CommandShapeRiskIdempotentWhy it matters
prd:create_production_orderCreatewritetrueAllocates PO-{yyyyMMdd}-{seq} code, initialises status planned, quantities to 0
prd:release_production_orderStateTransitionwritetrueplanned → released; gate for downstream MES dispatch
prd:start_production_orderStateTransitionwritetruereleased → in_progress; captures actual start timestamp
pe:confirm_productionStateTransitionwritetruedraft → confirmed; Java handler explodes BOM into pe_material_requirement children
pe:start_productionStateTransitionwritetrueconfirmed → in_progress; Java handler auto-creates inv_outbound picking document
pe:complete_productionStateTransitionwritetruein_progress → completed; Java handler auto-creates inv_inbound finished-goods receipt
pe:execute_mrpStateTransitionwritetruedraft → running; Java handler computes net requirements and emits planned orders + exceptions
pe:assign_workstationActionwritetrueBinds operator to a workstation for a shift window

A button labelled "Start Production" is wired to pe:start_production — not to a raw PUT /api/pe_production_plan. The same command is reachable from automation ("auto-start plans whose materials are fully picked"), from a BPM task ("Production Supervisor approval"), and — because it declares riskLevel: write, idempotent: true — from an AI agent acting under a supervised plan. pe:cancel_production and pe:complete_production are marked irreversible for the agent surface.

Permission example

A realistic shop-floor role: "Plant Production Supervisor — Line SMT-1".

  • RBAC: granted prd.production.manage, prd.production.execute, pe.mes.manage, pe.workstation_assignment.manage; not granted pe.mrp.manage (held by the planner) and not granted pe.production.version (held by engineering).
  • Org scope: data visibility restricted to plants in the supervisor's org subtree (org-and-descendants); cannot see orders or work reports from sibling plants.
  • ABAC: can start and complete production orders only when prd_po_work_center_id belongs to a work center they own; cannot release production orders whose prd_po_priority = urgent (those require the Production Manager).
  • Field-level: cost-rate fields on prd_work_center and component cost on pe_material_requirement are masked; planned quantity, completed quantity and scrap quantity are visible.

All four layers evaluate in order on every command invocation, every list query and every detail view. The same declarative role definition covers what would otherwise be branching across the React UI, the Spring controllers and the reporting layer.

Process orchestration

The plan-to-finished-goods flow is a BPM process. Each task resolves back to a command:

                ┌───────────────────────┐
                │ Plan drafted          │  ←  pe:create_production_plan
                └──────────┬────────────┘
                           │
                ┌──────────▼────────────┐
                │ BOM explosion + check │  ←  pe:confirm_production
                └──────────┬────────────┘   (Java handler writes
                           │                 pe_material_requirement rows)
                ┌──────────▼────────────┐
                │ MRP + planned orders  │  ←  pe:execute_mrp
                └──────────┬────────────┘
                           │
                ┌──────────▼────────────┐
                │ Material picking      │  ←  pe:start_production
                └──────────┬────────────┘   (Java handler emits
                           │                 inv_outbound)
                ┌──────────▼────────────┐
                │ MES dispatch + report │  ←  pe:assign_workstation,
                └──────────┬────────────┘     pe:report_exception (loop)
                           │
                ┌──────────▼────────────┐
                │ Finished goods inbound│  ←  pe:complete_production
                └──────────┬────────────┘   (Java handler emits
                           │                 inv_inbound)
                ┌──────────▼────────────┐
                │ Close + dashboard KPI │
                └───────────────────────┘

An engineering change mid-run does not break the flow: pe_production_version carries the BOM + routing revision in effect; in-flight work orders keep the version they were started with, and new plans pick up the new one once activated.

Agent integration

Three command classes are intentionally exposed to AI agents in the manufacturing solution:

  1. Read-and-summarize commands (pe:list_overdue_plans, pe:weekly_yield_summary, pe:equipment_downtime_report) — read-only, idempotent, low risk. Agents can call freely.
  2. Drafting commands (pe:draft_planned_order_from_shortage, pe:suggest_maintenance_window) — write, idempotent, reversible. The agent proposes; a human confirms via pe:confirm_planned_order or pe:create_eq_maintenance.
  3. Operational nudges (pe:report_exception) — write, idempotent. An agent watching IoT data points can open an operation exception; it cannot resolve one (resolution stays on the supervisor).

What is not exposed: pe:cancel_production (irreversible), pe:complete_production (irreversible plus financial impact via finished-goods receipt) and prd:delete_work_center (irreversible). These carry agentHint: "Human-only" in their definitions; the agent surface filters them out before the model ever sees them.

How to get it

  • Community: build it yourself. The runtime, command pipeline, BOM models and inventory plugin are open-source. The PCBA Manufacturing handlers (pe:confirm_production, pe:start_production, pe:complete_production, pe:execute_mrp) are reference Java handlers that you can fork.
  • Standard: white-label the base platform; build your own manufacturing-shaped plugins on top.
  • Professional: get the pre-wired Production + PCBA Manufacturing plugin pack with menus, roles, the production dashboard and the MRP dashboard.
  • Enterprise: same pack plus dedicated delivery engineering, MES integration design, IoT protocol adapters (MQTT/OPC-UA/Modbus) and SLA-backed support.

See Pricing for the full edition comparison.

Enterprise note — Marketplace publication of the manufacturing plugin pack, License/Entitlement enforcement on MRP and APS commands, the cross-tenant Agent Control Plane for multi-plant orchestration, and Observability Pro per-stage trace spans on pe:confirm_production → BOM explosion → material issue are commercial-only. The open-core runtime described above is the same in every edition.

Next steps

  • System overview — how plugins, commands and the runtime fit together
  • Command pipeline — the execution contract used by every command above
  • Permissions — the layered model used by the Plant Production Supervisor role
  • Plugin manifest — how the Production and PCBA Manufacturing plugins declare their dependencies
  • Agent readiness — designing agentHint and risk fields for safe execution