Blog: Control Plans: Linking Quality Characteristics to Measurement Data

src/blog/2026/08/control-plans.md

@@ -0,0 +1,111 @@
+---
+title: "Control Plans: Linking Quality Characteristics to Measurement Data"
+subtitle: "Closing the gap between documented control plan requirements and real-time production measurements"
+description: "Control plans define what to measure, how often, and how to react, but shop-floor equipment rarely knows it. Here's how to connect control plan characteristics to live measurement data."
+date: 2026-08-28
+authors: ["sumit-shinde"]
+image: /blog/2026/08/images/control-plans.png
+tags:
+   - posts
+   - flowfuse
+meta:
+  faq:
+    - question: "What's the difference between an automotive control plan and inspection data?"
+      answer: "A control plan, developed under APQP and maintained within an IATF 16949 quality system, is the requirement: what to measure, how often, and what to do if it fails. Inspection data is the result, the actual readings a gauge, CMM, or torque controller records on the line. The two live in separate systems by default, which is why matching a reading back to its control plan requirement is usually a manual step rather than an automatic one."
+    - question: "Why doesn't shop-floor equipment automatically know IATF 16949 control plan limits?"
+      answer: "Gauges, CMMs, torque controllers, and PLCs are configured at installation with whatever limits or point IDs someone entered at the time. They have no ongoing connection to the control plan document itself, so when the control plan changes during a PPAP revision or process update, the equipment doesn't change with it unless someone updates it manually."
+    - question: "How do you verify 100% inspection compliance for an IATF 16949 audit?"
+      answer: "Data alone doesn't prove it. A measurement system just stores whatever gets recorded, whether that's every part or one in ten. Verifying full coverage requires mapping each control plan characteristic to its measurement stream first, so you can confirm every required check on the line is represented, not just count the readings that happened to arrive."
+    - question: "What happens when a part fails an in-process torque or dimensional check?"
+      answer: "The control plan's reaction plan defines the required response, typically holding the part, notifying the line lead or quality engineer, and logging the event. Without a direct link between the measurement and the control plan, a person has to catch the failure and carry out that response manually. With the link in place, the system can trigger the hold, notification, and log entry the moment the out-of-spec reading is captured."
+    - question: "Can you prove control plan compliance for a customer or IATF audit?"
+      answer: "Yes, once characteristics are mapped to measurements, coverage, conformance, and response all become queryable. Instead of exporting and cross-referencing data by hand, an auditor's question like \"show every bore diameter check from Station 30 last quarter and confirm every out-of-spec result was caught and contained\" can be answered from one traceable record."
+cta:
+  type: contact
+  title: "Connect your control plans to production data"
+  description: "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."
+tldr: "Control plans specify what to measure, how often, and how to react, but this logic is rarely connected to the equipment collecting data on the floor, creating gaps in identifiers, limits, inspection frequency, and reaction plans. Closing the gap requires mapping characteristics to measurement points, capturing production context with each reading, maintaining a single source of truth for limits, and triggering reactions automatically when measurements fall out of spec."
+---
+
+A control plan requires a bore diameter check on every part, within a defined tolerance, with a reaction if it falls outside. The gauge records the measurement under its own point ID; the CMM uses another. Neither is directly linked to the control plan.
+
+<!--more-->
+
+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](/blog/2026/07/calibration-management-dashboard/).
+
+::cta-image{src="/blog/2026/08/images/control-plan-cta-1.png" alt="Know which gauges are due for calibration - sign up for FlowFuse" cta="sign-up"}
+::
+
+## 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](https://www.aiag.org/training-and-resources/manuals/details/APQP-3) and maintained within an [IATF 16949](https://www.iatfglobaloversight.org/iatf-169492016/) 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](/blog/2025/12/what-is-plc/) 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](/blog/2026/08/automotive-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](/blog/2025/11/industrial-data-validation-guide/), 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.
+
+::cta-image{src="/blog/2026/08/images/control-plan-cta-2.png" alt="Not sure where your measurement data gaps are? Book a demo" cta="demo"}
+::
+
+## 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](/blog/2025/06/structuring-storing-data-mes-integration/), 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](/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/), [Modbus](/blog/2025/09/using-modbus-with-flowfuse/), and [MQTT](/blog/2024/06/how-to-use-mqtt-in-node-red/), adding production context, checking it against configured limits, and routing anything out of spec to an [MES](/blog/2025/06/what-is-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.

src/blog/2026/08/layered-process-audit.md

@@ -156,6 +156,8 @@ Good questions usually come from:
 - Scrap and rework data
 - Past audit findings
 
+A control plan check should verify the characteristic itself, its specification and tolerance, and the reaction if a reading falls outside them. See [Control Plans: Linking Quality Characteristics to Measurement Data](/blog/2026/08/control-plans/) for how that mapping works in practice.
+
 Write questions so they can be answered *Yes* or *No* by observing the process.
 
 | Avoid                                    | Better question                                                      |

src/blog/2026/08/run-at-rate.md

@@ -85,7 +85,7 @@ If the agreed threshold is 95%, a result of 95% or higher passes. In the example
 
 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.
+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](/blog/2026/08/control-plans/).
 
 ![Comparison diagram showing PPAP components and where run at rate fits within the approval process](./images/pap-vs-run-rate.png)