First-Hand:Building the U.S. Navy's First Seagoing Digital System - Chapter 4 of the Story of the Naval Tactical Data System

By David L. Boslaugh, Capt. USN, Retired

A Radical Idea; a Dedicated Project Office

In Chapter 3 we learned that the Office of the Chief of Naval Operations authorized development of the Naval tactical Data System in April 1956, and assigned the Bureau of Ships as lead developing agency. The Bureau,  in turn, assigned Commander Irvin McNally as NTDS project “coordinator” with Cdr. Edward Svendsen as his assistant. Over a period of two years the coordinating office would evolve to one of the Navy’s first true project offices having complete technical, management, and funds control over all life cycle aspects of the Naval Tactical Data System including research and development, production procurement, shipboard installation, lifetime maintenance and system improvement. In the following two sections we will review the initial staffing of the coordinating office and then the evolution from project coordinator to project office, then we will return to the story of building the Naval Tactical Data System.

Staffing the Project Office

By 1956, Cdr Irvin McNally had been in the navy 24 years, the first ten of these as enlisted and then as a radio warrant electrician. Even though his temporary rank was commander, his permanent rank was lieutenant because most of his promotions through the officer ranks had been spot promotions. Upon inquiry to the Bureau of Naval Personnel regarding whether he would be eligible to be considered for promotion to captain rank in the remaining six years of his career, he found the answer was no. Faced with the prospect of no chance for promotion, McNally submitted his request for retirement from the service to get an early start on a civilian engineering career.

Prior to his departure from the Bureau of Ships, McNally met with engineers of the Radar Development Branch to work out the performance details of the two new NTDS compatible shipboard search radars called for in the NTDS Technical And Operational Requirements document. The first radar was to be a three dimensional search radar having a range of more than 200 miles and also having unprecedented accuracy so that it could turn targets over to missile and gun pencil beam radars with minimum search time on their part. The second radar was to be a two-dimensional long range search radar able to detect relatively small targets at ranges over 250 miles. Its main function was to detect targets at long ranges and then turn them over to the three dimensional radar when they were within its range.

McNally retired from the navy in June 1956, and went to work for Raytheon Corporation at their Wayland, Massachusetts, laboratory as department manager for range instrumentation. Later, Raytheon won the Bureau of Ships competition to develop the AN/SPS-49 long range two-dimensional search radar; the NTDS compatible radar which McNally had envisioned in his NTDS concept paper. Raytheon then made him head of their Search Radar Laboratory in charge of developing the new radar. [McNally, Cdr. Irvin L., Interview with D. L. boslaugh, 20 April 1993]  [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-1] The AN/SPS-49 radar would first go to sea aboard the destroyer Gyatt for testing in 1965. It would become the U. S. Navy’s principal shipboard long range air search radar  for more than four decades; still on active duty in 2011. It would be built in eleven ever improved variants, the latter ones of which would feature automatic target detection and tracking. [Wikipedia, the Free Encyclopedia, AN/SPS-49 Radar]

When Cdr. Irvin Mcnally retired from the Navy, he went to work for Raytheon Corporation where he was put in charge of building the long range two-dimensional air search radar he had specified in his NTDS concept paper. The SPS-49 antenna, shown here, was mechanically stabilized so that it remained level with the horizon as the ship pitched and rolled. U. S. Navy photo

When Irvin McNally left the navy for civilian pursuits, Cdr Svendsen was reassigned as NTDS project coordinator, and told to work out the size of his project staff and their proposed duties. Svendsen wanted three things. He wanted to keep the size of his staff small so that there would be very short lines of communication among staff members so that each member would know what the others were doing, and so that they could back each other up when necessary. He wanted no more than six naval officer and civilian engineer assistants in his office staff. Secondly Svendsen wanted the three “technical codes”: the Radar Development Branch, the Special Applications Branch, and, the Communications Development Branch to carry out the technical details of developing the needed new equipment by assigning engineers to be dedicated to the NTDS project; and thirdly, Svendsen wanted to be able to personally pick the engineering duty officers and civilian engineers for his own staff.

The Chief of the Bureau of Ships backed Svendsen up on all counts. The Radar Branch nominated Mr. Frederick A. Russell to work on the NTDS display subsystem, Special Applications provided Lt Alfred M. Bettis and Mr. Donald L. Ream to develop the unit computer, and the Communications Design Branch provided Mr. Robert L. Lynne to develop the high frequency data communications radio and data terminal set.  Svendsen was also told he could have his pick of engineering duty officers for his immediate staff no matter where they were presently assigned in the navy. For his assistant project officers, Svendsen valued technical knowledge of electronics, especially digital computer experience, more important than military rank or acquisition management experience. Furthermore operational shipboard experience was a prerequisite. He also wanted proven, fast moving hard drivers who could handle massive amounts of technical and management detail. [Svendsen, Capt. Edward C., Interview with D. L. Boslaugh, 20 Jan 1995]  He had already been given two in the persons of Lt. Bettis and Don Ream in the Special Applications Branch.

Alfred M. Bettis

When Ensign Al Bettis graduated from the U. S. Naval Academy in 1945, his first duty posting was to a Landing Ship Medium (Rocket) getting ready for the invasion of Japan. At war’s end he was put to work in a ship decommissioning unit until 1946 when he started a two-year study of radar at MIT. Following that he served as electronic maintenance officer for two years aboard the aircraft carrier Franklin D. Roosevelt. Next was a fateful assignment, because in it he learned the rudiments of digital technology while working with decimal and binary counting circuits in the Special (Nuclear) Weapons Program at Sandia Base, New Mexico. In 1952, while in the Special Weapons Program he was designated an engineering duty officer (EDO). With his digital technology experience and EDO designation he was a natural for posting in 1953 as head of the Computer Design Section in Commander Svendsen’s Special Applications Branch.

The Computer Design Section was not physically located with the Bureau of Ships in Main Navy, but was located under tight security wraps at the Navy Security Station in Northwest Washington, D.C. At the time the Section’s main workload was developing codebreaking computers and special codebreaking devices for the new National Security Agency. When Bettis started developing the NTDS computer, some experts were alarmed at the seemingly risky features and technologies he specified for the NTDS devices. He would tell them, “Don’t worry, it will work.”; but he couldn’t tell them the reason he knew so was because those ‘advanced’ features were already at work in secret codebreaking computers. Many years after, when an interviewer asked Bettis what he felt was his most important contribution to the Naval Tactical Data System, he quickly replied “Hiring Don Ream.” [Bettis, Capt. Alfred M., Interview with D. L. Boslaugh 22 Mar. 1993]

Donald L. Ream

Because he had a degree in chemistry and physics, Ensign Donald L. Ream was posted to a nine-month course in radar, given jointly by Harvard and MIT, upon his graduation from Navy Officer Candidate School in early 1944. Upon completing the radar course, Ream found himself on the island of Mindoro in the Philippines where he was assigned to Motor Torpedo Boat Squadron 13 as electronics maintenance officer. In November 1945 the PT boat squadron was decommissioned and he was transferred to the minesweeper tender tender Chimo where he served as electronics officer until his discharge in June 1946.

Ream decided to return as a student to the College of William and Mary where he earned a degree in mathematics in June 1947. He accepted a job at the college as mathematics instructor and may have continued in this profession, but in mid 1948 he was approached by the navy codebreakers at Communications Supplementary Activity, Washington and recruited to join them because of his math degree and navy operational experience. He started work at the Navy Security Station in 1948, and his first assignment was the care and maintenance of a number of special purpose electronic codebreaking devices, most of which had come from the Naval Computing Machine Laboratory in St. Paul. These devices used vacuum tubes in enormous quantities, and one of Ream’s maintenance aids was a large wicker basket which he used to collect burnt out tubes. After he had gained experience in the functioning of the special purpose codebreaking devices, Ream was assigned as an engineer on the Atlas codebreaking computer project.

During his employment at CSAW Ream traveled frequently to become familiar with other digital computer developments worldwide. In the process he met and worked with a number of digital technology pioneers including Alan Turing and F. C. Williams -inventor of the electrostatic memory tube, at Manchester University, England, Maurice V. Wilkes - builder of the Cambridge EDSAC computer, Andrew Booth - builder of the University of London Arithmetic Relay Computer, Presper Eckert and John W. Mauchly - of ENIAC and EDVAC fame, Dr John von Neumann - after which the general purpose, stored program computer architecture is named, Seymour Cray - of NCML and later developer of supercomputers, and the navy’s own Grace Hopper - credited with inventing the precursor of COBOL high order programming language.

This photo of Cdr. Alfred M. Bettis and Donald L. Ream was taken in December 1963 at the Univac plant in St. Paul. Univac engineer Finley E. McLeod is showing them the Navy’s new CP-667 computer, a descendent of the NTDS unit computer made of first generation integrated circuits. Though it was the most powerful militarized navy computer yet built, it was just a proof-of-concept demonstration, and did not go into production. Photo from Capt Erick Swenson, courtesy of Unisys.

In 1953 Don Ream was recruited by Remington Rand Univac to be technical manager of their Arlington, Virginia, ERA 1101 computer center. However in 1955 Lieutenant Alfred Bettis managed to recruit Ream back to navy civilian service in the BUSHIPS Computer Design Section at the Navy Security Station. For the next three years Ream would work half time as project engineer for NTDS computer development, and the following four years full time in the same capacity. [Ream, Donald L., letter to D. L. Boslaugh, 24 Mar. 1993]  [Ream, Donald L., Interview with D. L. Boslaugh, 1 Nov. 1995] [ Graf, p IV-14]

Erick N. Swenson

It was June 1956 and Commander Svendsen now had to think about staffing his NTDS project coordinating office. As luck and fate would have it his first new project assistant, Lieutenant Erick N. Swenson - an old friend, walked in to Svendsen’s office just to pay his respects to his former boss. Lieutenant Erick Swenson had been drafted into the navy in August 1944, and after basic training was sent to radio electronic technician school, but came the end of World War II before he finished the school. With the pressure for new naval personnel relieved Swenson served as a fleet technician for only a year before he was released from active duty and entered the electrical engineering curriculum at the University of Rochester.

Swenson earned his degree in 1950 and went to work for Westinghouse Electric Corporation. His Westinghouse employment was cut short in February 1951 because he had stayed in the Naval Reserve and was recalled for active duty in the Korean War. Because he now had a degree in electrical engineering he was given an ensign’s commission, and designated an engineering duty officer. He then served for one year aboard the battleship Missouri as Electronics Division Officer, and a second year at the San Francisco Naval Shipyard where he was assigned to a group of electronics ship superintendents under the direction of Lieutenant Commander Edward Svendsen. Erick Swenson left active duty in June 1953 and went to work for Eastman Kodak Company in Rochester; but again he remained in the Naval Reserve. The reserve required yearly two-week active duty tours, and Swenson’s 1956 tour was in the Bureau of Ships. Thus he walked over to Cdr. Svendsen’s office to renew an old friendship.

Commander Svendsen remembered Eric’s vigorous drive when they worked in the shipyard. He also recalled that Erick really new how to get things done, and he could handle incredible amounts of detail. The Commander described the challenge of the NTDS project and asked Erick if he would like to work in his new coordinating office. If so, he could arrange his return to active duty with one phone call. Swenson was back on active duty in February 1957.

The Navy requires engineering duty officers to have a masters degree in engineering. After two years in the NTDS project Lt. Erick Swenson was sent off to the Naval Postgraduate School. In 1962 when he finished his studies, he was assigned as the BUSHIPS Technical Representative at the Univac plant in St. Paul. This March 1963 photo shows Lcdr. Swenson at the control panel of a production NTDS CP-642B unit computer. Photo from Capt. Erick Swenson, courtesy of Unisys.

Svendsen wanted to keep the coordinating office small, so each of his assistants had to handle a number of responsibilities. Lt. Swenson was to take on financial management, contracts management, engineering administration, shipboard equipment installation coordination, project standards, and establishing NTDS operator and maintenance training schools - including setting up their curricula. In Cdr. Svendsen’s project management concept, other people in the Bureau’s technical codes, contracting office, laboratories, and contractors would carry out the details, and Swenson’s job was to keep track of the details and make sure they got done when they needed to be done. Years later an interviewer asked one of the NTDS project officers if the project had used a Project Evaluation and Review Technique (PERT) system in its early days. The answer was: “Heck no, Swenson was our PERT.” [Svendsen, Capt. Edward C., Interview with D. L. Boslaugh, 3 Feb. 1995}

Joseph S. Stoutenburgh

Commander Svendsen had already prepared a list of qualifications he wanted in his project coordinating assistants and had passed it to the Engineering Duty Officer Assignment Branch in the Bureau of Naval Personnel (BUPERS) so they could review records and propose a list of potential candidates. One of LT. Swenson’s first tasks when he arrived at BUSHIPS in Feb. 1957, was to go over to BUPERS to review and summarize the records of the proposed candidates. This he did and also made up a prioritized list of the candidates. Svendsen reviewed Erick’s summaries and his priority list - with which he agreed. Their top candidate was Lieutenant Commander Joseph S. Stoutenburgh, presently teaching electronics at the U. S. Naval Academy. With another quick phone call to the flag level, Svendsen secured Stoutenburgh’s assignment as his second assistant project coordinator. [Svendsen, CAPT Edward C., Interview with D. L. Boslaugh, 3 Feb. 1995]

Ensign Stoutenburgh had graduated from the Naval Academy in June 1945 and received orders to the Cruiser Minneapolis operating in Far East waters. After a year at sea he was selected for the two-year MIT radar course, following which he was posted to the aircraft carrier Franklin D. Roosevelt in charge of the Electronics Division. In 1950, while aboard the “FDR” he was selected for an engineering duty designator and transferred to the Philadelphia Naval Shipyard for the next four years. The next assignment was to the Office of Supervisor of Shipbuilding at Bath, Maine, and then to the U. S. Naval Academy to teach electronics and to help write a textbook on electronic fundamentals.

Commander Joseph S. Stoutenburgh. Photo from Capt. Joseph Stoutenburgh

The Naval Academy was just a short drive from the District of Columbia so Lt Swenson volunteered to visit Stoutenburgh at the academy and give him advance word of his forthcoming orders. After hearing Swenson’s enthusiastic description of his new job, and being subject to a half hour stream of technical acronyms which he had never heard before, Stoutenburgh stopped the young lieutenant for a minute and observed that their must be another Joe Stoutenburgh they wanted because he was sure he was not qualified for the job Erick was describing. Nevertheless Stoutenburgh reported for duty at the Bureau of Ships in June 1957. Cdr. Svendsen had two assistant coordinator positions he wanted to fill; one managing development of the NTDS radar display subsystem, and one managing data links. Stoutenburgh opted to take charge of the display subsystem which included operator consoles and equipment to interface them with the radars and NTDS computers. [Stoutenburgh, Capt. Joseph S., Interviews with D. L. Boslaugh, 22 Oct. 1994 and 2 Nov. 1994]

Edmund B. Mahinske

Commander Svendsen was still looking for one more engineering duty officer to manage data link/communications subsystem development, and a draft magazine article about digital computers reminded him where he could find a young EDO to fill that billet. Svendsen had been asked to review the draft article and clear it for publication; instead he stamped it confidential and picked up the phone to arrange orders for his new assistant. Ensign Edmund B. Mahinske graduated in the same June 1945 Naval Academy class as Ensigns Alfred Bettis and Joseph Stoutenburgh, and like them he was ordered to a ship operating in the Western Pacific, in this case the cruiser Portland. In early 1946 he was accepted into the navy sponsored electrical engineering master’s degree program at MIT. Two years later, having his new master’s degree, with specialization in electronics, Mahinske was ordered to the destroyer Eversole where he served as electronics officer until 1949. In that year he applied and was approved for designator change to engineering duty officer. With his designator change and electronics specialization, Mahinske’s next set of orders were to the navy codebreakers computer development staff at Communications Supplementary Activity, Washington (CSAW). There he worked on special purpose electronic codebreaking devices, as well as the Atlas computers. In the process he got to know a young civilian engineer, Don Ream, who worked in an adjacent building, and who always had his vacuum tube collecting basket nearby.

Lieutenant Edmund B. Mahinske. Photo taken just before he was transferred from the computer engineering group at Communications Supplementary Activity, Washington, (CSAW) to the NTDS project office. Photo from Capt Edmund Mahinske.

 

Following CSAW, Mahinske served in electronics specialization billets in Japan and in a San Diego-based service squadron until mid 1955 when he was ordered to the Navy Electronics Supply Office (ESO) at Great Lakes, Illinois. Mahinske was fascinated by the extensive punched card accounting systems used at ESO, and while watching them in operation he realized that general purpose stored program computers, such as the Atlas computers at CSAW, could do a much better job, at less expense, than the punched card systems. He was inspired to write a magazine article on the untapped potential of digital computers where he described not only their ability to replace punched card accounting systems but also their ability to handle navy tactical functions such as ocean surveillance and combat direction. Mahinske had been careful to avoid mention of the navy Atlas computers and their codebreaking role, but he was aware that the draft article would have to be reviewed and approved by navy officials before it could be submitted for publication. Thus, the article found its way to Cdr. Svendsen’s office where he became concerned that if readers knew of Mahinske’s tour at CSAW, it could be an inference that the navy was using digital computers for codebreaking, which was top secret. He regretted having to classify the article, but he was glad to be reminded who could fill his remaining project coordinator billet. By August 1957, Mahinske was at work in the NTDS coordinating office. Commander Svendsen had his desired three naval officer assistants, and other than a project secretary, Frances Bartholomew, only one other person would be added to the original  office staff. That would be Lois K. Winker who came aboard the office to help Lt. Swenson keep track of the details of equipment procurement, production, delivery and installation.

Frances Bartholomew can take credit for giving the new system its name. Soon after she came aboard the project office she noticed that in the many letters and other paperwork the project officer and his assistants produced they were calling the new system different names. Some did use “Naval Tactical Data System” but then the next day the same person would call it by a different name. “Navy Tactical Data System“ was also used occasionally, and some called it the “Fleet Data System” or the “Consolidated Electronic Display System.” Frances told the assembled project officers she was becoming embarrassed that the system did not seem to have a name that they all agreed on. She also told them that no matter what they wrote in their drafts, the name “Naval Tactical Data System” was going to come out of her typewriter.  

The number of naval officers and civil servant managers in the NTDS office would never exceed six. He wanted each of his assistants to know at all times what the others were doing to foster good coordination, and so that any assistant could back up one of the others, or himself, when needed. A six day work week, and incessant travel would become standard for the coordinating office, and each knew they were expected to keep up the pace for at least five years. [Mahinske, Capt. Edmund B., Letter to D. L. Boslaugh, 31 July 1994]

Incidentally, Captain Svendsen never worked us to death; the individuals in the group were harder on themselves than Captain Svendsen might ever have been.  Capt. Edmund Mahinske. 5 April 1993

The coordinating office was now staffed with engineering duty officers who had operational experience (particularly in combat information center operations and combat direction), had engineering degrees in electronics, most had shipyard experience, most had industrial management experience, and perhaps most importantly of all had a good grasp of what the navy needed and how to build it. Even so, they knew they were facing formidable challenges, and many outside the project felt the technologies of digital computers and transistors were too immature for them to succeed. Many project opponents were comforted by this prediction. The closest thing to what they were expected to build was the Air Force Sage system with its warehouse sized computer centers, which had the further simplicity that they were not floating, pitching, and rolling, and constantly changing position with respect to each other. Many outsiders felt they could not possibly pull it off, especially in the incredibly short time of five years. 

Evolution of the Project Office

The reader will recall that Commander Svendsen’s reporting senior, Capt. Cassidy, the BUSHIPS Assistant Chief for Electronics, retained technical and management authority for the NTDS project, and that ‘recommendations’ from the coordinating office were just that; they were recommendations only. All authoritative directions to other Bureau offices, laboratories, navy field activities, and contractors had to be reviewed, approved, and signed out by Capt. Cassidy. This was not dictatorial on his part; it was just the way the Bureau did business. The concept of dedicated navy project offices having their own technical and management authority had not yet arrived on the scene; but this was about to change.  

By late 1957 Cassidy had developed complete confidence in the project coordinating office, and he was beginning to realize that the process of all directions and orders having to emanate from him was only slowing the project down. In an unprecedented move, with the blessing of Chief BUSHIPS, he gave the coordinating office the authority to directly direct, task, and review the activities of the supporting technical codes, navy activities and contractors. He also changed Svendsen’s title from project coordinator to project officer, and told him that from now on he only wanted short progress briefings and progress reports. They had complete technical and management decision making authority. Svendsen’s seniors had always told him he could have more office staffing any time he wanted it, but he opted instead to put the additional staffing, mainly in the form of engineering duty officers, at supporting laboratories, contractors, and later at installing shipyards. These engineers had instructions to review written tasking from the project office, recommended changes to tasking, review progress, and find problems. They were to communicate with the project office on a daily basis, and a problem was never to be allowed to fester. Svendsen considered these field representatives as part of the project office.

The only thing now not directly under NTDS project office control was authority to release research and development funds to performing activities. Cdr. Svendsen still had to arrange release of funds by the Assistant Bureau Chief for Research and Development. Even though the NTDS project office developed the annual project budgets and justified them to OPNAV (and OPNAV unfailingly came through with the requested funds) control of the funds was still vested in the Assistant Chief for R&D. This is just the way things were done in the Bureau. The process was time consuming and was an additional management step that could introduce errors and misunderstandings.  By early 1958 Cdr. Svendsen began to believe more and more in the ‘golden rule’ of project management, that being “he who controls the gold, makes the rules.” Finally in a BUSHIPS reorganization of 1958, Svendsen prevailed on his seniors to give his office direct control of releasing project funds to performing activities. This was done by giving Svendsen a ‘double hat’ wherein he reported directly to the Assistant Chief for R&D. In return he was authorized funds control and only had to let the Assistant Chief know what he had done. Thus by mid 1958 the NTDS project office had written authority to carry out what they had been informally doing by force of character and attention to project detail since the ‘coordinating office’ had been first formed. [Graf, p. VII-2] [Cherington, Paul W., Case Studies of TITAN and NTDS, National Academy of Sciences, Committee on the Utilization of Scientific and Engineering Manpower, 1964, p.2, pp IV-2-3]

The NTDS office was now a strong project office in all respects with full technical decision making, task issuance, and funds control authority. Svendsen’s agreement with his seniors and with his OPNAV sponsor office was; “When we need help, we will ask for it.”  This was not just an idle statement for they would have to request outside help many times, and they always got it in good measure, especially from their “parallel” project office in OPNAV. This would become especially important when the project officers had to secure cooperation from navy activities and organizations not under their direct control, such as the Naval Facilities Engineering Command, the Bureau of Naval Personnel, the Naval Training Command, the Operational Test and Evaluation Force, and the Bureau of Yards and Docks.

A Parallel Project Office

The Naval Tactical Data System was not just going to be a suite of new equipment aboard ships, it was going to need officer and enlisted personnel assigned to operate and maintain it, they in turn would need new training schools. It would also need new fleet computer programming centers because after BUSHIPS delivered and tested the first few systems, fleet personnel were going to take over maintaining NTDS computer programs and developing new ones. Determining manpower, training, and shore support facility requirements, and bringing them into existence was not BUSHIPS’ job. This work as well as justifying annual NTDS budgets and obtaining the money from Congress was the OPNAV sponsor’s job.

In a previous chapter we mentioned that the head of OPNAV’s Surface Type Warfare Division (OP-34), Rear Admiral William D. Irvin was assigned sponsorship of the new system project. Irvin was mindful that NTDS was going to be installed in about half the ships of the U. S. Navy, and in those ships it was going to be the largest single electronic system. Furthermore, it was going to interface with a number of other electronic systems on those ships; some of which their project managers and sponsors were not to happy to have to interface with the new upstart digital system. To add another dimension of complexity, some allied navies were also building digital shipboard command and control systems, and NTDS would have to be able to exchange tactical data with them. Establishing the required international data link standardization was also going to be OPNAV’s job, with BUSHIPS technical help.    

Radm. Irvin also realized that NTDS was already very controversial because of the concern of fleet officers that digital computers were going to be interposed between them and their sensor systems in an apparent decision making (or order giving?) role. This did not set well with them. In an early informal survey of fleet line officers, Irvin’s staff found that about 19 out of 20 line officers were opposed to NTDS; some emotionally so. Irvin wisely decided to set up a small dedicated project staff in his Combat Systems Branch, OP-345 headed up by Capt. William E. Kuntz, who would work only on NTDS. As in the BUSHIPS project office they would be assigned for the duration of the expected five-year development life, and as already agreed with BUSHIPS, instead of time-consuming formal project reviews, they would work on a daily basis, in great detail, with the BUSHIPS project managers to stay abreast of the development. [Graf, p IV-23] [Swallow, Capt. Chandler E., Letter to D. L. Boslaugh, 16 Nov. 1994]

William E. Kuntz

William Kuntz is not new to this story. In 1942 as a Lieutenant he had helped Irvin McNally build his radar maintenance school at Pearl Harbor, then when McNally got his surprise orders to the Radar Development Branch in the Bureau of Ships, Kuntz had relieved MCNally as officer in charge of the radar maintenance school. Although an unrestricted line officer he had specialized in radar and CIC operations. In 1956 he was heading up RADM Irvin’s group in charge of sponsoring shipboard search radar development and CIC improvements until he was assigned to head the NTDS project staff.

Horace Stanwood Foote

In late 1956, Commander H. Stanwood Foot was working in the OPNAV Combat Systems Branch where he was in charge of shipboard combat information center policy; that is until he was informed by his boss, Capt. Kuntz, that Foote was going to be the interim OPNAV NTDS project officer. Cdr. Foote had been involved in at-sea combat direction since the early days of WW II even before the days of combat information centers; when they were called “air plotting rooms” and the officers who manned them were called fighter direction officers (FDO).

On 7 May 1942 Ensign Stan Foote was one of three assistant FDOs aboard the aircraft carrier Lexington and on that day they were involved in the first sea battle in history where aircraft carriers fought each other. It was called the Battle of the Coral Sea. The Japanese lost the light carrier Shoho, but the next day planes from the carriers Shokaku and Zuikaku scored hits on Lexington starting fires that eventually caused tanks of aviation fuel to explode and forced ship abandonment. Ens. Foote had to go over the side and an American destroyer plucked him from the water later that day. After his rescue, Foote was returned to the U. S. where he was assigned as combat information center (CIC) officer of the escort carrier Santee. After about a year’s experience with the new concept of a combat information center, he was assigned as CIC officer of the newly constructed heavy Essex Class carrier, Shangri-La, where he ran one of the first CICs designed into a new-construction ship. Because Shangri-La was the flagship of a carrier task force, Foote also became Carrier Task Force 38/58 CIC Officer (CICO).

The aircraft carrier Lexington on fire on fire following the Battle of the Coral Sea, 8 May 1942. Ensign Stan Foote would be getting ready to go over the side. U. S. Naval Historical Center photo.

At the end of hostilities Lcdr. Foote transferred to the new construction heavy carrier Lake Champlain where he served as Task Force CICO, and then was ordered to the flagship carrier Midway to serve as Carrier Division 6 CICO. By the mid 1950s Foote was a specialist in combat information center operations and layout and was ordered to the Combat Systems Branch (OP-345) to work on CIC improvement programs. In late 1955 he began working with Lcdr. William Gaienne, an aviator specializing in air intercept control, designing a new, larger CIC layout which grouped specialists such as air intercept controllers, surface gunnery coordinators, and anti-submarine operations in their own separate modular areas in the CIC, and which surrounded a central display and decision area where senior officers could easily communicate with each specialist group. After this project Foote took charge of the CIC policy group until late 1956 when he was informed he was going to be the initial OPNAV NTDS project officer. [Foote, Capt. H. Stanwood, letters to D. L. Boslaugh on 4 Oct. 1994, and 10 April 1995]

Lieutenant H. Stanwood Foote. Photo taken in September 1943 when he was Task Force 38 Fighter Director Officer in the Western Pacific, Photo from Capt. H. S. Foote.

Chandler E. Swallow

In 1953 Lieutenant Commander Chandler Swallow began a three year tour aboard USS Northampton, a cruiser sized tactical command ship, as electronics officer. Northampton had been commissioned in March 1953 under the command of Capt. William D. Irvin, and as a tactical command ship had aboard at least one each of every type of advanced electronic equipment that had started development in late WW II. Only one of this ship type was ever built, and as such, in addition to serving as a command center afloat, the ship served as a platform to evaluate new electronics equipment.  When Capt. Irvin was promoted to Rear Admiral he was ordered from the Northampton to take charge of the Surface Type Warfare Division in OPNAV. Radm. Irvin was well aware that as his former electronics officer on Northampton, Lcdr. Chan Swallow was versed in an unusually wide variety of electronics systems and equipment, and would be an ideal OP 34 staff member to monitor the many electronic devices being developed under his sponsorship. Irvin requested that Swallow be given orders to his staff when his Northampton tour was up, and soon after his arrival in OPNAV Irvin decided Swallow would be an ideal member of the new OP 34 NTDS project office. Here he would take on sponsorship responsibility for the NTDS display subsystem as well as the NTDS computer program. In this later assignment he would be in charge of coordinating the establishment of two new fleet computer programming centers at San Diego and Dam Neck, Virginia. [Swallow, Capt. Chandler E. Letter to D. L. Boslaugh, 16 Nov. 1994]

The massive combat information center aboard the tactical command ship Northampton was the largest and most advanced CIC built around manual radar plotting techniques. The ship carried at least one each of every advanced navy electronic system or equipment of the early 1950s. In addition to serving as flagship for various afloat commanders, it was a floating electronics evaluation laboratory, and designated the President’s National Emergency Command Post Afloat. U.S. Navy photo

 

Captain Parker F. Folsom

As CDR. Joe Stoutenburgh once noted, the Naval Tactical Data System was going to be “plunked down right in the middle of everything.”  To be effective NTDS had to have tentacles reaching out to sensor systems such as the search radars, sonars, and electronic warfare systems. It would make demands

Commander Chandler Swallow. Photo from Capt. Chandler Swallow

When this writer asked Captain Chan Swallow if he ever received a medal or other citation for his contributions to the Naval Tactical Data System, he responded, “Oh no, I got something much better when I left the OPNAV NTDS project office: command of a radar picket destroyer escort, The USS Kretchmer.” The ship operated on the Northern Radar Barrier sending radar inputs to the USAF SAGE continental air defense system. Note the AN/SPS-8 height finding radar and special communications antennas on the rear deckhouse. U. S. Navy photo.

on shipboard communications, exterior and interior. It would send processed target information to gun and missile systems; and even in some cases to anti-submarine weapon systems. It would have a strong impact on the way air interceptor control was done, and it would interoperate with new air tactical data and Marine tactical data systems. It would also heavily impact the way the surface line officer community commanded their ships. In short NTDS was going to impact on the way a number of navy officer communities did their job, most of whom were at least very leery of the new system, and some downright opposed.  In addition to their NTDS sponsorship duties, Stan Foote and Chan Swallow were given another job. They were to do their best to scope out the sociological impact NTDS was going to have on the Navy and its various interacting officer communities, and they were to develop a proposed list of the needed qualifications and qualities in the permanent OPNAV NTDS project officer. In addition to lists of technical background and operational experience, Foote and Swallow told their boss, now Captain Paul Van Leunen, that the project officer would need the negotiating and diplomatic skills of an ambassador, and the rank influence of at least a vice admiral.

Van Leunen commenced a search and finally found the man he wanted, unfortunately not a Vice Admiral, but well stocked with all the other recommended capabilities. Parker F. Folsom was one of the few, perhaps the only, line officer captains who knew what a digital computer was. This was by virtue of his having worked on the Office of Naval Research “logistics computer” project which was the second life of the secret relay-based “Baby Atlas” computer that had been built by Engineering Research Associates to prove out some of the first Atlas codebreaking computer’s design features. Also, while at the Naval War College he had written computer programs for the Navy Electronic Warfare Simulator, a vacuum tube digital computer. Folsom was also well connected in navy internal politics and was considered a visionary.

Capt. Folsom reported to OPNAV in December 1957, and a few months later he took over Capt. Van Luenen’s job when Van Leunen received transfer orders. Folsom, however continued to personally carry out the OPNAV NTDS project officer function. He was regarded by the BUSHIPS NTDS project officers as a strong and convincing NTDS advocate. He was especially admired for his ability to think and talk extemporaneously at length in support of the system, prompting Commander Joe Stoutenburgh to remark proudly of him, “He’s the only guy I know who can talk while inhaling.” [Swallow, Capt. Chandler E. Letter to D. L. Boslaugh, 16 Nov. 1994]  [Mahinske, Capt. Edmund B., Letter to D. L. Boslaugh 15 April 1993]

A Sample of their Work

One of the OPNAV sponsors’ tasks was periodic presentation, justification, and defense of the NTDS budget before the House Armed Services Committee (HASC). Normally the OPNAV NTDS project office prepared the details of the budget for the Deputy Chief of Naval Operations for Surface Warfare, Vice Admiral Lawson Ramage, Radm Irvin's boss, who presented the budget to the HASC. In the 1958 hearing sessions Vadm. Ramage was ill on the day that the NTDS and combat information center improvements were to be presented, and he directed that the officer who had prepared the details of that part of his budget should speak before the HASC. That officer was Commander Stan Foote, and he had no particular problem in his presentation until he came to funds for developing the NTDS computer.  Foote was interrupted by Congressman Flood of Pennsylvania who complained that he knew that the navy already had many types of computers and he did not see why another one was needed for NTDS. Foote explained that, yes the navy did already have numerous computer types, mostly used for gun and missile fire control, but they were analog special, purpose devices, each having a very narrowly defined function. Furthermore, in any event, an analog computer having the capabilities of the NTDS digital computer would be incredibly complex and expensive, and would probably fill half a ship.

Commander Foote went on to explain that if even a minor change would be needed in an analog NTDS computer it could only be done by physically redesigning and rebuilding the computer, an expensive and time consuming process. The digital NTDS computer’s functions, however could be changed by loading in a new computer program, a process that only took a few minutes. It became quickly apparent to Foote that the committee members did not at all grasp the concept of a computer program. His semi-technical description of a computer program evoked only more blank stares, and Foote realized he had to come up with an analogy, and quick.

His inspiration was rolls in a player piano. Foote noted how a player piano could be “reprogrammed” to play any kind of music by simply putting in another roll. Congressman Flood grasped the analogy well enough to reply that Foote could have his digital computer money. When Foote reported back to OPNAV the next day, Vadm. Ramage was so impressed with Foote’s explanations to the Committee that he directed that from then on Foote would defend that part of the budget. The next year a large portion of the budget was for NTDS computer programs, and Foote asked the Committee members if they remembered the piano rolls from last year. Seeing heads nod, he said this year we need the funds to start developing the piano rolls. They authorized the money without any more questions. [Foote, Capt. H. Stanwood, Letter to D. L. Boslaugh 15 May 1995] We have reviewed how the management of the NTDS project was organized, its modus operandi, and the persons who carried it out. Now it is time to return to the main story of how the Naval Tactical Data System was built, and the contractors and Navy organizations that did it. We will go back to the fall of 1955.

No Prime Contractor?

In September and October of 1955 Commanders Svendsen and McNally, accompanied by two of their sponsors, Radm Irvin and Capt Kuntz, visited a number of contractors and other organizations throughout the U.S. and Canada. They had two goals: first to seek advice on how they should go about designing and building the Naval Tactical Data System, and second to size up the contractors’ ability to participate in developing the system. In seeking technical advice they called upon Lincoln Labs at MIT (The SAGE system manager), the Applied Physics Laboratory at The Johns Hopkins University, the Navy Electronics Lab in San Diego, the Naval Research Lab in Washington, D.C., the Control Systems Lab at the University of Illinois, Cornell Aeronautical Lab in Buffalo, NY, and Royal Canadian Navy labs. In Canada they particularly asked for briefings on their discontinued DATAR system - which would have been the Canadian version of NTDS.

When visiting contractors they tried to assess the contractor’s ability to design, integrate, and test a complex system, their knowledge of radio data communications, their knowledge of digital technology, their ability to develop a complex computer program, and their ability to develop a digital computer driven radar display system. The normal approach to developing a complex military system at the time was to establish a prime contractor who was knowledgeable in all the requisite technical areas, who could guide the integration and testing of a complex system, and who could either design and build the needed equipment or competently guide subcontractors in doing so. [Graf, R. W., p III-5]

McNally and Svendsen were disappointed in finding no one potential prime contractor having the needed capabilities in all technical areas. They noted that industry experience in building and programming digital computers, let alone a transistorized one, was particularly thin. Bell Telephone Laboratories seemed to come the closest so what they were seeking, but Bell Labs made it clear they were saturated with work on the Air Force’s Nike air defense missile system. It became clear to the two commanders that the highest probability of success was for the Navy to serve as its own prime contractor. The navy had two laboratories well versed in electronics, radar systems, radio communications, system integration, and to a certain extent computer development and programming. These were the Naval Research Lab in the District of Columbia, and The Navy Electronics Lab in San Diego.

Against the advice of many, McNally and Svendsen decided that one of these two laboratories would serve as system integration and testing agent, and the Bureau of Ships would contract directly with equipment developers in their areas of expertise to develop the new equipment. The selected laboratory would also  undertake studies in various areas of technology as tasked by the Bureau to help resolve technical unknowns; and there were quite a few. This was an unprecedented approach to developing a new large scale system, and it meant that the BUSHIPS project officers would be responsible for making many technical decisions as well as the normal management and administrative details of project management. [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.60]  [McNally, Cdr. Irvin L., letter to D. L. Boslaugh 20 Apr. 1993]

Both of the candidate laboratories were technically well qualified to take on the proposed system and integration and test role, but NEL had two additional qualifications. NEL was located just across the street from the navy’s Combat Information Center School on Catalina Blvd. in San Diego, and the school had at least one of every kind of presently operational shipboard search radar. An NTDS engineering test site would need access to live search radar inputs, and thanks to McNally’s earlier efforts signal cables from those radars already fed radar distribution switchboards in the lab. Second, and perhaps even more important, San Diego was a Navy town in which resided many navy activities, home ported ships, and operationally experienced naval officers and senior enlisted.

A view of Point Loma, the home ofthe Navy Electronics Laboratory. These barracks were built during World War II and became the work spaces of the scientists, enginers and other workers of NEL. The laboratory antenna testing range can be seen in the background. From web page “Where In The World Is 32.42N 117.14W? by George Edw. Seymour”

Mcnally and Svendsen were well aware that most navy line officers were opposed to the new system, and one of their strategies to help overcome that opposition was to get a number of line officers, as well as senior enlisted, involved in developing it. They had already found that once a line officer understood what the system did, and perhaps even more important what it didn’t do, they usually became supporters. They chose NEL as “lead laboratory” because of the local availability of experienced navy personnel who could be detailed to work on system integration and test. This would have the additional benefit of working their at-sea operational knowledge into system design, especially into the operational computer program, as they helped work out the kinks and wrinkles. In late 1955 the two project officers visited the Navy Electronics Laboratory and presented their plan to the commanding officer and his leading civilians, who agreed to take on the role.

NEL headquarters building under construction in March 1950. U. S. Navy photo

The two commanders briefed Radm. Irvin on their idea, and soon got the full backing of the Chief of Naval Operations for transferring the navy personnel to NEL. [McNally, Irvin l., Interview with D. L. Boslaugh, 20 April 1993] At the height of NEL’s effort, there would be 77 line officers and about the same number of enlisted working at NEL on NTDS integration and test. [Navy Electronics Laboratory, San Diego, CA, Letter to Chief of Naval Personnel , Subject: Officer Personnel Assigned to NTDS; status of, 1330 Ser. 1700-23 Dtd. 21 Apr 1960]         

It would have been a predictable disaster if the project had tried to assemble its first suite of developmental equipment aboard a ship. There were just too many technical unknowns; too many things that had never been tried before. The project officers were sure that the new system would not immediately come to life and work the first time it was turned on, and it would probably tie up a ship for a year or more while unwillingly serving as a floating laboratory. The adverse publicity thus gained would be fuel for the projects many detractors, and the project most likely would have failed. They felt it was essential to assemble the first prototype at a land based test site in a laboratory environment where they could “build a little and then test a little” in a controlled environment. Thus NEL's most important task would be to build and operate an NTDS land based test site. The prototype system was to have authentic live inputs, such as the live search radar inputs, wherever possible. Where live interconnections to interfacing shipboard systems was not possible, the laboratory was to devise realistic simulators to represent the interfacing systems.

The laboratory engineers were also to visit the equipment contractors frequently to monitor equipment development. A streamlined reporting system was to be developed so that the NEL engineers could quickly field problems and issues, and their recommended solution to the project office for resolution. The project office would normally also ask the contractor for their view of the matter, and thus in the would be able keep a running check on the progress of the contract. They made a point of never letting a problem fester; the quicker the resolution the better. [Conlin, Paul A., ed., “Pentagon Profile - This Month Capt. Edward C. Svendsen, USN, Armed Forces Management, Vol 7, No 10, July 1961, p. 34]

The Main Industry Players

Univac Division of Sperry Rand Corporation

In late 1955 when the NTDS project officers made their nationwide tour of electronics contractors they found only a few who had interest in trying to develop a militarized, transistorized digital computer. Exceptions included Philco corporation who was working on a transistorized version of the Navy Atlas codebreaking computer - the desk sized SOLO cryptanalyst’s “personal” computer; however, at the time Philco was having problems with SOLO. [Snyder, Samuel S., Influence of U.S. Cryptologic Organizations on the Digital Computer Industry, National Security Agency, Fort George G. Meade, MD, May 1977, p. 18] IBM had built a transistorized version of their vacuum-tube IBM 604 electronic calculator and expressed interest in developing the NTDS computer. [Pugh, Emerson W., Memories that Shaped and Industry - Decisions Leading to the IBM System/360, The MIT Press, Cambridge, MA, 1984, ISBN 0-262-16094-3, p. 18]

While the Navy survey group was at Univac Division of Sperry Rand in St. Paul, company engineers showed them two full scale transistorized computers in process: the TRANSTEC demonstration computer and the Air Force’s ground based ATHENA guidance computer for the TITAN I missile system; neither of which had yet successfully run. The Navy group was particularly interested in the Air Force’s high reliability requirement for the ATHENA. But, the sad truth was, nobody had yet successfully run a full scale transistorized digital computer, not to mention a highly reliable militarized one. McNally and Svendsen adjudged that Univac was the most advanced, and they were impressed by the transistor reliability investigation that Univac was doing for the Air Force.

The TITAN I missile system ground based ATHENA guidance computer, built by Univac Division of Sperry Rand Corp. was fully transistorized and had a stringent reliability requirement. The machine had two separate memories, a small 24-bit magnetic core unit of 256 words for storing transient data, and a magnetic drum of 8,192 words which stored the computer program and various constants. Photo from Univac archives

The Navy team was also appreciative that a Navy contract/technical surveillance group was already at the Univac plant in St. Paul. Minn. Although the BUSHIPS Naval Computing Machine Lab had been disestablished by 1955, a smaller Bureau of Ships Technical Representative (BSTR) office had taken its place. It was staffed by a few engineering duty officers and civil servant engineers to monitor computer development work BUSHIPS was doing for the National Security Agency.

Although IBM and Univac both had experience in developing computer programs, McNally and Svendsen still felt Univac had the edge, and recommended that a contract be issued to Univac to develop the NTDS unit computer, its initial tactical programs, and accompanying militarized peripherals such as magnetic and paper tape units, manual keysets, and analog to digital converters. The prototype NTDS computer programs  would eventually be turned over to the Navy Fleet Computer Programming Centers for further development and maintenance. The December 1955 NTDS contract also included systems analysis and study tasks.  [Graf, pp V-3-V-4]

Mr. Seymour R. Cray, a Genius With Transistors

Univac decided to put all NTDS tasks under a single project manager in the St. Paul Military Systems Group which was headed up by Frank Mullaney; who in turn, reported to the general manager of the Remington Rand Univac Computer Division, William C. Norris. Mullaney decided that the new NTDS Department would be split into two groups, hardware development and computer program development, each led by an assistant department manager. To get a quick start on the NTDS work, Mullaney moved a number of senior engineers from the ATHENA Computer Department including the lead ATHENA computer designer, Seymour Cray who was to be department head.

Seymour R. Cray, designer of the prototype NTDS unit computer and later builder of supercomputers. Charles Babbage Institute, University of Minnesota photo

  Cray had joined Engineering Research Associates in 1951 upon graduation from the University of Minnesota and was first assigned to work on the navy Atlas II  codebreaking computer. Within a few years he had risen meteorically to senior design engineer in charge of ATHENA. As a prelude to ATHENA his engineers had designed both the MAGSTEC magnetic amplifier-based computer, and the transistorized TRANSTEC computer to determine whether magnetic amplifier switching or transistors would be used in ATHENA. Transistors won. [Murray, Charles J., The Supermen - The Story of Seymour Cray and the Technical Wizards behind the Supercomputer, John Wiley & Sons, Inc., New York, 1997, ISBN 0-471-04885-2, pp 50-53]

Cray picked engineer Malcom Macaulay to head the computer programming and systems engineering tasks, but elected to lead the unit computer development team himself. About two weeks after Univac signed the NTDS contract, the Bureau issued its first task which called for an investigation of what highly reliable solid state computer components were available throughout American industry. Macauley’s first task from the Bureau was to start with McNally and Svendsen’s NTDS Technical and Operational Requirements paper and expand it into a detailed technical shipboard system description and a tactical computer program requirements description.  The system description was required to highlight where specific studies would be needed to determine how to interconnect a central digital system to other shipboard systems such as search radars, sonars, gun and missile systems, the ships gyrocompass and stable vertical sensor, the unerwater speed log, communications radios, and other sensors like electronic warfare systems. Macaulay assigned 25 engineers to these two tasks. [Lundstrom, David E., A Few Good Men From Univac, The MIT Press, Cambridge, MA, 1988, ISBN 0-262-12120-4, p 39]

The Bureau’s first task to Cray under the unit computer line was to demonstrate the feasibility of inter computer data transfer; the most critical aspect of the unit computer concept. The first step in the demonstration was to be the connection of Cray’s MAGSTEC and TRANSTEC computers to a common memory; through which they successfully performed high speed inter computer data transfer. After this, in January 1957, Cray started detailed hardware design of the unit computer. [Cherington, pp 4-6] 

Every item of electronics in the U.S. military is assigned a unique nomenclature code under the Army/Navy Joint Service Electronics Equipment Designation System. The project officers were not allowed to assign a code themselves, but rather submitted a description of each new device to a central DOD authority who then decided upon the nomenclature code. One can see that the AN nomenclature system was then not ready to encompass general purpose stored program digital computers, as the assigned nomenclature came back: U   standing for the platform carried aboard, and assigned ‘general utility’ S   standing for the equipment type, and assigned ‘special or combination of types’ Q  standing for the purpose, and assigned ‘special or combination of purposes."  The new computer was the 17th piece of equipment to be given the USQ designation and thus became the AN/USQ-17 computer.

The project office had specified that the new computer was to have a 32-bit word length because the number 32 is a power of two which would make design easier and make the most efficient use of transistors. The TRANSTEC computer was a 24-bit machine, and Cray could already see that a 32-bit computer was going to be a severe design challenge using the best available germanium surface barrier transistors of the time. He built test circuits and found the best they could support with the power output of germanium transistors was a 30-bit word.  Cray convinced Commander Svendsen that he was going to have to accept a 30-bit word length. Don Ream, the Bureau’s lead computer engineer, later acknowledged that if any one other than Cray had designed the unit computer, the Bureau probably would have had to accept an even shorter word length. [Lundstrom, p 136]  Commander Svendsen had called for a memory size of 32,768 (two to the power of 15) words in the unit computer’s core memory, and this Cray was able to accommodate.

There are basically two ways digital equipment can communicate with each other: serially where the bits in a transmitted message word travel over a single conductor, one after the other, and in parallel where each bit in the word has its own conductor and all bits are transmitted simultaneously. Serial transmission requires a much higher data rate per conductor than does parallel transmission and thus are more demanding of input/output electronic circuits and of the transmission conductor. Furthermore, there was almost nothing known about shipboard digital communications, thus Cdr. Svendsen opted to take the more conservative approach of parallel communications among the subsystems of the Naval Tactical Data System. This being in spite of the wrist-thick, multi conductor digital transmission cables that would be required. The project had to take a ‘make it work’ approach.

The NTDS project office’s conservative decision to use parallel digital communication within the system necessitated thick multi conductor cables containing 33 twisted pairs of wires, plus spares. It also called for fairly massive cable interconnect switches to allow system setup and reconfiguration. This is the resultant SB-1299 Interconnection Panel. To get an idea of scale, it is about four feet tall. U. S. Navy photo

Svendsen and most of his officer assistants had worked in naval shipyards and they well knew the perplexing and frustrating problems attendant to trying to establish a common ground for electronic equipment by grounding it to the metal of the ship’s hull. Again they took a ‘make it work’ approach. They specified that every equipment item in the system would be connected to a common ground cable running through every compartment having NTDS equipment. This cable would have a cross section equivalent to a one-inch diameter copper rod and every equipment unit would be connected to it with a large cable. Even though the cable weighed thousands of pounds and added undesirable topside weight, the project officers resisted every attempt or “beneficial suggestion” to cut its diameter. It would prove to work and was cheap insurance. [Ream, Donald L., interview with D. L. Boslaugh, 1 Nov. 1995]  [Lundstrom, pp 47, 56, 62-63]

The unit computers would have to support system operation in ‘real time.’ The system would have to input and process data on over 100 target tracks simultaneously and could not lag behind actual events. They were to be the heart of a battle management system, so inability to keep up with actual events could mean death and disaster. Any processing delays had to be less than human reaction times. This meant that the machines had to be able to input and output large amounts of data with minimum effect on the central processing unit, which was very busy doing other things.

Cray’s  input/output scheme transferred a block of data into or out of memory with only one instruction. Once started the external device would communicate directly with the computer memory with no other involvement with the central processing unit (CPU). Furthermore, to relieve the CPU of data transfer tasks, Cray called for the external subsystems to initiate the data transfers by using two additional conductors in the parallel interconnect cables which called for input and output data requests. These external requests did not stop the CPU, but rather set ‘flags’ in the computers executive routine sub program (today called an operating system) which notified the operational program to service the requests in a preset priority order.  Svendsen, Capt. Edward C., and Ream, Donald L., Bureau of Ships, U. S. Navy. “Design of a Real-Time Data Processing System,” Proceedings of the International Federation for Information Processing Congress 65, Vol 1, May 24-29, 1965, Spartan Books, Inc., Washington, D.C., Library of Congress Card No. 65-24118, 1965, pp 291-] The results of the shipboard systems engineering task indicated that each unit computer should have more input/output channels than other computers of the day; in fact 12 output and 18 input. All channels would use parallel transmission but would be of varying width depending on their function. About half were 30-bit channels for communicating with the major subsystems. Some were 6 bits for smaller peripherals, and some were 15 bits for analog to digital converters.

Even though Seymour Cray was also responsible for developing the militarized NTDS peripheral equipment such as magnetic tape unit, paper tape unit , system control panel, manual keysets, keyset central unit, analog to digital signal converters, experimental automatic radar video processor, and a modified teletype unit, as well as systems engineering studies and the prototype NTDS operational computer program, he elected to do most of the unit computer detailed logic design himself. This extended down to individual transistorized circuit board designs and computer inter board wiring layout. In these endeavors, Cray devised programs for a Univac 1103 computer (commercial Atlas II) to automate circuit design and to work out inter board wiring runs fixing the location of each circuit board in a chassis to minimize overall wiring length. [Lundstrom, p 24]

In July 1957, Cray horrified the NTDS project officers by telling them that he was leaving Univac to become engineering director if the new Minneapolis computer company, Control Data Corporation (CDC), which had been formed by a number of former univac engineers who had become disgruntled with Sperry Rand management. Cray was good enough to inform Cdr. Svendsen of his departure before he made it public, and he also promised to stay at Univac until he had completed detailed design of the Unit computer. Other key engineers on the Univac NTDS team were also leaving to go to CDC. It was not a happy day for Svendsen. Upon Cray’s leaving, Univac assigned Dr. Robert R. Coon as NTDS Department Manager.  [Graf, p V-15-18]  [Lundstrom, p 37]

Seymour Cray at the console of Control Data Corporation’s first 1604 computer. The U.S. Navy bought this computer and installed it at the U. S. Naval Postgraduate School, Monterey, CA. The author learned programming on this machine. Charles Babbage Institute, University of Minnesota photo

In the summer of 1957 Univac engineers began assembling the first unit computer. They built only one at a time so that they could gain lessons learned from the earlier machines. In spite of the loss of Cray and other lead engineers, the tasks stayed on schedule. The first four prototypes were laid out like a horizontal freezer chest, with main access door on top. Fourteen electronics chassis fit vertically into the main; and they found raising and lowering just one chassis was a two-man effort. This experience drove them to rearrange the layout so that prototypes five and six were stood on end so that the heavy chassis could slide in and out like drawers. [Graf, p V-17]

Serial number 1 AN/USQ-17 transistorized and military hardened computer with covers removed. One of the sliding printed circuit card chassis has been raised to show the rows of small printed circuit cards. The vertical sliding electronics chassis would prove to be difficult to handle, which inspired a redesign of the last of the series which involved tipping the machine on its end to allow the chassis to slide out like drawers. Photo from Capt. Alfred M. Bettis, courtesy of Loral Corporation.

The entire AN/USQ-17 Computer set consisted of the unit computer at left, the operating console (non militarized) at center, and the Friden Flexowriter automatic typewriter with paper tape punch and reader at right. Photo from Donald L. Ream, courtesy of Unisys.

AN/USQ-17 serial number one arrived at the Navy Electronics Lab test site in March 1958 - on schedule. When NEL and Univac engineers lit it off it met all navy specifications. Unit computers two and three were completed in mid 1958, and one was shipped to NEL for the next critical test. The other machine remained at Univac for performance testing, wherein it was found that it could execute a sample tactical computer program at a rate of about 50,000 instructions per second. Seymour Cray’s machine was truly fast for its day. The critical test at NEL was to demonstrate high speed inter computer data transfer with their two unit computers. This was accomplished in the late summer of 1958 without the use of any buffer between the two machines, using only an inter computer cable. Many experts in the computer field had warned Svendsen it could not be done, thus this was not only a key milestone crossed, but a great relief to the project officers.  Univac delivered the remaining three unit computers to the test site in the spring of 1959. [Graf, p V-9] [Remington Rand Univac, Division of Sperry Rand Corporation, Functional Characteristics of the NTDS Unit Computer, 17 Oct. 1957, p 1] 

Of the six prototype AN/USQ-17 computers the last two were repackaged so that they stood upright. This not only saved deck space, but also made handling the sliding electronic chassis much easier. Photo from Donald L. Ream, courtesy of Unisys.

 

A New Animal. the Seagoing Operational Computer Program

The BUSHIPS NTDS project officers felt they had sold their souls to the devil in making a compromise with OPNAV that placed the two new fleet computer programming centers under the Commanders in Chief, Pacific and Atlantic, rather than as field activities of the Bureau of Ships. They were concerned that they had lost control of the one most critical element of the system. The original NTDS concept had called for the programming centers to be under BUSHIPS control, but staffed by experienced fleet naval officers and senior enlisted - because the programs were so tightly related to the technical functioning of the NTDS equipment. OPNAV felt otherwise. The programs were going to manifestations of tactical battle doctrine and had to be under fleet control. There was also the thought that this would also help mollify those many line officers who were still very leery of having a computer tell them how to manage an anti-air battle.  [Swenson, Stoutenburgh, Mahinske, p 57]

The compromise called for the Bureau to develop the programs for the land based engineering test system and the service test ships. Then the programs would be turned over to the fleet commanders for future improvement and maintenance. Thus in December 1959 the Bureau added a task to the Univac contract to write the seagoing service test programs as well as the engineering test programs. In early 1956 Univac engineers had already begun to translate specifications from their systems engineering studies into computer program code for the engineering test system. There had not been time to develop a higher order language compiling system for the unit computers; or even a lower order assembly routine to help automate the program writing, so the programs for the USQ-17 computers at the test site were written in the ones and zeros of unit computer machine code.

The programmers were under such intense pressure to deliver program sequences to the test site that they were still performing system engineering tasks to define program requirements and specifications while actually writing the computer programs. The situation made Cdr. Svendsen and Univac management realize that intense discipline was going to be needed in documenting program requirements, specifications, the resulting programs, and perhaps most importantly documenting and keeping track of all changes in all three areas in the face of such a fluid environment.  [Svendsen and Ream, p 292] The Bureau added a task for Univac to prepare a computer programming manual laying out a detailed and extremely disciplined process for keeping track of program documentation and changes. The manual also spelled out required practices, prohibited practices, and standard conventions. For example the programs would be written in modules each of which accomplished a clearly defined function. Each module was to have only one starting point and would communicate only with the executive routine and no other module. An example of prohibited practice was self modifying code (which the programmers seemed to love to do) because of the difficulty they caused in reconstructing what happened in case of a system crash. [Remington Rand Univac, Division of Sperry Rand Corporation, Naval Tactical Data System Programmers Guide for Computer and Equipment, Publication PX 1493, for Navy Department, Bureau of Ships, Contract NObsr 72769, 1 Mar. 1961]

Real-Time Programming

The Naval Tactical Data System was to be a ‘real-time’ system, meaning computer responses to input and output requests from the subsystems had to be short as compared to human reaction times. The unit computers had to exchange data with as many as ten different equipment groups in real-time, and some of those groups could have up to 40 separate input/output devices as did the display subsystem. [Chapin, George G., “Programming a Shipboard Real-Time Computer System”, Sperry Engineering Review, Summer 1963, p 32] Thus the first challenge facing the programmers was designing the executive control routine that would schedule the initiation of program modules. The requirement was: each request had to be fulfilled within its reaction time requirement under peak system loading conditions. To begin, the programmers worked out the expected processing demand of each module and allocated the modules to unit computers to best even out peak computer loading. There was no particular sequence in which the various program modules were to run, and no given order in which the computer was to service the external subsystems such as the display subsystem ot the radio communications subsystems. As already mentioned, when a program module had been executed the program returned to the executive routine. This routine contained three tables containing continuously updated data on the subsystems and modules. The data included: the last time a module had been executed or a subsystem had been served, various flag indicators, alerts, subsystem data requests, subsystem data ready indicators, and priority indicators. When a function had been completed and the program had returned to the executive routine it scanned the three tables and established the next task to be undertaken based on a quick computation of the priority of each task, and then servicing the task which had risen to highest priority. The designers of the executive routine worked out the main control loop, that scanned the status tables and computed priorities, which required only 12 instructions. [Svendsen and Ream, p.296]

 The Display Subsystem Program

Of the NTDS subsystems the display system would be the most challenging to the programmers because of its complexity and many functions. The computer would send the same tactical picture to all of the operator displays in the combat information center and would have to refresh that picture at least 15 times per second (20 times per second was the goal). A refresh rate of less than 15 per second caused an annoying, and operator fatiguing, flicker of the computer placed symbols. Thus the executive routine was to scan the input and output data request tables and repaint the symbols fast enough that less than one fifteenth of a second would elapse between an operator action and the computer’s response. Since the response was less than human reaction times, the system would appear to the operators to be running in real-time. [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/SPS32 and AN/SPS-33, for the Navy Department, Bureau of Ships, Contract NO bsr-77604, 28 Feb. 1961, pp 12,47,49]

One of the most difficult of the display subsystem program modules was track smoothing which was intended to smooth out errors in radar target inputs caused by the human radar input operators and also position errors inherent in the radars. The programmers found that even though the human eye and brain combination can relatively accurately fair a line through a scattered set of data points with no apparent effort, it was much harder to program a computer to do so. Furthermore their difficulty was compounded because airplanes can make turns in flight which could be interpreted as an input error. Fortunately the Air Force SAGE programmers could give the Navy the benefit of their experience.

For the NTDS computer programmers there was no such phrase as ‘data base’  in the mid 1950s. They simply set aside an area of memory in one of the unit computers called ‘track stores.’ For the service test ship programs the BUSHIPS goal was to store data on 64 own-ship tracked targets (air, surface, and submarine) and 64 remote tracks from the tactical data link. Approximately 90 binary bits were needed to store complete data (as listed in the following table) on one air target. In addition to target tracks the track stores were also the repository for interceptor pre-launch data sets, interceptor performance descriptions, local and remote electronic countermeasures ECM) bearing lines,  ECM fixes, stationary geographic reference points, moving reference points, address assignments for the data links, and track number block assignments for the various participating units. [Naval Ship Systems Command, NTDS Project Office, NTDS Operational Program Capabilities as a Function of Ship Class. (Condition 10, 1968]  [Hughes Aircraft Co., Interim Engineering Report No 6, p 13]

NTDS Track Stores Data Elements

The Data Communication Subsystem Program

Even though all NTDS ships would have the equipage to control the inter computer radio data link (which was named the A Link, and later NATO Link 11) only one ship at a time in a given task force exercised ‘net control’, and it was usually, but not always, the task force commander’s flagship. The net control ship would establish the broadcast mode (round robin, roll call, or single unit broadcast), and would assign blocks of track numbers to participating units. These units would then assign track numbers to locally tracked targets. Net control could also assign tracking areas to specific ships and could direct some ships to report more often than the regular reporting interval. The data link would operate as a ‘simplex’ net, which meant all stations would transmit and receive on the same frequency, and only one unit would transmit at a time. Once the A Link was up and running it would function fully automatically with no operator intervention needed. [Hughes Aircraft Co., Interim Engineering Report No 6, p 13]    One of the principal goals of NTDS was to create a single tactical situation picture available to all participating units; and the vehicle by which this was to be done was the A Link. The data link would allow all participating units to share target tracking data, weapons status and weapons engagement assignments. All target tracks on all participating platforms were eligible for transmission over the A Link, however in many cases more then one ship could be tracking the same target, so transmitting all tracks in all track stores would be wasteful. The programmers devised a means whereby only the data on the ‘best’ tracks would be transmitted. Best in this case would be determined by a new parameter they called ‘track quality.’  A quality measurement would be computed for each target track and put in the track stores along with all other track data. They devised a fairly simple, but ingenious, method of determining track quality. It was based primarily on how many radar inputs had been made on a particular target during a measured number of radar scans. For example if a tracking input had been made for each of the past ten scans, the track would have a high quality. Before transmitting any tracks in local stores the computer would search its remote and local track stores to find any tracks in both stores that had the same track number. Then the computer would feed to the A Link only two types of tracks: 1. local tracks not having been reported by any other participating unit, and 2. local tracks having a better track quality than had been reported by any other unit. Thus, the tracks reported by all ships were the best in the task force. [Hughes Aircraft Co., Interim Engineering Report No 6, p 13]

It was necessary for the Naval Tactical Data System to not only have a compatible A Link message structure with the Marine Tactical Data System, the navy’s Air Tactical data System, and the SAGE system; but also with the Royal Navy and the Royal Canadian Navy who were also developing seagoing tactical data systems. The means of establishing this standardization was the Tactical International Data Exchange (TIDE) message formats. There were a number of TIDE message formats to handle all tactical eventualities. In order to make best use of the limited high frequency radio bandwidth some of the messages were crafted to be transmitted less frequently than others. For example target speed varies more slowly than target heading or location so target speed messages would be transmitted less frequently. [Hughes Aircraft Co., Interim Engineering Report No 6, p 14]  Commander Stanwood Foote of OPNAV and Lieutenant Commander Edmund Mahinske of the NTDS project office would represent the NTDS project on the TIDE Committee. 

Air Force SAGE sites and Marine Tactical Data System sites would be fixed in one location, however ships and aircraft are constantly moving. Thus one of the more important TIDE message formats was participating unit location, and one of the more important NTDS computer sub programs was ‘surface operations’ intended to keep track of own ships location. It would be initiated by entering the best available ships navigation position at a keyset and would be continuously updated by a dead reckoning program module into which ships heading was fed from the ship’s gyrocompass and speed from the underwater speed log. The dead reckoning calculations could even be ‘tweaked’ by operator entries of estimated wind set and current drift.

Accurate knowledge of ship’s position was absolutely vital to the operation of NTDS. When a ship broadcast target track coordinates on the A Link, these coordinates were with respect to the broadcasting ship, and it was the responsibility of the receiving unit to recompute the coordinates with respect to each receiving ship. Thus knowledge of the position of the broadcasting unit as well as own ship was needed. If the positions were not accurate the received target coordinates could be interpreted by the receiving ship as a separate target and would be painted on the radar screen as a target moving parallel to the originally reported target; causing great confusion.

In addition to the inter computer data link (A Link) the McNally/Svendsen Technical and Operational Requirements paper also called for a means by which NTDS target data could be transmitted to non NTDS equipped ships. This was to be accomplished using regular navy teletype communication circuits and standard navy teletypes modified to communicate with the NTDS computer. This was to be called the ‘B Link’, wherein the track information would be transmitted in human readable format and plotted by hand at the receiving ships. It would later be found that the B Link teletype was a handy way for operators to communicate with the unit computers when running special system testing programs.

One of the few Navy standard stock equipment items in the Naval Tactical Data System were standard communications teletypes modified with an adapter which allowed them to communicate with the NTDS computer. The adapter box is mounted at lower left side of the unit. Primary function of the teletype was to send NTDS track information to non-NTDS ships. U. S. Navy photo

Threat Evaluation and Weapons Assignment Programming

The threat evaluation and weapons assignment (TEWA) program had two primary functions: 1. rank all target tracks in order of their computed threat to own ship or to a defended area, and 2. Recommend the most appropriate weapon to engage a selected target. The TEWA module was to be programmed using anti-air tactical doctrine, the laws of physics, the rules of geometry and logic, a large dose of common sense, and the known or estimated capabilities of potential opponent’s weapons such as how far would an iron bomb travel when dropped from a given altitude at a given speed, or the ranges of various air launched anti ship missiles.

The OPNAV NTDS project officers were well aware that this aspect of the program would clearly cross into the sphere of operational line officers, and that the best way to mitigate their discomfort would be to request a number of operational commands and other activities to assign, or nominate, technical and operational experts in anti-air warfare to work on a TEWA requirements committee. Lcdr. Chandler Swallow of the OPNAV office and Lcdr. Joseph Stoutenburgh of the BUSHIPS NTDS office would chair the committee, and one of their first steps would be to tabulate and codify all the existing rules of anti-air warfare. After that they would devise additional rules that could take advantage of the speed and memory of the NTDS computers. Their final product was to be a set of TEWA performance specifications they could give to the Univac programmers. [Stoutenburgh, Joseph S., interview with D. L. Boslaugh, 2 Nov. 1994]

The TEWA committee was made up of 13 members including Stoutenburgh, Swallow, Univac systems engineers C. J. Homan and P. N. Sampson, and engineers and scientists from nine other activities including BUORD, BUSHIPS, the Navy Electronics Lab, The Applied Physics Lab of Johns Hopkins University, Bell Telephone Labs, the University of Illinois, and Naval Ordnance Test Station, China Lake, CA. It is interesting to note that all members, other than Swallow and Stoutenburgh, were civilians, but they were acknowledged experts in anti-air weapon systems, fire control, and air target tracking; and they enjoyed the full confidence of their sponsoring operational commands. The TEWA programming schedule called for the Univac programmers to start writing code in only a few weeks, so the TEWA committee had to work diligently and fast. Alec Radcliffe of the Applied Physics Lab volunteered to to take input from all committee members and organize it. From that input he wrote the detailed TEWA computer program specifications. Stoutenburgh and Swallow later told this writer they regarded Radcliffe as the ‘guiding light’ of the TEWA committee. [Swallow, Capt. Chandler E., letter to D. L. Boslaugh, 16 Nov. 1994]

To compute the threat of a given hostile or unidentified target, the TEWA program would first have to determine with respect to a particular defended area the attacker’s closest point of approach (CPA) and projected time of CPA. The program would then, for each target, take into account such factors as target speed, altitude, weapons carried (if known), target aspect angle, raid size, and whether the target was confirmed hostile or just unidentified. From this information the program would have to compute the relative threat of each oncoming target and rank the targets in priority order of threat, and then present the most threatening targets to the ship’s weapons coordinator. Next the program would have to rapidly assess the high-threat target’s locations with respect to screening ships and available airborne interceptors. For each of these weapons carrying platforms, considering the attacker’s altitude, course and speed, the program would have to determine for each platform whether it carried weapons that could reach the target before it dropped or launched weapons. From these computations the program would have to show the location of the recommended weapons platform and where the recommended weapon would impact the attacker.

At the request of the ship’s weapons coordinator (SWC) the program also had to be able to generate trial intercepts from other selected ships and interceptors, and where the impact points would be. The SWC could then decide which weapon should be paired with the attacker, or he could assign additional weapons. For each weapons/target pairing assignment the program had to generate a pairing line on the NTDS displays of all participating units to let all know what weapons had been assigned to what attackers. TEWA would turn out to be the largest subprogram in the system. [Remington Rand Univac, Division of Sperry Rand Corporation, Introduction to Digital Systems - Volume 1 of 2, Course Guide prepared by Univac for Naval Ship Systems Command, 9 Aug. 1971]

Interceptor Control Programming

The basic function of the interceptor control program module would be to help a shipboard air intercept controller (AIC) coach a fighter/interceptor to an advantageous firing position on an aircraft target. To begin with, the AIC would have to enter interceptor pre-launch data via his manual keyset for all interceptors under his control so that the computer would know the interceptor type, its performance characteristics, its weapons load, and fuel status. Once the AIC had selected a particular attacker for intercept, the program had to generate trial intercepts by available interceptors to determine the feasibility of intercept, and which interceptor was best positioned. Once the AIC selected a particular interceptor to engage the target the computer would compute interceptor speed, heading, and altitude orders, and would also cause a pairing line to be drawn between the interceptor and the intended target.

  There would be two possible ways of sending to the interceptor the orders displayed on the AIC’s auxiliary readout indicator. He could read off the speed, heading and altitude commands and give them to the pilot by voice radio, or if the interceptor was equipped with an AN/USC-2 data link (also called Link 4) the controller could automatically send the commands via the data link. At the interceptor, the pilot could elect to have the commands displayed on a cockpit display, or he could switch to a fully automatic mode whereby the data link directly controlled the craft’s autopilot. If using the USC-2 link, the NTDS computer would automatically update the interceptor’s computer with data on the target’s altitude, speed and position, and the interceptor would send back to the NTDS computer its altitude, airspeed, heading, and its position with respect to the controlling ship. Once the aircrew could ‘see’ the target, either visually or with their own radar, the aircrew took over control of the intercept.  [Hughes Aircraft Co., Interim Engineering Report No 6, p 12]

In 1961 the McDonnell F4H-1 Phantom was the Navy’s newest fighter type. Phantoms were equipped with the AN/USC-2 data link which enabled an NTDS shipboard computer to send steering commands directly to the aircraft’s autopilot. U. S. Navy photo

Most of the Univac NTDS computer programmers were engineers who at one time might be designing a circuit or at another time might be writing computer programs. The NTDS project managers as well as Univac management found that, like engineers, the program writers were never satisfied with their product and always wanted to improve it; sometimes spending too much time on one small subprogram, to the detriment of completing the module. Management thus found they had to set firm dates for program ‘builds’ and save improvements for later builds. The rule of the game was they had to have ‘something’ ready to run at each build milestone. Management also maintained a firm insistence on keeping program documentation updated and accurate; in particular documenting changes. We will find in the next chapter that this requirement for thorough computer program documentation would save the project from disaster. [Svendsen and Ream, p 296]

NTDS Operational Program Composition

Collins Radio Company

When they wrote the NTDS technical and operational requirements document, Commanders McNally and Svendsen worked out an estimate of how much data link traffic would be needed to tie together all the NTDS computers in a task force during a saturation air attack. They came up with about 1,500 English words per minute which was the the equivalent of 15 teletype circuits operating in parallel. This, in turn represented 650 binary bits of tactical information per second. They also estimated that as much again binary information would be needed for data link control, management, and error detection and correction. The total of 1,350 bits per second would be no particular challenge for a well designed high frequency radio. [Remington Rand Univac Division of Sperry Rand Corp., St. Paul, MN, The Naval Tactical Data System (Second Draft), PX 1272, 6 Apr. 1959’ p 19]

The Bureau of Ships Communications Design Branch, in mid 1956, sent out to the American radio communications industry a request for proposals (RFP) for a prototype NTDS high frequency (HF) data radio and a data terminal set (today called a modem, which is short for modulator/demodulator) which could connect the radio to the NTDS computer. Of the proposals that came back, the one from Collins Radio Company at Cedar Rapids, Iowa, seemed to practically anticipate the NTDS data transmission requirement. Collins was already an industry leader in long range HF radio communications by virtue of their expertise in ‘single sideband’ radios in which they put all the outgoing energy in one of the transmitted sidebands by using clever engineering techniques to suppress the power consuming carrier wave (which transmitted no intelligence), and also by suppressing the other sideband (which transmitted the same information that was in the non-suppressed sideband). Single sideband could therefore achieve much greater ranges than conventional HF radios.

Collins had also made breakthroughs in data transmission by their efforts to improve teletype communications, which is a form of binary data transmission. They had perfected a patented modulation technique which they called ‘Kineplex’ phase modulation that could transmit a large amount of binary data over an HF channel with minimum errors. Instead of modulating the transmitted wave to carry information by changing its amplitude (AM radio) or by changing its frequency (FM radio) they transmitted binary information by modulating the phase of the outgoing wave. It seemed to be perfect for digital data transmission. At the time, the Bureau of Ships was already under contract with Collins to buy some experimental HF radios using the Kineplex modulation technique in an experimental program to improve HF teletype communications. They called the project High Capacity Communications (HIGHCAPCOM). The NTDS project in September 1956 elected to buy three modified HIGHCAPCOM single sideband radios and four data terminal sets incorporating the Kineplex modulation technique to connect an input/output channel of an NTDS computer to the radio. [Graf, p III-6]  [Swenson, Stoutenburgh, Mahinske, p 58]

Communications between the unit computer and the data terminal set were to be in the standard NTDS 30-bit parallel mode. The data terminal set took the 30 parallel lines two at a time and fed them to 15 human audible tone generators, having much the same sounds as a touch tone phone. Signals on each pair of lines were translated to shift the phase of the tone generator to one of four quadrature phases. A two-bit binary number can be any one of four combination of ones and zeros, so each tone generator could represent a two-bit binary number, and the 15 generators in parallel could represent a 30-bit word. The human ear can not detect phase changes in a musical note, but at the receiving data terminal the 15 musical tones were fed to 15 very sensitive electromechanical resonators, each ‘tuned’ to one of the 15 tones. The resonators could be quenched and then quickly reactivated as each parallel word was received. When reactivated, each resonator would vibrate in phase with the newly received tone. Electronic circuitry could detect the phase of vibration with respect to a reference tone, and the circuitry would convert the received transmission burst as a 30-bit parallel signal to be sent to the receiving computer. The radio and data terminal combination could transmit seventy five 30-bit words per second. [Collins Radio Company, Kineplex, Collins High Speed Data Transmission System, Oct. 1957, p 9]

When the people at the Army/Navy Joint Service Electronics Equipment Designation Office read the data terminal set description, they decided it matched the description of an air dropped sonobuoy used to detect submerged submarines by transmitting their sounds to an aircraft. They thus assigned it the AN/SSQ-29 designation of a sonobuoy. In the spring of 1958, Collins delivered three of the data terminal sets and the three HIGHCAPCOM radios to the Navy Electronics Laboratory at San Diego. NEL installed one suite in the NTDS land based engineering test site, one suite in a communications truck, and the remaining one aboard their research ship USS Rexburg. The remaining data terminal set was sent to the Univac plant in St. Paul for use in computer program development and testing.

USS Rexburg a former patrol craft was turned over to the Navy Electronics Laboratory as a research ship, with armament removed and a heavy boom installed at her stern to handle equipment for underwater sound experiments. An NTDS A Link radio and data terminal set were installed aboard Rexburg to allow A Link testing between the NEL shore based engineering test system and Rexburg at sea. National Archives photo

The Collins Radio AN/SSQ-29 NTDS primary data link data terminal set that connected the unit computer to the Link 11 radio. The functions performed by this modem are today performed by a single integrated circuit chip. The data link control panel is mounted at left. Rockwell International Corporation photo.

Hughes Aircraft Company

Lieutenant Commander Joe Stoutenburgh was not only in charge of the TEWA committee but his primary responsibility was developing the NTDS display subsystem. He would have been very happy to have adapted the displays used by the Air Force SAGE system but evaluation showed that the ‘charactron’ cathode ray tubes used for their radar displays had a thin, fragile stencil mask built into the tube to generate their very clear, crisp symbols. Testing showed the symbol mask could not stand up to the shock and vibration rigors of shipboard life. He would have to find some other technology to draw the symbols which would be placed on the scope faces under computer command. [Stoutenburgh, Capt. Joseph S., letter to D. L. Boslaugh, 14 July 1995]

Mr. Fred Russell  of the The Bureau of Ships Radar Design Branch was assigned as the NTDS point of contact for the Radar Branch and in in April 1956 he issued an industrywide request for proposals which described the capabilities of the display system they wanted for NTDS. (By June of 1957, Russell would be working full time on the NTDS display subsystem.) Ten proposals came back and the most responsive appeared to be one from the Hughes Aircraft Co. Data Processing Laboratory. Hughes engineer L. G. Durham was developing digital radar displays for the U. S. Army’s Nike and Hawk anti-air missile systems and could see where his display technology might suit the NTDS requirement. The Hughes proposal was technically convincing, but also higher in cost than the other proposals. Hughes Aircraft Ground Systems Group was primarily an Army contractor and had no track record with the Navy. Cdr. Svendsen decided that he and the proposal evaluation team would visit the Hughes facilities at Fullerton, CA, to get a better feeling for their capabilities and the technologies involved in their proposal. The Hughes engineers were convincing, and in June 1956, only two months after issuing the request for proposals, the Bureau awarded a contract to the Hughes Data Processing Laboratory for developing the NTDS display subsystem. [Graf, pp VI-1, VI-2] [Cherington, p6] [Swenson, Stoutenburgh, Mahinske, p 57]

BUSHIPS obtained the nomenclature AN/SSA-23 Data Display group for the subsystem, and it would be built with the following design goals:

1. Use transistor electronics wherever possible.
2. Make the display consoles flexible and general purpose with as few console types as possible.
3. Show electronically generated, computer placed, symbols in company with raw video, and not obscure the raw video.
4. From each radar, derive the most possible information such as ability to measure target or raid size.
5. Use ‘quick action’ buttons to allow operators to send decisions and commands to the computer program. [Graf, p VI-5]

The project officers realized that the technology of automatic radar target detection and tracking was not sufficiently mature for use in NTDS. For one thing it was highly demanding of precious computer memory. Target inputs from the radar scopes would have to be picked off manually and entered into the computer program. The key to doing this would be a quick acting, accurate, manually controlled, cursor that an operator could move about the face of the radar scope.   From July 1956 to January 1957 the Hughes team made a detailed review of available technologies and planned out the overall approach to developing the display subsystem. During the same interval, Mr. Everett McCown of the Navy Electronics Lab led a team of engineers writing detailed performance specifications for the subsystem. NEL had already investigated various ways that an operator could move a cursor around on a cathode ray tube including light pens, manual joysticks, and manual track balls; and had concluded that the best compromise between accuracy and speed of placement was the track ball. Their specification thus called for the use of a track ball on each console. The cursor would be a small electronically generated circle with a dot at the center. They called it the ‘ball tab.’ [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, p 57]

In January 1957 the Hughes team commenced detailed design of the display equipment units. At first they decided to package the individual displays in the same manner that radar repeaters had been for years. That is, with the cathode ray tubes pointing straight up with faces horizontal; however they realized that operators would either have to stand up or sit on tall stools - not a very comfortable situation for a four-hour watch. They decided instead to devise a desk style console before which the operators could be seated in chairs. The faces of the radar display tubes would be inclined slightly from the vertical. User consoles, as distinct from data input consoles, were also to be provided with an ‘auxiliary readout indicator’ standing next to the console, and on which could be displayed information about a particular track selected by the console operator. Auxiliary information would include such measures as course, speed, and altitude. [Hughes Aircraft Company, Final Engineering Report for Data Display Group AN/SSA-23(XN-1), p 49]

A Hughes AN/SSA-23 prototype NTDS operator plan position indicator (PPI) console built for evaluation in the Navy Electronics Laboratory NTDS engineering test system. The cigarette lighter can be seen at the front-center of the console. Hughes Aircraft Co. photo.

The display subsystem would contain not only operator consoles, but would also include a separate electronic unit called the symbol generator which could electronically generate a repertoire of symbols which the computer could then place at specific locations on the consoles. For example a round symbol designated a friendly target, which would be further differentiated a submarine by showing only the bottom half of the symbol,  a surface ship by showing the whole symbol, and an aircraft by showing only the upper half. Square symbols would represent unidentified targets, and diamond shaped ones represented hostiles. The repertoire also included target/weapon pairing lines, missile range circles, target velocity leaders, defended zone circles, air corridors, pointer symbols and a host of others. [Hughes Aircraft Company, Fullerton, CA, Navy Tactical Displays, undated publication, pp 14, 17]

In order for the NTDS computer to compute accurate target speeds from sequential radar inputs of a given target, it had to know the precise time the radar sweep painted that target on the scope. The problem was, a busy operator might not get around to ‘ball tabbing’ a particular target blip until many seconds after it had been painted, and this would raise havoc with target speed calculations. The solution was called a radar azimuth converter which took in an analog measure of antenna bearing and converted it to a digital number which was fed continuously to the computer. Then from a knowledge of an inputted target’s bearing, the computer could quickly deduce the time the target had been painted on the scope.

Hughes AN/SSA-23 height/range console evaluated in the NEL shore-based engineering test system. The cigarette lighter in the front of the ‘bullnose’ did not make it into the next generation shipboard AN/SYA-1 service test system. Hughes Aircraft Co. photo

Other display group equipment would include a ‘central data repeater’ which connected the display subsystem to the unit computer, and a radar switchboard. By means of the switchboard an operator seated at a console could turn a selector switch to tell the switchboard which radar he wanted to feed his console. In addition to conventional ‘plan position indicator’ radar consoles, each display group would have one or more height size consoles by which operators could enter altitude data from height finding radars. The height size console would also have a feature by which a radar blip could be greatly expanded to help reveal whether that blip might be composed of a number of aircraft, and in some cases even allow counting the number aircraft.

The project officers wanted as few different types of display consoles as possible to hold down cost and enhance system flexibility. They wanted consoles that could be used for more than one CIC function by turning a selector switch to that function to tell the computer what the console function was to be. Hughes analysis showed, however, that building a lot of functionality into one console type would drive up its cost. The project thus reached a compromise of seven console types:

1. Threat evaluation/weapons assignment - user
2. Interceptor control - user
3. Command - user
4. Detector/tracker and tracking supervisor - input
5. Identification - input
6. Height/range analysis - input
7. Size analysis - input

[Hughes Aircraft Company, Final Engineering Report for Data Display Group AN/SSA-23(XN-1), p 4]

Today smoking a cigarette in a shipboard combat information center would be a ‘captain’s mast’ offense. But the sociology of smoking was much different in the mid 1950s; so different that Hughes, as a matter of course designed a cigarette lighter into each console. There was a reason for the lighter; that is the concern that lighting a match in the darkened CIC might temporarily blind the operator. The cigarette lighter would make it to the Navy Electronics Lab shore based engineering test system, but no further.

Hughes Aircraft would deliver the first units of the engineering test display subsystem to NEL in August 1958 - a little more than one year and half after start of detailed design, and by March 1959 would have delivered all 13 prototype display consoles and accompanying equipment. [Hughes Aircraft Company, Final Engineering Report for Data Display Group AN/SSA-23(XN-1), pp 6-9]  By the spring of 1959 all the required unit computers, their accompanying peripheral equipment, the prototype radio data link equipment, and the prototype display subsystem had been delivered to the Navy Electronics Lab engineering test site. NEL engineers had already been working feverishly to get the test site ready for the prototype equipment, including acquiring and installing interfacing shipboard systems and equipment or devising realistic simulators to represent interfacing shipboard systems.

The reader may go on to the next chapter in the history of the Naval Tactical Data System by clicking on this link: Chapter 5 - Testing the Naval Tactical Data System.