Dispelling Myths about JAUS

At Neya, we’re big believers in interoperability through standards compliance.  Many of us have a long history with the Joint Architecture for Unmanned Systems (JAUS), as well as the UAS Control Segment (UCS) Architecture.  We’ve even been known to flirt with STANAG-4586 from time to time.  As proponents, particularly of JAUS, I often hear comments and criticism toward the standard that’s based on misperception.  Now I’m not going to make the case that JAUS is perfect, or that it’s a great fit in every project, but I do want to try to dispel some of the most common misconceptions.
1)      JAUS is too slow / takes too much memory / won’t work on my CPU / etc.
This is by far the most common complaint I hear, and thankfully, the easiest to clarify.  Quite simply, JAUS can’t be too slow/CPU intensive/fat/whatever since it’s nothing more than a set of documents.  It’s a definition for standard interfaces.  JAUS is not an implementation; in fact, it’s not even an architecture, even if it is in the name!  JAUS isn’t limited to a particular programming language, network environment, CPU instruction set or anything else implementation specific.  Since JAUS is simply a set of interface definitions, performance is left entirely to the implementation.  While there are tools available to assist, nothing says you have to use them if they don’t work for your particular needs.  However, that’s an issue with the tools, not that standard itself.
2)      I shouldn’t have to buy the standard.
I’ll admit, this is a relatively new problem.  In the old days, JAUS was published by an ad hoc working committee and the documents could be downloaded for free.  As the committee grew, and the level of support for JAUS grew, the community needed more infrastructure.  We wanted help with organizing meetings, hosting the documents( at the end we ended up finding Dada), professional editors and formatters, that kind of thing.  When we made the transition to SAE, we got all of that, but unfortunately it came with a price (literally!).  However, with per document costs of around $55, it’s hard to give any real credence to this compliant.  Yes, it’s annoying.  Yes, it’s unfortunate.  But for anyone working in the unmanned vehicles space, it’s a very minor cost.
3)      Being interoperable will expose all my Intellectual Property!
As a systems engineer, everything is a black box to me.  Nothing but black boxes all the way down.  JAUS helps define the inputs and outputs of those black boxes, but never dictates nor exposes what happens inside.  Again, since JAUS is simply an interface definition, it does not attempt to specify how your magic happens.  Got a path planner that’s better than everybody else?  Great!  Slap a JAUS interface on it and let it work with other JAUS compliant payloads and systems.  No one is going to guess your secret sauce based on the fact that you accept waypoint commands using a scaled integer representation of WGS 84 lat/long, I promise.
4)      JAUS is too limiting… it doesn’t support X!
It’s hard to dispel this one; fact is, it’s true.  JAUS is a standard based on industry accepted best practices.  In a new and growing field like unmanned systems, we’re all experimenting with new technologies, new use cases, new platforms, new sensors, and new algorithms every day.  There is simply no way that an interoperability standard like JAUS can stay in front of that kind of development.  Does that mean JAUS is irrelevant?  Absolutely not!  Most systems have many degrees of commonality, whether it’s run-time discoverability of services, teleoperation capabilities, articulated manipulators, video cameras, range sensors, or GPS and positioning devices.  If JAUS can cover 80% of the interfaces required for that common functionality, I’d argue that’s success.  And when you need an interface not covered by JAUS, the service oriented approach and interface definition language (JSIDL) allows for extension through custom services.  Got a new plug-and-play payload that measures chemical composition of soil?  We don’t cover that directly in JAUS, but a well-designed custom service can still take advantage of the JAUS discovery and mutual exclusion mechanisms, without having to write your own interfaces and implementation.
5)      Why would I want to be interoperable?  I want my customers to come to me for their upgrades…
Let’s face it, at the end of the day, this is the most common fear.  In the good ‘ol days, custom interfaces often meant repeat business.  Sorry to break the news to you, but the landscape is changing.  Embrace it.  I’ll put aside the rah-rah stuff that interoperability in a fledgling industry is good for everybody.  I’ll even ignore the big stick that programs like the Advanced EOD Robotics System (AEODRS), Engineer Squad Robot (ESR), and the RS-JPO’s Interoperability Profile (IOP) all rely on JAUS-compliance as a major cornerstone.  So here’s the carrot: Why would an organization want to be JAUS compliant?  Because 80% of the work of developing an Interface Control Document is already done for you.  Using JAUS, development teams can focus more on their constituent pieces rather than negotiate interfaces across team boundaries.  Organizations can re-use assets, whether software algorithms, sensor nodes, vehicle platforms, or operator control interfaces across multiple projects without having to re-implement the same basic infrastructure over and over again.  Sure – it may require a little massaging and some custom extensions here and there, but in the long-run your development times will be faster and your customer will be happier.  It’s as simple as that.