Making an undocumented system understandable

The PLC monitoring cabinet could not close properly. Cables were hanging, connections were unidentified, some cables were too short for the existing arrangement, and no usable installation documentation was available.

Before reorganizing it, I needed to understand what was actually connected—and why.

I searched for available documentation, studied the manuals for the PLC series, and traced relevant connections one by one: the monitored sensor, its signal origin, the corresponding PLC terminal, and the monitored unit it belonged to.

The model did not exist beforehand. It emerged from the investigation.

As the connections became clearer, so did the constraints. Cable lengths limited how the panel could be rearranged, parts of the layout prevented connections from being organized cleanly, and the available power supply was insufficient for the PLC together with the active sensors.

Repairing only the most visible faults would leave much of the underlying uncertainty in place. I presented the condition of the panel to the vessel manager and obtained agreement for a broader reorganization.

Cost remained a real constraint. Instead of assuming that every component should be new, I inspected material available aboard and reused verified equipment where appropriate, including power-supply equipment.

I removed the PLC panel, reorganized the panel and terminal bars by motor or monitored unit, and gave every terminal a unique identifier. A team already organizing other electrical panels helped with the cable bundles.

The investigation produced a map showing the origins and destinations of the connections and their relationship to the monitored units. I printed and laminated it and attached it to the inside of the cabinet door, where someone working on the panel later could consult it directly.

The project left the panel substantially more organized and understandable, with documentation available directly at the maintenance point.

On a later visit, the chief engineer specifically thanked me for how much easier the map made it to identify the origin and destination of connections.

The work had not only changed the physical arrangement. It had made knowledge that was previously implicit available to the next person approaching the system.

This experience is not evidence of specialization in PLCs or industrial automation. Its relevance to my work as a Software Engineer lies in the reasoning pattern: investigate before changing, build a model from available evidence, make constraints explicit, choose according to context, and leave useful knowledge with the system.

In software, implicit knowledge can be made visible through tests, boundaries, diagrams, logs, decision records, abstractions, documentation, and observable behavior.

When critical knowledge is implicit, making it visible can become part of the engineering solution.

Explore other evidence