Fastener Data Management: Reliably Documenting Fastener Data

On a Thursday, a supplier receives a complaint from an automaker. A brake caliper, manufactured fourteen months ago, has a loose screw connection; the serial number is available. The customer’s question is simple: What torque was used to tighten this bolt, what tool was used, and was the tool calibrated? The values exist. They are stored in the control systems of four bolting systems, in two export directories, and in a database that was purged eight months ago to free up space. After three days, the result is in: The operation can no longer be clearly identified. This means the question is not left unanswered, but has been answered—only to the supplier’s disadvantage.

This case is not the exception. It is the norm in companies that collect bolting data but do not manage it. The difference between the two determines whether existing measurement values provide exculpatory evidence in an emergency or merely prove that measurements were taken.

Torque data management is therefore not a matter of measurement technology, but of data architecture. In most plants, the sensor technology has long been adequate. What is missing is the path from the measured value to a verifiable data record and from there to a storage solution that lasts longer than the system in which it was generated.

This article outlines the entire lifecycle: what data is generated, how to integrate tools from different manufacturers, why the wrench is more important than the measured value, how long you must retain the data, and where the process regularly fails in practice. The normative minimum requirements for each fastening class are not the subject of this article; they are covered in the article on fastening classes according to VDI/VDE 2862.

What is screw data management?

Screw data management refers to the end-to-end recording, assignment, evaluation, and audit-proof storage of all measured values from a tightening operation throughout its entire lifecycle. The term thus encompasses more than just logging at the tool, which in many companies is equated with screw data management.

The distinction can be defined by a single question. A fastening system logs a tightening operation with the actual torque, angle of rotation, and pass/fail decision. That is data collection. Whether this becomes verifiable evidence depends on whether this data set is linked to the component, whether it was evaluated against the approved target value, and whether it will still be retrievable in ten years. That is management.

In practice, the difference often goes unnoticed for a long time. A company can collect data comprehensively for years without ever being able to provide meaningful insights, because the first actual retrieval only occurs when a complaint is filed. Until then, the data looks good in every dashboard.

The four key figures indicate the sources of these requirements. The minimum technical requirements are set forth in VDI/VDE 2862; the obligation to provide evidence stems from product liability and quality management standards; and tax law plays a secondary role. Anyone who bases their retention policy on the tax law retention period is basing it on the wrong criterion.

Why fastening data differs from other quality data

A test characteristic in metrology is a number. A fastening operation is a time series. Depending on the sampling rate of the fastening system, hundreds of pairs of torque and angle values are generated per fastening operation, which together describe the curve. This characteristic has three practical implications that distinguish the data management of fastening data from that of other quality data.

First, the volume. A line with thirty screwdriving stages and a cycle time of one minute generates—when the entire curve is stored—a data volume that exceeds the magnitude of conventional measurement data by several factors. Over a ten-year retention period, this becomes a storage decision—not a trivial matter.

Second, the interpretive value. Two screw-in operations can achieve the same final torque while having completely different curves. A rise that begins too early indicates an obstruction; a flat curve suggests a lack of contact surface; and a drop after joining indicates settlement. The final value alone does not reveal any of these cases. The article on bolting curves discusses which patterns correspond to which causes.

Third, the tool context. Unlike a measuring instrument that tests a characteristic once, the fastening tool is part of the process itself. The measured value is therefore only as valid as the tool’s calibration status at the time of tightening. A data set without a tool ID does not allow for this verification.

The Five Stages of the Fastener Data Lifecycle

The path from the tightening process to reliable information involves five stages. Each stage has a typical breaking point, and in most companies, the breakdown does not occur during data collection but one or two stages later.

It’s revealing to see where investments typically end up. They go to Level One—tools and sensors—because the benefits are visible there and the supplier is tangible. Stages two and four rarely receive their own budget, even though that is where the ability to demonstrate results originates. Therefore, before investing in better measurement technology, examine a specific process to determine at which stage your chain is actually breaking.

Level five is the only one visible from the outside. An auditor or a customer experiences only this level. Everything upstream is judged solely by how quickly and completely information about a single component can be provided. The article on audit trails in manufacturing describes how to establish a robust audit trail for this purpose.

How to Integrate Screwdrivers from Different Manufacturers

Virtually no plant relies exclusively on screw systems from a single manufacturer. Established production lines typically include three to six different brands from various generations, and a new one is added with every expansion. The issue of integration is therefore not a one-time project task, but an ongoing one.

The key rule is: All data paths must converge into the same data model. A manufacturer’s protocol is not the problem as long as the resulting data set has the same structure as that from the OPC UA channel. It becomes a problem when each connection path retains its own format and the data is then evaluated on a per-manufacturer basis. In precisely this case, it is no longer possible to obtain information about a serial number that has passed through three stations from three different manufacturers in a single step.

In practice, this means: Define the data model before you connect the first device, not after. The order sounds obvious, but it is regularly reversed because the first connection usually arises from a specific need rather than from a conceptual plan. Korbinian Hermann explains why manufacturer independence is not merely a matter of convenience in his article on manufacturer independence in production.

Why the Key Is More Important Than the Measured Value

This section contains the one sentence that makes all the difference in practice: A torque value that is not linked to a serial number, bolt location, and tool ID is worthless in the event of a complaint.

The reason lies in the nature of the question being asked. During an audit or in the event of a complaint, no one asks which torque values were measured in a specific calendar week. The question is about a single component, identified by a serial number or a batch. A database organized solely by time and workstation cannot, in principle, answer this question, regardless of its size and quality.

The key must be consistent throughout the process. It must be created in the work order, carried over into the inspection, and retained in the archive. If it is lost during a handoff, a gap is created that cannot be closed retroactively because the components have long since been shipped by that point. The article on the data model for traceability describes the minimum fields that such a data model must include.

In the event of a complaint, no one asks for your torque values. They ask for that one specific component. Anyone who cannot provide an answer within minutes has merely collected data without maintaining proper documentation.

Amadeus Lederle, Chief Technology Executive, CSP Intelligence GmbH

Two other key fields are often underestimated. The screw position must be unambiguous because capability indices are calculated per screw position and not per station. If multiple positions are grouped under a single identifier, a mixed distribution results, and its Cpk is meaningless. The article on Cpk limits according to IATF 16949 clarifies which limit values apply in such cases.

The second underestimated area is the distinction between initial tightening and retightening. Retightening a joint that has already been assembled produces a different curve profile and a different statistical contribution than initial tightening. If both are treated the same, the rework systematically skews the process capability upward.

Curve or final value: what you actually need to save

There is no one-size-fits-all answer to this question, but it can be clearly structured. Compliance documentation and root cause analysis have different data requirements, and anyone who tries to cover both with the same storage policy will either pay too much or lose analytical capabilities.

What the proof requires

To demonstrate that a connection was tightened within the specification, the final value—along with the target value, tolerance, pass/fail decision, and key fields—is sufficient. This data set is small and can be retained without issue for very long periods. It is essential and must not, under any circumstances, be sacrificed for the sake of storage capacity.

What the analysis requires

Root cause analysis requires the data history. Only this history reveals whether a deviation stems from the component, the fixture, the tool, or the assembly sequence. Without the data history, the analysis stops at the observation that a value was outside the tolerance, leaving the question of “why” unanswered.

A practical compromise looks like this: final values recorded continuously throughout the entire retention period, complete curves for a limited period of several months, and beyond that, only the curves for notable events and safety-critical fastening operations recorded continuously. This preserves the ability to analyze the current process without the data volume growing over the years.

Anyone who analyzes curves quickly reaches the limits of threshold testing. A tolerance check flags an error after it occurs, whereas a pattern analysis of the trend can detect anomalies before they happen. The article on curve outlier detection with Curve Anomaly AI demonstrates how this works through machine learning-based analysis.

How Long Screw Data Must Be Retained

The most common misconception in this area is that the tax-related retention period is the one that applies. It is not. Assembly data are not accounting documents, and the retention periods that are actually binding stem from product liability, quality management standards, and customer contracts.

A simple rule follows from this overview: Base your retention policy on the longest binding requirement, not the shortest. In the automotive supply industry, this is generally the customer’s requirement; in medical technology, it is the regulatory requirement for the product; and in neither case is it tax law. A complete overview of the various retention periods can be found in the article on retention periods under the HGB, GDPR, and GoBD.

Two key conditions are often overlooked. The retention period begins when the product is placed on the market, not when it is manufactured—which makes a significant difference when it comes to inventory management. And the new EU Product Liability Directive, which must be transposed into national law by December 9, 2026, imposes stricter documentation requirements. The article on the EU Product Liability Directive discusses what manufacturers can specifically expect in this regard.

Why Screw Fastening Data Management Fails in Practice

The following five issues occur regardless of industry or company size. It is noteworthy that none of them is a technical problem in the strict sense. All five stem from a decision that was not made.

The last point is the most costly because it often goes unnoticed. A system replacement is evaluated based on effort and license costs, rarely on the availability of information. If the legacy system is taken offline without transferring the relevant data to an independent storage solution, the chain of evidence ends on that date, even though the retention period continues. The article on replacing legacy systems describes how to plan a replacement without this loss of data.

A typical scenario involving all five points: The error is made during the rollout and noticed only when a complaint is filed—often more than a year later. This delay is why these issues recur so reliably. There is no immediate feedback to correct them.

Checklist: Is your fastener data management system capable of providing information?

The following eight questions will help you determine in about an hour whether your chain of custody is sound. Each question has a clear exclusion criterion. If even one exclusion criterion is met, it means the chain of custody is not reliable at that point.

Perform the check on a transaction from the previous year that you did not prepare, rather than on a current one from the current week. The current transaction is still in the production system and therefore does not answer the actual question. Auditors select old transactions for the same reason.

If the check fails on question one, start with the key and not with the measurement technology. If it fails on question seven or eight, it is an issue of archiving architecture and falls under IT, not quality assurance. The assignment of responsibility determines the processing time in this case.

Screw Data Management in Manufacturing OS

MOS’s Manufacturing OS is the integrated platform on which process data acquisition, operator guidance, inspection, audit-proof archiving, and AI-based anomaly detection operate on a shared database. For fastening data, the IPM module handles process data, the QST module handles inspection and tool verification, and the CHRONOS module handles long-term storage.

The architectural core is the serial number as a continuous primary key. Because all modules operate on the same basis, the mapping does not occur via an interface between separate systems but is already embedded in the data model. This eliminates the breaking point where most chains of evidence break down.

• Manufacturer-independent integration of screwdrivers and test equipment via OPC UA, REST, and device-specific adapters, all into the same data model
• Serial number as a continuous primary key across operator guidance, process data, and the archive, ensuring that information remains precise down to the component level
• Required fields for each tightening case class are automatically populated, including tool ID, timestamp, and reference to the approved parameter set
• Verification of the tool ID against the test equipment history, so that an expired calibration status is detected before the tightening operation
• Capability indices for each fastening location and time period derived from real-time production data, with separate handling of re-tightening operations
• Audit-proof long-term storage, ensuring that data availability survives a system replacement

Classification is part of the process. The platform does not replace any fastening system or calibration. Nor does it replace the determination of which fastening cases are assigned to which class, as this decision remains a technical one. What it does provide is an end-to-end chain from integration to reporting. Details about the data entry page can be found on the page about process data management with IPM; details about the analysis of curve patterns can be found on the page about anomaly detection.

Frequently Asked Questions

What is fastener data management?

Screw data management refers to the end-to-end recording, assignment, evaluation, and audit-proof storage of all measurement values from a tightening process throughout its entire lifecycle. It goes beyond simply logging data at the tool, because it links the data set to the serial number, fastening position, tool ID, and parameter set, and keeps it accessible for the required retention period. The difference only becomes apparent in the event of a complaint: recorded values without assignment provide no proof.

What are the minimum fields that a fastening data record must contain?

Six fields provide the evidence: the component’s serial number or lot number, unique fastening position, actual torque with target value and tolerance, actual angle of rotation for angle-controlled connections, tool ID, and a machine-generated timestamp. In addition, there are the pass/fail decision, designation as initial or retightening, and the version of the approved parameter set. VDI/VDE 2862 specifies which fields are mandatory for each fastening class.

Do I need to save the complete tightening curve, or is the final value sufficient?

In many cases, the final value along with the target value and tolerance is sufficient for the sole purpose of demonstrating compliance. However, it is not sufficient for root cause analysis, because two fasteners with identical final torque can have completely different torque curves. A practical approach is to permanently store the final value and to store the entire torque curve in full for a limited period of time, and to do so only in cases of anomalies or for safety-critical bolting applications.

How long must bolting data be retained?

In practice, the binding retention period is not determined by tax law, but by product liability and the customer contract. According to Section 13 of the German Product Liability Act (ProdHaftG), claims expire ten years after the product is placed on the market. IATF 16949 Section 7.5.3.2.1 requires retention for the duration of production and service requirements plus one calendar year, unless the customer specifies otherwise. Customer-specific requirements for safety-critical fastenings typically exceed this period. Interpret the retention period based on the longest binding requirement.

How do I connect screwdrivers from different manufacturers?

Use open standards, not manufacturer-specific formats. OPC UA is the most widely supported option because many screwdriver systems and controllers come with a built-in server. REST and MQTT are suitable for newer systems and for high-volume trend data. Manufacturer protocols often remain the only option for legacy systems, but they require a separate adapter for each manufacturer and device generation—one that you’ll have to maintain indefinitely. The key is that all methods feed into the same data model.

Why is the serial number more important than the measured value?

Because without proper assignment, the measured value does not answer any of the questions that arise in the event of a complaint. The question is never which torques were measured in calendar week 14, but rather which tightening operations correspond to this exact component and whether they were performed correctly. Only a continuous primary key spanning operator tracking, inspection, and archiving makes this information possible. Without it, you have a collection of data, but no proof.

How can I tell if my fastening data management system is audit-ready?

The quickest test is a random sample: Have the system display all tightening operations for a randomly selected serial number from the previous year, including target value, actual value, tool ID, and calibration status. If this takes longer than a few minutes or if values have to be gathered from multiple systems, the chain of evidence is not robust. Auditors ask exactly this question, and they ask it about a process you haven’t prepared for.

What happens to fastening data during a system migration?

This is the most common type of silent loss during a system shutdown. When a legacy system is taken out of service, the ability to retrieve information about the operations stored there often disappears as well, even though the retention period continues. The ability to provide evidence then depends on the continued operation of software that no one maintains anymore. A retention strategy with audit-proof archiving must therefore be in place before the system is replaced, not after.