Practices that keep shop-floor instructions provable

I define a digital thread narrowly: the customer's approved model and revision, the routing and traveller we issue, the program or weld procedure used, and the inspection result that closes the work. If any link depends on someone remembering to compare a printout, the thread is broken at that point. I start with the products that change most often and carry the highest rework cost, rather than buying one platform for every product family. For naval work, that meant linking model revisions to travellers and coordinate-measuring results before touching scheduling. I judge the thread by revision-related nonconformances and inspection hours, not by the number of systems connected. Design engineers own the model, planners own the traveller and quality owns acceptance. My team keeps the connections between them reliable, and visible when one fails.

Much of our operational technology was installed when nobody expected a machine tool to touch a network. Some controllers run software their makers no longer support, and several are still excellent machines with decades of work in them. I group equipment into zones by what it does and what an interruption would cost, then decide which connections each zone genuinely needs. Program transfers pass through a controlled server, portable storage ports are sealed, and remote vendor sessions are opened for a set period and logged. Replacement is first a capacity and reliability decision, with security one input to it. I report to our audit and risk committee from a register of every controller, its software version, its zone and its spares, so directors see the exposure itself rather than a coloured summary.

Naval customers send technical data that may fall under Australian export controls and, on some programmes, under United States rules for US-origin information. As a member of the Defence industry security program we also carry obligations for people, premises and information systems. I describe these generally here because their detail belongs in contracts and with advisers. In practice they shape architecture: who may open a file, from which country a supplier may view it, and whether a particular cloud service is acceptable for that data at all. Our export-control officer and security officer decide classification and access; I design systems that make their answer the easy one to follow. I do not treat a contractual security condition as an obstacle to engineer around, and I ask for advice before assuming a rule.

I do not ask whether to automate welding or machining in general. I ask which joint or operation repeats often enough, with stable geometry and a procedure we can qualify, to justify a robot, and which work needs a qualified welder's judgement about fit-up, access and distortion. Naval structures contain both. The answer also depends on people. Adelaide has fewer experienced welders than our order book needs, and those we have carry knowledge no program contains. When we automate, I want experienced tradespeople to program and supervise the cell at a recognised rate, and apprentices to learn manual skills before they learn the pendant. A robot that leaves the plant dependent on one integrator's technician is a new fragility, whatever its arc-on time.

Our plants run about 140 programmable logic controllers across cranes, cutting tables, blast and paint lines and test rigs, from four generations of hardware. I keep one register of each controller, its program backup, its spare modules and the people able to support it. Replacement is planned by consequence and parts risk, not by age alone. A crane controller with no spare power supply moves ahead of a newer cutting table that uses a standard part. Each change is proven on a bench before it reaches the floor, with the maintenance electricians who will be called at night involved from the start. The register has become one of the more useful papers our board receives, because it turns obsolescence into dated and costed decisions rather than a general worry.