The Navy has had "smart" systems on board its ships for a while—the Ticonderoga (CG-47) was designed to be operated without anyone in the engine room. What it needs are decision makers who understand the automated systems and operate them as such.
The smart ship campaign being waged by the U.S. Navy is being lauded as a way to reduce the sailor's workload through automation. In fact, it is just another sad testament to the lack of communication between the top brass and the sailors in the engine rooms. The present effort to replace working control systems with unengineered and poorly patched together controls (a.k.a. the smart ship) is an act of misinformed leadership.
We have had automation on many ships, and it has worked fairly well, despite the efforts of transient users who instead of understanding the way things work, have tried to make equipment function according to their own ideas of engineering. The Spruance (DD-963) class, for example, was designed as an automated platform, to operated with minimal crews. But only one naval officer, the commissioning chief engineer of the Briscoe (DD-977), in June 1978, ever actually operated the ship the way it was designed. He locked the doors to the engine rooms and sailed the ship with unmanned engine rooms.
The Oliver Hazard Perry (FFG-7), Kidd (DDG-993), and Ticonderoga (CG-47) classes were similarly designed, and also were intended to be operated without anyone in the engine rooms. Yet the Navy chose to rely more on tradition than on engineering science, and it manned the engine rooms of all of these automated ships. Millions of man-hours were wasted—and still are being wasted—having sailors standing in front of consoles that can shut down engines in microseconds and trigger safety control equipment faster than the human operator can assess the emerging problem. We send robots to Mars and trust our lives to the electronics that control a Boeing 767 on a transatlantic flight, but the surface Navy still is manning the engine rooms of automated ships.
Automation is a concept not well understood by most in the surface Navy. The Deyo (DD-989), like all Spruance-class ships, has automated controls. Recently, the ship was waiting at sea for an inspection team to perform the last phase of a test that would have completed a lengthy and expensive work-up. Of the thousand sensors on this ship, one—the sensing circuit for power turbine speed—had failed. A shipboard computer detected the problem, and the Propulsion Examining Board team refused to fly out to the ship. The ship had to come back to port. The Fleet Technical Support Center repaired the problem and the ship sailed twice more, and then it was tested and passed.
The fact that there are two speed-sensing circuits for each power turbine, and that one takes over when the other one fails, was of no technical importance. On inspection day, we expect a 15-20 year old ship to perform as if it were brand new. If one electronic circuit fails, then the ship fails. Instead of accepting the fact that things fail and understanding the engineering concept of redundant systems, we waste fuel and manpower and put wear and tear on the equipment. The smart ships will have at least twice as many sensors as the present control systems. Will there be zero tolerance for equipment failure on those ships during inspections? If so, will they ever pass?
We have too many surface Navy commands involved in maintenance, safety, and training of shipboard personnel, and because of it, the shipboard sailor is burdened with engineering processes that are void of product. And when real problems occur, it is too easy for these shore commands to pass the buck. The lack of technical leadership and responsibility is evident in recent events on board the Stump (DD-978) and the Comte de Grasse (DD-974). On these ships, electric power generation uses Allison 501K17 gas turbines that were rather new in 1953. Since then, the engine has been modified to the point that it has become a very capricious device to start and keep running. The electronic control panel is a poorly designed system. Together, these problems are causing us to have an engine removal rate of one engine every ten days, for 1995-1997.
Until recently, these failures usually damaged or destroyed an engine, but they had never caused any problems outside of the module. A recent modification, however, causes fuel to leak inside the secured engine. Thereafter, when the engine is started, there is an explosion. On both the Stump and the Comte de Grasse explosions literally blew the glass panes out of the inspection windows. Flames came shooting out of the modules and into the engine room space. We already have had cases of minor injuries.
At the waterfront, it seems as if the surface Navy has no funds, no time, and at times, not enough interest in finding a solution to this serious problem. On the smart ship Yorktown (CG-48), new controls were installed, but this accident-waiting-to-happen was not resolved.
The surface Navy has bought Osprey (MHC-51)-class coastal mine-hunting ships that have a control system that requires 30 minutes of diagnostic testing. This means that upon powering up, instead of performing its role as the sole means of starting, stopping, and controlling the engines that generate propulsion and electrical power, the control system spends 30 minutes deciding if it is healthy. Assume that this type of ship is working in a mine field. Assume also that it is being shelled from shore. A near miss most likely will cause the electronics to shut down, making the ship dead and dark in a mine field. Now, instead of bringing systems back on-line in a minute or two, the crew will have to wait 30 minutes while the electronics run diagnostics on themselves. Is there any better way to provide a target for the enemy?
We have various control systems on board the automated ships that perform self-diagnosis while simultaneously operating the shipboard equipment. The operator usually is warned of a malfunction by audio and visual means —similar to the "service engine" fault light in your car. Somehow, this idea that circuits can check themselves and announce a failure still is a mystery to the folks who dictate what happens in an engine room of a surface Navy ship. So, these valuable tools are not considered. Instead, we have man-hour-intensive programs that keep people on payroll, destroy working equipment, and usually make more work for the shipboard sailor. Some of these programs are: calibration, preventive maintenance, repeated drills that precede any inspection, and, of course, the actual inspections. For some reason, we find it necessary to send 20-30 engineers for a two-week period to perform inspections—called TARGET—on equipment that is not broken. We know that it is not broken, because the built-in tests do not detect any faults, and the commanders of these ships have no outstanding casualty reports on their equipment.
On the DD-963, DDG-993, and CG-47 classes, there is a way of controlling engines from the engine rooms (local) or in central control (remote). The electronics do not allow control to be transferred if there is a mismatch in command functions between the two consoles involved in the transfer. This electronic safety check prevents equipment from changing status during transfer as a result of a control system malfunction. This built-in check has worked very well for as long as we have had these ships, but instead of trusting the electronics, we waste 43 minutes for each transfer, doing litanies of useless visual checks. One of the checks is to see if the red cover on the emergency switches is up or down, as if that really could affect anything. This waste occurs because the people who wrote the transfer procedures did not fully understand the design of the control system.
We have ships with two propulsion shafts and two engines driving each shaft. We can start and put on-line the engines that drive those shafts in 40-50 seconds by depressing a button. Yet during sea details we use all four engines to achieve speeds of up to 15 knots—a speed easily achieved with only one engine on-line. We also use two tugboats, a harbor captain, and on some ships, 10-20 people in the pilothouse. Every engineering person is standing in front of equipment that he/she has no control of, because it is in remote. This goes on for hours at a time. Then when the ship is finally tied to a pier, it takes anywhere from 15 to 60 minutes to put a plank from the ship to terra firma.
We do ground searches on electronic control systems, trying to isolate the equipment from the conducting ship's hull. No one seems to understand that this is not a technically feasible or necessary thing to do. A warship is expected to do battle and sustain damage—flooding of spaces, grounding of wires, and other pesky things that happen in real life. When the Stark (FFG-31) sustained two missile hits, she suffered a series of grounds and alarms. The watch acknowledged the alarms, and there was no change of plant status for the equipment not involved with the damaged part of the ship. This happened while the ship was doing a full power run. Any doubts that the system would work even when grounded should have gone away then, but they did not. We still have a class advisory that makes sailors do ground checks on the FFG-7s. The new Arleigh Burke (DDG-51) and Supply (AOE-6) classes have similar instructions.
Recently, a DDG-51-class ship at Norfolk, Virginia, did a ground search after an off-ship inspection team told them to do it. The search resulted in cut ribbon cables. The ship lost 50% of its propulsion power because we could not control one of her shafts.
In actual battle, will we stop the ship to do a ground search? If not, then why do them in peacetime, and only when the ship is tied to a pier? Why waste the manpower, especially when there is no evidence that a ground search fixes any problem?
The DD-963, DDG-993, and CG-47 classes have the means to release CO2 into the engine module automatically after sensing a fire. This circuit has been responsible for the accidental releasing of CO2 inside the LM2500 modules at least once per year per engine per ship. This problem has been around since the control systems were being prototyped in 1973-74—I know, because I was responsible for the first inadvertent release. Two modifications to the release circuit have failed to resolve the problem. A suggested change to take away the automatic release was debated, then prototyped, and found to be a reliable solution. Yet U.S. Navy sailors still are being used to carry accidentally spent bottles of CO2, and their full replacements, from and into the engine rooms of these ships. Modification is on hold.
Millions of dollars have been wasted as the Naval Sea Systems Command (NavSea) acted as life-cycle manager or in-service engineers agency for the automated control systems. Money was wasted getting people to Washington to talk about problems. Meetings were held and decisions were made "by show of hands," regardless of the qualifications of the voters. Money was wasted in buying all of the forerunners to the present in-place Condition Assessment System. Money was wasted in trying to develop an engine controller to replace the poorly designed Free Standing Electronic Enclosure that comes with the LM2500 jet engine. Money was wasted putting illegible tech manuals in computer systems. Many efforts were made by NavSea to understand and rectify the problem, but usually each effort failed, most likely because the decision-making people had no working concept of electronic engineering.
After 20-25 years of working automated ships, NavSea has not yet devised a control system that is useful, easy to maintain, and reliable. Each new class of ship is a new experiment, and each time we must overcome the same problems that were in the old system, such as grounding. Because of the transient nature of the Navy, the service has no reliable bank of corporate knowledge.
Here is the latest example that should make it clear that things are not right here. In early 1975, it was discovered that the self-noise of the Spruance from central control was not acceptable. Cooling fans either were removed from some consoles or were replaced with fans that run at half the original speed—only in central control. The tech manuals were changed and all of the ships delivered to the Navy had slower fans in some consoles and faster fans in others. Now, 23 years later, while we are decommissioning some of these ships, and with not one reported case of heat-induced damage in the consoles in central control, the issue has come up that the fans are wrong. NavSea is studying this problem. Meanwhile, the module fires in the gas turbines on the DD-963 sooner or later will kill someone.
NavSea is not the only factor that has prevented automated ships from being operated as such. On the waterfront there is the Propulsion Examining Board (PEB). This agency has caused more damage to equipment in the engineering plants of ships than any other U.S. Navy effort. Because of its unchecked authority to pass or fail a ship, it has created a world where automation is totally misunderstood. Automation is the replacement of humans; the sailor standing in front of a console should have to decide only whether to bring up more engines or other equipment to fulfill the demands of the people on the bridge. Instead, PEB routinely goes on board ships and asks for drills that have no engineering value—for example, loss of throttle control, fire in the consoles, timing sequences for the lube and fuel oil automatic sequences, or even worse, simulating a wavering meter on a console and asking the operator to respond.
Automation can shut down an LM2500 in less than one microsecond. The human in front of the console should never have been put there to prevent damage, because he never has had even a chance to beat the control systems. Automation takes care of things. The only problem is that PEB does not really understand this. So, the sailor again comes into play doing routines that have little engineering value, because PEB has dictated them. The reason we have not lost control of an engine—exception being the GTGs —is not because of exams or training. It is because automation has worked. In a sense, we already have smart ships, but we do not have an engineering management system able to comprehend what the control systems do on these ships.
Now the surface Navy leadership is trying to convince us that things need to be improved, but instead of buying simpler and more manageable control systems, the Navy has bought the smart ship—which is not really all that smart. The Yorktown's failure in September 1997 was not as simple as reported. It took two days of pierside maintenance in Norfolk to resolve the problem, and there have been similar failures in the past when the ship has had to be towed into port. The problem in September 1997 was a simple case of bad data being put into the computers, which caused the computers to try to divide a number by zero. But if you understand computers, you know that a computer normally is immune to the character of the data that it processes. Your $2.95 calculator, for example, gives you a zero when you try to divide a number by zero, and does not stop executing the next set of instructions. It seems that the computers on the Yorktown were not designed to tolerate such a simple failure.
In addition, anyone designing equipment for combatant platforms should know to prevent damage from a failing device from propagating to others —this is called survivability. This is not the case on the smart ship, or so it seems. Using Windows NT, which is known to have some failure modes, on a warship is similar to hoping that luck will be in our favor. Installing a control system on a warship and resolving problems as the project progresses is a costly and naive process. Now, with the top people rotated off the smart ship project, it would be wise for the Navy to investigate this fiasco more fully. If we are going to put electronics in the engine rooms, we need managers who actually have worked as electronic engineers, or who are smart enough to admit their lack of knowledge and rely on those who do know electronic engineering—not transient civil servants or naval officers with degrees in mechanical or naval engineering.
We have had smart systems on board surface ships for a while; what we need are decision makers who understand them and use that information to better the situation of the sailors in the engine rooms of those ships.
Mr. DiGiorgio has worked as as engineer since 1967, beginning with the guidance and control division of Litton. A tech rep in Vietnam for almost three years, he worked on inertial and bombing systems on various aircraft for the U.S. Air Force, Marine Corps, and Army. In 1972, he began to work on the engineering plant control system for the Spruance (DD-963) class, and in 1980, he transferred to civil service, working for the Atlantic Fleet Technical Support Center. For the past 26 years, he has resolved problems on most automated control systems on board U.S. Navy ships.
The Smart Ship Is Not the Answer
By Anthony DiGiorgio