A Layered Process Audit works earlier than that. Supervisors, engineers, and managers check the process while production is running and while they are standing at the workstation. These short, regular audits help catch problems before defects are produced, reinforce standard work, and keep communication active between shifts and departments.

This guide explains what an LPA is, how manufacturers use it, how to run one, and includes a practical checklist you can use on the shop floor.

Layered Process Audit (LPA): Definition and Meaning

A Layered Process Audit (LPA) is a structured manufacturing audit used to verify that a process is being performed according to the defined standard. The audit focuses on how the work is done, not on inspecting finished parts.

In practice, an LPA is performed at the workstation. The auditor observes the operation, asks a small set of standard questions, and records whether each requirement is being followed. The same process is checked repeatedly by different levels of management, which is where the term layered comes from.

The layers are organizational levels, not stages of production. A typical program includes:

• Layer 1: Supervisor or team leader
• Layer 2: Area manager
• Layer 3: Plant leadership

All three may audit the same station, but at different frequencies.

A useful way to think about an LPA is as a routine health check for production. Final inspection tells you a part is bad; an LPA is intended to find the missing setup check, incorrect material, bypassed error-proofing device, or out-of-calibration tool before bad parts are made.

LPAs are common in automotive manufacturing and other industries with strict quality requirements. They do not replace product audits, process audits, or the plant's quality management system; they add a frequent, practical layer of process verification where the work happens.

Why Manufacturers Run LPAs

Historically, LPAs spread through automotive manufacturing on the back of OEM supplier requirements. DaimlerChrysler and General Motors developed the common approach under the Automotive Industry Action Group, which published the first edition of the CQI-8 Layered Process Audit Guideline in 2005 and a second edition in 2014. Today those requirements reach suppliers through customer-specific documents from OEMs such as General Motors and Stellantis, and CQI-8 remains the guidance most plants reference.

The purpose is simple: verify that critical process controls are being followed while production is running. Finding a bypassed sensor today is far less expensive than sorting suspect parts weeks later.

LPAs support the intent of IATF 16949, but they do not replace the internal, process, or product audits required by the quality management system.

Manufacturers typically use LPAs to reinforce standard work, verify critical process settings, reduce repeat quality problems, improve accountability, and increase management presence on the shop floor.

The value of an LPA comes from consistent observation and quick correction, not from the checklist itself.

How the Layers Work

The same process is checked by different levels of management at different frequencies. Lower layers audit more often and in greater detail; higher layers audit less often and across a broader area.

The table below is a common starting point rather than a rule. CQI-8 deliberately leaves audit frequency and question topics to each organization, so set yours based on process risk and expect them to change as you learn which stations need more attention.

Layer 1: Supervisor Audit

The supervisor audits the station or line they manage. The focus is operator practice, standard work, tooling, materials, and immediate process controls. Simple problems are usually corrected immediately.

Layer 2: Manager Audit

The area manager audits across several lines. In addition to the checklist itself, they verify that Layer 1 audits are being completed and that previous findings have been closed.

Layer 3: Plant Leadership Audit

Plant leadership audits less often and across a wider scope. The focus is whether the LPA system is functioning: audits completed, repeat issues addressed, and no critical controls quietly abandoned.

A practical rule is: the higher the layer, the wider the scope and the lower the frequency. That overlap creates accountability across the organization.

How to Run a Layered Process Audit

1. Select the process. Start with a high-risk operation such as one with customer complaints, scrap, rework, safety exposure, or critical process parameters. A Pareto chart is a useful way to identify the stations causing the largest share of defects.
2. Create the checklist. Use the PFMEA, control plan, work instructions, and recent quality issues. Ten to fifteen objective questions is usually enough.
3. Define the schedule. Decide which layer audits each area and how often.
4. Train the auditors. Auditors should observe the process, ask factual questions, and record evidence rather than opinions.
5. Perform the audit at the station. Watch the operation and record answers while standing at the workstation.
6. Correct immediate issues. Fix simple problems during the audit whenever possible.
7. Assign corrective actions. Give each finding an owner and a due date.
8. Verify closure. Confirm that the action was completed and remains effective during the next audit cycle.

Most LPAs take 5 to 15 minutes. If an audit takes much longer, the checklist is usually too large for a routine layered audit.

Many plants start LPAs with paper checklists or spreadsheets. As the program expands, they often digitize the same workflow so audits can be scheduled automatically, findings can trigger alerts, and corrective actions can be tracked across shifts and plants.

What to Put on the LPA Checklist

An LPA checklist should verify the few process controls that matter most. Keep it short and focused.

Good questions usually come from:

• PFMEA high-risk items
• Control plan checks
• Customer complaints
• Scrap and rework data
• Past audit findings

Write questions so they can be answered Yes or No by observing the process.

Example LPA Questions

Standard work

• Is the latest work instruction displayed?
• Is the operator following the defined sequence?
• Is the correct revision of the process sheet in use?

Materials

• Is the material label correct and readable?
• Is FIFO being followed?
• Is the approved material being used?

Tooling and equipment

• Is the torque tool within calibration date?
• Is the machine parameter within the approved range?
• Is the gauge identified and available at the station?

A calibration date on a checklist is only as good as the record behind it. For what that record should contain and how intervals are set, see What Is Instrument Calibration (Equipment Calibration)?; for turning that register into overdue and due-soon status the auditor can check in seconds, see Tracking Instrument Calibration with a Digital Dashboard.

Error-proofing

• Is the poka-yoke device active and not bypassed?
• Does the sensor stop the process when a fault is introduced?

Traceability

• Is the batch or serial number recorded correctly?
• Can the current part be traced to its material lot?

Safety and workplace condition

• Are required PPE items being worn?
• Is the workstation free from oil, scrap, and obstructions?
• Are safety guards in place?

A useful checklist usually fits on one page and can be completed while standing at the station.

The workplace-condition questions overlap with 5S. Keep only the few conditions that affect the process directly and handle broader housekeeping through a separate 5S audit.

Download the LPA Checklist Template

Download the one-page Layered Process Audit checklist template and use it on the shop floor as a starting point for your LPA program. The sample questions can be adapted to your own PFMEA, control plan, and process requirements.

Layered Process Audit Software: Moving LPAs Off Paper

Paper LPAs are easy to start, but they become difficult to manage as the program grows. Finding repeat issues, overdue actions, or missed audits usually means searching through forms or spreadsheets.

A digital LPA keeps the same audit process while making results immediately available. Auditors can complete checklists on a phone or tablet, attach photos, trigger alerts for failed checks, and assign corrective actions from the workstation.

The bigger advantage is connecting LPA results with production data. With FlowFuse, audit applications can connect to machines, PLCs, sensors, databases, and other industrial systems. This lets teams compare failed audit checks with downtime, scrap, machine states, or process parameters to understand what was happening on the line.

With FlowFuse Dashboard, plants can build LPA forms, track findings and corrective actions, and visualize audit results alongside production data.

A useful starting point is the 5S Checklist Blueprint, which can be adapted for an LPA program by replacing the 5S questions with LPA questions.

Where LPA Programs Break Down

Most LPA programs do not fail suddenly; they become mechanical.

A common problem is pencil-whipping, where audits are marked complete without anyone visiting the workstation. Another is that higher management layers gradually stop performing their scheduled audits, so the layered system weakens over time.

Plants also struggle with findings that remain open for too long and checklists that are not updated when the process changes.

A healthy LPA program stays short, focused, and regularly reviewed. If audits become long and repetitive, people will eventually rush through them or skip them.

Measure the Program, Not Just the Audits

Treat the LPA as a managed program, not just a checklist activity. Review it monthly by checking whether each layer completed its audits, how quickly findings were closed, whether the same issue is appearing repeatedly at the same station, and whether corrective actions were documented and verified.

If a finding keeps returning, use a structured method such as a Five Whys analysis to investigate the root cause rather than repeating the same corrective action.

Digitize your shop-floor audits

Talk to us about building LPA forms, alerts, and corrective action tracking on your existing industrial data infrastructure.

Contact Us

Two fleets under separate control can't share an intersection. So you either accept deadlocks, or you split the floor into separate lanes and waste space. Each fleet manager also needs its own link to your ERP, MES, or WMS. Adding a vehicle from a new vendor means another integration project. And because no single system sees all the work, one vendor's AGVs sit idle while the other's are backed up.

VDA 5050 solves that. FlowFuse gives you somewhere to build the master control system that uses it.

Why VDA 5050?

VDA 5050 is an open communication standard. The VDA (the German automotive association) and the VDMA (the machinery association) publish it together. The Institute for Material Handling and Logistics (IFL) at KIT leads the technical work.

It first appeared in 2019. It sets out how a master control system sends transport orders to a vehicle, and how that vehicle reports back. Messages travel over MQTT as JSON.

Most AGVs and AMRs on factory floors today speak the 2.x version. Version 3.0 came out on 19 March 2026 and adds support for freely navigating robots.

One interface, any vehicle

A master control system that speaks VDA 5050 can drive vehicles from different makers. You don't write a new integration for each one.

The standard fixes the message contract, not the vehicle. How an AGV avoids obstacles or plans its path is still up to the manufacturer. What you get is a shared order format and a shared status format.

If you already run Sparkplug B on the same broker, the two solve different problems. Sparkplug standardizes telemetry from any device. VDA 5050 standardizes a command-and-report contract for one class of device, so it says what an order looks like as well as what a status message looks like.

Safety stays out of scope. Emergency stops and person detection live on the vehicle and follow standards like ISO 3691-4. VDA 5050 reports safety state. It does not implement it.

Real detail, not just a heartbeat

The messages carry operational data. A state message includes position, battery charge, order progress, and any active errors. An order describes a route of nodes and edges with actions attached, such as pick, drop, wait, or charge.

That detail is what lets master control make dispatch decisions, instead of just knowing a vehicle is online.

Built on MQTT

MQTT suits a fleet well. It is lightweight, it uses publish and subscribe, and it copes with devices that drop off the network. Vehicles report when something changes rather than waiting to be polled, which is event-driven architecture applied to a floor full of moving hardware.

Every VDA 5050 topic follows the same pattern. So one wildcard subscription hears from every vehicle on the floor, whoever built it.

The six topics

Both state and visualization carry position. That is on purpose.

state is the full picture. A vehicle sends it when something changes, and at least once every 30 seconds. visualization is a small message with just position and velocity, so it can go out far more often, typically once a second or faster.

Use state for anything master control acts on. Use visualization only to draw a smooth live map. Note that visualization is optional in the standard, so some vehicles never send it. Version 3.0 widens its job: it now carries the planned path too, so traffic control can read it rather than just a map display.

How topics are named

<interfaceName>/<majorVersion>/<manufacturer>/<serialNumber>/<topic>

For example: uagv/v2/AcmeRobotics/AGV-042/state

uagv is the interface name the standard uses in its own examples, and most people read it as short for "universal AGV". The standard itself only calls it the name of the interface, and each site can set its own. But nearly every 2.x deployment uses uagv, including the vehicles you are likely to buy. Treat it as fixed unless the vehicle's manual says otherwise.

The same caveat applies to the levels around it. The standard mandates the topic names in the final segment, order, state, and so on. It calls the five-level structure a suggestion for a local broker, because cloud brokers impose their own topic rules. On-premise fleets follow it anyway, so build against it and adapt only if your broker forces you to.

The version segment is the major version only. So v2, not v2.0.0. The full version number goes in the version field inside the payload.

Because the maker and serial number sit in the topic, master control can subscribe once to uagv/v2/+/+/state and hear from every vehicle. Restrict each vehicle to its own topic path, using an allowlist on your broker.

A note on version 3.0

This tutorial uses version 2.x names, because that is what most vehicles speak today. Version 3.0 renames a lot:

• The example topic prefix moves to vda5050/v3/...
• agvPosition becomes mobileRobotPosition
• batteryState becomes powerSupply, and batteryCharge becomes stateOfCharge
• positionInitialized becomes localized
• safetyState.eStop becomes activeEmergencyStop, and the AUTOACK value is gone
• actionStates splits into actionStates, instantActionStates, and zoneActionStates, each cleared by its own instant action
• Edges drop startNodeId and endNodeId. Position in the sequence alone now says which nodes an edge connects
• Errors gain two levels, CRITICAL and URGENT
• Every robot must support startPause, stopPause, and cancelOrder
• timestamp moves from hundredths of a second to milliseconds
• Version 3.0 adds two optional topics, zoneSet and responses, and a fourth blocking type, SINGLE
• CONNECTIONBROKEN becomes CONNECTION_BROKEN, and HIBERNATING is added
• It also adds the operating modes STARTUP and INTERVENED
• The wording changes from "AGV" to "mobile robot" throughout

Version 3.0 also strips abbreviations out of parameter names across the whole document, which is a breaking change. The 3.0.0 release notes link a table of every rename, so check that before you port a 2.x integration.

If your vehicle ships with 3.0 support, swap the names. The topic structure and the ideas below stay the same.

What a state message looks like

{
  "headerId": 42,
  "timestamp": "2026-08-10T09:15:00.000Z",
  "version": "2.1.0",
  "manufacturer": "AcmeRobotics",
  "serialNumber": "AGV-042",
  "orderId": "order-1001",
  "orderUpdateId": 0,
  "lastNodeId": "node7",
  "lastNodeSequenceId": 6,
  "nodeStates": [
    { "nodeId": "node8", "sequenceId": 8, "released": true }
  ],
  "edgeStates": [
    { "edgeId": "node7-8", "sequenceId": 7, "released": true }
  ],
  "agvPosition": {
    "x": 12.4,
    "y": 3.1,
    "theta": 0.0,
    "mapId": "floor1",
    "positionInitialized": true
  },
  "velocity": { "vx": 0.5, "vy": 0.0, "omega": 0.0 },
  "batteryState": { "batteryCharge": 76.5, "charging": false },
  "driving": true,
  "actionStates": [
    { "actionId": "drop-42", "actionStatus": "WAITING" }
  ],
  "operatingMode": "AUTOMATIC",
  "errors": [],
  "safetyState": { "eStop": "NONE", "fieldViolation": false }
}

That vehicle is driving from node7 to node8, with a drop waiting at the end of it. Three things to know before you write code against this.

Some fields are always there. orderId, orderUpdateId, lastNodeId, lastNodeSequenceId, nodeStates, edgeStates, driving, actionStates, batteryState, operatingMode, errors, and safetyState are required. An idle vehicle sends empty nodeStates and edgeStates arrays. It does not drop the fields.

Position is not, but read the exception carefully. agvPosition and velocity are optional. The standard only lets a vehicle omit agvPosition if it cannot localize itself at all, such as a line-guided AGV. A vehicle that can localize but hasn't finished yet still sends the field, with positionInitialized set to false.

So master control needs two checks, not one. Confirm agvPosition is there, then confirm positionInitialized is true before you trust the numbers. Code like msg.payload.agvPosition.x crashes on a line-guided vehicle. Code that skips the second check will route a truck using coordinates the truck itself doesn't stand behind.

Watch the timestamp precision. 2.x writes timestamp with hundredths of a second, while JavaScript's toISOString() gives you milliseconds. Vehicles accept it in practice, and 3.0 moves to milliseconds officially, but a strict schema validator flags it.

The standard ships JSON schemas for all six topics. Point a validator at them and you can check a payload before you send it, rather than finding out from the vehicle.

Build it

What you need

• A running FlowFuse instance on your edge device. If you do not have an account, sign up for a free trial and set up your instance following the instructions in this guide.
• An MQTT broker your AGVs (or an AGV simulator) already publish to, or FlowFuse's built-in team broker if you're prototyping. If you're still choosing a broker, any one with retained messages, last will, and per-client topic permissions will do.
• At least one vehicle or simulator publishing VDA 5050 topics, so you have real messages to work with.

Step 1: Connect to your broker

1. Drag an mqtt in node onto the canvas. Double-click it.
2. Click the pencil icon next to Server to add a broker.
3. Enter your broker's host and port. Use 8883 and tick Use TLS on the Connection tab. Only use plain port 1883 on an isolated test network.
4. On the same tab, set Keep alive to 15 seconds. The standard suggests around that, because the keep alive decides how fast the broker notices a vehicle has vanished. Node-RED defaults to 60, which leaves a dead AGV looking alive for up to a minute and a half.
5. If your broker needs a login, open the Security tab and enter the username and password.
6. Leave the topic empty for now. You'll fill it in next.

The FlowFuse MQTT nodes replace steps 2 to 5 if you're pointing at the FlowFuse broker. They create the client and fill in the credentials themselves.

Step 2: Subscribe to fleet state

1. In the mqtt in node, set Topic to uagv/v2/+/+/state. Each + stands for one topic level. Here they cover manufacturer and serial number, so this one subscription picks up every vehicle.
2. Set QoS to 0. VDA 5050 asks for QoS 0 on order, instantActions, state, factsheet, and visualization, and QoS 1 only on connection. Setting a higher QoS on your side doesn't help anyway. MQTT delivers at the lower of the two values.
3. Set Output to "a parsed JSON object". You then get a JavaScript object instead of raw bytes. If a vehicle sends broken JSON, the node logs an error and drops the message.
4. Add a function node (the one from step 3 below) and a debug node after it.
5. Deploy. Check that the mqtt in node says "connected", then watch messages arrive in the debug sidebar.

[{"id":"vda-mqtt-in","type":"mqtt in","z":"vda-flow","name":"Fleet state","topic":"uagv/v2/+/+/state","qos":"0","datatype":"json","broker":"vda-broker","nl":false,"rap":true,"rh":0,"inputs":0,"x":210,"y":160,"wires":[["vda-parse"]]},{"id":"vda-parse","type":"function","z":"vda-flow","name":"Identify vehicle","func":"const parts = msg.topic.split('/');\nif (parts.length !== 5) {\n    node.warn('Unexpected VDA 5050 topic: ' + msg.topic);\n    return null;\n}\n\nmsg.manufacturer = parts[2];\nmsg.serialNumber = parts[3];\n\nconst p = msg.payload;\nif (p.manufacturer !== msg.manufacturer || p.serialNumber !== msg.serialNumber) {\n    node.warn('Topic and payload disagree on ' + msg.topic);\n}\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":430,"y":160,"wires":[["vda-debug"]]},{"id":"vda-debug","type":"debug","z":"vda-flow","name":"State debug","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":650,"y":160,"wires":[]},{"id":"vda-broker","type":"mqtt-broker","name":"VDA 5050 broker","broker":"your-broker.example.com","port":"8883","clientid":"","autoConnect":true,"usetls":true,"verifyservercert":true,"protocolVersion":"4","keepalive":"15","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"sessionExpiry":""}]

Flow exports never include passwords. After importing, open the broker node and enter your own host and login.

Step 3: Tell the vehicles apart

The state message tells you what is happening. You also need to know who sent it.

manufacturer and serialNumber appear twice: in the payload, and in the topic. Read them from the topic. Here's why.

The topic is the message's address. It is what your broker rules are written against, so it's the right value to route and store by.

Comparing the two is also a free sanity check. If a vehicle's payload disagrees with its topic, it is misconfigured. Better to see that in a log line than to find out when an order goes to the wrong truck.

Put a function node between the mqtt in node and whatever comes next:

const parts = msg.topic.split('/');
if (parts.length !== 5) {
    node.warn('Unexpected VDA 5050 topic: ' + msg.topic);
    return null;
}

msg.manufacturer = parts[2];
msg.serialNumber = parts[3];

const p = msg.payload;
if (p.manufacturer !== msg.manufacturer || p.serialNumber !== msg.serialNumber) {
    node.warn('Topic and payload disagree on ' + msg.topic);
}

return msg;

Now msg.payload holds the state object, and msg.manufacturer and msg.serialNumber tell you which AGV sent it.

Step 4: Catch vehicles going offline

Repeat the same pattern for one more topic, pointing it at the broker you already set up.

Subscribe to uagv/v2/+/+/connection at QoS 1. This tells you when a vehicle drops off the broker. The payload has a connectionState field with one of three values in 2.x:

• ONLINE
• OFFLINE for a clean, deliberate disconnect
• CONNECTIONBROKEN for an unexpected drop

The vehicle registers that last value as its MQTT last will when it connects. So if it vanishes without saying goodbye, the broker publishes it for the vehicle. Vehicles publish every connection message with the retained flag set, so a new subscriber picks up each vehicle's last known status straight away.

This is where the keep alive from step 1 earns its place. The broker only fires the last will once the heartbeat lapses, so a 60-second keep alive can hide a dead vehicle for well over a minute.

One warning. connection is a network check, not a health check. Version 3.0 states that outright in its topic table, and 2.1 works the same way without saying it as plainly. It tells you the link dropped. It tells you nothing about a vehicle that is still connected but faulted, stuck, or lost. For that, watch errors, operatingMode, and safetyState in state. Also treat any state message older than 30 seconds as stale, since that is the longest gap the standard allows.

Putting it on a screen

None of this is visible to anyone on the floor yet. You can build a screen from these same flows with FlowFuse Dashboard, without writing any HTML: a table of vehicles with battery level and current order, an alert when a vehicle drops off the network, and a live map of where everything is.

Step 5: Send an order

Three rules decide whether the vehicle accepts your order at all. Get these wrong and it refuses.

The first node must be where the vehicle already is. The standard says the AGV has to be standing on the first node, or inside its deviation range. Send an order that starts anywhere else and the vehicle rejects it. A rejected order shows up as a validationError warning in the vehicle's state, and the warning stays there until it accepts a valid order. Read lastNodeId and agvPosition from the vehicle's current state, and build the order from there.

orderId and orderUpdateId together must be new. Use a fresh orderId for each job. Start orderUpdateId at 0, and only raise it when you extend that same order. A 2.x vehicle checks the incoming orderUpdateId against the one it already holds, treating a lower one as deprecated and an equal one as already received. Version 3.0 draws the line more precisely: resending an identical message is fine, but reusing an orderUpdateId with different content is an error.

The vehicle must support the actions you send. pick and drop are standard action types, but supporting them is optional. Ask for the vehicle's factsheet first, using the factsheetRequest instant action, and check its list of supported actions.

Then wire it up:

1. Add an mqtt out node pointing at your broker. Leave Topic empty so the flow can set msg.topic per vehicle. Leave Retain off. The broker re-delivers a retained order every time the vehicle reconnects, which is how you move a truck at 3am by accident.
2. Feed it a payload matching the order schema: a nodes array and an edges array.
3. Trigger it with a dashboard button for manual dispatch, or from an http in endpoint if orders come from your WMS.

Here is a real pick-and-drop order:

const manufacturer = 'AcmeRobotics';
const serialNumber = 'AGV-042';

msg.topic = `uagv/v2/${manufacturer}/${serialNumber}/order`;

// headerId counts per topic, so key the counter by topic and raise it
// by one for every message you send to that topic
const headerKey = `headerId:${msg.topic}`;
const headerId = (flow.get(headerKey) || 0) + 1;
flow.set(headerKey, headerId);

msg.payload = {
  headerId,
  timestamp: new Date().toISOString(),
  version: "2.1.0",
  manufacturer,
  serialNumber,
  orderId: `order-${Date.now()}`,
  orderUpdateId: 0,
  nodes: [
    {
      // The AGV must already be at this node, or within its deviation range
      nodeId: "station-1",
      sequenceId: 0,
      released: true,
      nodePosition: { x: 0, y: 0, mapId: "floor1" },
      actions: [{
        actionId: `pick-${headerId}`,
        actionType: "pick",
        blockingType: "HARD",
        actionParameters: [
          { key: "stationType", value: "floor" },
          { key: "loadType", value: "EPAL" }
        ]
      }]
    },
    {
      nodeId: "station-2",
      sequenceId: 2,
      released: true,
      nodePosition: { x: 12, y: 4, mapId: "floor1" },
      actions: [{
        actionId: `drop-${headerId}`,
        actionType: "drop",
        blockingType: "HARD",
        actionParameters: [
          { key: "stationType", value: "floor" },
          { key: "loadType", value: "EPAL" }
        ]
      }]
    }
  ],
  edges: [{
    edgeId: "station-1-2",
    sequenceId: 1,
    startNodeId: "station-1",
    endNodeId: "station-2",
    released: true,
    actions: []
  }]
};
return msg;

Set version to the version your vehicle actually runs. Its factsheet and its own state messages both tell you.

Note the counter keyed by topic. headerId is defined per topic and rises by one per message, so a single shared counter across two vehicles leaves gaps in both their sequences.

Four more details matter. sequenceId counts across nodes and edges together, which is why the edge is 1, sitting between nodes 0 and 2. released: true marks the base, the part of the plan the vehicle should run now, as opposed to the horizon, which is work it knows about but hasn't been told to start. And actionId has to be unique, because that is how the vehicle reports progress back to you in actionStates.

blockingType is the one worth reading twice. It decides whether the vehicle can drive, and whether other actions can run at the same time. HARD means the action runs alone, with no driving and no other actions. SOFT allows other actions but still stops the vehicle. NONE allows both. For a pick or drop you want HARD, and note that SOFT does not let the AGV keep driving, which is the one people get backwards. Version 3.0 adds a fourth, SINGLE, which allows driving but no other actions.

[{"id":"vda-order-trigger","type":"inject","z":"vda-flow","name":"Dispatch order","props":[{"p":"payload"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":210,"y":320,"wires":[["vda-order-build"]]},{"id":"vda-order-build","type":"function","z":"vda-flow","name":"Build order payload","func":"const manufacturer = 'AcmeRobotics';\nconst serialNumber = 'AGV-042';\n\nmsg.topic = `uagv/v2/${manufacturer}/${serialNumber}/order`;\n\n// headerId counts per topic, so key the counter by topic\nconst headerKey = `headerId:${msg.topic}`;\nconst headerId = (flow.get(headerKey) || 0) + 1;\nflow.set(headerKey, headerId);\n\nmsg.payload = {\n  headerId,\n  timestamp: new Date().toISOString(),\n  version: \"2.1.0\",\n  manufacturer,\n  serialNumber,\n  orderId: `order-${Date.now()}`,\n  orderUpdateId: 0,\n  nodes: [\n    { nodeId: \"station-1\", sequenceId: 0, released: true, nodePosition: { x: 0, y: 0, mapId: \"floor1\" }, actions: [{ actionId: `pick-${headerId}`, actionType: \"pick\", blockingType: \"HARD\", actionParameters: [{ key: \"stationType\", value: \"floor\" }, { key: \"loadType\", value: \"EPAL\" }] }] },\n    { nodeId: \"station-2\", sequenceId: 2, released: true, nodePosition: { x: 12, y: 4, mapId: \"floor1\" }, actions: [{ actionId: `drop-${headerId}`, actionType: \"drop\", blockingType: \"HARD\", actionParameters: [{ key: \"stationType\", value: \"floor\" }, { key: \"loadType\", value: \"EPAL\" }] }] }\n  ],\n  edges: [\n    { edgeId: \"station-1-2\", sequenceId: 1, startNodeId: \"station-1\", endNodeId: \"station-2\", released: true, actions: [] }\n  ]\n};\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":440,"y":320,"wires":[["vda-order-out"]]},{"id":"vda-order-out","type":"mqtt out","z":"vda-flow","name":"Send order","topic":"","qos":"0","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"vda-broker","x":680,"y":320,"wires":[]},{"id":"vda-broker","type":"mqtt-broker","name":"VDA 5050 broker","broker":"your-broker.example.com","port":"8883","clientid":"","autoConnect":true,"usetls":true,"verifyservercert":true,"protocolVersion":"4","keepalive":"15","cleansession":true,"autoUnsubscribe":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"sessionExpiry":""}]

This snippet brings its own broker node so it imports on its own. If you paste it into the same tab as the flow from step 2, you'll end up with two. Point this flow at the one you already set up and delete the spare, or the two clients will fight over the same login.

The inject node keeps the import simple. Swap it for a ui-button once your dashboard exists.

Before this touches real AGVs

A flow that works on a test rig is not a production system. Check these first.

• Lock down the broker. Restrict each AGV to its own topic path. Give the wildcard subscription to master control only. Use an allowlist, not a blocklist.
• Use TLS. Factory networks are shared. Fleet commands should not travel in clear text, and leave certificate checking on.
• Never retain order or instantActions. The broker replays retained commands to every vehicle that reconnects. connection and factsheet are the two topics that should be retained.
• Match the standard's QoS levels. QoS 0 for order, instantActions, state, factsheet, and visualization. QoS 1 for connection. If your site does something different, change it on both ends, since MQTT delivers at the lower of the two.
• Set the keep alive to around 15 seconds. It sets the floor on how fast you can detect a vehicle dropping off, so a long keep alive quietly undoes your offline alerting.
• Watch state freshness, not just connection. A vehicle can hold its connection open while stuck or faulted. Alert on errors, on operatingMode leaving AUTOMATIC, and on state messages older than 30 seconds.
• Validate orders before you send them. Check the first node against the vehicle's current position, keep orderId and orderUpdateId unique, and check every action type against the factsheet.
• Cap message size on the broker to what VDA 5050 payloads actually need. It limits the damage a misbehaving client can do.

What's next

You now have the basics: subscribe to fleet state, tell vehicles apart, spot vehicles going offline, and send orders. That's enough for a pilot with two or three AGVs.

The next thing most teams do is replace the button with the WMS or ERP, so orders arrive from whatever already decides what needs moving. After that comes order updates and cancellation, because a job that can't be extended or pulled back mid-route is not much use on a real floor. Both of those need the vehicle's factsheet, so it's worth requesting and storing it early. Master control can then check load capacity, size, and supported actions before it dispatches anything.

Two bigger pieces usually wait until the pilot has proved itself. Logging state history gives you throughput and utilization numbers, which is normally what makes the case for expanding. Publishing that state into a Unified Namespace puts it alongside the rest of your production data, so the systems that plan the work can see where the vehicles are. Traffic rules come last, and only once vehicles from different vendors start sharing aisles, because that is the point where a single master control system stops being a convenience and starts being the reason the floor works at all.

When the pilot becomes a deployment, FlowFuse adds the parts a real fleet system needs: remote device management for edge gateways, snapshots and instant rollback, audit logs, DevOps Pipelines, team access control, and high availability.

Run Every AGV From One System

See how FlowFuse connects AGVs from any vendor over VDA 5050, takes orders from your WMS, and rolls the same master control setup out to every site you run.

Contact Us

This guide covers what manufacturing dashboards do, the metrics they should track, and five dashboard examples, for production, OEE, downtime, quality, and calibration, built with FlowFuse.

What Is a Manufacturing Dashboard?

A manufacturing dashboard is a visual interface for monitoring production performance in real time. It pulls data from factory equipment and business systems (PLCs, SCADA, MES, ERP, databases, sensors, or operator input) into a single view built around production output, machine status, downtime, OEE, quality, and targets. FlowFuse's own Dashboard platform is built specifically for assembling these views without writing custom front-end code.

The key difference between a dashboard and a report is timing. A report tells you what happened after the shift ends. A dashboard shows you what's happening now, while there's still time to change the outcome.

That's also what separates a good dashboard from a cluttered one: it doesn't try to show everything. It shows the specific person using it what they need in order to act, which is exactly why dashboards have become so central to how manufacturers run production.

Why Dashboards Matter in Manufacturing

Production problems get expensive when they stay invisible. A machine that stops, a line falling behind target, or a defect that goes unnoticed can quietly erode throughput, cost, and delivery schedules before anyone catches it.

A shared dashboard closes that gap. Operators see production status as it happens, supervisors track performance across the line, and maintenance teams spot equipment issues sooner. The value isn't the dashboard itself; it's the time saved between a problem occurring and someone responding to it. That's the shift FlowFuse is built to support: turning raw factory data into faster decisions on the floor, whether the source is an MES system or a SCADA historian.

Knowing dashboards matter is one thing. Knowing what belongs on them is another, and that comes down to the metrics behind the view.

Key Metrics Every Manufacturing Dashboard Should Track

The right KPIs depend on the role and the goal, but most production dashboards center on four categories: output, equipment performance, downtime, and quality.

• Production output: actual output against the planned target
• OEE: equipment effectiveness across availability, performance, and quality
• Downtime: lost production time and its biggest contributing causes
• Cycle time: whether machines and processes are running at expected speed
• Quality performance: defects, scrap, rework, and first-pass yield
• WIP levels: where bottlenecks are forming in the production flow

These metrics exist to answer a small set of operational questions: Are we producing at the required rate? Are machines running effectively? Where is time being lost? Are we producing quality parts? If a dashboard can't answer those quickly, it's showing too much, or the wrong things.

What that looks like in practice varies by where the metrics are applied. Here's how these same building blocks show up across five common manufacturing dashboards.

Manufacturing Dashboard Examples

Dashboards work best when they're designed around a specific decision, not a general audience. A production team needs visibility into output and downtime; quality and maintenance teams need a different lens entirely. The five examples below show common patterns, all built with FlowFuse using data from machines, production systems, databases, and industrial protocols, but for using it purpose it uses demo data

1. Production Dashboard (Andon Live)

A production dashboard answers one question in real time: is the line hitting its target? FlowFuse's Andon Live Dashboard gives operators and supervisors a shop-floor view of actual output against target, shift progress, and current line status, so a gap can be caught and addressed before it grows.

FlowFuse Andon Live dashboard showing a target of 100 against an actual count of 84, a delta of 16, stoppage timers, and the current shift for Production Line 33

It typically shows actual production count, target vs. actual output, shift progress, and stoppage information, the same building blocks behind FlowFuse's Andon Task Manager. Because every production environment is different, FlowFuse connects this same dashboard pattern to whatever data sources are already in place, including PLCs, MES systems, production counters, MQTT, and OPC UA.

Ready to deploy: Andon Live Dashboard

2. OEE Dashboard

Where a production dashboard tells you whether output is on target, an OEE dashboard explains why it isn't. FlowFuse's OEE Dashboard combines production and downtime data into one view covering OEE, availability losses, performance losses, quality losses, and trend data over time.

FlowFuse OEE dashboard with gauges for OEE, performance, availability and quality above a downtime summary, production totals, and a table of underperforming machines

That breakdown matters because a low OEE score can come from very different root causes, frequent stops, slow cycle times, or defect rates, and each one needs a different fix. Separating them lets teams target the actual source of the loss instead of chasing a misleading number.

Ready to deploy: OEE Dashboard

3. Downtime Dashboard

Availability losses are usually the biggest piece of that OEE picture, which is why they tend to warrant a dedicated view of their own. Downtime is the single biggest drain on production capacity, and the real question isn't just when machines stop, it's why. FlowFuse's Downtime Tracking Dashboard captures stop events as they happen and turns them into a live view of downtime duration, causes, and impact on availability, rather than something pieced together from manual spreadsheets after the fact.

FlowFuse downtime tracking dashboard listing open stoppages by machine with start times, how long each has been open, and a button to close the event and log a reason

That shift, from reviewing downtime after a shift to tracking it in real time, is what lets teams move from reacting to failures toward reducing what causes them.

Build it: Build a Machine Downtime Tracking Application

4. Quality Dashboard (Defect & Quality Monitoring)

Quality losses need the same treatment. A quality dashboard shows where defects are happening and what's driving them. FlowFuse's Defect & Quality Monitoring Dashboard combines defect data, production information, and quality KPIs, including defect trends, defect categories, first-pass yield, cost of poor quality, and a Pareto breakdown of causes, into one view.

FlowFuse defect and quality monitoring dashboard with a Pareto chart of defect types, a root cause breakdown, severity and disposition splits, and SLA resolution times

The Pareto view tends to be the most useful part: it isolates the small number of issues responsible for most of the quality loss, so improvement effort goes where it actually pays off, instead of spreading thin across every defect type. Pairing it with statistical process control catches quality drift before it produces a defect at all.

Build it: Build a Defect Tracking and Quality Monitoring Dashboard

5. Calibration Dashboard

Defects aren't always caused by the process itself; sometimes the measurement equipment used to catch them is the problem. Where measurement accuracy affects product quality and compliance, instrument calibration tracking can't run on spreadsheets. FlowFuse's Calibration Management Dashboard gives teams a live view of measurement equipment status (what's ready, what's due, what's overdue) along with calibration history and compliance status, cutting the risk of equipment running outside its required window.

FlowFuse calibration management dashboard showing 120 instruments split into valid, due soon and overdue, a 73.3% compliance rate, and a table of overdue tools by department

Build it: Tracking Instrument Calibration with a Digital Dashboard

Manufacturing Dashboard Design Best Practices

Having the right dashboard type for the job is only half the equation. How it's designed determines whether anyone actually uses it. A manufacturing dashboard should make decisions easier, not add more information to review, and the best dashboards are designed around the people using them and the actions they need to take.

Key principles include:

• Design for the user: operators, supervisors, and managers need different views based on their responsibilities
• Focus on actionable metrics: every KPI should help identify a problem, measure progress, or support a decision
• Keep important information visible: production status, downtime, and quality issues should be clear without searching through multiple screens
• Avoid unnecessary complexity: too many charts and metrics make important information harder to find
• Support drill-downs: start with a clear overview, then allow users to investigate the details behind an issue

A successful manufacturing dashboard is not the one with the most data. It is the one that helps the right person understand the situation and act quickly.

One design decision worth calling out on its own is timing: not every dashboard should show the same moment in time.

Real-Time vs. Historical Manufacturing Dashboards

Not every manufacturing decision requires the same type of dashboard:

• Real-time dashboards are built for immediate action, showing what is happening on the shop floor right now, such as current production output, machine status, downtime events, and quality issues
• Historical dashboards are built for analysis, helping teams identify trends, compare performance over time, and understand recurring problems

Manufacturers often need both. Real-time dashboards keep production running today, while historical dashboards help improve how production runs tomorrow.

Timing is one axis a dashboard can vary on. Who it's built for is another, and that's a separate design decision entirely.

Single Source of Truth vs. User-Specific Dashboards

Manufacturing dashboards can follow two common design patterns depending on how they are used.

A single source of truth dashboard gives everyone the same operational view. This works well for Andon boards, production displays, and OEE dashboards, where teams need a shared understanding of factory performance.

Single source of truth pattern: a device populates both a ui-chart and a database, and the chart displays the same dashboard to all clients

A user-specific dashboard provides different information based on the user's role or workflow. Operators, for example, may see production status and tasks, while maintenance teams see equipment issues and service information. This pattern relies on the dashboard knowing who's looking at it, which is what FlowFuse's multi-user addon is built to support.

User-specific pattern: opening the dashboard fires a ui-event that queries the database using the viewer's client ID, so the chart displays data for that user only

The right approach depends on the decision the dashboard needs to support. Some manufacturing applications use one shared view; others combine shared visibility with role-specific information. Either way, someone has to actually connect the underlying data and build the thing, which is where FlowFuse comes in.

Building Manufacturing Dashboards with FlowFuse

The challenge in manufacturing is rarely a lack of data. Most factories already generate information from machines, PLCs, sensors, and business systems. The real challenge is connecting that data and turning it into something teams can use, whether that's a single shared view or a set of role-specific ones.

FlowFuse helps manufacturers build operational dashboards by connecting industrial data sources, processing production information, and creating applications for the shop floor. A typical workflow includes:

• Connect data: bring in data from PLCs, machines, databases, and protocols such as MQTT, OPC UA, and Modbus
• Process data: convert production events, downtime, and quality records into useful metrics
• Build dashboards: create views for operators, supervisors, and managers

Once a dashboard is built, teams can manage and deploy it across multiple lines, or facilities without rebuilding it from scratch, to keep every deployment in sync. The goal is simple: turn factory data into reusable applications that improve operational visibility.

Conclusion

Manufacturing dashboards give teams a shared view of what is happening on the shop floor. They help operators respond faster, supervisors understand performance, and engineers identify opportunities for improvement.

From production tracking and OEE monitoring to downtime analysis, quality management, and calibration control, the right dashboard connects operational data with the decisions teams need to make, whether that decision needs a real-time or historical view, a shared display or a role-specific one.

The goal is not to create more screens. It is to create better visibility into production and give teams the information they need to keep improving. With FlowFuse, manufacturers can connect existing factory data, build operational applications, and scale successful dashboards across machines, lines, and facilities.

Build Your Manufacturing Dashboard

Connect factory data and create real-time dashboards for production, OEE, downtime, and quality with FlowFuse.

Book a Demo

FlowFuse is an industrial application platform that works with manufacturers who face this daily. Bosch, Cargill, Moderna, Worthington Steel, and 25+ other enterprise manufacturers use FlowFuse to build and standardize operational applications across sites, including the real-time monitoring that makes statistical process control practical at scale. Customers have documented a 50% reduction in scrap rate, and the platform is SOC 2 Type 1 and Type 2 certified.

This article covers what statistical process control is, how SPC charts and control charts work, how SPC applies across manufacturing sites, and where Six Sigma SPC and SPC software fit in.

SPC control chart with a table of measurements

How Statistical Process Control Works: SPC Charts And Control Charts Explained

Statistical process control is a method for monitoring a manufacturing process using data collected while it runs, rather than waiting to inspect the finished product. It works by plotting measurements from the process, such as part dimensions, temperature, or pressure, onto a control chart over time. That chart includes a center line at the process average and upper and lower control limits placed three sigma either side of it, derived from the short-term variation within the process itself rather than from a fixed specification. Control limits and specification limits are not the same thing: a process can run entirely inside its control limits and still make parts outside spec, which is why an SPC signal means the process changed, not that a given part is bad.

The right control chart depends on how the data is collected. X-bar R and X-bar S charts are built from sample subgroups, small batches of readings pulled close together in time, and plot the subgroup average alongside its range (R) or standard deviation (S). When it isn't practical to pull parts into subgroups, an I-MR chart plots individual readings and the moving range between consecutive points instead. Picking the chart that matches how the data is actually collected is one of the more common places SPC implementations go wrong.

SPC charts make it possible to see the difference between common cause variation, which is expected and should not be adjusted for point by point, and special cause variation, which signals something has changed and needs investigation. A single point falling outside the control limits is one signal to intervene, but a non-random pattern building up over several points, such as a run drifting steadily in one direction or a cluster of points hugging one side of the center line, is also a signal. Quality teams formalize these checks using the Western Electric Rules or Nelson Rules, which pair the out-of-limit test with additional tests for runs, trends, and points clustering in the outer bands of the chart. Most of those tests fire on a sequence of points that are each individually inside the limits, which is why charts running these rules divide the space into one and two sigma bands rather than just plotting the outer limits. This is the core discipline behind statistical process control: catching drift while it is still correctable, not after a batch has already failed inspection.

Building and reading control charts by hand across dozens of machines and lines is slow and does not scale well across multiple sites. For a deeper look at how these charts are typically built and interpreted in practice, see Statistical Process Control (SPC): Benefits and Implementation Guide.

Manufacturing quality dashboard showing an SPC chart for bearing diameter and process capability metrics.

SPC In Manufacturing: Turning Shop Floor Data Into Process Control

Statistical process control only works if it has a steady stream of accurate data from the process it is monitoring. In most plants, that data lives across PLCs, sensors, MES systems, and manual entry points that were never designed to talk to each other. Getting SPC to work at scale depends on solving that connectivity problem.

Where SPC Data Actually Comes From

Process data for SPC charts typically comes from PLCs, edge devices, and sensors tracking variables like temperature, torque, or dimensional tolerances. Pulling that data into a usable chart requires IT/OT connectivity that moves it securely from the shop floor to wherever it is analyzed, without brittle point-to-point integrations that break every time equipment changes. FlowFuse provides that layer. It reads from PLCs, sensors, and MES over OPC UA, MQTT, or Modbus, so the chart updates from live process data rather than from manual entry.

Deploying SPC Across Multiple Sites Without Rebuilding

What works on one line will not scale to fifty unless the underlying logic can be standardized. FlowFuse customers deploy SPC monitoring using a build once, run everywhere approach, standardizing a proven workflow on one machine and rolling it out across 20+ manufacturing sites from a single platform, without rebuilding it at each new location.

Working With Brownfield Systems Instead Of Replacing Them

Most plants run a mix of legacy PLCs, older MES installations, and newer edge hardware. Rather than requiring a full system replacement, SPC monitoring can extend a brownfield environment as-is. This staged approach avoids the all-or-nothing rollout risk described in All-or-Nothing Manufacturing Software Is Killing Your Agility.

Six Sigma SPC And Modern SPC Software: Choosing The Right Tools

Statistical process control does not exist in isolation. It works alongside broader quality methodologies and depends on the right software to make the data usable at scale. Choosing how SPC fits into your quality program and which tools support it are two separate decisions that shape how much value you get from the practice.

SPC's Role In Six Sigma Methodology

Six Sigma SPC refers to using control charts within the Six Sigma framework, particularly during the Control phase of DMAIC. The chart provides the ongoing measurement that shows whether an improvement is holding, rather than a one-time check to declare the project complete.

What To Look For In SPC Software

SPC software should connect directly to the data sources already on your shop floor rather than requiring manual data entry. Look for real-time monitoring, support for brownfield environments with existing PLCs and MES systems, and a way to deploy the same setup across multiple sites without reconfiguring it at each one. FlowFuse covers all three: connect the measurement over OPC UA, MQTT, or Modbus, chart it with calculated limits and alerts on a dashboard at the line, then roll that same setup out everywhere else.

SPC Alongside Other Root Cause Tools

Control charts show you when a process has drifted, but they do not always explain why. Pairing SPC with other root cause analysis tools helps close that gap. For a breakdown of one commonly used tool for identifying the biggest contributors to a quality issue, see Pareto Chart & Diagram for Manufacturing.

Final Thoughts

Statistical process control gives manufacturers a way to catch problems while they are still cheap to fix, but only if the underlying data actually reaches the people and systems that need it. That is often the harder part. Most plants already have the sensors and PLCs generating the right signals; what is missing is a reliable way to move that data from the shop floor into a usable chart, consistently, across every line and every site.

This is where an industrial application platform like FlowFuse fits. It connects the equipment, and your team builds the chart and the alerts on top of that data by dragging nodes, not writing code. It runs on the line, and you deploy the same setup at the next plant instead of rebuilding it. For manufacturers managing quality across dozens of sites, that difference determines whether SPC becomes a routine part of operations or another initiative that never quite scales past the pilot line.

Sources

• American Society for Quality (ASQ). "What Is Statistical Process Control? SPC Quality Tools."
• American Society for Quality (ASQ). "Understanding Variation."
• American Society for Quality (ASQ). "Control Chart – Statistical Process Control Charts."
• International Organization for Standardization. "ISO 7870-2:2023 — Control Charts, Part 2: Shewhart Control Charts."
• NIST/SEMATECH e-Handbook of Statistical Methods. "Shewhart X-bar and R and S Control Charts."
• NIST/SEMATECH e-Handbook of Statistical Methods. "Individuals Control Charts."

Bring SPC To Every Line You Run

See how FlowFuse connects your PLCs, MES, and SCADA systems, then builds real-time SPC charts and rolls out the same setup across every site.

Contact Us

Most registers also have a status field next to those dates, and reading it seems like the obvious move. But whatever writes that field can fall behind. Then the dashboard reports a compliant plant while due dates quietly pass. This build works out every figure from the due date instead, and counts how often the stored status disagrees with it.

For background on calibration records, including what they should contain, how calibration intervals are determined, and why overdue instruments matter, see What Is Instrument Calibration (Equipment Calibration)?.

A screen in the quality office is only half the job, though. The moment that matters is when someone picks up a torque wrench, and that person isn't looking at a dashboard. So the same check also runs behind a camera at the station: scan the label, get a verdict.

The finished dashboard: filters in the app bar, KPI row, and asset detail table on one page.

In this article, we'll build a calibration application in FlowFuse. It will show plant-level compliance figures, let you filter by department and time window, give an asset-level view of what's due and when, and offer a camera-based tool check for the shop floor.

Note: This tutorial reads from a calibration_assets table in FlowFuse Tables, filled with sample instruments. Everything here works the same against a real calibration register, a CMMS, or an ERP endpoint. Only the query nodes change.

You can interact with the live demo here: .

What You'll Need

Before you start building, get these ready:

• A FlowFuse account. Sign up for FlowFuse Cloud, or use a self-hosted instance.
• A FlowFuse instance up and running. If you don't have one yet, create a new instance from your FlowFuse Platform.
• FlowFuse Dashboard installed. This tutorial uses @flowfuse/node-red-dashboard nodes (ui-template, ui-event, ui-button, ui-markdown, ui-notification, ui-page, ui-group, ui-theme) to build both pages. Install it from the Palette Manager if it isn't already in your instance.
• A webcam node and an OCR node. The Tool Check page uses @sumit_shinde_84/node-red-dashboard-2-ui-webcam to capture the label and @sumit_shinde_84/node-red-contrib-simple-ocr to read it. Install both from the Palette Manager.
• A device with a camera for the Tool Check page, since the scanner works through the browser.

Note: FlowFuse Tables is available to Enterprise tier teams on FlowFuse Cloud, and to Enterprise licensed self-hosted teams running on Kubernetes. If you're on a different tier, use any external database instead, such as Postgres or MySQL, with the standard database nodes from the palette. The SQL here is standard PostgreSQL, and the widgets only care about the shape of the rows, not where they came from.

How the Application Works

Before we build anything, let's walk through what the application does. There are two pages, and one idea holding them together.

1. Home. A quality engineer picks a department and how far ahead to look. Six figures across the top show how much equipment there is, and how much of it is valid, due soon, overdue, coming up in the chosen window, and compliant overall. Below that is a list of instruments due inside that window, most urgent first, each with its status, due date, and days remaining. The cards describe the whole register for the chosen department. Only the Upcoming figure and the table below respond to the time window.
2. Tool Check. An operator holds a calibration label up to the camera and presses SCAN. The app reads the tool ID off the label, looks it up, and shows an answer in the middle of the screen: OK to use, Do not use, Not in register, or Label not readable. No numbers to interpret and no dashboard to search through.

The due date is the single source of truth for the whole application. Every KPI figure, every status chip in the table, and the scanner's verdict all come from comparing that date to the current time. That is what stops the office screen and the station gate from ever telling two different stories about the same tool.

Importing the Simulated Flow

Instead of pointing the application at a live calibration register, we'll generate one.

1. Import the following flow into FlowFuse and click Deploy.
2. Click the trigger on Create Table, then the trigger on Generate & Insert Automotive Calibration Dataset. Drop Table is there for when you want to start over from scratch.

That gives you 120 instruments with IDs from TL-0001 to TL-0120, spread across eight departments: roughly 70% valid, 20% due soon, and 10% overdue. The eight department names are the same ones the filter dropdown offers later.

Everything we build reads from these columns:

Note: Your register will likely name these columns differently. Alias your columns in the SELECT list, as in SELECT gauge_ref AS tool_id, cal_due_date AS next_due_ts, ..., and every widget will still work. Only the due-date column is essential.

Before running the generator, set its reference date near the top of the function, const today = new Date('2026-07-28T10:00:00'), to roughly today's date. Otherwise everything will land relative to a date in the past.

Setting Up the Dashboard Layout

The application has two pages and four groups. Most widgets sit inside a named group. The filter bar is scoped to the page instead, because it appears in the app bar rather than in the grid. See the Dashboard layout docs if you're new to how pages, groups, and bases relate.

1. Create two ui-page nodes. The Dashboard automatically creates a base dashboard the first time you add a Dashboard node to the canvas.
   • Home (path: /home): the calibration status dashboard. Set the layout to Grid.
   • Tool Check (path: /tool-check): the scanner. Set the layout to Notebook.
2. On the Home page, create two ui-group nodes, both 12 columns wide with Show title turned off:
   • KPIs (order 1)
   • Asset Detail (order 2)
3. On the Tool Check page, create two more ui-group nodes, also 12 columns wide with titles off:
   • Scanner (order 1)
   • Verdict (order 2)
4. Open the ui-base node and set Header Content to page. This shows the app bar, which the filter widget needs.
5. Set up the ui-theme to suit your needs. The dashboard already comes with a default theme, which you can use for now.

Building the Filter Bar

Two controls drive the page: which department, and how far ahead to look. Both sit in the app bar rather than the grid, so no row of the page is used up by a dropdown.

The department list is read from the register itself, not typed in by hand, so adding a department next year doesn't mean editing a flow. The time windows are fixed, because "next 30 days" is a choice this application makes rather than something the data tells you.

1. Add a ui-event node named "Page Load / Refresh Event" and select your "My Dashboard" ui-base. It fires whenever a page loads.
2. Add a tables-query node named "Load Departments":

Tip: You don't have to write the SQL yourself either. Use FlowFuse Expert and describe what you want the query to return in plain English, and it will generate the SQL for you.

SELECT DISTINCT department
FROM calibration_assets
WHERE department IS NOT NULL
  AND btrim(department) <> ''
ORDER BY department;

1. Import the App Header Filters ui-template below, set its type to Widget (Page-Scoped), select the Home page, and turn off Pass through messages from input to output. The complete component is provided below, so there's no need to build it yourself. It shows two dropdowns in the header using Vue's Teleport: Department, filled from the query above, and Time Window. It opens on All departments and Next 90 days, sends { department, timeWindow } on every change, and sends the same on load so the dropdowns and the data always agree.

Tip: Whenever you need a custom Dashboard widget, you don't have to write the Vue code yourself. Use FlowFuse Expert and describe the widget in plain English, and it will generate the ui-template for you.

4. Add a change node named "Save Filters to Global Context" and set the persistent global filters to msg.payload.
5. Add a link out node named "Filters Changed". This is what makes the page respond right away. Changing a dropdown writes the new selection to context, but nothing would redraw until the next poll tick, so the operator would be looking at stale numbers for up to fifteen seconds. The link carries the change straight into the next flow, which re-runs its query and refreshes the page.
6. Wire the nodes: Page Load / Refresh Event → Load Departments → App Header Filters → Save Filters to Global Context → Filters Changed.

The Department and Time Window dropdowns shown in the app bar, with departments read from the register.

Working Out the KPI Figures from the Due Dates

This is where we stop using the register's status column. Every figure on the page comes from comparing next_due_ts against the current time, and one extra count reports how often the stored status disagrees with that comparison.

1. Add an inject node named "Poll Data (15 sec)", set it to repeat every 15 seconds and to fire once shortly after deploy, so the page has data before the first tick.
2. Add a link in node named "Filters Changed" and point it at the link out from the filter bar.
3. Add a change node named "Set Params". This maps the saved filters onto the $department and $timeWindow parameters the SQL reads. Set three rules, in order:
   • Set queryParameters to {} (JSON): starts clean so old values don't linger.
   • Set queryParameters.department to filters.department (global persistent).
   • Set queryParameters.timeWindow to filters.timeWindow (global persistent).

The "Set Params" change node open in the edit panel, all three rules visible.

1. Add a tables-query node named "KPI Query":

SELECT
    -- Sent back so the cards label themselves from the data on screen,
    -- not from whatever the dropdowns happen to show. COALESCE covers the
    -- first poll after deploy, before any browser has sent a selection.
    COALESCE($department::text, 'All')          AS filter_department,
    COALESCE($timeWindow::text, 'Next 90 days') AS filter_window,

    COUNT(*) AS total_assets,

    -- Buckets worked out from next_due_ts instead of the stored status column,
    -- which drifts whenever whatever writes it falls behind. These three
    -- don't overlap, and add up to total_assets. The 30-day threshold is a
    -- policy decision, not a view setting: it does not change with the dropdown.
    COUNT(*) FILTER (
        WHERE next_due_ts > NOW() + INTERVAL '30 days'
    ) AS valid_assets,

    COUNT(*) FILTER (
        WHERE next_due_ts >= NOW()
          AND next_due_ts <= NOW() + INTERVAL '30 days'
    ) AS due_soon_assets,

    COUNT(*) FILTER (
        WHERE next_due_ts < NOW()
    ) AS overdue_assets,

    -- The only figure the Time Window dropdown affects. It sends a label, so
    -- it maps to an interval here; ELSE also catches an unrecognised label.
    COUNT(*) FILTER (
        WHERE next_due_ts >= NOW()
          AND next_due_ts <= NOW() + (
              CASE COALESCE($timeWindow::text, 'Next 90 days')
                  WHEN 'Next 7 days'  THEN INTERVAL '7 days'
                  WHEN 'Next 30 days' THEN INTERVAL '30 days'
                  WHEN 'Next 90 days' THEN INTERVAL '90 days'
                  WHEN 'All future'   THEN INTERVAL '100 years'
                  ELSE INTERVAL '90 days'
              END
          )
    ) AS due_in_window,

    COUNT(*) FILTER (
        WHERE next_due_ts BETWEEN NOW()
                            AND NOW() + INTERVAL '7 days'
    ) AS due_next_7_days,

    -- Compliance means "inside its calibration interval", which includes
    -- tools due soon, since they have not expired yet.
    ROUND(
        COUNT(*) FILTER (WHERE next_due_ts >= NOW()) * 100.0
        / NULLIF(COUNT(*), 0),
        1
    ) AS valid_percentage,

    -- Counts records where the stored status and the live date disagree, so
    -- the drift shows up on the dashboard instead of staying hidden.
    COUNT(*) FILTER (
        WHERE (status = 'Overdue') <> (next_due_ts < NOW())
    ) AS stale_status_count

FROM calibration_assets
-- Driven by the Department dropdown; 'All' turns the filter off.
WHERE (COALESCE($department::text, 'All') = 'All'
       OR department = $department::text);

stale_status_count is the figure worth watching. It counts the rows where the stored status and the due date disagree, which is the number that justifies leaving the status column out of every other calculation.

5. Add a link out node named "Refresh Asset Table" and wire it from Set Params, so the table below runs on the same selection instead of working it out again.
6. Import the KPI Cards ui-template below and assign it to the KPIs group. The complete component is provided below, so there's no need to build it yourself. It shows a header with the active filter and a last-updated time, six cards for total equipment, valid, due soon, overdue, upcoming and compliance, and a three-line summary strip. When stale_status_count is above zero it also shows a warning banner naming the number of drifted records.

7. Wire the nodes: Poll Data (15 sec) → Set Params → KPI Query → KPI Cards, and Filters Changed → Set Params.

Deploy and open /home. The six cards fill in, and on the seeded data the drift banner should appear right away, because the generator creates records whose stored status no longer matches their due date.

Six figures worked out from the due dates, with the active filter and refresh time shown in the header.

Listing Every Instrument with Days Remaining

The cards tell a supervisor how much is overdue. This table tells them which tools, so someone can actually go and collect them. It's a worklist rather than a full register dump, which is why the time window scopes it down.

1. Add a link in node named "Refresh Asset Table" and point it at the link out from the KPI flow. Taking the filters from that message instead of reading context again is what keeps the table and the cards working from the same selection.
2. Add a tables-query node named "Asset Rows":

SELECT
    -- Sent back so the table can state its own scope in the header.
    COALESCE($timeWindow::text, 'Next 90 days') AS filter_window,

    tool_id,
    equipment_name,
    department,
    location,
    serial_number,

    -- Same 30-day policy threshold as the KPI buckets, so a tool never reads
    -- one status here and another elsewhere. The bare column name still
    -- refers to the table column.
    CASE
        WHEN next_due_ts < NOW() THEN 'Overdue'
        WHEN next_due_ts <= NOW() + INTERVAL '30 days' THEN 'DueSoon'
        ELSE 'Valid'
    END AS status,
    status AS stored_status,

    last_calibration_ts,
    next_due_ts,
    calibration_interval_months,
    calibration_lab,
    certificate_no,

    -- Negative for anything already past due, which the widget shows as
    -- "12d overdue" rather than "-12d".
    (next_due_ts::date - CURRENT_DATE) AS days_remaining

FROM calibration_assets

-- This is a worklist, not the whole register: the window scopes it to what
-- needs attention. Overdue tools have a past due date, so the upper bound
-- already includes them; no separate clause needed.
WHERE (COALESCE($department::text, 'All') = 'All'
       OR department = $department::text)
  AND next_due_ts <= NOW() + (
      CASE COALESCE($timeWindow::text, 'Next 90 days')
          WHEN 'Next 7 days'  THEN INTERVAL '7 days'
          WHEN 'Next 30 days' THEN INTERVAL '30 days'
          WHEN 'Next 90 days' THEN INTERVAL '90 days'
          WHEN 'All future'   THEN INTERVAL '100 years'
          ELSE INTERVAL '90 days'
      END
  )

ORDER BY next_due_ts ASC
LIMIT 500;

Sorting by due date ascending puts the worst offenders at the top, which is the only order that makes a calibration list useful. stored_status is included but not used by the widget, so it's there when you want to see exactly which records have drifted rather than just how many.

3. Import the Asset Table ui-template below and assign it to the Asset Detail group. The complete component is provided below, so there's no need to build it yourself. It shows a Vuetify data table with a status chip per row, formatted dates, and days remaining shown as "12d overdue" or "due today". Its header names the active window, so it's clear the list is scoped rather than the full register. Above the table sit a search box and a status toggle with live counts for Overdue, Due soon and Valid, filtering the rows already on the page without hitting the database again. The Department column hides itself when every row belongs to the same department, since a single-department view makes it a fixed value.

4. Wire the nodes: Refresh Asset Table → Asset Rows → Asset Table.

Deploy and open /home. The table fills in below the cards, most urgent first, with its header naming the window it covers. Change a dropdown and both halves of the page update together.

Instruments due inside the selected window, soonest due first, with status chips and days remaining.

Note: The toggle counts describe the table, not the register, so they will read lower than the cards above. That's the point of the split: the cards answer "how are we doing," and the table answers "what needs collecting." Select All future and the two match.

Checking a Tool at the Station

A dashboard in the quality office doesn't reach the person about to pick up a torque wrench. This page does: hold the calibration label to a camera, press one button, get one answer.

1. Add a ui-button node named "Scan Label Button" in the Verdict group, order 1. Set the label to SCAN and the payload to the string capture, which tells the webcam to take a frame.
2. Add a ui-webcam node in the Scanner group, with Pass through and QR detection both off. Leave image width, height and quality blank to use the camera's defaults.
3. Add a change node that sets msg.payload to msg.payload.image. The webcam outputs an object; the OCR node just needs the image.
4. Add a simple-ocr node, then a link out / link in pair to carry the result down to the next row of the canvas.

Tip: OCR keeps this tutorial hardware-free, but if your labels have a barcode or QR code, scanning one is faster and far more reliable than reading printed text. Swap the camera and OCR nodes for a barcode scanner and feed the decoded ID straight into "Set Tool ID," and everything downstream will keep working. You can also drop "Extract Tool ID" and "Scan Valid?", since a scanner either returns an ID or nothing.

5. Add a function node named "Extract Tool ID":

Tip: The same goes for function node logic. Describe what you want the function to do in plain English, and FlowFuse Expert will generate the code for you.

// Stickers read TL followed by four digits. OCR loses the hyphen and swaps
// look-alike characters, so normalise before matching.
const text = String(msg.payload?.text || msg.payload || '');
const flat = text.toUpperCase().replace(/[^A-Z0-9]/g, '');

const FIXES = { O: '0', Q: '0', I: '1', L: '1', S: '5', B: '8', Z: '2', G: '6' };

const m = flat.match(/T[L1I]([A-Z0-9]{4})/);
const digits = m ? m[1].replace(/[A-Z]/g, c => FIXES[c] || c) : '';
const toolId = /^\d{4}$/.test(digits) ? 'TL-' + digits : null;

msg.payload = {
    success: !!toolId,
    toolId,
    // Shows what OCR actually read when a scan fails.
    rawText: text.replace(/\s+/g, ' ').trim()
};
return msg;

Wire a debug node to this as well and leave it enabled. When a scan fails, rawText shows what the camera actually read, which is the difference between fixing the label and guessing at it.

Note: The pattern above expects TL followed by four digits, because that's what the seeded data uses. Your labels almost certainly look different: a different prefix, more digits, a plant code, or no letters at all. Change the regex and the length check to match your own sticker format before you test this on real tools, or every scan will come back as Label not readable.

6. Add a switch node named "Scan Valid?" on payload.success, with is true on the first output and otherwise on the second. A failed read skips the database entirely.
7. Add a change node named "Set Tool ID" on the true branch, with two rules:
   • Set queryParameters to the JSONata { "toolId": $trim(payload.toolId) }
   • Set scannedId to the JSONata $trim(payload.toolId), so the ID survives to the verdict even when no row comes back
8. Add a tables-query node named "Look Up Tool":

SELECT
    tool_id,
    equipment_name,

    -- The safety answer comes from the date, not the stored status flag,
    -- which can go stale if whatever recalculates it falls behind.
    (next_due_ts >= NOW()) AS ok_to_use

FROM calibration_assets

-- Deliberately NOT filtered by department or time window: a scan is a
-- lookup of one tool, not a view. Case, padding and hyphens are all
-- normalised away, at the cost of the index, which is fine at register size.
WHERE replace(upper(btrim(tool_id)), '-', '')
    = replace(upper(btrim($toolId)), '-', '');

9. Add a function node named "Build Verdict". Wire both the query output and the switch's second output into it:

// Two paths feed this node: a completed lookup, and a failed scan routed
// straight past the query. Tell them apart by payload shape.
const p = msg.payload;

if (p?.success === false) {
    msg.payload = { state: 'scan_failed' };
    return msg;
}

const row = Array.isArray(p) ? p[0] : p;

if (!row?.tool_id) {
    msg.payload = { state: 'not_found', scannedId: msg.scannedId };
    return msg;
}

msg.payload = {
    state: row.ok_to_use ? 'ok' : 'blocked',
    tool: row
};
return msg;

Four states come out of it, and they're the only four an operator ever sees:

10. Add a function node named "Format Notification". It shows what was scanned, the verdict, and what to do about it:

const v = msg.payload || {};
const t = v.tool;

// timeout 0 on 'blocked' is deliberate: an expired-tool verdict must be
// dismissed by a person, not fade out while nobody is watching.
const VERDICTS = {
    ok:          { text: 'OK to use',          do: 'Carry on.',                        color: '#15803d', timeout: 8 },
    blocked:     { text: 'Do not use',         do: 'Tag it and tell your supervisor.',  color: '#b3261e', timeout: 0 },
    not_found:   { text: 'Not in register',    do: 'Tell your supervisor.',             color: '#b45309', timeout: 12 },
    scan_failed: { text: 'Label not readable', do: 'Wipe the label and scan again.',    color: '#b45309', timeout: 8 }
};

const cfg = VERDICTS[v.state] || VERDICTS.scan_failed;

// ui-notification renders raw HTML, so escape what came from the register.
const esc = s => String(s ?? '').replace(/[<>&"]/g,
    c => ({ '<': '&lt;', '>': '&gt;', '&': '&amp;', '"': '&quot;' }[c]));

const scanned = t
    ? esc(t.tool_id) + ' - ' + esc(t.equipment_name)
    : esc(v.scannedId || 'No ID read');

msg.payload = `<div style="font-size:1rem;opacity:.85">${scanned}</div>`
    + `<div style="font-size:2rem;font-weight:700;margin:4px 0">${cfg.text}</div>`
    + `<div style="font-size:1rem">${cfg.do}</div>`;

msg.color = cfg.color;
msg.timeout = cfg.timeout;
return msg;

11. Add a ui-notification node named "Verdict" and select your ui-base. Set Position to center center, turn off Use default colour, turn on Show countdown, Allow dismiss and Allow raw HTML. The display time and colour on the node are only fallbacks; msg.timeout and msg.color override them for each verdict.
12. Add a ui-markdown node named "Tool Check Instructions" in the Verdict group, order 2:

<div style="text-align: center">

### Before you use a tool

</div>

**1** Hold the calibration label flat in front of the camera.

**2** Press **SCAN**.

**3** Read the message in the middle of the screen.

---

**"OK to use"**: the tool is inside its calibration interval. Carry on.

**"Do not use"**: set the tool aside, tag it, and tell your supervisor. If you have already used it on parts today, say so; those measurements need checking.

**"Not in register"** or **"Label not readable"**: wipe the label and scan again. If it fails twice, tell your supervisor.

---

Anything other than **"OK to use"** means the tool stays out of production.

13. Wire the nodes: Scan Label Button → ui-webcam → change → simple-ocr → Extract Tool ID → Scan Valid?, then Scan Valid? (true) → Set Tool ID → Look Up Tool → Build Verdict, and Scan Valid? (otherwise) → Build Verdict → Format Notification → Verdict.

Deploy and open /tool-check on a device with a camera. Hold a label reading TL-0007, or one in whatever format you configured above, in front of it and press SCAN. Whatever the seeded data says about that tool is what comes back. Because the verdict compares the date instead of reading the status column, it will always agree with the Home page.

The scanner page: camera preview, one button, and the operator instructions below it.

What Next

You've built a calibration application that answers two different questions from the same data. The office screen tells a quality engineer how the plant stands and what needs collecting this week. The station screen tells an operator whether the tool in their hand is fit to use. Both read the due date, so neither can drift from the other.

Right now it runs on generated data. To go live, remove the simulator flow and point the queries at your own register. Just alias your column names in the SELECT lists, and everything downstream keeps working. If your records sit in a CMMS or ERP behind an API, swap the query nodes for http request nodes and nothing else changes. From there, the obvious next steps are ones the register already supports: email the overdue list to the calibration lab each Monday, or notify someone the moment a critical gauge goes overdue instead of waiting for a screen to be looked at. The same approach works for defect tracking and downtime too, and for the other manufacturing dashboards teams build on the same data. It also pairs with floor-level checks such as a layered process audit, where a tool's calibration status is exactly the kind of item this dashboard can hand the auditor an answer for instead of a lookup. See how manufacturers are using it on our automotive solutions page.

See What Your Team Can Build

See it live with our team, and the variety of applications you can build without coding expertise, then scale them across your plant in a single click.

Contact Us

That sounds straightforward, and at the bench it usually is. Accredited calibration laboratories perform this work every day with well-established procedures.

The problems that create audit findings and production risk tend to appear elsewhere: an overdue gauge that stayed in service, a certificate that cannot be linked to a specific tool, a due date that was never updated, or a failed instrument whose previous measurements were never reviewed.

A caliper that reads 0.03 mm low can pass parts that are actually oversize. Nothing on the line may look unusual while that caliper is being used. The risk appears later, when those parts are assembled, shipped, or returned.

This article explains what calibration is, how it differs from verification and adjustment, what a calibration record should contain, and how manufacturers can manage calibration status more effectively across the plant.

What Is Instrument Calibration?

Calibration is the process of comparing an instrument with a reference standard and recording the difference between the two at defined test points.

A complete calibration involves five elements: the instrument under test, a reference standard with better accuracy, measurements taken at selected points across the instrument's range, the deviation between the instrument and the reference, and a documented record of the result.

Notice what is not included in that definition: repairing or adjusting the instrument. Calibration measures performance; it does not automatically correct it.

You will also see the terms equipment calibration, instrument calibration, and gauge calibration. In manufacturing they are generally used to describe the same activity.

Calibration vs. Verification vs. Adjustment vs. Validation

These terms are often used interchangeably, but they describe different activities.

A calibration certificate may contain both calibration data and a verification statement such as PASS or FAIL. The pass/fail decision is based on a stated tolerance; it is not the same thing as the calibration itself.

An adjustment changes the instrument. After an adjustment, the instrument should be calibrated again so the final condition is documented.

Validation is broader than calibration. It addresses whether a process works reliably, not whether one instrument reads correctly.

How Traceability Works

A calibration result is meaningful only when the reference standard is traceable to recognized measurement standards.

The traceability chain runs from the SI unit, through a national metrology institute such as NIST, NPL, or PTB, through an accredited calibration laboratory, through any working standards used in the plant, and finally to the instrument being calibrated.

Each link in that chain must be documented. The reference standard should have significantly better accuracy than the instrument it is checking.

When selecting an external laboratory, a practical check is accreditation to ISO/IEC 17025 with a scope that covers the measurement discipline you need, such as pressure, torque, temperature, dimensional measurement, or electrical measurement.

What a Calibration Record Should Contain

Many organizations store only the certificate date and the pass/fail result. That is rarely enough for traceability, audits, or impact assessment.

A useful calibration record identifies the asset and serial number, records where the instrument is used, and stores the last calibration date, next due date, and interval. It should also preserve the as-found readings, any as-left readings after adjustment, the acceptance tolerance, the laboratory that performed the work, and the certificate number.

Those fields support different operational needs. The due date supports scheduling, the as-found readings support drift analysis, and the certificate number supports audit traceability.

How Calibration Intervals Are Determined

Calibration intervals are not fixed by physics. They are management decisions based on risk and evidence.

The interval is influenced by manufacturer recommendations, measurement criticality, frequency of use, operating environment, and historical calibration results.

A torque wrench used continuously on an automotive assembly line may need a shorter interval than the same model used occasionally in a maintenance shop.

The most valuable evidence is the as-found history. If several consecutive calibrations show very small drift, the interval may be extended. If drift trends toward the tolerance limit, the interval should be shortened.

Without historical as-found data, interval decisions become difficult to justify.

Why Overdue Instruments Matter

An overdue instrument is not simply an administrative issue. It may represent an active production risk.

If the instrument remained in service after the due date, parts may have been measured without current calibration evidence. If it was removed from service and no spare was available, production may have been affected.

Effective programs monitor instruments before they become overdue. The warning window should reflect the actual lead time, including laboratory turnaround, shipping, internal approvals, spare availability, and planned shutdown schedules.

A 30-day warning is common, but it is not universally appropriate. Some calibrations require much longer planning windows, while others can be completed within a few days.

What Happens When an Instrument Fails Calibration?

When an instrument is found out of tolerance, the first step is straightforward: remove it from service and prevent further use.

The more important question is what happened before the failure was discovered.

An impact assessment considers the last successful calibration date, the size and direction of the error, the characteristics measured with the instrument, the tolerances of those characteristics, and whether product reinspection is required.

This is one reason calibration records should preserve historical calibration events rather than overwriting the previous record.

The same principle applies to reference standards. If a working standard is later found out of tolerance, instruments calibrated against it may also require assessment.

Which Standards Require Calibration?

Several quality management standards include calibration requirements.

• ISO 9001:2015 clause 7.1.5.2 — calibration or verification where measurement traceability is required.
• IATF 16949 — automotive-specific calibration records and laboratory competence requirements.
• ISO 13485 — calibration control for medical-device manufacturers.
• AS9100 — aerospace calibration controls and record requirements.

Audit findings are frequently related to missing records, overdue equipment, unclear status identification, or inadequate impact assessment rather than to the calibration measurement itself. A shop-floor layered process audit is one of the places these gaps get caught early, since checking whether a tool is within its calibration date is a standard item on that checklist.

Where Calibration Data Should Be Managed

Calibration data is operational data. Production supervisors, maintenance teams, quality engineers, and auditors may all need access to current status information.

A spreadsheet can work for a small population of instruments, but it becomes difficult to maintain as the number of assets grows. Common problems include stale status fields, missed due dates, duplicate records, and limited visibility across departments.

A digital calibration register can derive status directly from due dates, generate due-soon alerts, filter by department or asset type, and provide live compliance metrics.

FlowFuse can connect to calibration records stored in a database, CMMS, or ERP system and present overdue and due-soon status in real time. It can also trigger alerts before an instrument becomes overdue.

We walk through that implementation in Tracking Instrument Calibration with a Digital Dashboard.

Need visibility into calibration status across your plant?

Talk to our team about connecting calibration records, CMMS data, and shop-floor systems to a real-time calibration dashboard with FlowFuse.

Contact Us

Set Up Your Plant Floor Hardware Straight From the Terminal

Getting your own hardware into FlowFuse meant working backwards. You signed up, found the remote instance section, learned what the Device Agent was, created the instance in the platform, copied its connection details, and only then ran the installer with that code in hand.

Now you can start where the hardware already is. Run the installer from your terminal and it walks you through registering — including setting up an account if you need one — ending with your machine registered as a remote instance and ready to build on. If something's in the way — like port 1880 already being in use — the installer tells you up front instead of failing partway through.

You can grab the install command for your platform on the Device Agent page and have a machine online in a few minutes. More of the from-scratch onboarding experience lands in upcoming releases.

Modbus Certified Node

FlowFuse Edge customers can now install a FlowFuse-certified Modbus node straight from the palette manager in their editor. It covers Modbus TCP and Serial — including RTU and ASCII — in a single package.

Modbus is one of the most common protocols on the factory floor, but the community package most teams rely on depends on volunteer maintainers. The FlowFuse-certified node is backed by our own testing, SLA-backed security patching, and a long-term maintenance commitment.

This feature is available exclusively to FlowFuse Edge customers, on both FlowFuse Cloud and Self Hosted, from v2.33.

Ask the Expert About Your Tables

Available in: Edge, Hub, Fleet

Until now, checking on your Tables data meant leaving the chat panel and opening the Tables view yourself. Now you can just ask the Expert: which tables exist, what a table's columns look like, or for a quick peek at the data, and it answers right there. For real analysis, like filtering, sorting, or making changes, the Expert can build that for you too, as a flow using the tables-query node.

This release also closes a rough edge in Tables itself: databases with tables outside the default schema now behave correctly throughout, and the UI shows you which schema each table belongs to.

Availability: This feature is available to FlowFuse Hub and Edge customers on FlowFuse Cloud and Self Hosted from v2.33.

Changelog: FlowFuse Expert Can Now Work With Your Tables

Docs: FlowFuse Tables

Your Dashboards, All in One Place

Available in: Edge, Hub, Fleet

Dashboards now have a home. A new Dashboards entry in your team navigation lists every dashboard across your hosted instances, and opens each one right inside FlowFuse instead of a separate browser tab. Each application also has its own Dashboards tab, showing just the dashboards from that application's instances. A drawer lets you switch between dashboards in a single click, without going back to a list.

Until now, dashboards were reachable only through an "Open Dashboard" button on individual instance pages: fine if you knew where to look, a dead end if you didn't. Dashboard-only users had it worst, landing on a bare list of instances with nowhere to go. Now dashboards are a first-class part of the product, with a home scoped to exactly what each user can access.

Availability: all users of FlowFuse Cloud and all Self Hosted users from v2.33.

Changelog: A Dedicated Home for Your Dashboards

Tighter Control Over Who and What Reaches Your Systems

The more of your platform that automated clients and AI agents can reach, the more the question shifts: not just what they are allowed to do, but what you can prove they did afterwards, and how narrowly you can scope their access up front. 2.33 adds three controls that answer it.

Platform MCP Tools & API Actions Audit Trail

FlowFuse now logs actions performed through the supported platform MCP tools for AI agents such as our own first class AI agent the FlowFuse Expert. Each log entry records the action, when it occurred, and the user that performed it through it's dependency on the user's Personal Access Token. These logs do not capture activity related to MCP server nodes with which you can build your own MCP tooling and is part of our FlowFuse Expert Insights offering.

If you answer to an OT security team or an auditor, "the AI did it" is not an acceptable line in an incident report. The audit trail turns AI activity into the same kind of accountable, reviewable record you already expect from human operators.

Availability: Hub and Edge from v2.33.

Scoped Personal Access Tokens

Available in: Edge, Hub, Fleet

Personal Access Tokens can now be scoped to specific teams and include read or write permissions. Create a token that can do exactly what its integration needs and nothing more. This is especially important for AI use cases.

Previously a PAT carried the full permissions of the user who created it. If you generated a token for a read-only dashboard integration, that token could still modify your instances. Scoped tokens close that gap and follow the least-privilege pattern your security team already applies everywhere else.

You can easily navigate towards your personal settings to setup a new personal access token and configure it with the right scope and permissions.

Availability: Hub and Edge from v2.33.

Changelog: Team Scoped Personal Access Tokens

Manage Granular RBAC Through Your Identity Provider

Available in: Edge, Hub, Fleet

SSO admins can now map SAML groups to FlowFuse's granular roles. When someone joins the "Plant Floor Operators" group in your identity provider, they get the matching FlowFuse permissions automatically. No manual role assignment, no drift between your IdP and your platform.

Availability: Hub and Edge from v2.33.

Changelog: Application Roles from SSO Groups

Docs: Single Sign-On (SSO)

Also in This Release

• The Expert is better at telling when you want it to act versus when you want guidance.
• MCP server enumeration is much faster for teams with many instances.
• Fixed dropdown inputs rejecting values that matched the start of a suggestion.
• Plus dependency updates and smaller fixes.

For detailed breakdowns of each feature with additional visuals, visit our changelog. For the complete list of everything included in FlowFuse 2.33, check out the release notes.

If something in this release improves your workflow, or if there is still friction we can remove, please share feedback or report issues regarding this release to us.

Try FlowFuse

FlowFuse Cloud

The fastest way to get started is with FlowFuse Cloud. Get started for free and have your Node-RED instances running in minutes.

Self-Hosted

Run FlowFuse locally using Docker or Kubernetes.

What's Next

2.33 closes out the 2.x line. Something bigger arrives in August. 📈

Start building with your own industrial data

Connect your systems, automate workflows, and see what’s possible in your environment.

Try it out

Kaoru Ishikawa built a drawing in the 1960s to kill that exact reflex. It looks like a fish skeleton, which is why almost nobody calls it by his name. Sixty years and a dozen fancier root-cause tools later, engineers still reach for it first. Not because it's clever. Because it forces every theory in the room onto one wall, where the weak ones have nowhere to hide.

What Is a Fishbone Diagram?

Strip away the terminology and a fishbone diagram is a structured way to brainstorm causes without letting the loudest person in the room decide the answer.

You write the problem, the effect you want to eliminate, on the right side. That's the fish's head. A horizontal line runs left into it: the spine. Off that spine you draw diagonal branches, the ribs, and each rib is a category of causes. Under each category you hang the specific things that might be going wrong. When you're done, you're looking at every plausible cause for one problem, sorted into groups, on a single page.

The naming gets confusing, so here it is plainly. Ishikawa diagram, fishbone diagram, and cause-and-effect diagram all refer to the same tool. The names are used interchangeably in practice, though purists will point out that not every cause-and-effect sketch follows the fishbone shape. It's one of the seven basic quality tools, the club of simple techniques quality engineers lean on before pulling out anything statistical.

What it does not do is prove anything. A fishbone diagram generates hypotheses. It tells you where to look, not what the answer is. That distinction is the whole difference between a diagram that helps and one that wastes an afternoon, and we'll come back to it.

Who Invented the Ishikawa Diagram?

The diagram is named after Kaoru Ishikawa (1915–1989), a Japanese engineer, University of Tokyo professor, and one of the founding fathers of modern quality management. He popularized it in the 1960s while developing quality processes at the Kawasaki shipyards, and formalized it in his 1968 book Guide to Quality Control. His aim was democratic: he wanted quality improvement in the hands of ordinary workers, not locked inside a specialist team, so he built a diagram simple enough that anyone on the line could use it, which is a big part of why the American Society for Quality still lists it among the seven basic tools sixty years on.

Its reach since has been broad. One famous case is Mazda, whose engineers reportedly used an Ishikawa diagram to map every factor behind the "Jinba Ittai" (horse and rider as one) feel of the original MX-5 Miata.

What Are the 6Ms in a Fishbone Diagram?

Ishikawa suggested generic labels for the rib categories so teams would have somewhere to start instead of staring at a blank spine. In manufacturing, those defaults became the 6Ms:

• Manpower (people): training gaps, unclear responsibilities, communication breakdowns, fatigue.
• Method (process): missing standards, steps performed inconsistently, procedures that no longer match reality.
• Machine (equipment): worn parts, skipped maintenance, wrong tooling, calibration drift.
• Material (inputs): out-of-spec raw material, supplier variation, wrong batch, storage damage.
• Measurement (data): miscalibrated instruments, wrong gauge, inconsistent inspection, bad data collection.
• Mother Nature (environment): temperature, humidity, vibration, dust, anything the surroundings do to the process.

Here is the part most guides bury: Ishikawa himself told people to rename these categories to fit their problem. The 6Ms are training wheels, not scripture. They map cleanly onto a factory floor, but even there you'll often want to tweak them, and outside a production line they can fall apart entirely.

Some teams add a seventh M, Money, when cost drivers matter. Process industries sometimes swap in categories like Environment, Equipment, and Procedures. For a service or business problem, the 7Ps (Product, Price, Place, Promotion, People, Process, Physical Evidence) fit better than machinery and materials. The right categories are the ones that make your team say "oh, we haven't thought about that bucket yet." If a category sits empty because it doesn't apply, delete it. An empty rib is not a sign you missed something; it's a sign the label was wrong for your problem.

How to Make a Fishbone Diagram

The mechanics take five minutes. Doing it well takes discipline. Here's the sequence.

Write a problem statement, not a topic. "Machine downtime" is a topic. "Line 3 filler stops an average of 4 times per shift, each stop lasting 6 to 12 minutes" is a problem statement. The second one gives the team something specific to explain. Vague heads produce vague ribs.

Draw the spine and pick your categories. Four to six is the sweet spot. Fewer and you're not really sorting; more and the diagram turns into a wall of branches nobody can read. Start from the 6Ms if you're in manufacturing, adapt hard if you're not.

Brainstorm causes under each category. This is where the tool earns its keep. Go category by category and ask what, under this heading, could produce the effect. Write everything down, even the theories you doubt. The point of sorting into buckets is that it triggers ideas you'd never reach with an open-ended "what's wrong?"

Push each cause deeper with "why." A first-level cause is rarely the root. Pair the fishbone with the 5 Whys: for each rib entry, ask why that happens, and hang the answer as a sub-branch. "Bearing failed" becomes "bearing failed → lubrication skipped → PM schedule not followed → no one owns the schedule." Now you're looking at a root, not a symptom.

Then stop drawing and start verifying. This is the step that separates analysis from theater. A finished fishbone is a list of suspects, and every suspect is a hypothesis you can test against data. Circle the two or three most likely causes, then go check them: pull the maintenance log, measure the material, watch the operator. The diagram points the flashlight. It doesn't tell you what's in the dark.

Fishbone Diagram Example

Abstract diagrams teach nothing, so here's the kind of case that plays out on a real line. A packaging line is rejecting cartons because the printed date code is smearing. That's the head of the fish. The team runs 6M categories:

• Machine: print head height drifted, print head overdue for cleaning, conveyor speed increased last month.
• Material: new ink supplier introduced two weeks ago, carton stock switched to a glossier finish.
• Method: no standard for print-head-to-carton distance, cleaning interval never written down.
• Manpower: night shift not trained on the new ink's dry time.
• Measurement: no check on ink cure before cartons stack.
• Mother Nature: plant humidity up since the HVAC repair.

Six categories, roughly a dozen suspects. Now the 5 Whys on the strongest lead: the glossier carton stock. Why does gloss smear? Ink doesn't absorb. Why not? The new stock is non-porous. Why did we switch? Purchasing found a cheaper supplier. Why didn't anyone flag the print impact? No one owns print-compatibility sign-off on material changes.

Notice what happened. The obvious fix, "clean the print head," would have bought a day of relief and then the smearing returns. The fishbone surfaced two causes that interacted, a material change and a missing sign-off process, that a single-thread investigation would have walked right past. That's the entire value of the tool: it makes interacting causes visible instead of letting you commit to the first plausible one.

Fishbone vs. 5 Whys vs. Pareto: Which One, When

The fishbone rarely works alone, and it's easy to reach for the wrong tool. Here's how the three most common root-cause techniques divide the labor.

The sequence is: fishbone to find suspects, 5 Whys to reach the root of the best ones, Pareto to decide which roots are worth fixing first. They're not competitors. They're a pipeline.

Fishbone Diagram Template

You don't need software. Here's a text skeleton you can drop into any doc and fill in:

                    Method            Machine           Measurement
                       \                 |                  /
             cause ─────\        cause ──|        cause ───/
             cause ──────\       cause ──|        cause ──/
                          \              |               /
   ══════════════════════════════════════════════════════════►  [ PROBLEM ]
                          /              |               \
             cause ──────/       cause ──|        cause ──\
             cause ─────/        cause ──|        cause ───\
                       /                 |                  \
                   Manpower          Material           Mother Nature

Rules for using it: replace the six labels with categories that fit your problem, keep the problem statement specific, and treat every "cause" line as something you'll later verify with data. If you prefer digital, any diagramming tool works, but the paper-and-marker version on a wall is often better because it gets the whole team pointing at the same branch.

Common Fishbone Diagram Mistakes

Most failed fishbone sessions fail the same handful of ways.

Labeling empty branches and calling it done. Six categories with two vague words under each is a brainstorming template, not root-cause analysis. If the diagram doesn't contain specific, checkable causes, you've drawn a fish, not found a problem.

Confusing the diagram with the answer. The single most common error. The fishbone lists suspects; it does not convict any of them. Teams that skip verification and just "fix" the most-discussed branch are gambling, not analyzing.

Using the 6Ms where they don't fit. Forcing every problem into the manufacturing 6Ms produces empty ribs and missed causes. Pick categories that match your failure surface, and drop the ones that don't apply.

Vague problem statements. A fuzzy head produces a fuzzy diagram. Spend the extra two minutes writing what actually happened, where, and how often.

Stopping at the first level. "Operator error" is where lazy analysis ends and real analysis begins. Ask why five times before you believe you've hit a root.

Where the Fishbone Fits

The Ishikawa diagram survives because it does one job well: it gets a group of people to externalize their theories, sort them, and argue about them on paper before spending money. It's cheap, it's visual, and it needs no training to read. Those are the same reasons the simplest tools tend to outlast the sophisticated ones.

It has limits. It shows causes but not their relative weight or how they interact over time; for that you'd reach for a Pareto chart, fault tree, or statistical analysis. And it's only as good as the verification that follows it. Draw the fish, then go prove which bone is broken.

Used that way, as a hypothesis generator that hands off to real investigation, it remains one of the fastest ways to stop treating symptoms and start fixing causes. Sixty years in, that's still a rare thing for a tool to do.

The catch is that verification needs data the whiteboard can't give you: how often the machine actually stalls, whether the material batch really shifted, what the sensor logged when the defect appeared. That's the step where FlowFuse fits, connecting your PLCs, sensors, and quality systems into dashboards so you can test which suspected cause is real and confirm the fix held. It won't draw the fishbone for you, but it settles which bone was broken.

Turn suspected causes into verified ones

Talk to our team about connecting your PLCs, sensors, and quality systems to FlowFuse, so you can verify which root cause is real with live production data and confirm your fixes actually hold.

Contact Us

But shared stations raise a question paper never had: who's using it? Without a way to tell operators apart, the work order, the current step, and the record of what happened all blur together. Authentication draws the line, the operator's identity becomes the thread the app hangs on.

Digital work instructions dashboard showing operator work orders, production status

Operator interface displaying guided work instructions with step completion and defect reporting options

In this article, we'll build a digital work instructions app in FlowFuse: an operator interface with work orders, step-by-step assembly guidance, defect reporting, and traceability via authentication.

Note: This demo is deliberately configured with a preset demo user so anyone can try it, even without being on the team where it's deployed. The version you build following this article uses FlowFuse User Authentication, which limits dashboard access to members of the same team.

You can interact with the live demo here: .

What You'll Need

Before you start building, get these ready:

• A FlowFuse account. Sign up for FlowFuse Cloud, or use a self-hosted instance.
• A FlowFuse instance up and running. If you don't have one yet, create a new instance from your FlowFuse Platform.
• FlowFuse Dashboard installed. This tutorial uses @flowfuse/node-red-dashboard nodes (ui-template, ui-table, ui-form, ui-button, ui-control, ui-event, ui-text) to build the operator interface. Install it from the Palette Manager if it isn't already in your instance.
• The FlowFuse Dashboard user addon. This is what attaches the logged-in user to every dashboard message. We'll install it in the first section.

Note: The Multi-User addon is available to Teams and Enterprise Self-Hosted customers. If you're on a different tier, contact us for the configuration to get started.

How the Application Works

Before we build anything, let's walk through what the app does and how the pieces fit together. There are three pages, and one idea holding them together.

1. Home. After logging in, the application uses the operator's username to retrieve only the work orders assigned to them from the ERP or MES. It displays their station, production summary, the highest-priority work order, and the remaining queue. Selecting Start Work Order opens the instructions.
2. Instructions. Operators follow step-by-step instructions with images, checklists, and target cycle times. They can progress through each step, complete the operation, or report an issue at any time.
3. Report Issue. Operators can quickly log defects by selecting the issue type, severity, affected part, and description, with the issue automatically linked to the current work order.

The logged-in username acts as the application's lookup key. It retrieves the operator's assigned work orders and stores their active work order and current step, allowing them to resume exactly where they left off, even on shared production stations.

There are two different questions the app has to answer, and it's worth keeping them separate from the start:

• "Where is this operator's data stored?" — under a persistent global key named after their username, e.g. global.get('operator1', 'persistent'). This is a durable, shared store, and it's meant to be: it's what lets progress survive reloads and reconnects.
• "Who is acting right now, in this message?" — this must be read fresh from the message that triggered the flow (msg._client.user), not from a single shared "current user" variable. A shared variable has only one value at a time; the moment a second operator's browser connects, it overwrites the first operator's identity for the whole running flow. We'll come back to this the moment it becomes relevant, but it's the one rule that makes every "per operator" claim in this tutorial actually true when two people are logged in at once.

Importing the Simulated Flow

Instead of connecting to a real ERP or MES, we'll use a simple simulated backend that serves sample work orders through an HTTP API.

1. Import the following flow into FlowFuse and click Deploy.

The flow initializes a set of sample work orders and exposes REST APIs that the Digital Work Instructions application uses throughout this tutorial. The GET /workorders endpoint returns the active work orders, while the other endpoints simulate completing a work order, reporting defects, and retrieving production statistics. This lets you build and test the application without a live ERP or MES. Later, you can replace these endpoints with calls to your production system while keeping the rest of the application unchanged.

Setting Up the Dashboard Layout

The application consists of three pages. Most widgets are placed inside named groups, while a few are scoped differently. See the Dashboard layout docs if you're new to how pages, groups, and bases relate. The app bar greeting is UI-scoped, and the work instruction widget is page-scoped, allowing it to fill the entire Instructions page without requiring a group. Before adding any widgets, create the dashboard structure by setting up the pages and groups.

1. Create three ui-page nodes. The Dashboard automatically creates a base dashboard the first time you add a Dashboard node to the canvas.
   • Home (path: /home) – The operator's landing page after login. Set the layout to Notebook to match the demo application.
   • Instructions (path: /instructions) – Displays the step-by-step work instructions. Set the layout to Grid.
   • Report Issue (path: /report-issue) – Contains the defect reporting form. Set the layout to Grid.
2. Configure the theme for each page as desired.
3. On the Home page, create four ui-group nodes:
   • Current Station
   • Stats
   • Current Work Order
   • Up Next
4. On the Report Issue page, create a single ui-group named Report Issue. This group will contain the issue reporting form and its action buttons.

The Instructions page does not require a ui-group because the work instruction widget is page-scoped and automatically occupies the full page.

With this layout in place, each widget added in the following sections can be assigned to the appropriate group, or directly to the page when required.

Enabling FlowFuse User Authentication

Everything starts with a login. Without authentication, the dashboard cannot identify who is using it, so every visitor sees the same experience.

Note: FlowFuse User Authentication grants dashboard access to members of the same team as the instance. Operators you want to sign in must belong to that team, otherwise they won't be able to reach the dashboard. If you need people outside the team to use the application, you'll need to add them to the team.

1. Open your FlowFuse instance Settings.
2. Select the Security tab.
3. Enable FlowFuse User Authentication.

Enable FlowFuse User Authentication in the instance Security settings. You'll also create a Personal Access Token here for authenticating API requests later in the tutorial.

The first time someone opens the dashboard, they will be prompted to sign in using their FlowFuse username and password. Once authenticated, the dashboard can personalize the experience for each operator throughout the rest of this tutorial.

Because this tutorial also interacts with the FlowFuse API, you'll need to create a Personal Access Token:

4. In the same Security tab, click Add Token.
5. Enter a name for the token and choose an expiration date.
6. Click Create, then copy the generated token and save it somewhere secure. You will need it later in the tutorial.

Security note: Every http request node in this tutorial authenticates with this token, and for the sake of a self-contained tutorial we reference it as a plain Bearer token on each node. Don't leave it hardcoded that way in a real deployment. Store it as an environment variable on your FlowFuse instance and reference that variable from each http request node's auth config instead, so the raw token never sits in exported flow JSON or version control.

Installing the User Addon

Authentication identifies the user, but your flows also need access to that information. The FlowFuse User Addon attaches the authenticated user's details to every Dashboard message.

1. Open Manage Palette.
2. Go to the Install tab.
3. Search for @flowfuse/node-red-dashboard-2-user-addon.
4. Click Install.

After installation, every Dashboard message includes a msg._client.user object:

{
  "userId": "",
  "username": "",
  "email": "",
  "name": "",
  "image": ""
}

The same information is available in a ui-template using setup.socketio.auth.user (or this.setup.socketio.auth.user in the script).

1. In the FF Auth sidebar tab, ensure Include Client Data is enabled.
2. Also enable Accept Client Data for ui-template, ui-control, ui-event, ui-form, and ui-table so each browser session is handled independently and operators don't affect each other's dashboard.

Enable Include Client Data and Accept Client Data to make Dashboard interactions user-specific.

This is the setting that matters most in this tutorial, and it's worth being explicit about why. With Accept Client Data enabled, every message a widget sends carries msg._client.user for the session that sent it. That's a per-session identity attached directly to the message, as opposed to a single shared variable that every session would otherwise read and overwrite. We'll use msg._client.user as the source of truth for "who is acting right now" in every function node from here on, rather than a global variable.

Greeting the Logged-In Operator

The first, simplest payoff: show the operator their name and avatar in the app bar, so it's obvious who's signed in at this station. This uses Vue's Teleport to render into the header's action area from a single widget that lives on every page, so you don't have to add it per page.

1. Add a ui-template node and name it "App Bar User Info".
2. Set its type to Widget (UI-Scoped) and select your "My Dashboard" ui-base. UI-scoped widgets render on every page automatically, so one widget covers the whole app, no group needed.
3. Paste in the snippet below:

<template>
    <!-- Teleport into #app-bar-actions, the action bar's right-hand corner -->
    <Teleport v-if="loaded" to="#app-bar-actions">
        <div class="user-info">
            <img :src="setup.socketio.auth.user.image" />
            <span>Hi, {{ setup.socketio.auth.user.name }}</span>
        </div>
    </Teleport>
</template>

<script>
export default {
    data() {
        return { loaded: false };
    },
    mounted() {
        // Wait for mount so #app-bar-actions exists before teleporting into it.
        this.loaded = true;
    }
}
</script>

<style>
.user-info { display: flex; align-items: center; gap: 8px; }
.user-info img { width: 24px; height: 24px; }
</style>

Deploy and open the dashboard. The signed-in operator's name and avatar appear in the top-right corner. You don't redeploy when a different operator logs in, the addon fetches each user's data at runtime, so everyone sees their own. This widget reads identity straight off the browser's own socket session (setup.socketio.auth.user), so it's already per-operator by construction, no shared state involved.

The signed-in operator greeted by name and avatar in the app bar, rendered from a single UI-scoped widget.

Seeding the Operator into Context on Login

Greeting the operator is the visible half. The other half is making their identity available to every function node, not just the widgets.

You might reach for a single shared global here, global.set('user', msg._client.user, 'persistent') on connect, then read it everywhere. Don't. Global context is one store for the whole flow, not one per session, so if two operators are connected at once, whichever connects last overwrites the identity for everyone, and function nodes start attributing the wrong operator's actions to the wrong person.

Instead, read msg._client.user off each message for "who is acting right now," and use the username only as a durable storage key for saved state. A shared global is still handy as a bootstrap fallback for the very first tick of a page, before any client-tagged message has round-tripped.

1. Add a ui-event node named "Client connected" and select the "My Dashboard" ui-base. It fires when a browser session connects.
2. Add a change node named "Seed globals" with these set rules, in order:
   • user (global, persistent) → msg._client.user. Bootstrap fallback only, not the source of truth elsewhere.
   • StationContext.stationName (global) → your station's name, e.g. Wheel Assembly Station 12.
   • StationContext.stationId (global, persistent) → this station's ID, e.g. ST12.
   • Instructions (global, persistent) → the instruction set (steps, images, target times, checklists), cached so the Instructions page loads instantly.
3. Wire "Client connected" into "Seed globals".

From here on, every function node that needs the current operator uses this pattern, per-session identity first, bootstrap global only as a fallback:

const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

Showing the Station and Stats on the Home Page

The Home page shows the current station and a quick summary of work order statistics. Both update whenever the page opens.

Display the Station Name

1. From the Client connected event, add a change node named Read station name and set msg.payload to global.StationContext.stationName.
2. Connect it to a ui-text node named Current Station in the Current Station group. Set the value to msg.payload.

Display the Stats

1. Add a ui-control node named Page changed, set its event to change, and select your dashboard.
2. Add a function node named Build /stats request URL and paste in the following code. Replace https://your-instance.flowfuse.cloud with your own FlowFuse instance URL.

const StationContext = global.get('StationContext', 'persistent');
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

const params = new URLSearchParams();
params.set('stationId', StationContext.stationId);
if (username) params.set('username', username);

msg.url = `https://your-instance.flowfuse.cloud/workorders/stats?${params}`;
msg.method = "GET";
return msg;

3. Add an http request node that uses msg.method and msg.url, returns a parsed JSON object, and uses Bearer authentication.
4. Configure the bearer token using the access token you created earlier. For production, store it as an environment variable instead of hardcoding it in the flow.
5. Add a ui-template named Stats Cards in the Stats group and paste in the template below.
6. Wire the nodes: Page changed → Build /stats request URL → HTTP Request → Stats Cards.

The request includes the logged-in username, so the Assigned to me count is personalized for each operator, and because ui-control is client-data-aware, msg._client.user reflects whichever operator's browser triggered the page change.

The Home page displays station statistics, including total, assigned to me, completed, and defected work orders.

Loading the Operator's Work Orders

Now for the main part of the Home page: fetching and displaying the operator's work orders. Because the request includes the logged-in username, each operator only sees the work orders assigned to them at the current station.

1. Add a ui-control node named Page changed, select your dashboard, and set the event to change. It fires whenever the operator navigates to the Home page, triggering the work order request.
2. Add a function node named Build /workorders request URL, paste in the code below, and replace https://your-instance.flowfuse.cloud with your own FlowFuse instance URL.

const StationContext = global.get('StationContext', 'persistent');
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

const stationId = StationContext?.stationId;

const params = new URLSearchParams();
params.set('stationId', stationId);
if (username) params.set('username', username);

msg.url = `https://your-instance.flowfuse.cloud/workorders?${params.toString()}`;
msg.method = 'GET';
return msg;

3. Add an http request node, set the Method to Use msg.method, leave the URL field blank so it uses msg.url, set the Return type to a parsed JSON object, and configure Bearer authentication. Use the access token you created earlier as the bearer token. For production deployments, store the token as an environment variable and reference it here instead of hardcoding it in the flow.
4. Connect the http request node to a link out node named Work Orders Out. The widgets that display the work orders will connect to this node using their own link in nodes, allowing the same API response to be reused without stretching wires across the canvas.

The username in the request is what makes the dashboard personal. Two operators can open the same page at the same station, yet each receives only the work orders assigned to them, because each one's ui-control event carries their own _client.user, not a shared one.

Splitting the Current Order From the Queue

The Home page shows one work order front and centre and the rest as a queue. A function splits the list, sorting by priority so the most urgent job is the one the operator sees first. This function also records which work order the operator is about to start, that's the record the Instructions page, the Complete Operation flow, and the Report Issue flow will all read back later, so it has to be attributed to the right operator from the start.

1. Add a link in node named "link in 6" and point it at the "work orders out" link.
2. Add a function node named "split current vs queue (by priority)" with 2 outputs:

const orders = Array.isArray(msg.payload) ? msg.payload : [];

// Sort by priority (Critical/Urgent -> High -> Medium -> Normal -> Low)
const priorityOrder = { critical: 0, urgent: 0, high: 1, medium: 2, normal: 3, low: 4 };
const sorted = [...orders].sort(
    (a, b) => (priorityOrder[(a.priority || '').toLowerCase()] ?? 5)
            - (priorityOrder[(b.priority || '').toLowerCase()] ?? 5)
);

const currentWorkOrder = sorted[0] || null;

// Record which work order the current operator is about to see/start.
// Identity comes from the triggering message's client data, not a shared global,
// so this is always attributed to the operator whose browser fetched this list.
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

if (username && currentWorkOrder) {
    const userState = global.get(username, 'persistent') || {};
    userState.workOrderId = currentWorkOrder.workOrderId;
    global.set(username, userState, 'persistent');
}

return [
    { payload: currentWorkOrder },  // output 1: current order (for card)
    { payload: sorted.slice(1) }    // output 2: remaining orders (queue)
];

3. Import the Current Work Order Card ui-template below and assign it to the Current Work Order group. The complete component is provided below, so there's no need to recreate it.

Tip: Whenever you need a custom Dashboard widget, you don't have to write the Vue code yourself. Use FlowFuse Expert and describe the widget in plain English and it will generate the ui-template for you.

4. Wire output 1 to the "Current Work Order Card" ui-template in the Current Work Order group. It shows the work order ID, station, operation and estimated cycle time, the vehicle (model, variant, VIN, colour), a priority chip, and a Start Work Order button. On click, the button sends { action: 'start', workOrderId, stationId }.

The Current Work Order card: work order ID, priority chip, station, operation, vehicle details, and the Start button.

5. Add a ui-table node and assign it to the Up Next group. Turn off auto-columns and add two text columns as shown below: Work Order (workOrderId) and Priority (priority). Wire output 2 of the split function into it.

The Up Next table showing the remaining queued work orders with their priority.

6. From the card, wire a change node named "go to Instructions" that sets payload (msg) to Instructions, then into a ui-control node with its event set to change to switch the page.

When the operator taps Start Work Order, the card sends them to the Instructions page. Because the split function already saved this operator's workOrderId under their own username, the Instructions page, Complete Operation, and Report Issue flows can all look it back up correctly, even if another operator is doing the exact same thing on another screen at the same moment.

Loading the Cached Instruction Set

The Instructions page needs the steps to show. Because the instruction set was cached in context on login, the page can paint it instantly without another round trip.

1. Add a ui-event node named "Page opened" for the Instructions page.
2. Add a change node named "Load cached instruction set". Set payload (msg) to the persistent global Instructions.
3. Wire "Page opened" into it, and its output into the "Work Instruction Widget" you build next.

Remembering Each Operator's Step

This is something paper can't do and shared screens get wrong. If an operator completes the first two steps of a five-step wheel installation and returns later, they should resume at step 3, not start again at step 1. We achieve this by saving their progress against their username, the one they were identified as when the step was saved, not whichever username happens to be sitting in a shared global at read time.

The instruction widget emits two housekeeping actions: save_step whenever the operator moves between steps, and load_step when the page opens and needs to know where to resume. One function node handles both.

1. Import the Work Instruction Widget ui-template below, assign it to the Instructions page, and set its scope to Page. The widget displays one instruction at a time with its image, target cycle time, and checklist. Operators can't move to the next step until every checklist item is completed, and the final step changes the button to Complete Operation.

Tip: Whenever you need a custom Dashboard widget, you don't have to write the Vue code yourself. Use FlowFuse Expert and describe the widget in plain English and it will generate the ui-template for you.

The Instructions page: step image, checklist, target time, and Previous / Report Issue / Next controls.

2. Add a function node named "Track step (save/load per user)":

// Remembers the current step per user for the active work order.
// Handles two actions from the widget:
//   save_step - persist the step the operator is on
//   load_step - reply with the saved step so the widget can resume
const p = msg.payload || {};

// Identity comes from this message's own client data first. This is what
// keeps two operators using the widget at the same time from reading or
// writing each other's progress.
const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;
if (!username) return null;

// Read the user's saved state
const userState = global.get(username, "persistent") || {
    workOrderId: null,
    stepIndex: 0
};

switch (p.action) {
    case "save_step":
        userState.stepIndex = p.stepIndex ?? 0;
        global.set(username, userState, "persistent");
        return null;

    case "load_step":
        msg.payload = {
            workOrderId: userState.workOrderId,
            stepIndex: userState.stepIndex ?? 0
        };
        return msg;

    default:
        return null;
}

3. Wire the "Work Instruction Widget" output into this node, and wire the node's output back into the widget so the load_step reply can jump it to the saved step.

Look at the store key: global.get(username, ...) and global.set(username, ...). The operator's own username is the storage key, so two operators at the same station never overwrite each other, their progress lives under different keys, and because that key is now sourced from msg._client.user rather than a shared global, it's always the username of whoever's browser actually sent this particular save_step or load_step message.

Deploy, walk halfway through an operation, then reload the page. It reopens where you left off, because the step is filed under your name.

Completing the Operation as the Logged-In User

When the operator completes the final instruction, the widget sends { action: "complete_operation" }. The flow looks up the operator's stored work order and builds the payload that will be sent to the API.

1. Add a link in node and connect it to the Work Instruction Widget actions link.
2. Add a switch node named Route by Action and route messages where msg.payload.action equals complete_operation.
3. Add a function node named Build Complete Payload and paste in the following code.

const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

if (!username) {
    node.warn('No logged-in user found — cannot complete operation');
    return null;
}

const stored = global.get(username, 'persistent') || {};
const workOrderId = stored.workOrderId || null;

msg.payload = { workOrderId };
return msg;

4. Add an http request node, set the Method to POST, configure Bearer authentication using your access token, and set the URL to https://your-instance.flowfuse.cloud/workorders/complete. Replace https://your-instance.flowfuse.cloud with your own FlowFuse instance URL.
5. Add a change node that sets msg.payload to Home, then connect it to a link out node. This will be used in the next step to reset the operator's state and navigate the operator back to the Home page.

Because the payload is built from the logged-in operator's stored state, keyed off that same operator's per-message identity, the API always completes the correct work order, even when multiple operators are using the dashboard at the same time.

Reporting a Defect as the Logged-In Operator

If an operator encounters a defect, they can report it from the Work Instruction Widget. The report is automatically linked to the work order they're currently performing, so there's no need to enter a work order ID manually.

The Report Issue button sends { action: "Report Issue" }. Use that action to open the report form.

1. Add a link in node named Widget Action In and connect it to the Work Instruction Widget actions link.
2. Add a switch node named Route by Action and route messages where msg.payload.action equals Report Issue.
3. Add a change node that sets msg.payload to Report Issue, then connect it to a ui-control node to navigate to the Report Issue page.
4. Add a ui-form node named Report Issue Form to the Report Issue group with four required fields:
   • Issue Type (dropdown)
   • Severity (dropdown)
   • Affected Part (text)
   • Description (multiline)
   
   Populate the dropdown fields with the issue types and severity levels used in your application.

The Report Issue form collects the defect details before submitting them against the current work order.

Configure the Issue Type and Severity dropdowns with the options used in your application.

5. Add a function node named Prepare Defect Payload and paste in the following code.

const p = msg.payload || {};

const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

if (!username) {
    node.warn('No logged-in user found — cannot report defect');
    return null;
}

const stored = global.get(username, 'persistent') || {};
const workOrderId = stored.workOrderId || null;

const issueType = p.type;
const severity = p.severity;
const affectedPart = p['affected-part'];
const description = p.description || null;

if (!workOrderId || !issueType || !severity || !affectedPart) {
    node.warn('Missing required defect fields — defect not sent');
    return null;
}

msg.payload = {
    workOrderId,
    issueType,
    severity,
    affectedPart,
    description
};

return msg;

6. Add an http request node, set the Method to POST, configure Bearer authentication using your access token, and set the URL to https://your-instance.flowfuse.cloud/workorders/defect. Replace https://your-instance.flowfuse.cloud with your own FlowFuse instance URL, then connect the request to a link out node so the flow continues to the reset step.
7. Add a ui-button named Back to Work Instructions to the same group and connect it to a ui-control node that navigates back to the Instructions page. Since the operator's progress is stored against their username, they return to the same instruction they left.

The completed Report Issue page where operators can submit a defect or return to the work instructions.

The work order ID is retrieved from the logged-in operator's stored state, ensuring every defect report is associated with the correct work order, and the lookup key for that state again comes from this message's own client data, not a value that could have been overwritten by someone else's login in the meantime.

Clearing State When Work Ends

When an operation is completed or a defect is reported, clear the operator's saved progress so the next work order starts from step 1 instead of resuming a finished one.

1. Add a link in node named Complete / Defect Result In and connect it to the link out nodes from the Complete Operation and Report Defect flows.
2. Add a switch node that checks msg.statusCode equals 200, so the state is only cleared after a successful API response.
3. Add a function node named Clear User Step State and paste in the following code.

const username = msg._client?.user?.username
    || global.get('user', 'persistent')?.username;

if (!username) return null;

global.set(username, {}, 'persistent');

msg.payload = "Home";
return msg;

4. Connect the function node to a ui-control node to navigate the operator back to the Home page.

Because the state is stored and cleared by username, and that username is read from the message that carried the successful API response rather than a shared global, resetting one operator's progress never affects anyone else, even if a second operator has logged in on another screen in between.

Deploy the flow and open the dashboard. After signing in, operators see only the work orders assigned to them. If they leave and return, they resume from the same instruction. Once they complete the operation or report a defect, their progress is cleared and they're returned to the Home page, ready for the next work order.

Where to Go Next

You've built a personalized digital work instructions application that knows who the operator is, what work they're assigned, and where they left off, correctly, even when several operators are on the dashboard at once. Replacing the simulator with a real ERP or MES is simply a matter of pointing the HTTP Request nodes to your production /workorders, /workorders/complete, and /workorders/defect endpoints.

From there, you can extend the application with production history, quality tracking, role-based experiences, and the OEE, downtime, and quality dashboards that run alongside it, all powered by the same operator identity. To see how FlowFuse fits into modern automotive manufacturing, explore the Automotive solutions page.

Want to connect this to your real ERP or MES?

Talk to our team about integrating digital work instructions with your production systems, adding full traceability, and rolling this out across your shop floor.

Contact Us

Edge devices, gateways, servers, and data collection systems maintain their own clocks, and those clocks drift over time. When these systems collect and process industrial data, inaccurate timestamps can lead to out-of-order events, unreliable historical records, and incorrect analysis.

In this article, we'll look at why clock drift happens, how to keep distributed industrial systems synchronized, and how to monitor clock health using FlowFuse.

Why edge clocks drift

Every computer keeps time using a crystal oscillator. These crystals are accurate but not perfect: some run slightly fast, others slightly slow, and their accuracy changes with temperature and age. Two systems that start with the same time gradually drift apart.

That's the slow cause. In production, there are usually bigger reasons clocks become inaccurate.

No real-time clock

Most servers and desktops include a battery-backed Real-Time Clock (RTC) that keeps time while the machine is powered off. Many low-cost edge devices don't.

The Raspberry Pi is the best-known example. After being powered off, it has no reliable way to remember the current time, so it must wait until it can reach a time server. Without network access, it may boot thinking it's days, months, or even years in the past.

The operating system doesn't know the time is wrong. Applications running on that system, such as data collectors, gateways, and logging services, will continue creating timestamps based on whatever time the operating system reports.

No access to a time server

Most systems periodically synchronize with a time server to correct clock drift, but that isn't always possible in industrial environments. Many OT networks intentionally block internet access, and some are completely air-gapped.

If an edge device, gateway, or data collection system can't reach a trusted time source, it keeps relying on its own clock, drifting a little further each day. A few milliseconds won't matter. A few weeks or months usually will.

Backup power doesn't last forever

Some industrial gateways include an RTC but use a supercapacitor instead of a battery to keep it running during power outages. That works well for short outages, but leave the device unpowered for several days or weeks and the capacitor eventually discharges, resetting the clock.

Some industrial Linux systems then fall back to the operating system build date or another fixed timestamp. That's why you'll occasionally find multiple systems reporting exactly the same incorrect date from years ago.

If several systems suddenly report the same incorrect date, it's usually a sign that the backup clock source has been lost.

Leave a fleet running long enough and the clocks won't agree anymore. Most systems will only be slightly off, while a few can end up completely wrong.

What drift does to your data

Clock drift rarely causes obvious failures. Systems stay online, messages keep arriving, and dashboards still update. The timestamps just quietly become unreliable, and by the time anyone notices, the root cause can be difficult to trace.

The problem appears when data from multiple systems needs to be compared. SCADA platforms, HMIs, historians, and data collection systems rely on timestamps to understand event order, calculate production metrics, and investigate failures.

Events start appearing in the wrong order. If one system reports a motor stop, another an emergency stop, and a third a conveyor jam, but their clocks disagree, the sequence you see may not match what actually happened.

Data can also land in the wrong time bucket. A reading stamped a few seconds late can fall into the wrong aggregation window and quietly skew averages, production counts, and OEE calculations. The timestamp is not invalid, just inaccurate.

Cross-machine correlation suffers too. Comparing robot cycles with conveyor speed, or analyzing a production line failure across multiple systems, only works when those systems share a consistent timeline.

The impact is not usually that machines stop working. The problem is that the historical data used for analysis, troubleshooting, and reporting becomes harder to trust.

Step one: keep system clocks synchronized

The best place to solve clock drift is at the systems that generate and store timestamps. For edge gateways, servers, and data collection systems, this usually means keeping the operating system clock synchronized. When these systems have an inaccurate clock, applications such as data collectors, SCADA connectors, historians, and logging services can create unreliable timestamps.

Before changing anything, check what's actually running on your systems. Industrial deployments are rarely uniform, since different hardware vendors, OS images, and software versions often ship with different defaults, so it's worth confirming rather than assuming:

which chronyc    # chrony present?
which ntpq       # classic ntpd present?
timedatectl show-timesync --all   # systemd-timesyncd, on many minimal images

Whichever client is present, the underlying goal is the same: keep it pointed at a reliable source and give it a way to maintain accurate time across reboots and network outages.

Choose an NTP client deliberately

On many modern Linux distributions, chrony is the default and has largely replaced the older ntpd service. It tends to suit edge environments well: it synchronizes quickly after boot, keeps tracking clock drift while offline, and recovers cleanly when the network becomes available again.

But it isn't universal, since some minimal or vendor-specific images ship with ntpd, systemd-timesyncd, or nothing at all. Check first, and install or switch only if it makes sense for your deployment.

If you do use chrony, a basic configuration is enough for most deployments:

# /etc/chrony/chrony.conf

pool pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

Use multiple time sources

Avoid relying on a single time server. If that server has the wrong time or becomes unavailable, every system depending on it inherits the problem.

Using several independent time sources lets the NTP client compare responses, ignore outliers, and maintain a more reliable clock.

Air-gapped networks still need time synchronization

No internet does not mean industrial systems have to operate with independent clocks.

A common approach is to run a local time server inside the OT network and point edge gateways, servers, and data collection systems to it. The protocol does not change. Only the time source does.

For example:

server 10.0.5.10 iburst

Even if that local server is not synchronized with the internet, every system in the plant can maintain a consistent timeline. For many industrial applications, consistency between systems is more important than perfect UTC accuracy.

If accurate wall-clock time is required, the local server can be synchronized using GPS or another external reference.

Add a real-time clock where possible

If your hardware does not include an RTC, consider adding one. For devices like the Raspberry Pi, an inexpensive battery-backed RTC module lets the system boot with the correct time even before the network is available.

This is especially useful for systems that power on, perform a task, and shut down again before NTP has a chance to synchronize.

Keeping the operating system synchronized solves most clock drift issues. The next step is making sure your applications preserve the correct timestamps and alert you when a system starts drifting.

Monitoring drift from FlowFuse

If FlowFuse is already running on your edge devices, it is a convenient place to monitor whether the system clock used by data collection flow remains accurate.

This check applies to the edge computer running FlowFuse or the data collection node, not the PLC itself. The goal is to detect when timestamps generated by the industrial data collection layer may no longer be reliable.

The flow below works with chrony; if a device runs ntpd instead, swap the command in step 2 for ntpq -p and adjust the parsing in step 3 to match its output format.

1. Add an inject node to the canvas, name it "Check clock every 5 min", and set it to repeat on an interval of 5 minutes. Clock drift is a trend, not a single reading, so a one-off check will not show whether the offset is increasing.
2. Add an exec node after it, name it "Get chrony offset", and set the command to:

chronyc tracking

This pulls the actual offset from the operating system clock synchronization service rather than estimating it from application timestamps.

3. Add a function node after the exec node, name it "Parse offset", and set it to:

const lines = msg.payload.split('\n');
const data = {};

lines.forEach(line => {
    const [key, ...rest] = line.split(':');
    if (key && rest.length) {
        data[key.trim()] = rest.join(':').trim();
    }
});

const parseOffset = (v) => v ? parseFloat(v) * 1000 : null; // to ms

msg.payload = {
    stratum: parseInt(data['Stratum']),
    lastOffsetMs: parseOffset(data['Last offset']),
    rmsOffsetMs: parseOffset(data['RMS offset']),
    leapStatus: data['Leap status'],
    timestamp: new Date().toISOString()
};

return msg;

stratum tells you how many hops this system is from a reference clock. A rising value can indicate that it has fallen back to a less reliable time source.

leapStatus should normally read Normal. Any other value should be treated as a synchronization problem rather than simply a small clock offset.

4. Add a switch node after the function node, name it "Over threshold?", checking payload.lastOffsetMs. Set the threshold based on how the timestamps are used:

5. Wire the failing branch to a function node, name it "Build alert", and create a message containing the affected system, clock offset, and stratum information.
6. Send the alert to your existing notification system, such as MQTT, email, or another monitoring platform.

After deployment, trigger the inject node manually once. You should see the parsed clock status in the debug sidebar.

How accurate does your clock need to be?

Not every industrial application needs microsecond precision. For most use cases, such as historian logging, dashboards, OEE calculations, condition monitoring, and production reporting, NTP provides more than enough accuracy.

With a stable network, a well-configured NTP client can typically keep systems synchronized within a few milliseconds. That is already more accurate than many industrial applications that aggregate data into one-second or one-minute intervals require.

PTP (Precision Time Protocol) is a different story. It is designed for applications where events must be synchronized with sub-millisecond or even microsecond precision.

Examples include:

• motion control
• synchronized robotics
• high-speed sequence-of-events recording
• applications where timing is part of the control or measurement requirement

PTP requires compatible hardware and network infrastructure, making it more complex to deploy than NTP.

If your application does not have strict timing requirements, NTP is usually the simpler and more practical choice.

Wrapping up

Clock drift is one of those problems that is easy to ignore until it starts affecting production data.

Machines continue running, dashboards continue updating, and messages still arrive, but inaccurate timestamps make troubleshooting, event correlation, and reporting increasingly difficult.

The challenge is not usually PLC control logic itself. PLCs typically operate using scan cycles, timers, and internal execution timing. The one exception is when the data changing on the PLC is faster than the protocol used to read it. In that case, the PLC has to buffer those fast-changing values in an array so nothing is lost between polls. That's a program design and memory concern, not a clock synchronization one; the PLC still isn't timestamping anything itself. The impact of clock drift appears when data from multiple systems needs to be collected, compared, and analyzed.

SCADA systems, historians, HMIs, edge gateways, and industrial data platforms depend on accurate timestamps to understand production events and maintain reliable historical records.

Preventing clock drift does not require complex infrastructure. A reliable NTP client, multiple or local time sources, and hardware with a real-time clock where appropriate can eliminate most clock synchronization issues.

Just as importantly, monitor system clock health so problems are detected before they affect operational data.

Clock drift monitoring is really just one small thing you can do with FlowFuse. At its core, it's a platform for collecting data from your PLCs and sensors, building applications and dashboards on top of that data, and deploying and managing all of it across your fleet from one place.

Monitor and Manage Edge Devices with FlowFuse

Deploy Industrial applications, monitor edge devices, detect clock drift, and manage industrial deployments from a single platform. See how FlowFuse simplifies managing distributed edge infrastructure.

Contact Us

The finished defect tracking dashboard showing stat cards, Pareto chart, and trend line

In this tutorial, you'll build a defect tracking and quality monitoring dashboard using FlowFuse in about 30 minutes. It reads defects from a database, calculates the KPIs a quality engineer actually looks at, and renders them live, filtered by line, shift, and date range.

You can interact with the live demo here: .

By the end, you'll have a foundation you can extend into broader production monitoring or OEE tracking, or a plant-wide quality report.

What You'll Need

Before you start building, make sure you have the following ready:

• A FlowFuse account. Sign up for FlowFuse Cloud, or use a self-hosted instance.
• A FlowFuse instance up and running. If you don't have one yet, create a new instance from your FlowFuse Platform.
• FlowFuse Dashboard installed. This tutorial uses @flowfuse/node-red-dashboard nodes (ui-text, ui-chart, ui-table, and ui-template) to build the interface. If it is not already installed, add it from the Node-RED Palette Manager. If you are new to FlowFuse Dashboard, follow the Getting Started guide to become familiar with the basics before continuing.

Note: FlowFuse Tables is currently in beta and available to Enterprise tier teams on FlowFuse Cloud, as well as Enterprise licensed self hosted teams running on Kubernetes. If you're on a different tier, you can follow along using any external database instead, Postgres, MySQL, or whatever you already have, with the standard database nodes from the palette. The SQL and flow logic in this tutorial will work the same either way.

How the Application Works

This dashboard is a read layer. It doesn't capture defects itself; it sits on top of a table of them and turns that table into something a supervisor can read at a glance:

• Defects live in one table. Each defect is a row: where it happened, what it was, how severe, its root cause, how it was handled, and what it cost. Something else fills this table: an operator logging defects from a form, or automatic events arriving over MQTT. For the tutorial, a simulator stands in for that source.
• One query calculates everything. A single query filters the table once and computes every KPI on the dashboard in one pass, then splits the result across every card, chart, and table, so the whole dashboard updates from a single source of truth.
• The header drives it all. Line, shift, and date-range dropdowns live in the dashboard header. Change any one and every widget recalculates together.

Importing the Simulator

You need a table and data in it before the dashboard can show anything. Rather than build that by hand, import the simulator flow; it creates the defects table and fills it for you.

It gives you two generators. A historical seed fills about six months of defects, so the charts have something to show right away. A live feed then inserts a fresh defect every few seconds, so the dashboard keeps updating on its own while you build.

Both run automatically on deploy: no buttons to click. The table is created first, the historical seed lands a few seconds later, and the live feed takes over from there. Within moments your table holds over a thousand records and keeps growing.

The schema it creates

You don't run this yourself; the import handles it. But it's the contract the whole dashboard depends on, so it's worth knowing what the defects table looks like, especially if you later point the dashboard at your own database:

CREATE TABLE IF NOT EXISTS defects (
    defect_id         VARCHAR(20) PRIMARY KEY,
    date              DATE NOT NULL,
    line              VARCHAR(20),
    station           VARCHAR(30),
    shift             VARCHAR(20),
    sku               VARCHAR(20),
    defect_type       VARCHAR(50),
    defect_category   VARCHAR(30),
    severity          VARCHAR(10),
    detected_stage    VARCHAR(20),
    root_cause        VARCHAR(50),
    disposition       VARCHAR(20),
    status            VARCHAR(20),
    cost_impact       NUMERIC(10,2),
    resolution_hours  NUMERIC(6,1)
);

CREATE INDEX IF NOT EXISTS idx_defects_date ON defects(date);
CREATE INDEX IF NOT EXISTS idx_defects_line ON defects(line);
CREATE INDEX IF NOT EXISTS idx_defects_shift ON defects(shift);

Each row is one defect. The columns group into where it happened (line, station, shift, sku), what it was (defect_type, severity, detected_stage), how it was handled (root_cause, disposition, status), and what it cost (cost_impact, resolution_hours). The three indexes cover the columns the dashboard filters by, so queries stay fast as the table grows.

Building the Query

Running one query per widget means a dozen database trips on every refresh. This dashboard runs a single query instead. It returns one row where each field holds one widget's data, and every widget reads just its own field.

Two CTEs at the top do the filtering. filtered_all applies all three filters: line, shift, and date range. filtered_line_and_shift skips the date filter, so the live ticker always shows the latest defects. After that, one json_agg block builds the data for each widget:

Tip: You don't have to write SQL yourself. Use FlowFuse Expert and describe the interface in plain English. It will generate the ui-template code for you.

WITH
  filtered_all AS ( -- full 3-filter set, used by almost every widget
    SELECT * FROM defects
    WHERE ($line = 'All' OR line = $line)
      AND ($shift = 'All' OR shift = $shift)
      AND date >= CURRENT_DATE - ($daysback || ' days')::interval
  ),
  filtered_line_and_shift AS ( -- ticker: "right now" view, ignores the date filter
    SELECT * FROM defects
    WHERE ($line = 'All' OR line = $line) AND ($shift = 'All' OR shift = $shift)
  )
SELECT
  -- stat cards + cost of poor quality (one pass over the filtered rows)
  (SELECT json_agg(t) FROM (
    SELECT
      COUNT(*) FILTER (WHERE status IN ('Resolved','Verified'))     AS closed_count,
      COUNT(*) FILTER (WHERE status NOT IN ('Resolved','Verified')) AS open_count,
      COUNT(*)                    AS total_count,
      ROUND(SUM(cost_impact), 2)  AS total_copq
    FROM filtered_all
  ) t) AS stat_cards_and_copq,

  -- average resolution time + SLA breach per severity
  -- (SLA targets: Critical 24h, Major 72h, Minor 168h)
  (SELECT json_agg(t) FROM (
    SELECT severity,
      ROUND(AVG(resolution_hours), 1) AS avg_resolution_hours,
      COUNT(*)                        AS resolved_count,
      COUNT(*) FILTER (WHERE resolution_hours >
        CASE severity WHEN 'Critical' THEN 24 WHEN 'Major' THEN 72 ELSE 168 END) AS sla_breached_count,
      ROUND(100.0 * COUNT(*) FILTER (WHERE resolution_hours >
        CASE severity WHEN 'Critical' THEN 24 WHEN 'Major' THEN 72 ELSE 168 END)
        / NULLIF(COUNT(*), 0), 1) AS sla_breach_pct
    FROM filtered_all WHERE status IN ('Resolved', 'Verified')
    GROUP BY severity
    ORDER BY CASE severity WHEN 'Critical' THEN 1 WHEN 'Major' THEN 2 ELSE 3 END
  ) t) AS avg_resolution_and_sla,

  -- Pareto: defect-type counts with a cumulative % (window functions)
  (SELECT json_agg(t) FROM (
    SELECT defect_type, COUNT(*) AS defect_count,
      ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 1) AS pct_of_total,
      ROUND(SUM(COUNT(*)) OVER (ORDER BY COUNT(*) DESC) * 100.0
            / SUM(COUNT(*)) OVER (), 1) AS cumulative_pct
    FROM filtered_all GROUP BY defect_type ORDER BY defect_count DESC
  ) t) AS pareto,

  -- daily trend
  (SELECT json_agg(t) FROM (
    SELECT date, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY date ORDER BY date
  ) t) AS trend,

  -- disposition breakdown
  (SELECT json_agg(t) FROM (
    SELECT disposition, COUNT(*) AS defect_count, ROUND(SUM(cost_impact), 2) AS total_cost
    FROM filtered_all GROUP BY disposition ORDER BY defect_count DESC
  ) t) AS disposition,

  -- severity breakdown
  (SELECT json_agg(t) FROM (
    SELECT severity, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY severity
    ORDER BY CASE severity WHEN 'Critical' THEN 1 WHEN 'Major' THEN 2 ELSE 3 END
  ) t) AS severity,

  -- root-cause breakdown
  (SELECT json_agg(t) FROM (
    SELECT root_cause, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY root_cause ORDER BY defect_count DESC
  ) t) AS root_cause,

  -- status funnel, ordered by workflow stage
  (SELECT json_agg(t) FROM (
    SELECT status, COUNT(*) AS defect_count
    FROM filtered_all GROUP BY status
    ORDER BY CASE status WHEN 'Detected' THEN 1 WHEN 'RCA' THEN 2 WHEN 'Corrective Action' THEN 3
      WHEN 'Resolved' THEN 4 WHEN 'Verified' THEN 5 END
  ) t) AS status_funnel,

  -- most recent 20 defects, for the live ticker
  (SELECT json_agg(t) FROM (
    SELECT defect_id, date, line, station, defect_type, severity, status, cost_impact
    FROM filtered_line_and_shift ORDER BY defect_id DESC LIMIT 20
  ) t) AS ticker;

With the query written, wire it up so it runs on a timer and its result reaches every widget.

1. Add a change node before the Query node and name it "Set Params". This maps the saved filters onto the $line, $shift, and $daysback parameters the SQL reads. Set four rules, in order:
   • Set queryParameters to {} (JSON): starts clean so stale values don't linger.
   • Set queryParameters.line to filters.line (global persistent).
   • Set queryParameters.shift to filters.shift (global persistent).
   • Set queryParameters.daysback to filters.dateRange (global persistent).

The "Set Params" change node open in the edit panel, all four rules visible.

1. Add an inject node named "Poll Data" and set it to repeat every 10 to 30 seconds. Wire it into "Set Params"; this re-runs the query on a timer so the dashboard keeps up as new defects arrive. Also add a link in node here, named "Refresh Trigger," and connect it to the "Set Params" change node; this will let the filter flow you build next trigger a refresh as well.
2. After the Query node, add a single link out node and name it "KPI Result". Each widget you build next will connect a link in node to it, so the one result broadcasts to every widget at once.

Adding the Filters

The filters go in the dashboard header rather than a widget group, since they control the whole page, not one chart. Each selection saves to the global filters object that "Set Params" reads before every query run.

1. Add a ui-event node. It fires on page load, so a fresh browser session starts with the dropdowns populated.
2. Add a change node named "Set Filters". Set payload to one JSON object containing your filter options. For this tutorial it looks like the following, but update it to match your table:

{
    "line": "SUV Line",
    "shift": "Night",
    "dateRange": 30,
    "lineOptions": [
        "All",
        "Sedan Line",
        "SUV Line",
        "EV Line"
    ],
    "shiftOptions": [
        "All",
        "Morning",
        "Evening",
        "Night"
    ],
    "dateRangeOptions": [
        {
            "label": "Last 7 days",
            "value": 7
        },
        {
            "label": "Last 30 days",
            "value": 30
        },
        {
            "label": "Last 90 days",
            "value": 90
        },
        {
            "label": "All time",
            "value": 100000
        }
    ]
}

3. Add a ui-template node named "Header Filters". Set its type to "Widget" (UI scoped) and select your UI. Ask FlowFuse Expert to build it:

Create a ui-template with three header dropdowns, Line, Shift, and Date Range, wrapped in <Teleport defer to="#app-bar-actions"> so they render in the header bar and survive a reload. msg.payload has the selections (line, shift, dateRange) and options (lineOptions, shiftOptions, dateRangeOptions). Line/Shift options are strings; dateRangeOptions items are {label, value} objects, so bind label as text and value as the value, not the whole object. On any change, and on load, send {line, shift, dateRange} downstream.

Below is the template it produced for us, import it directly if you prefer:

The finished header filters. Capture the Line, Shift, and Date Range dropdowns in the live dashboard header.

4. Add a change node named "Save Filters" that sets the persistent global filters to msg.payload, and connect its input to the "Header Filters" ui-template node.

The "Save Filters" change node, setting the persistent global filters to msg.payload.

5. Next, add a link out node, connect its input to the "Save Filters" change node, and connect its output to the "Refresh Trigger" link in node you added earlier.

Deploy, and the dropdowns appear in the header. Change one and the next query pass redraws every widget against it.

Building the Widgets

Everything the dashboard shows comes from the "KPI Result" broadcast, so every widget follows the same wiring: a link in node connected to "KPI Result", a change node that extracts that widget's field, and the display node.

Before adding widgets, create a page for the dashboard (ours is "Assembly Quality Monitor") and a ui-group for each widget. The group is what positions and sizes a widget on the grid.

Stat cards

Start with the four numbers a supervisor checks first: total defects, open, closed, and cost of poor quality.

1. Add a link in node and connect it to "KPI Result".
2. Add a change node named "Extract KPI Summary" with one rule: set msg.payload to msg.payload[0].stat_cards_and_copq (msg). Wire the link in to it.
3. Add four ui-text nodes, one in each of the four top groups (Total Defects, Open, Closed, Cost of Poor Quality). Wire the change node to all four.
4. In each ui-text node, set the value to the matching field: msg.payload[0].total_count, msg.payload[0].open_count, msg.payload[0].closed_count, msg.payload[0].total_copq.

Open counts everything not yet Resolved or Verified; the cost figure sums cost_impact across the current filter, so it moves the moment you switch line or shift.

The four stat cards populated with seeded data.

Pareto chart

The Pareto chart ranks defect types by count and overlays a cumulative-percentage line with an 80% marker. It is the fastest way to see which few defect types cause most of the pain. The built-in ui-chart can't combine bars and a line, so this one is a ui-template that draws the SVG itself.

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Pareto Data": set msg.payload to msg.payload[0].pareto (msg).
3. Add a ui-template node in the Pareto group. Ask FlowFuse Expert to generate it:

Create a Vue ui-template that renders a Pareto chart as responsive inline SVG. msg.payload is an array of {defect_type, defect_count, cumulative_pct}, sorted by count descending. Draw a bar per defect type with its count above and a word-wrapped label below, a cumulative-percentage line with dots over the bars, a dashed threshold line at 80%, and a small legend. Derive the rows from msg.payload reactively so the chart redraws on every new message.

Below is the template it produced for us, import it directly if you prefer:

The rendered Pareto chart. Make sure the cumulative line and the dashed 80% threshold are both visible.

Root cause

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Root Cause Data": set msg.payload to msg.payload[0].root_cause (msg).
3. Add a ui-chart node in the Root Cause group, chart type Bar, root_cause on the x-axis, defect_count on the y.

The query sorts it most-common-first, so the chart reads left to right as a priority list.

The root cause bar chart, bars descending left to right.

Severity and disposition

1. Add two link in nodes connected to "KPI Result", one per chart.
2. Add two change nodes: "Extract Severity Data" sets msg.payload to msg.payload[0].severity; "Extract Disposition Data" sets payload to payload[0].disposition.
3. Add two ui-chart nodes in their groups, chart type Pie. For each, set the label to the category column (severity / disposition) and the value to defect_count.

Severity shows how serious the mix is; disposition shows what it's costing you: Scrap, Rework, or Use-as-is.

The two pie charts. Capture Severity and Disposition together.

Defects per day

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Trend Data": set msg.payload to msg.payload[0].trend (msg).
3. Add a ui-chart node in the Defects Per Day group. Set the chart type to Line, the x-axis property to date (type: time), and the y-axis property to defect_count.

This is where a bad week, or a bad batch, shows up as a bump you can point at.

The daily trend line chart. A date range showing a visible bump makes the point best.

Resolution time and SLA

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Resolution & SLA Data": set msg.payload to msg.payload[0].avg_resolution_and_sla (msg).
3. Add a ui-table node in the Average Resolution group. Turn off auto-columns and configure five: Severity (severity), Hours (avg_resolution_hours), Resolved (resolved_count), SLA Breached (sla_breached_count), SLA % (sla_breach_pct).

This is the widget that answers whether defects are being closed fast enough, not just how many exist.

The resolution/SLA table, all five columns per severity row.

Status funnel

1. Add a link in node connected to "KPI Result".
2. Add a change node named "Extract Status Funnel Data": set payload to payload[0].status_funnel (msg).
3. Add a ui-chart node in the Status Funnel group, chart type Bar, status on the x-axis, defect_count on the y.

The query orders it by workflow stage (Detected, RCA, Corrective Action, Resolved, Verified), so a pile-up at any stage is visible at a glance.

The status funnel bar chart, bars in workflow order.

Deploy and open the dashboard. Every widget populates from the seeded data at once. Change a filter in the header and the whole page recalculates together; leave the live feed running and the numbers keep ticking.

What Next

You've built a working quality dashboard: a defects table, a single query that computes every KPI in one pass, and a page of stat cards, a Pareto chart, trend and breakdown charts, an SLA table, and a status funnel, all filtering live by line, shift, and date.

Right now it runs on the simulator, but that was only ever a stand-in for your real data. To go live, remove the simulator flow and point the query at your own defects table. Everything downstream keeps working, because the dashboard only ever reads from that one query. Your defects don't live in PostgreSQL? That's fine too. FlowFuse connects to MySQL, MongoDB, InfluxDB, and more, as our database integration guides show.

That's the real point. FlowFuse lets you build the exact application your floor needs quickly, without deep engineering knowledge or writing code, wired to the systems you already run instead of forcing your process to fit a fixed tool. This tutorial happened to build defect tracking, but the same approach covers the full range of manufacturing dashboards, production monitoring, OEE, and the wider quality picture. See how manufacturers are already putting it to work on our automotive solutions page.

See What Your Team Can Build

See it live with our team, and the variety of applications you can build without coding expertise, then scale them across your plant in a single click.

Contact Us

That was simply how factories evolved.

Today, the machines are still there. PLCs still control equipment, robots still move products, sensors still collect data. But many improvements now happen in software instead. Manufacturers are connecting machines, production systems, enterprise software, and cloud services in ways that weren't common a few years ago, building dashboards, maintenance workflows, quality applications, and production reports without constantly changing the machines themselves.

That's the idea behind software-defined manufacturing (SDM): separating control logic, process orchestration, and operational intelligence from any single piece of hardware, and running them instead in a software layer that sits above the equipment. The machines don't change. What changes is how quickly and easily they can be connected, coordinated, and improved, through software updates instead of rewiring cabinets or reprogramming individual PLCs.

Some in the industry, including analysts at ARC Advisory Group and Deloitte, describe the fuller vision of SDM as extending all the way to AI-driven optimization and autonomous, agent-based production, where software doesn't just orchestrate equipment but continuously improves how it runs. That broader picture is real, but it starts with the same foundational shift: getting control logic and orchestration out of rigid, single-purpose implementations and into a software layer that can evolve. This article focuses on that foundational layer, the practical, incremental part of SDM that most manufacturers are building toward today.

Manufacturing Is Becoming More Software-Centric

Manufacturing isn't the first industry to move this way. Networking became software-defined networking. Storage became software-defined storage. Instead of adding dedicated hardware every time a new capability was needed, software took on more responsibility for configuring, managing, and coordinating those systems.

Manufacturing follows a similar pattern, with one important difference: factories still depend on deterministic control, safety systems, and equipment that may stay in production for twenty years or longer. Those systems aren't going away, but what runs around them increasingly is software rather than hardware.

Software sits above those systems, connecting them, exchanging data between them, and coordinating what happens around the production process. That's increasingly important because factory data no longer stays inside the plant. Maintenance teams, quality systems, MES platforms, ERP software, historians, cloud services, and sometimes AI applications all need it. Adding a dashboard, connecting a new machine, or automating a maintenance process has become more of a software project than a hardware one. The equipment stays where it is; the software around it keeps evolving.

Why Traditional Manufacturing Software Starts to Struggle

The problem is that much of today's manufacturing software wasn't designed to change this often. Many industrial systems were built around a single large implementation: install it, customize it, train everyone, then leave it running for years. That worked when production changed slowly. It becomes much harder when operations are constantly looking for new reports, additional integrations, better visibility, or another workflow. Even small requests, like adding a dashboard, connecting another PLC, or integrating a maintenance system, can turn into large projects.

Vendor lock-in makes this worse. Many industrial platforms depend on proprietary tools or tightly coupled software, so even straightforward improvements take longer than expected because every change runs through the same platform.

Most factories also aren't starting with a clean slate. A single production line might include PLCs installed fifteen years ago alongside modern robots, vision systems, industrial PCs, barcode scanners, cloud services, and enterprise software. The challenge usually isn't replacing those systems. It's getting them to work together reliably.

Software governance adds another layer. Manufacturing teams already have strict processes for changing production equipment; software needs the same discipline. Teams need to know what version is running, who changed it, when it was deployed, and how to roll back if something goes wrong. Without that, software becomes difficult to maintain as more applications get added across the factory. Large modernization projects don't really fix this either, since they often take months or years to deliver value, by which point the business has usually moved on to the next requirement.

Building Applications That Can Grow

Software-defined manufacturing takes a different approach. Instead of one large application trying to handle everything, manufacturers build smaller applications that each solve a specific problem. Those applications work together, but they don't all have to change at the same time.

Imagine a packaging machine stops unexpectedly. One application records the downtime for OEE. Another updates the production dashboard. Another notifies the maintenance team. Later, the quality team adds an inspection step. Only the quality application needs to change. The downtime application keeps running. The dashboard doesn't need to be touched. Maintenance continues working the same way.

Each application evolves independently, which makes the whole system easier to understand, test, and improve over time. The PLC still controls the machine; the software extends what happens around it, connecting systems, sharing information, automating workflows, and giving different teams the information they need. It's the same decoupling principle behind software-defined networking and storage, applied to the factory floor: the hardware stays fixed, and the software layer above it is what keeps changing.

From Software Projects to a Software Platform

Building an industrial application is no longer the difficult part.

The difficult part is what happens after that application proves its value.

It gets deployed to another production line. Another factory wants the same solution with a few changes. A new machine needs to be connected. Another dashboard is requested. Before long, what started as one successful application becomes dozens running across multiple lines, plants, and teams.

That's when software-defined manufacturing stops being a development challenge and becomes an operational one.

Manufacturers need more than a way to build applications. They need a consistent way to deploy them, manage them, update them, secure them, and scale them across the organization without every site becoming its own isolated software project.

This is the role FlowFuse plays.

Rather than being another manufacturing application, FlowFuse provides the platform that manufacturers use to build, deploy, and operate industrial applications throughout their lifecycle. It creates a common operating model for software running across the factory, whether that software connects equipment, collects production data, orchestrates workflows, or integrates with enterprise systems.

As more applications are introduced, that consistency becomes increasingly valuable. Teams can standardize how applications are developed, deploy them reliably to edge devices, manage changes through version control and GitOps, track every deployment with audit logs, control access through role-based permissions, and operate applications across multiple sites from a single platform.

The result is that software scales with the business instead of becoming another maintenance burden. Once an application proves its value, it can be reused, adapted, and continuously improved without rebuilding the entire solution for every production line or facility.

Arch Systems experienced this challenge as its manufacturing platform expanded across customer sites. Connecting more than 100 production databases and MES systems manually was slowing every deployment. By building reusable integration components and deploying them through FlowFuse, Arch standardized its rollout process and propagated changes across production environments from a single platform.

That same approach extends to existing development practices. FlowFuse DevOps Pipelines support GitHub, GitLab, Bitbucket, Gitea, and other Git servers, allowing manufacturers to adopt GitOps workflows without changing the infrastructure they already use.

Software-defined manufacturing isn't simply about writing software for factories. It's about creating a repeatable way to operate software as it becomes part of everyday manufacturing. FlowFuse provides the platform that turns individual software projects into a scalable software-defined manufacturing environment.

Where Manufacturing Is Heading

The factories that adapt fastest over the next decade won't necessarily be the ones with the newest equipment. They'll be the ones that can turn one operational problem into one working application, then reuse and extend it the next time the same problem shows up on another line or at another site. That's the real shift behind software-defined manufacturing: not a single large modernization project, but a growing library of applications that connect existing equipment, adapt as requirements change, and compound in value over time. FlowFuse is the platform manufacturers use to build that library, one application, one production line, one factory at a time.

Ready to start building software-defined applications for your factory?

Talk to the FlowFuse team about connecting your PLCs, devices, and enterprise systems into industrial applications you can build, deploy, and manage with version control.

Contact Us

Many factories still record downtime on paper or in spreadsheets. Others rely on PLC alarms without keeping a centralized history that teams can review and analyze later.

In this tutorial, you'll build a machine downtime tracking application using FlowFuse. The application records machine stop and start events, calculates downtime duration, lets operators assign downtime reasons, and displays a live dashboard with unresolved events and key metrics. Following the steps below, you can have this application built and deployed in about 10-15 minutes.

The finished dashboard: KPI cards on top, unresolved stoppages below.

You can interact with the live demo here: .

By the end, you'll have a foundation you can extend into OEE, production reporting, maintenance dashboards, or MES integrations.

What You'll Need

Before you start building, get these ready:

• A FlowFuse account. Sign up for FlowFuse Cloud, or use a self-hosted instance.
• A FlowFuse instance up and running. If you don't have one yet, create a new instance from your FlowFuse Platform.
• FlowFuse Dashboard installed. This tutorial uses @flowfuse/node-red-dashboard nodes (ui-button, ui-table, ui-chart) to build the operator interface. Install it from the Palette Manager if it isn't already in your instance.
• The Humanizer node installed. This is what turns raw downtime into readable text like "12 minutes." It comes from the node-red-contrib-moment package, install it from the Palette Manager.

You won't need a PLC or any real hardware for this tutorial. We'll simulate machine stop and start events with inject nodes, and the same flow logic applies later when you connect real signals.

How the Application Works

Before we build anything, let's first walk through what it should do and how the flow will look:

1. Machine stops. A signal comes in and a new downtime record opens for that machine.
2. Machine starts again. The record closes on its own, and the duration gets calculated.
3. Operator logs a reason. From the dashboard, closing it manually too if it wasn't already.
4. The table shows what's unresolved. Anything open, or anything closed without a reason, stays visible with the clock still running next to it.
5. The KPI cards keep score. Machines down now, missing reasons, average downtime, and the most common reason.

Once you see these five pieces working together, the rest of the tutorial is just wiring them up.

Setting Up the Database Table

Everything in this application reads from and writes to a single table, so that's where we start.

Note: FlowFuse Tables is currently in beta and available to Enterprise tier teams on FlowFuse Cloud, as well as Enterprise licensed self hosted teams running on Kubernetes. If you're on a different tier, you can follow along using any external database instead, Postgres, MySQL, or whatever you already have, with the standard database nodes from the palette. The SQL and flow logic in this tutorial will work the same either way.

1. Add a Query node to your canvas. This lets you run SQL queries directly against your FlowFuse managed database.
2. Set its query to create the table:

CREATE TABLE IF NOT EXISTS downtime_events (
    id SERIAL PRIMARY KEY,
    machine_id TEXT NOT NULL,
    status TEXT NOT NULL DEFAULT 'Open',
    reason TEXT,
    comments TEXT,
    start_time TIMESTAMPTZ NOT NULL,
    end_time TIMESTAMPTZ,
    duration_seconds INTEGER,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

3. Wire an inject node into the Query node. This is what triggers the query to run.
4. Add a debug node after the Query node. This lets you confirm the table was created successfully.
5. Click the inject node once, then check the debug sidebar. You should see a confirmation that the query ran.

Each row in this table represents one stoppage. Status tracks whether it's open or closed, reason and comments stay empty until an operator fills them in, and duration_seconds gets calculated the moment a stoppage closes.

With the table in place, the application has somewhere to write to. Next, we'll set up the event that opens a record the moment a machine stops.

Capturing Stop and Start Events

With the table ready, the next step is getting machine events into it, using MQTT.

Note: this tutorial uses the FlowFuse built in broker, available to Pro and Enterprise tier teams on FlowFuse Cloud. If you're on a different tier, contact us to get access, or use your own broker with the standard MQTT nodes instead, they work the same way here.

The event names used here, downtime_started and downtime_ended, are just an example. Your source may use different tags or a boolean instead of a string. What matters is the pattern, one signal opens a record and one closes it, so adjust to match your actual data.

1. Add an ff-mqtt-in node to the canvas, name it "Machine Events In", and set the topic to factory/plant2/line1/+/events, with QoS 0. Once you deploy this node, it will automatically pick up the connection and credentials for your team's broker, no config node needed.

The Machine Events In node subscribed to the wildcard topic.

2. Add a switch node checking payload.event, with two rules, downtime_started and downtime_ended.

Routing incoming events by type before they reach the database.

3. For downtime_started, add a change node before the Query node with two rules: set queryParameters.machine_id to payload.machine_id (msg), and set queryParameters.timestamp to payload.timestamp (msg).

Both sides of each rule set to msg, this is the step most likely to get mistyped.

4. Add the Query node itself:

INSERT INTO downtime_events (machine_id, start_time)
SELECT $machine_id, $timestamp
WHERE NOT EXISTS (
    SELECT 1 FROM downtime_events
    WHERE machine_id = $machine_id AND status = 'Open'
);

5. For downtime_ended, add the same kind of change node, queryParameters.machine_id and queryParameters.timestamp mapped the same way, then a separate Query node:

UPDATE downtime_events
SET status = 'Closed',
    end_time = $timestamp,
    duration_seconds = EXTRACT(EPOCH FROM ($timestamp::timestamptz - start_time))
WHERE machine_id = $machine_id AND status = 'Open';

To test without hardware, import the following flow:

This gives you two buttons, one that simulates a machine stopping, one that simulates it starting again, wired through a function node that builds the topic and payload, then out over MQTT just like a real device would.

Deploy, click Simulate: Downtime Started, then check your table, a new open record should appear. Click Simulate: Downtime Ended and it should close with a duration.

Next, the dashboard table and the reason form operators use to close and explain a stoppage.

Building the Dashboard Table and Reason Form

With events flowing into the database, the next step is showing them to the operator, and giving them a way to log why a machine stopped. Before starting, add a ui-page named "Downtime Events" and a ui-group named "Stoppages" on that page, this is where the table will live.

1. Go back to your event flow from the last section, after both Query nodes, downtime_started and downtime_ended, add a link out node. Give it a name like "event processed" so it's easy to find later.
2. In this new part of the flow, add a link in node and connect it to that same link out node. This is what lets the dashboard react any time a record opens or closes, without wiring long lines across the canvas.
3. There's one gap to close before moving on. The table only refreshes when an event comes in, so if a machine stays down for an hour with no new signal, "Open For" will sit frozen instead of counting up. Add an inject node set to repeat every 30 seconds, with its own link out wired to the same link in from step 2. This keeps the table and KPI cards refreshing on their own, even when nothing else is happening.
4. After the link in node, add a Query node that pulls every stoppage that's either still running or missing a reason. This is a triage table, so it only ever shows what still needs attention, once a stoppage is closed and explained, it drops off:

SELECT *,
       EXTRACT(EPOCH FROM start_time) AS start_epoch,
       TO_CHAR(start_time, 'DD Mon YYYY, HH12:MI AM') AS start_time_display,
       COALESCE(TO_CHAR(end_time, 'DD Mon YYYY, HH12:MI AM'), '-') AS end_time_display,
       COALESCE(reason, 'Not logged') AS reason_display,
       CASE WHEN reason IS NULL THEN true ELSE false END AS needs_review
FROM downtime_events
WHERE status = 'Open' OR reason IS NULL
ORDER BY CASE WHEN status = 'Open' THEN 0 ELSE 1 END, start_time DESC;

This formats the timestamps into something readable, like 07 Jul 2026, 02:45 PM, sorts open stoppages to the top, and falls back to a dash or "Not logged" instead of a blank cell wherever a value is missing.

5. Add a split node after it, to break the result set into individual rows so each one can be processed on its own.
6. Add a change node that computes how long each stoppage has been open, using JSONata. Set the rule to payload.elapsed_seconds, type JSONata:

$floor($millis() / 1000 - $number(payload.start_epoch))

7. Add a humanizer node after that, set to read from elapsed_seconds. This turns the raw number into something readable, like "12 minutes" instead of "720".
8. Add a function node named Colorize Duration. This wraps the humanized value in a colored badge, so a stoppage that's dragged on stands out without anyone having to read the number:

Tip: You don't have to write this JavaScript yourself. Use FlowFuse Expert and describe the logic in plain English. It will generate the code for you.

const seconds = msg.payload.elapsed_seconds || 0;
let color = "green";

if (seconds >= 1800) {
    color = "red";
} else if (seconds >= 300) {
    color = "orange";
}

msg.payload.duration_html = `<span style="background:${color}; color:white; padding:2px 8px; border-radius:4px;">${msg.payload.humanized}</span>`;

return msg;

Under five minutes shows green, under thirty shows orange, anything longer shows red. Adjust the thresholds to whatever counts as concerning on your floor.

9. Add a join node set to rebuild the rows back into a single array, so the table gets the full list at once instead of one row at a time.
10. Add a ui-table node, assign it to the Stoppages group you created earlier, and wire it to the join node. Set up the following columns:

• Machine, key machine_id, type Text
• Start Time, key start_time_display, type Text
• End Time, key end_time_display, type Text
• Open For, key duration_html, type HTML
• a button column labeled something like "Close & Log Reason"

The HTML type on Open For is what renders the colored badge instead of showing raw tags. The query also computes reason_display and needs_review, these aren't shown as columns here, but stay available in the row data if you want to add them to the table later.

Column setup for the Stoppages table, including the HTML type on Open For.

11. Wire the table's button output to a ui-template node. Leave its group field empty and set its page to the same "Downtime Events" page, since this needs to render as a popup dialog over the whole page, not sit inside the table's group. This is where the reason form lives, a small custom dialog with a dropdown for reason and a text field for optional comments, built with a bit of Vue, since there's no default form node for this exact popup-on-row-click pattern:

Tip: You don't have to write the Vue code yourself. Use FlowFuse Expert and describe the interface in plain English. It will generate the ui-template code for you.

<template>
  <v-dialog v-model="show" max-width="420">
    <v-card prepend-icon="mdi-alert-circle-outline" title="Record Downtime Reason">
      <v-card-subtitle>{{ machine_id }}, Stoppage #{{ id_value }}</v-card-subtitle>
      <v-card-text>
        <v-select v-model="reason" :items="reasonOptions" label="Reason*" required></v-select>
        <v-textarea v-model="comments" label="Comments (optional)" rows="2"></v-textarea>
      </v-card-text>
      <v-divider></v-divider>
      <v-card-actions>
        <v-spacer></v-spacer>
        <v-btn text="Close" variant="plain" @click="handleClose"></v-btn>
        <v-btn color="primary" text="Save" variant="tonal" :loading="submitting" :disabled="!reason || !id_value || submitting" @click="confirmSubmit"></v-btn>
      </v-card-actions>
    </v-card>
  </v-dialog>
</template>

<script>
export default {
  data() {
    return {
      show: false,
      id_value: null,
      machine_id: '',
      reason: null,
      comments: '',
      submitting: false,
      reasonOptions: [
        'Mechanical Failure',
        'Electrical Fault',
        'Material Shortage',
        'Changeover',
        'Operator Break',
        'Quality Issue',
        'Other'
      ]
    }
  },
  mounted() {
    this.socketHandler = (msg) => {
      if (msg?.payload?.id) {
        this.id_value = msg.payload.id;
        this.machine_id = msg.payload.machine_id;
        this.reason = null;
        this.comments = '';
        this.submitting = false;
        this.show = true;
      }
    };
    this.$socket.on('msg-input:' + this.id, this.socketHandler);
  },
  beforeUnmount() {
    this.$socket.off('msg-input:' + this.id, this.socketHandler);
  },
  methods: {
    handleClose() {
      if (this.reason || this.comments) {
        if (!confirm('Discard the reason you entered?')) return;
      }
      this.show = false;
    },
    confirmSubmit() {
      if (!confirm(`Close this stoppage on ${this.machine_id} with reason "${this.reason}"?`)) return;
      this.submitReason();
    },
    submitReason() {
      if (!this.id_value || this.submitting) return;
      this.submitting = true;
      this.send({
        payload: {
          id: this.id_value,
          reason: this.reason,
          comments: this.comments
        }
      });
      this.show = false;
    }
  }
}
</script>