The expression “plug and play” is the military community’s favored way to evoke interoperability, which is becoming increasingly important with unmanned undersea and air systems. And while achieving this state sounds simple, ensuring that multiple systems have complementary protocols, technologies, and business models is a lengthy process.
When fax machines first came out, both the sending and receiving machine had to be made by the same manufacturer. It wasn’t until standards were created and systems were built to those standards that machines of different manufacturers could finally communicate. The same goes for unmanned systems.
As with fax machines, it’s the market that usually settles on the standard, as the 1970s and ’80s competition between Betamax- and VHS-format videotapes demonstrated. In the terrestrial wired/wireless industry, uniform communication standards such as Ethernet, USB, WiFi, and GSM (Global System for Mobile Communications) allow subsystem technologies from different vendors to be integrated into a complex system fairly seamlessly.
When it comes to the underwater domain, however, achieving interoperability is currently impossible due to the lack of common standards and protocols for wireless communication. But this is beginning to change.
According to the DOD Unmanned Systems Integrated Roadmap Fiscal Years 2013–2038, released in December 2013,
DOD is working to accomplish unmanned systems interoperability by standardizing critical interfaces within the overall UAS [unmanned aerial systems] architecture by implementing standard interoperability profiles. Since “standards are ever evolving,” key enablers in this effort will be to clearly and consistently define the communication protocols, message formats, and implementation methods across these interfaces for new start efforts and system upgrades. In addition, development of middleware that can translate the multiple system inputs and outputs will be a key enabler. This effort will facilitate the mandated acquisition, technology, and logistics lifecycle management efficiencies across current and future unmanned programs.
Interoperability Challenges
“If a common communication system could be established in the underwater domain, the advantages would be immense,” said Dr. Mandar Chitre, assistant professor at the department of electrical and computer engineering and head of the Acoustic Research Laboratory at the National University of Singapore’s Tropical Marine Science Institute. “Subsystems from various vendors could be integrated into larger systems easily.”
In the initial stage, the integration would likely be with a central control system rather than machine-to-machine, which would allow one operator to monitor various subsystems from a single interface. “As . . . users build confidence in the technology, peer-to-peer communication would allow subsystems to interact directly without the need for every communication to go through a central control system or operator,” said Chitre.
Almost all underwater vehicles or sensors currently use proprietary interfaces and protocols for communication, especially for wireless communication in water. This means that devices from different manufacturers cannot communicate with each other. “In many cases vehicle and sensor manufacturers include communication technology, such as underwater modems, from other manufacturers,” he said. Because the protocols and data formats used by devices are not standardized, it is not even guaranteed that two devices that have modems from the same manufacturer can communicate with each other.
But interoperability is possible. “In practice, the major challenge is to get various technology vendors to agree on a common standard and protocols. It is necessary to have a basic framework that is standardized while letting technology providers innovate and provide differentiated products that fit within the framework,” Chitre stressed. “This would ensure that technology vendors do not lose their competitive edge by agreeing to standards, but instead create a larger market where their products can easily be integrated with other vendors’ products to create systems beyond what is possible today.” Such a framework would require industry players to make a concerted effort. Companies like Subnero, with which Chitre is affiliated, are now making their software-defined underwater modem technologies customizable and open.
Organizations such as the NATO Centre for Maritime Research and Experimentation (CMRE), located in la Spezia, Italy, are also helping this effort through standardization initiatives and encouraging development of software-defined modems and networks. Dr. Eric Pouliquen is the branch head for future solutions at NATO Allied Command Transformation in Norfolk, Virginia, and worked previously as a CMRE researcher. He said the boundaries between the various domains of sea, air, and land are blurring, as some vehicles or platforms can perform in more than one domain, so the standards for the different domains must be compatible—if not the same. “It would not make sense that we develop a set of standards for something that swims that is completely different from a vehicle that is on land, for example. So it is more and more ‘joint-ness’ and ‘interoperability-by-design’ across domains that we are often seeking.”
CMRE has developed standardized agreements that codify acoustic communications underwater between two platforms. This will allow data to pass from modem to modem underwater so that a U.S. unmanned underwater vehicle (UUV) can communicate with a British UUV, for example. “This data linking is codified now; it’s a NATO standard,” Pouliquen pointed out. And when a NATO standard is agreed on, it becomes a global standard—even for partner nations that tend to adopt NATO standards in order to be interoperable.
Cooperating through Communication
According to CMRE research scientist Dr. John Potter, military maritime operations have been driven by a relatively small number of large, expensive platforms dealing with well-defined threats to which those platforms could be designed to address. “In the last couple of decades, a number of things have happened which have really changed that picture. The threats are now much more diverse, changing rapidly, and it requires a more adaptable, flexible response,” he noted.
This has driven a change in focus from platforms, which have decades-long life cycles, to capabilities, so now platforms are being built that can support many different types of capabilities. “You basically plug in the ones that you need for this mission, and that underlines a lot of design methodology across the board. The capability you have on a vehicle today will be very different five years from now, but the vehicle will basically be the same.”
Autonomous unmanned vehicles (AUVs) are becoming mature, and we can expect their numbers and applications to grow. They’re relatively inexpensive and capable of dirty, dangerous jobs. “Some of these platforms have very long endurance; they don’t get tired, they don’t get seasick, they don’t need to be fed. When you don’t need them you can put them on the shelf, which you can’t do with sailors,” Potter asserted. “They’re smaller and cheaper than ships. Instead of sensing the undersea environment by towing a long physical aperture behind a ship,” we can now gather environmental information over a distributed network aperture and respond to it.
Eventually, Potter said, it will be possible to develop and deploy clandestine networks of large numbers of small, long-endurance, inexpensive robots to detect, classify, track, and, if necessary, prosecute enemy submarines. “Not every nation can contribute a destroyer, but most can offer something smaller like an unmanned system. If you need the different nations to contribute to a pool of multiple autonomous assets, AUVs have a relatively low threshold of participation.” And if these systems could interoperate, they could be deployed in a more flexible manner.
However, the undersea domain is challenging. Communication between underwater maritime systems is complex because of the sheer physics involved, and is limited by low bandwidth and prone to frequent disruptions.
Janus, a new standard for underwater communications being developed through an effort led by CMRE, can provide a way to send and receive messages. “This language opens a portal between two domains—two different operating paradigms—through which they can talk,” Potter commented. “It’s primarily a physical coding protocol, which is rather like a language, and many different kinds of hardware can be made compatible since it is so simple and does not require a great deal of computing power or memory.” Once the standard is adopted, Potter predicts that many existing comms systems will be brought into compliance.
The simple digital underwater signaling system can be used to contact underwater assets using a common format, announce the presence of an asset to reduce conflicts, and allow node discovery to enable a group of assets to organize themselves into an ad hoc network. It is the first digital underwater coding standard being developed to provide global interoperability in underwater communications, said Potter. “Janus will likely be the first NATO digital underwater communications standard, but we have no aspirations to make it ‘the’ NATO standard signaling method because we fully anticipate that other standards will follow and that future modems will be able to ‘speak’ several ‘languages’ and be able to choose the best suited to any particular situation.”
In fact, Potter admits that Janus may be the poorest choice if there is another common language between modems, because Janus is very simple and low bit-rate, intended to be robust. “Janus is not a magic bullet for collaborative and cooperative behavior. Just because two people are able to communicate with a common language does not guarantee that they will be friends. But it is an important starting point,” he said.
Intelligent Robots
Systems with a higher degree of autonomy are needed to reduce the manpower requirement and dependence on full-time high-speed communications links, while also reducing decision-making time. “By adding autonomy to a distributed network of moving sensors, we can reduce risk to personnel and be more persistent, while at the same time reducing cost,” surmised Dr. Kevin LePage, cooperative antisubmarine warfare program manager at CMRE.
CMRE is working on a heterogeneous, underwater, adaptive-sensing network with distributed intelligence for the persistent littoral surveillance of submarine targets. Because of current communication limitations, UUVs must be able to do as much processing as possible on board and make decisions about what’s important and what needs to be shared.
The key is for vehicles to work together and produce overall efficient group action. “It’s one thing to make a system autonomous. It’s quite another to make it intelligent,” said LePage. “They have to know what to do.”
“To say, ‘we’ve got all these autonomous underwater robots, and they can listen for and detect submarines, and cooperate with each other to hunt the submarines down’ sounds very sci-fi Matrix-like. And, indeed, it’s a big leap forward to devolve the intelligent actions of hunting a submarine down to an automated system,” Potter said. “It’s a huge step in machine intelligence.”
LePage and his team validated the improved on board processing capabilities of CMRE AUVs during Proud Manta, the NATO antisubmarine warfare exercise in the Ionian Sea, which included the fusion of contacts using CMRE’s Distributed Multi-Hypothesis Tracker and a communications suite called the Networking Exchangeable Modem Operator from the Massachusetts Institute of Technology’s pAcommsHandler.
Any of the sensors’ nodes can detect, classify, and track targets by themselves. “They have the ability to do underwater messaging, so each node can share track information with its collaborators,” according to LePage.
Different communications nodes must know when and when not to transmit information. A network that isn’t fixed, such as one in place underwater, may have multiple mobile assets that are frequently moving and routing that is constantly changing. “If a node can’t communicate directly it may need to relay a message,” said Rob Breen, CMRE’s deputy head of engineering. This means that it must know which node can accept the relayed message and its location. “The dynamics of who has to talk might adapt and change very rapidly. If everybody needs to talk at some point, you have to split them up and schedule them, with protocols to handle that.”
Common Ground—In the Air
Standards need to be applied to systems that operate in all domains. Some efforts to achieve interoperability that have focused on UAVs can be applied to unmanned systems in all domains. One way to achieve this is by changing the way ground control systems (GCS) are designed, built, and acquired.
“We’ve standardized the means of controlling and communicating between the ground and the aircraft, and all of the systems involved. The standard that we’re working on is called Unmanned Aircraft Systems [UAS] Control Segment [UCS],” disclosed Rich Ernst, who leads the UCS architecture development in DOD. “This architecture effort was initiated to remove proprietary restrictions and enable competitive, yet seamless integration and certification through reuse of mission essential services and applications, and it’s hardware independent.”
“UCS ensures that the interface standards are known to all vendors so we don’t have proprietary interface standards where only the original equipment manufacturer can add or subtract to it without significant cost growth,” said Lieutenant Colonel James Kennedy, Product Manager Common Systems Integration with the Unmanned Aircraft Project Office, PEO Aviation at Redstone Arsenal, Alabama.
If you have one company develop software, then they become the only ones that can add or subtract to it without significant cost growth. We typically end up having to go back to the same vendor who wrote the software initially to add capability. UCS repackages that software into an open standard that is well-known, that isn’t commercialized, that industry recognizes, and thereby opens our competition and it opens the ability for third parties to add capability.
As we move to open architecture, our vision is that we will have an architecture that is flexible enough to range from our small UASs and remote video terminals, through our large UASs and the ground control station. They’re all made by different manufacturers. However, once we have an open architecture across all those platforms, it should more easily and efficiently allow us to add capabilities to all of those systems without having to quadruple the integration cost for any one of them.
UCS breaks up the different GCS functionalities, which allows for the insertion of new capabilities and upgrading of legacy capabilities—such as route planning, weather services, task monitoring, or flight-status monitoring that most GCS have to implement—without having to re-build the entire GCS. “By breaking up the GCS into individual capabilities that are all separate and individually developed, there is no longer a requirement to have a single vendor develop all functions within a GCS,” Ernst revealed. With well defined open standards and processes, it should be possible to bring in third parties to add capability, thereby reducing cost.
Plug and Play, Unplug and Switch
According to Ernst, UCS allows for the creation of an ecosystem, where the best services are the most demanded in the marketplace. An “app store” repository has been created so new software can be available to users of GCS-compliant systems.
If you are a small company and have a particular area that you consider your core competency, and have the next killer app for some aspect of the GCS, then you have a clear pathway to have your app integrated into a larger system. We are developing a UCS software developer’s kit to enable rapid creation of UCS-compliant software systems. We think this will help to further drive adoption of UCS across the small business landscape, demonstrate the ease with which UCS software can be developed when using the right tools, and fundamentally increase the level of innovation across industry.
Dreamhammer Chief Technology Officer Chris Diebner said Dreamhammer’s Ballista software is an instantiation of UCS. “We followed the model and achieved immediate interoperability, verified and validated. UCS is a way for systems and parts of systems to talk to each other. It’s the glue that holds it together, a single point of interaction for dissimilar systems.”
Diebner said UCS takes a new approach. “It defines the 150 or so services, but you can pick and choose which ones you need. With UCS you don’t have to use them all.” He pointed out that solutions from the big defense contractors usually push the third-party developers to the margins. “We want to develop an ecosystem of third party developers who can concentrate on hardware, and can use Ballista to leverage the software piece.”
“A drone uses a computer interface to leverage intelligence, technology, and diversified control,” said Dreamhammer CEO Nelson Paez. “The key to the future of drones and robots will be their ability to work together. Ballista allows government or commercial customers to link together machines from numerous developers performing a variety of tasks.”
According to Paez, Ballista is the first commercial multiple-drone operating system. “It can plug-and-play with all current and future unmanned aircraft, their sensors, embedded systems and related command-and-control software and operational databases.”
Paez said some drones require as many as 200 people to conduct a mission—more than manned vehicles. But, he added, Ballista allows a single user to manage multiple drones simultaneously. “The services need to adopt UCS. Right now it’s an informal standard. It’s all about adoption. You can have the best system, but what if nobody adopts it?”
Creating or updating standards is hard work, involving meetings of international stakeholders and experts, and dividing the work into committees and subcommittees. But the best solution as agreed upon by a majority will arise from this process. Despite the adoption of common standards, however, there will continue to be the need for interfaces that can accept and connect legacy systems and make the data exchangeable with other systems.
With standard connections, languages, software, and methods of operations, even the smallest coalition partner can bring something of value, such as a minehunting unmanned vehicle, that can make a valuable contribution to a multinational operation. A ship from one navy could get under way, launch a UUV belonging to another navy, and send the results to a different command to analyze the data. With standard communication protocols, one sensor network could alert others, and eventually a command center afloat or ashore.
With regard to UCS-compliant architecture, good ideas can replace a control segment component on any likewise compliant system, making a big market opportunity for small businesses and individual innovators. For many challenges in the unmanned world, there is a standard answer.