It all starts on a dreamy Christmas morning. You open a present from your mother-in-law. You find a "multi-tool" with or without a "sturdy belt holster". You thank her for the thoughtfulness. You might even give her a mother-in-law hug. Later you can't find your pocket knife so you grab your new multi-tool and go hiking in Moab, Utah. 127 hours later, trapped and near death in a canyon, you hack through your arm with the dull blade of the multi-tool and cut through your nerve fibers with its crappy fold-out pliers. Multi-tools don't work. You might say, "Hey, that famous climber Aron Ralston saved his own life because he had a multi-tool and was able to successfully cut his arm off". He was lucky. And his luck was the kind that casts James Franco as his character in the Hollywood reenactment. The rest of us don't have that kind of luck. The rest of us die.
When we send troops into combat, we don't issue multi-tools. We give them weapons with singular lethal purpose. If more killing power is required we keep it simple. Last time I checked a fire team consisted of two riflemen, a grenadier, and a machine gunner. They may all be able to operate each weapon but when the fire-fight starts they stick to their specialty. Then they might add a mortar team, or heavy artillery, or close air support. This is the building block approach to effective warfare...and it works. The same goes for air power. We don't issue multi-tools to our Air Force pilots. Instead, along with their high performance jet aircraft, a fighter pilot is issued a hook blade knife. The hook pops out like a switch-blade. The hook is used to cut the parachute risers in case their aircraft ceases to fly properly and they must bale out. The smart ones open the hook blade in advance and tuck it into their flight suit. This way they have the right tool for the job and don't have to struggle to open it as they plummet beneath a tangled parachute.
Use the right tool for the job. Any mechanic, carpenter, infantry soldier, or fighter pilot will tell you having the right tool is a life saver. Why then is there a belief that tools can be bundled into more effective packages. The answer is, of course, cost. There is always a cost savings when you buy five tools in one, just watch late night television. There is a fallacy in believing this combination of tools does cost less, or is just as effective as the tools in their individual form, or even worse, believing they are better.
John Boyd successfully argued against the multi-tool in the 70's and made his point. The result was the F-16 fighter. This aircraft is the greatest pure dog fighting aircraft ever conceived. Here's another question that Boyd answered. How do you put a 30 mm cannon in the air? Ladies and gentleman we give you the A-10 Warthog...not very pretty but pretty damn effective. The A-10 was also a direct product of this proper tool for the job mentality. Fighter's fight, bomber's bomb, attack aircraft attack, and ISR aircraft...well, what exactly do ISR aircraft do? More on ISR aircraft later. First some preparatory thoughts.
The philosophy of the multi-tool goes deeper than cost. There is a belief that grouping things or aggregating them into communal living improves effectiveness too. What could be more effective then always having the right tool for the job at your finger tips? Well, for starters, having the right tool for the job. The multi-tool is rarely the right tool for any job. So why does everybody buy them? Well that's the magic of creative marketing and hopeful gift giving. Giving someone a plain screwdriver is somewhat unimaginative. But giving someone a tool that does everything is believed to carry more value. Here's a better idea. How about giving someone a non-conductive screwdriver? That's both thoughtful and could be a life saver. Last thing I want to do is poke around in a high voltage fuse panel with a screwdriver that unfolds from the handle of my multi-tool. That's candidate material for next year's Darwin award. Yet we still have leaders in our Department of Defense who think giving the troops a multi-tool will reduce the budget and enhance effectiveness. These leaders should also be on the short list for next year's Darwin award, except it's not those leaders who have to use the crappy pliers. It's the men and women in the trenches who get stuck with the bad Christmas gift. Ultimately our national security is eroded by the same faulty logic.
Some of this can be traced to an early belief in the power of network centric warfare. Twenty years ago, Andrew Marshall, in the OSD Office of Net Assessment, threw down a vision for a Revolution in Military Affairs in which the DoD could transform the way we fight wars, predicated by the coming advances in information technology. Much has been written and many things have been attempted. The promise of increased combat power, based on the power of the network alone, has not materialized. We do not have a single integrated air picture (SIAP). We do not have joint integrated fire control (JIFC). We do not have a cooperative engagement capability (CEC). At least not to the level envisioned by their proponents. We do have a few more unmanned systems in operation; remotely piloted aircraft have increased for instance. But we have always had unmanned satellites, rockets, big missiles, cruise missiles, and target drones. The unmanned technology is not new; just the attempt to apply the technology in a ubiquitous fashion is new. Technology has driven a belief in something ethereal, something strung together in network form, with an added social benefit. It is this communal effect applied to technology that fuels the promise of the multi-tool. It is the socialization of air power that we should work hard to avoid less we suffer a reduction in our effectiveness.
Recently a high ranking DoD official stood up at a conference and said, "The DoD will never again buy a single aircraft with a single mission purpose". This DoD official has a lock on a job with television infomercials upon their retirement. The myth of the multi-mission aircraft remains strong within the Department of Defense. Although the Navy is still building the MP-8 multi-mission aircraft, the Air Force abandoned hopes for their version of a large multi-mission aircraft several years ago. Thank God. Back then it was called the E-10A and was destined to cost the country close to $500M dollars per copy. Oddly the multi-tool concept of lower cost broke down with the E-10A. Seems like bundling the capability should reduce its cost right? Not if you are placing two unique $200M dollar systems on a $100M dollar aircraft. But the real confusion existed in the operational concept for this multi-mission aircraft. Where would it fight? And which mission would have priority? Combining the mission of the JSTARS with the mission of the AWACS on a single platform seems, on the surface, to be a worthy goal. Until you realize the missions are vastly different. The JSTARS looks at what’s moving on the ground while the AWACS keeps an eye on what's flying in the air. Both missions must happen continuously. They fly two completely different radars both in frequency, power, and utilization. But of even greater importance is the fact that the two missions operate in separate areas of the battlefield. This operational information was lost from the very beginning. Sure, the technology could be made more comparable, after all both systems are radars. But to fly one to cover the JSTARS mission means a second one would have to be flying to cover the AWACS mission. Instead of two multi-tool jets costing the country $1B dollars, we could buy two dedicated jets (1 radar system a piece) that would cost a total of $600M thereby saving the country $400M, for which we could purchase a third jet and still return $100M to the national treasury. What were they thinking? The word we are searching for is multi-tool.
And it is this multi-tool mindset that continues to inspire our dreams and cloud our judgment. Here is another example. Dedicated mission aircraft, such as the JSTARS and AWACS have served proudly for decades. The promise of lower cost remotely piloted aircraft, serving a general purpose, non-dedicated aircraft has crept into our imagination. The highly publicized KC-X tanker has also raised the spectra of possibility to do more general purpose service in more mission areas. Using general purpose aircraft to fly non-dedicate missions has been a goal of transformation advocates for many years. If more of our mission systems could be placed into pods then any aircraft could be used to fly any mission. The flexibility of air power seemingly rises to the infinite in possibility. There is of course no free lunch as many would wish to believe. One senior Air Force official has said with regard to the application of a non-dedicated concept to the ISR mission, that, “…they [non-dedicated ISR concepts] have been the bane of my existence".
Non-dedicated operations break down because there are too many variables to control. We dedicate things when the mission is too important to delay, screw up, or fail…like fighting a war. Will there be an aircraft available? Have the generic systems on the aircraft been maintained? Will a higher priority mission bump our mission at the last minute? Many of these issues could be solved with proper technology. But we are talking about more than technology. People are involved. The technology could be ubiquitous. To a computer a one or a zero is still the same tomorrow as it was today. But it's the people who fight the wars. You wouldn't tell Mario Andretti to go out into the parking lot and pick a random car to drive in the Indianapolis 500. When we ask Air Force personnel to fly and operate sophisticated machinery, it's not just at a race on Sunday; it's in a war zone. It would be nice for them to have taken a few laps around the track first. Yes there is the right stuff mentality prevalent in all pilots, and Mario Andretti could probably smoke us all driving a Ford Focus, but that's not the right way to organize, train, and equip people for mortal combat.
We have to stop thinking with a one-size-fits-all mentality. We might think the benefit of technology is to enable one-size-fits-all. It does not. Technology may provide the infantry soldier an M-16 that is lighter, more powerful, and less likely to misfire. But it will not reduce the requirement to have an M-16 with a dedicated soldier behind the trigger. It will not reduce the reality that certain missions cannot be made stronger by combining them with those that are less strong. And those that are weak can be strengthened by combining them with those that are less weak. To think that technology enables every system to contribute according to its capability and every need can be filled with whatever capability is available sounds suspiciously like a failed system of government. It is not in any way like any war that has ever been fought and won. Warfare is not a social experiment nor is it a system of government. You win with weapons that work effectively applied with overwhelming force, and a whole lot of intelligence. Then one bullet must be fired from one rifle. Just ask Osama bin Laden. Giving Seal Team 6 a multi-tool doesn’t work.
The Socialization of Air Power
by Jim Muccio
Saturday, October 19, 2019
Monday, October 14, 2019
Open Mission System Blues
Before we get to the military utility of open mission systems the reason for this website is security. Open architectures and open systems are more vulnerable to security breaches simply because the blue-prints to hack them are published and proliferated. Once that is done, the possibility of a single key fitting all locks becomes a possibility. Maybe the military utility of moving to an open architecture out-weighs that kind of risk? Doubtful. But generally, at least for this essay, I take aim at the subject of open mission systems and the perceived belief in their superiority. The increased lack of security is just another reason not to jump wholly onto this bandwagon.
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…
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…
Subscribe to:
Posts (Atom)