Nobody, in most cases. Each manufacturer documents its own machine and stops at its terminals. The dialogue between two pieces of equipment from different suppliers, the signals exchanged, the synchronisation conditions, all of that stays verbal. When the fault sits there, the maintenance team works without a document and each supplier points to the other.
This grey area exists for a simple reason: it belongs to everyone and to no one. Industrial intelligence platforms such as Mimorian model equipment and the links between them to support field maintenance teams in fault diagnosis, including when the defect sits on the boundary between two machines.
Why does documentation stop at the terminals of each machine?
A manufacturer delivers a machine. Its manual covers its contractual scope: functions, settings, spare parts, fault codes, electrical cabinet drawing. Anything beyond its terminals falls to the integrator, when an integrator was involved, or to the site itself.
The integrator documents the installation as it stood on commissioning day, then leaves. Later adjustments, a new recipe, a change of throughput, an added buffer station, happen inside the programmable logic controller program, with a note in a logbook at best.
Reliability standards keep this split alive. ISO 14224 structures data around the equipment, the cause, the failure mode and the corrective action [Source : ISO 14224, 2016]. That framework is built to compare pieces of equipment with one another. It says nothing about what connects them.
What does a fault in the grey area cost?
The line stops. The upstream machine reports a transfer fault, the downstream machine shows a wait state. Taken separately, both work. The defect is in the dialogue: a permission arriving too early, a presence detector read at the wrong moment, a timer adjusted one production day and never recorded.
The team calls the first supplier: my equipment is compliant, take it up with the other one. It calls the second, same answer. Two contacts, two scopes, one boundary with no owner. Meanwhile the equipment stands idle and the maintenance technician searches alone, reading the program.
Diagnosis then happens without a document, so on intuition. The Vanson Bourne study for ServiceMax attributes 23 % of unplanned downtime in manufacturing to human error, against a rate that falls to 9 % in other sectors [Source : Vanson Bourne/ServiceMax, 2017].
Why do newcomers pay for this grey area first?
An undocumented interface holds up as long as someone carries it in their head. A long-serving technician knows that this conveyor waits one extra second since the format change, that this transfer fault comes from the same badly fixed detector. That knowledge travels during the break and stops there.
The day a maintenance technician arrives from another site, they inherit the manufacturer manuals and very little on the links. They open the electrical cabinet, trace the inputs and outputs of the programmable logic controller, and rebuild the picture alone. At Mimorian, we judge a diagnostic support tool first on what it documents about interfaces, precisely for those newcomers.
Team turnover speeds up this loss. DARES counts three occupations out of four under strong or very strong tension, that is 68 % of total employment [Source : DARES, 2023]. Arrivals and departures follow one another faster than knowledge transfer.
Knowledge concentrated on one or two people is a neighbouring problem, covered in our article on the loss of expertise when people retire. The subject here is the area nobody ever wrote down, even with the whole team present.
How can you document an interface without waiting for the manufacturers?
The right scale is small. An interface fits on one page, and that first page already creates value where a complete plan would stay at the intention stage. Five steps are enough to start.
- Give the link a name. As soon as it carries its own identifier, separate from the two pieces of equipment it connects, it has a file and anyone can attach something to it. A name such as transfer from accumulation conveyor to packaging machine does the job.
- List the signals exchanged. Transfer permission, product presence, stop request, acknowledgement: for each one, the sender, the receiver, the expected state. That table already exists inside the controller program, it is waiting to be written in plain language.
- Write down the synchronisation conditions. Timers, thresholds, acceptance windows. These are the values that shift in operation and that people always end up hunting for during a stoppage.
- Capture it while it is fresh. The best moment to document a link is the end of an intervention that took place on it: the maintenance technician has just understood the mechanism. A few lines in the job report, attached to the link as much as to the equipment.
- Connect the objects together. The link points to its two pieces of equipment, each piece of equipment points to its links. A production line then reads as a graph of dependencies.
Where do you file this documentation when everything is sorted by equipment?
The dominant tree structure runs by site then by equipment, with documentation and interventions in the same sub-folder. A clear logic as long as every object has an owner. The link fits nowhere easily: filing it under one of the two machines means betting on the one people will open first.
Two options hold up. Create an interfaces level at the same rank as equipment inside the line folder, which works with a plain file tree. Or attach each intervention to one or several objects, equipment as well as link, which calls for a tool able to carry relationships.
Frequently asked questions
Do you need to document every interface on a line? Starting with those that have already caused a stoppage and with the boundaries between different suppliers is plenty. A handful of links come back more often than the others in night calls. The rest gets added as interventions happen.
Can the manufacturer supply the interface documentation? It can supply the input and output table of its machine and the logic expected on its side, which already covers half the work. Combining the two sets of logic belongs to the site. Asking for that table at order time costs one line in the specification, asking for it three years later costs a paid service.
Can AI help on an interface fault? It helps when it knows the link, its signals and its history. A model that only sees isolated equipment reproduces the grey area. The value comes from modelling the connections and capturing past interventions. AI takes over when the site expert is away, and captures their reasoning when they are there.
Key points
- Interface documentation is missing by design: each manufacturer documents its own scope, the integrator photographs commissioning day, and reliability standards reason equipment by equipment.
- The cost shows up as downtime and as suppliers pointing at each other, and it lands first on maintenance technicians who joined recently, the ones still building the implicit knowledge of the site.
- Documentation gets built in small steps, while the memory is fresh, by giving each link a name, a signal table and its synchronisation conditions.
A concrete next step: take the last three stoppages on the line, spot those whose cause sat on the boundary between two machines, and open a file for each of those links.
An industrial intelligence platform that models equipment and the links between them makes this documentation useful during diagnosis, at the moment the line is down. That is the choice Mimorian makes.