Beep, configure, and fire
Military planners are now talking in terms of plug-and-fight capability. This is a spin on the old personal computing term plug-and-play – catchy, but outdated. As a marketing person at heart, I can’t help but suggest an updated term that better describes what we see taking place and what elements are going into this capability.
Most of us have seen some version of the movie scene where the condemned prisoners are paraded out in blindfolds, lined before a wall, and a firing squad is issued the familiar cliché “Ready, aim, fire!”
Today, with electronics driving most combat systems, a more appropriate term for the plug-and-fight process would “Beep, configure, fire!”
Beep – Join the network
For today’s warfighter, there is a wealth of information and intelligence available in real time as close as the nearest network. Sensor and command data fused into the network from a variety of modes and locations enable a tactical system to quickly access reliable information on the mission plan, threat situation, and the configuration of neighboring defense systems.
Recently, I visited a friend in the San Francisco Bay area, and he was showing me his new Bluetooth-enabled phone and headset. He commented that he could not help but notice that when he wears the headset while driving, especially on the freeways, he hears frequent beeps as the headset attempts to connect with devices in neighboring vehicles. It’s almost too easy to connect to a network now.
Short-range wireless networks provide a continuous network tone and have made it easy to connect quickly to a wide variety of devices. Technologies such as Bluetooth, Wi-Fi, Ultrawideband, Wireless USB, and the longer-range WiMax may soon be enabled with a security layer, enabling their use in defense applications. For now, defense networks using Software Defined Radio (SDR) technologies fit the bill.
Planners talk of systems fitting into a netted, distributed force. Whether wired or wireless, today’s defense systems-of-systems are built around network-centric designs and rely on being able to join the network quickly.
Configure – Compute for effect
Reconfigurable computing has advanced an incredibly long way in recent years. Advances in System-on-Chip (SoC) technology combining processing with FPGAs allow designers to optimize and adapt computing hardware to better fit immediate requirements. Linux-based open system architectures allow clusters (just another term for systems-of-systems) to add distributed nodes easily, enabling distributed processing and sensor fusion capability quickly and reliably.
It’s the intersection of processor, network fabric, and operating system in a reconfigurable form that becomes interesting. One example of this is the CoSine from Micro Memory. Built on the Xilinx Virtex-4 FPGA family with VxWorks running on two PowerPC 405 cores, it includes connectivity for serial RapidIO or PCI Express, a corner-turning Direct Memory Access (DMA) engine to aid in data movement, and a user-programmable area for signal processing algorithms. [Editor’s note: please refer to the Micro Memory article in this issue.]
Additionally, advances are being made in Linux on FPGA platforms. The University of Queensland in Australia recently secured a contract for NASA’s Reconfigurable Scalable Computing (RSC) project, building from a starting point in which a version of uClinux is adapted to the Xilinx MicroBlaze soft-core processor. The ultimate goal will be to remotely (as in ground-to-space) partially reprogram FPGAs on the fly.
We may see that general-purpose processors ultimately give way to reconfigurable processors in defense applications, both for functional and life-cycle reasons. Teamed with the University of Southern California and using IBM Cu-08 90 nm process technology, Raytheon's Morphable Networked Micro-Architecture (MONARCH) project targets April 2008 for a device that can alternate instantaneously between front-end (streaming) and back-end (threaded) processing.
According to Jack Kelble, president of Raytheon Space and Airborne Systems, "In the past, a bank of processor boards accepted information and another bank processed it." He added, "Now a tiny but highly sophisticated device a fraction of the size will perform both functions with unprecedented speed, power, and capacity to store and process a vast amount of data." MONARCH is expected to perform in a single chip or SoC role, possibly significantly reducing the number and types of processors required for computing systems. In the latter application, it will be able to process incoming and outgoing data while analyzing it.
Fire – With open weapons
Using technologies such as these, networked, reconfigurable weapons systems are beginning to emerge as the norm. Initiatives including the Modular Open Systems Approach (MOSA) sponsored by The Open Systems Joint Task Force within the US Department of Defense continue to set higher expectations.
Openness in new acquisitions is being demanded as seen in these comments from Lieutenant General Ronald E. Keys in February 2005: "We've got to get to this thing called the ‘compatible open architecture.’ I've got to be able to truly plug- and-play, and it's got to plug-and-play better than Microsoft. It's actually got to plug, boot up, recognize, and work …. So don't bring me stuff that's not compatible because I'm not going to be happy."
Large combat systems already architecting around plug-and- fight concepts include the Medium Extended Air Defense System (MEADS), Future Combat Systems (FCS), and the Littoral Combat Ship (LCS).
MEADS is the US Army’s next-generation replacement for Nike Hercules, Hawk, and Patriot air-defense missile systems, designed from the ground up to move with ground forces and interoperate with other allied forces. It relies heavily on networking and distributed intelligence to achieve its mission. A MEADS system has the capability to command a fleet of distributed missile launchers while simultaneously detecting and tracking hostile forces and targets. There is a key tactical advantage to this distributed design: The missile launchers can be located well away from the ground radar and the battle management units, reducing the risk of detection of the launchers. This also opens the possibility to transfer command and control of the launchers and missiles to a neighboring battle management unit while some management systems are offline for whatever reason.
FCS isn’t a single system but rather a blended system-of-systems intended to transform the US Army’s fighting capability. Underlying FCS is a software architecture called Fire Control – Node Engagement Technology (FC-NET). FC-NET provides an adaptable, flexible architecture that modularizes the interaction between the technical weapon system (the intelligence that controls and guides the weapon) and the tactical information systems. This enables weapon systems to readily join the command fabric to get the information they require.
Another plug-and-fight system is LCS. It’s being designed to work in three primary mission areas for the US Navy, including mine countermeasures, anti-submarine warfare, and anti-surface warfare, presumably with anti-air, self-defense capability in each role. This is being accomplished through the design of mission packages that fit into the sea frame and adapt the capability to the desired mission area. Open-systems architecture and modular, networked subsystems are again the key to success, and the notion of being able to reconfigure the system for the role at hand is prominent in the architecture.
Open doesn’t mean big
Creating new systems-of-systems isn’t necessarily about using big computers. From the looks of things, it could be just the opposite, using networks of relatively small processors tied together wirelessly with very intelligent software and combining these systems into larger systems.
Researchers at the University of Essex are working on a concept called the gridswarm, where small Unmanned Aerial Vehicles (UAVs) capable of speeds up to 120 mph fly in formations similar to the flocking behavior of small birds. In the prototype, these aircraft are connected by a Bluetooth mesh driven by Linux compute modules from Gumstix. These tiny modules run Linux 2.6 on 400 MHz Intel Xscale processors with 64 MB DRAM and 4 MB Flash, along with USB, serial, and optional Bluetooth interfaces. It’s a great example of small systems fitting into larger systems fitting into still larger systems with aggregated intelligence.
Rapid developments in wireless networking, reconfigurable computing, and network-centric weapons systems are going to spawn new innovations quickly. The results should also reduce the long-term costs of weapons procurement, enabling easier upgrades and reducing the impact of obsolescence by allowing subsystem level replacements.
I’ll be sure to tell my friend the next time I see him that when he hears a whole bunch of beeps in rapid succession on his Bluetooth headset, he should duck. It could be a UAV gridswarm reconfiguring just overhead, and hopefully they are unarmed and peace loving.
If you happen to see a gridswarm, or other interesting developments that beep and configure, drop me a line.