Torque Traceability Software for Atlas Copco, Desoutter & Cleco
Multi-brand torque traceability: every fastening from Atlas Copco, Desoutter, Stanley, Cleco and Ingersoll Rand controllers written into one schema and bound to the vehicle's VIN at the moment it happens, with the calibration state of the tool on the record.
Watch with transcript →1:08 · captions · narrated demo
Software Modules
Complete Torque Traceability Modules
Screens from the running system — click a module to preview
System Architecture
Connect multiple torque controller brands over Open Protocol for comprehensive monitoring.
Real-time torque traceability for every critical joint
MileSoft Torque Traceability is the system automotive OEMs and Tier 1/2 suppliers install to prove that every critical safety joint on every vehicle meets spec. Brakes, steering, suspension, airbag mounts — the joints that show up in recalls — are exactly the joints the system captures, validates, and logs against a VIN in real time. The platform integrates every major torque controller brand (Atlas Copco, Desoutter, Stanley, Cleco, Ingersoll Rand) in the same daisy chain via Open Protocol, ToolsNet, or TCP/IP, so a mixed-vendor line doesn't fragment the audit trail.
On the line, the system reads every torque event live, compares it against the joint's stored specification, and returns pass/fail immediately — with rework routing if out-of-spec. Vehicle identity comes in through barcode scanners, RFID, or PLC handshakes (including Allen-Bradley via RS Linx), so every tightening event is bound to the exact VIN on the line. Station buyoff certificates print automatically at shift end or per-vehicle; the digital archive is searchable by VIN for warranty investigations, recall defense, and IATF 16949 audits.
Beyond compliance, the system drives continuous quality improvement: Cp, Cpk, Pp, and Ppk process capability metrics are computed per joint, per shift, per line, and feed SPC dashboards that flag torque drift before defects occur. Integration with plant MES and ERP is standard, as is fault signaling back to the PLC for fastener rejects. Manual torque recording disappears — the audit trail that once took a quality team to produce for an audit now generates itself, continuously, for every vehicle that leaves the line.
Torque traceability
One record per joint, bound to a VIN at the moment of fastening
Every fact a warranty claim asks for was measured. Conventionally, none of them was written down together.
A critical-fastener warranty claim names a vehicle and a date. The supplier must establish which station built it, which tool made the joint, which operator was signed on, what torque and angle were achieved, and whether the tool was in calibration. The controller recorded a result keyed to itself; the line recorded a build sequence; calibration lives in a quality system. Assembling them is forensic work against a deadline.
Two decisions remove the reconstruction: every controller writes into one normalised schema regardless of vendor, and every fastening is bound to a vehicle identity at the moment it occurs. Backward traceability from a VIN and forward traceability from a suspect condition then become index lookups rather than joins.
Worked example: what binding the forward set is worth
A controller is found to have drifted after a maintenance event four days earlier. The line builds 690 units a shift across two shifts, so about 5,520 vehicles passed through. Because each fastening carries a resolved VIN, the query returns exactly the vehicles that controller touched — say 1,840, since it serves one of three parallel stations.
Without identity binding, containment is all 5,520 vehicles. With it, 1,840 — and the other 3,680 are excluded provably rather than by argument. The drift and the detection were identical; only the ability to bound the population changed. Query speed is containment size by another name.
Why audits hurt
Five failure modes of conventional torque data collection
Each one is structural, which is why careful people still end up reconstructing records.
Vendor-fragmented logs
Each controller writes its own format, so the audit trail has as many shapes as the plant has tool brands.
Station-keyed results
A result identified by station and timestamp cannot be bound to a vehicle after the shift without a separate occupancy record.
Late limit application
Where torque windows are applied in a reporting tool instead of at capture, the same raw result can be judged conforming or not depending on which limit version the report used.
Capability without control state
Cpk is reported for processes that are not in statistical control, overstating confidence in a way the number itself does not show.
Unverified verification
Hand-torque audit results are recorded without the calibration state of the tool that produced them.
Multi-brand torque data collection
Multi-brand torque data collection: Atlas Copco, Desoutter, Stanley and Cleco in one schema
Adding a controller brand should change an adapter and nothing else.
Atlas Copco, Desoutter, Stanley, Cleco and Ingersoll Rand controllers are collected over Open Protocol, ToolsNet or direct TCP/IP, with a vendor adapter isolating each protocol's differences. A mixed-vendor line therefore produces one audit trail, not several that disagree about format. Fault signalling runs the other way: a rejected fastener signals the PLC, so the line's own interlocks take part in the reaction rather than depending on someone noticing a screen.
Four governed master records decide what the capture layer accepts: the line, the controller, the model code, and the joint specification — its torque and angle window and its VDI/VDE 2862 classification. VDI/VDE 2862 Part 1 classifies automotive bolted joints by the consequence of failure, and that class sets the minimum detection capability the tightening system needs. Held as master data, it is enforced at capture; held in a quality document, it drifts from the tooling actually used, and the gap is found in an audit rather than before one.
- Vehicle identity by barcode, RFID or PLC handshake
- Allen-Bradley PLCs over RS Linx
- Station buyoff certificates per vehicle or per shift
- Archive searchable by VIN
Bolt torque management
What makes a bolt torque record admissible evidence
Four facts must resolve at capture, or the record cannot answer an auditor's question.
admissible = VIN resolved AND joint in the governed set AND specification version bound AND tool within its calibration interval
Calibration is part of the record because ISO 6789-2 governs calibration and measurement uncertainty for hand torque tools. A verification torque quoted without the calibration state of the tool that measured it is incomplete.
An event that fails the test is written and flagged, not dropped. A discarded event leaves a gap that looks identical to a fastening that never happened, and in a dispute that difference matters enormously.
The same structure is why a buyoff certificate can be regenerated for a vehicle built months ago and come out identical: the verdict and the specification version were stored, not recomputed. That is what makes the document evidence rather than an assertion, and it is why IATF 16949 audit preparation stops being a compilation exercise — the trail generates itself for every vehicle that leaves the line.
Cp, Cpk, Pp, Ppk
Why Cpk can flatter a drifting station, and what to report instead
ISO 22514-2 separates processes in statistical control from those that are not. The index you report depends on which.
Cpk uses within-subgroup spread · Ppk uses overall spread · Cpk ÷ Ppk ≈ overall σ ÷ within σ
The two pairs coincide when a process is in control and diverge when it is not. The size of the divergence is itself the diagnostic.
Worked example: same shift, two numbers 60% apart
A critical joint is specified at 52 Nm ± 5 Nm. Over one shift, 25 subgroups of four fastenings give a mean of 52.4 Nm, within-subgroup σ of 0.92 Nm and overall σ of 1.48 Nm. Cpk = 1.67 — comfortably acceptable. Ppk = 1.04. The ratio of 1.61 says the mean is drifting between subgroups: tool warm-up, a loosening reaction arm, or a joint surface changing through the shift. Reporting Cpk alone would have recorded a healthy station.
Worked example: catching drift before any fastening fails
With an established mean of 52.0 Nm and a standard error of 0.46 Nm, successive subgroup means of 52.1, 52.4, 52.8, 53.2 and 53.5 Nm give Z values of 0.22, 0.87, 1.74, 2.61 and 3.26. Every individual result is still inside 47–57 Nm and no operator has seen an alert — but at that rate the mean reaches the limit within the shift.
Flagging at Z = 2 produces a tool check on a station still making good joints. Waiting for a reject produces an investigation, a quarantine, and a question about every vehicle built since the drift began.
Limits, stated plainly
Torque traceability detects bad fastenings; it does not prevent them
A real limitation, and the reason the reaction to a detection matters as much as the detection.
Unlike a physical interlock that makes a wrong action impossible, torque traceability detects a non-conforming fastening. What the architecture adds is that detection is immediate rather than downstream, that the unit is flagged rather than passed, and that for the highest joint classes the station can be inhibited pending documented rework. The gap between detection and prevention narrows only as far as the reaction is enforced by the system rather than left to a person.
So "compliance" should be read precisely: every joint is evaluated against its specification at capture and a non-conforming result cannot pass undetected — not that a non-conforming fastening never occurs.
MileSoft's published Industry 4.0 case study describes a Tier-1 automotive supplier across Pune and Nashik where Torque Traceability ran alongside Andon, Material Traceability and ERP, bringing more than forty controllers across twelve stations under one trail. Its results belong to that four-module programme; this module's share was not isolated, so they are not claimed here.
Evaluating torque software
Eight questions to put to any torque traceability system
Each is answerable by demonstration — including by us.
| # | Dimension | Ask the vendor to demonstrate |
|---|---|---|
| D1 | Vendor neutrality | Add a controller from a new brand. Does anything beyond an adapter change? |
| D2 | Identity at capture | Is a fastening admissible without a resolved VIN, or is it flagged? |
| D3 | Capture-time evaluation | Is the verdict stored with the raw value and the specification version that produced it? |
| D4 | Version recovery | For a vehicle built a year ago, can the system state which torque window applied? |
| D5 | Control state | Are Cp/Cpk and Pp/Ppk both computed, with the control state reported alongside them? |
| D6 | Forward closure | Name a suspect tool and a date range. How long to return the exact affected VIN list? |
| D7 | Device verification | What happens when a controller is overdue for verification? Demonstrate the state. |
| D8 | Reproducible buyoff | Regenerate a buyoff certificate from six months ago. Is it identical to the original? |
D8 is the strongest single test. A buyoff that regenerates identically proves the verdict and specification version were stored rather than recomputed.
Standards referenced: IATF 16949, VDI/VDE 2862 Part 1, ISO 22514-1 and -2, ISO 6789-1 and -2, IEC 62264-1 / ISA-95, IEC 62541 (OPC UA), ISO 22400-2, ISO/IEC 19987. Derivations are in the torque traceability method paper.
Features
Key Features
Built-in capabilities that set our software apart
Multi-brand collection
Atlas Copco, Desoutter, Stanley, Cleco and Ingersoll Rand over Open Protocol, ToolsNet or TCP/IP, in one schema
VIN binding at capture
identity from barcode, RFID or PLC handshake is resolved before the fastening is written
Capture-time evaluation
the verdict is stored with the raw value and the specification version that produced it
Governed joint classification
VDI/VDE 2862 class held as master data and enforced by the capture layer
Capability with control state
Cp/Cpk and Pp/Ppk per joint, shift and line, with drift flagged before a reject
Reproducible buyoff
station and vehicle certificates regenerate identically from stored events
PLC fault signalling
a rejected fastener signals the line so its interlocks take part in the reaction
Benefits
Key Benefits
What your team gains from adopting our platform
none passes undetected
Integrations
Works with the systems you already run
Torque controllers and PLCs MileSoft already collects from on live assembly lines.
Testimonials
What Our Clients Say
Trusted by industry leaders across manufacturing, HVAC, and logistics.
"The software features, such as real-time monitoring and alerts, have proved invaluable in optimizing machine operations. MileSoft team's professionalism, technical expertise, and dedication to meeting our requirements have been impressive."
FAQ
Torque Traceability Software — FAQs
Answers to the most common questions about this product. Need more? Book a demo or reach out via Contact.
What is torque traceability and why do automotive assembly lines need it?
Which torque controllers does MileSoft integrate with?
Can it link torque events to a specific VIN?
Does it produce buyoff reports?
What quality metrics does it calculate?
Explore More
Related Products
Complementary tools teams often pair with this solution
Related Reading
Go deeper
Explore the long-form story behind this product.
A Digital Pedigree for Every Joint: Multi-Vendor Torque Capture, VIN Binding, and Capability at the Fastening
Architecture, Computational Methods, and Field Evidence from MileSoft Torque Traceability
Read the paperRead the full Torque Traceability Software for Atlas Copco, Desoutter & Cleco deep-dive
Read articleSee how MileSoft delivers in Industry 4.0
Read case studySee your savings in under a minute
Estimate the time and cost this tool could give back — free, instant, no sign-up.
Put your mixed-brand line to the eight-question test
Name a suspect tool and a date range from your own line. We will show the exact VIN list it returns, regenerate a past buyoff, and report Cpk beside Ppk.