James Kennedy

Protect your unmanned investment, operate multiple systems, mix and match services Plug-and-play capabilities for unmanned systems?

Scientists have long recognized the value of unmanned systems as tools to conduct exploration and research.  The advantages are many, and the cost is usually less than would be incurred for a research ship or manned aircraft mission.
Original equipment manufacturers (OEMs) who make unmanned underwater vehicles (UUVs), unmanned surface vehicles (USVs), and unmanned aerial vehicles (UAVs) usually provide the vehicle, control station, software and communication protocols, which are almost always unique to that system.
As technology and the market mature, there is a growing demand for flexibility to adapt systems for different missions, operate different systems from a common control station and upgrade them easily when new and innovative applications become available.
While the armed forces are leading the way, commercial, academic, homeland security, law enforcement and other users of unmanned systems can benefit, too.
“We’ve standardized the means of controlling and communicating between the ground and the bird and all of the systems involved.  The standard that we’re working on is called the Unmanned Aircraft Systems (UAS) Control Segment, or UCS, and it is hardware independent,” said Rich Ernst, who leads the USC architecture development in DoD.” 
All systems do not necessarily use the same functions, but with many systems you have to accept what functions the OEM provides.  Some are simple, and others complex. Some systems give you more than you really need, and some not quite enough.  With UCS, you can now mix and match applications, using only what you need, and you can take advantage of new applications as they become available. 
“We can identify specific requirements and create applications that meets that requirement, or closes the gap,” said Ernst.
“We’ve been limited by the fact that OEMs have different approaches with different hardware, software, processes and interfaces—different everything,” said Ernst.  “That’s what we’re trying to avoid.”
“UCS ensures that the interface standard is known to all vendors so we don’t have proprietary interface standards where only the OEM can add or subtract to it without significant cost growth,” said Lt. Col. James Kennedy, Product Manager Common Systems Integration with the Unmanned Aircraft Project Office, PEO Aviation at Redstone Arsenal, Alabama.  “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.”
“Our vision is an architecture that is flexible enough to range from our small UAS and OSRVT (One System Remote Video Terminal), through our large UAS and the ground control station,” said Kennedy.
According to Ernst, UCS breaks up the different ground control segment functionalities, which allows for 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 rebuild the entire GCS. “It’s ‘plug and play’ for GCS development.”
Legacy systems can be adapted for UCS, and are then able to take advantage of the many benefits of UCS.  This helps to protect an investment in a system, and can prolong the service life of the system by adding new capability.
The software from the Army Bi-Directional Remote Video Transceiver (BDRVT), which is an enhanced version of the Army’s One System Remote Video Transceiver (OSRVT) (made by AAI Corporation to support video and telemetry from a number of UAS such as Shadow, Predator, Pioneer and others), was used to demonstrate how UCS works. 
One experiment was conducted by the Navy.  “BDRVT was totally integrated software,” said Wayne Perras, UCS project manager at the Office of Naval Research (ONR).  “We broke it up into services and rewrote those services into UCS in two different codes.  Then we combined the services back together again to see if we can have that same BDRVT to prove that that it operates vehicles.” 
“We showed that we’ve got interoperability by having it built and written in a different code, and being able to exchange or replace services while continuing to operate at the same performance,” Perras said. 
Then the Army flight-tested the UCS-compliant BDRVT with an AAI Corporation Shadow reconnaissance UAS.
“We took a bidirectional capability, put it into an open architecture model which was compliant with the UCS standards and demonstrated that the open model could, in fact, address the bidirectional capability that we’re looking to put into our systems,” said Kennedy. 
The flight-test using an Army Shadow UAS was a success.  “It was so successful that we have moved our whole OSRVT architecture to be compliant with those open standards,” Kennedy said.  “This allows us to more readily connect the applications that third parties may have developed, whether it’s Garmin or third-party contractor developed applications that plug into our known standard, thereby reducing the cost of integration for the program overall.  It also allows us to introduce competition into the program, because now we don’t have to keep going back to the same vendor in order to add capabilities.  We can compete and allow other vendors to be able to develop those applications—as long as they’re applying those standards that are embedded due to UCS and open architecture—so the integration cost is less.  So it was a very successful demo and it’s caused us to really focus our OSRVT around that open architecture standard.”
“Legacy GCS systems can naturally transition to using the UCS architecture.  This simplifies the integration of legacy systems, since, in large part, UCS was designed from the ground up to ensure that the needs of legacy systems were analyzed and incorporated,” Ernst said.
Adapting existing software incurs a cost, but that cost can have a significant return on investment.
Ernst said that there are many industry best practices for developing modular software. UCS has chosen a “functional decomposition,” which breaks apart GCS capabilities based on common functions (e.g. route planning, weather monitoring, task monitoring, flight status monitoring, etc.) that most GCS have to implement.
This is benefiting the Navy today as it develops the UCS-based common control system (CCS) for the Unmanned Carrier Launched Airborne Surveillance and Strike — or UCLASS.  A control station built to the UCS model could conceivably fly other Navy UAS, like Triton, Fire Scout or Scan Eagle, as well as other unmanned systems in other domains.
“It makes it easier to bring in the best of breed,” said Kevin Davis, program manager requirements officer for the common control system and common standards and interoperability (OPNAV N2 / 6 F2).  “If you have two apps that do relatively the same thing, we can have the warfighter determine which one they like best.  If they have different, multiple weather apps or something, you could bring in those, test them out and see which one they like best and go with that one.  It really helps out.”
“We’re not mature enough yet throughout our different systems to fly everybody’s air vehicles, but that’s where we’re headed,” said Jeff Davis, deputy program manager for CCS in the strike planning and execution systems program office at Naval Air Systems Command (NAVAIR PMA 281).
UCS is more than a technology-architecture; it’s an open business model that allows small businesses to compete on an even playing field.
“It’s a huge paradigm shift for us to be able to go out to multiple vendors and buy pieces and components of the system,” Davis said.
“The faster that we show we can integrate those applications and get them out to users, it encourages industry to start building the better widget, and a lot of people will start getting involved in that market,” said Jeff Davis.
And that’s what it will become: a market.  Ernst called it an “ecosystem that goes beyond the typical technical and business structure.”
It’s bigger than the military—other users, like the S&T community—will drive that market, too.
Ernst said that when new UCS-compliant applications are developed, they will be made available through an online “app store” repository.  The best apps will be in demand, creating a market that will stimulate innovation.
“Even within the individual military services, nobody has situational awareness of what everybody’s building and the opportunities for reuse,” said Ernst.  “There now is transparency, with a marketplace to go and look at products that can be leveraged.  You might not find exactly what you want, but it helps identify products that are very close to what you want and you just go to the vendor and work with them to modify the existing product to meet your requirement.”
 “We talk about getting a common architecture defined for everybody.  Well, here it is.  That’s the power of UCS architecture,” said Jeff Davis.  “And we’ve got to start thinking that way.”

To learn more about the UCS architecture and how you can both adapt your system to be UCS compliant and develop applications for use across the spectrum of UCS-compliant systems, visit
www.ucsarchitecture.org

(As published in the March 2014 edition of Marine Technology Reporter - www.seadiscovery.com)