It is sad to say but the trend in the DoD today with regard to open mission systems is not new when it comes to the hopeful belief in a technology that can solve multiple problems. Most technologist skip the best way to fight in combat and jump straight to a technology that can make things faster, smaller, and more integrated. They believe that somehow this jump to technology will make things better and magically increase combat power. That, of course, is the great promise and the free lunch. One such jump to technology is a belief in standards that drive open mission systems and subsequently open architectures. Both concepts have been in the game of buzzword bingo around the Pentagon for many years. It’s important to note that I believe in standards. Without them, we would have technological chaos and no internet…plus a railroad system riding on a national network of rails where the width of the track was decided by the Roman Empire chariot wheel separation. When we ask for standards, we must understand what we are asking for in the context of their employment. The great promise of Network Centric Warfare (Admiral Cembroski), the Navy Cooperative Engagement Capability (CEC), decades of Joint Integrated Fire Control (JIFC), and the long pursuit of such capability through the Joint Integrated Air and Missile Defense Organization (JIAMDO) were all envisioned by open standards upon which everything can communicate with everything else. Others organizations have also been enamored by the promise. Everything we build should talk to everything we build. It is the warfighting equivalent to the Internet of Things (IoT). Or so it goes. Well just what do open mission systems and open architectures actually mean and what are the ramifications of such technology (and buzzwords) on the future of DoD force structure and our ability to fight wars?
In his recent article for Defense News, General Goldfein the current Chief of Staff of the United States Air Force (CSAF) put forth his vision. He has embraced the buzzwords and authored a short article entitled, “Future wars will be won with open mission systems”. The article draws you in for its upbeat promise. Because, on the surface, the concept of open mission systems has merit. Unfortunately, it is a red herring from the stand point of what we should be doing. And it is an inefficient use of resources in the wrong hands. I’m saddened that the article came out of the highest echelons in the Air Force and wish someone with some background in the technology would have helped him edit the piece for accuracy. For the record, it’s not easy to critique the CSAF. One day I may work for the USAF again. For now, I can only fall back on often-quoted phrase about speaking truth to power...”Hey power, please listen, national blood and treasure is at stake”. So let us dive in.
The idea of integrated mission systems stemming from open architectures has been around since the very first soldier on the battlefield tried to coordinate fires or pass intelligence data through whatever means possible. You brought smoke signals? Oh hell, I brought two tin cans and some string. Skipping a few thousand years of military history, the poetic “One if by land, two if by sea”, speaks volumes to the merit of broadcasting a signal (open) that could get a coordinating word out to an intended recipient (integrated). Interestingly, this type of communication is known as a cue. It’s a tip-off that something is coming. Not a whole lot more information is contained in the signal but nevertheless it’s a signal of huge strategic value, or could be. It’s not the tactical signal that enables a Minuteman to shoot a Red Coat. As it turns out, forever captured in Revolutionary lore by poet Longfellow, the midnight ride of Paul Revere and his lanterns in the Old North Church, were redundant to the operation that evening in Boston. The lanterns were a back-up plan. The primary conduit for the signal was a messenger traveling across the Charles River by boat. Consider for a moment the bandwidth available in the two approaches, One, “the messenger” and two, “the lanterns” in the Old North Church. The messenger, with eyes on the movement of troops out of the Boston Common would be more accurate in every detail. Let's call that analog. On the other hand, the lanterns possess only a binary signal...and it’s important to note that one light or two lights is a binary signal with better positive affirmation than one light or no lights. Call it an early form of error correction.
Obviously, by saying binary my foreshadowing about coming digital technology is showing. That said, almost everything one needs to know about military communication is contained in this simple example. Anyone who has ever sent a text message tends to know that an email is superior. And a phone call is superior to an email. And a video chat is superior to a phone call. And a face to face meeting is superior to a video chat. But is that really true? Of course not. As a society, we would not be texting as much if texting did not provide a very relevant service at a low data rate. And an analog, face to face meeting, is expensive. But the difference is huge. It is the difference between attending Cirque du Soleil in person and watching it from your iPhone on YouTube. Paul Revere, from his flip phone (he never upgraded), standing behind a tree, peering upon the Boston Common, would probably have sent a text. And then followed up with an email. But a simple text would have gotten the job done. The message was strategic. The bits required to convey that, “The British are coming”, by land or by sea, few.
And that is the common misconception with regard to military communications. That somehow, more is better. Yes, more is better in some cases, as in an engagement solution that requires fire control quality data. The only way to achieve this level of accuracy is to pass high bandwidth information, straight from the sensor to the shooter. Superior to that, is for the weapon itself, to collect the required data in real time, at endgame, through its seeker. The following graph loosely depicts how much and when.
Strategically, we need less data and less often. Tactically, we need more data and more frequently. Gen Goldfein is a fighter pilot. That means he is a disciple of the OODA Loop and seemingly John Boyd theory's on maneuver warfare. Some of the best tacticians in the world are fighter pilots…but we win wars with strategy not tactics…getting inside someone's strategic OODA Loop requires thinking, not technology. When we chase a tactical solution to strategic problem, we are looking in the wrong direction. And that’s not to say in other circles, more strategic in nature, those folks (intelligence) would love technology to give them more, more, and then some more. This is very expensive and drives very expensive architectures, think satellites, with mixed results.
The pace of technology has caused many within the DoD to lose track of first principles. How and why we are here? Just because it is possible to watch a video on an iPhone, while inside a self-driving Tesla, and at the same time order dinner from PF Chang’s, does not mean an F-35 pilot should be texting home that it would be great to Chicken Fried Rice for dinner. And if you couldn’t order from PF Chang’s tonight, because GrubHub, hasn’t added PF Chang’s to their restaurant options yet, doesn’t mean you should be upset if the company who wrote the app did not push a new update for the new restaurant option on the very next day. If left unchecked, the DoD, will most certainly move in this direction. If you do not recognize the development cycle, I am speaking specifically about DevOps and the way Silicon Valley has revolutionized building software applications, quickly, and cloud based. Great for commercial markets, great for start-ups wanting to disrupt status quo, great for selling iPhones, and ordering pizza. However, not so great for fighting wars.
What many consider to be a problem, stovepipes, by stark contrast, are strangely the solution when in combat. The vision was originally directed at DoD system of systems (SoS) because of the perception that stove pipes are in actual need of integration. That is easy to understand if you consider the seeming incompetence of Lockheed Martin Corporation (or the United States Air Force), that developed two 5th generation stealth fighter aircraft, the F-22 and the F-35, that are unable to communicate with one another through their data links. Many would consider this to be a humiliation however the reality is something quite different. Consider for a minute the way things that can be connected shown below. All are valid and useful constructs. Some are more expensive than others. None have a monopoly on combat power although individuals chasing connectivity as an empowering solution will drive to “Fully Connected”.
A vision of an integrated future, and the reality of how the DoD fights wars, are two different things. JIAMDO labored for years to bring the DoD such things as JIFC and the Navy CEC. There was this great promise of enhancing military effectiveness by increasing combat power through integration. That promise has never materialized. Two things conspired to reduce the promise. One, there actually is no combat power increase when integrating systems. Kinetic energy is kinetic energy. You can't create energy by networking systems that deliver kinetic energy. And two, military concepts for operations (CONOPS), concepts for employment (CONEMPS), doctrine, and tactics, techniques, procedures (TTPs) are all developed to simplify the delivery of violent effects to reduce the fog and friction of war and increase the chance of survival of combat forces. That is why stove pipes emerge, not because of the lack of ability to integrate. You integrate what is necessary. What is necessary in combat are such things as ubiquitous knowledge of commander's intent. And some shared situational awareness (SA) of the battle space. You do not integrate at the end game. At the engagement, all focus must be on the last seconds before impact. Texting a dinner order home reduces your SA and more importantly reduces the probability of a successful engagement.
Here is how we build a layered air defense. Notice the engagement zones and more importantly where the kinetic effects zones are located. We intentionally isolate engagement zones to divide command and control and reduce fratricide. Technologist need to understand the CONOPS behind how we fight wars and not just how we plug into the internet.
A good example of an open architecture that did change the world is GPS. However, GPS is not well understood in this regard. GPS is not a technology that provides integration of multiple systems to a JDAM. GPS is a broadcast service that provides sufficient precision information to a JDAM in order for it to divine its own location. Even though the timing signal that GPS provides becomes enticing, it a red herring if pursuing multiple communications systems that should be able to communicate with one another simply because there is a exquisite timing source upon which to synchronize. GPS provides a ubiquitous service for location and navigation accuracy that an engagement sensor uses to precisely position itself at endgame. Beyond that it is a dumb signal conveying nothing smarter to the weapon no better than the coordinates that were loaded into the weapon. If those coordinates are inaccurate, the JDAM will guide precisely to the wrong coordinates. Use of that signal for timing has become ubiquitous as well because most of the world is not dropping JDAM. But unlike an autonomous JDAM that calculates its own trajectory off the signal, systems that communicate integrate with each other using the timing to synchronize. It’s not the fault of GPS if you can’t make your own integration synchronization work because the signal fails, for whatever reason. To date many millions of dollars still pour into fixing vulnerabilities that arise from using the GPS timing signal for military communications having discovered that it is easy for an adversary to deny systems the use of that GPS timing signal. When we emerge on the other side of that understanding, which I hope is the defense department's ubiquitous use of GPS-III with M-Code, we will be better off for it, but we should have learned a valuable lesson from this history.
A better lesson, and one that Gen Goldfein incorrectly tries to use from history is the development of the SAGE program some 70 years ago, to illustrate his point about the success for open architectures. Given that SAGE was the most advanced integrated warfighting (and computing system) of it’s time, it was far from what anyone could possibly confuse with what we describe as an open architecture today. Nothing existed back then. It all had to be created from scratch. It was it’s own stove pipe on a national level. Anything that touched it had to comply with the protocol as it existed. Granted, in today’s terms, the protocol was not sophisticated. Bit’s that flowed across networks could pass with 1 and 2 bit error correction code. One of the first uses of bit error correction. It was an integrated air defense systems built throughout the United States with the mission beating back a nuclear attack by the Soviet Union. A first of it’s kind and it’s development ushered in the computer age. A worthy reference but far from an integrated and open system. Early on it was programmed in machine language, with coders leaning octal. In later stages, Systems Development Corporation (SDC), an off-shoot of RAND Corporation, invented Jovial for programmers to begin developing code in one of the very first higher level programming languages. This is hardly the right historical reference to define open systems. My dad, a developer on the SAGE system, has plenty of war stories to tell about, reprogramming the radar detection zones, in one case to search for missing aircraft outside the displayed coverage regions of a radar on a Texas Towers off the east coast. In another case, during a national exercise, the simulated tracks of inbound Soviet bombers were not being displayed in the command center. Patching the binary to set the proper flag to allow the simulated tracks through to the command center was perhaps the first real time hack in SAGE history. Communication protocols between radar sites and higher echelons had to be created. They were not copied and implemented from libraries. Forward error correction grew up out of necessity. And what about encryption...seriously?
Gen Goldfein, please don’t reference the SAGE system as some shiny beacon of integration and the perfect example of an open systems architecture out of history...it’s so inappropriate for your discussion. At best it was a National level stove-pipe kluge of many things. Uniquely built, uniquely run, and uniquely upgraded on a vast scale. Instead, reference the failure that was the E-10A and that program heavily birthed out of the JIFC communities. Let’s learn from a disaster of a program. I’m going to state for the record that nobody in the Pentagon knew the mission of that aircraft. When I briefed COMACC a few years ago, and stated that very fact. COMACC told me point-blank in his conference room, surrounded by his cohort of O-6's, who I had briefed previously (but failed to come to my rescue) the harsh words, “Don’t ever fucking say that again”, and yes he used the F-bomb. I will not say which COMACC or when that happened, but I will say, he was dead wrong. At that moment, it was not necessary for me to correct him (nor would I have) or for his council of colonels to come to my rescue. Everything he needed to know was contained in my briefing so I moved forward. If you have three hours, and a full three hours, I’ll walk you through the analysis. Our analysis decimated the E-10A. In the words of one engineer from Hanscom AFB who had labored on the program for 10 years, "I felt like I just found out my wife had been cheating on me". Nobody knew the mission of that aircraft. Nobody really wanted to know. Everybody had their eyes on the $51B in new funding. Or a combat career field for the C3ISR community. What was uncovered was a series of misunderstandings (to be generous) or out and out deceptions from the program office. The greatest perhaps was the MP-RTIP Radar. That stands for Multi-Platform Radar Technology Insertion Program. The promise was a scalable radar for use on many different platforms. The reality was that there was nothing common beyond the backend software. Where is the E-10A today? I still remember as vividly as yesterday when the light turned on for the first Senior Executive in the chain on the way to the fateful day with COMACC. The executive pushed himself clear of the table and announced to the room, “That will be the death of the E-10A’. After that, I spent a few years looking over my shoulder for those who were not happy with that particular outcome.
Simply stated, those involved in the research and development of new technology for our military are not the ones who have to pull the trigger. Thus, the warfighter wants a system that works, is robust, is reliable, and enables their CONOPS. The channel must be understood completely, and must be impervious to disruption, and above all, completely reliable. Anything else will get left on the sideline. There is enough fog of war without the uncertainty of the cloud of technology. Simple is always better. Kick it simple stupid. But there is more.
Warfighting systems fight in stove-pipes by design. Stovepipes fight in kinetically restricted baskets that optimize their effectiveness and outcomes. They only touch command and control (C2) at their periphery for shared SA and commands from higher echelons. This is why, even if all systems had open architectures to allow fire control quality information and passed engagement solutions to be past amongst themselves, the majority of that information wouldn't be used. The engagement solution is predetermined by very restricted physical limitations governed by kinematics. The engagement solution is also predetermined by the forces in contact alongside the pre-established operating and engagement zones, for multiple reasons but of specific note, to prevent fratricide.
I’m not saying communications standards are not necessary and shouldn’t be considered when building a system. Standards are a good thing in many cases when they actually exist. But when solutions are necessary in areas where technology is literally being invented as is the case in most military systems, imposing standards reduces the design space for the engineers and increases the overhead they have to carry. Computers and any system on the ground can tolerate those increases in size, weight, and power. Military systems that roll, fly, sail, or orbit are significantly different. Asking engineers to pack more and more into a design does not save money…it increases the complexity of the design, waters down any specific capability, reduces its ability to function correctly, and delays it’s development timeline. Think well Gen Goldfein before you take our Air Force into that particular future…that feels more like Silicon Valley then the Department of Defense…
No comments:
Post a Comment