The Torque Tool That's No Longer Typed In

The problem

The last barrier before the customer depends on a manual selection.

Safety fastening points are the last barrier before the customer. Any manually-selected torque program error becomes a safety risk. Manual selection remains the standard method because integrating the torque tool with the MES 'takes engineering time' that never gets prioritized.

• Safety fastening points — suspension, brake lines, steering column, subframe — are the last barrier before the vehicle reaches a customer.
• The torque tool has an API, but it is not connected to the MES. The operator picks the torque program for each variant by hand, at takt, on every unit.
• On a mixed-model line that is one more decision per station and per VIN, and a wrong program on a safety joint is a safety risk, not a cosmetic defect.
• The integration that would solve it keeps losing to other engineering priorities, so manual selection remains the standard method.

How it fits the IRIS system

Connect stitches the torque tool to the MES — driven by the VIN at the station.

Connect stitches the torque tool and the MES via API: when the MES flags which VIN enters the station, it automatically publishes the correct torque program; the OK/NOK result returns to the MES tied to that VIN, with no manual typing.

When the MES says which VIN enters the station, Connect publishes the right program to the tool. When the tool finishes, the OK/NOK result and the tightening go back to the MES under that VIN. The operator stops choosing and keeps tightening. On a mixed-model line, that removes one decision per unit at every connected station, and with it the most dangerous kind of error the station can make.

See the full IRIS architecture →

Before and after

Torque programs picked by hand versus picked by the active VIN

Aspect	Today	With iLEAN Connect
Torque program per variant	Selected by the operator	Loaded from the active VIN
Wrong program on a safety joint	Possible on every unit	Removed as a manual step
OK/NOK result	Lives in the tool's controller	Written to the MES under the VIN
NOK on a safety point	Handled at the station by the operator	Raised through andon with the VIN
Evidence for a field investigation	Searched across controllers	One query per VIN
Engineering effort	A project that never gets prioritized	API to API, no tool replacement

Manual program selection with human-error risk → automatic selection with no manual typing, complete per-VIN torque traceability.

Impact estimate

Impact estimate — to be validated with your numbers.

The block below is an estimate to be validated against your plant's actual data. We put it forward so the committee has an order of magnitude; we refine it during the assessment.

• Fast payback, estimated at 3-6 months.
• A drastic reduction in the risk of a safety non-conformance caused by a wrong program on a critical joint.
• Complete per-VIN torque traceability, without a single value typed by hand.
• And when a field question comes in about a specific vehicle, the answer is a query, not a search across tool controllers.

Fast payback, 3-6 months, drastic reduction in safety non-conformance risk. *Figure to be validated*. (Payback 3-6 months · reduces safety-recall risk)

And the fair question from the production manager

“What if the MES publishes the wrong VIN and the tool loads the wrong program?” — matching a VIN to its variant's torque program is an anchored lookup against your own bill of process, where even the best models drop below 1.5% error [1], and here it is mostly deterministic. The second net is the tool itself: it confirms which program is loaded before the first rundown, and a mismatch between VIN and program stops the station instead of tightening, with the reason shown to the operator.

^[1] OpenAI paper "Why Language Models Hallucinate", 2025 — on the reliability of AI in anchored tasks.