Recently. as part of the course in advanced submarining taught by Naval Submarine School, my class toured the Naval Undersea Warfare Center (NUWC) in Newport, Rhode Island. I was incredibly impressed with the technological capabilities that were demonstrated, state-of-the-art computer simulations, training scenarios, real time data links and more. But wait a minute. This was the Naval Undersea Warfare Center. Why was I so impressed with the technology there? I’m the one who goes in harm’s way. Perhaps I was impressed because I came from a 594 class boat with a 15 year old fire control system based on 25 year old processors. However, I ·think many of my fellow classmates were equally impressed. After all, from an operator stand point the latest version of BSY-1 isn’t much different from what we bad on the old TINOSA-fish.
At NUWC we were shown the amazing advances of the BSY -2 combat system, and the open architecture of the New Attack Submarine (NSSN). That’s great, but I have a more limited outlook. My understanding is a total of three BSY -2 boats (SEA WOLF class) will be built. Period. My classmates and I have around a 1 in 25 chance to serve on one. And the NSSN? Who knows? By some estimates, if we don’t get the NSSN down to $1.2 billion and do some creative financing, there may not be any. Consequently, I’m concerned with the fire control systems we’ve got now. Like Mk113 (still out there as one of my classmates recently found out), Mk117, Mk118, CCS Mk1, and even CCS Mk2. CCS Mk2 is supposed to provide most of the front end capability of BSY -2 for the boats we currently have. Unfortunately, the installation of the first new operator interface since the late ’70s bas been cancelled for a number of platforms due to cost concerns.
There are many brilliant people at NUWC working bard to provide solutions to the complex problem of submarine warfare. It is evident to me that these people fully understand, and in many cases are at the forefront of, the transformation of warfare. Even
now, battles are often decided by superior information processing and transfer. In this new paradigm, the most critical interface is the one between the organic data processor, in other words the human operator, and the electronic data processor. In testimony to the truth of this statement, NUWC labs are replete with menu driven software, multitasking operating systems and high resolution three dimensional color graphics. Numerous LANs connect the engineers and scientists to each other and the internet. Evidently the government can purchase the kind of computer equipment we need. It’s out there right now. It costs less than the systems we currently have.
Of course that is a naive point of view. As a submariner I fully understand the need for reliability. My life depends on it. This is the precious commodity that our present systems have. Sure, and there’s a bridge in Brooklyn which I’d love to sell you. The documented mean time between serious program errors for most combat systems out there is around one week. Not willing to be caught with their pants down, most boats shut down their fire control and sonar systems daily to reload the programs that allow them to see (hear) and fight. Even when the programs are running properly, many uncorrected errors still distract the crew from doing their jobs. Errors that move torpedo safety boundaries the wrong way, inhibit command shutdown of the weapon, and cause the torpedo to tum the wrong way after missing the target. Sure there are ways to get around these problems, but after many program upgrades why are they still there?
The worst problem with the Mk117, CCS Mk1, BSY-1 and even the CCS Mk2 systems are the user interfaces. On TINOSA, my first XO made the mistake of making me CO’s Tactical Display (COTE) operator. Suffice it to say I was one of the fire control system knob twiddlers. I don’t remember how many times I embarrassed myself by screwing up yet another periscope observation. Or trying to figure out which knob did what in towed array mode. Or mixing up fire control trackers that had different names in sonar. Fortunately, I subsequently became the time-frequency plotter and gave much meaningful input to the fire control party. Though I chafed at the ignominy of plotting those little dots in the prescribed colors, evaluation was intuitive.
Just thinking of the training time that could be saved and put toward more useful areas if we didn’t have to explain to every Submarine Officer Basic Course student, not to mention every returning SOAC student, what a bearing difference dot was and what Dmho and Cqts stood for. Is there some arcane reason more obvious names could not have been used in the displays, for instance 0/S speed and tgt AOB? I don’t know about anyone else but it took me about one hour in the lab to understand how to create a geoplot and obtain every important piece of information it could give. I’ll never forget how to do it. On the other hand, consider the procedure for detecting and analyzing a target zig in towed array mode. I supposedly learned that just a couple of months ago. That’s not to say Submarine School did not do the best job they possibly could. They did. You simply cannot effectively teach information that doesn’t make sense, that doesn’t logically flow from basic principles. We all have an I believe button; it’s just not connected to any memory cells.
With just a little training anybody can nail a contact solution on the geoplot and see the tactical situation at the same time. But don•t think I’m a retro-grouch that wants everything on paper. I simply want the intuitive elegance of those human interfaces. The process of setting up each plot and plotting the incoming information is a huge waste of time for the human operators who ought to be spending their time performing high level evaluation. The physical act of plotting requires additional people in an already cramped space. Furthermore, it adds inaccuracy and time delays. Consider an electronic format that would provide the data plotted on correctly scaled axes. A computer derived data averaging interval taking into account source, frequency, perceived bearing rate, and desired accuracy would not only provide more accurate bearings but give the operator some objective evidence as to Possible statistical errors. This would allow the human operator to concentrate on the critical task of evaluation and correlation with other data sources.
Already I can think of much information such a system could easily provide. Information that paper plotters would never have time to calculate. It could perform automatic curve fitting and ranging calculations, bad data screening, give meaningful threshold alerts, and calculate error statistics for all derived quantities. You may think all this additional data is extraneous to the problem. It’s not, and this is something a computer can do. The approach officer (AO) sets fire control range error based on input that comes from the time range plot through the fire control coordinator (FCC). This crucial quantity is often overlooked but
is a key to whether the target has time to evade and counter fire. Where does the time range plot get his error bars? From the fire control party. At best they are educated guesses with little or no statistical significance. Is this a training problem? No. Even if SUBSCOL taught statistical error analysis what operator would bother to learn it, much less do it while he or she were being attacked? I sure wouldn’t want such a geek in my fire control party.
Some may say that these capabilities already exist in the HP9020 and the TAC-3. They do, but with significant drawbacks. There are add-on devices. In most cases they cannot send any information to fire control and ultimately to the weapons. Often they are located nowhere near the AO or the FCC. Out of sight, out of mind. Remember, the human interface is crucial. Automatic data entry (ADE) is an absolute necessity. Without it, the operator must enter all the raw data. This is about as efficient as plotting dots. Many boats only got this modification recently for the old HP9020s. ADE for the TAC-3 is still being developed. Finally, the HP9020 is slow and there are not enough TAC-3s to go around.
Fortunately the solutions are being pursued vigorously at NUWC, Submarine Development Squadron Twelve and many other places. As I stated previously, however, slashed budgets are destroying even the best laid plans. CCS Mk2 with its planned Joint Operational Tactical Software and Submarine Fleet Mission Program Library (SFMPL) inter-operability is only making it to the fleet slowly. Why? It’s too expensive. Perhaps the emphasis should be on simplification, efficiency and cost reduction. I applaud the NUWC designed elastomeric torpedo ejection system. What a truly brilliant idea that could provide a quantum jump in submarine stealth while improving reliability and drastically reducing cost. Unfortunately, back in the fire control side, several managers were quite proud of the fact that the main programs of BSY-2 and SFMPL 5.0 used approximately two million lines of code. Somehow, I’m not sure that is an accomplishment of which I would be proud. We paid someone to write those 2 million lines of code. What’s the possibility there is an error somewhere in that jungle? If all that code improves the user interface, great. If not, get rid of it. I’m tired of programs that degrade over time and are fraught with errors that can’t be fixed.
My final question is really the first one all over again. Why does it take so long for existing technology to filter down to the operator? The technology the Submarine Force needs I use every day on my laptop. It’s the technology NUWC is using to support the Navy. The consensus at NUWC is that acquisition procedures are to blame. I don’t find that hard to believe. During the short time I spent working at Hughes Aircraft Radar Systems Group, I became familiar with the MILSPEC system. I was dumbfounded to find detailed specifications for the threads on tiny nuts and bolts that held components on circuit cards. In fact, there were specification for the types of ink allowed on the circuit cards. I know how much Hughes paid me to ensure these ridiculous specification were met. But let’s not forget the money spent on the federal employee or consultant who researched and wrote the specifications. In the end, who shelled out that money? The American public did, thinking they were buying the best equipment available for their military. Perhaps even more crucial, MILSPECs make new system design and manufacture move at the speed of a UYK-7, the laughable standard data processor on today’s nuclear submarine.
The government still procures military systems essentially the same way it did 20 years ago, back when American car manufacturers took a half decade to build a Pacer and everyone still chuckled at the Japanese. In the 1990s, the average time the Big Three take to go from concept to production is about three years and as everyone can attest the results are impressive. Superior data processing and information networks have made the U.S. economy the most competitive in the world. The government’s military acquisition policies have stifled this critical shift in the operation of our front line units. The procedural lag is most evident in areas where technology is changing most rapidly, i.e., information processing and transfer systems and human-computer interfaces. The very technologies that will determine the outcome of warfare in the future. Acquisition procedures for military platforms (specifically submarines) need to change now. The longer we wait, the more time and money are lost getting those crucial and ever improving human interfaces to our platforms. If we wait too long money and time may not be the only things we lose.
