Implementing AI in a manufacturing environment is more than selecting the right model. It requires connecting data, building applications, and bringing results to where they can have the most impact. This article covers the main use cases for AI in manufacturing, the software required, and how to implement AI in production.

What Is AI in Manufacturing?

AI stands for artificial intelligence. It encompasses technologies that enable learning from data, recognizing patterns, making predictions, and performing tasks that require human intelligence.

Applied to manufacturing, AI can analyze production data to detect anomalies and defects, predict equipment failures, optimize processes, and support production decisions.

Common Use Cases of AI in Manufacturing

AI can be applied to many aspects of a manufacturing operation. The particular use case depends on the process, the problem to be addressed, and the data involved.

At a high level, AI can help manufacturers predict what may happen, detect problems as they occur, optimize processes and resources, assist operators and engineers through applications and analysis, and automate repetitive tasks. These capabilities span equipment maintenance, quality inspection, process optimization, and support for operators and engineers.

Predictive Maintenance

Equipment availability is one of the most critical metrics in manufacturing, and unplanned downtime is costly. Predictive maintenance uses AI to estimate when a machine is likely to fail, so maintenance can be scheduled before it does.

The model analyzes machine data over time to find patterns associated with equipment degradation. For example, it might analyze vibration, temperature, and current data from a motor to detect changes that predict a bearing is starting to wear. Maintenance teams can use that signal to investigate early, order parts in advance, and schedule the work during planned downtime rather than after a breakdown.

Anomaly Detection

Anomaly detection is similar to predictive maintenance, but it answers a different question. Instead of predicting a specific failure, it flags when equipment has stopped behaving normally, and it doesn't need examples of past failures to do it.

The model learns what normal looks like from signals such as temperature, pressure, vibration, current consumption, and cycle time, then raises an alert when readings stray from that pattern. Since it only needs normal operating data, it's a practical starting point when failures are rare or poorly documented.

For example, an AI-powered motor anomaly detector built with FlowFuse can detect abnormal behavior in a motor's current consumption, so teams can investigate before the issue turns into a larger production problem.

Quality Inspection

The same pattern recognition can be used to inspect product quality. AI-powered vision systems can detect defects, variations, or other characteristics that are hard to catch consistently through manual inspection.

For example, a camera can capture each product as it exits a conveyor while a vision model checks for surface defects. The results can be used to sort defective products and reveal recurring issues that point back to a particular machine, tool, or material batch.

Process and Energy Optimization

Process optimization is about making production itself as efficient as possible. AI can analyze process variables to see which ones contribute the most to the outcome, for example machine speed, temperature, material feed rate, and energy use, to find the combination that delivers the required output with the least waste.

Energy is a typical optimization target, since it's often one of the largest controllable costs. AI can flag wasteful energy usage such as idling equipment or compressed air leaks, and help shift flexible loads to lower-cost periods. These optimizations are typically measured in terms of energy per unit produced.

Demand Forecasting

AI can find patterns in historical demand data that indicate future trends. Manufacturers can use this to estimate demand for particular products or components in the coming weeks and months, accounting for seasonality, promotions, and market changes.

Production Planning and Scheduling

Building on demand forecasts, AI can help decide what to produce, when, and on which line. It can sequence orders, balance workloads, anticipate material shortages, and re-plan when a machine goes down or a rush order arrives.

The value is in handling many constraints at once, such as machine availability, changeover times, material lead times, and delivery dates. Many teams start with recommendations that a planner reviews before moving toward automated scheduling.

Digital Twins and Simulation

Digital twins create virtual representations of machines, production lines, or processes using data from their physical counterparts. AI can analyze this data to identify patterns, predict outcomes, and test “what if” scenarios, such as changes to line speed or production settings, before applying them to the real process.

Simulation can also supplement real-world data when failures are rare or difficult to capture. These applications are typically most valuable for complex or high-value processes where testing changes in production is costly or risky.

Operator Assistance

Operators, engineers, maintenance staff, and quality teams spend a lot of time searching for information: what an alarm means, what the procedure is, whether it's happened before. AI can shorten that search.

For example, when a machine raises an alarm, an operator can ask an AI assistant to explain the likely cause, pull the relevant troubleshooting procedure from a knowledge base, and surface recent data from that machine for review. The same approach works at a plant-wide level, where an engineer can ask which lines are underperforming this week and get an explanation of what's driving the gap.

Software Stack for AI in Manufacturing

AI is only one part of an AI application in manufacturing. To put a model into production, manufacturers also need software to collect and connect machine data, process and store it, run the model, and deliver its results to the systems and people who need them.

Industrial Data and Connectivity

An AI application needs data, which comes from sources including machines and PLCs, sensors, MES, SCADA, databases, cameras, and more.

Industrial connectivity software gathers this data and makes it available to the AI application. FlowFuse connects industrial equipment and routes this data through the application, which is essential for processing it. Its built-in MQTT broker can also act as the central hub where this data is published and made available to the AI application and other systems.

Edge and Cloud Computing

AI applications need computing resources to run models and generate predictions or other outputs. That computation can happen close to the machine at the edge or in the cloud, depending on the requirements of the workload.

Edge AI is useful where inference needs to happen with low latency and without a network connection, while cloud AI can provide access to more compute for demanding workloads. FlowFuse supports AI applications across both environments, running AI alongside industrial applications at the edge and connecting flows to cloud-hosted AI services when required.

AI and Machine Learning

The AI component itself depends on the use case, since it needs to be trained to perform a particular task such as predicting demand, detecting anomalies, or optimizing a process.

Various AI and machine learning software can implement these functions. For example, FlowFuse can run an ONNX machine learning model on an edge device using the ONNX node.

Data Storage

Depending on the application, data may need to be stored for later use, such as training models or displaying results to users. Various types of databases, including SQL and NoSQL, can be used for this.

FlowFuse can connect to databases already in use in the manufacturing environment, and also provides a built-in database for storing operational data.

Applications and Workflows

Finally, for an AI application to have an effect, its results need to reach the people and systems that can act on them. That could be a dashboard showing predicted demand, an alert indicating a machine is about to fail, or a maintenance task created automatically when an anomaly is detected.

FlowFuse provides a visual application development environment for building these applications and workflows and connecting them to industrial data. FlowFuse also integrates with AI agents, allowing FlowFuse Expert and a coding agent of your choice to interact with the platform and build applications and data workflows through its MCP server and MCP nodes. This is how external AI services such as Claude, OpenAI, and Gemini connect to FlowFuse to work with manufacturing data and applications.

Not every application needs the full stack; it depends on the problem you're solving. At minimum, you need industrial data connectivity, somewhere to run the model, and the model itself. Beyond that, some applications also need data storage, dashboards, workflows, or AI assistants before the results can actually close the loop.

How to Implement AI in Manufacturing

A successful manufacturing AI project starts with a clear production problem, not an AI model. In practice, implementation can be approached in five stages:

1. Define the outcome. Decide what you want to improve: reduce downtime, detect defects, increase throughput, help operators troubleshoot equipment faster. A specific, measurable outcome makes the project easier to scope and evaluate.
2. Validate the data. Identify the data needed to support the use case and confirm it's available and collected consistently.
3. Pilot a focused use case. Connect the relevant factory systems and test the AI on one machine, line, or process rather than across the entire plant. Starting small makes it easier to validate results, measure impact, and catch data or integration issues before scaling.
4. Put results into the workflow. Once results are validated, connect them to where people can act on them: a dashboard that displays a prediction, an alert that indicates a likely failure, or a maintenance task created automatically when an anomaly is detected. A prediction only creates value when someone can act on it.
5. Monitor and iterate. Treat the application as part of normal operations, not a one-time deployment. Equipment, processes, and production conditions change over time, and the models and applications built around them may need updating as new data becomes available.

The objective isn't to add AI for its own sake, but to apply it where it produces a measurable improvement in a real manufacturing process.

Connect Your Factory Data to an AI Application

Talk to the FlowFuse team about connecting your machines, PLCs, and factory systems to the AI use case you're evaluating.

Contact Us

A Manufacturing Execution System (MES) sits between two systems every plant already runs. ERP plans production at the scale of days and weeks: what to build, how much, by when. SCADA supervises the equipment below it, collecting tag data from PLCs in real time. MES is the layer in between, taking the ERP plan, dispatching it as work orders, and tracking execution as it happens.

From Monolithic MES to Modular MES

For most of MES's history, the entire stack shipped as one tightly coupled platform (hence the term ‘monolith’). Changing any piece meant touching the whole system: a vendor engagement and months of lead time for custom configurations.

That model is breaking down for the same reason why automotive plants are hard to standardize in the first place. Every plant, product line, and OEM contract has its own quality requirements, downtime taxonomy, and mix of legacy equipment. The industry's response has been a shift toward modular, composable MES architecture that breaks routing, quality, genealogy, and downtime tracking into pieces that can be built or replaced independently. Extending an existing MES, the third option here, is that same shift applied to a plant that already has a working MES and no interest in replacing it just to get modularity.

Why Automotive Manufacturing Makes MES Decisions Harder

Automotive manufacturing carries more accumulated technical debt than most manufacturing environments, and it's structural, not incidental. Equipment spans decades, so a single line can mix PLCs from different vendors and eras never built to talk to each other. Plants added through M&A bring their own MES instances, ERP configurations, and naming conventions with them. Every integration is custom and manual, usually an integrator writing point-to-point code for one connection at one plant that nobody else can safely touch, and when that engineer leaves, it's a real risk.

None of this is unique to any specific manufacturer. It's the normal condition of any automotive manufacturer or supplier, and it's exactly why a corporate rollout can't assume one MES configuration fits every site.

The Real Decision: Buy, Build, or Extend

When Buying an Off-the-Shelf MES Is Right

An off-the-shelf MES is the fastest path to solid routing, dispatch, and out-of-box error-proofing. It's right when a plant runs a standardized process, has no system yet, and needs core execution running quickly. Cost varies a lot by architecture and market: on-premise systems typically run {% raw %}$120,000 to$600,000{% endraw %} upfront, plus around 20% of license cost annually in maintenance, with six to eighteen months before going live, while cloud-native platforms start in the low thousands per month (Symestic, 2026). In the UK, a cloud MES typically runs £6,000 to £15,000 a year with a 90-day go-live, against £75,000 to £150,000 to implement on-premise and three-year totals of £120,000 to £450,000 (TotalControlPro, 2025).

There are plenty of strong MES platforms on the market, from comprehensive systems like Siemens Opcenter Execution and Rockwell's Plex, to composable, build-your-own-app platforms like Tulip. Manufacturers running these don't need to rip them out to close the gaps this blog covers. In practice, manufacturers have implemented FlowFuse alongside deployments like these to extend their functionality, which is what the next option is about.

When Building a Custom MES Is Right

Building makes sense when a process is differentiated enough that no off-the-shelf platform fits it, and the organization has the capacity to own it long term, not just ship it once. The trade-off is real: a custom build competes with the IT roadmap for a year or more, and every future change depends on that same team staying in place. Hexagon Manufacturing Intelligence took this route, building its own Smart Factory Manager rather than buying off-the-shelf, after concluding the fit and long-term ownership were worth the investment (IndustryWeek, 2025).

When Extending Your Existing MES Is The Right Move

Extending is right when the core MES already works, and the actual gaps are plant-specific: a quality gate that enforces a specific control plan, a genealogy structure that satisfies a specific OEM's safe launch requirements, a downtime taxonomy that matches how a plant fails. Those are the pieces that get patched together in scripts and spreadsheets when nobody builds them properly, and what a modular extension layer standardizes.

This is where FlowFuse fits, and it's worth being direct: FlowFuse is not an MES, and it doesn't compete with the one already running the plant. It's an application layer that connects to MES, ERP, and SCADA systems already in place and makes them more configurable at the plant level.

It's also worth naming a fact that shapes this whole decision: to our knowledge, no vendor sells an MES built and sold specifically as an automotive-only product. MES platforms are horizontal, enterprise-wide systems used across automotive, pharma, food and beverage, and electronics alike, not vertical-specific products with a separate automotive SKU. That's why customizing your existing MES is often the more practical path:

• Capturing torque measurements across the chassis line with poka-yoke checks that stop the station before a bad fastener moves downstream, then standardizing that application for other lines like powertrain.
• Measuring operator productivity at one plant and rolling that application out across all sites so data flows into a standard dashboard without manual reconciliation.
• Automating genealogy capture, binding component lots to serial numbers, for one vehicle program, then extending that logic to additional programs or plants instead of running a custom integration project each time.
• Adding real-time quality gate enforcement, control plan limits with automatic hold-and-containment, to a line where the base MES configuration lacks it, then standardizing that pattern across other lines and plants building for the same OEM, even though each site submits its own PPAP per part number.

Where the Gaps Are, and What Extension Needs to Cover

Routing and dispatch are the core of what a packaged MES sells, and an extension layer doesn't need to touch that logic. FlowFuse supports IT/OT connectivity that layers on top of existing MES routing, adding what a packaged system leaves as a gap.

The gaps themselves cluster into two categories: quality gate enforcement (capturing a measurement, holding the station when a control-plan rule trips, routing the part to containment, and logging it against the serial number) and standardization across sites (a shared downtime taxonomy and genealogy captured at the point of consumption, so a reason code or a build record means the same thing at every plant). Unplanned downtime alone costs industrial manufacturers an estimated $50 billion annually (Forbes Technology Council, 2022), and without standardization, a recall investigation ends up tracing the same defect to a shift's production at one plant and specific serial numbers at another.

Final Thoughts

So where do we go from here? It honestly depends on how fast you want to see results and the availability of your existing resources.

If the core MES is good, a manufacturer can use FlowFuse to extend its existing capabilities rather than replace it, closing the quality gate, genealogy, and downtime gaps most vendors leave for each plant to solve on its own. FlowFuse gives IT and operations teams a way to build custom applications, starting small and expanding from there, instead of reconfiguring the same enforcement at every site. It's part of FlowFuse's broader automotive manufacturing solutions, used by 30+ automotive manufacturers in 20 countries.

Sources

• Forbes Technology Council. (2022). "Unplanned downtime costs more than you think."
• Symestic. (2026). "MES System Prices 2026: Cost Comparison, TCO & ROI."
• TotalControlPro. (2025). "The End of the Production Black Box: How Much Does a Modern MES Really Cost?"
• IndustryWeek. (2025). "Build or Buy Your MES? Lessons from Hexagon Manufacturing Intelligence."

Start building with your own industrial data

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

Try it out

A good template keeps the analysis disciplined: one problem statement, one causal chain, evidence at every step, and a corrective action with an owner and a due date.

Download the free template below to give your team a consistent way to run a 5 Whys analysis and document it for corrective action tracking.

What Should Be on a 5 Whys Template?

A 5 Whys template only needs a few fields, each filled in with something you can verify rather than an assumption:

• Problem statement: What happened, where, when, and how you know it.
• Why 1–5 (as needed): Each answer builds on the one before it. Stop once you reach something fixable at a systemic level.
• Root cause: The systemic gap the chain of whys points to.
• Corrective action: The specific fix, an owner, and a due date.
• Verification: Confirmation, at a later date, that the fix actually held.

Not every analysis needs all five whys filled in, and some need more than five. The fields matter more than the count.

How to Fill In a 5 Whys Template

Each answer should be specific enough that someone reading it later, without having been in the room, understands exactly what was found.

The goal is an answer that is objective and traceable to evidence (a log, a measurement, a witness), not a label that just restates the problem.

5 Whys Template Example

Consider a line that produced 40 rejected units during a single shift.

The team fills in the problem statement with the exact count, shift, and defect type rather than "quality issue on Line 3." Each why is answered with something checked on the floor, not a guess, until the chain reaches a worn sensor that was past its replacement interval. The corrective action gets an owner and a due date, and a follow-up entry on the template confirms the replacement held during the next production run.

The template makes this process repeatable across shifts and lines without each team reinventing the format.

Keep the Template Simple

A 5 Whys template should stay simple enough to fill out during the analysis itself, not after the fact from memory.

Resist adding fields for every possible category of information. If a template starts accumulating sign-off boxes, severity ratings, and cost fields beyond the owner and due date, it has drifted from a root cause tool into a different kind of form. Keep it to the problem, the chain of whys, the root cause, and the corrective action.

Connect Production Data to Corrective Actions

See how FlowFuse connects machine and process data with quality workflows so your team can track corrective actions and verify that fixes work.

Book a Demo

Unlike a 5 Whys template, which documents one causal chain going deep, a fishbone template holds several categories side by side going wide. That shape is the whole point: it's built for the moment you don't yet know where a problem lives.

Download the free template below and use it the next time your team needs to brainstorm causes across categories, not drill into one.

Fishbone Diagram Parts

A fishbone template is really just four zones, each doing a different job:

• The head: a single problem statement, specific enough that "what happened, where, and how often" are all answered in one sentence.
• The spine: the line running into the head. It doesn't hold information, it just gives the ribs somewhere to attach.
• The ribs: four to six categories branching off the spine. The 6Ms (Manpower, Method, Machine, Material, Measurement, Mother Nature) are the manufacturing default, not a requirement, rename or drop any that don't match your process.
• The branches: the specific, checkable causes hanging off each rib, plus a note on which ones you later verified against data.

An empty rib isn't a gap to fill. It means that category doesn't apply to this problem, and forcing entries into it just to fill the space adds noise, not signal.

How to Fill Out the Template

The most common way teams misuse the template is drilling into the first plausible cause the moment someone suggests it. That collapses a breadth tool into a narrow one before it's done its job.

Work one rib at a time and exhaust it before moving to the next: everything Machine-related, then everything Material-related, and so on. Only once every rib has been brainstormed should the team circle the two or three strongest branches and hand those to a depth tool like the 5 Whys.

Vague branches defeat the exercise just as fast as skipping ribs does:

A branch should be specific and testable, not a category name repeated back as if it were an answer.

Example

A packaging line is rejecting cartons because the printed date code is smearing, that's the head. Working rib by rib, the team notes a drifted print head under Machine, a new ink supplier under Material, an unwritten cleaning interval under Method, and rising plant humidity since an HVAC repair under Mother Nature. No single rib explains it alone.

Two branches stand out once all six are filled: the new ink and the humidity shift. Those are the ones worth verifying against a log or measurement, not whichever one came up first.

Using the Template for Different Problems

The categories on this template are meant to be edited, not treated as fixed. A service outage will need ribs that look nothing like a factory floor's, and that's expected. What should stay constant across every use is the shape: a specific head, ribs that actually apply, and branches specific enough to check against real data rather than restating the category they sit under.

Verify Which Suspected Cause Is Real

See how FlowFuse connects PLCs, sensors, and quality systems so your team can test which cause on the fishbone is real, using live production data.

Book a Demo

It's a core part of quality management in standards such as ISO 9001 and ISO 13485, but determining whether an action actually worked can be difficult when teams rely on manually updated records. Connecting shop-floor data to quality workflows, with platforms like FlowFuse, can give teams objective production data to support investigations and effectiveness checks.

This article explains the difference between corrective and preventive action, how each process works, where CAPA systems break down, and how FlowFuse supports CAPA with connected production data.

What Is Corrective Action and Preventive Action?

Corrective action is the action taken to eliminate the cause of an existing nonconformity and prevent it from recurring.

Preventive action is the action taken to address the cause of a potential nonconformity before it occurs.

Under ISO 9001:2015, corrective action is addressed in Clause 10.2. Preventive action is no longer a standalone requirement; the 2015 revision incorporated prevention into the standard's risk-based thinking approach. Quality teams may still use preventive action as part of their risk management practices.

A Simple Example

Say a machine's cutting tool wears down and starts producing parts outside tolerance. Replacing the worn tool and changing the maintenance interval to prevent the same failure from recurring is corrective action because it addresses an actual defect and its cause.

If a technician notices during a routine check that a different tool on a similar machine is wearing faster than expected and replaces it before it produces a bad part, that's preventive action. No defect has occurred; the action addresses a potential failure.

This is the same logic behind preventive maintenance programs and poka-yoke, or mistake-proofing: both aim to prevent a failure before it produces a defect.

Fixing the immediate bad parts, such as scrapping them or sorting the batch, is neither. That's containment. Containment limits the immediate impact, while corrective and preventive actions address the cause.

Root Cause Analysis

Corrective and preventive actions depend on understanding why a problem occurred or could occur. Stopping at the first plausible explanation can result in a fix that addresses the symptom while leaving the underlying cause in place.

A few methods cover most cases:

• 5 Whys: Ask "why" repeatedly, with each answer guiding the next question, until you reach an actionable cause rather than restating the symptom.
• Fishbone (Ishikawa) diagram: Maps potential causes across categories such as people, methods, materials, and equipment. It's useful when a problem may have several contributing causes.
• Fault tree analysis: Works backward from a failure, breaking it into the combination of conditions that had to be present for it to occur. It's commonly used for complex or safety-critical processes; NASA's Fault Tree Handbook is a widely cited reference for the method.

The investigation should draw on multiple sources of evidence, including process records, operator interviews, maintenance logs, and inspection results. A problem can have more than one contributing cause, so addressing only one may not prevent recurrence.

Corrective Action vs. Preventive Action: Comparison

The key difference is when the action is taken: corrective action responds to an existing problem, while preventive action addresses a potential one.

The Corrective Action Process

A corrective action process typically follows these five steps:

1. Identify and document the nonconformance. Record what happened, when it happened, and any immediate containment taken.
2. Investigate the cause. Use an appropriate root cause analysis method and gather enough evidence to understand why the nonconformity occurred.
3. Determine the appropriate response. The severity and impact of the problem determine the response, which can range from changing a process to scrapping product, notifying customers, or initiating a recall.
4. Implement the action. Address the identified cause rather than only correcting the defective output.
5. Verify effectiveness. Monitor the relevant process or quality indicator to confirm that the action achieved its intended result before closing the CAPA.

The Preventive Action Process

Preventive action follows a similar structure, but starts with a potential failure rather than an existing nonconformity:

1. Identify potential failure points. Use FMEA, near-miss trends, maintenance logs, or process capability data to identify where a nonconformity could occur.
2. Assess and prioritize risk. Evaluate likelihood and severity to determine which risks require action.
3. Implement the preventive measure. This might mean changing a maintenance schedule, modifying a process, updating work instructions, or adding mistake-proofing.
4. Monitor the result. Track the relevant process or risk indicator to determine whether the preventive measure achieved its intended result.
5. Document the action. Record the identified risk, action taken, and evidence that the measure was effective.

Both processes can follow the Plan-Do-Check-Act (PDCA) cycle: plan and investigate, implement the action, check whether it worked, then apply what was learned.

Where CAPA Systems Break Down

A CAPA process can look complete on paper and still fail to solve the underlying problem. One common issue is that teams focus on forms and approval chains instead of collecting enough evidence during the investigation. Another is stopping at the first plausible cause and moving directly to a fix.

Even when the right action is identified, closing the CAPA without objective evidence can make it difficult to determine whether the change actually worked.

A strong CAPA process needs clear ownership, an evidence-based investigation, and a defined effectiveness check. Production data can support this. For example, SPC charts built from live process data can show whether a corrective action actually shifted a process back into control.

How FlowFuse Supports CAPA

CAPA investigations and effectiveness checks often require data from multiple systems, including machines, PLCs, databases, and quality systems. When that information is disconnected, teams may have to rely on manual records or piece together evidence from several sources.

FlowFuse connects production systems and data sources so manufacturers can use operational data as part of their existing CAPA process.

For example, FlowFuse can help teams:

• Collect relevant production data when a quality issue or nonconformity occurs using data integration workflows.
• Connect data across machines, PLCs, databases, and quality systems to support root cause investigations.
• Automate workflows and notifications when production or quality events require attention, including production monitoring and notifications.
• Monitor process and quality data after an action is implemented to provide evidence for effectiveness checks, such as through quality dashboards.

FlowFuse does not replace an organization's CAPA or quality management system. Instead, it helps connect the production data and operational workflows that support investigations, corrective actions, and verification that an action actually worked.

Tracking CAPA Effectiveness

Closing a CAPA does not mean the problem is solved. Teams need to check whether the action actually worked.

Useful measures include CAPA cycle time, recurrence rate, overdue actions, and recurring root causes. A Pareto chart can help identify which causes need attention, while MTTF, MTBF, and MTTR can help measure the effect of corrective actions on equipment reliability.

The quality of these measures depends on the data behind them. Production records, process measurements, machine states, and maintenance history can give teams the evidence they need to investigate a problem and confirm that the action was effective.

Start building with your own industrial data

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

Try it out

Much of this still runs on paper checklists and spreadsheets, which makes it easy for inspection results to drift away from the production data that explains them.

What Is First Article Inspection (FAI)?

First Article Inspection (FAI) is a planned, complete, independent, and documented physical and functional inspection process used to verify that production processes can produce an item that meets specified requirements.

That definition comes from SAE AS9102, the standard that establishes the requirements for performing and documenting FAI. AS9102 originated in aerospace, but its terminology and report structure now shape how many customers outside aerospace, including automotive customers, define FAI in their own purchase documents.

Inspectors check dimensions, tolerances, materials, surface finishes, and other specified characteristics against the engineering drawing, specifications, and applicable requirements.

The goal is to confirm that the manufacturing process can produce a part that meets the defined requirements before or during production approval.

FAI Example: Inspecting an Automotive Part

Consider a supplier manufacturing a machined mounting bracket. Its drawing specifies:

If the hole position measured 0.35 mm against a ±0.2 mm requirement, it would fail. The supplier would document the nonconformance, determine the cause, take the required corrective action, and reinspect the affected characteristic.

When Is FAI Required?

FAI requirements vary by customer, industry, and quality procedures. It is typically performed when a new part or a change could affect the part's requirements.

In automotive, the specifics usually come from the customer rather than from a single industry-wide FAI standard. IATF 16949 requires suppliers to run a product and manufacturing process approval process that conforms to requirements the customer defines, and each OEM publishes its own customer-specific requirements through the IATF. Check the applicable purchase document and customer-specific requirements before deciding what to inspect and submit.

Common triggers include:

• New part introduction
• Significant design or engineering changes
• New tooling or equipment
• Manufacturing process changes
• New manufacturing location or supplier
• Production restart after a significant interruption

Depending on the applicable requirements, a change may require a full or partial FAI. A partial FAI focuses on the characteristics affected by the change rather than repeating the entire inspection.

How Does the FAI Process Work?

1. Review the requirements

Use the latest engineering drawing, specifications, and revision. Identify the characteristics that require inspection and any applicable customer requirements.

2. Produce the first article

Manufacture the part using the intended materials, tooling, equipment, and production process. The objective is to inspect a part representative of the manufacturing process being evaluated.

3. Inspect the part

Measure the required characteristics using appropriate inspection equipment. Compare each result with the specified requirement and acceptance criteria.

4. Record the results

Document the requirements, measurements, inspection equipment, and other required information in the FAI report.

5. Address failures

If a characteristic does not conform, document the nonconformance, determine the cause and required corrective action, and reinspect the affected characteristic after correction.

6. Maintain traceability

Maintain records that connect the inspection results to the part, drawing revision, production run, tooling, equipment, and measurement equipment where required. This is the same traceability backbone that makes it easier to determine what was inspected and investigate issues later.

What Does an FAI Report Include?

An FAI report documents the requirements that were inspected and the results obtained. Depending on the applicable requirements, it may include:

• Part number and name
• Drawing number and revision
• Characteristic or feature identification
• Nominal dimensions and tolerances
• Actual measurement results
• Material and process information
• Inspection and measurement equipment
• Inspection date and personnel
• Nonconformities and disposition
• Supporting documentation and traceability information

For example, a dimensional characteristic might be recorded with its drawing requirement, actual measurement, inspection method or equipment, and pass/fail result. This creates a traceable record showing whether the inspected part met the specified requirements.

The exact contents and format of an FAI report depend on the applicable customer, industry, and quality requirements. Customers that work to AS9102 expect the results on its three standard forms: part number accountability, product accountability for material and special processes, and the characteristic-level results.

FAI vs. PPAP

FAI and Production Part Approval Process (PPAP) both help verify that manufactured parts meet requirements, but they serve different purposes. PPAP is defined in the PPAP manual published by AIAG, and most North American OEMs name that manual directly in their customer-specific requirements.

FAI primarily demonstrates that the inspected part conforms to the defined design requirements. PPAP provides broader evidence that the supplier's production process and supporting quality systems are capable of consistently producing conforming parts. AIAG publishes the supporting core tool manuals, including MSA and SPC, that PPAP submissions draw on.

FAI can support a PPAP submission, but it does not replace PPAP when a customer requires it. PPAP approval also isn't the end of the story — most OEMs require a safe launch monitoring period once production starts.

Common First Article Inspection Mistakes

Common FAI errors include using an outdated drawing or specification, uncalibrated inspection equipment, inspecting a part made with the wrong production process, missing characteristics, and incomplete measurement records.

Calibration is where inspection records most often lose their weight. Calibration by a laboratory accredited to ISO/IEC 17025 ties a measurement result back to recognized measurement standards through a documented chain, which is what makes the number on the FAI report defensible during a customer review or an investigation.

Using the correct drawing revision, appropriate and calibrated inspection equipment, the intended production process, and traceable inspection records helps avoid these errors. Tracking calibration status against due dates in a live dashboard makes it easier to catch an overdue instrument before it ends up on an FAI report.

Improving First Article Inspection With Digital Data

Traditional FAI can rely on inspection sheets, spreadsheets, and manual data entry. This can leave inspection results disconnected from the production data associated with the part.

FlowFuse connects machines, inspection systems, databases, and other factory systems so manufacturers can collect and process data in one workflow.

For example, an FAI workflow can associate inspection results with a part, machine, production run, tooling, material batch, or work order. If a hole diameter repeatedly approaches its tolerance, manufacturers can compare inspection results with machine and production data to investigate whether tooling, equipment, material, or a specific production run is contributing to the issue.

FlowFuse does not replace the FAI process. It connects the production data around it, reducing manual data handling and making inspection results easier to use for quality analysis and investigation.

Connect First Article Inspection Data with FlowFuse

Connect inspection results with machine and production data using FlowFuse to reduce manual data handling and investigate quality issues.

Contact Us

That's not how an industrial AI agent should work. It should be able to work directly with your industrial systems, rather than generating something for you to copy and paste.

That's what our first class integrated industrial AI agent, FlowFuse Expert, was built to do. It works within the FlowFuse platform, where it can understand your applications, instances, flows, and operational data, and then build and edit the operational flows directly in Node-RED instances.

So why did this happen?

Ask why they don't use the FlowFuse Expert built into the platform, and the answer usually isn't about quality; it's about policy. Plenty of the companies we work with run an approved-AI-only rule. So for those teams the only option was to use "their AI, through the clipboard" with the alternative being no AI-support at all.

What changed in FlowFuse 3.0

FlowFuse now acts as an MCP server. Your own AI agent connects to it as a client and because the AI agent is yours, so is the choice of model it uses.

That means the AI agent your company already approved can work the platform directly: look at your teams and applications, check what your instances are doing, read runtime logs, query your FlowFuse Tables data, create applications and instances, and build and edit the flows inside your instances.

How an AI agent connects to FlowFuse

Connecting an AI agent to FlowFuse takes three steps depending on the agent you would like to use.

You add one address in your AI agent's connector settings. On FlowFuse Cloud that address is https://app.flowfuse.com/mcp. You are then triggered to sign in to FlowFuse, after which you pick which teams the AI agent may act on, and whether it gets editing rights or read access only.

If you want to jump ahead and get connected now, skip to the steps at the end.

What you're actually granting

"We gave an AI agent access to production" is usually a sentence that ends conversations, so let's clarify.

You choose the teams. If you have a production team and a development team, granting only development means an instruction can only hit what you manage in that team.

You choose read access or editing rights. Read access is useful on its own: what's running, what's failing, what the logs say, what's in your tables, and so on. An industrial AI agent with read access has no ability to change anything. When permitting editing rights, the agent can set up applications, instances, and edit the flows inside of them.

And there are things nobody can grant. An industrial AI agent working through FlowFuse can't delete an instance, an application, a snapshot, or a team. That is because those tools don't exist. Lastly, deploying a Node-RED flow is, for now, still done by you manually as well.

Two things run underneath all of it. The role-based access control that already governs your teams affects the industrial agent too, so it can't reach past what your own account reaches. And every action it takes lands in the audit log attributed to you and marked via MCP, so "what the AI did last Tuesday" is a question with an answer.

Most agents will prompt you and ask before they act. This logic belongs to the agent itself rather than to FlowFuse, so it looks different in each one, but in practice you see the tool call before it runs, so you retain visibility and control.

We're working towards AI that can act as required in production setups and in setups where experimentation is fine, and those are different settings for different scenarios. But what is described above is the boundary as it ships right now.

It builds where you can see it

Node-RED has always been visual. You look at a flow and you can tell what it does.

We didn't want to trade away control for AI, so when your agent builds a flow, it builds it in a live editor session, on the canvas in front of you. You watch the nodes appear and get wired up. If it's going somewhere you don't like, you can see that while it's happening rather than afterwards. Up for review before you enable the deployment.

Asking questions about your platform needs no active browser session open at all. It's flow work specifically that runs in an editor you're looking at.

The conversation with IT

Most people reading this can't add a connector on their company sanctioned AI agent. On ChatGPT, a workspace administrator switches on custom connectors. On Claude Team and Enterprise, an owner adds the connector for the organisation and then people connect individually. On Microsoft Copilot, a tenant administrator approves it.

It's one address. Everyone still signs in with their own FlowFuse account, and still chooses their own scopes, so nobody inherits anyone else's access. Nothing about it makes FlowFuse a new data processor for your organisation.

We're also working on removing the question at all.

Where to start

If your team is on FlowFuse Cloud, you can get connected already. Our Industrial AI page has the three steps for whichever agent you use similar as noted above.

If your team is on FlowFuse self-hosted, make sure to be on at least version FlowFuse 3.0 or higher. On self-hosted, platform messaging runs over the MQTT broker, so the Team Broker needs to be available. Whether anything is needed from you depends on how your self-hosted platform was installed. Our documentation has further details on what to do for custom situations.

For now, begin with any of the following prompts when authenticated with the platform:

Connect your own agent

Three steps, and they depend on which agent you would like to use.

Want to see this against your own setup?

Walk through connecting your agent with our team, on your instances, and see what it can and cannot reach.

Book a Demo

A good checklist is focused rather than comprehensive. It should cover the controls that matter most to the process and use questions that can be answered by observing the work.

If you're building an LPA program, having a consistent set of questions makes it easier for different management layers to audit the same critical controls. Download the free checklist below as a starting point for creating your own LPA.

What Should Be on an LPA Checklist?

LPA questions should come from the controls that are important to the process. Useful sources include the PFMEA, control plan, work instructions, previous audit findings, customer complaints, and recurring scrap or rework.

Depending on the process, a checklist might cover:

• Standard work: Is the current work instruction being used?
• Materials: Is the correct material being used at the station?
• Equipment: Is the machine parameter within the approved range?
• Tooling: Is the torque tool within its required calibration period?
• Error-proofing: Is the poka-yoke device active?
• Traceability: Is the required batch or serial number recorded?

Not every checklist needs all of these areas. Select the controls that are most relevant to the process being audited.

How to Write LPA Questions

Questions should be specific enough that the auditor knows exactly what to check.

The goal is to make each question objective and observable, rather than dependent on the auditor's opinion.

LPA Checklist Example

Consider an automotive assembly station where a component is fastened using a torque-controlled tool.

The checklist might verify that the current work instruction is being used, the correct component is at the station, the torque tool is within its approved range, and the error-proofing system is active.

During the audit, the supervisor finds the torque setting outside the approved range. They correct the setting, record the finding, and check what the station has built since the last verified check. Anything suspect gets segregated before it moves down the line.

A later audit verifies the setting held.

The checklist makes these critical controls easy to verify consistently without turning the LPA into a full process audit.

Keep the Checklist Relevant

A checklist should change when the process or its risks change.

Review it after significant process changes, recurring quality problems, new customer requirements, or findings that show the current questions are no longer sufficient.

Avoid adding questions simply to make the checklist more comprehensive. The goal is to check the controls that matter, not everything that could possibly be checked.

Build a Digital LPA with FlowFuse

Use FlowFuse to build digital LPA forms, connect audit results to machine and production data, trigger alerts, and track corrective actions.

Contact Us

That evidence is often spread across machines, PLCs, sensors, MES platforms, and quality systems. FlowFuse can connect these production systems and bring operational data together, making it easier to access the evidence needed to monitor and demonstrate process performance.

This guide covers VDA 6.3 process elements, scoring, audit evidence, common findings, and how to prepare.

What VDA 6.3 audits

VDA 6.3 was developed by the Verband der Automobilindustrie (VDA) to evaluate process performance across the product and process lifecycle. The VDA QMC describes it as a reference manual for conducting process audits across the automotive supply chain.

VDA 6.3 is different from IATF 16949. IATF 16949 focuses on the automotive quality management system, while VDA 6.3 examines whether a specific process is planned, controlled, and capable of producing the required output. VDA 6.5, by comparison, focuses on the product itself.

Auditors review documented procedures, inspect the production floor, question process owners, and compare records with actual conditions. Having IATF 16949 certification does not guarantee a strong VDA 6.3 result.

When is VDA 6.3 used?

VDA 6.3 can be used at different stages of the supplier and production lifecycle. A potential supplier may be assessed before a contract is awarded, while established suppliers may be audited during product development or series production.

Process audits can also be triggered by major process changes, recurring quality problems, or customer requirements. The scope depends on the purpose of the audit, so an audit does not necessarily cover every process element from P1 to P7.

The seven process elements

VDA 6.3 divides the audit into seven process elements:

P1 is generally used when assessing a potential supplier or new location and is not scored with P2–P7. For established production, the audit typically covers P2–P7.

P6 focuses on the production process and examines six areas: process inputs, work carried out, personnel resources, material resources, effectiveness, and process outputs. These areas cover everything from incoming materials and process instructions to operator qualifications, equipment, process controls, and the quality of the finished output.

How a VDA 6.3 audit works

A VDA 6.3 audit starts with preparation and definition of the audit scope. The auditor reviews relevant information and identifies the processes and personnel to be assessed.

Before the audit, potential process risks should be identified so they can be assessed during the audit. VDA 6.3 uses the Turtle Model as one way to structure this risk analysis. It examines what enters and leaves the process, how the work is performed, which personnel and resources support it, and how process effectiveness is measured. The model can be applied to different process elements, including P6.

Turtle diagram for VDA 6.3 process audits, showing a central process surrounded by six questions covering input, output, resources used, personnel involved, and process results

During the audit, the auditor examines documents, observes the process, asks employees questions, and reviews objective evidence. Findings are recorded and the applicable questions are scored.

The audit ends with a closing meeting where the results and identified weaknesses are discussed. Corrective actions may then be assigned, followed by a review of whether those actions have addressed the findings.

How VDA 6.3 scoring works

Audit questions are scored according to how well the requirement is met:

The auditor bases the score on objective evidence from the process. Individual question scores are then used to calculate the result for the relevant process elements and the overall audit.

The classification is:

• A: 90% or higher — capable
• B: 80–89% — conditionally capable
• C: Below 80% — not capable

Specific downgrade rules can also affect the classification when serious weaknesses are identified. The overall percentage should therefore not be considered in isolation. The A/B/C classification and 10-8-6-4-0 scoring model remain part of VDA 6.3:2023.

What auditors look for

Auditors compare documented requirements with what is happening on the production floor.

They may check control plans against the current process, FMEA and control plan linkage, SPC data and capability values such as Cp and Cpk, reaction plans for out-of-control conditions, operator training records, corrective actions and their effectiveness, and production and inspection records.

The main risk is a gap between documentation and actual production. When production data is spread across different machines and systems, it can be difficult to connect that data back to the documented process and demonstrate that the required controls were followed.

For example, a control plan may identify a bore diameter as a critical characteristic, while the measurement system stores that value under a different name with different limits. If the systems are not connected, proving that the characteristic was checked correctly can require manual data matching.

By connecting these systems, FlowFuse can help make the production data behind these checks easier to access and trace.

Common reasons suppliers lose points

Common findings include outdated control plans after process changes, missing links between FMEAs and control plans, capability values below requirements without an effective reaction plan, weak oversight of sub-suppliers, corrective actions closed without effectiveness evidence, training records that do not match the current process, and production data that cannot be traced to the relevant characteristic or operation.

These issues often develop when process changes are not reflected across documents, systems, and training records.

Layered process audits can help identify these gaps between formal VDA 6.3 audits. Short, regular checks on the production floor can catch bypassed controls, outdated work instructions, and missing records earlier.

How to prepare for a VDA 6.3 audit

Run an internal audit against the applicable VDA 6.3 requirements before the external audit. Focus on evidence from the current production process.

1. Check process documentation. Make sure control plans, work instructions, and FMEAs match the current process.
2. Review production data. Check SPC charts, capability values, inspection records, and deviation logs. Make sure the data can be retrieved quickly.
3. Check the production floor. Verify that equipment, materials, process parameters, identification, and controls match the documented process.
4. Review corrective actions. Confirm that open and recently closed actions include evidence that the corrective action was effective.
5. Prepare process owners and operators. Make sure the people involved can explain their processes and understand the controls that apply to their work.

The best preparation is to keep process documentation, production data, training, and corrective actions aligned throughout the year rather than preparing only before the audit.

Connect your production data with FlowFuse

Bring data from machines, PLCs, and industrial systems into one place to make process information easier to access and monitor.

Book a Demo

That makes compliance a manual exercise: match measurements to control plan requirements, check inspection coverage, verify limits, and confirm reactions.

The solution is to connect control plan characteristics to production measurements so each reading can be evaluated against the right requirement as it happens. That only works when the measurement data itself is trustworthy, including calibration status.

What a control plan specifies

A control plan is a structured document that defines what needs to be controlled during production, how it should be measured, how often it should be checked, and what to do when a result is out of specification. It is typically developed as part of APQP and maintained within an IATF 16949 quality system.

For each process step, it defines:

• Characteristic: the dimension, torque, weld strength, surface finish, or other property being controlled
• Specification: the required value and acceptable tolerance
• Measurement method: the equipment or method used to check it
• Inspection frequency: how often the check must be performed
• Reaction plan: what happens when a result is outside the specified limits
• Special characteristic: whether the characteristic has additional control requirements

For example, a row might specify: bore diameter at Station 30, 25.00 mm ± 0.05 mm, measured with an in-line air gauge on every part, with CMM verification every 50 parts. An out-of-spec result requires the part to be rejected and the quality engineer notified.

Where the link breaks down

Control plans get created before production starts, then reviewed and updated as the process changes. That part usually works. What doesn't is the equipment on the floor, which carries on with whatever was configured at installation. Gauges, CMMs, torque controllers, vision systems, and PLCs collect measurements without knowing what the control plan requires.

Identifiers don't match

A control plan might call something "Bore Diameter, Station 30," while the CMM stores it as DIM_30_04 and the in-line gauge reports it as channel 4. Without a stable mapping between them, no system can confirm they're referring to the same characteristic. That mapping has to be built device by device, then maintained as equipment is added, replaced, or reconfigured.

Measurements arrive without context

A torque reading of 42.1 Nm only becomes useful for traceability once it's tied to the part, the workstation, a timestamp, the operator, and the device. Capturing that context at the moment of measurement avoids reconstructing it later, a reconstruction that isn't always possible.

Limits drift apart

The control plan might specify 24.95 to 25.05 mm for the Station 30 bore while the in-line gauge enforces 24.94 to 25.06 mm. Both systems work fine; they just enforce different requirements, and a change to one can go unnoticed for a long time. The fix is a single source of truth for limits and validation, with a controlled path for pushing changes to equipment and a record of which limits were active when each part was produced. On validated processes, that path may itself need to go through change control.

Reactions stay manual

The control plan may require a failed part to be rejected, held, and reported, but the measurement device just records the value. Someone still has to catch it and act. Closing this gap means triggering the reaction at the moment of measurement: the part held, the right person notified, the event logged automatically.

Inspection frequency compounds all four. A control plan may require 100% inspection, but a measurement system just collects whatever gets recorded. The presence of data doesn't prove the required frequency was followed. Solving the four gaps above is what makes frequency verifiable in the first place: a mapped, contextualized measurement stream is what lets you confirm every required check actually happened.

A practical example

Consider a fastener torque check with the following requirements:

• Specification: 40 to 45 Nm
• Inspection: 100%
• Reaction: Reject the part and notify the line lead

The torque controller records 38 Nm.

In a disconnected setup, the controller just stores the value locally. A technician has to find the failed reading, trace it to the right part, and confirm the reaction was taken.

With the characteristic mapped to the measurement stream, that same 38 Nm reading is evaluated the instant it's captured. The system already knows the characteristic, the part, the location, the timestamp, and the applicable limit. The part gets held, the line lead is notified, and the event lands in the production record, without anyone hunting for it after the fact.

Where this fits in the data architecture

Measurement data comes from PLCs, gauges, CMMs, torque controllers, vision systems, and other floor equipment. Wherever it originates, it has to be collected, tied to production context, checked against the applicable limits, and routed to whatever handles the next step.

FlowFuse can sit between these systems as the integration layer, pulling data from sources like OPC UA, Modbus, and MQTT, adding production context, checking it against configured limits, and routing anything out of spec to an MES, notification system, or quality database.

The control plan stays in the system the quality team already manages. The measurement workflow uses its requirements to evaluate production data and trigger the right response.

Verifying the control plan was followed

Once control plan characteristics are mapped to production measurements, compliance becomes directly queryable. For any characteristic, you can see:

• Coverage: were all required inspections completed?
• Conformance: were measurements within the limits in effect at the time?
• Response: for out-of-spec results, was the reaction plan followed, and how quickly?

An audit becomes a report, not a multi-day export-and-match exercise. You can answer "show every bore diameter check from Station 30 last quarter and prove every out-of-spec result was caught and contained" from one traceable record. Proving nothing out of spec left the building takes one more link, to part genealogy and dispatch records. That link is only worth building once the measurement side underneath it is trustworthy.

Connect your control plans to production data

See how FlowFuse integrates measurement data from OPC UA, Modbus, and MQTT sources with your control plan requirements to automate quality reactions in real time.

Contact Us

This release ships alongside FlowFuse 3.0; see what else is new in that announcement.

What's new in FlowFuse Dashboard 1.31.0:

• Five built-in themes — Light, Dark, Dracula, Nord, Sepia — all WCAG AA contrast compliant
• Everything you need to build a dark mode dashboard: date pickers, charts, gauges, and icons all render legibly
• Charts draw at their default size; no more empty boxes on auto-height
• Long button labels wrap or truncate instead of clipping mid-word
• Gauges size and draw correctly on auto
• Table date/time columns render in the viewer's own local timezone

Node-RED Dashboard Themes: Build a Better Light & Dark Mode Dashboard with FlowFuse Dashboard

Choose from five built-in Node-RED Dashboard themes in FlowFuse Dashboard: Light, Dark, Dracula, Nord and Sepia. The selected theme applies across every page, group and widget.

Until now you got one white-and-blue default. Changing it meant hand-editing ten theme values, or writing CSS against Vuetify class names to reach anything the theme didn't expose.

If you built a dark mode FlowFuse dashboard before this release, native date and time pickers rendered black on black. Chart text sat at a contrast ratio you couldn't read across a desk. Icons stayed dark while the text around them flipped.

All five themes now meet WCAG AA contrast for text and icons. On the dark themes, date and time pickers, charts, gauges and markdown all render legibly.

Existing FlowFuse dashboards keep the theme they have. Nothing changes unless you pick a preset, and if you already built a dark mode FlowFuse dashboard by hand, it renders better than it did.

FlowFuse Dashboard charts draw at their default size

Add a chart, leave the size at auto, deploy. You get a chart.

Previously you got a title and an empty box. A chart set to auto height collapsed to a single 48-pixel row, and since a chart has no natural height of its own, it drew nothing at all. The workaround was to guess pixel heights until something appeared and that assumed you'd worked out sizing was the problem in the first place. The empty box gave you no clue.

FlowFuse Dashboard buttons wrap long labels instead of clipping them

A button labelled "Acknowledge compressor fault" now wraps onto a second line instead of being sliced at both ends. Long labels wrap across up to two lines, and anything beyond that truncates cleanly with an ellipsis rather than losing characters from the start and finish of the text.

If your FlowFuse dashboard carries equipment names or fault descriptions, this is the fix you'll notice first.

FlowFuse Dashboard gauges size correctly on auto

Gauges no longer leave a band of dead space above them as the screen narrows, and the card edge no longer slices them off.

Three-quarter gauges size correctly on auto, and the needle dial draws at the right proportions. If you run gauges on a wall-mounted screen, they'll look deliberate rather than approximate.

FlowFuse Dashboard tables show real dates, not raw timestamps

Set a ui-table column to date, time or datetime and it renders as a readable date, formatted in the viewer's own locale.

A timestamp column used to show 1735689600000. Getting a date out of it meant adding a function node to reformat every row before it reached the table — which also baked in one timezone. Formatting now happens in the browser, so someone in Stuttgart and someone in Detroit each see their own local time from the same flow.

See the ui-table documentation for the column types.

Smaller fixes in FlowFuse Dashboard 1.31.0

• Editing one theme changes only that theme. Changing a colour used to change it on every theme not assigned to a page.
• Tables fill the height you give them. Set a table to a fixed size and it used to clamp to a single row, hiding everything below the first. Now it fills the widget.
• Text input renders correctly as a multi-line text area. It used to render partially.

Thank you to our contributors

This release includes a fix from waldbaer, who solved widget ordering inside subflows (#710). Put a widget in a subflow where the group already held two others and you couldn't position it between them — it stuck to the top or the bottom whatever you did. waldbaer tracked it down and fixed it.

Thanks as well to everyone filing issues with reproduction steps and screenshots. Several fixes above came from reports that included exactly what we needed to reproduce the problem — #151, #1607 and #1772 among them. That saves us hours, and it goes straight into what ships.

Where FlowFuse Dashboard is going

Our goal is that you can build a real operator screen with FlowFuse Dashboard — the kind mounted next to a production line: glanceable, green when things are running, red when they aren't, readable from across the room. Today, FlowFuse Dashboard builds a good data dashboard. It doesn't yet build an HMI.

Two things stand in the way, and they're what the next two releases are about.

The first is that FlowFuse Dashboard is message-driven. A widget shows whatever the last message told it, and shows nothing until one arrives. That's fine on a laptop while you're building. It's a problem on a screen next to a machine, where an operator walks up mid-shift and needs the state of the line right now.

Tags fix that. Define a named, typed data point once, feed it from wherever your data comes from, and bind widgets to it. FlowFuse Dashboard holds the value server-side, so a page renders real state the moment it opens. Tags also carry what industrial data needs and messages don't: a type, a range, warning and alarm limits.

The second is that you can only arrange widgets in a grid. Every widget is a rectangle that flows into rows and columns. That works for a set of charts and readouts. It can't give you a picture of your process: three tanks with the pipes between them, a motor symbol that spins while it's running, a temperature sitting on top of the vessel it came from.

Canvas is a new page type you draw on. Drop shapes and industrial symbols wherever you want them, bind each one to a tag, and set rules like green in range and red out of range.

We're still working out the shape of both, including where tags should live. If you're running FlowFuse dashboards across machines, sites or lines, tell us what you'd bind, what you'd want stored, and what would have to be true for this to replace how you wire data today.

Tell us on this form.

FlowFuse Dashboard 1.31.0 FAQ

How do I change the color scheme of my FlowFuse Dashboard?

Pick a theme from the dropdown — Light, Dark, Dracula, Nord, or Sepia. Every page, group, and widget updates automatically, and existing FlowFuse dashboards keep their current look until you choose one.

Will switching to FlowFuse Dashboard's dark mode break my existing flows?

No. Your FlowFuse dashboard keeps the theme it already has. Nothing changes unless you actively select a preset from the dropdown.

Does this fix apply to self-hosted FlowFuse Dashboard instances, or only FlowFuse Cloud?

Both. FlowFuse Dashboard is an open source npm package that installs into any Node-RED instance, whether you run it on FlowFuse Cloud or your own hardware.

This feature is available to all users from FlowFuse Dashboard v1.31.0, open source under Apache 2.0.

Start building with your own industrial data

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

Try it out

FlowFuse 3.0 sharpens that promise. We reorganized the way you buy the platform around how you actually work, so the edition you run matches your use case and you get exactly what you need out of the box. We also made updates that move the build experience forward: faster app creation, more usable dashboard interface, and additional certified connectivity.

Introducing FlowFuse Hub, Edge, and Fleet

Which FlowFuse Product Should I Use?

Until now, picking the right FlowFuse setup meant reasoning about tiers. FlowFuse 3.0 replaces that with three clearly-positioned products, each built around a real deployment shape:

FlowFuse Hub: Integrate Enterprise Systems and APIs

FlowFuse Hub is for IT teams. Integrate and orchestrate data across enterprise systems, APIs, and databases, with centralized governance.

Hub fits teams moving data between ERPs, databases, and cloud APIs, where the applications live in a data center rather than on a plant floor.

FlowFuse Edge: Connect PLCs and Machines Across Sites

FlowFuse Edge is for OT teams. Deploy, manage, and scale industrial applications across sites, with certified industrial connectivity and centralized governance.

Edge fits teams connecting PLCs, machines, and systems, and businesses standardizing automation across multiple plants. Certified nodes ship with Edge, so the protocols your flows depend on come tested and supported rather than maintained by volunteers.

FlowFuse Fleet: Manage Node-RED on Distributed Devices

FlowFuse Fleet is for large IoT deployments. Run managed Node-RED across distributed field devices, with remote flow updates and fleet-wide visibility.

Fleet fits telemetry collection, distributed device deployments, and hardware and OEM partners shipping FlowFuse to their own customers. Where Edge gives you depth at each site, Fleet gives you reach across thousands of them.

It's the same strong platform underneath. The difference is which problem each one is tuned for — data center, manufacturing site, or a distributed fleet — so the path from "sign up" to "in production" is shorter for every team, making everything easier from POCs to prod and scaling.

Every product is enabled by FlowFuse Expert, and every product connects the AI agent you already use.

Build: faster from idea to working application

FlowFuse 3.0 makes it easier to go from an idea to a working application, with new AI capabilities and a more intuitive dashboard experience. Describe what you want to build, and FlowFuse Expert helps assemble it.

Connect Your Own AI Agent

Expert works through a set of tools on the FlowFuse MCP server. In 3.0, it stops being the only agent that can use them.

Add the FlowFuse MCP server to whichever AI agent you already use, sign in, and choose which teams it can reach and whether it has editing rights. Microsoft Copilot, ChatGPT, Claude and Gemini all connect this way, as does a local agent with MCP capabilities running any model. Command-line agents use the same address as well and all have access to the same tools as our integrated agent.

This way the AI your company already approved can be extended with FlowFuse and Node-RED, under the same governance you already have in place. The agent you are familiar with, now extended.

Tell it what you want to build and it will build it for you with what the platform offers including applications, hosted and remote instances, snapshots, mqtt brokers, tables, device groups, or the materials in your team library like custom nodes from submodules or blueprints. It will navigate your browser session to the Node-RED editor so it can build it out in front of you, read the debug output, and correct its own node configuration when needed. You stay in control, you can watch it happen and take over at any point.

Three things follow from that:

• Company-sanctioned AI, unlocked. Govern and secure agentic development and orchestration at scale.
• Your agent, your setup. Each engineer stays in the agent they already work in, next to their existing MCP servers and customizations.
• One workflow. FlowFuse platform operations and Node-RED flow editing become a natural extension of the AI workflow you already own leading you to more efficiently and effectively deliver results.

FlowFuse ensures control and enforces on every call what you granted: the teams, and read access or editing rights. Visual coding work runs in one of your own browser sessions making sure you have visibility and which ends when you close the tab. Every action lands in the audit log attributed to you and marked via MCP.

Pick your agent on the AI page to get setup in three simple steps.

Connect the agent you already use, grant it a team and an access level, and work with FlowFuse from there.

What's new with FlowFuse Dashboard?

FlowFuse's Dashboard v1.31.0 delivers a round of UX and UI improvements — the low-friction fixes that make building and reading a dashboard feel obvious instead of fiddly. Built-in themes for Node-RED Dashboard 2.0 lead the release: predictable to edit, and every preset meets WCAG AA contrast, so dark mode stays legible. Charts render instead of leaving empty boxes. Tables show readable dates instead of raw epoch numbers. Plus a run of smaller UI fixes — labels and gauges that stay inside their cards, spacing that holds at narrow widths. Less setup. More dashboard.

Five built-in themes, one dropdown, all meet WCAG AA contrast.

Set the column type to Date, Time, or Datetime. Epoch values format themselves.

Deploy: to the edge, at any scale

The Hub / Edge / Fleet split is, at its core, a deployment story. Whether your applications live in a data center, run per manufacturing site, or spread across thousands of small instances in the field, 3.0 gives you a product shaped for that reality rather than a one-size-fits-all tier. Deploying to the edge and scaling out stop being exceptions you work around and start being the default the product expects.

Running at the edge starts with our Device Agent; it provides the bridge back to the FlowFuse platform. We’re continuing to improve the entire experience of getting setup with the Device Agent - making it as easy as possible to install while retaining flexibility in how you want it set up. This release of the installer guides you through more options on where the agent gets installed and how it gets run - making it easier than ever to get running on your hardware.

Govern: centralized control wherever flows run

As soon as applications spread across sites and devices, the hard part shifts from building them to keeping them under control. Every 3.0 product carries centralized governance through the same lens — role-based access control, audit logging, and a single place to see and manage what's running — so extending to the edge doesn't mean giving up oversight. One team, one set of controls, whether you're running one instance or a fleet.

How Do I Get Started With FlowFuse 3.0?

Explore the product page to decide if FlowFuse Edge, FlowFuse Hub, or FlowFuse Fleet is for you. FlowFuse 3.0 is live today on Cloud and Self-Hosted.

1. Start a Free Trial of FlowFuse Edge: All OT teams can request a free 30-day trial immediately; if you're looking to try out FlowFuse Hub or FlowFuse Fleet, just contact us and we'll make it happen.
2. See the full feature set and request Pricing
3. Set up a demo to see all of these new features

Note: FlowFuse Self-Hosted requires the 3.0 release installed for the new license types and features mentioned in this release.

Find out which FlowFuse product fits how you run

Walk through Hub, Edge, and Fleet with our team and leave with the right fit for your deployment, not a generic tier.

Book a Demo

Controlled shipping is what happens when the automaker stops taking that on trust. It is a formal status assigned after a defect reaches a customer plant, and it comes in two levels. CS1 requires the supplier to add its own inspection layer before shipment, document it, and report on it. CS2 adds an independent third party on top of CS1. The supplier keeps running its own containment; the third party verifies it, at the supplier's cost.

Both are survivable. What makes them hard is not the inspection itself. It is proving, shipment after shipment and site after site, that the inspection actually happened the way you said it did. Most MES platforms handle single-site nonconformance well. Producing one consistent containment record across several plants on a two-week timeline is where they tend to fall short.

What Triggers CS1 and CS2 Controlled Shipping

A defect reaching the customer plant is the starting point, but controlled shipping is an escalation beyond it. Automakers apply it when the defect is severe, when a previously closed issue resurfaces, when a line stops, or when the initial corrective action response falls short. A defect caught at incoming inspection, a field failure, or a warranty claim can each lead there. CS1 typically requires the supplier to add an extra layer of inspection before shipment, while CS2 means the automaker brings in a third party to inspect on the supplier's behalf, at the supplier's cost. Both carry real financial and reputational stakes.

For automotive quality manufacturing, the trigger event is rarely the hard part. The harder part is proving, with data, that every unit shipped afterward meets the added inspection requirement. Without a system connecting inspection points to production data in real time, that proof often depends on manual logs that are slow to compile and easy to dispute during a customer audit.

Building Containment That Holds Up Under Scrutiny

Surviving CS1 or CS2 status depends on more than reacting to the initial defect notice. Automakers and third-party auditors expect proof that every containment action is documented, repeatable, and traceable back to a specific inspection point and operator sign-off. Building that level of rigor across multiple sites, each with its own systems and habits, requires structure in three key areas.

Documenting Every Inspection Point

Every added inspection step needs a written record: what is being checked, how often, and by whom. Inspection also has to happen in a dedicated containment area, separate from normal production flow, staffed by people other than the operators who produced the part. Real-time production monitoring can capture this automatically at the line level, giving you a live record instead of a stack of paper checklists compiled after each shift. It's the same discipline a layered process audit runs on: defined checks, at a defined frequency, signed off by someone other than the operator.

Sign-Offs That Hold Up During Customer Containment

Customer containment often involves the automaker's own quality team reviewing supplier data directly. A shared FlowFuse Dashboard gives operators, quality engineers, and customer auditors the same live view of inspection results, so sign-offs reflect what actually happened on the line, not a summary written after the fact.

Where CS1/CS2 Automotive Plans Break Down

Most CS1/CS2 automotive plans fail at scale, not on day one. A process that works on a single line becomes inconsistent across five plants using different spreadsheets and different definitions of "checked." Standardizing the same containment action across every site closes that gap without rebuilding it at each location.

Identifying Certified Stock

Contained parts need distinct marking, usually a containment label or coloured tag, agreed with the customer and applied from a defined start date. That marking is how the customer separates parts that passed containment inspection from parts shipped before containment began. Containment also covers material sitting in your warehouse, already in transit, and on the floor at the customer's plant, not only what ships next. That marking needs to tie back to the same automotive traceability record as everything else you ship, not a separate log that only exists for the duration of containment.

From Customer Containment to Exiting CS1 and CS2 for Good

Passing containment inspections is only half the work. To exit CS1 or CS2 status permanently, a supplier has to show the automaker that the root cause has been identified and corrected, not just contained. That shift from reactive inspection to lasting correction happens across three areas.

Connecting Containment Data to Root Cause

Containment inspection data is only useful if it points back to where the defect originated. Ongoing defect and quality monitoring at the line level helps quality teams trace a recurring issue to a specific machine, shift, or process step. Structuring that investigation with a tool like an Ishikawa fishbone diagram keeps the search organized instead of guessing at a fix.

Keeping Every Shift Aligned on Corrective Action

Corrective action fails when one shift changes a process and the next shift reverts it. Clear shop floor communication keeps operators, quality engineers, and plant leadership working from the same updated procedure, reducing the risk of the same defect resurfacing after containment is lifted.

Proving Consistency Before Requesting Release

Automakers typically require a sustained defect-free run before lifting controlled shipping status. Every containment action taken during that run needs a documented, consistent trail across shifts and lines, giving the supplier a clear case to present when requesting release from CS1 or CS2.

Final Thoughts

CS1 and CS2 status test more than a supplier's quality process. They test whether that process can be documented, trusted, and applied the same way across every site under scrutiny, often on a timeline that leaves no room for rebuilding tools from scratch at each plant. The suppliers who exit controlled shipping fastest are usually the ones who can prove consistency without relying on manual logs and disconnected spreadsheets to make their case.

An industrial application platform like FlowFuse gives manufacturers a way to standardize that proof once and apply it everywhere it is needed, from inspection tracking to shift communication to root cause data. Getting through CS1 or CS2 is difficult enough without also rebuilding the containment process at every site. Build it once, and let it run everywhere containment is required.

Build containment you can prove

Talk to us about connecting inspection data, sign-offs, and root cause tracking so your containment action holds up across every site.

Book a Demo

What is a Safe Launch Automotive Program, and Why Does it Start After PPAP?

A safe launch program is a defined containment period that runs from the first production shipment. It usually follows PPAP approval, though a supplier operating under interim approval is often required to contain from day one. PPAP proves capability over a significant production run, typically 300 consecutive parts at production rate on production tooling. Safe launch proves the process holds that capability over months, across every shift, every operator, and a full tooling wear cycle. For manufacturers running automotive manufacturing solutions across multiple plants, that distinction matters because failure modes at launch rarely match what showed up in validation.

This is why safe launch exists as its own phase. A redundant inspection layer, tighter reaction limits, and faster escalation paths catch issues that a one-time approval cannot. In most programs this means 100% inspection of specified characteristics, carried out separately from the normal in-process checks, not a higher sampling rate. Without them, defects can reach hundreds of vehicles before anyone notices a trend, turning a manageable process shift into a costly field action.

Building a Safe Launch Plan for the Post-PPAP Monitoring Period

A safe launch plan gives structure to what would otherwise be a loosely managed monitoring period. It defines how long the elevated scrutiny lasts, what triggers an escalation, and who owns the response when a defect trend appears. Four elements determine whether that plan actually works on the shop floor.

Containment Inspection That Sits On Top of Normal Controls

Containment inspection is additional, not a substitute. It runs at a dedicated station downstream of the normal process, covering the characteristics the customer specified, usually at 100%. Operators need to see which characteristics are under containment and what the current results look like, on the line, in the shift they are working. Real-time production monitoring turns that into a live view instead of a paper checklist.

Escalation Criteria Everyone Understands

A safe launch plan fails when escalation depends on someone noticing a problem manually. Defined thresholds, tied to real-time production monitoring data, remove that guesswork and route alerts to the right person before a trend becomes a containment event.

Exit Criteria Set by the Customer, Proven by You

The customer defines the exit criteria at the start, usually a combination of elapsed time, cumulative volume, and zero containment defects. You cannot exit unilaterally. You build the evidence, request release, and wait for sign-off. A defect found during the window normally resets the clock rather than simply extending it, which makes a clean, continuous record worth more than a strong average.

Identification of Contained Parts

Parts that clear containment inspection carry a customer-agreed label or mark, applied from a defined start date, so the receiving plant can tell contained stock from anything shipped before the program began. Missing or inconsistent identification is one of the most common reasons a containment period gets extended.

Early Production Containment: Turning Launch Data Into Long-Term Quality Gains

Early production containment generates a large volume of data in a short window, but most of that data gets archived once launch monitoring ends. This is a missed opportunity. The same data used to catch defects during launch can improve quality processes well beyond it: three approaches make that connection possible.

Feed Containment Data Into Standard Quality Workflows

Containment findings should not disappear once a program exits its monitoring period. Applying the same defect and quality monitoring logic used during launch to standard production keeps defect detection sharp long after containment ends.

Use Launch Insights to Improve Future Programs

Every launch surfaces failure modes specific to a part, process, or line. Capturing those patterns in a reusable operational application means the next launch starts with better containment plans and escalation thresholds instead of starting from scratch.

Standardize Containment Logic Across Plants

A containment workflow built for one line can run at every site without rebuilding it, following FlowFuse's build once, run everywhere approach to automotive manufacturing, so standardized workflows scale across brownfield environments instead of starting over at each plant.

Final Thoughts

A safe launch program only works when it treats the post-PPAP period as its own discipline, not an extension of validation. That means containment inspection layered on top of normal controls, escalation paths that do not depend on manual observation, and exit criteria the customer sets and you prove. Getting this right protects against the kind of defect trends that turn into costly field actions.

The bigger opportunity is what happens to that containment data afterward. Instead of archiving it once monitoring ends, manufacturers can carry those insights into standard quality workflows and future launches. An industrial application platform like FlowFuse makes that possible by letting quality teams build a containment workflow once and run it everywhere it's needed, so every new launch starts ahead of the last one instead of rebuilding the process from scratch.

Get your next launch off to a clean start

Talk to us about connecting inspection points, escalation criteria, and containment reporting so you can prove your safe launch program held up and exit with confidence.

Book a Demo

The distinction matters because process validation alone doesn't prove it. A supplier can pass validation with every checked part coming back within spec, launch, and still miss its shift target three weeks in, at which point it's a customer problem instead of an engineering one. Run at rate is the check meant to catch that before launch happens, not after.

Where the requirement comes from

General Motors formalized the requirement in its GM Global APQP Supplier Quality Manual (GM 1927), performed after PPAP approval as confirmation of the rate claimed on the supplier's warrant. Ford builds it into the PPAP submission itself, through the capacity evaluation section of the official AIAG Production Part Approval Process (PPAP) Manual. Stellantis standardizes its version via the Stellantis Supplier Portal Capacity Assessment Tool (CAT) framework. German OEMs execute a two-day trial called 2 Tagesproduktion (2TP), governed by the VDA QMC Volume 2 PPA Standard.

The paperwork varies by customer. The question underneath it doesn't: can this line, with this tooling and these operators, actually produce at the rate that was quoted.

Requirements for a valid run

A few conditions have to hold.

The setup has to match real production, not a demo. Production tooling, production gauges, trained operators, standard work as documented. Auditors specifically watch for stand-ins, an engineer hovering over a fixture, hand-picked material, extra staff who wouldn't be on the floor during a normal shift. Any of that and the result doesn't count.

The run has to cover enough time to mean something. A line can hold takt time for twenty minutes and still drift once fixtures heat up and operators settle into a real pace instead of a rehearsed one. That's why most programs require a full shift or a defined multi-hour window rather than a short burst at rate.

And everything counts against the result, not just the good parts. Downtime, changeovers, scrap, and rework all subtract from the demonstrated rate.

How to calculate run at rate

The math only needs two numbers: what the line was supposed to produce, and what it actually produced as good parts.

Theoretical output = run duration ÷ target cycle time

Run at rate % = (net good output ÷ theoretical output) × 100

Take an 8-hour shift, or 480 minutes, against a 60-second target cycle time. The theoretical output for that window is 480 units.

During the run, 45 minutes are lost to downtime, leaving 435 minutes of actual production time. At the target cycle time, the line produces 435 units, but 12 are scrapped, leaving 423 good parts.

Run at rate = (423 ÷ 480) × 100 = 88.1%

Downtime and scrap don't get calculated separately and added back in. They show up as fewer good parts against the theoretical output, which is why a line can be running most of the shift and still post a rate well under target..

What Does Pass or Fail Look Like?

The customer or program team sets the required run-at-rate threshold before the test, based on the production capacity that was quoted or required. The threshold varies by customer and program, so 95% is an example rather than a universal requirement.

If the agreed threshold is 95%, a result of 95% or higher passes. In the example above, the line achieved 88.1%, so it fails to demonstrate the required capacity. That restarts the clock rather than ending the program: trace the shortfall to downtime, scrap, or cycle drift, fix it, and run again. Until a run passes, the quoted capacity stays unproven, and launch approval waits with it.

Pass: ≥ required threshold
Fail: < required threshold

Run at rate vs. process validation vs. PPAP

Process validation confirms a process can hold tolerance, usually at reduced volume with an engineer watching each unit come off the line. That's a different test than holding tolerance for 400 consecutive cycles at full speed with nobody intervening, which is what runs at rate checks.

PPAP is the larger documentation package: control plans, measurement system analysis, part approval as a whole. Run at rate is one piece of that package, specific to volume. It isn't a substitute for the rest of the file, and the rest of the file isn't a substitute for it. For how a control plan's characteristics get tied to the measurement data collected on the floor, see Control Plans: Linking Quality Characteristics to Measurement Data.

Why capacity gaps still show up after launch

Changeover time gets estimated instead of measured live, and the real changeover, with new operators and no rehearsal, runs longer than planned. A station that tested fine on its own turns out to be the actual bottleneck once the full line runs together, starved for parts or backed up behind a slower neighbor. Quality that looked stable during a short trial drifts once tooling wears across a full shift, a failure mode a short run wouldn't catch. If that drift reaches the customer plant, it's the kind of defect that triggers CS1 or CS2 controlled shipping.

Some of the challenge comes down to how run-at-rate data is collected. During a live run, cycle times, downtime, production counts, and rejects are often recorded manually, making it difficult to capture every event accurately. Much of this data is already available from the equipment through PLC tags and machine states. A platform like FlowFuse can connect to that equipment to automatically collect the data, calculate the demonstrated production rate, and visualize the results as the run progresses, giving teams a clearer view of how the line is performing against its target.

Why it matters

Process validation proves a line can make a good part. Run at rate proves it can make good parts fast enough, for long enough, to hit the number in the launch plan. With production data collected directly from your equipment, FlowFuse helps automotive manufacturers monitor production counts, cycle time, downtime, and quality in real time, making capacity gaps visible before they become launch problems.

See What Your Production Line Is Capable Of

Connect your production equipment with FlowFuse to collect production data, calculate demonstrated rates, and monitor performance against target capacity.

Try it out

FlowFuse, an industrial application platform, works directly inside the environments where SCADA systems operate, connecting to PLCs, sensors, and edge devices as part of building operational applications across plants and production lines. The platform is SOC 2 Type 1 and Type 2 certified and is trusted by manufacturers including Bosch, Cargill, Moderna, and 25 or more other enterprise customers to standardize workflows across hundreds of sites without rebuilding from scratch.

This article breaks down what SCADA is, how it works, how it compares to related systems like PLCs and HMIs, and why it still matters in brownfield environments today.

How Does SCADA Work? The Core Components

SCADA, which stands for Supervisory Control and Data Acquisition, is a system that collects data from equipment across a plant and gives operators a centralized view to monitor and control that equipment in real time. A simple definition covers what the system does, while the SCADA meaning points to its core function beyond just the acronym, supervising and gathering data across distributed equipment. Any basic SCADA system definition includes four layers working together: field devices, controllers, communication networks, and the software that displays and stores the data. Each of these layers works together as follows:

The four layers of a SCADA system: field devices, controllers, communication networks, and the software operators use to monitor and control equipment.

Field Devices And Sensors

Sensors and field devices sit closest to the physical process, measuring variables like temperature, pressure, flow rate, and machine status. These devices generate the raw data that everything else in the system depends on. Without accurate field-level data, supervisory dashboards and historical trends built on top of a SCADA system lose their value almost immediately.

PLCs And RTUs

Programmable Logic Controllers and Remote Terminal Units take the raw signals from field devices and convert them into structured data. PLCs typically run more complex local control logic and keep equipment operating safely between supervisory updates, while RTUs are more common in geographically spread-out environments, like pipelines or remote wellheads, where they focus more on data acquisition and communication over long distances. Most industrial environments rely on PLCs as the layer directly beneath SCADA, translating physical inputs into a format the rest of the system can use.

Communication Networks

Communication networks carry data between field devices, controllers, and the central SCADA software, using protocols like Modbus, OPC UA, MQTT, or Ethernet/IP depending on the equipment and environment. This layer determines how reliably and securely data moves across a facility, and it becomes especially important when connecting older equipment to newer IT/OT platforms.

HMI And Central Monitoring Software

The Human-Machine Interface, or HMI, is where operators view live data, alarms, and trends pulled from PLCs and RTUs. Central SCADA software aggregates this information across multiple lines or sites, storing historical data for reporting and analysis. This layer is what turns raw signals into the visibility manufacturers depend on to catch problems early.

SCADA vs. PLC, HMI, And MES: Where It Fits In The Stack

Anyone asking what is SCADA usually runs into overlapping terminology almost immediately, since PLCs, HMIs, and MES platforms all touch the same data at different points. Each system serves a distinct purpose, and confusing them leads to gaps in coverage or duplicated effort across sites. Getting the distinctions right matters for anyone responsible for architecture decisions across multiple plants:

SCADA vs. PLC

A PLC executes control logic directly on the equipment it is connected to, reacting to inputs in real time without needing a central system. SCADA, by contrast, supervises multiple PLCs at once, pulling their data into a single view for monitoring and historical analysis, and sending supervisory commands like setpoint changes back down to the equipment. For a full breakdown of how PLCs function on their own, see What Is PLC.

SCADA vs. HMI

An HMI is the interface operators interact with directly, usually tied to a single machine or line. SCADA software aggregates data from many HMIs and PLCs across a facility or multiple sites, giving a broader operational picture than any single interface can provide. Guidance on setting up interfaces at the equipment level is covered in Building HMI for Equipment Control.

SCADA vs. MES

MES platforms manage production scheduling, quality records, and traceability at a business process level, while SCADA focuses on real-time equipment data and control. These systems are meant to work together, not replace each other, though many manufacturers still rely on tools like Kepware to bridge the gap between SCADA data and MES or ERP systems. This is a core part of what SCADA is often used for in practice.

Why SCADA Still Matters In Modern Brownfield Environments

SCADA systems are not going anywhere in most industrial facilities, and understanding why requires looking at how much infrastructure is built around them. Many plants run SCADA installations that are ten or twenty years old, tied directly to equipment that still works fine and would be expensive or risky to replace. Ripping out a functioning brownfield environment rarely makes sense when the goal is better visibility, not a full overhaul.

The real challenge is connecting older SCADA systems to newer IT and OT tools without breaking what already works. Protocol choice plays a large role here, and manufacturers evaluating how to move data between legacy equipment and modern platforms often need SCADA explained in the context of specific protocols like OPC UA and MQTT. The comparison in OPCUA vs MQTT covers how each protocol handles that kind of connectivity differently.

Extending a brownfield SCADA system with an IT/OT layer rather than replacing it.

Extending a brownfield SCADA system, rather than replacing it, lets manufacturers keep proven equipment logic in place while adding the IT/OT connectivity needed for enterprise-wide visibility. That approach protects existing investment and reduces the operational risk that comes with large-scale system replacement.

Final Thoughts

SCADA remains one of the most important systems on any plant floor, giving operators and engineers the visibility needed to catch issues before they turn into costly downtime. Knowing how the pieces fit together, from field devices up through PLCs, HMIs, and central monitoring software, makes it easier to spot where gaps exist and where legacy equipment can be extended rather than replaced.

For manufacturers managing SCADA across multiple sites, the harder problem is often not the system itself but everything built around it: custom scripts, one-off integrations, and workflows that get rebuilt at every new plant. An industrial application platform like FlowFuse addresses that layer directly, letting teams take a proven operational workflow and deploy it across every site instead of starting over each time. Build once, run everywhere is not just a convenience. It is what breaks the rebuild cycle for good.

Reading about SCADA only gets you so far

Connect to a PLC over OPC UA or Modbus, watch live tags arrive, and build a view on top of them.

Try it out

Automotive traceability makes that history possible to reconstruct.

What Is Automotive Traceability?

Automotive traceability is the ability to follow a vehicle, component, or individual part through manufacturing and connect it with the data that production generates along the way. At vehicle level the anchor identifier is the VIN. At component level it is a serial number that serialization applies at the start of the process, and the finished result is often called the as-built record: everything known about how that specific unit came together.

Take a manufacturer producing brake assemblies. Each assembly receives a unique identifier, and as it moves through production the manufacturer ties that identifier to the supplier who provided the components, the line that assembled the part, the machine that performed each operation, the torque values the tool recorded, the inspection results, the operator, the timestamp of each operation, the batch number, and whether the part passed its quality check.

Now suppose a quality issue surfaces several days later. Instead of searching through disconnected machine logs, spreadsheets, and production records, the manufacturer looks up the affected part and reads its production history. That is the real value of traceability: it turns production data into a history someone can follow.

Why Traceability Matters in Automotive Manufacturing

Traceability matters more in automotive manufacturing than in most industries because a problem with one component can affect a large number of vehicles, and because the supply chain runs deep. An OEM depends on Tier 1 suppliers who depend on Tier 2 suppliers, and a defect can enter at any level. It is also expected rather than optional, since IATF 16949 requires manufacturers to define traceability so they can identify and contain suspect product.

The scale explains the pressure. NHTSA processes over 1,000 new recalls each year, and completion rates for most component categories land between 60% and 75%. A recall that covers more vehicles than it needs to therefore costs more and still leaves defective units on the road. Narrowing the scope is not only cheaper, it is more effective.

Consider a supplier discovering that a batch of components does not meet specification. The manufacturer needs to determine which parts from that batch entered production and which vehicles contain them. That is forward traceability: start with a suspect input and find everywhere it went. Backward traceability works the other way, starting from a returned vehicle and reconstructing what went into it. Without reliable records, either direction turns into a manual investigation across production logs, databases, and spreadsheets. With them, the manufacturer queries the relevant identifiers and gets the affected scope directly.

The same connected history speeds up root-cause analysis. When a component fails final test, a quality engineer starts at its identifier and works backward. Which material batch went into it? Which machine and station handled it? What were the process parameters, and did other parts from the same window show similar results? That makes traceability an engineering tool rather than a compliance checkbox.

It also works proactively. If failures start increasing on one assembly line, engineers compare failed parts against machine parameters, tooling changes, and operating conditions. When a process parameter drifts outside its normal range, teams catch the trend before it produces a large batch of defective parts.

Where Traceability Starts: Incoming Material

Most traceability projects begin at the first production station, which is one station too late. The chain has to start at receiving, because that is where the plant takes custody of material whose history it did not record.

When a shipment arrives, the plant captures the supplier, the supplier's lot or batch number, the material certificate where one applies, the quantity, and the date. That record becomes the top of the genealogy chain, and every part built from that material inherits the link. Skip it, and forward traceability stops at the plant boundary: you can prove which vehicles used lot B-184, but not who supplied B-184 or what else arrived alongside it.

This is the line between internal and external traceability. Internal covers everything inside the plant, from receiving through production and shipping. External extends the chain across organizational boundaries, so a Tier 1 supplier can answer questions about material that came from a Tier 2 supplier. Recall investigations almost always need both, which is why label and identification standards matter: a code applied at a Tier 2 plant has to stay readable at the Tier 1 plant and again at the OEM.

Incoming material also brings the batch-versus-unit question forward. A supplier may ship serialized components, or a lot of bulk material with one identifier covering thousands of pieces. Whatever granularity arrives at the dock sets the floor for how precisely the plant can trace anything built from it.

What Data Needs to Be Tracked?

A traceability system is only as useful as the data connected to each part. Requirements vary, but a few categories show up almost everywhere.

Part identity is the starting point: a serial number, Data Matrix code, or RFID tag that links a physical component to its digital record. Automotive commonly uses direct part marking, where a laser or dot-peen head cuts the code into the component itself so it survives washing, painting, and handling. Production information describes where and when the plant processed the part, covering line, workstation, machine, operator, and timestamp. Process data adds detail about the operation itself, which might mean torque, pressure, temperature, or cycle time. Quality data records whether the part passed its inspections and tests. Material and batch information connects the finished component back to its source, which matters most when a supplier batch later turns out to have a problem.

Not every part warrants a serial number. Safety-critical and high-value components such as airbags, brake assemblies, and battery packs usually get unit-level identity, while fasteners, adhesives, and bulk materials stay at batch or lot level. Choosing the wrong granularity costs money in both directions: serializing everything adds marking and scanning time at every station, while batch-tracking a safety-critical part widens the containment scope when something goes wrong.

None of these datasets should sit in isolation. The goal is to establish relationships between them, so a vehicle connects to an assembly, which connects to a component, a production step, a machine, its process data, and the resulting quality result.

Why Connecting the Factory Is the Hard Part

The information traceability requires comes from systems that nobody designed to work together. A PLC holds machine states and process values. A scanner identifies the part. A vision system produces an inspection result. An MES manages production information while a database holds historical records. Each works fine on its own.

A tightening controller may report that an operation finished at 10:42:13 with a torque value of 42 Nm. A scanner may have identified the part as BRK-10482 moments earlier. The traceability system has to establish that those two events belong together, which means treating machine connectivity, timestamps, identifiers, and storage as one workflow rather than five separate projects.

The problem compounds because one line often includes equipment from several vendors, each exposing information differently. One machine speaks OPC UA, another communicates over EtherNet/IP, and other equipment publishes through MQTT or exposes a vendor interface of its own.

None of this requires replacing the existing MES, SCADA, PLCs, or vendor systems. FlowFuse acts as a low-code IT/OT integration layer between them, connecting machines, protocols, databases, and MES platforms without a rip-and-replace project. Rather than pushing every piece of machine data into a central system, workflows process and route information when relevant production events occur.

Associating Production Data With Individual Parts

Collecting machine data is only half the problem. The system also needs to know which part that data belongs to, and a unique identifier provides the answer.

Take a simple assembly station. A scanner reads PART-84721, and the station opens an active context for that part. The identifier also selects the tightening program, so the tool runs the limits that belong to this specific assembly and stays locked until a valid scan arrives. When the operation finishes, the stored record shows part PART-84721 at station Assembly-04, tightened under program 7, with a torque of 42.1 Nm, an angle of 87.4°, an OK result, and a timestamp of 10:42:13.

A scan opens the context; the tightening result lands against the part that was scanned.

Notice that the values arrive from two different systems. The identifier lives in the station controller, the torque and the verdict live in the tightening controller, and neither one means much without the other. That record is far more useful than an isolated 42.1 Nm reading, because the identifier supplies the context. A FlowFuse workflow handles the logic directly: take the identifier, collect the values from the relevant equipment, transform them into the required structure, and route the record to its destination.

The same identity check also enables error-proofing. If a part reaches station 5 without a passing record from station 4, the workflow blocks the operation instead of adding another entry to a history nobody reads until a recall. Traceability that only records is a reporting system. Traceability that interlocks stations stops defects from moving down the line.

Building Part Genealogy

Once manufacturers connect production records, they can build part genealogy, which describes the relationships between a finished product and everything that contributed to it.

Vehicle A contains battery pack 1042, which contains module M-07, built from cell lot B-184 supplied by cell supplier X. Line 3 and station 7 are not links in that chain. They belong to the point where one item was consumed into another, recorded alongside the timestamp, operator, and result.

Genealogy links a finished vehicle to the components and suppliers behind it, and reads in both directions.

The chain reads both ways. Trace back from a returned vehicle to find every component behind it, or forward from a defective cell lot to find which modules used it, which packs took those modules, and which vehicles received those packs. The same principle applies down to individual fastening operations, welds, and inspection points.

Notice also where the identifiers change type. The vehicle carries a VIN and the pack and module carry serial numbers, so each one is traceable as a single unit. The cells carry a lot number, so they are traceable as a batch. Where serialization stops is where containment scope widens.

Structuring and Storing Traceability Data

Genealogy only works if the underlying data has structure. A traceability database typically holds parts and serial numbers, production orders, workstations, machines, process steps, materials and batches, measurements, quality results, and timestamps, and the relationships between those records matter as much as the values themselves. A production event that references a part ID, station ID, process ID, and timestamp lets someone reconstruct the history later without duplicating information across systems.

FlowFuse transforms and routes production data into the platform a manufacturer already runs, so teams structure information to fit their existing architecture instead of forcing every production system into one storage technology.

High-volume environments usually separate real-time operational data from long-term historical data. Real-time data supports production monitoring and immediate decisions, while historical data stays available for quality analysis, audits, and investigations. Retention is worth settling early, because customer contracts and regulatory requirements often set it rather than leaving it to the plant.

Scaling Traceability Across Production Lines

A solution that works at one station becomes hard to manage once it spreads across an entire factory. Different lines carry different equipment, protocols, and processes, while manufacturers still want one consistent approach to collecting production information.

Instead of running a separate integration project for every line, manufacturers can establish reusable workflows and deployment patterns. FlowFuse provides centralized management for industrial applications across production environments, which helps teams move past one-off integrations as applications reach multiple lines or plants. Workflows still adapt to the equipment at each site while following common patterns for deployment, management, and governance.

Final Thoughts

Automotive traceability is about more than knowing where a part came from. It makes production observable enough that manufacturers understand what happened, when it happened, and how the events connect.

That takes more than collecting data. Manufacturers need to connect machines and assets, move information between protocols and systems, structure the result, and deliver it to the people and applications that depend on it. An event-driven integration layer like FlowFuse supplies that connective tissue without replacing the systems already running the factory.

The payoff is an architecture that grows with the operation, from one station to a full line and eventually across multiple plants. When every relevant production event connects to the part it belongs to, manufacturers gain a complete, searchable history of how their products were made. The next time a quality issue appears, they are no longer asking what happened. They can start answering it.

Build Traceability On the Systems You Already Run

Connect PLCs, scanners, inspection systems, and databases into production workflows you can deploy across every line with FlowFuse.

Contact Us

A Layered Process Audit (LPA) helps manufacturers catch these problems earlier by regularly checking critical process controls while production is running.

This guide explains what an LPA is, how the layers work, and how manufacturers use them on the shop floor. As LPA programs grow, digitizing audits can make it easier to capture findings, track corrective actions, and connect audit results with production data.

What Is a Layered Process Audit?

A Layered Process Audit (LPA) is a structured, process-focused audit in which personnel at different levels of an organization systematically verify that critical manufacturing processes, controls, and work practices conform to defined requirements and standards.

Instead of inspecting finished parts, an LPA checks the process itself. An auditor observes the operation and verifies selected controls such as machine settings, standard work, tooling, materials, or error-proofing.

The layers are different levels of management. A supervisor may check a process daily, an area manager weekly, and plant leadership monthly.

The layers are not different stages of production. They are different levels of oversight.

LPAs are widely used in automotive manufacturing and other industries where consistent process control is important. They complement formal process and product audits rather than replacing them.

How Do LPA Layers Work?

Each layer checks important process controls at a different frequency.

These frequencies are common starting points, not universal requirements. Manufacturers can adjust them based on process risk.

Layer 1 is closest to the operation and focuses on whether the process is being followed as defined.

Layer 2 provides broader oversight across production areas and can identify recurring findings or problems that were not resolved.

Layer 3 looks across the plant to identify patterns and verify that important issues are being addressed.

The same critical controls can therefore be checked regularly by people with different levels of responsibility.

Layered Process Audit Example

Consider an automotive assembly station where a component must be tightened to a defined torque.

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.

The supervisor corrects the setting and records the finding. During a later Layer 2 audit, the area manager checks the same control and confirms that the tool is still being used within the required range.

If similar findings appear on other stations, plant leadership can identify a wider problem with tool settings or process control.

This illustrates the purpose of an LPA: find process deviations close to where they happen and use different management layers to keep critical controls in place.

How to Run a Layered Process Audit

An LPA can be straightforward when it focuses on the controls that matter most.

Identify the Process

Start with a process where regular verification is valuable, such as one with recurring defects, high scrap or rework, customer complaints, or critical process parameters. A Pareto chart can help identify where problems are concentrated.

Define What to Verify

Use information from the PFMEA, control plan, work instructions, and previous quality problems to identify the critical controls. Our LPA checklist template has example questions to help you get started.

Assign the Layers

Decide which management level will perform the audit and how often. Higher-risk processes may need more frequent checks.

Perform the Audit at the Workstation

The auditor observes the actual operation and records whether the defined requirements are being followed.

Correct and Follow Up

Simple problems can be corrected immediately. Other findings should have an owner and due date, with a later audit confirming that the issue has been resolved.

An LPA should be short enough to fit into normal shop-floor activity. If it becomes a lengthy inspection, its scope is probably too broad.

Common LPA Problems

An LPA program can lose its value when the audit becomes a paperwork exercise.

Pencil-whipping is one common problem: an audit is marked complete without the auditor actually checking the process.

Another is repeat findings. If the same problem appears in every audit but nothing changes, the organization is recording the problem without solving it.

Missed management layers can also weaken the program. If higher-level managers stop performing their audits, the additional oversight disappears.

Finally, the audit criteria can become outdated when the process changes. LPA questions should be reviewed periodically to make sure they still focus on current process risks.

LPA vs. Process Audit

An LPA and a process audit both examine manufacturing processes, but they are used differently.

An LPA provides frequent checks of important controls, while a process audit provides a deeper assessment of the overall process.

Digitizing Layered Process Audits

Manufacturers can start an LPA program with paper forms or spreadsheets, but managing audits and findings becomes harder as the program grows.

A digital LPA can help schedule audits, record findings, notify responsible people, and track actions through closure.

Connecting the audit with production data provides another benefit. With FlowFuse, manufacturers can connect an LPA application to machines, PLCs, sensors, databases, and other industrial systems.

This allows audit results to be viewed alongside production information such as downtime, machine states, or process parameters. Instead of only recording that a process failed, teams can investigate what was happening around the failure.

With FlowFuse Dashboard, manufacturers can build applications to record audit results, track findings, and visualize them alongside operational data.

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.

The same live data is useful during a run at rate, when a team needs to verify that the line can sustain its required output before launch.

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