One platform covering the ground between your controls and your ERP: it watches the machines, records what was produced, tells people when something needs attention, and keeps the paperwork that proves it.

Who it is for

Most of this platform is table stakes done properly. These ten are the things customers tell us they did not find elsewhere — and every one of them exists because a plant got burned by the alternative.

PulseMQ is switched on a machine at a time. Every capability below is a card on that machine's Features tab: turn it on, and its own configuration tab appears. Nothing you do not use is in anybody's way.

Which features a machine can have

A machine's production mode is set once, at creation, and it decides which execution model is on offer. The rest are available to every machine.

The screens people leave open all day. State, rate, output and alarms for every machine in the building, updating as the machines change — not on a refresh button.

What you are looking at

Making it yours

Configurable widgets

Each machine dashboard is built from widgets — OEE summary, process value cards, active job, availability timeline, alarm list, maintenance counters — arranged and saved per machine.

Status your way

Machine state can come from a single boolean tag (with inverted logic if that is how the PLC was wired) or from a multi-state word, each value given its own label, colour and running or stopped meaning.

Light and dark

A dark theme for control rooms and night shifts, a light theme for offices, chosen per user.

Installs like an app

The dashboard installs to a tablet or panel PC home screen and opens full-screen without browser furniture.

Every stop is detected from the machine itself and timed to the second. The question that follows — why — is where the platform asks for a human.

Detecting the stop

Automatic stop detection

State changes are captured as they happen and held as a timeline. No one has to notice a stop for it to be recorded.

State vocabulary

Each state value on the machine is given a name your plant recognises, a colour, a category and whether it counts as running — so "Ready" and "Starved" stop being lumped together as "not running".

Explaining the stop

Planned versus unplanned

Downtime is split by category, so changeovers and scheduled maintenance do not score against availability the way a breakdown does.

Downtime analysis

Stops ranked by duration and frequency across a date range, machine set or shift — the Pareto that tells you which fix to fund.

Reason coding

An operator-facing prompt to classify a stop against your own reason-code list, so the record carries a cause and not just a duration. Rolling out — see section 22.

Offline versus stopped

A machine that has stopped talking is shown as offline, distinctly from a machine that is present and idle. The difference matters and the platform never blurs it.

Production performance monitoring: Overall Equipment Effectiveness with production metrics, shift targets and analytics — calculated continuously from machine signals rather than reconstructed from a clipboard at the end of the shift.

The three factors

Three production modes, three ways of measuring

Setting the targets

Targets and baselines

Ideal cycle time, ideal line speed, target output per shift, standard shift length and a target percentage for each factor — each set as a fixed value or read live from a PLC tag when the product changes the target.

On the screen

OEE Dashboard

A dedicated screen per machine: the headline number, the three factors, target versus actual, and the trend behind it.

KPI strip

A compact banner of the numbers that matter, sized for a wall display above the line.

Factor spider chart

Availability, performance and quality against target on one radar — the fastest way to see which leg is short.

Availability timeline

A running band of state changes across the shift, so a forty-minute gap is something you can point at rather than infer.

Hierarchical OEE

With ISA-88 equipment modules enabled, OEE rolls up through the equipment hierarchy rather than stopping at the machine.

Over time

Shift capture

At every shift boundary the shift's OEE and its component numbers, downtime, running time and counts are written to history automatically, on your shift calendar and time zone.

Loss waterfall

Planned time stepped down through each category of loss to the good product that actually came out — the chart that starts improvement conversations.

OEE heatmap

Machines down one axis, days or shifts across the other, so a pattern that repeats every Monday night stops hiding inside an average.

Alarm detection, severity levels and notification routing to users. Catch the problem while it is still small, and put it in front of the one person who can do something about it — not in a mailbox everybody ignores.

The cycle, end to end

What is standing right now

Active alarm view

Standing alarms per machine, colour-coded by severity, with the value that tripped them and how long they have been up.

Alarm history

A searchable record of every alarm event with duration, machine and resolution — the source for reliability analysis.

Finding the pattern

Alarm analytics

Frequency by alarm and machine, occurrences over time, and a bubble view weighing how often an alarm fires against how long it stays up. Nuisance alarms separate themselves from real ones.

Stale alarm cleanup

When a machine goes offline mid-alarm, open alarms are re-evaluated rather than left standing forever.

Reaching the right person

Notification schedules

Shift-aware routing: the night alarm goes to the night contact.

Test before you trust

Fire an alarm deliberately from the configuration screen to prove the whole path — condition, routing, delivery — before you rely on it.

Auxiliary equipment alarms

Alarms from supporting equipment monitored at the edge — saws, pumps, dust collection — surface in the same list as machine alarms.

Plants do not all make things the same way, so PulseMQ carries three execution features and lets each machine use the one that matches it — with ISA-95 work orders sitting above all three.

ISA-88 Equipment Modules

Equipment hierarchy and PackML states. For processes that make a defined quantity to a recipe: the MES owns the recipe and downloads it to the equipment. On a continuous machine the same toggle is offered as ISA-88 Hybrid Mode.

Equipment hierarchy

Equipment modules configured to the ISA-88 / IEC 61512 hierarchy, each with its own signals and material tracking, and hierarchical OEE calculated up the tree.

PackML state tracking

The full 18-state PackML model read back from the equipment, per machine and per phase.

Master recipes

Versioned recipes with phases, parameters, material requirements, expected outputs and linked maintenance requirements. Searchable by name, code or product.

Recipe lifecycle

Draft, review, approved, active, obsolete — with a status history that records who moved it and when.

Approval signatures

Recipe approval and material disposition can require an electronic signature: a stated meaning, the signer's password re-verified at the moment of signing, an unbroken hash chain over the record, and separation between the person who authored and the person who approves.

Import and export

Recipes move between sites and systems as JSON. Duplicate an existing recipe as the starting point for a new one.

Dispatch to the machine

Pick recipe, machine and parameters; the control recipe is frozen at dispatch, so a later edit to the master cannot rewrite history. Pre-batch maintenance is checked, with a supervisor override that is recorded.

Batch queue

Queued, ready, running, held, completed and aborted batches per machine, with scheduling, priority and a queue tab of their own.

Material interlock

The equipment can hold until the required materials are verified. The operator scans, the platform confirms against the recipe, and only then is the cleared flag written back.

Quality checks and events

In-batch quality results and events recorded against the batch record.

Disposition

Accept, reject or rework at completion, signed where your process requires it.

Equipment arbitration

When two batches want the same shared equipment module, requests are queued, granted and released explicitly instead of colliding.

Archive and restore

Completed batches move to long-term storage on your schedule and can be pulled back intact for an audit.

Batch analytics

Phase durations, material consumption and yield across batches, with a side-by-side comparison of any two or more and a bottleneck summary that names the phase costing you the most.

ISA-106 Continuous Process

Full continuous process support: state tracking, material genealogy, job boundaries, production context, the ISA-95 PLC interface and work order management. The PLC owns the recipe; PulseMQ observes, records and reconciles.

Jobs

A job is a continuous run with a target and many outputs. Create it by hand, dispatch it from a work order, or let the line create it — in autonomous mode a job opens by itself when the line starts producing.

Production context

Recipe, product, lot, order and roll identifiers are read from the PLC or HMI, logged on change and attached to the job, so what the line was actually set to is what gets recorded.

Procedural states

Idle, startup, threading, ramp, normal, transition, wash, shutdown and fault, mapped from your own state word and usable as the machine's headline status.

Job boundaries

A roll change, cut or index is detected from a counter increment — and only an increment, so a power cycle that resets the counter is never mistaken for production. Each output is recorded with its own length, weight, defect count and the state the line was in.

Output categorisation

Product made during a transition can be accepted, sorted or rejected per output, and the decision follows the material into inventory.

Production logging

Actual length or weight against target, average speed and a projected finish, updated continuously through the run, with auto-complete on target.

ISA-95 PLC interface

UDT mapping and handshake between MES and controller — the structured exchange described below.

Quality & serialisation

Serial number generation for produced units, with facility code and default grade, feeding the Quality tab.

Job labels

Label data published to a printer at every output, at job end, on a quantity threshold, on a PLC signal, or on demand.

Job Tracking

ISA-95 production order tracking for discrete parts machines with simple job workflows — the standard job infrastructure without ISA-88 batch or ISA-106 continuous complexity.

Start and stop

Open a job, run it, close it. No recipe download, no phase model.

Output counting

Good and reject counts read from the machine and totalled against the job.

Progress monitoring

Quantity against target with elapsed and projected time, on the machine card and the job list.

Work orders & products · ISA-95

Work order lifecycle

Created, scheduled, released, in progress, paused, completed, closed — with quantities, due date, priority and the customer or ERP order reference carried through.

Schedule board

A calendar and timeline view of the coming work, with drag-and-drop scheduling across machines.

Linked execution

A work order links to the jobs or batches that fulfil it; progress rolls up automatically and the order can complete itself when the quantity is met.

Operating mode

Autonomous, scheduled, observation, work-order or manual — how much the line is trusted to start work on its own, set per machine.

Product Catalog

Products with type and status, a bill of materials covering inputs, outputs and by-products, and routing steps. A dispatch can be validated against material availability before it goes out.

The machine handshake

Commands with receipts

Every command sent to a PLC carries a sequence number the controller echoes back. The job is confirmed only when the machine says it received it, and the start time recorded is the machine's — not the moment somebody clicked.

Timeout and retry

If no acknowledgement arrives inside your timeout, the job is flagged and a retry button appears. A silent failure is not one of the possible outcomes.

Job control UDT

A structured exchange in the controller: command, identifiers, targets, units, rates, operator, tool and material going down; state, counts, progress, cycle time, speed, faults and consumption coming back.

Auxiliary commands

Machine-specific buttons — purge, index, reset, tare — configured per machine and published to the PLC on press, with the permission to press them controlled by role.

Operator Station

Track raw material inputs, actual versus target quantities, consumption per batch and parent-child genealogy records — essential for recalls, quality investigations and regulatory compliance. From the pallet at goods-in to the roll on the truck, verified at the machine rather than reconciled afterwards.

Defining what you buy

Material Catalog

Material definitions with unit of measure, GS1 identifiers, and how each is tracked — by weight, volume, length, count or time.

Bill of materials

The inputs a recipe or product expects, with target quantities, compared against what was actually consumed.

Receiving and holding stock

Receiving

Create lots on receipt with quantity, supplier, expiry and barcode. Print a label if the supplier's is not usable.

Lots and sublots

A lot can be broken into sublots on carriers, each staged, delivered and consumed independently, with its own reservations and consumed quantity.

Lot status

Quarantine, released, consumed, expired. Material that has not been released cannot be consumed by mistake.

At the machine

Two-step scanning

The operator scans the position label on the machine, then the material barcode. The platform pairs them, so a material is bound to the station it was actually loaded into — not to whichever slot happened to be highlighted on screen.

Barcode parsing

GS1-128 and common vendor formats are parsed into material, lot, sublot, supplier, quantity, unit and expiry. Field names that differ between suppliers are normalised on the way in.

Verification with the PLC

The controller asks, PulseMQ answers: is this the right material, in the right quantity, released and unexpired? A pass writes the bound lot back to the machine; a fail returns a status code and the line stays held.

Load and close-out

The first scan loads and verifies; the second closes the lot out and computes what was actually consumed. Rejections are explicit and carry a reason.

Through the run

Consumption tracking

Consumption follows a PLC tag through the run — either as a running total or as discrete deductions — with manual entry available when a material is not instrumented.

Mid-run changeover

Swapping a lot part way through a batch or job is supported where you allow it, optionally requiring the machine to acknowledge the change.

After the run

Genealogy records

Input lots are linked to the outputs they became, and outputs become lots in their own right. Given a finished roll you can name every input that went into it; given a suspect input you can name everything it touched.

Demand overview

What upcoming scheduled batches and jobs will need, against what is on hand.

Material History

Viewed by batch — everything one batch consumed — or by material — everywhere one lot went.

MES-controlled label printing

Output labels triggered at batch end, at each output, on a threshold, on a PLC signal or manually, using your template and field layout.

Two features, deliberately separate: Maintenance Tracking watches one machine's counters and schedules, and Enhanced Maintenance plans across every machine from one place. Digital PM forms carry the work out on the floor.

Maintenance Tracking

Counter-based or time-based schedules on the machine itself, with service history, counter resets and alerts.

Maintenance counters

Cycles, hours, length or any counted quantity tracked against a setpoint, shown as a progress bar with the remaining amount, and reset from the dashboard by anyone with the permission.

Time-based schedules

Intervals in days or weeks for the work that comes round on a calendar rather than a counter.

Due and overdue

Counters approaching or past their setpoint raise a maintenance condition on the machine and can notify like any other alarm.

Task templates

Per machine and per counter: the procedure text, required parts, required tools, estimated downtime, and who it should go to.

Pre-batch check

Dispatching a batch to a machine with maintenance due warns before it goes, with an override that is recorded against the batch.

Service history

Every reset, every completed task, every override — kept with the machine.

Enhanced Maintenance

Centralised scheduling: plan maintenance for every machine from one place, on the Overview page. Switching it on consolidates maintenance — the standalone Parts tab folds into this screen rather than sitting beside it, so there is one place to plan from instead of two.

Cross-machine predictions

What is coming due across the plant, projected from counters that are still running, so work can be grouped before it becomes urgent.

Prioritisation

Rank the queue across every machine rather than machine by machine.

Assignment

Allocate work to people or teams from the same screen, against the production schedule.

Digital PM forms

The paper preventive-maintenance packet, replaced end to end: authored, published, dispatched, completed on a tablet, reviewed, and returned as a PDF report.

Scheduled machine performance reports with OEE metrics, maintenance summaries and trend analysis, delivered by email — plus the interactive analytics behind them. Everything the platform records is queryable after the fact, and everything on screen can leave as a file.

How you ask a question

The charts

Summary cards

The headline numbers for the current selection, before you look at a single chart.

OEE trend and heatmap

The three factors over time, and a machine-by-period grid that exposes patterns an average hides.

Cycle time trend

Cycle time drift over a run or a week — the early signal that something mechanical is changing.

Quality and defects

Defect counts and categories by machine, product and period.

Job history

Completed jobs with targets, actuals, speeds, outputs and durations, plus a timeline of every change made to a job during its run.

Batch performance

Phase timings, material consumption and quality outcomes per batch, with comparison and bottleneck analysis across a set.

Alarm analysis

Alarm frequency and duration by machine and period, including the bubble view that separates nuisance alarms from costly ones.

Machine hierarchy view

Roll performance up from machine to cell to area, or drill from the plant number down to the asset behind it.

Leaving the platform

Exports

Historical and batch data as CSV; batch and job reports as PDF; recipes, alarm and tag configuration as JSON or CSV; QR labels as printable sheets.

Bi-directional data exchange with your ERP — and, with it, the Quality Management tab. Turning on ERP Integration turns on both.

The exchange

Quality Management

Quality Holds

Place and release holds against material or output, with status tracked and counted on the tab so nothing on hold quietly ships.

Test Results

Record test outcomes against the product, with pending tests surfaced as work still to do.

Tube Serials

Serial numbers generated per produced unit, using a facility code and default grade configured on the machine, and traceable back through genealogy.

Grade Specs

The specification each grade must meet, held as the reference test results are judged against.

MTR Reports

Material test reports generated from the recorded results and serials — the certificate that travels with the product.

Non-conformances

Raised in PulseMQ and posted to the ERP, so a quality event is one record in two systems rather than two records that disagree.

Environmental performance monitoring. Map a meter — power, flow, temperature, humidity — on the Environmental tab and it behaves like any other signal in the platform: live on the dashboard, on the trends chart, and in history. The long-run ESG layer that rolls those readings into scores and period reports is still being built.

Available today

Environmental tab

Configure the environmental signals a machine publishes — power, flow, temperature, humidity and similar — with display names, units and visibility, exactly as you would any process metric.

Power monitoring

A power consumption widget reads the machine's mapped energy signal and charts it over time, including peak-window analysis for spotting the demand spikes that drive a utility bill.

Environmental widgets

Water usage, waste reduction and carbon footprint widgets display whichever signal you bind to them, with target and capacity thresholds, so a site that already meters water can put it on the dashboard now.

Trends and history

Environmental signals chart alongside production values on the Trends tab and are retained with the rest of the machine's history.

In development

Automatic rollups

Per-shift and per-period aggregation of energy, water and waste into a reportable record, rather than a live reading you watch.

Sustainability scoring

The composite ESG score and its dashboard.

Carbon derivation

Emissions from energy consumption. When it ships, the conversion factor will be one you set and can defend to an auditor.

Bring the machine's own on-device screen into the dashboard, so a supervisor investigating a fault does not have to walk to the panel — without the dashboard ever pretending to be the controller.

What you see

Live diagnostics

The AlarmIQ diagnostics and playback view from the machine's on-device controller, framed inside a Diagnostics / HMI tab on the machine page.

Bridge HMI

Optionally the operator HMI itself, alongside the diagnostics view.

Process mimic

A native process mimic rendered in the dashboard from the device's own declarative manifest — the structure is fetched once and only live values stream, which keeps it responsive over a mobile uplink.

How it is delivered

Read-only by design

The device stays the source of truth and the dashboard only displays it. There is no write path through the embed; anything that changes the machine still goes through the device's own permission checks.

Gateway enrolment

Requires the device to be enrolled in the gateway registry, and the viewer to be signed in — the stream is not open to the network.

Natural language MES operations. Ask questions and give commands in plain English — powered by Claude on AWS Bedrock, with per-machine budget controls and monthly usage caps.

What you can ask it

Ask about the plant

Check machine status, look up schedules, investigate downtime — answered from live and historical data, in the context of the machine you have open.

What it can do

Give it work

Dispatch work orders, add a maintenance item, define a process value, create a task template, adjust an OEE baseline — described in words, performed against the real configuration.

Guided machine setup

Walks a new machine through the whole chain: create, choose features, map status, map process and production signals, select OEE signals, set baselines, add alarms and maintenance, then validate the result.

Boundaries

Bounded by your roles

The assistant can do exactly what the signed-in person could do by hand, and nothing more. Significant changes are confirmed before they are made.

Costs you can see

Budget controls are set per machine and usage is tracked and capped monthly, so the feature cannot run up a bill quietly.

Every feature is switched on a machine at a time, so you can start narrow and widen later. Two things decide what is available: the machine’s production mode, and whether a feature depends on another.

Three routes in

Three ordinary days, to show how the features in Part two behave once they are switched on and something goes wrong.

A discrete line, Monday morning

06:00 — the shift opens itself

The line starts and the machine’s state signal changes. PulseMQ opens the shift, starts the availability timeline and begins counting. Nobody logs in to start anything.

08:12 — a stop nobody would have written down

The line idles for eleven minutes. It lands on the timeline with its own duration, and the operator is asked to classify it against your reason-code list.

09:40 — performance drifts

Cycle time creeps four per cent above ideal. The trend shows it as a slope rather than a single bad reading, which is the difference between a tooling conversation and a shrug.

14:00 — shift close

The shift’s OEE, its three factors, downtime split and counts are written to history automatically, on your shift calendar. The report arrives by email without anyone assembling it.

A batch that will not start with the wrong drum

The recipe is dispatched

A supervisor picks recipe, machine and parameters. The control recipe is frozen at dispatch, so editing the master tomorrow cannot change what ran today.

The equipment holds

The controller raises its verification-required flag. Nothing starts until the materials are confirmed.

The operator scans

Position label first, then the drum’s own GS1 label. PulseMQ checks it is the right material, in the right quantity, released and unexpired.

A wrong drum is refused

The answer goes back as a status code and the line stays held — before the batch is made, not after it is dispositioned.

The right drum clears it

The bound lot is written back to the controller, the cleared flag is set, and the batch runs. That lot is now part of the batch’s genealogy for as long as the record exists.

A PM in a basement with no signal

The work is dispatched

A planner assigns the published form to a named technician and a machine. If the machine’s lockout procedure is not on file, dispatch is refused and says so.

The tech walks out of coverage

Their tablet already holds the form. Answers, readings and photos are captured normally.

Nothing claims to be saved

Every answer sits in the on-device queue marked Queued. The app does not tell them the work is filed when it is not.

They come back upstairs

The queue drains, the server confirms each batch, and only then do the answers stop showing as queued.

The record closes

Submission is checked server-side; anything missing is marked on the form. A reviewer accepts it, and a PDF is filed to the machine’s vault with the lockout revision that was shown and a content hash on every page.

PulseMQ speaks Sparkplug B over MQTT — the industrial standard for publishing machine data. If your controls can publish it, we can read it; if they cannot, a small edge gateway bridges the gap. Nothing on the machine is replaced.

Sparkplug B native

Birth, data, death and command messages are handled as the specification intends — a device that reconnects re-declares everything it publishes, so PulseMQ never runs on a stale tag list.

Report-by-exception aware

Sparkplug publishes only what changed. PulseMQ holds the full picture between updates and force-reads the handful of signals where a missed change would matter, such as command acknowledgements.

Automatic device discovery

Every node and device that announces itself is registered with its published tag list, its parent node and its last-seen time — including sensors, saws, pumps and other equipment hanging off a machine.

Tag naming you control

Raw controller tags are normalised and then mapped to friendly names, units and categories. Rename on the screen without touching the PLC.

Offline detection

A sweep every five minutes flags any machine that has gone quiet past its threshold, marks it offline, records the transition, and re-evaluates its open alarms.

Tiered storage

Live values stream straight to screens; a durable record is written on a slower cadence for recovery and reporting; state changes, acknowledgements and completed outputs are written the instant they happen.

Historical archive

Every processed message is also filed to long-term storage in a query-friendly layout, so an audit two years from now can still reconstruct the shift.

Works with old iron

Twenty-year-old controllers are in scope. The requirement is a route to MQTT, not a modern PLC.

The platform holds a model of your plant, not just a list of machines — which is what lets a number roll up and a fault drill down.

Hierarchy

Company, location, area, cell, machine — following the ISA-95 model, with work centres and cell positions.

Cell Layout

A visual view of areas and cells with the machines in them and their live status, expandable down to the asset. Administrators add areas and cells and assign machines from the same screen.

Machine roles

Primary, auxiliary or standalone. An auxiliary asset — a saw, a conveyor, a dust collector — is attached to its parent machine and reports against it.

Line topology

Upstream and downstream relationships between machines, so a stoppage can be read in the context of what feeds it.

Equipment modules

Sub-units within a machine defined as a tree, each with its own signals and material tracking, and each able to be arbitrated between competing batches.

Equipment types

Reusable definitions, so the tenth machine of a kind is configured from a pattern rather than from scratch.

Equipment capability

Which equipment can execute which procedure — checked before a batch is sent somewhere it cannot run.

QR labels

Printable labels for machines, positions and devices, so scanning replaces typing an asset number.

All of it is configuration, not code. Turn a feature on and its tab appears; every screen in this guide is driven by settings an engineer can change on a Tuesday afternoon without a software release.

Signal path builder

Structured tag paths are assembled from a base path, an element and a field, matching the UDT structures your controls team already built — with either separator convention.

UDT generation

Generate the PLC tag structure straight from the machine's configuration and download it as a Rockwell L5X for Studio 5000, an Ignition UDT in JSON, or a flat CSV tag list for the PLC and IoT bridge. The screen tells you how many tags it will produce before you download.

ISA-88 recipe structures

Recipe and phase structures export as L5X on the same principle, so the controller's recipe interface is generated rather than transcribed.

Setup wizard

A guided path for a new machine, from creation through features, signals and baselines to validation — by hand or through the AI Assistant.

Cost control

A machine can be deactivated so it stops consuming processing and storage, while its configuration and history stay intact.

The hardware around the machine is registered, addressed and testable from the same place as the machine itself.

Pairing by scan

Pair a handheld scanner or an auxiliary asset to a machine by scanning its label — no address typed, no configuration file edited.

Scan modes

Devices can be set to load, close-out or reject modes, so the same scanner serves several steps without a menu.

Print targets

Label printers receive job, batch and material label data on the triggers configured per machine.

Access is decided on the server for every request — not by hiding buttons in the browser — and a company's data is reachable only by that company's people.

Sign-in

Managed accounts with password policy and session expiry, or your own identity provider by SAML or OIDC federation, so people use the credentials they already have.

Permission matrix

Permissions are grouped by area — machines, users, system, alarms, materials, reports, maintenance — and defined once, so the screen and the server can never disagree about who may do what.

Enforced on the server

Every request carries the caller's identity and is checked against their role and their company before anything is read or written. An unrecognised role is denied, not waved through.

Company isolation

Data is partitioned by customer. One company's users cannot reach another's machines, batches, recipes or documents.

Electronic signatures

Where your process needs them: a stated meaning, the password re-verified at the moment of signing, an unbroken hash chain over the signed record, separation of duties between author and approver, and an append-only history. Signatures are never editable or deletable — only superseded.

Audit trail

Configuration changes, dispositions, overrides, resets and approvals are recorded with who, what and when.

Emergency lockdown

An administrator can lock the platform to a maintenance screen immediately if something needs to stop.

Recoverable by design

Continuous backup with point-in-time recovery on operational data, and configuration held with change history.

Your production data belongs to you, stays retrievable, and leaves the platform in formats other systems can read.

Live signal store

Current and recent machine values, kept hot for the dashboards and the calculations behind them.

Production records

Jobs, batches, work orders, material lots, genealogy, alarms and maintenance records, each held as its own record and queryable by machine, status and date.

Shift history

Per-shift OEE with its component numbers, downtime split and counts, retained for long-term trending.

Long-term archive

Completed jobs and batches move to archival storage on a schedule, leaving a searchable index behind, and can be restored intact. Older archives roll to cold storage automatically to keep costs down.

Query-ready layout

The archive is written in a partitioned, analytics-friendly structure, so your own BI or data science tooling can read it directly.

REST API

The same interface the dashboard uses is available to your systems: machines, jobs, batches, work orders, materials, recipes, alarms and reports.

Live subscriptions

For applications that need push rather than poll — machine status, job progress and batch status stream out as they change.

ERP exchange

Orders in, completions and receipts out, on the connector described in section 12.

File exchange

CSV for historical and tabular data, JSON for recipes and configuration, PDF for reports and completed forms.

Two ways to run it, and the same product either way.

Installation

Typically live within a week. Network access and a tag list is most of what we need from you, and there is no production stoppage to install.

Alongside SCADA

PulseMQ does not replace your control system. It reads what the control system publishes and adds the execution, history and reporting layer above it.

Devices

Desktop browsers, plant-floor panel PCs and tablets. The tablet experience installs as an app and keeps working through a network outage.

Multi-site

Several locations under one company, with per-location filtering, per-location notification routing, and roll-up reporting across them.

Health monitoring

Connection state per machine, message logging with retention, and offline detection — you find out from the platform, not from a supervisor.

Stated plainly, because a roadmap item described as a finished feature is how trust gets lost. These are built or building, not yet in general use.

Downtime reason coding

Operator-facing stop classification against your own reason-code list, feeding cause into the availability analysis. Built and provisioned; rolling out to production lines.

ESG rollups & scoring

Live environmental monitoring works today (section 13). What is still being built is the layer above it: per-shift and per-period aggregation of energy, water and waste into reportable records, the composite sustainability score, and carbon derived from consumption on a factor you set.

Maintenance alarm baselines

Clearing a maintenance alarm from a counter reset, by holding the baseline the alarm was raised against.

Additional ERP connectors

Epicor Kinetic ships as a direct connector today. SAP and Oracle connect through the order-import and completion-export interface; direct connectors for those are in development.