On an axle assembly line, several thousand bolted joints are tightened per shift. Every single one is critical to safety. The crucial question in the audit is not whether the fasteners were in order, but whether you can verify this for every single component. And this is precisely where production facilities that record their quality data on the line differ from those that piece it together afterward.
The market promises this with a single term: quality management software. But the term obscures a crucial difference. A system that tracks documents and manages actions is not the same as a system that records the actual torque curve of a fastener at the moment it is tightened and assigns it to the component. One manages the specifications; the other provides the proof.
Anyone familiar with production lines knows where the chain of evidence breaks: not at the machine and not at the worker, but at the point where a measured value is manually entered into a spreadsheet. This data discontinuity is the most expensive step in the entire quality assurance process. It leads to audit findings, prolongs recalls, and causes quality metrics to diverge from reality.
This article shows what quality management software actually accomplishes on the production line, why traditional quality assurance fails due to data bottlenecks in high-variety manufacturing, what kind of integration production-integrated data capture requires, and how to get started in five steps.
KEY POINTS AT A GLANCE
|
IN A NUTSHELL
|
Quality management software on the production line captures quality-relevant process data directly at the point of origin and links it immediately to the component. The difference from traditional quality assurance lies not in the analysis, but in the timing of the data collection: The data is generated at the exact same moment the product is produced, not in a downstream log.
Specifically, the software reads values such as torque, press-fit force, screw-in and press-fit curves, test results, or operator confirmations directly from the system’s control level. Each value is automatically stamped with the timestamp, the station, and the component code. This creates a continuous history file from many individual measurement points, eliminating the need for manual documentation.
In this way, the software precisely addresses the traceability requirements set forth in IATF 16949 Section 8.5.2 and the requirements for data-driven decisions in ISO 9001:2015 Section 9.1. Traceability is not an additional feature, but rather the result of data collection at the right location.
|
8.5.2 IATF 16949 section requiring traceability down to the component level IATF 16949:2016 |
35+ years Audit-proof data availability for product liability and audits CSP White Paper on Production Data |
Billions Data points analyzed and processed daily CSP White Paper: Production Data |
Class A Audit finding class that regularly includes a lack of traceability IATF 16949 Audit Practice |
Traditional quality assurance isn’t wrong—it’s just in the wrong place. As long as products, test plans, and tolerances rarely change, manual data entry and summary logs work well. In high-variety manufacturing, where orders change multiple times per shift, these very procedures break down.
The bottleneck always arises at the same point: where a system change is bridged by manual entry or an Excel file. At this point, quality data loses its context, and without context, data cannot serve as a basis for decision-making. The following four bottlenecks recur time and again in projects.
| Data Bottleneck | What It’s About | Impact on Quality and Audits |
|---|---|---|
| Manual Data Transfer | Measurement values are manually transferred to a log or spreadsheet. There is a media break between the measurement and the entry, which results in a loss of context and association. | Mapping to individual parts is lost. Errors remain undetected until they reach the customer. No searchable documentation is available during audits. |
| The Collective Log | One log for many parts. Approval is granted in bulk for a batch, not on a per-component basis. In production with many variants, this model breaks down. | Partial recalls are not possible; only full recalls are allowed. IATF nonconformity due to lack of serialization. Loss of the approval history for each component. |
| The Data Silo | Machine data, inspection data, and order data are stored in separate systems that do not communicate with one another. The common key is missing. | No complete component file. Manual consolidation required for every audit. Inconsistent metrics across systems. |
| The Archiving Gap | Data is recorded but not stored in an audit-proof manner or made available for the long term. After the ERP migration—or years later—access is lost. | Evidence gap in the event of future product liability claims. GoBD and HGB deadlines cannot be met. Reconstruction is only possible with significant effort. |
The core of digital quality assurance is moving the point of data capture forward. The following three real-world cases illustrate the same mechanism in different situations: Capturing data at the point of origin makes the process verifiable, not just the result.
| Case | Documented downstream | Recorded at the production line | Insight |
|---|---|---|---|
| Screw connection | The final value is read from the tool memory at the end of the shift. | The torque curve is recorded directly during tightening and assigned to the component. | Recording at the point of origin makes the process verifiable, not just the result |
| Changeover | The inspector manually updates the plan; the changeover time is not documented. | The software recognizes the job and automatically loads the inspection plan and tolerances for each part. | Automatic assignment closes the typical gap in high-variety manufacturing |
| Audit | Data from the MES, inspection software, and archive is manually compiled. | The component file is retrieved in full within minutes using the serial number. | Seamless integration reduces audit documentation time from hours to minutes |
The pattern is identical in all three cases. The downstream process ultimately yields a number, but no context. The history, the timing, and the association with the individual part are lost—and with them, the ability to detect a deviation at all. Data capture at the production line reverses this: It provides the complete history for each component and makes deviations visible before the part leaves the station.
The most costly aspect of quality assurance is neither the machine nor the worker. It is the moment when a system change is bridged by an Excel file. That is where quality data loses its context.
— Amadeus Lederle, Chief Technology Evangelist, CSP Intelligence GmbH
Data collection on the production line stands or falls with machine connectivity. A solution that captures data only via the keyboard merely shifts the data discontinuity; it does not eliminate it. Open protocols and vendor independence are crucial.
At the machine level, four protocols are key. For higher-level systems, REST API and XML are also used. The following overview categorizes the common connectivity options.
| Readiness for Data Collection | Level | How to Identify It | Next Step |
|---|---|---|---|
| Paper Log | Level 0 | Measurement values recorded manually, no system integration | Digitization of the three most critical processes |
| Manual entry | Level 1 | Values entered into a form after the fact | Direct machine connection instead of a keyboard |
| Semi-automatic | Level 2 | Some systems provide data, others do not | Seamless connection of all stations subject to reporting requirements |
| Integrated | Level 3 | All stations provide real-time data down to the component level | Integration with ERP, MES, and the archive |
| End-to-end | Level 4 | Process, inspection, tooling, and archive in a single database | Predictive analysis and anomaly detection |
The choice of protocol is not purely an IT issue. The following overview categorizes common protocols according to their role in production-integrated quality management software.
| Protocol | Level | What it is used for | Typical Use |
|---|---|---|---|
| OPC UA | Machine | Cross-vendor access to controllers without proprietary drivers | Newer equipment, PLCs, test systems |
| MQTT | Machine / IoT | Event-based transmission of sensor data | Sensor networks, distributed measurement points |
| S7 / Modbus | Machine | Integration of older controllers | Existing systems without OPC UA |
| Open Protocol | Tool | Standard for Screwdriving and Tightening Systems | Screw fastening, torque measurement |
| REST API / XML | System | Integration with higher-level systems | ERP, MES, order and master data |
OPC UA has established itself as a vendor-neutral industry standard and allows access to controllers without proprietary drivers. MQTT is suitable for event-based sensor data. S7 and Modbus connect older controllers. Open Protocol is the standard for bolted joints. For screw connections, VDI/VDE 2862 further specifies exactly which values need to be recorded.
The second critical point is vendor independence. In almost every established plant landscape, screwdrivers, presses, and testing equipment from different manufacturers operate side by side. A data collection solution that processes only devices from a single manufacturer creates precisely the kind of data silo it is supposed to eliminate. Only a solution at the shop floor level that processes data from different manufacturers leads to a unified database.
|
Three Common Misconceptions About Integration One interface is sufficient. In fact, end-to-end data collection requires integration at the machine level and coupling with ERP and MES via a common part number. The equipment manufacturer provides the data collection capability. In a mixed plant landscape, this results in a separate silo for each manufacturer, rather than a unified database. Data collection means storage. Collected data that is not archived in an audit-proof manner and accessible over the long term will be missing precisely when product liability requires proof years later. |
End-to-end quality data capture is not a single product, but rather the controlled interaction of four functional areas. They can be implemented individually and gradually integrated into a shared database. Together, they form the Manufacturing OS.
| IPM Process Data Management | PGX Digital Operator Guidance | QST Tool and Process Inspection | CHRONOS Audit-Proof Archiving |
|---|---|---|---|
|
Task Collects process data such as torque, press-fit, and screw-in curves directly from the control level and links them to specific components. |
Task Guides operators step-by-step and variant-specific through the assembly process and records confirmations and deviations. |
Task Plans, executes, and evaluates process and tool capability tests over the tool’s service life, regardless of the tool manufacturer. |
Task Archives production and quality data in an audit-proof manner and ensures long-term availability, in compliance with GoBD, HGB, and IATF. |
|
On the production line Direct machine integration, limit value monitoring, and real-time email alerts in case of deviations. |
On the production line Multi-level notification system; deviation logging with timestamp and operator ID for each component. |
On the production line Individual measurement points for each joining technique, process and machine capability testing, manufacturer-independent. |
On the production line Long-term archiving with data retrievability after 15 years or more; departmental access without an IT ticket. |
|
Benefits for the chain of evidence Complete process data for each component as the basis for every chain of evidence |
Benefits for the audit trail Errors are prevented at the workstation rather than checked afterward |
Benefits for the audit trail Verification that the process and tool are operating within tolerance |
Benefits for the chain of evidence The audit trail remains available for the entire statutory retention period |
The appeal of this modularity lies in the ability to get started without a major IT project. A company does not have to implement all four modules at once. It begins with process data collection at safety-critical joining stations and adds operator guidance, tool inspection, and archiving where the documentation requirement demands it. Because all modules use the same part key, each step contributes to a more complete part file rather than creating another silo.
Being honest about one’s own limitations means clearly identifying what production-integrated quality management software cannot replace. Those who understand these limitations can plan more realistically and avoid disappointments during the project.
First, data collection on the production line does not replace a comprehensive quality management system in terms of document control. It provides real-time process data for each component but does not manage the approval of test specifications, complaint workflows, or audit planning. These two levels complement each other; they do not replace one another. The Manufacturing OS is a production and process data layer, not a QMS documentation suite.
Second, the software does not make autonomous approval decisions. It monitors threshold values, reports deviations, and flags anomalies, but in safety-critical industries, the decision to approve a component remains with humans. The EU AI Act and the EU Product Liability Directive 2024 set clear boundaries here: AI-supported evaluation is decision support, not a substitute for the responsibility of the approving inspector as defined in IATF 16949 Section 8.6.
Third, even the best anomaly detection is dependent on data sets and training data. A model trained on one material cannot be transferred to another without validation. If the production environment changes, revalidation is required. AI on the production line reduces the inspection workload; it does not eliminate it.
The successful implementation of quality management software on the production line does not come from a large-scale, plant-wide project, but rather through a controlled integration, station by station. The following path is based on successful reference projects in which data collection began at a critical assembly station and was gradually rolled out.
| Step | Time Frame | Tasks | Result |
|---|---|---|---|
| 1. Identify processes requiring documentation | Weeks 1–2 |
|
Prioritized list of stations subject to verification |
| 2. Clarify data keys and the system landscape | Weeks 3–4 |
|
Data model with primary key and interface overview |
| 3. Integrate the pilot at one station | Weeks 5 through 10 |
|
A productive station with complete data capture |
| 4. Roll out to additional stations | Weeks 11 through 20 |
|
Ensure consistent data collection across all prioritized stations |
| 5. Standardize archiving and analysis | on an ongoing basis |
|
Implement quality data collection on the production line as a permanent operational state |
The Manufacturing OS consolidates process, quality, and tool data into a single, integrated database. Data collection on the production line is not a separate step but is integrated into the manufacturing process.
|
Practical Tip Manufacturing OS – End-to-End Quality Data Collection on the Production Line Manufacturing OS connects the four modules—IPM, PGX, QST, and CHRONOS—within a shared database. Process data is captured directly from the control level, linked to specific components, monitored against threshold values, and archived in an audit-proof manner. Reference customers in the automotive sector include BMW, Mercedes-Benz, and Knorr-Bremse.
|
On-line quality management software is a system that captures quality-relevant process data directly at the point of origin in production and links it in real time to a batch or serial number. Instead of transferring measurement values to an inspection report after the fact, the software reads torque values, press-fit values, curve profiles, or test results directly from the system’s control level. The result is a complete component record that is generated without any manual documentation work. The key difference from traditional quality assurance lies not in the evaluation, but in the timing of the data capture.
A traditional quality management system documents processes, manages compliance with standards, and controls corrective actions, but primarily works with data entered retrospectively. Production-integrated quality management software, on the other hand, captures actual process data directly at the machine—with component-level precision and automatically. The two systems are not mutually exclusive; they serve different levels: The QMS manages specifications and document control, while the production-integrated software provides the actual measurement values for each component. Consistent quality is achieved only when both levels are linked via a common data key.
Open protocols are crucial for connecting to the machine level: OPC UA as a cross-vendor industry standard, MQTT for event-based sensor data, S7 and Modbus for controllers, and Open Protocol for screwdriving systems. REST API and XML are used for connecting to higher-level systems, such as for integration with ERP and MES. Vendor independence is key: A solution that processes tools from only a single manufacturer creates data silos once again in a mixed plant landscape.
In high-variety manufacturing, products, inspection plans, and tolerances change frequently—often multiple times per shift. Manual data entry and summary logs cannot keep up: they can no longer unambiguously assign measurement values to individual components and lose the process context. The data bottleneck arises where a system change is bridged by an Excel file or manual entry. It is precisely at this point that the chain of evidence becomes incomplete, which manifests as a finding during an audit and, in the event of a recall, as costly uncertainty in containment.
Traceability requires that every process step be documented down to the component level and linked via a common identifier such as a batch or serial number. When data collection is moved to the production line, each measurement value automatically carries this identifier because it is generated at the same time as the component. This allows a complete component file—comprising material, process parameters, test results, and proof of shipment—to be reconstructed in minutes rather than hours. IATF 16949 Section 8.5.2 requires precisely this traceability, which is systematically achieved through data collection at the point of origin.
Key standards include IATF 16949, with Section 7.5 on documentation, 8.5.2 on traceability, and 8.6 on release decisions, as well as ISO 9001:2015 with Sections 6.1 on risk-based thinking and 9.1 on data-driven decision-making. GoBD and Section 257 of the German Commercial Code (HGB) apply to long-term archiving. For bolted joints, VDI/VDE 2862 specifies the requirements. If AI-supported functions are used, the EU AI Act and the EU Product Liability Directive 2024 also apply.
Software on the production line can prepare data-driven release decisions by monitoring threshold values, reporting deviations in real time, and flagging anomalies. However, in safety-critical industries, the decision itself remains with humans. Fully autonomous approvals without human oversight are not permitted in these areas under the EU AI Act and the EU Product Liability Directive 2024. The software provides the basis for the decision and documents it in a traceable manner, but it does not replace the responsibility of the approving inspector as specified in IATF 16949 Section 8.6.
It makes sense to start with a single line or station, not the entire plant. Such a controlled pilot can be up and running in just a few weeks because modern solutions use standard software with limited customization requirements. Reference projects in the automotive industry demonstrate a step-by-step approach: first connect a critical assembly station, ensure data quality, and then gradually roll out the system to additional equipment. What matters is not the speed, but that the first connected station delivers reliable, component-specific data.