We speak to Commander Carl Cringle, Naval Nuclear Surface Warfare Officer in the US Navy, about the challenges he has faced managing critical repairs and technical documentation on a range of ships including the Navy’s fleet of $11bn aircraft carriers.
Can you give us a brief overview of your maintenance responsibilities within the Navy?
Sure. I’ve managed repairs ranging from emergent underway system failures – big problems that happen while ships are far out at sea – to maintenance work in nuclear dry dock. Repairs have included radar and navigation systems, combat systems and all naval engineering systems, such as diesel, gas turbine, steam, nuclear, and all associated auxiliary systems. And I’ve worked on destroyers, amphibious ships which carry Marines into land, and aircraft carriers. During one part of my career I worked for the carrier maintenance organization which manages 11 carriers, each one of which is an $11-billion vessel.
These are almost unimaginably sophisticated machines but the engineers working on them still depend on hard copy technical documentation…
That’s right and this is where you can start to run into some challenges which, if you could solve them, would drive enormous efficiencies.
“The problem is the discrepancies you encounter between installed products and the versions of the manuals you are using”
Can you give us an example?
Absolutely. In one instance we had a failure on a massive pump while out in the Arabian Gulf. This was a piece of machinery capable of pumping 4,500 gallons of water a minute and it had a great deal of equipment surrounding it; interferences which needed to be removed in order to get to the machinery itself. And, when we opened it up, we couldn’t reconcile what we were seeing with the hard copy technical manual.
Part of the problem is simply the limitations of hard copy manuals; you can’t always get to the level of granularity you need if there is a particularly small part which requires repair. But perhaps the bigger issue was the kind of discrepancies you sometimes encounter between the version of a product which is installed and the version of the manual you are using.
How does that problem arise?
Once a contractor is identified to supply a piece of equipment, such as that pump, they will supply pumps for all future ships for a period of time. As time passes it is discovered that certain pieces have inherent failures, so the contractor updates the product to make them more robust. But the technical manual may not be updated to reflect those newer units. Or perhaps three of the pumps on board are accurately depicted by the current manual but one pump is a newer or older version.
That’s a significant challenge in the Navy, and not just on the ships. I worked very closely with pilots on carriers and they reported the same issues in terms of maintenance on their jets. And it’s particularly challenging in deployed scenarios where you’re reliant on voice calls or emails to try and explain the issues back to State-side shipyards that source replacement parts.
Anecdotally I understand that similar challenges are rife within the commercial engineering and manufacturing sectors.
How does the Navy manage this issue?
Well, this is the DoD. Budget is less of an issue than in the commercial sector, while safety and operational effectiveness are obviously paramount. So it is understood, it is expected, and it’s accepted – and for good reason.
When you’re reliant on phone calls and email and hard copy documentation to communicate defects there is a risk that a replacement part gets incorrectly identified which could have catastrophic consequences if it is installed and the machine is run. So, to buy down that risk, quite often the decision will be taken to simply replace the entire machine. In this instance that entire pump was replaced because as a unit we knew it was correct, it was tested, and it worked. That’s great in terms of operational certainty but it carries tremendous cost.
A team has to fly out with this massive pump, you have to shut down an area of the ship, they have to install it, test it, flight operations are affected, and so on. The amount of money, time and human effort that goes into that repair is significant. And there’s clearly wastage. If we had a more effective means of visual communication, of interaction, of real-time sharing, the savings could be enormous.
But risk cannot be tolerated. Engineers back at HQ tend to have a zero risk mentality because they are culpable if they’re signing off on a repair. When you are in what we call an ‘austere environment’ – in the desert or out at sea – those HQ engineers are the decision makers because of the communications limitations and they will always buy down risk to ensure safety.
Based on your experience, what’s the answer?
The biggest friction point for me operationally getting these big repairs done was the level of discussion required between the different engineers. The worker, the supervisor, the approver. All that has to happen at length because we don’t have the ability to provide absolute precision, absolute clarity on the nature of the problem we’re trying to solve.
So, as I said, the ability to do real time visual collaboration would change the game. Something that lets everyone understand that the best possible engineering decisions are being taken at all times.
“The ability to do real time visual collaboration, and let everyone know the best decisions were being taken at all times, would change the game.”
And it’s true elsewhere in the process, not just in terms of service and maintenance. It’s true in the design and production stages. We have some brilliant engineers from a range of disciplines at one of the national labs developing capabilities for us, for example. We have mechanical engineers, electrical engineers, systems engineers, and so forth.
But the collaboration is not as effective as it could be because they are working their own pieces of the project somewhat in isolation. A systems engineer could design something that requires more power than the electrical engineer made available. Or both of those guys might design something that doesn’t fit in the space the mechanical engineer has developed. And they don’t find out until it’s too late that these things don’t work together. I’ve seen that many times on the production side.
So that same real-time visual collaboration would be just as effective there as it would be in addressing the inherent limitations of hard copy technical documentation.
Clearly there’s an opportunity to drive very high impact efficiencies…
An enormous opportunity. And I believe it applies across the board. From these massive pieces of equipment – ships that may look the same macroscopically but which are actually different in many nuanced ways – to commercial engineering and manufacturing scenarios. What’s needed is a solution which can enable the key decision makers to take that risk out of the equation by providing absolute clarity. That will free people and organizations to drive huge positive change.
.png)
