First-Hand:Testing the Naval Tactical Data System - Chapter 5 of the Story of the Naval Tactical Data System

The San Diego Land Based Test site and the System that Never Sailed

A New Breed of Sailor

One of the arguments detractors used against the Naval Tactical Data System was their idea of the exotic nature of the new digital equipment. They complained it was too complex for sailors to understand and maintain. Commander Svendsen couldn’t tell them he had seen sailors readily master the Navy’s secret codebreaking computers, even to the point of recommending improvements to the circuitry. The only question in Svendsen’s mind was whether the technical knowledge requirements of the Navy’s existing electronic technicians should be expanded to encompass digital equipment and their accompanying computer programs; or should a new enlisted rating be established to maintain NTDS devices. After discussions with training specialists at the Bureau of Naval Personnel (BUPERS) Svendsen recommended to the OPNAV project officers and to BUPERS that a new enlisted rating should be established. The new rating would be called “data system technician”; or “DS” for short.

What better place to start training the initial cadre of the new data system technicians than the engineering test site at the Navy Electronics Lab? But there was a problem. The DSs would be needed at all enlisted levels from chief petty officer to seaman and the Navy could not just make a chief or petty officer first class data systems technician overnight. BUPERS sent out fleet wide notices encouraging senior enlisted ratings to volunteer to convert their rating to data systems technician. Many volunteered and BUPERS was able to hand pick the cream of the crop. They were the very best.

Cdr. Svendsen issued a task to NEL to set up system level NTDS training courses for the new DSs; as well as making contractual arrangements for the three NTDS equipment contractors to give specialized courses on their particular equipment. Once trained, they would gain hands-on learning by helping to test the prototype system; and the project would get the benefit of their navy experience. The volunteers would readily master digital technology and would become one of the principal reasons for the eventual success of the Naval Tactical Data System. In all, about 75 enlisted, at all levels, received orders to the NTDS project at the Navy Electronics Laboratory, and roughly an equal number of officers. The following table shows to what work the officers were assigned. [Bureau of Ships, Technical Development Plan for the Naval Tactical Data System (NTDS)-SS 191, 1 Apr. 1964. p 11-13] [Swenson, Capt. Erick N., Stoutenburgh, Capt. Joseph S., and Mahinske, Capt. Edmund B., “NTDS - A Page in Naval History,” Naval Engineer’s Journal, Vol 100, No. 3, May 1998, ISSN 0028-1425, p.59]

Duties of the 77 fleet officers assigned to the Naval Tactical Data System project at the Navy Electronics Laboratory - April 1960.

Lord Admiral of the Fleet

In October 1956 BUSHIPS assigned Problem Task J1-6 to the Navy Electronics Laboratory. It was was to be the Lab’s most extensive NTDS task and had the name “Developmental NTDS Instrumentation and Evaluation”. It called for the installing the prototype NTDS equipment from the three contractors, in company with interfacing shipboard equipment, or simulators, in the Lab’s Applied Systems Development and Evaluation Center. Lcdr. Alfred Bettis received transfer orders from the BUSHIPS Computer Design Section to the Navy Electronics laboratory in mid 1957. His new job was to manage building the engineering test site, and then supervise system testing. When he finished testing three years later he would move on to San Francisco Naval Shipyard to work on planning the installation of NTDS service test systems in two service test ships. [Graff, R. W., Case Study of the Development of the Naval Tactical Data System, National Academy of Sciences, Committee on the Utilization of Scientific and Engineering Manpower, Jan 29, 1964, p IV-13]

In the meantime, by April 1957, NEL engineers and artists had created a suite of miniature cardboard scale model NTDS equipment units and built a miniature combat information center to work out the details of equipment locations. They even had to account for space requirements around every unit to allow for opening drawers and tops for maintenance access. When they were satisfied with equipment placement in the scale model, they had the NEL shops build full sized wooden mockups of all units and installed them on the test floor in early July to verify the layout, to work out operational procedures, and to satisfy themselves that the human engineering aspects of the layout worked well. In this they were assisted by the sailors who would eventually operate the real prototype equipment.

It is best to make mistakes on paper rather than in real life. NEL artists fabricated miniature cardboard replicas of all NTDS equipment types. These were used in a miniature mockup of the engineering test site to establish equipment locations. Note the models even show arcs of floor space to indicate where maintenance panels had to swing open without interference by nearby equipment. U. S. Navy photo

The cardboard mockup of the NTDS engineering test system to be installed in the NEL Applied Systems Development and Evaluation Center (ASDEC). This photo, taken in April 1957 shows the modular CIC arrangement at right and the computer area at left. Three computers were to be installed so that the site could replicate an attack carrier system or any smaller system. U. S. Navy photo

Preparing NEL’s Applied Systems Development and Evaluation Center for the engineering test system. The walled area will house the replication of a shipboard modular combat information center. The raised platform will allow the test conductor to view activity in the CIC. U. S. Navy photo

By March 1958 Univac had delivered AN/USQ-17 computer serial no. 1 to the engineering test site and two months later the Collins data link terminals and HIGHCAPCOM radios arrived. NEL outfitted its research ship USS Rexburg with one of the data terminal sets and a matching HIGHCAPCOM high frequency radio. The Navy Electronics Lab had enough equipment on hand to begin testing the tactical data link between shore and sea. Instead of an NTDS computer the shipboard system was fitted with a logic box that simulated a computer. When the logic box received an A-Link message from the engineering test site it merely changed all the ones to zeros, all the zeros to ones, and transmitted the ‘mirror image’ message back to the test site. At the test site the 30-bit outgoing and response message words were added together in the computer and the result was printed out. A perfect message printout would be all ones, and a transmission error would be shown as a zero - which would stick out like a sore thumb.

The first live NTDS A-Link tests, to be done in the spring of 1958, were of great interest to the Tactical International Data Exchange (TIDE) Committee made up of representatives of the Royal navy, Royal Canadian Navy, and the U. S. Navy. The Royal Navy called their automated shipboard combat direction system Action Data Automation (ADA). It used Ferranti general purpose, stored program computers as well as a special purpose digital computer for automatic target detection and tracking. The Royal Canadian Navy was working on a sequel to their Digital Automated Tracking and Resolving System (DATAR) that they called CCS-280. The three systems were required to exchange tactical data with each other, and what better time and place to have a TIDE Committee meeting than at the Navy Electronics Lab at the start of NTDS A-Link testing.

To add interest to the meeting, the transmission format of the link was still a very controversial and undecided subject among the three navies. The Royal Navy preferred a high speed serial teletype-like link with a 36-bit word, which they felt would cost less than the USN link, and with the longer word it could have more error detection and correction features. The problem was, in order to achieve operational compatibility, either the RN was going to have to adopt the U. S. link format, or the USN was going to use the British format. [Claisse, Lcdr. J., RN, “Tactical Data Handling in the Royal Navy,” International Defense Review, May 1971, pp 436-439] The first American A-Link tests were of such interest that Admiral of the Fleet, Lord Louis Mountbatten, himself, elected to attend the TIDE meeting.

In the spring of 1958 Lord Louis Mountbatten, Admiral of the Fleet, and some of his Royal Navy Staff visited the NEL engineering test site to witness the first live testing of the NTDS tactical data link. First row, from right, Radm. Martin Commandant 11th Naval District, Dr. Christianson NEL Technical Director, Admiral Mountbatten, Cdr. H. S. Foote OPNAV. Second row, from right, Cdr. E. C. Svendsen NTDS project officer, Cdr. USN unidentified, Cdr. P. E. I. Bailey, RN, Naval Attache British Embassy, Mr. Ian McCord Technical Director Admiralty Surface Weapons Establishment, Portsmouth. U. S. Navy photo

Admiral Mountbatten was no novice to naval communications. His specialty in the RN had been ‘signals’ and he was well versed in radio communications engineering. He arrived at NEL the day before the TIDE meeting and asked to observe the A-Link testing. He stood at the line printer and watched the printouts - which showed unacceptable numbers of transmission errors. A certain number of errors were to be expected, and they would be handled by the error detection and correction feature, if it had been turned on. But there were far more errors than there should be. Commander Svendsen was unable to convince the Admiral that they were most likely due to an equipment problem, that could be corrected. Mountbatten was convinced the errors were due to a flaw in the USN 30-bit parallel transmission concept, and that the RN 36-bit serial transmission was far superior. It was not a good day for the NTDS project.

In the data communications area of the engineering test site, Lord Louis Mountbatten and Lcdr. Bettis discuss the differences in the USN and RN approaches to their preferred tactical data links. Cdr Stan Foote is at far left. Years later, Capt. Bettis told this writer it was not a friendly discussion. U. S. Navy photo

Cdr. Svendsen also knew that Admiral Mountbatten would be visiting the USN Chief of Naval Operations, Admiral Arleigh Burke after the TIDE meeting, and he would surely try to sway Burke into adopting the Royal Navy’s preferred link format. Commander Stan Foote of the OPNAV NTDS project office had also been witnessing the tests and Svendsen proposed he return to Washington as soon as possible to brief Burke on the coming controversy and to tell him that Svendsen was sure the problem was due to an intermittent equipment error that they expected to find soon, and that they planned to write up an analysis in the form of a position paper which would prove the USN approach was technically superior to the RN serial approach.

That night Svendsen and Stoutenburgh proceeded to Lcdr. Bettis’ home on Point Loma to go over the day’s data link test printouts. It was to be expected that there would be occasional transmission errors evenly distributed among all 30 bits of the data words, but after a couple hours of scrutiny, it became apparent that two bit positions were experiencing more random errors than the other bit positions. When the extra errors in these two positions were ruled out, they saw the link was performing exceedingly well. Apparently two of the tuned resonators in the Rexburg’s data terminal set were on the ragged edge of tuning.

With the cause of the poor link performance pinned down. The three spent an all-night session drafting a paper comparing the capabilities of the two competing data link technologies, and building a strong case for using the USN approach. Each took a section of the draft to write, and while they were writing Mrs. Bettis supplied them with snacks and many pitchers of martinis. Lcdr. Stoutenburgh noted that as the night progressed, their handwriting drifted toward unintelligible, but even so, the NEL secretaries were able to decipher their writings the following morning. The resultant paper became known as the Point Loma Multiple Martini Position Paper, and Stoutenburgh concluded that martinis apparently stimulate creative brain cells, and kill off only the uncreative ones.

In the mean time, Stan Foote had caught a late night ‘red eye’ flight back to Washington and upon landing called Lcdr. Bettis’ home to learn that the problem was due to equipment malfunction and they thought they had an iron clad case that the USN system was superior to the Royal Navy’s serial system. Then he proceeded to Admiral Burke’s office in the pentagon. Burke told him that he had to board a Navy airplane to New London, Connecticut, in just a few minutes, and if he needed to brief him, Foote had better get on the plane too. Foote told him of the data link situation, and that Lord Mountbatten would surely try to convince him to switch to the British system. He also told him that Cdr. Svendsen had the matter well in hand and that he could prove the merits of the USN approach. He urged the Admiral not to give in to Mountbatten regardless of his expertise in naval communications. The final upshot was, the Royal Navy and Canadian Navy eventually adopted the USN 30-bit parallel system, which later became known as NATO Link 11. [Foote, Capt. H. Stanwood, Interview with D. L. Boslaugh, 14 July 1995] [Stoutenburgh, Capt. Joseph S. , Letter to D. L. Boslaugh, 14 July 1995]

Iron Sailors and Wooden Consoles

In the Summer of 1958 Commander John F. Felter was posted to NEL to take charge of the military contingent assigned to train at and/or support testing at the test site. Reporting to Felter, CDR Billy F. Brown took charge of the officers and sailors assigned to help evaluate the new system. They began by simulating CIC operations using the wooden consoles, and from this work they helped prepare detailed specifications for the follow-on NTDS shipboard service test equipment. [Graf, p IV-22]

Second of July 1957. The engineering test site has progressed to wooden models of the consoles. These were used to verify placement of the actual consoles as well as test human engineering considerations and operational procedures in the design of an automated CIC. Head of the NEL Systems Division, Charles S. Manning is at center. U. S. Navy photo

NEL engineers had designed a number of devices to simulate shipboard equipment connected to NTDS such as the ships gyrocompass, stable vertical, and underwater speed log; and many of these were driven by specialized computers to allow them to input realistic changing inputs. The first of these started arriving from contractors and NEL shops in February 1958. Three AN/USQ-17 unit computers were needed to replicate the largest NTDS suite that would be in an aircraft carrier, and these three were in place by July 1958. The complete suite of display subsystem equipment had arrived from Hughes Aircraft and was installed by March 1959. [Hughes Aircraft Company, Final Engineering Report for Data Display Group AN/SSA-23(XN-1) - Combat Information Central AN/SSQ-25(XN-10 Contract NObsr-72612, 15 June 1959, pp 6-9]

The contractor and NEL engineers learned that it was impossible to write an electronics interface specification that couldn’t be interpreted differently by two rational, knowledgeable engineers. For example the official project definition of the word “input” meant data coming into the central computer, whereas some peripheral equipment builders had traditionally interpreted “input” as data coming into their device. Many of the prototype equipment units were meeting their interfacing equipment for the first time and interface incompatibilities and misinterpretation of specifications was rampant. It was a good thing this system was not being installed for the first time aboard a USN ship. It would have been most embarrassing to the project. Mr. Robert P. McMannus, an NEL engineer, volunteered to take on the task of keeping track of all the incompatibilities, and forcing solutions to them. By April 1959 he had them resolved and the system was ready for formal testing. [Graf, p V-19]

The Coffee Break Combinations

The Navy organization that tests new equipment and systems at sea for operational suitability is called the Operational Test and Evaluation Force (OPTEVFOR). In the case of NTDS, even though it was not their responsibility to do so, OPTEVFOR arranged to send a cadre of officers and men to NEL to assist in the testing in order to get a feel for how they should go about testing the Navy’s first digital system at sea, and to try to get an early feeling as to whether the system was really going to perform as expected. They would work as operators alongside the navy personnel assigned to the project. [BUSHIPS NTDS Technical Development Plan, p 4-6]

The computer area of the engineering test site. Two of the AN/USQ-17 computers can be seen. The two persons seated at the computer operating consoles are two of a number of graduate students hired to do detailed analysis of test data. The computer operating console shown here was for shore use only. A much smaller system monitoring panel was to be used in the shipboard installations. U. S. Navy photo

The laboratory and contractor engineers brought the subsystems on line one sub-unit at a time until a complete subsystem was operating with the computers. At first they exercised each sub-unit with ‘nonsense’ computer programs that exercised every feature of the unit one at a time, kept track of each response and printed out missing responses on the teletype. The nonsense programs were found so useful that they were later refined as maintenance testing programs called “Programmed Operational Functional Appraisals” or (POFAS). When the equipment of each subsystem: data processing, display, and data communications, had been checked out separately with the computers they brought the data processing and display subsystems up simultaneously and worked out more program bugs. Finally they had all three subsystems operating together with a special testing program, and it was time to test the system with the tactical operational computer programs. First the two-computer program for the guided missile frigates, and then the three-computer cruiser/ attack carrier version.

Chief of Naval Operations, Admiral Arleigh Burke, visited the engineering test site in November 1958. Here Lcdr. Alfred Bettis briefs him on the layout of the site. Cdr. H. Stanwood Foote of the OPNAV NTDS project office is at far left. U. S. Navy photo

As well as the specialized data recording equipment devised by NEL, the tactical computer programs had been modified to extract and record operational data while the system was running. This data would be very useful in attempting to troubleshoot the causes of system crashes, and their were many. The testers started by performing each tactical function such as surface tracking, surface navigation, air tracking, threat evaluation, weapons assignment, and interceptor control, one function at a time. Many program crashes occurred, and the programmers resolved them one-by-one. Then they began running tactical functions in parallel.

The crashes continued, or sometimes the system didn’t crash, it just ran out of control as if the computer program had taken over from the operators. Other times they found that the computer program became confused. If an operator pressed two quick action buttons on a console at the same time, or some times a particular combination or sequence of pressed buttons would result in a crash. The sailors called these “coffee break combinations” because they would be afforded time for a coffee break while the programmers mulled over the data printouts to find and correct the program problem. Or sometimes they would find a flaw in the equipment, to the disbelief and unhappiness of the equipment contractors.

Prototype NTDS under test in March 1960. The test conductor in the foreground is equipped with an intercom system so that he can talk to the individual operators and listen to their conversations. The small, thin units beside the user consoles are auxiliary readout indicators which showed detailed information about selected targets. The square screen at the back is called the SKIATRON screen. On it a sailor could plot target coordinates projected, one target at a time, from the SKIATRON projector: the black box on the floor in front of the screen. One of the unit computers directed the target beam projection. It was an early attempt at a large screen display, but did not make it into service test.

A number of equipment flaws were found, some of which could be ‘worked around’ by the programmers, but had to be dealt with in the next generation of equipment which would go aboard ships for at-sea ‘service testing’. The testers also found many desirable changes and modifications that the project office would work into the service test equipment contracts. The problem was engineering system testing was scheduled to finish in the fall of 1961, whereas in order to have service test equipment ready for service test to meet the ambitious five-year schedule, the new equipment contract to Collins Radio had to be let by May 1959 and in late 1959 for the Univac and Hughes equipment.

The seven track input consoles of the prototype automated modular CIC are at left. The two with backs to the camera are specialized consoles used for height input and raid size analysis. Part of the decision area is at right. The dark gray console at center is a Weapons Direction Equipment Mk. 9 console. It was fed raw video from the radars as well as artificial target symbols from a special purpose analog computer capable of holding eight target tracks. This analog computer was fed high interest targets from the NTDS computers through a digital-to-analog converter. U. S. Navy photo

The foregoing dilemma meant that equipment changes had to be determined, agreed upon, and written into the contracts in real time. Furthermore, the equipment contractors would be chasing a moving target during the design phase. To keep the decision process short, the project officers and the BUSHIPS design division engineers had to spend considerable time at the test site reviewing proposed changes and making instant decisions. This is one of the reasons a ‘normal’ project took fourteen years from approval to equipment ready for service test.

Vadm. Charles B. Martell, with arms folded, visited the test site in July 1960. He was Chief of Anti-Submarine Warfare in the Office of the Chief of Naval Operations and was interested in applying NTDS to anti-submarine warfare. The OPNAV NTDS sponsor, Capt Parker L. Folsom, is in civilian clothes. It was OK then to smoke in the CIC; even to the point of putting a cigarette lighter in the ‘bullnose’ of each console. U. S. Navy photo

Training While Testing

Even when the engineering test site was equipped only with wooden consoles, the site was used at night to begin operational procedures training for the future NTDS operators of the service test ships. Later when the engineering test equipment had been installed, the testing team evaluated the system during the day while the sailors used the equipment at night to learn operations and maintenance. Later an NTDS operator’s school would be set up at the Combat Information Center School at the Fleet Anti-Air Warfare Training Center just across Catalina Boulevard from NEL, and a Data Systems Technicians School would be established at the U. S. Naval Schools Command, Vallejo, California.

The NTDS development plan also called for a Fleet Computer Programming Center (FCPC) to be set up in a new building at the Fleet Anti-Air Warfare Training Center. The new FCPC was to take over the operational computer programs of the service test ships to modify and maintain them, and have new programs ready for the ‘first production’ NTDS ships that would need their computer programs by early 1963. There was a twofold problem, first at worst, NTDS might never be ‘service approved,’ and at best service approval could not happen until mid 1962. Waiting for service approval before starting construction on the new building did not allow near enough time to finish construction and then have the production computer programs ready. OPNAV had to take another calculated risk to start construction in mid 1959.

Concurrently with construction, OPNAV requested that the Navy Electronics Lab set up an NTDS computer programmers school in order to have a staff of military computer programmers ready to man the new Center. With Univac contract help, Cdr. Robert E. Sink, of CDR Felter’s staff had the school up and running by December 1959, and the first class of programmers graduated in early 1960. This first class of approximately 20 officers and chief petty officers were assigned to the Univac programming group working on finishing the engineering test system and service test ship programs. They materially aided the Univac programmers by working military realities into the computer programs. [Graf, p IV-22]

In addition to systems engineering support and the NTDS land based test site, the Navy Electronics Lab taught a number of different types of NTDS training courses to naval personnel, including NTDS equipment maintenance, operation, and computer programming. NEL and Univac engineers taught a series of six-week computer programming classes, and this March 1961 graduating class is thought to be the third of such classes. The computer programming classes prepared officers and senior enlisted to work on future NTDS operational computer programs. U. S. Navy photo

Too Many Console Types

The engineering test system had seven different types of display consoles including a specialized height/range console for use with height finding radars, a specialized raid size analysis console, and five types of conventional plan position indicator (PPI) consoles. Furthermore the military testing specialists had developed compelling arguments to have even more types of consoles. At the same time engineering testers had made recommendations for many technical changes. One of the most difficult problems with the engineering test consoles was the irregular shapes of range circles, lines and symbols and their lack of precision in placement on the faces of the radar scopes. This was mainly due to the analog transistorized circuits which created and placed the symbology.

Hughes engineers told Lcdr. Stoutenburgh that digital circuits in place of the analog circuits could probably greatly improve symbology appearance and accuracy, but it would be technically difficult and make the consoles much more costly. Stoutenburgh felt the digital improvement was essential, but he was also advised that the improved displays were going to cost more than $100,000 each. This would make the display subsystem cost more than the data processing and communications subsystems together. There was concern in OPNAV that Congress might refuse to give them such an increase.

The Hughes engineers also told Stoutenburgh if they could reduce the number of display console types, they could bring down total cost by the benefit of larger production runs of each console type. He resolved to reduce the types to three: a combined height/range and raid size analysis console, a universal data input console, and a universal user console. The consoles would tell the computer which CIC function they were performing by a selector switch setting.

Stoutenburgh got Commander Svendsen’s permission to spend up to two months at the NEL engineering test site. His goal was to learn every function performed by the seven console types and then work out a way to perform those same functions with only three types. He participated in the daily testing and took volumes of notes. Evenings he went over the day’s test printouts and read equipment technical manuals. He also arranged meetings with the military operational specialists, such as the air intercept controllers, tracking supervisors, and missile engagement controllers, and with the Hughes display engineers.

From his information gathering, Stoutenburgh built a detailed tabulation for each of the seven console types of every display feature, button action, and control setting, and what operational result each was expected to bring about, as well as the expected computer response for each. Then he wrote a detailed functional specification for each of his three console types that would accommodate every requirement. Then he went after the easy one first; his new height/range/size analysis console.

Stoutenburgh asked BUSHIPS display engineer Fred Russell and NEL engineer E. E. McCown to design a single console that would accommodate the above three functions. It was not too hard for them to design a single console that could work with a height finding radar to display target height and range, or with any radar to do raid size analysis. His next task was to boil down the five plan position indicator (PPI) console types to one input, and one user console type. His conceptual input console was to be able to tell the computer it was to be treated as: a detector, tracker, electronic countermeasures input, or identification console; whereas the user console was to be switchable to weapons control, air intercept control, air traffic control, threat evaluation, or command functions.

Next came meetings with the technical specialists. Stoutenburgh challenged each specialist group to tell him why they could not perform their functions with the two PPI console types. There was resistance at first, but with his weeks of analysis to back him up. he was able to turn around every argument. He also told them that if the display system cost could not be brought down, there might never be an NTDS. They eventually found ways to perform all their required functions with the two console types and all agreed to only two PPI types. [Stoutenburgh, Capt. Joseph S., letters to D. L. Boslaugh, 14 Jul. and 5 Aug. 1995]

Goodbye to the AN/USQ-17

By mid 1959, the evaluators at the Navy Electronics Lab test site were finding the performance of the USQ-17 unit computer was just barely adequate to support the forthcoming shipboard systems. They found the computers needed more 30-bit communications channels, the intercomputer communications scheme worked, but could be made much better. Furthermore,the Q-17s were found difficult to maintain, and reliability was marginal. R. J. Malone of Univac had taken over unit computer development in early 1959 and by mid October 1959 was recommending to Cdr. Svendsen that a much improved computer could be built using newly available planar transistors rather than the USQ-17s surface barrier transistors. Don Ream, the BUSHIPS unit computer project engineer also seconded Malone’s recommendation. The catch was, surface barrier transistors could not merely be replaced one-for-one by planar transistors. A totally new design would be needed.

The project schedule called for delivering service test computers to shipyards in December 1960, which meant the prototype of a new computer would have to be ready for testing in mid August 1960. This would allow barely enough time to time to make final corrections and modifications and produce a small production run of service test computers. Extending the NTDS project schedule was out of the question; Svendsen knew the many project critics would try to use the delay as ammunition to discredit the project and kill,it if they possibly could. A newly designed unit computer prototype would have to be ready for test in less than eleven months from mid October 1959. [Ream, Donald L., Interview with D. L. Boslaugh, 1 Nov. 1995] [Graf, p V-18]

The only features of the AN/USQ-17 that would be carried forward to the new computer would be the instruction set architecture (so that the new computer could run the programs written for the USQ-17) and the input/output interface specification (so that interfacing subsystems and peripheral equipment would not have to be redesigned). Svendsen put the question to Univac. Could they design and build a totally new computer within these immovable time constraints? Univac’s answer was if Svendsen would authorize them two months to work up a preliminary design, they would know enough to assure him whether they could have a new prototype ready in the remaining 9 1/2 months.

At this time, Univac was producing the Air Force’s ATHENA ground guidance computer for the TITAN I ballistic missile. Athena was also transistorized and , although having less computing capacity than the unit computer, it had a stringent reliability requirement similar to the NTDS computer. Because of these similarities, Univac management picked Vernon E. Leas, ATHENA’s manufacturing manager to lead the preliminary design team for the new computer. Leas brought with him a small contingent of engineers who had worked on the details of ATHENA, and by mid December they had enough of a handle on the new unit computer that Leas told Univac senior management they could have a new unit computer prototype ready for test in the required 9 1/2 months. Cdr. Svendsen responded by issuing a contract covering prototype detailed design and construction, and a small production run of new NTDS unit computers. We will review how Univac went about accomplishing this seemingly impossible commitment in a later section. [Graf, p V-6] [Swenson, Capt. Erick N., Stoutenburgh, Capt. Joseph S., and Mahinske, Capt. Edmund B, p 57]

Captain Edward C. Svendsen pictured on the July, 1961, cover of Armed Forces Management magazine. Armed Forces Management magazine, July 1961

The Navy Electronics Lab and Operational Test and Evaluation Force representatives finished all testing at the engineering test site in November 1961. Many system problems and flaws had been found and corrected in a reasonably realistic shore-based environment, and the OPTEVFOR contingent felt the Naval Tactical Data System was sound enough to continue forward to at-sea service test. Since the beginning of testing, equipment changes had been feeding back to the three major contractors for incorporation in service test equipment design; the most radical of which was the complete redesign and rebuild of the unit computer.

In a normally paced project all of these changes would have accumulated to go before a review board who would survey test results and one-by-one review and approve or disapprove each change. The process could have added a year to project schedule; which the compressed NTDS project could not afford. Instead the BUSHIPS and OPNAV project officers had kept up a running change review and approval process so that service test equipment detail designs were constantly updated as engineering system testing progressed.

Getting the Service Test Ships

You Want an Attack Carrier?; Who the Hell do You Think You’re Kidding?

Service test was the acid test for a new Navy system. It was to be done at sea in as realistic an environment as possible, and it would be conducted by an independent Navy activity, the Operational Test and Evaluation Force who reported directly to the Chief of Naval Operations. OPTEVFOR knew how to stress a new system to its limits and find every flaw and weakness. In order to test the tactical data link at sea, at least two service test ships would be needed, and they should be Pacific Fleet ships so that they could work with the Navy Electronics Lab at San Diego. Furthermore, one of the ships should have a two-computer NTDS, and one ship should have a three-computer system. The three-computer ship could be either a heavy cruiser or an attack carrier. At least one of the ships should have a surface missile system and guns to test the weapons direction function. This ship could be a guided missile frigate having a two-computer system.

In mid 1959 the BUSHIPS guided missile frigate ‘type desk’ nominated two frigates, King and Mahan (DLGs 10 and 11) under construction in naval shipyards, whose schedules would allow NTDS installation soon after commissioning. OPNAV said the project could use both, but this was the easy part. [Swenson, Capt. Erick N., Stoutenburgh, Capt. Joseph S., and Mahinske, Capt. Edmund B, p 59] OPNAV was inclined to offer up a heavy cruiser to test the three-computer system, but the NTDS project officers were especially desirous of getting an attack carrier in order to give the system’s air intercept control and air traffic control features a realistic workout. In fact they had a specific attack carrier in mind, the USS Oriskany (CVA 34). This carrier was not only Pacific based, but also was the only Pacific Fleet carrier with a large modular combat information center that could easily accommodate the NTDS equipment.

The guided missile frigate King, nearest camera, under construction at Puget Sound Naval Shipyard, Bremerton, WA, on 26 November 1968 one week before launching. U.S. Navy photo

The guided missile frigate King (DLG 10) underway, one of the three NTDS service test ships. Her two two Terrier missile system pencil beam radar directors can be seen on the after deck house, and two Terrier missiles are loaded on her twin rail launcher. U. S. Navy photo

There was a lot of resistance in the fleet, and in OPNAV, to take one of the Navy’s 13 attack carriers out of circulation for almost a year for installing and testing a new system that most senior naval officers did not want. Not even NTDS supporter Admiral Burke was inclined to go so far as to direct that Oriskany be made available to the project. It looked like they were going to have to settle for an older cruiser.

An F2H-2P Banshee fighter comes aboard the attack carrier Oriskany in February 1955. U.S. Navy photo

When, at the outset of World War II, the U. S. Navy acquired the property of the Mount Vernon Seminary for Girls in Northwest Washington D. C. to become the home of the Navy codebreakers, the school’s chapel came with the property. The attractive colonial style chapel was renamed the ‘Navy Chapel’ and was a sought after site for navy weddings. Assistant NTDS project officer Lt. Erick Swenson and his friend Sandy Hopwood ushered there on most Sundays and at many of the weddings. Sandy’s father was Vice Admiral H. G. Hopwood, Commander in Chief of the Pacific Fleet, and in the fall of 1959 he attended a wedding at the chapel.

For some reason, the person who was to take the admiral back to his hotel didn’t show, and Erick found Vadm. Hopwood waiting in the parking lot. He offered the admiral a ride which was graciously accepted, and on the way Erick, who was not exactly a shrinking violet, told the admiral of the NTDS project and how important it was to get an attack carrier as one of the service test ships. When they reached the hotel, Hopwood invited Erick in and he continued his enthusiastic briefing for two more hours, during which he stressed the reasons for specifically getting Oriskany for service test.

The third service test ship, the guided missile frigate USS Mahan. U.S. Navy photog

Back at his headquarters in Pearl Harbor, Hopwood reviewed the NTDS project with the four senior officers on his staff. He then told them he wanted a vote on whether they should offer Oriskany for NTDS service test. It was four to one against supporting the NTDS project; however the one yes vote was Hopwood’s, and he told them they had been outvoted. He told them to write up a message to the CNO offering Oriskany for service test, and the reasons why that particular ship was needed. [Swenson, Annette M., Interview with D. L. boslaugh, 17 Apr. 1993] On 30 March 1961 USS Oriskany entered San Francisco Naval Shipyard to begin a five-month overhaul that included installation of the Naval Tactical Data System.

Suddenly, Two More “Service Test” Ships

The Billboard Radars

The best place to mount a search radar antenna is at the top of the mast so that it will have a clear undistorted view all around the ship. The trouble is, most modern ships have only one mast, and many electronic devices compete to have their antenna located at the top of that mast, and the end result is many radars do not get that favored location; and the penalty is loss of radiated power and angular distortion when the beam is forced to try to look through masts, other antennas, and pieces of the ship’s structure. It had been an unrealized dream of radar engineers to build a radar antenna that didn’t rotate, but rather could be ‘wrapped’ around a ship’s structure.

For years radar engineers had known how to electronically ‘steer’ a radar beam from a flat array of antenna elements. One way to make a radar beam emanate at an angle from a flat array is to feed each antenna element through a phase shifter so that each element in a line of antenna elements releases the wave front at a slightly different time than the element next to it, resulting in a wave front skewed from a perpendicular to the flat array. This is called phase scanning.

Another way to steer the beam from a flat array of antenna elements involves feeding all the elements in a linear array through a wave guide that has been folded repeatedly into a serpentine shape; with a tap for each antenna element at the same point on sequential folds. It can be appreciated that if the distance between taps is exactly equal to the wavelength of the signal feeding the wave guide, a beam will emanate at a right angle to the plane of the array. But, if the wavelength is made slightly longer or shorter than the inter-tap distance the wave front will leave the array at an angle to the perpendicular. This is called frequency scanning.

The problem however was that some kind of very fast, adroit control device was needed to rapidly change the phase shifters, or the frequency, if a radar beam was to be rapidly flicked around from a planar antenna array. Simple phase and frequency scanning schemes had been around for years, primarily used in gunnery fire control radars which concentrated on one target and wherein the beam did not have to be repeatedly and rapidly flicked around to track many targets as did an electronically scanned search radar. [Inman, Capt. Bryce D., USN, Letter to D. L. Boslaugh, 15 Aug. 1995]

What a viable electronically steered search radar needed to program and control a frequency or phase scanned search radar was a digital computer, and finally by the mid 1950s they were beginning to appear on the scene. This prompted the Bureau of Ships Radar Design Branch to issue a task to the Navy Electronics Lab to investigate the use of a digital computer for control of an electronically steered search radar. Part of the Lab task called for the Lab to issue solicitations to the radar industry to propose their ideas for such a radar.

Hughes Aircraft Company was one of the respondents, and they proposed an idea that had just been rejected by the Air Force for an electronically steered stationary ballistic missile early warning radar that was to be steered in bearing and elevation by computer controlled phase shifters. The USAF had rejected the idea out of concern for the level of technological risk and uncertainty, but the Hughes had modified their ideas in the Navy proposal by controlling the steering in bearing by frequency scanning and elevation by phase scanning. This considerably reduced system complexity, and the Radar Branch felt it was worth some research and development dollars. They gave Hughes the go-ahead for preliminary design of an experimental shipboard search radar.

The design actually took form as two radars working as a team, and with each radar having four fixed planar arrays that would be mounted on four sides of a ship’s superstructure - at right angles to each other. The first radar was a two-dimensional long range air search radar that was frequency scanned in bearing. It was designated AN/SPS-32, and its purpose was to find air targets at long range and display them on radar scopes where they could be manually picked off by human radar operators. The operators would then feed these targets to a computer that controlled the beam of a three- dimensional search radar that was frequency scanned in elevation and phase scanned in bearing. This radar was designated AN/SPS-33, and its beam was controlled by a fast special purpose, fixed program digital computer called the ‘computer tracker.’ [Polmar, Norman, “The U. S. Navy Phased-Array Radars,” Naval Institute Proceedings Vol. 105/4/914, Apr., 1979, p 119]

Long Beach and Enterprise

The two radars turned out to be the largest shipboard radars ever built. The SPS-32 antennas measured 25 feet in height and 20 feet wide, and the whole radar with electronics weighed over 48 tons. The SPS-33 antennas were even bigger at 40 feet by 20 feet high for each of the four antennas. No wonder they were called the ‘billboard radars.’ Furthermore, the SPS-33 weighed in at 120 tons. In the late 1950s there were only two ships in the construction pipeline that could possibly carry such massive high topside weight in safety: the Navy’s first two nuclear powered surface ships’ the attack carrier Enterprise, and the heavy cruiser Long Beach.

The U. S. Navy’s first nuclear powered cruiser - USS Long Beach. Two of her ‘billboard antenna arrays can be seen mounted on the bridge structure. The taller array at the left is the AN/SPS-32 long range two dimensional search radar antenna that fed live video to radar scopes. The wider array at right is the AN/SPS-33 antenna who’s ‘agile beam’ was computer controlled and who’s returns went only to the computer. The ship had Terrier and Talos missile systems instead of guns in her main battery. U. S. Navy photo

In addition to the weight and the large amount of topside real estate needed, there was yet another problem to be solved to make these radars viable. The SPS-33 three dimensional radar did not send raw video to a radar scope. Its targets coordinates were known only in the computer tracker that, when notified of the range and bearing of a new target, would schedule a pattern of search beams around the given target position until it got back a hit. Then it would schedule beams as needed to keep the target in track. This track information was simply maintained as numerical information in the computer. A computer printout of this information was OK for a laboratory demonstration, but to make the radars militarily useful they needed some form of operator/user displays that could not only show the analog video from the SPS-32, but also the digital track information from the SPS-33.

The Radar Branch had two choices for the display system. They could embark on a new digital display system development, or they could use modified Naval Tactical Data System Displays. The latter almost seemed to be a marriage made in heaven, because Hughes was also developing the NTDS display subsystem, and modified NTDS displays would cost considerably less than a new development. The problem was, the NTDS display subsystem was not a complete operable system in itself. It needed the NTDS data processing subsystem to make it workable, but in mid 1960 NTDS was still just a research and development project, and a risky one at that.

USS Enterprise, the U. S. Navy’s first nuclear powered aircraft carrier, and the world’s largest ship when commissioned in November 1961. Experience showed that when her AN/SPS-32 and 33 billboard radars worked, they worked very well, but they were technologically too far ahead of their time. They were subject to electronics unreliability, and even worse, the big billboards flexed in heavy seas, ruining their accuracy. They were removed from Enterprise and Long Beach in 1981/82 shipyard overhauls and replaced by conventional rotating radars. U. S. Navy photo

The NTDS schedule called for completion of the operational evaluation in mid 1962, whereas Enterprise would need delivery of her NTDS equipment by mid 1961, and Long Beach would need hers by early 1962. This would mean ordering two more suites of NTDS service test equipment well in advance of service approval. There was only one man in the Navy who had the authority to bet the military effectiveness of two of the Navy’s most precious future assets on the success of the unproved Naval Tactical Data System. That was Admiral Arleigh Burke, and in September 1960 he placed his bet by directing that two more NTDS service test systems be put on order.

The small and heavily loaded NTDS project office was now in the position of having to acquire and manage installation of five rather than three suites of service test equipment almost at the same time. There was one silver lining in the new storm cloud. The expanded production runs would help bring down the cost of the individual NTDS equipment units. They made their best estimates of the new equipment costs and told OPNAV how much ‘Ships Construction’ money should be sent from Long Beach and Enterprise construction accounts. The contractors did even better than estimated, and Cdr. Joe Stoutenburgh was pleased to tell this writer that the NTDS project was the first Navy research and development project ever to give back ships construction money. [Newport News Shipbuilding and Dry dock Co., “More Electronics on the Enterprise than Any Ship Afloat,” Shipyard Bulletin, Vol XX, No 5, Sep. 1960] [Swenson, Capt. Erick N., Stoutenburgh, Capt. Joseph S., and Mahinske, Capt. Edmund B., p 57]

Getting Ready for Service Test

 A New Computer in 9 1/2 Months!

Because of differences between the old surface barrier and the new planar transistors none of the original AN/USQ-17 circuits could be used. Electronically, as well as mechanically, the new computer was going to be a new design throughout; with the exceptions of reusing the old instruction set architecture and the interface specification. Even so, at the input/output interfaces there would still be changes. Instead of the Q-17’s 12 output and 18 input channels of varying bit widths, the new computer would have 12 input and 12 output, all 30 bits, plus two pair of 30-bit intercomputer channels. Because of the changes the new computer got a new Army/Navy equipment designation. It would be the AN/CP-642.

Univac’s Engineering Director of Data Systems, Arnold P. Hendrickson, was assigned responsibility for developing the CP-642 as well as the production runs of supporting peripheral equipment. These included: magnetic tape units, paper tape units, manual keysets, keyset central, system control panel, interconnecting digital switch panels, modified teletypes, motor generator and controller for computer power supply, an experimental automatic radar video processor, and a new refrigerator sized device called an interconnecting digital to analog converter - or IDAC for short.

The NTDS militarized magnetic tape unit. Remington Rand Univac photo

The militarized paper tape reader and punch unit was an alternative to the Magnetic tape unit for loading programs and program changes into the unit computers and for reading out data. One of its uses was for loading minor computer program changes and corrections. The computer programmers and data system technicians could read the coding in a punched paper tape faster than we normal mortals can read a line of printed text. Remington Rand Univac photo

The Universal Keyset was the primary way for NTDS operators to enter data into the computers, such as: ship’s navigational position, interceptor pre-launch data, and electronic countermeasures lines of bearing and fixes. Remington Rand Univac photo

Keyset Central collected the inputs from the universal keyset units throughout the CIC and sent them to the unit computers. It also contained analog-to-digital conversion channels that converted analog synchro voltage inputs from the ship’s gyro compass and underwater speed log to binary numbers and fed them to the unit computers. Remington Rand Univac photo

Each NTDS shipboard suite had one System Monitoring Panel that told the operators the status of the unit computers, and allowed operators to start and stop the computers as well as to load and readout programs or data to and from from magnetic and paper tape units from the CIC without having to go to the unattended equipment area which was in a different space from the CIC. This System Monitoring Panel is configured to control three unit computers. Remington Rand Univac photo

Shipboard surface missile systems included a weapons control area in the combat information center that included radar consoles for air tracking and weapons control, (usually five), and a special purpose analog computer that held track stores for selected high priority targets (usually eight) which operators picked from the radar consoles. The weapon’s control officer could assign these targets to missiles or guns by sending selected target coordinates, in the form of electrical voltages, to the analog missile or gun fire-control computers.

The NEL engineering test site had used a bank of non militarized digital to analog converters to send target coordinates and status signals from the NTDS computer to the weapons direction system computer, but real shipboard systems would need a fully militarized device to convert and transmit these analog signals. While assigned to the engineering test site, Lcdr. Edwin L. Ball, a line officer with subspecialty in gun and missile systems, had worked out the details of the communication that had to take place between NTDS and the gun and missile systems. From this he wrote up contract specifications for the Bureau of Ordnance to contract with Univac for developing the needed interconnecting digital to analog converter. The numerical data flow was in one direction only, from digital computer to analog weapon systems with status signal feedback to NTDS to let NTDS know when a target had been assigned to a fire control system, what target, and when the fire control system was locked on and tracking. [Graf, p IV-22]

Arnie Hendrickson picked a four-man team to work up the electronic design details for the new computer. A combatant ship’s electronic equipment must operate in an environment having extremes of mechanical shock, vibration, temperature, and humidity as well being exposed to the corrosive effects of salt laden air. It must therefore be appreciated that a fully militarized computer’s mechanical packaging and cooling was every bit as challenging as electronics design, and it is significant that Hendrickson assigned 20 mechanical engineers to work up CP-642 mechanical packaging. The vertical standup configuration of A/N/USQ-17 computers serials six and seven was the starting point for their mechanical design.

The four-man electronics design team was headed up by Herman Osofsky who was not only a mathematician skilled in logic design but an electronics engineer versed in circuit design. He worked on the computer’s central control section.  Electronics engineer Glen Kregness would design the arithmetic unit, Findley E. McLeod the magnetic core memory, and Robert L. Burkholder the input/output section. The control, arithmetic and input/output sections of a computer work in very complex ways with each other so Osofsky, Kregness and Burkholder were paced in a common cubicle so they could work closely with each other; as they had no time to waste. [Lundstrom, David E., A Few Good Men From Univac, The MIT Press, Cambridge, MA, and London, 1998, ISBN 0-262-12120-4, p 48-49]

It was decided the CP-642 would use a series of standardized printed circuit cards for all electronics circuits. The cards would be relatively small, measuring 1 5/8 by 2 5/8 inches, and would contain anywhere from two to five discrete transistors and 15 to 30 diodes, capacitors and resistors. It must be remembered that the mid 1950s was before the advent of integrated solid state electronic circuits, so each transistor was mounted inside its own protective ‘can’ measuring about a quarter inch both in diameter and height. As opposed to today's multi layer circuit boards, the CP-642 boards would be of a single layer having the printed circuit wiring on the side opposite the electronic components. The printed wires ran to a standardized 15-pin connector fastened to one of the long edges of the board.

The four designers fed their completed circuit designs to Lee Granberg, Univac’s chief circuit designer, who packaged their designs onto the standardized boards, and worked out the inter board wiring runs in the large sliding drawers that made up the electronics chassis. Granberg’s engineers came up with 49 different standardized card types, and each unit computer used 3,810 cards. [Remington Rand Univac, Univac CP-642B Computer Design Characteristics, Contract NObsr 87528, 30 Aug. 1963, p 5]

One of the 49 standardized types of printed circuit cards used in the CP-642 unit computer. Each unit computer was populated with 3,081 of these cards, and each card held from two-to-five discrete transistors; three of which can be seen in their cans on this card. Photo by the author

The new unit computer looked something like a large refrigerator, in fact many pieces of equipment comprising the Naval Tactical Data System were about the size of a large refrigerator because this was the maximum size of equipment that could be manhandled and moved within the confines of a ship with standard sized watertight doors. If the equipment had to be larger, it would be broken into two or more units. Today the electronics of most of these equipment units would be condensed on to a thumbnail sized integrated circuit.

The cabinet front of the CP-642 was made up of two doors that opened vertically and allowed maintainers to slide out the horizontal electronic chassis drawers for inspection and card changing. Hundreds of test points were located at the leading edge of each drawer. The computer maintenance and control panels, with their hundreds of blinking lights and push buttons, were mounted on the inside surface of the doors, so the doors had to be opened to view and work the panels. This would turn out to be not so good an idea.

The Univac engineers completed CP-642 electronic and mechanical design in in the spring of 1960, and by late June production workers had completed the card set for the new prototype unit computer, designated CP-642 (XN-1). By this time the new cabinet, its power supply, and electronics drawers were ready to receive the cards. The four-man electronics design team inserted the cards one drawer at a time; and as soon as the drawer had been slid back into its bank of connector plugs they applied power. Then they monitored the test points to look for anomalies that would indicate a design error or assembly mistake. As they found each error, they stopped the test to work out the cause and the needed design change; and they would note the needed change on the circuit plans. This process took six weeks until the new machine was fully operational without errors. They had met their goal to design and build a new unit computer in 9 1/2 months. [Lundstrom, p 57]

The prototype CP-642 unit computer. The top seven electronic chassis drawers have had their printed circuit cards inserted. The bottom drawer shows how the drawers could be pulled out and inverted to allow maintainers to view the wiring that connected the printed circuit cards. Photo from Donald L. Ream, Courtesy Unisys

In test, they found the new machine executed instructions at about twice the speed of the USQ-17, or about 100,000 instructions per second. Two of the new unit computers working together thus had about the same processing power as one vacuum tube SAGE computer that occupied 20 thousand square feet and consumed 1,5 million watts of power. For comparison, two unit computers consumed 5,000 watts. [Conlin, Paul, “Combat Computer Boosts Navy’s Sea Punch,” Armed Forces Management, Vol 7, No. 10, July 1961, p 15] [Pugh, Emerson W., Memories that Shaped an Industry-Decisions Leading to the IBM System 360, The MIT Press, Cambridge, MA, 1984, ISBN 0-262-16094-3, p 126]

The Cigarette Lighter Doesn’t Make it

BUSHIPS ship installations engineer Harvey G. Klohen was not amused when he saw the specification sheet calling for a cigarette lighter needing 60 Hertz power in each new service test operator console. The consoles ran on 400 Hertz power, and the lighter was the only 60 Hz item in the console; calling for a separate power source. With one quick call to the NTDS project office he got the lighter eliminated. The engineering test consoles had been primarily proof of concept devices and were not fully militarized. In addition to conversion of numerous circuits from analog to digital and boiling down the number of console types from seven to three, the biggest change in the service test consoles would be “hardening” them to pass all shipboard electronics military specification requirements.

Even though testing of the engineering test system at the Navy Electronics Lab was not completed until November 1961, as early as the fall of 1958 BUSHIPS had issued a contract to Hughes Aircraft to start design of the military specification packaging for the service test consoles and supporting equipment such as the symbol generator and the radar azimuth converters. Then in January 1959 the Bureau issued the service test equipment production contract to Hughes, who started incorporating new electronics design changes from ongoing engineering test results from NEL.

The new symbol generator design not only incorporated substitution of analog with digital circuits which made the symbols on the scopes more consistent in shape, cleaner, and clearer, but also included two complete symbol generators in the cabinet. This allowed one symbol generator to serve all consoles if the other generator failed, or it allowed breaking the consoles into two groups so that one group could be used for training, testing, or maintenance using one computer while the other group provided normal CIC functions while driven by the other computer. [Graf, pp VI-9-VI-10] In recognition of the major display system changes, the service test displays were assigned a new nomenclature - AN/SYA-1 Data Display Group [Hughes Aircraft Company, Final Engineering Report for Data Display Group AN/SSA-23(XN-1) - Combat Information Central AN/SSQ-25(XN-10 Contract NObsr-72612, 15 June 1959, pp 6-9]

Hughes service test AN/SYA-1 display subsystem equipment components. Hughes Aircraft Co. photo

The first destination for a service test display subsystem was a new NTDS land based test site at the Fleet Anti-Air Warfare Training Center, Pacific, in San Diego, just across the street from NEL. By the end of December 1960 Hughes was preparing the first display units for shipment to the new test bed. To illustrate the highly compressed schedule of the NTDS project, we reiterate, testing would continue at the Navy Electronics Lab engineering test site until November 1961. As early as March 1961, Hughes began delivering display units for the attack carriers Enterprise at Newport News Shipbuilding, and Oriskany at San Francisco Naval Shipyard. [Hughes Aircraft Company, Fullerton,CA, Interim Engineering Report No. 6 for the Data Display Group AN/SYA-1 (V) and The Tracking Group for Radar Sets AN/SPS-32 and AN/SPS-33, for the Navy Department, Bureau of Ships, Contract NObsr-77604, 28 Feb. 1961, pp 197, 213]

Service Test Communication Subsystems

Even though it had nearly caused an international incident in the spring of 1958 when two of the tuned resonators in USS Rexburg's Collins AN/SSQ-29 data terminal set (modem) intermittently malfunctioned during Admiral Mountbatten’s visit to the engineering test site, the SSQ-29 came through testing with flying colors. The service test version required so few changes that it retained its original nomenclature; being called the AN/SSQ-29 (XN-2).

The Collins KWT-6 HIGHCAPCOM high frequency radio also did well; in fact so well that BUSHIPS recommended to OPNAV that it be used it not only as the NTDS A-Link radio, but also for general shipboard high frequency communications. It was redesignated the AN/SRC-16 radio set, and four of these radios would be installed in each NTDS equipped ship.

The AN/SRC-16 high frequency radio system had four radio transmitters and four receivers installed in a ‘communications central’ radio room. One of the transmitter/receiver combinations was used for the NTDS A-Link and the other three were used for general shipboard long haul communications. Photo from Collins Radio Co. - now Rockwell International Corporation

The BUREAU, in July 1958, contracted with Collins Radio for eight AN/SRC-16 service test radio systems. The first would go to the new land based test site at the the Fleet Anti-Air Warfare Training Center, San Diego. Others would go to shipyards for the three service test ships, for Long Beach and Enterprise, and two other shore sites. Later, in May 1959, Collins was directed to ship eight SSQ-29 data terminal sets to the same recipients. [Rockwell International Corporation, Commerce Daily Bulletin Synopsis No. 310, Contractor Qualification for Development and Integration of a New Link 11 System for Use with the Navy Tactical Data System, undated, estimated year 1975]

The interceptor control data link was also to be tested during operational evaluation. For this purpose, the Bureau of Ordnance acquired seven service test AN/SSW-1 interceptor control data terminal sets from Western Electric Company. These sets would be delivered to the three service test ships, Long Beach, Enterprise, and two shore sites. Also acquired were seven Manson Laboratories AN/SRC-17 UHF radios to support the interceptor control link. These radios were connected into the shipboard system so that they could alternately serve as interceptor control radios or a UHF tactical data link called the C-Link.

The UHF C-Link was to be an alternate to the high frequency radio based Link-11 primary data link. It would have an expected range of about 150 miles, and its tactical advantage would be high data rate line-of sight radio transmission which helped reduce a task force’s vulnerability to giving away its location by radio intercept. In mid 1959 BUSHIPS contracted with Univac for development of a C-Link data terminal set which was given the name ‘terminal equipment logic’ or (TEL). The Bureau acquired six TEL units for the 13,000 bit-per-second secondary tactical data link. [Bureau of Ships, NTDS Project Office, Data Link Equipment Delivery Tables, 1 July 1971, p 36]

One More Land Based Test

Soon after the XN-1 computer was in test, Univac completed CP-642 computer Serial number two in the summer of 1960, and immediately shipped it to the new land based test site. The Hughes service test display subsystem and Collins data link equipment had already been installed. This site would eventually be used for NTDS operator training and computer program development, but its first use was to be to test a complete assemblage of service test equipment, for the first time.

The new unit computer had never before operated with the other NTDS service test subsystems, and this test would be critical. Cabling had already been made up for the computer, and all that remained was to roll the computer in from its van, hook up the cabling and turn the system on. Senior representatives were on hand from the three equipment contractors, as well as NEL engineers and NTDS project officers, and they were more than a little anxious. Technicians connected the cables, found and corrected a few wiring errors, and powered up the equipment. They loaded a simple test program and began methodically checking the subsystem functions, one-by-one. All present were greatly relieved when, within three hours, all subsystems had passed their tests. [Lundstrom, p 61-62] The project was still on track! Univac was directed to start building fifteen more CP-642 computers, and by December 1960 Univac was shipping the new computers to shipyards. [Graf, p V-6 V-18]

CP-642 unit computer serial No. 2 installed at the Fleet Anti-Air Warfare Training Center, San Diego, shore based test site. This machine was fully ‘militarized’ to meet all shipboard environmental requirements for electronics. The maintenance and control panels can be seen inside the doors, which were normally kept closed.

Univac had been contracted to build the new service test computer programs, which were to be turned over to the Fleet Computer Programming Center at FAAWTC following service test. The engineering test computer program had been written in the native machine code of the USQ-17 computer, but the service test program was written with the new NTDS CS-1 compiling system, a ‘high order’ coding system in which formalized english language and numerical programmer statements were automatically converted to machine code. It was thus a completely new program, and it had its ‘bugs’ which the Univac programmers, assisted by the new Navy programmers, patiently corrected. After a few months they had the program running well in the test site environment, and there was no reason to believe it would not perform just as well in the shipboard environment. They were in for a rude awakening. More about this later. [Graf, pp V-11-V-13]

July 3 1961. The air tracking and decision areas of the FAAWTC guided missile frigate CIC mockup equipped with AN/SYA-1 service test consoles. A Height/size console is located between the two tracking input PPI consoles. Lcdr. James V. Radja, the NTDS project office service test ‘trouble shooter’ is manning the utilization console at the far left. The officer at right is manning a Weapons Direction Equipment Mk 9 console. U. S. Navy photo

Installing Digital Equipment in an Analog Shipyard World

Puget Sound Naval Shipyard was to install the service test NTDS suite in the new- construction guided missile frigate King, and San Francisco Naval Shipyard was to do the same for the Attack Carrier Oriskany and the frigate Mahan. These yards had never before seen a digital system, but nevertheless had only six months to install the systems and check them out.

From his own shipyard experience, Capt. Svendsen knew there would be unforeseen problems and crises that could kill the project if not quickly resolved. He thus arranged for naval officer project coordinators to be assigned to each shipyard; they were to have a direct line of communication back to the BUSHIPS project office. He also made sure these project coordinators were already technically well versed in NTDS, as well as knowing the Navy and contractor project organization and persons involved. Svendsen also tasked the three NTDS equipment contractors to send engineers to the installing yards to assist in installation. Perhaps even more importantly, OPNAV arranged for the ships’ future data system technicians, who had learned NTDS maintenance at the NEL engineering test site, to be aboard their ships prior to start of installation so they could give the shipyard workers the benefit of their expertise.

Lieutenant Commander Alfred Bettis thereby received orders in 1960 to proceed from the Navy Electronics Lab to San Francisco Naval Shipyard to take charge of installing the service test systems in Oriskany and Mahan. Chief Warrant Officer H. A. Cain received similar orders to proceed from NEL to Puget Sound Naval Shipyard to take over King’s installation. When Lcdr. Bettis left NEL he was replaced by engineering duty officer Lcdr. Stanford R. Wilde who took over data link testing. This he did until mid 1961, when he was transferred to Philadelphia Naval Shipyard to supervise NTDS installation in the nuclear cruiser Long Beach.

The land based test sites at San Diego had worked so well that BUSHIPS issued tasks to each shipyard to set up a location ashore where the ship sets of NTDS equipment could be assembled, complete with their shipboard interconnecting cables, and tested before installing aboard the ships. The connectors would then be taken off one end of the prefabricated cables so shipyard workers could pull the wrist sized cables through their runs; which, in some cases, were longer than 300 feet in Long Beach and Enterprise.

The three service test ship’s, Oriskany, King and Mahan, installation schedules called for completion of NTDS installation and checkout by end of September 1961, which Puget Sound and San Francisco Naval Shipyards did without any great difficulties. The carrier Enterprise was not equipped with missile systems, so her NTDS configuration was simpler than the missile equipped ships, and she was able to use Oriskany’s three-computer program with only minor changes to accommodate her two ‘billboard’ radars. Furthermore, Newport News Shipbuilding, who was building Enterprise, was close enough to Washington D.C. to allow a representative from the BUSHIPS project office, Lieutenant Hal Morris, to drive down weekly to review progress and field problems. Newport News delivered Enterprise in January 1962 with her NTDS up and running. [Graf, p IV-13] [Stoutenburgh, Capt. Joseph S., Letter to D. L. Boslaugh, 3 Mar. 1995]

Univac was contracted to build only one experimental radar video processor. It was installed aboard Oriskany during service test to determine its ability to automatically detect and track air targets, and was found not ready to go into production. After further testing and improvements, the Royal Australian Navy was the first to use it in their U. S.-built version of NTDS. Remington Rand Univac photo

In March 1963 the National Geographic magazine published an excellent article about USS Enterprise. Pages 442 and 443 are a spread of photos taken in Enterprise’s combat information center. The bottom half of the two pages is a photo of the five tracking operators of the AN/SPS-32 long range, two dimensional search radar at their NTDS consoles. The video from each of the four quadrants of the billboard antennas can be seen on their radar scopes. [Kennedy, Nathaniel T., Abercrombie, Thomas J., “Mighty Enterprise, World’s Largest Ship,” National Geographic, Vol. 123, No. 3, March 1963, pp 431-448]

Lcdr. Stan Wilde’s work was cut out for him. USS Long Beach was the U. S. Navy’s first cruiser to have no guns in its main battery; it was armed solely with guided missiles. It had two twin-rail Terrier missile batteries forward, and a twin-rail Talos battery aft. Her NTDS was to have a complex interface with the two missile systems through the newly developed Weapons Direction Equipment Mark 2. Long Beach had been built by Bethlehem Steel Corporation of Quincy, MA, and was commissioned in September 1961. However, neither the Hughes AN/SPS-33 three dimensional radar, nor her NTDS had been installed by the shipbuilder.

Hughes had run into technical troubles with the SPS-33 and had to deliver late; and the NTDS service test equipment schedule did not match the ship’s construction schedule. Both of these systems were to be installed by Philadelphia Naval Shipyard starting in the spring of 1962. Wilde arrived in the shipyard in the summer of 1961 to start planning for the three-computer installation, its interfaces with the missile systems, and its interfaces with the billboard radar systems, as well as the test of a number of new NTDS computer program features related to the missile systems. Installation and checkout took eight months and finished on schedule in late 1962. [Graf, p V-3]

Operational Test and Evaluation Force, the Navy’s Consumer Advocate

The Operational Test and Evaluation Force (OPTEVFOR) is a separate command beholden to nobody except the Chief of Naval Operations. It is independent of the operating forces as well as the bureaus and organizations that develop and procure material for the Navy. Its mission is to test each new equipment or system acquired for Navy use in a realistic at-sea environment and recommend service approval or rejection. In most cases it will find things wrong with the new product and will recommend what has to be done to make it serviceable.

In 1960 Rear Admiral William D. Irvin was ordered from his job in the Office of the Chief of Naval Operations, where he had been sponsor of the NTDS project, to take command of OPTEVFOR. One of his first actions in the new job was to find Lieutenant Commander Chandler E. Swallow, who had just finished a tour as CO of a radar picket destroyer escort and who had been in the OPNAV NTDS project office before that. Irvin arranged for Chan Swallow to be ordered to OPTEVFOR’s Pacific Detachment in San Diego to take charge of the NTDS operational evaluation (OPEVAL). [Graf, p IV-4]

Staff of the Operational Test and Evaluation Force, San Diego, late 1961. Radm. William D. Irvin, commander of OPTEVFOR, and formerly OPNAV sponsor of the Naval Tactical Data System project, is seated in the front row, second from left. Capt. Maynard, commanding officer of the detachment is seated to the right of Radm. Irvin. Lcdr. Chandler Swallow, director of NTDS service test is in the middle row, fourth from left. U. S. Navy photo, courtesy of Capt. Chandler Swallow

This arrangement, to have two officers who were obviously advocates of the new system, in charge of ‘impartially’ testing it would seem to be a conflict of interest, however, in reality, it is an indication of how seriously the senior management levels of the Navy were committed to the success of NTDS. This in spite of the other 95 percent of senior naval officers who were adamantly opposed to it. The sentiment of the highest level of management was, if there is something wrong with NTDS, let’s find it and fix it, and the way to do that is to test the hell out of it. There was also the chance that NTDS might actually be found unviable in a realistic operational environment, and unfixable. After all, the sea was known to OPTEVFOR as “the monster who ate science.” In spite of the shore based test sites there were still a lot of unknowns.

The operational evaluation was to start in October 1961, and Lcdr. Swallow arrived at the Pacific Detachment of OPTEVFOR a year prior to start preparing the test plan. OPTEVFOR had never before tested a digital system, however they felt it would be very important to know what was going on in the computer programs while under test. What Swallow wanted was a way to periodically extract data from the computers while they were running. He spent considerable time with the Univac programmers at NEL trying to devise data extraction routines. They found that it could be done, and data could be printed out almost in real time at the NTDS teletypes, but there was a hitch. The data extraction routines took up valuable memory, and they found that to be of practical use, the amount of memory needed would require deletion of one or more operational program tactical modules; which was unacceptable. Today, thanks mainly to the incredible growth of inexpensive computer memory, event recording is a standard part of any USN ship combat system.

The best they could do was rig up the A-link terminal in the engineering test site at the Navy Electronics Lab to listen to and record on magnetic tape the data link transmissions from the three service test ships. This would allow them to reconstruct what was happening at sea in a fair amount of detail, and turned out to be very useful. Other than this, Swallow and his testers were going to be restrained to taking notes and talking into voice recorders to reconstruct what was going on with somewhere around 90 operators and seven digital computers on three ships. They had wanted to take motion pictures of the activities in the combat information centers, but could find no technology that would support photography in the darkened CICs.

The Pacific Missile Range at Point Mugu, CA, had precision radars that could track and record the three ships and air targets when they were within range of the Mugu radars, and Swallow made arrangements for them to do so. This would allow comparison of data link coordinates of ships and aircraft with simultaneous measurements made by the Mugu radars.

The first phase of the OPEVAL would be a Technical Evaluation (TECHEVAL) where the systems would be primarily under the control of Capt. Svendsen supported by engineers from the three equipment contractors and NEL. They would bring up the systems a little at a time. First they would have the sailors enter simulated tracks into the systems to see how the computers processed them and painted artificial track symbols on the radar consoles. Then they would do the same thing using live video from the ship’s radars, one radar at a time, until all radars were up simultaneously. Next they would turn on the three ship’s tactical data links and trade tracking data with each other under the master control of the NEL shore based data terminal set. Finally they would exercise the data link under net control of one of the three ships. This had never been done before. OPTEVFOR observers would stand by taking notes and observing data link recordings during this phase.

The next phase would be under OPTEVFOR control and only the ship’s company sailors would operate the system. It should be noted that Capt. Svendsen had already decided that, as a measure of his confidence in their training and abilities, the ship’s data system technicians would maintain the NTDS equipment from the beginning of TECHEVAL - with no help or intervention by contractor engineers; and they did so with flying colors.

NTDS service test system diagram. This diagram is a composite of both the attack carrier and guided missile frigate configurations. Diagram by the author from various U. S. Navy diagrams and technical manuals

The OPTEVFOR phase would exercise NTDS in realistic task force operations. They would include air attacks replicating Soviet capabilities and tactics. The attacks would start with a few USN aircraft at a time and, as time passed, would build up to massed saturation attacks by up to 20 attacking groups coming in at many altitudes and many directions at once. OPTEVFOR would score NTDS performance by recording the numbers of aircraft detected and tracked, numbers of simulated missile launches and gun engagements, as well as numbers of interceptors successfully coached into firing positions on their targets. This performance would be compared with performance of manual plotting CIC teams in past similar air exercises. Observers would also attempt to record the amount of effort, activity, and confusion going on in the three combat information centers. Confusion would happen, but it would turn out that the main source of confusion was not air attackers, but would be self inflicted by the new computer programs. [Swallow, Capt. Chandler E., Letter to D. L. Boslaugh, 16 Nov. 1994]

Nightmare at Sea

Captain Svendsen knew better than to expect the OPEVAL to go smoothly without emergent problems. He just couldn’t predict what problems and where they would pop up. What he did do was establish a system and a person whose job was to find problems, keep track of them and field them for fixing. Lieutenant Commander James E. Radja was ordered to NEL in mid 1960 to take on that job. His task was to try to find every incipient flaw in the service test system and send it on its way to solution; if possible, before start of OPEVAL. He was to be a roving troubleshooter, and another part of his job was to keep track of every equipment failure and its cause so that a statistical record of equipment reliability could be built up.

Lcdr. James E. Radja was assigned as the NTDS project office’s trouble shooter. Here he and a data system technician have raised an electronics drawer of an AN/USQ-17 computer to examine a printed circuit card. Raising a Q-17 drawer was a two-man operation and one of the reasons why the CP-642 unit computer was designed with horizontal drawers.

In mid 1961 Capt. Svendsen arranged for his own change of station orders from BUSHIPS to the Navy Electronics Lab so that he could be onsite during OPEVAL. He would personally take charge of the initial ‘technical evaluation’ part of the OPEVAL. [Graf, pp IV-10-IV-14] Techeval started on schedule in October 1961, with the sailors on the three ships entering simulated tracks into the computers. Things worked fine at low tracking loads - just like the system at the shore test site. But as the load went up, and especially when other interfacing shipboard systems were turned on, things started to go wrong. It was like the early days at the engineering test site. The computer programs faulted over and over again. Things got worse when the sailors made deliberate control misapplications as might happen in real life operating at sea. [Swallow, Capt. Chandler E., Letter to D. L. Boslaugh, 16 Nov. 1994]

Each night the Univac computer programmers worked at the Fleet Anti-Air Warfare Training Center test site analyzing and correcting computer program flaws, and delivered ‘corrected’ programs to the three ships each morning. Capt. Svendsen began to realize that moving a well tested computer program to a new environment was the equivalent of having a brand new program that needed a few months of ‘test and correct’ before it could be pronounced stable. He would have dearly liked to have those few months to find and fix all the new errors, but the opeval schedule would not allow it. Extending the OPEVAL would have meant changing the ship’s later deployment schedules and would have given critics the ammunition they wanted to scrub the project. He decided to have the ships go to sea regardless of the continued appearance of new program bugs.

One of the most critical at-sea tests was to start up the tactical data link on all three ships and run it under Oriskany’s net control. The link had never run independently of the link master control at the NEL test site, and the test was scheduled for the Friday after Thanksgiving in 1961. It was probably nervous sailors punching in incorrect net assignments, or setting the wrong radio frequencies, and for the first few hours all attempts to start the net failed. Finally a radio call from a chief petty officer on one of the guided missile frigates, “I think we're synching!” Than calls from the other two ships “We are synched!” Cheers rang throughout the three CICs. Scopes in the CICs began to show the new target tracks coming from the other ships. The system was finally starting to work. [Mahinske, Capt. Edmund B., Letter to D. L. Boslaugh, 31 July 1944] [Swallow, Capt. Chandler E., Interview with D. L. Boslaugh, 23 April 1996]

Even after weeks at sea, new computer program bugs kept popping up when new features were turned on for the first time. Information on the new bugs was transmitted to the FAAWTC test site each night and the Univac programmers worked feverishly through the night. Each morning new program tapes would be flown out to Oriskany. The programmers began to appreciate the thorough computer program documentation they had been required to maintain - under some protest. Svendsen would have liked much more time to continue TECHEVAL, but he was moving into the time when extensive air services had been scheduled for OPEVAL and he agreed to concurrently continue TECHEVAL and at the same time have the Cdr. Swallow start the OPEVAL.

The air attacks started, and daily built up in number of aircraft. But sometimes there seemed to be more target symbols on the radar scopes than there were known targets in the air. They seemed to proliferate more as the day went on. Svendsen began to suspect that the cause of the extra track symbols was due to ships’ position errors. When accurate ship’s positions were entered at the beginning of each day the problem was not so bad. But it seemed that as the dead reckoned position of a transmitting ship began to diverge more and more from its true position, the transmitted target symbols fell miles away from the targets actual position and other ships interpreted the radar blip without accompanying target symbol as a new target and began their own track on it. Recordings from the precision radars at Point Mugu, when compared with the NEL data link recordings confirmed that sometimes the system held three separate tracks on the same target. A different track from each ship.

The Global Positioning System was not even a dream in the mid 1950s, and ship and aircraft navigational fixes could be less accurate by an order of magnitude than radar measurements. This mismatch of accuracy could have been a project killer had it not been for a computing routine the Univac programmers hurriedly devised to take advantage of the relative accuracy of radar measurements. The project officers christened the routine ‘gridlock.’ Whenever ships in a task force were be close enough to see each other on long range surface search radar, the NTDS operators could establish accurate relative positions with respect to the participating units using radar measurements. The net control ship was generally set up as the master ship and all other participating ships could use the intership radar measurements to derive an accurate relative navigational position based on the master ship. The gridlock program module allowed operators to do the gridlock function in seconds, and the multiple false targets went away. [Hughes Aircraft Co., Interim Engineering Report No 6, p 14]

Toward the end of the six-month evaluation, Lcdr. Swallow reported that the system was finally staying up for three to four hours without program failure, and when it worked, it worked very well. However, usually after a maximum of four hours gremlins began to appear, most usually in the track reporting and updating routines. In normal operation, when a target was moving from the operating area, the ship’s tracking supervisor was supposed to delete it to keep the track stores from filling up with old tracks. It was found the track stores were filling up with targets the supervisors had missed before they disappeared off the scopes. Then when the computer could find no more space in the stores, it could not cope. One of OPTEVFOR’s final recommendations was an automatic track deletion routine.

A number of senior naval officers were curious enough about NTDS to visit the ships during the evaluation. They were all invited to sit at the consoles and exercise the system, especially the threat evaluation and weapons assignment (TEWA) function. Lcdr. Chan Swallow noted that they were usually uneasy about TEWA, and they would express this as giving up their judgment and decision making flexibility to a machine. What Swallow finally realized was bothering them was the fact that by the time they had taken their finger off the button, the system was showing them its recommendation. They would have felt much more comfortable if the computer would have chewed on the data a while before spitting out the answer. He also had to keep reminding them that the computer was giving recommendations not orders, and that they could always add new data or conditions and have the computer try again. [Swallow, Capt. Chandler E., Letter to D. L. Boslaugh, 16 Nov. 1994]

In the spring of 1962 Univac engineer David Lundstrom was aboard one of the service test guided missile frigates in harbor at San Diego. He happened to overhear Lcdr. Jim Radja grilling the ship’s NTDS maintenance chief about equipment failure data. He said he was getting plenty of data on almost all equipment except the unit computers. Was the chief saving up computer failure reports that he had not yet turned in? Radja said he really needed them for his analysis. The hard pressed chief said he had turned in everything he had, and then to explain the paucity of computer failure data he emphatically said. “Hell, it don’t hardly ever fail sir.” Radja apologized and confided in the chief that the other two ships had also experienced very few computer failures. [Lundstrom, p 61]

Survival

The OPEVAL finished on 1 April 1962, and OPTEVFOR's subsequent report noted that although the computer programs had failed at least once a day, and sometimes three and four times per day, the NTDS equipment had been found to be very reliable. Because of the deliberate redundancy built into the system and it’s graceful degradation capability, at no time had any of the three ship’s systems been inoperable due to equipment failure. Lcdr. Radja’s eight-month reliability study backed this finding up. He found for example that the unit computers, that had been assigned a goal of 200 hours mean time before failure (MTBF) actually experienced 1,500 hours MTBF.

Part of the results of LCDR. Jim Radja’s NTDS service test equipment reliability analysis.

Radja’s report noted that the seven unit computers on the three ships had a total of 26,670 printed circuit cards, out of which just 25 cards had failed over the eight months. Furthermore seven of these failures were intermittent and had been caused by connector pins which occasionally lost contact. The remaining 19 failures were due to failed electronic components. Radja calculated that for all the NTDS subsystems the annual NTDS repair parts consumption cost for the three ships would be less than a half of one percent of the original equipment cost. This was unbelievably low. All three ship’s commanding officers recommended that they could get by with fewer NTDS data system technicians. [Bureau of Ships, Technical Development Plan for the Naval Tactical Data System (NTDS), -SS 191, 1 Apr. 1964, pp 10-1, 10-12] [Von Alven, W. H., and Blakemore, G. J. Jr., Reliability of Semiconductor Devices, The ARINC Research Corporation Final Report, Contract NObsr 81304, 22 Dec 1961,]

The only disappointing equipment was the secondary high speed UHF tactical data link (C-Link), and that was not due to equipment failure per se, but rather to the vulnerability of UHF transmissions to moisture in the air. On some days the C-Link could not communicate more than 20 miles, rather than its 150 mile goal. This link was deleted from the NTDS operational requirement. [BUSHIPS TDP for NTDS, p 8-8] The C-Link remained useful in another way however. In future ship NTDS installation layouts, NTDS installations engineer William C. O’Sullivan left a space between the two unit computers for a mythical C-Link terminal. It would turn out that when OPNAV directed that a third unit computer be back fitted into those guided missile frigates, the weight, space, power, and cooling water reservations for the C-Link terminal, by amazing coincidence, were exactly the same as the unit computer’s.

The computer programs were the real problem. Lcdr. Swallow was confident that the programs could not wear out from use, and neither were they modifying themselves during operation, so what was causing the failures. In long discussions with the programmers it became apparent that each new bug appeared to happen when the program was traversing a path through which it had never run before during all the testing. Surrounding conditions and events might make it traverse that exact path only once a year, and if a bug was lurking in that path it would trip the program up.

An example of one of these hiding bugs is one that happened every few days in Oriskany’s program; and it happened a few times right during saturation air attacks when it brought the ship’s entire system down. The computer programmers ashore investigated the problem for weeks until they finally found that it was one wrong instruction in a part of the program that was rarely executed. But when this program branch was traversed, the erroneous instruction set the real time clock to zero in one of the three computers which not only stopped that computer but the other two computers as well. [It became clear that no amount of shore testing could replicate everything that might happen when running in the real ship’s system. It also became clear that a new computer program should be extensively tested in the actual first ship of a new class before it could be certified.  [Swallow, Capt. Chandler E., Letter to D. L. Boslaugh, 16 Nov 1994]

Soon after the end of OPEVAL Radm. Charles K. Bergen took over OPTEVFOR from Radm. William D. Irvin, and Cdr. Chan Swallow prepared his brief of final OPEVAL recommendations for the new admiral. Swallow reported that when NTDS worked, it worked very well; an order of magnitude faster and more accurate than the manual plotting teams. The system had never been overwhelmed during any air attack - except when the computer program failed. He noted that the NTDS equipment had been exceedingly reliable, and the only real problem had been the programs. He further noted that the computer programs were fixable without any great expense; time was the main needed ingredient. He proposed that the system be given a ‘provisional service approval’ so the project could proceed, and that BUSHIPS be allowed to continue cleaning up the programs before turning them over to the Fleet Computer Programming Centers. [Swallow, Capt. Chandler E., Letter to D. L. Boslaugh, 16 Nov. 1999.

Radm. Bergen agreed and noted in the cover letter to the final OPEVAL report that if the NTDS equipment had performed as poorly as the operational programs he would have had no choice but to give the system a down check. The Chief of Naval Operations concurred with the OPTEVFOR recommendation, and the OPNAV sponsor office arranged for a small contingent of OPTEVFOR evaluators and Univac computer programmers to stay on the three service test ships on their subsequent deployment to the Western Pacific in June 1962.

Oriskany, King and Mahan returned to San Diego in December 1962 with greatly improved computer programs. In March 1963 the Chief of Naval Operations approved the Naval Tactical Data System for full service use, and designated the NTDS equipment as standard Navy equipment. [BUSHIPS TDP for NTDS, p 12-1] President John F. Kennedy inspected Oriskany’s NTDS installation during a Pacific Fleet demonstration on 6 June 1963. [Navy Department, Office of the Chief of Naval Operations, Naval History Division, Dictionary of American Naval Fighting Ships, U. S. Government Printing Office, Washington, D.C., 1964-1981, Vol III, p 529]

The total research and development (R&D) cost of the project to the end of service test was $136 million, including not only contractor’s cost to develop and produce the equipment and computer programs but also all involved military personnel and civil servant pay and allowances, laboratory tasks, and shipyard design and installation costs. For comparison, the cost of building USS Enterprise, in 1961 dollars, was $451.3 million. Of the total NTDS R&D cost $14.4 million was for acquiring and installing the service test equipment in the three service test ships. The service test NTDS equipment remained in use aboard these ships with only minor field changes and modifications until the ship’s decommissionings many years later. Thus in addition to developing a radical new system that gave the U. S. Navy a quantum boost in tactical capability, the Navy accrued a long term useful capital investment of $14.4 million represented by the equipage of the service test ships. [Boslaugh, David L., When Computers Went to Sea - The Digitization of the United States Navy, IEEE Computer Society, Los Alamitos, CA, 1999, ISBN 0-7695-0024-2, pp 260-261]

31 July 1964 - USS Enterprise (bottom), USS Long Beach (center), and the guided missile frigate USS Bainbridge made up "Task Force One," the first USN nuclear-powered task force. They were among the first ships to be equipped with NTDS, and they sailed around the world in 65 days without refueling or replenishment. .U. S. Navy photo

Even though the operational evaluation was not finished until April 1962, as early as December 1961 OPNAV had authorized the Bureau of Ships to issue contracts to proceed with detailed design of NTDS production equipment. The design changes were based on OPEVAL findings being fed back in real-time to the three equipment contractors. Then in March 1962, with service test still in progress, OPNAV directed the Bureau to start planning for the acquisition of NTDS production equipment to outfit seventeen ships. Seven existing major combatants and ten new-construction guided missile frigates had been committed to receive the new system. There was still no time to lose, and there would be no respite for the NTDS project officers.

In early 1964 the U. S. Navy’s first three nuclear powered surface ships,: USS Enterprise, USS Long Beach, and the guided missile frigate USS Bainbridge (also equipped with NTDS) made a round-the -world cruise without refueling. When they returned, the task group commander of ‘Operation Sea Orbit’ Radm. Bernard M. Strean, reported the following about their use of NTDS.

“I have had the privilege of using the Naval Tactical Data System as a command and control tool. Its effectiveness is such that I consider the evaluation of this system to represent the single greatest step forward in tactical direction since the invention of Radar. The equipment reliability is of very high order. The “down” time over the past few years being measured in minutes instead of hours or days” [Strean, Radm. Bernard. M., Task Group Commander, Operation Sea Orbit, Speech given upon completion of Operation Sea Orbit, Oct. 1964]

The reader may proceed on to the next chapter: "MOVING THE FIRING KEY TO NTDS - Chapter 6 of the Story of the Naval Tactical Data System" by clicking on this link.