Inside simpliMES: How One Django Core Runs Discrete and Batch Manufacturing on the Same Engine

September 7, 2026

Every manufacturing digitalization conversation eventually runs into the same wall: the ERP knows what should be made, the machines know what’s actually happening, and nothing in between is translating one into the other in real time. That gap is exactly what a Manufacturing Execution System exists to close — ISA-95 calls it Level 3, sitting between Level 4 planning systems and Level 1–2 shop-floor control.

simpliMES is Simplico’s answer to that gap: a single, on-premise MES core built to run discrete manufacturing (machining, assembly, packaging) and batch processes (heat-treat, chemical, process) through the same data model and the same execution engine, rather than bolting one onto the other. This post walks through what’s actually built — architecture choices, the operator experience, data collection, and the one AI feature in the system — and is explicit about what’s shipped today versus what’s still on the roadmap.

1. What simpliMES actually is

  • ISA-95 Level 3. It takes work orders from Level 4 — an ERP handling planning, purchasing, and finance — and drives execution against Level 1–2 equipment: PLCs, instruments, SCADA.
  • One stack per site, on-premise. Each factory runs its own Docker Compose stack. No cloud dependency, no multi-tenant SaaS — the shop floor keeps working if the internet doesn’t.
  • A product, not a one-off project. The ERP is reached only through a connector contract, so ERPNext, SAP, Odoo, or a CSV drop are all just different connectors. No ERP-specific assumptions leak into the core.
  • Discrete and batch in one model. Machining, assembly, and packaging run through the same WorkOrder and step model as heat-treat, chemical, and process batches. One run engine drives both.

This sits alongside two other things Simplico builds in the same space, and it’s worth being clear about the boundary: simpliMES Lite is a lighter, faster-to-deploy package aimed at SMEs starting their first digitization step, and simpliFactory‘s IMCS/simpliInterface layer solves measurement routing and shop-floor connectivity specifically. simpliMES is the full execution-and-traceability core for plants that need work-order dispatch, genealogy, and multi-protocol equipment integration in one system. Simplico’s MES Development service is where a simpliMES engagement is actually scoped and priced.

2. Architecture: the decisions that shape everything else

Choice Why it matters
Modular monolith One deployable core app (Django), with hard internal module boundaries — modules talk only through published service functions and an in-process event bus, never by importing each other’s models directly. Simple to run, still clean to change.
Edge I/O is a separate process Equipment communication runs in a standalone async service (the connector), isolated from the web app’s lifecycle. Restart the UI without dropping a single reading.
Store-and-forward at the edge Every reading is written to a local disk spool before any publish attempt. If the broker or core is down, readings pile up on disk and replay in order when connectivity returns. Ingest is idempotent, so replay is safe. Lost production data is a design constraint, not a hope.
DB-managed connector config The core is the single source of truth for what each connector polls. Add a tag in the UI, and a background job republishes the full config to a retained MQTT topic; the connector hot-reloads its drivers with no restart. The connector also caches config to disk so it can start while the core is offline.
One data model, two execution paths A work order’s mode is discrete or batch. Releasing it generates steps from a routing (discrete) or a process spec (batch). The same run engine drives both; batch runs additionally check live telemetry against spec limits.
Telemetry-to-work-order stitching by time There is no foreign key from a sensor reading to a run. A reading is associated to a run by a time-range query anchored on the run’s start and end events — a design that survives replay and clock skew cleanly.
flowchart TD
    ERP["ERP Level 4 planning"]
    CORE["simpliMES core Django domain logic"]
    MQTT["MQTT broker Mosquitto"]
    CONN["Connector process asyncio edge IO"]
    TS["TimescaleDB tag samples"]
    PLC["PLC and instruments OPC UA S7 Modbus"]

    ERP -->|"work orders"| CORE
    CORE -->|"results and sync log"| ERP
    CORE -->|"published config"| MQTT
    MQTT -->|"config hot reload"| CONN
    CONN -->|"readings"| MQTT
    MQTT -->|"tag events"| CORE
    CORE --> TS
    CONN --> PLC
    PLC --> CONN

Four processes make up a site: core (Django — UI, API, domain logic), connector (asyncio — equipment I/O), a Celery worker, and an MQTT consumer. Infrastructure is PostgreSQL + TimescaleDB, Redis, and Mosquitto. Core and connector communicate only over MQTT — never a direct API call — which is what lets either one restart independently.

3. Work orders and dispatch

Work orders come in from the ERP or get created by hand. Releasing one generates its steps from the item’s routing and operations (discrete) or its process spec (batch). A dispatch board shows released work sequenced to work centers, and steps promote automatically — finishing one readies the next, and the work order completes when the last step does.

4. The operator terminal: a kiosk, not a shrunk-down desktop screen

A chromeless, touch-friendly kiosk sits at /execution/terminal/, deliberately separate from the staff UI:

  • The terminal binds once to a workstation; operators identify by badge or an operator-code-plus-PIN per shift.
  • The flow is pick a job and a machine, then start → report quantity or scrap with a reason → pause or resume → complete. Every tap posts to a service and re-renders one panel — no page navigation mid-task.
  • For batch runs, the panel shows live process parameters against spec limits — soak temperature, door state, and similar — pulled from the machine’s telemetry during the run.
  • Every action is transactional, writes an audit entry, and publishes a domain event, with full attribution: which operator, which workstation, which run.

5. Automated data collection, three protocols deep

  • Three industrial protocols, live today: OPC-UA, Siemens S7, and Modbus TCP/RTU. Each driver normalizes to a common tag model — a reading with equipment, tag key, source timestamp, numeric or text value, and quality.
  • Readings land in a TimescaleDB hypertable, keyed on tag and time.
  • Manual entry covers equipment with no digital interface.
  • Downtime capture with reason codes drives the machine’s live state and feeds the OEE-style dashboards.

This is the same protocol-fragmentation problem we’ve written about separately — most shop floors genuinely speak five dialects at once, and simpliMES’s edge connector is one of the two places (alongside simpliFactory’s simpliInterface) where Simplico actually builds the bridging layer that problem calls for.

6. Equipment: hierarchy, live state, and a floor plan you can actually use

  • Hierarchy follows ISA-95 — site, area, line, cell, unit — described in plain English rather than pure standard-speak.
  • A live status board shows every machine’s current state (running, idle, down, setup), grouped by area and connector, auto-refreshing.
  • Live state is event-driven, not polled: a run starting flips a machine to running, ending flips it to idle, a downtime opening flips it to down (with its reason), and closing returns it to running if a run is still active. The equipment module maintains this purely by reacting to execution events on the bus.
  • A floor plan shows where each machine physically sits, colour-coded by live state. Engineers place machines by dragging them in an edit mode; positions are saved as an audited coordinate on the equipment record.
  • Calibration and maintenance cover generic calibration records with due dates, a maintenance event log, and per-machine reference documents — manuals, spec sheets — with text extraction.

7. Genealogy and traceability — partially shipped, and we say so

The data model for material lots and serials, consumption records (what a work order consumed), and parent-to-child lot links is built — it’s the backbone for as-built traceability of a work order or batch back to the material and equipment it used. What’s still being wired for the next release is the automatic link creation on run completion, plus the forward and backward trace UI and the full trace report. If your evaluation depends on pulling a complete genealogy report today, that’s the one piece worth asking about directly before signing off on scope.

8. AI Analyze: a local-LLM panel, entirely optional, entirely on-prem

An "AI Analyze" panel appears on the run-detail, downtime-detail, equipment-detail, and fleet-wide calibration pages:

  • It builds a compact structured summary for whatever it’s looking at — per-tag telemetry statistics, spec-limit breaches, state and downtime and production events, excerpts from uploaded reference documents — and never sends raw samples.
  • That summary goes to a local Ollama model (the default is a small 3B-parameter model). The work runs as a background task and is cached; the panel polls until it’s ready.
  • It is entirely optional and entirely on-premise — no data leaves the site, and if the local model endpoint isn’t reachable, the button simply doesn’t appear.
  • It’s steerable two ways: an operator can add a free-text focus note ("why did scrap spike?"), and an equipment’s uploaded manuals are fed in as ground truth the model is told to trust over its own general knowledge.

This is the same architectural pattern we described for reading factory-floor logs with a local model over on the simpliSOC side — a small on-prem model reading structured context and producing a plain-language summary, advisory only, nothing written back to equipment. simpliMES’s AI Analyze panel is that pattern shipped inside the MES itself, scoped to runs, downtime, and calibration rather than security alerts.

9. ERP integration: a connector contract, not an ERP-shaped core

  • A single connector contract (ErpConnector) is the only way an ERP touches simpliMES; implementations self-register. ERPNext is the reference implementation, and a generic REST connector ships alongside it.
  • A scheduled pull drives a connector and upserts through the masterdata and dispatch services, writing one sync-log row per entity — so a failed sync on one item never hides inside a batch-level success message.
  • An ERPNext webhook endpoint accepts Work Order events, authenticated with a constant-time shared token.
  • Field-map assumptions that still need a specific customer’s confirmation are marked directly in code and listed in the connector spec — not left implicit.

10. Reporting, two web experiences, and settings you can change live

  • Batch and quality certificates render as PDF in a background task.
  • In-app dashboards built with server-rendered HTMX cover four tiles: production (work-order status, active runs, due/overdue), equipment (running/idle/down donut, current downtime), today (good/scrap, downtime by reason), and attention (overdue calibrations, sync errors, stuck work orders).
  • Metabase ships as a separate container against a read-only database role, for the ad-hoc BI that a fixed dashboard set can’t anticipate.
  • Two distinct web experiences serve two audiences: a staff shell — left-nav, server-rendered, role-filtered navigation with a tooltip on every item — and the operator kiosk described above, reachable without a staff login.
  • A live-editable settings page covers the AI Analyze model, URL, and timeout, site identity, and whether equipment or tag changes auto-publish connector config — all without a redeploy.

11. What’s in v1, and what’s deliberately deferred

Being precise about this matters more than any individual feature, because a roadmap item quoted as a current capability is the fastest way to lose a plant’s trust mid-implementation.

Shipped in v1: work-order dispatch and execution for both discrete and batch, automated data collection across three protocols plus manual entry and downtime capture, the full equipment hierarchy with live state, floor plan, calibration, and maintenance, basic genealogy and consumption tracking, batch certificates, the in-app dashboard set, ERPNext and generic-REST integration, and the local-LLM AI Analyze panel.

Deferred to a later release: the forward/backward trace UI and full trace report, file/CSV and REST-webhook ingest for data collection, in-process quality checks, non-conformance and hold workflows, the full OEE dashboard suite, standard-specific compliance packs (AMS2750, CQI-9 pyrometry), SPC, multi-site aggregation, and finite-capacity scheduling.

FAQ

Does simpliMES do full forward and backward traceability today?
The underlying data — lots, serials, consumption, parent-to-child links — is captured today. The trace UI and the full trace report that query it are still being built and are scheduled for the next release, not the current one.

Does the AI Analyze panel ever act on equipment or change a setpoint?
No. It reads structured summaries and produces text — a plain-language explanation and, where relevant, a suggested focus area. It never writes to a PLC, never adjusts a setpoint, and never auto-closes anything. A human reads it and decides.

Can simpliMES run without an ERP connected at all?
Yes. Work orders can be created by hand inside simpliMES; the ERP connector is additive, not a hard dependency for day-to-day execution.

Does simpliMES include SPC or full OEE out of the box?
Not yet. OEE-style views exist today through the dashboard tiles and equipment live-state tracking, but the full OEE dashboard suite and statistical process control are on the deferred list for a later release.

12. Simulators and how a plant actually gets to a demo

The repository ships device simulators — an OPC-UA furnace, a Modbus press, an S7 tempering furnace — each driving its values through a shared registry that eases toward targets with realistic noise, plus a web control panel with manual per-signal override and per-device scenario buttons (heat, soak, cool, jam, overheat). An autopilot mode runs the whole simulated floor through realistic scenarios for a set duration and then parks everything at rest — useful for a demo, a training session, or a sales call that needs a live system without a live plant behind it.

13. Deployment and stack, for the people who’ll actually run it

One Docker Compose stack per factory site: core, connector, worker, MQTT consumer, PostgreSQL/TimescaleDB, Redis, Mosquitto, Caddy, and Metabase. Caddy terminates TLS and reverse-proxies; the connector caches its config and spools readings to disk, so a site survives the core being down for maintenance without losing data.

Layer Choice
Core app Python 3.12, Django 5, Django REST Framework
Edge connector asyncio, OPC-UA/Modbus/S7 client libraries, local SQLite spool
Messaging MQTT (Mosquitto) — the only channel between core and connector
Time-series PostgreSQL + TimescaleDB hypertables
Async work Celery + Redis, with scheduled jobs for periodic tasks
Local LLM Ollama, optional, on-premise
UI Server-rendered Django templates + HTMX, no CDN, no JS framework
Reports PDF generation, Metabase for BI

14. Where this fits into an actual engagement

simpliMES isn’t a shrink-wrapped SKU — it’s scoped per plant, and Simplico’s MES Development service lays out the tiers, the pricing bands, and a week-by-week pilot roadmap for exactly this kind of build. If your floor is already mixed-protocol and mixed-vintage — the five-dialects problem — that’s precisely the edge-layer scope simpliMES is built to absorb.

Reach the team at hello@simplico.net, by phone or WhatsApp at (+66) 97 496 6397, or on LINE at iiitum1984.


Sources:

Ready to talk about your project?

Share goals and constraints. We'll assemble architects and engineers to move fast with you.

Get in touch