When Computers Went to Sea: Technicians of the Digital Navy


[BACKGROUND: The Naval Tactical Data System was a remarkably successful project at the beginning of the shipboard digital revolution. Currently, the AEGIS Combat System and its successors embody the latest in technology and complex computer programs. In the case of NTDS as installed on Biddle, a handful of naval leaders had the foresight to conceive a new way to manage large numbers of much faster hostile targets that could threaten the fleet. Next, their new concept was brilliantly designed then implemented in the form of the Naval Tactical Data System, which incorporated a large group of disparate weapons, sensors, computers, and technologies into an integrated package. Finally, in order to remain an effective combat system, NTDS had to improve through both the introduction of new technologies and by correcting problems found in the fleet. This chapter tells how Biddle was at a vanguard position in the latter effort.]

David Johnson

The digital revolution that produced NTDS was more than the introduction of new technology and computer programs into U.S. Navy ships. It was also supported and enhanced on ships at sea by technicians of all ratings from within the combat system. These technicians had to deal with all the things not foreseen by the engineers who developed NTDS, many examples of which are provided later in the chapter.

Many of the original NTDS technicians had experience with systems from the WW II and Korean eras, complete with vacuum tubes and limited logistics or maintenance support. The digital revolution required new thinking to adapt to new technology, maintenance, and operating methods. In more recent years, what was the latest technology for Biddle-era ships is now old, outmoded, and replaced by electronic innovations such as high-capacity computers embedded in major equipment to wide-band fiber-optic networks. These, too, are being mastered by the technicians of the day just as the complexities of the initial digital revolution were mastered by the pioneer technicians of that long-ago time.

The full story of how NTDS began and was developed and deployed is well told in David L. Boslaugh’s book, When Computers Went to Sea. However, NTDS technicians were at the center of the process because NTDS was the major digital component introducing the new technology. This chapter is derived from Biddle’s early years, including pre-commissioning and shakedown, told from the perspective of the Data System Technicians. It is, however, intended to typify the experiences of technicians on sister ships all the follow-on crews that sailed on these great ships of the Belknap Class.

It should be recognized that the digital revolution did not just start with Biddle and her sister ships. Indeed, there were already a number of ships equipped with NTDS at sea. There were also special-purpose ships such as ocean-going survey ships with various digital systems, albeit generally older technology such as rotating drums for storage of data. Some shore stations also existed that used this digital technology for intelligence, logistics, and Command functions.

When NTDS was declared a real program, the call went out for NTDS technician candidates to man the first three service-test ships. This was several years before the Mare Island Combat System Maintenance Training Center (CSMTC) was opened and the Data System Technician rating and its training formally established. Fortunately, many of the technicians who responded had some level of digital experience, however limited, which made them valuable assets in the initial phases of the NTDS technical-support task. Before Mare Island, these first NTDS technicians, keeping their existing rating badges, were selected from throughout the Fleet. These ratings included virtually every technical and some operational ratings, and were cycled through factory schools to learn maintenance and operation of computers and peripheral devices, display consoles and associated units, data transmission systems, and even NTDS computer program fundamentals.

When the NTDS school was established at Mare Island in 1962, before the full-blown CSMTC was commissioned, many of these technicians formed the nucleus of the original staff. They were augmented by other senior technicians recruited from all Navy activities, who were experienced and well-trained at various advanced technical or “B” schools. They were sent to Computer Basics at Great Lakes, and then to the famous basic computer programming school at San Diego fondly called “Sink U” after Captain Robert Sink, who was in charge. This writer was fortunate to be in the latter group of NTDS recruits as an Electronics Technician. However, the whole prospective staff spent several months together at the old Naval Electronics Laboratory Center (NELC), San Diego before transiting to Mare Island and creation of the NTDS school. This assemblage of technical experts had also been to the excellent Navy Instructor Training School. Under the leadership of the officers who were responsible for fulfilling Navy training requirements, they set about creating a training environment that stressed both classroom fundamentals and hands-on equipment maintenance unique to the digital world.

An important adjunct to the usual technician training approach was an NTDS Systems Technician course. This was intended to support the new technician category that augmented the three basic NTDS technician ratings: Computer, Display, and Data Transmission. The Systems Technician course was unique in that it covered all the NTDS equipment, selected NTDS computer programs, interfaces with other subsystems, and basic shipboard operations. In addition, it also stressed a key part of the NTDS maintenance philosophy, computerized system testing and alignment. This led to a system-level manning and training approach that was to be significant for the new Belknap class of DLGs then being built.

These ships introduced the revolutionary NTDS with WDS MK 11, which brought the Missile and Gun systems directly into electrical integration with NTDS. By way of the NTDS computer programs, the tactical application of these weapon systems was also controlled by decision-makers and other operators connected by the digital environment. And, of initial concern to some traditionalist at the Command level, the NTDS data links connected all ships into a larger operational environment that made system maintenance even more demanding. These developments are discussed later on to show how important they were to Biddle’s success (and the success of sister ships) in shaking out the bugs from the new systems, interfacing devices, and computer programs.

The Bureau of Ships (BUSHIPS), later the Naval Ships Command (NAVSHIPS), that created NTDS had no way of knowing in advance just what would be required at sea to handle the myriad of possible failures, deficiencies, and new requirements that would emerge. That’s why Headquarters had the foresight to create technicians and Maintenance Officers who could deal with the unexpected and turn Service Test ships into mature and reliable deploying assets.

Of significant importance to ships at sea, especially in combat situations, is the role of electrical power, cooling water, heating and air conditioning, Electronics Casualty Control, and standard Damage Control. Most of these considerations were not completely modeled and evaluated during NTDS development, since they were not part of the engineering process at the time. These became the focus of much of Biddle’s operational and technical work, starting with the realization during Refresher Training at Guantanamo Bay that NTDS was not just another suite of electronics equipment. It took a while for the trainers to realize that damage control and electronics casualty-control procedures and training should be modified to really challenge these ships. Biddle and other ships worked hard to refine these important survival tools. The lasting effect of Biddle’s experiences on the Navy’s improvement in these areas from the OPNAV and NAVSHIPS perspective will be described.

To fully appreciate the experiences documented herein you have to envision not only just NTDS and its computers, but also the then-emerging Combat System entity as the collection of subsystems is now generally defined. That definition represents transition from basically stand-alone systems to the federation of these systems into a functional entity with enhanced mission capability and survivability as driving concern. With federation and integration achieved by a variety of interface techniques, the combat system for a number of years was not a well-identified composite entity with well-integrated subsystems for a number of years.
Most subsystems, some of which were analog and mechanical, were still independent entities for maintenance and some operations. Interfaces were often limited in their information-transfer capability, such as single-wire circuits carrying non-digital single-function signals. Computers at sea, capable of communicating with each other and many other equipments, made possible extensive and rapid changes in definitions and relationships between systems. However, many effective non-digital interfaces from legacy systems were retained by adapting them to the digital systems via converters of various types.

The evolution of interfaces is a major component of the full realization of advantages provided by digital systems and their designed-in electrical and functional relationships. Part of the challenge during these early years of the digital revolution for the technicians of all ratings was to keep those interfaces working correctly. This included recognizing failures and misalignments, and even on occasion identification of technical deficiencies in equipment and computer programs that sometimes could be corrected on board by experienced personnel.

Fortunately, there were dedicated technical and computer-program support activities established ashore to provide direct support to ships as problems and suggested improvements were reported via the several feed-back systems.

Lessons learned during those early years of NTDS/WDS maturation soon found their way into ship-class improvements and design requirements for new ships. These applied lessons also included documentation, training, and logistics, all things of great interest to shipboard technicians.

The following examples of somewhat anecdotal (but well-documented at the time) shipboard technician experiences are provided to show the range of accomplishments of the outstanding technicians who kept systems operating. These stories represent a small subset of those experienced on all ships, including Biddle, over the life span of these great ships. It is hoped that any Navy technician can relate to most of these situations in one way or another, and that the technicians who participated in these events may remember the details with pride.

Fundamentals of Success

NTDS training at Mare Island combined the knowledge and experience of staff and factory training, and was not class-specific except as needed to use available training documentation. The curriculum stressed integration with other systems and working across interfaces, and was one of the fundamental aspects of why NTDS technicians succeeded. Eventually, the new NTDS/WDS equipment suite and computer programs were being tested at the Mare Island Test Site whose facilities were also part of the Schools Command facility. As staff and students became available, especially those headed for one of the new DLG-28 Class ships, they were used to support test and evaluation work being done. This was a great advantage to the core DS staff and future ship’s technicians, since they were involved in various aspects of NTDS systems and training development that increased their individual knowledge and skills.

The practice of staff involvement in NTDS engineering work started before Mare Island was in business, as the staff gathered at NELC, San Diego for training in basic computer programming, and hands-on experience with NTDS equipment. Most of this select group immediately got into the flow of NTDS development and evaluation that was still being done at NELC. This gave them a broad perspective about NTDS and its relationships with other ship systems. It was because of this perspective that on Biddle, as on most NTDS ships at the time, we viewed NTDS as the center of the ship universe, with all else sort of peripheral to it. This was done to assure that the forward-looking concept of this radical digital world was somewhat isolated from the traditional systems and concepts that were still in place around the ship.

NTDS was the new and unproven component of the combat system. Its newly-developed WDS MK 11 replaced a lot of analog fire-control equipment (and moved the firing key to BUSHIPS, per David Boslaugh). NTDS technicians knew that they had a big job to prove their competence and NTDS reliability. A Planned Maintenance System (PMS) package and its integrated maintenance approach existed, and provided a good foundation for refinement of digital-system maintenance as a function of lessons learned in the real world at sea. In addition, we were closely associated with all other technicians, with whom we developed common interests because of the close coupling created by digital and analog interfaces that bound our systems together. Automated system maintenance and alignment testing was already a proven concept, was part of the PMS packages for NTDS and some weapon systems, and continued to be refined and expanded as experience allowed. Automated system maintenance and alignment testing, already a proven concept, was part of the PMS package and continued to be refined and expanded.

As key NTDS technicians reported aboard, Biddle’s expressed maintenance philosophy was informally defined to allow most problems being experienced by other systems and not yet resolved to be provisionally attributed to NTDS. This decreased to a large extent the uncertainty about cause versus effect, since little about NTDS was known by other ratings. The DSs would then set about isolating the problem source and, if not an NTDS problem, help others in the Combat System and Hull, Mechanical and Electrical (HM&E) organizations to find and fix it. Sometimes it was an operator’s problem due to lack of experience with specific console or ancillary-equipment particulars.

This philosophy minimized finger-pointing, centralized problem reporting and tracking, and made the DSs into the experts on which NTDS reliability (and thus mission integrity) often relied. In addition, the basic rule for DSs was that if an operator says there is a problem, assume there is a problem and stand at his side until we got a good understanding of the situation. This sometimes resulted in additional training for operators, some of whom were still in the initial stages of mastering the NTDS and WDS MK 11 console modes and the associated operational requirements.

There were some awkward situations early on because, understandably, some ship’s engineering-plant personnel had limited understanding of the unfamiliar demands NTDS was placing on ship services. Electrical and cooling services had seldom been challenged before by the requirements of such sophisticated (and sensitive) equipment. However, other systems such as the AN/SPS-48 Radar and the high-power AN/SQS-26 Sonar were also beginning to place demands similar to those of NTDS, adding to the complexity of supporting this new confederation of high-tech systems.

The underlying doctrine of the NTDS leadership was dynamic support of Command requirements, the operators, the interfaced or federated systems, and thus the ship’s missions. To assure seamless and consistent support to all users of NTDS/WDS facilities, the DSs were the designated experts for computer program loading and system reconfiguration for operation, testing, or training. This approach also sharpened the abilities of the DS team for rapid fault recognition and isolation, working in conjunction with the experts on the other side of the interfaces or in the functional operator organization. Constant practice at computer reloading and system reconfiguration under operational constraints proved to be invaluable in the demanding Tonkin Gulf environment.

The centralized maintenance approach (actually, centralized technical operations in support of tactical operations) was also practiced to some extent on many of the other NTDS/WDS MK 11 ships due to the training established at Mare Island for Missile Fire Control and NTDS system technicians. That in itself is a story, not much remembered by most. However, the concept of centralized casualty reporting and response coordination is now a basic part of ships operations under current Navy maintenance and readiness-management guidelines, and will be discussed below.

Biddle experiences, as well as those of the other ships of the class, provided guidance for work done in all phases of ship systems development and crew training. Many of those experiences were experiments permitted by Command and NTDS officers to see if they improved readiness-management concepts and practices as combat-system definitions and management began to evolve.

Preparing For NTDS/WDS System-Level Integrated Maintenance

Weapon systems have always had rigorous daily operability testing as a PMS requirement to assure operational readiness and to detect any degradation of performance. NTDS/WDS MK 11 provided the computers to run the Daily System Operability Test (DSOT) in digital form (DDSOT). A key test device was the Dynamic Synchro Data Source (DSDS) as described in David Boslaugh’s book, Chapter 8. The DSDS was developed to convert digital target designation data from NTDS computers running the DDSOT program to synchro signals for designation of test targets to the fire control systems. Repeat-back sampling of synchro signal was provided by the NTDS Keyset Central converter. These tests complemented many other automated tests provided as part of the Ship Operational Readiness Test (SORT) package.

As a couple of the DLG-28-class ships were nearing completion, it was determined at Mare Island that the only training for crew members in the new WDS MK 11 and automated testing was being done at Bath by Wainwright experts such as DSC Michael Snodgrass. The NTDS/WDS training plan was modified to have a Terrier Missile System chief and an NTDS System chief cross-trained at Mare Island in concepts of each other’s systems. This was followed by time together in the Test Site running the various tests to provide in-depth knowledge of the capabilities and use of the SORT package. It also covered the new digital test system hardware and software, and how to properly interpret dynamic indications and printouts of results. Setup of systems and switchboards was critical, and restoration after testing to a normal configuration quickly and correctly was a necessity in the at-sea environment. By running these tests in a laboratory environment at Mare Island, many of which were new and complex, and responding to a range of problem situations, the objective of training a well-functioning team for each ship was met.

So, in consultation with Wainwright experts and others, the NTDS Systems Technician staff developed a 7-week course. Four weeks were spent cross-training selected system FTs and DSs in fundamentals of each other’s system. Three weeks were devoted to joint laboratory system testing and familiarization with integrated maintenance practices. Most ships eventually got their teams, including Biddle. The concept worked fine, and contributed to the success of the WDS MK 11 and to the value of well managed interface testing and maintenance.

An interesting sidelight to the DDSOT computer program was its documentation. Developed by one of the Navy laboratories specializing in weapon systems, the DDSOT computer program itself was developed by an engineer who combined system knowledge with programming skill. However, the primary documentation at delivery time was just hard copy listing of the program’s instructions and data design, but a flow chart was also required. So, a staff DSC knowledgeable about both the DDSOT and computer program documentation was assigned to assist its programmer with developing the flow charts. This was done expeditiously by the two sitting at a table, and as the programmer read the listing and described the implemented functions, the DSC drew the equivalent flow charts. The Navy learned to better define computer program deliverables, and the DSC learned much useful information that he took to his ship.

Biddle played a major role at Bath Iron Works during final construction in supporting completion of the first NTDS System Manual, another story worth repeating. As NTDS with WDS MK 11 gained visibility and its tight integration with the gun and missile systems were noted, there was concern that NTDS documentation was not as complete at the system level as was that for weapon systems. Accordingly, several staff instructors from the NTDS System course at Mare Island were called in one Saturday for a meeting with Lieutenant Commander Joe Randolph from NTDS headquarters at BUSHIPS. The result was assignment of these instructors on a collateral-duty basis to develop a comprehensive NTDS system manual covering a wide range of subjects about hardware, software, interfaces, operation, testing, routine maintenance, performance monitoring, fault isolation, and impact assessment of faults, however detected. After months of intensive work, a draft manual was completed. Since Biddle’s System DS was on the development team, it was decided that shipboard assessment and completion of certain subject areas could be done upon arrival in Bath. This was done on an after-hours basis, and the initial manual was completed with a proper shipboard orientation. It proved to be a suitable complement to other shipboard documentation of the time, such as the Weapon System OPs and the Ship’s Information Book. Over time, the manual was redesigned to accommodate additional ship classes and differences within each class and turned over to contractors for production.

The Bureau of Ships provided as part of the SORT package a modified tactical program with extensive data extraction capabilities to allow capture of critical data during missile shoots and other exercises, or for use in training. Data reduction programs were run off-line to provide technical and operational time-line and statistical details and thus an evaluation of total system performance. These techniques have for some time been incorporated into combat system design for on-line use and real-time system evaluation.

Technician Networking for Mutual Support

Since the digital revolution at sea was just gathering momentum during Biddle’s early years, much of the work required by the DSs had few precedents to use as guidance. However, there was at the time a close relationship between many of the original DSs (who were converted from a number of other technical ratings) and their Weapon System counterparts from Mare Island. These were personnel who had gone to the DLG-28-class ships with WDS MK 11 prior to DLG-26 and 27 being retrofit. This created a network of experienced technicians that was frequently used to exchange opinions and recommendations from sister ships on problems, ideas, and lessons learned.

Dealing with the Unexpected

The at-sea success of NTDS/WDS MK 11 and related systems was not always the result of designed-in features. As will be related below, making complex things work together on a ship, along with all the other things happening on a ship at sea, often became the job of on-scene technicians, operators, and leaders. A respected NAVSEA engineer officer with responsibility for combat system design was heard to remark that systems are frequently procured and bolted down on ships and left up to the crews to refine maintenance and operation in the at-sea environment. Biddle and others worked hard at identifying and fixing those things not otherwise accounted for. Over time, this provided lessons learned for future ship projects so as to assure consideration of as many things as possible during design, construction, and testing.

WDS MK 11 was as revolutionary within the analog missile and gun community as was NTDS itself within the traditional Operations community. Commander Joe Randolph of BUSHIPS was way ahead of most of us with the digital WDS concept and its implementation (see David Boslaugh’s book, Chapter 8). Biddle, among other ships, helped smooth the transition process and provided solid evidence that the digital approach to weapon control was effectively supported by the DS rating.

The initial evidence was developed during Biddle’s PSA period in Boston in 1967. Concern within the Weapons community in Washington surfaced about how effective would be maintenance of the WDS MK 11 equipment if assigned to the DS rating. Equipment included two standard NTDS consoles used by WDS operators and associated WDS hardware such as the Fire Control Data Converter (FCDC) and the Weapon Control Panel (WCP). Switchboards were also involved, as was another NTDS console devoted to precision target tracking using the SPS-48 radar. One of the two NTDS Height/Size consoles was also part of the precision tracking ensemble.
It was thus recommended by the Weapons office that separate parts lists and PMS actions should be developed for those devices within the Weapons ratings. Biddle’s NTDS Officer and his System DS were assigned to the job. What resulted was a report that established clearly the commonality of consoles with other NTDS consoles, availability of trained and capable DSs with supporting documentation, and spare parts already within the NTDS logistics system. Accordingly, the decision was taken to leave WDS MK 11 within the NTDS area of responsibility. We quickly learned to work effectively with our counterparts in the Weapons systems, and on most ships this approach was satisfactory.

A very difficult problem involved the ship’s 400 Hz 100KW generators that persisted through shakedown. The SPS-48 radar and NTDS were routinely set up by the Electrical Officer to run off the same generator so that there would always be a stand-by generator available. Unfortunately, from time to time the NTDS consoles would startle operators by having the symbol displays just fly apart for a second, and then return to normal. We eventually found, after many hours of observation, that the radar transmitter would occasionally trip off-line (cross bar), which created an uncontained power surge at the generator felt by NTDS and its sensitive equipment. Voltage regulators of the time were not able to respond fast enough to prevent the surge from reaching consoles. After some negotiation, NTDS and the SPS-48 radar were put on separate generators and problems did not recur. This characteristic of the display equipment, among other power-related weaknesses, was eventually designed out of future versions of NTDS equipment. Also, solid-state converters have now replaced generators and provide built-in voltage regulation.

Some serious lessons were learned about how use of the wrong materials could result in major problems in the high-humidity environment of the Tonkin Gulf. As radar video distribution requirements increased during installation of new systems, several high-power video amplifiers were installed during the first PSA to improve signals to all video users. Lots of radar switchboard video cable connections were either remade or newly-made, using standard soldering techniques. Early in the 1968 deployment, the Display techs found recurring problems with some of the connectors, resulting in video failure out of the switchboards. Coincidentally, they also found that the video amplifiers seemed to be cooking the plastic-covered leads from the small amplifier vacuum tubes, which were soldered, to the associated circuit boards. The leads would then short, requiring a new amplifier tube to be soldered in. These problems confounded our collective wisdom until one of the Display techs concluded that acid-core solder was used during PSA when radar switchboards were reconnected to the video amplifiers and other users. After redoing all such known connections, that problem was resolved.

However, the video amps continued to cook leads. We then noticed that these problems occurred mostly when humidity got high in the unmanned but air-conditioned equipment room, not unusual at that time and was the same situation which had apparently also surfaced the switchboard connector problem. Some of the failed vacuum tubes with their charred plastic-covered leads were shipped to Naval Ship Engineering Center, Norfolk Division (NAVSECNORDIV), the BUSHIPS equipment technical support activity. A reply was shortly received: the manufacturer had failed to use inert tubing on the leads. In the occasional humid environment the reaction of plastic out-gassing and moisture formed a corrosive acid sufficient to eventually eat away the insulating plastic coating which allowed the wire leads to short out. Replacement tubes with properly insulated leads were received and another small but critical problem solved. The humidity problem was subsequently reduced when the Display techs began to check the external heat exchanger that cooled the space and notified the responsible “A” (Auxiliary machinery repair) gang, which supported equipment outside of the propulsion plant, of any problem, however slight.

During the early months of Biddle’s active life, Terrier Standard Missiles in the Surface mode on WDS MK 11 ships were noted for missing their targets. After analysis by a team of Missile engineers, the team arrived on Biddle one Friday afternoon to test for a suspected possible cause. This test required services of Biddle’s programmer and system technician, because it was thought that the problem was due to a capability of the NTDS/WDS MK 11 computer software to actually change the mode of a missile on the launcher rail. This was thought to happen on orders from the NTDS computer after the Surface mode was set up by the Fire Control Computer in control of the launcher and its missile. However, due to the in-depth knowledge of Biddle’s personnel about how the NTDS program worked, and with the capability to demonstrate that remote mode changes were locked out on assignment of the launcher to the FCS computer, we got a clean bill of health. The problem was later found to be in the missile itself. This turned out to be a useful exercise for Biddle, because she gained another level of credibility in the WDS community.

Computers, Peripherals, and Related Systems

The Computer Room technicians were responsible for the very key elements of the digital system. They also had a tough job because the computers themselves were so reliable that little need for repairs existed. This was good for the system, but provided limited practice for these experts. However, they were kept busy monitoring operations around the clock and doing required PMS checks. Emphasis was placed on over-maintaining the Magnetic Tape Unit (MTU), however, which was the only mass data storage and retrieval device available to NTDS at the time. This meant assuring detailed attention to the performance of the servo units that drove the heavy magnetic tape reels, and maintaining read/write head condition and alignment to tight tolerances.

Occasionally a challenging problem would occur that gave the computer technicians a challenge. For example, NTDS had two 5KW 400Hz generators for computer primary power to assure more close regulation of this critical service that was available from ship’s 400 Hz power. One day in the Tonkin Gulf one of the generators developed a fairly severe vibration. This unit had always had a slight tremor, but experts had not found sufficient reason to remove it. Unfortunately, Biddle was on her own this time, and a major effort was undertaken to remove the rotor and muscle it down to the machine shop. After being trued up on a lathe by a skilled machinist, it was muscled back and reinstalled. After testing, the generator worked properly, but retained a slight vibration for the duration of the deployment. Fortunately, modern power technology prevents that sort of burden on the digital maintainers.

While the FCDC was a marvel of electronic design and contained complex control and converter circuitry, the interfaces with Missile and Gun computers tended to be unstable and difficult to align. Long transmission cables contributed, requiring precise signal phase measurements and feedback adjustments. However, thanks to the technician network, DSC Snodgrass on Wainwright had solved the problem in conjunction with Fire Control technicians, and word got around before the resulting ORDALT was distributed. With permission of Command, Biddle’s DSs and FTs installed a set of precise input amplifiers in the MK 119 fire-control computer to accept and stabilize FCFDC analog output signals. FCDC alignment procedures were modified as required. The same fix was applied to the FCDC’sGun System computer channel, too. This emphasized the need for (and suggested the advantages of) “digitizing at the source” as was eventually possible when digital designation and repeat-back capabilities were provided by digital fire-control computers.

The FCDC was another equipment lacking well-done parts listings. The Computer Room techs decided to take on the task of producing improved listings while spending long hours on watch in WESTPAC. Every FCDC part was evaluated, using the technical manual, and all available logistics information verified. The resulting parts list was neatly typed and submitted to NAVSECNORDIV for reproduction and distribution to the other seven ships with the FCDC. However, documentation rules dictated that such material must be produced in sufficient quantity for copies to each possible interested activity. The required quantities exceeded funds available to do the job. However, technician persistence eventually saw most ships provided with a copy informally.

This interest in complete parts lists was created by an incident involving the new CP-1218 digital computer installed with the Beacon Video Processor at PSA. Spare parts were not loaded out at the time of computer installation, for some reason now forgotten. At the time, parts in the computers were marked only with proprietary codes from the manufacturer, so it was difficult to identify components such as transistors by standard electronics designators. As luck would have it, a transistor failed in the CP-1218 computer, and could not be typed or cross-referenced with available information. The computer tech used a storage-trace-storage oscilloscope to map out the performance curves of another transistor removed from the computer, and then found a transistor in Supply that closely matched those parameters. Fortunately, spare parts and a parts listing soon showed up. Technicians like that are assets, indeed.

The wisdom of over-maintaining the MTU was proven when Biddle and other ships were provided with a new NTDS computer program. To offset the limited computer memory, and since there was not yet available a way to expand memory, the Fleet Computer Programming Center at Dam Neck had developed a way to provide the additional tactical functions needed in the changing threat environment of the Tonkin Gulf. This method, called Dynamic Modular Replacement, required the program tape with the dynamic modules to reside on the MTU all the time, with the MTU always ready to respond to load commands. When a particular tactical function not already in memory was required by CIC, an operator entered the specified code which the computer used to make room in memory for the new function (or sometimes multiple functions) to be read in from the MTU. The required function on tape was read in and activated. There was no room for error by either an operator or equipment, and response time was critical for such functions as engagement. After several months of use, and to Biddle’s relief, this capability was replaced by standard programs. The Computer Room technicians never failed to assure a full-up MTU all the time. Today, of course, huge memories and high-tech mass storage devices provide sufficient capability to perform all required tasks without resorting to the DMR method.

Because of its good working relationship with the NAVSECNORDIV engineers, Biddle was often the test bed for field changes and other system improvements. One change installed just before deploying to WESTPAC was a capability to run both NTDS tactical computers from a single Real Time Clock (RTC). Since each computer had an RTC, switches were provided to allow selection of one or the other for both computers. This was installed as a reliability backup capability, but it resulted in a long-term improvement to CIC operations. It was a common situation in the early days of Tonkin Gulf operations for ships to report that displayed tracks would sometimes backup some small distance, and then continue normal movement. This was shown to be caused by the track updates done by one computer to be out of time correspondence with another computer receiving the tracks for display. This didn’t happen on Biddle because the computer RTCs were always in correspondence when a single clock was selected. The RTC field change was expedited to all ships, and the programs also modified to exchange time across the intercomputer interface. Today’s combat systems use a central time base, distributed to all computers and other users of a Real Time Clock.

The Computer techs met their match one day when an intermittent memory problem began to occur in one CP-642 computer. After standard trouble-shooting over several days had failed, unconventional tests of memory were tried. Again, no problems found. In desperation, a senior technician took a flashlight and inspected every connector and attachment such as fuse holders feeding the computer. A very slight discoloration around the fuse holder of one phase of the 3-phase 400 Hz input from the 5KW generator was found. It was a shot in the dark, but experience had shown that this was not a normal condition. The fuse holder was replaced and the intermittent memory problem never recurred. Good technicians always look for the indications everyone else has missed. That, plus good luck, another technician tool.

The WDS MK ll unit that controlled the launcher, showed computer loading and firing recommendations, and contained the firing key was the Weapon Control Panel (WCP). It was very reliable, containing both digital and analog electronics, since it talked to the NTDS/WDS computer and also to the launcher and the fire-control computer. It also contained dozens of small indicators containing low-wattage grain-of-wheat bulbs. When the WCP was on and in the operate mode, all indicators were on, they would flash or change brightness as an engagement was in progress. Unfortunately, the WCP was required to be activated for long periods of time when in the combat zone, and ran through the small bulbs in great quantity. Biddle technicians developed a simple field change that provided a front-panel switch that reduced illumination to a standby level without affecting the tactical state of the unit. When action was expected, the switch was operated to bring the illumination level back to normal. This change reduced the usage of bulbs down to a few per month. This is another example of how engineering did not consider the full scope of the operational environment, and how the sailors fixed it.

The Ship’s Programmer

During the early years of DLG operations with NTDS, each ship had a Ship’s Programmer billet that was to be filled by a qualified programmer, officer or enlisted. This was already customary on larger ships such as CGs and CVs. On Biddle, the NTDS System Chief was assigned to that billet as a collateral duty. Close cooperation with the Computer Room technicians and CIC personnel were key components of analyzing and possibly fixing program problems, using any available time slice to poke and peak at the offending program code. Having both equipment and program responsibilities made it possible for the Chief to better integrate all phases of NTDS maintenance and problem definition. It also required close coordination with Command and the NTDS Maintenance Officer to assure no impact on rules, regulations, and mission requirements. During those days, NTDS computer programs were not always completely debugged when delivered. This lack caused many system problems to be difficult to trace to the actual source, hardware or software or, in some cases, operator mistakes. It also meant that, as is sometimes now the case, the ship became the Beta tester for the programming activity. Much has been written about this situation, but Biddle managed it fairly well.

Ships in general provided a steady stream of trouble reports to the Fleet Programming Centers. As did some other ships, Biddle also usually provided with her reports a program fix, tested and often installed. We were always careful to fully document each shipboard change made, and over time had a local patch library that was used to update new programs as delivered on station. Biddle’s programs were controlled to avoid unnecessary bit-fiddling, with the result that more than once sister ships asked for copies of our tactical programs because they were solid and mostly debugged. For some reason, even though all our software fixes were Command approved, documented, tested, and submitted to FCPC for formal incorporation as approved, programs continued to be delivered while containing some of the same problems that had been previously reported.

Biddle was a regular contributor to the NTDS Newsletter produced by the Fleet Computer Programming Center, Dam Neck. The Newsletter allowed the sharing of Biddle experiences in hardware and software corrections and maintenance with other NTDS ships. Other ships did the same, which benefited all ships, the programming centers, and schools. The newsletter became part of the de facto technician network. Biddle also provided regular reports on improved maintenance checks worked out by NTDS technicians to complement standard PMS feedbacks.

Biddle’s objective in WESTPAC was to assure continuous combat system availability around the clock. It had been observed that the war usually stopped about 2400 to allow maintenance and other non-tactical tasks to be performed. Someone observed that some day the war might not stop so conveniently. So, it was decided that Biddle’s programmer would develop some simple test functions embedded in the tactical programs to support on-line use by operator function code entry. This very simple, end-around test software verified alignment of the WDS MK 11 designation/repeat-back circuits and control/status circuits when unable to run DDSOT. This concept was expanded over time to cover some other systems and equipment. In addition, the limited built-NTDS in program monitoring and fault detection logic was expanded to provide new status information as the system operated. As new computers and additional memory have become available, this concept has expanded to cover virtually all ship systems, including the engineering plant.

Data Link Operations and Maintenance

The initial NTDS configurations included a huge amount of data communications equipment that constituted the data links. Link 11 included computer program functions, a terminal set (the AN/SSQ-29 modem), a communications system (the AN/SRC -16), and three dedicated topside antennas. This was a not only a complex subsystem, but the radio system was integrated with standard ship’s communications via patch panels in Radio Central and couplers and tuners in the main Transmitter Room. The history of this system is interesting, well outside NTDS interests, and the technical requirements for its maintenance and operation were almost overwhelming. Accordingly, the Data Link technicians worked closely with RDs, ETs and RMs to assure correct setup of communication plans and minimize inter-frequency interference. Biddle’s link techs were truly the best, as demonstrated by the years of success in Link operations and communications support.

And, yes, there was also another radio, antennas, and terminal for the aircraft-control link, Link 4A. This link was not activated in the Fleet until the early 1970’s due to technical problems, and was in a layup state on Biddle during this time.

Biddle’s data-link success got started during her first predeployment workup at Roosevelt Roads. The first four-participant Link in the Atlantic Fleet was established and maintained while Biddle served as the Net Control Ship (NCS). Each participant in Link 11, whether a ship, aircraft, or shore site, is called a Participating Unit (PU). This level of successful operation for such a new ship was a pleasant surprise, especially on the East Coast, but not unexpected because of the time already spent grooming the Link system. This included radios, data terminal, antennas, and operator procedures. Bravo Zulu messages from COMNAVLANTFLT were received, and Hard Charger was a proud ship. This led to continued successes on deployment, where Biddle was required by CTF 77 to be NCS when in the Tonkin Gulf op area.

Adding to the complex data communications operation in the Tonkin Gulf was the Marine Air Control Squadron (MACS) at Da Nang. Equipped with the Marine Tactical Data System (MTDS), which also included radars and missile batteries, they were the only shore-site PU and participated like all other PUs. However, the MACS also served as the gateway for Air Force non-real-time tracks (called Iron Horse tracks at the time). Such tracks were collected around the North end of Vietnam by various detection methods unique to the Air Force. The Air Force Tactical Data System (TDS), code named Buick, processed all such sensor reports and was located near the MTDS site on Monkey Mountain. The two sites were connected by a data line.

Prior to the first WESTPAC deployment in 1968, Biddle dispatched the NTDS System Chief to Cherry Point to spend some time with the MACS that was to deploy to Da Nang. Biddle’s Ops Officer and NTDS Officer had learned that this MACS would be the unit at Da Nang with which joint operations would be conducted. It was deemed wise to establish technical contact since both units were new and would need lots of coordination on station to be successful. This proved to be a useful contact, since early on ships close to Da Nang could not maintain reliable Link operations with the Marines, while ships at some distance could. After many discussions about the problem, Biddle made a trip to Da Nang and sent a party to visit both the Marines and the Air Force. Eventually, it appeared that the MTDS antenna farm on Monkey Mountain did not have a good ground plane. This resulted in only long-distance communication via the generated sky waves, and no shorter-range communications because no ground wave was generated. By moving their antenna farm, the problem was fixed and the U.S. Navy was off the hook. Biddle’s Link technicians were pleased, because they could find no technical reason for the problem in their equipment. This situation also initiated a maintenance regimen for Biddle’s link equipment that emphasized keeping receivers as hot as possible and noise to a minimum. One of the four SRC-16 radio channels was groomed each day, another case of over-maintaining, perhaps. However, the enhanced maintenance standards worked out by the Link techs became PMS and factory standards. That’s another reason why Biddle’s Link 11 was one of the best.

USS Chicago, a guided-missile cruiser, spent much time in the Tonkin Gulf wrestling with an age-old problem called third-order harmonic interference. This was the result of running Link 11 at low frequencies and high power, often needed to assure good Link operations or for long-distance normal communications. The offending antenna was the 4-section long-wire fan antenna, the biggest communications antenna on ships at the time.
Third-order harmonics tended to interfere with other communication frequencies at or near the harmonic frequency, which is a multiple of the basic transmitter frequency. Such harmonics usually result from faulty antennas and nearby structural components of dissimilar metals that have weathered to form electrical diodes, called the “rusty bolt” effect. This combination reradiates harmonic frequencies and the more power in the fundamental frequency the more in the harmonics.
Chicago’s experts redesigned the long-wire antenna to use more advanced antenna wire with a PVC coating, and also inspected the ship to find many cases of the so-called “rusty bolt effect” in the form of dissimilar metallic junctions, loose fittings, and effects of rust and corrosion. Chicago submitted a Field Change Proposal (FCP) and sent Biddle a copy.

Biddle was beginning to have severe harmonic problems during the 1968 deployment. So, the DSs were given permission to rebuild the antenna using Chicago’s FCP. Antenna wire and special fittings were procured with TYCOM desk help. The Philadelphia Naval Shipyard provided newly-designed wire mounts made from a fiberglass material. Norfolk Naval Shipyard provided strain insulators with a newly-designed safety link. The new antenna was assembled with great effort, and extensive grounding and weather-proofing added around the masts. An inspection of over 800 groundstraps between the aluminum superstructure and the steel deck, plus topside ladders on the ship, found several hundred points of deterioration, which the deck force and technicians fixed. The result was almost full elimination of the harmonic problem, even at maximum power settings on the SRC-16. This configuration was used on the 1969 deployment, and was most effective for all modes of communication using the long wire antenna. This was the most ambitious undertaking by Biddle DSs of all the projects undertaken. BZ, all of you who worked on this modification.

Biddle’s SRC-16 techs also used built-in SRC-16 frequency standards and signal analysis equipment to evaluate the performance of other ships in the net. These techs could determine if a radio was off frequency, and by how much. They also could determine, via some skillful interpretation and computations, if the frequency standard used to time-base the Link radios and modems was out of calibration. These were tools used by Biddle as NCS to fine-tune Link operations, PU by PU.

The SRC-16 radio contained electronic switches called cross-point relays, whose function was to set up configurations of radio channels, tuners, couplers, and antennas as selected at a control unit. Early version of these relays, such as installed on Biddle during construction, were temperamental and internal contacts would often stick. In the way of experienced technicians, the Link techs would remove a stuck relay and slam it on the rubber deck mat. They almost always worked after that repair. This widespread problem was corrected when the manufacturer issued new relays that worked correctly.

One impressive use of ingenuity by the Link techs resulted from a failure in the Link 11 address panel and control unit of the SSQ-29 modem, located in CIC. After a momentary withdrawal from the Link 11 net, and turn-over of NCS to another PU, the technicians opened the unit, determined the failure magnitude, disconnected the offending circuitry and used some clip leads to restore a limited PU capability. Biddle rejoined the net, and continued Link operations in this unofficial casualty configuration until repairs were made. Upon completion of the work, Biddle again took NCS and continued operations.

The Ship’s Programmer teamed up with the Link technicians and CIC Track Supervisor to determine why a CV with a new NTDS program had started to send abnormally long transmissions. The team estimated what the transmit cycle should approximate, give the track load at the time. A Link data-extraction function was activated, which was a Biddle assignment by CTF 77, using a modified computer program. The extracted data was reduced with a special program that decoded messages and printed out results. What was found was the result of a failure to completely test and debug the new carrier program. There was an operator-requested function on the CV that required transmission of a single message type seven times. This was intended to be one time in seven consecutive transmit cycles. A programming error had each cycle sending the message 7 times, then 6, down to 1 time for each operator action. Biddle sent out an advisory message to the carrier, and the problem was fixed.

A one-time unusual event occurred in the Tonkin Gulf during Link 11 operations involving at least eight Participating Units (PU) and several E-2C Hawkeye airborne early-warning aircraft. This was prior to activation of the secure (encrypted) link. As Net Control Ship (NCS), Biddle was monitoring operations and noticed that what appeared to be a net PU had started into a constant transmit mode. Simultaneously, confusing tracks began to appear on ship NTDS consoles around the operational area. NCS quickly stopped interrogation of PUs to stop the cascading of bad track data, but the offending transmitter continued to offend. It was suspected that the North Viet Nam countermeasures folks had recorded and then played back on the same frequency several minutes of Link operations. Biddle’s SUPRAD intelligence team was alerted to analyze the emitter, but it stopped before they could respond. Needless to say, that example of effective jamming of Link ll gave CTF 77 concern, but it was not a surprise. Precautions were taken to carefully monitor the net for any more anomalies, but none were noted. The encrypted secure link capability was activated not too long afterwards. Biddle technicians later assisted an NSA representative in Subic Bay with checkout of the crypto system on several ships.
Reliable Link 11 operations became a Biddle characteristic, due to the technicians with mastery of the equipment and our capability to find, fix, and report Link-related computer program glitches originating on other ships. The accumulated experience also resulted in a couple of extra days at sea when in Norfolk to help the Fleet Computer Programming Center at Dam Neck check out some Link changes and problems.

Display and Beacon Video Processing Systems

The Biddle’s display system was of the AN/SYA-4(V) family. While a distinct upgrade from the initial SYA-1 series, it remained a challenge for technicians and sometimes new operators. As on most ships, constant work on the display system was required to catch all the problems, small or large, that could occur in this very complex equipment. It was also operated around the clock, and suffered from the normal wear-and-tear of any units with human operators. Some interesting maintenance actions and equipment modifications were developed by Biddle’s Display Technicians to handle unplanned problems.

Among many improvements to SYA-4 display equipments, Biddle technicians developed a field change to keep missile range circles at the correct ranges as console range scales were changed. This helped quiet complaints from ship’s operators and embarked staff, since each range setting would see the circles have a different diameter, and improved confidence in the accuracy of displayed information.
One continuing problem was that the track-ball units, used to move the cursor around, would become rough in operation. Each unit contained a set of costly and small ball bearings, and replacement would require considerable work. The simple fix was provided by toothpaste, any brand. After removal from the console, the unit was opened enough to allow a small quantify of toothpaste to be forced into each bearing. After a few minutes of bearing rotation, the roughness was usually gone, if only temporarily.

Operators also caused problems that later became fixes. During a WESTPAC deployment, there would be alerts at the System Monitor Panel (SMP) resulting from an illegal switch closure at an NTDS console. A Display Tech would usually respond, and never located a problem. However, it was noted that this alert occurred usually when a specific operator was on watch. Close inspection one night found that he had created a constant track-ball enable state, abnormal at the time for his console, by sticking a knife blade into the switch opening to keep it closed. This saved him a sore thumb, he said, since the button didn’t have to be pushed each time the track ball was needed and the console worked OK. Since this also placed a heavier processing load on the program for that console, he was instructed to case his knife.

A critical event at Gitmo during Refresher Training set the tone of casualty recovery on Biddle. While steaming out for the final battle problem there was an unplanned electrical power loss to CIC. Using the preplanned casualty-control procedures worked out during precomm, Biddle technicians quickly secured power to affected equipment in preparation for restoration of power by the engineers. This was done to minimize failures in the sensitive display consoles of the time. Upon power restoration and console reenergizing, seven consoles were found to have power-supply failures. Display techs started repairs at once, and by the time GQ sounded for the battle problem six consoles were up. The seventh was repaired shortly thereafter. That experience was proof that intensive practice and in-depth understanding of how to respond to problems was key to controlling and restoring casualties throughout the combat system.

Maintaining a uniform level of video display on all consoles was a constant problem. Cathode Ray Tube (CRT) degradation occurred gradually, and would cause operators to turn up video gain and burn holes in the phosphor which showed both radar video and symbols. This was not tactically appropriate, since it degraded the display of video and thus reduced operator effectiveness. Other conditions could occur, such as reduced output from a video amplifier. Biddle Display techs developed a video-distribution maintenance method and diagrams that used a total path analysis from sensor to CRTs, with Minimum Discernible Signal (MDS) factors to achieve a fairly standard of video display quality. This process was used to determine when to change the CRTs or identify video chain problems. It was simple, but effective in setting maintenance standards. This package was largely incorporated by NAVSECNORDIV into a formal video maintenance manual that was developed for PMS use.

While the DLG 28-class NTDS suite was the best of its day, engineering continued at the manufacturers to refine equipment capabilities and correct deficiencies in design. The Display Techs were always busy installing field changes, some of which were many hours per console. With a dozen or more consoles, days and nights begin to run together. However, the work was done, and done well.

Biddle received one of the earliest Beacon Video Processor (BVP) installations, considered as part of the Display system for maintenance. The BVP was a very complex digitized signal processor that operated under control of a computer program in the CP-1218. The BVP was also required on the input side to operate with old-technology IFF and defruiter systems. A defruiter was an electronic filter that assured that no random pulses, called False Replies Uncorrelated In Time, or FRUIT, got into the BVP signal processing section. Unstable BVP operation was immediately noticed, characterized by frequent inability to detect and decode valid IFF returns. Biddle’s BVP technician analyzed the likely cause as unstable and out-of-BVP-spec pulse pairs from the IFF system. These pulse pairs, or mode tags, were used by the BVP to synchronize its internal processing of each IFF mode as generated by the IFF system. With cooperation of the ETs, who owned the IFF system, the problem was traced to old-technology delay lines that created the mode tags. We opened up the sealed delay-line unit and carefully moved soldered taps on the delay line until outputs were within the range of BVP requirements. To the satisfaction of the BVP and IFF techs, proper operation was restored. The “modified” delay line served perfectly for the remaining months of deployment.

Sometimes doing things correctly gets a technician in trouble. Biddle was in the middle of an Operational Readiness Inspection with visiting experts on board, when during a tracking exercise using the BVP had a major failure. The BVP technician was dispatched, quickly isolated the problem and effected a repair. He reported the system back up in a short time, and the inspectors were impressed with how well the casualty was handled and corrected. Unfortunately, one of the ship’s officers was not pleased, and later called the DSC to his cabin to explain why the failure occurred if we had done all the PMS. Sometimes good technical explanations fail, but we were pleased that the inspectors were pleased.

Strange problems not covered in school or technical manuals were not unusual in the Display suite. One such problem resulted in a sweep jump at consoles selecting a specific radar. Radar sweep is generated in each console using sine/cosine pulses produced in a Radar Azimuth Converter (RAC). Each RAC gets radar antenna bearing information from its connected radar. The RAC outputs pulses as the antenna rotates, and the consoles generate sweeps from those pulses. This is all high-speed signal generation, and pulses must be within tight tolerances for proper display of the radar position as a smoothly rotating sweep on a console. The assigned Display tech spent hours checking circuits and pulse trains, all of which were apparently normal. Finally, he was able to set up a precision oscilloscope in such a way that he detected an extra pulse being produced by the Radar/RAC chain. It was very narrow, but got into the pulse trains and was sensed by the sweep circuits in the consoles so as to create the jumping effect. This was a sweet victory against technical odds that only technicians can appreciate.

Other Technical Challenges and Contributions

In relating incidents such as attempted herein, it is difficult to pick a few from the hundreds that could be of interest and that demonstrate the nature and capabilities of the sailors entrusted with making complex systems work. Biddle sailors of each crew, and sailors of all other ships, have always shown a level of competence and mastery of complex machines that set standards which assure that tomorrow’s ships will also be well served. Following are some examples of the larger scope of technician involvement in ship systems that show how lasting effects are achieved by the actions taken by the guys on the deckplates on each watch.

The SPS-48 radar was another integral part of the WDS MK 11 equipment suite. The original radar system did not have a Moving Target Indicator (MTI) capability, needed to see targets in clutter and weather. Biddle deployed in 1968 with the first MTI unit (brassboard model) and two engineers from the manufacturer. The radar operated with MTI all day, and the engineers made improvements and repairs at night. The result was an MTI capability that soon was installed on all ships. In addition, Biddle continued with SPS-48 support as the test platform for Operational Evaluation to determine radar characteristics in the at-sea environment. Such factors as blind speed, target glint and scintillation characteristics, burn-thru, and others were evaluated by Navy experts from Operational Test and Evaluation Force (OPTEVFOR). Lessons learned were incorporated into radar doctrine for all ships with this radar suite, updated with MTI to the SPS-48A, and used by Biddle on the next deployment.

Electronic warfare systems were very elementary during Biddle’s early years, while threats from the Soviet bloc were constantly increasing and proliferating. The Navy used Biddle as the test bed for an experimental passive and active EW system, named Shortstop. In late 1969 a Navy survey team was on Biddle to begin the process of designing the Shortstop installation, due for installation at the next overhaul. We assisted with determining equipment locations and made recommendations for improving existing installation problems. Biddle and Shortstop deployed in 1972, and demonstrated the full range of active and passive capabilities, including extensive Electronic Intelligence (ELINT) data recording and analysis. Today’s SLQ-32 EW system and later variants are derived from Biddle’s Shortstop installation and lessons learned from extensive operations.

Biddle NTDS technicians were required to become knowledgeable in the ship systems that provide power, water, air, HVAC, and Damage Control resources. They also practiced a version of Electronic Casualty Control (ECC) that was an NTDS-oriented extension of standard Repair 8 ECC operations. Repair 8 was one of the numbered repair parties used in a GQ situation or as required to provide manpower and equipment to control battle damage such as fires, flooding, plus equipment and personnel casualties. During Repair 8 ECC and all other operations, the NTDS technicians learned to work with all other technicians, operators, and the Engineering Department personnel to solve NTDS and other problems as the need arose. In turn, progress was made on Biddle in formulating organizational concepts that require such cooperation across all ship’s administrative boundaries of departments and divisions. This attitude goes back to the days of DLG 28-class NTDS/WDS training at Mare Island, where the system technicians were trained to think broadly and work with everybody to solve problems. All these are facets of the modern readiness-management concepts used throughout the Fleet today. These concepts support centralized and coordinated actions, standardized communications, rapid response to mission requirements with effective technical operations, and cooperation among all shipboard personnel.

We didn’t realize it at the time, but one of the most significant and continuing contributions of DLG 28-class Readiness Management fundamentals is found in an OPNAV-required system now found throughout the Fleet. It is called the Combat System Operational Sequencing System (CSOSS), and was created by the AEGIS cruiser USS Yorktown (CG-48) to support the comprehensive shock trials and survivability assessment in which the crew was required to respond to all casualties and damage from each blast. Only limited tools for total combat system casualty-control training and support was provided, Yorktown’s C.O. determined, so from the deck plates came the requirement for CSOSS. CSOSS optimizes the built-in features of the AEGIS Combat System as a highly-automated and monitored system with extensive fault-detection and reconfiguration features. CSOSS provides the tools such as procedures, diagrams, and status boards to support the sailor’s role in readiness management. As part of a Navy/Government/Contractor team, some former Biddle sailors contributed to development and institutionalization of CSOSS at the shipboard and NAVSEA levels, incorporating lessons-learned as appropriate.

CSOSS is a functional companion to the HM&E world’s Engineering Operational Sequencing System (EOSS), and is also modeled after EOSS. On Biddle, the concept of central coordination of combat system problems was done in vestigial form. However, the integration of systems and the central location for monitoring readiness and managing configurations is close to how CSOSS supports the integrated combat system on almost all surface-ship classes today.

Leave a comment