MPDS: Solving the Message Processing Problem Afloat

It is a truth almost universally acknowledged that military organizations push a lot of paper and pass a lot of messages. During the Cold War, keeping those messages moving was a vital but herculean task. The need to make sure senior commanders could reach the nuclear deterrent in a timely manner was behind a vast investment in strategic command and control  The practical impact of failures in strategic communication was apparent during attacks on the USS Liberty and the USS Pueblo in 1967–8, when vital messages sent via the military’s digital data network (AUTODIN) were processed to slowly to be of use on the scene.

The messages involved in the Liberty and Pueblo crises at least had high priorities. What about the vast numbers of significant but not critical messages being passed? To give a convenient example, in 1979 the US Pacific Command’s Operations Directorate received 2,000 messages a week and took two hours just to pass a priority message from the AUTODIN switch to the relevant action officer. Cutting through this morass of messages required automation, which the various branches of the military adopted with varying levels of alacrity.

One attempt was the Military Message Experiment, which gave CINCPAC’s Operations Directorate a set of computer terminals to automatically distribute and display messages received via AUTODIN. The Military Message Experiment was interesting because it was built to borrow many of its features from the early e-mail functionality on ARPANET, but it was hardly the only attempt to automate message processing. Nor did it take on the most challenging conditions: the message processing problem didn’t stop at the water’s edge either.

US Navy ships had special challenges when it came to handling message traffic. To avoid giving away their positions to enemy direction-finding, ships avoided two-way communications with the rest of the armed forces communications network. Instead, the Navy operated a chain of radio stations ashore that sent out a steady stream of radio messages. Ships listened to the “Fleet Broadcast” that went out over these channels and staff in each ship’s main radio room (known as “Radio Central”) copied down the messages relevant to them, then distributed them to recipients elsewhere aboard ship. A communications readiness exercise held by the First Fleet in October 1966 demonstrated how easily this system was overwhelmed when the number of messages surged from peacetime to wartime levels, with most of the trouble coming when the messages had to be handled by human operators.

The solution was automation, but while automating the message processing and broadcast process ashore was relatively simple, doing the same afloat was far more complex. Ships had limited space to spare, limited staff with which to operate, and a range of environmental hazards that included rough seas, shock, humidity, and even salt water. Luckily, the core component for solving the problem was already at hand.

The Naval Tactical Data System (NTDS) was a revolutionary computerized system that automatically shared tracking information on targets between ships, built around a series of transistorized general-purpose computers: the UNIVAC CP-642. The first computer to be operated regularly at sea, the CP-642 was the size of a large refrigerator, contained more than 10,000 transistors mounted on 3,810 circuit cards. The first installations began in 1961 and the system proved reliable. NTDS proved that you could put a computer on board a warship and expect it to operate effectively in a critical capacity.

USS Oklahoma City, underway 9 December 1960 US Navy Photo NH98662

USS Oklahoma City, underway 9 December 1960
US Navy Photo NH98662

So when the Naval Electronics Laboratory (NEL) at Point Loma, San Diego was asked to design a system to automatically receive, process, and then distribute messages, they borrowed the already-proven CP-642 as its processing core. The first experimental installation was installed aboard the Seventh Fleet flagship USS Oklahoma City (CLG-5) less than a year later in May 1967. This version of what was being called the Message Processing and Distribution System (MPDS) wasn’t fully automated, but it was successful enough that NEL was asked to design a fully automated system to install on the first Nimitz-class aircraft carrier in 1975.

Bow view of the US Navy Aircraft Carrier USS NIMITZ (CVN 68) underway off the coast of Southern California. DoD Photo.

Bow view of the US Navy Aircraft Carrier USS NIMITZ (CVN 68) underway off the coast of Southern California. DoD Photo.

The automated MPDS (designated the AN/SYQ-6) was built from three CP-642 computers, plus disk drives, CRT consoles, and a backup teleprinter. It listened to (or “guarded”) the relevant fleet broadcast channel, recorded the messages, checked to see which ones were directed to that ship, and then forwarded them to the appropriate remote terminal elsewhere on the ship. And it made a big difference in helping the carrier handle an average communications load of more than 2,500 messages a day. The MPDS worked well enough to be installed on the next two Nimitz-class carriers, the USS Eisenhower and the USS Vinson, too.

Of course, there were some rough spots. The electronic storage for past messages was insufficient, forcing the crew to print off messages as backups. The original software could only read US-formatted messages, not NATO-formatted ones, which made allied operations problematic – that issue was fixed, at least partly, with a patch. And, once carriers were having to process more than 3,500 messages a day the system started to reach its saturation point.

So why have you never heard of the MPDS? The answer is that the system was always a temporary fix for a broader problem. In 1973, having demonstrated the potential of communications  automation afloat, Naval Electronic Systems Command (NAVELEX) began designing the Naval Modular Automated Communications System (NAVMACS). NAVMACS was a modular system that would fit into all the Navy’s ships, not just its carriers. It would use a newer computer, the UYK-20. And its largest installation format, the NAVMACS V-5, would have all the same remote terminal features that MPDS featured. Once NAVMACS entered service, MPDS vanished into obscurity.

Sources: References to MPDS are pretty scattered; an official history of NEL at Point Loma mentions the Oklahoma City installation in brief, and a NAVELEX brochure that discusses plans for the automated system. The main source for this posting, apart from numerous handy pieces of information at, was a master’s thesis on the system’s development by Kenneth Lee Whitten written in 1981 (and available many places, including the Naval Postgraduate School).


2 thoughts on “MPDS: Solving the Message Processing Problem Afloat

  1. Interesting article….in the ’80’s I was a DS on the Eisenhower and MPDS was my system. Once in a while I’ll think about it and do a google search. This is the first real reference I’ve seen aside from the Whitten paper (which is pretty good also!).

    • Hi Rick,
      I was a DS maintaining MPDS on the Oklahoma City (CLG5) from 1968-1971. It would be interesting to compare notes about the differences between the two systems.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s