In my last blog (https://neyarobotics.com/dispelling-myths-jaus/), I talked about several of the ‘myths’ that I hear about JAUS, and tried to debunk them a bit. As noted in that article, one common complaint is that SAE JAUS doesn’t cover every possible interoperability issue; there will always be some new function, new sensor, or new actuator that the committee hasn’t considered. Given the rapid pace of unmanned systems development, there is simply no way for the committee to stay ahead.
That doesn’t mean, however, that JAUS is useless in these situations. In this article, I’ll focus on two ways we can maintain run-time interoperability even if existing, published services don’t cover your exact need.
The most obvious approach is to use the HMI Service Set. This is a set of published JAUS services which effectively enable a “remote desktop”-like environment. Rather than the display/OCU pulling information from the vehicle/sensor like it does in most JAUS implementations, the HMI Service Set allows a vehicle/sensor to push data directly to the display. There are JAUS services running on both the display side as well as the vehicle/sensor side to negotiate mouse and button clicks, some simple widgets, and other common display tools. Since the display becomes basically a dummy terminal, it’s assumed that a human operator is available to interpret and act on the data being sent.
The second approach to interoperability in the face of specialized requirements is through service inheritance. SAE JAUS introduced inheritance that follows a model very similar to class inheritance in object-oriented programming languages like C++ and JAVA. By inheriting from a parent service, a child service agrees to implement, and potentially extend, the interface offered by the parent. There are some very specific rules about what a child service can do, but basically: Adding behavior is okay, changing parent behavior is not allowed. When these rules are followed, a child service perfectly mimics the interface of the parent. At run-time, a client service can’t tell if it’s talking to the parent or the child service.
We can make use of service inheritance to add functionality and behavior that’s close to a published service while still maintaining some level of interoperability. Let’s consider an example in which we want to add arrival time to a waypoint. Published JAUS services allow for specification of waypoints (Global or Local Pose Driver), but timing is controlled purely by setting a travel speed. In our case, we want to explicitly define the time of day for the vehicle to arrive at the waypoint, and let the vehicle plan the best way to achieve those goals. We therefore define the “Arrival Time Waypoint Driver” which inherits from Global Waypoint Driver. Furthermore, we’ll define our own custom message that includes both the position of the waypoint as well as the arrival time. Since all services are unique, we’ll also need to give our new service a unique urn, like urn:jaus:dave:blog:ArrivalTimeWaypointDriver.
So how does our new service achieve interoperability? By exploiting the inheritance relationship! Since the child interface must adhere that of the parent, our new service can register with the discovery service as *both* a Global Waypoint Driver and an Arrival Time Waypoint Driver. For clients that only speak pure JAUS, they can still talk to our implementation using the standard published waypoint messages and travel speeds. Sure, they aren’t taking advantage of the full functionality of the service, but at least we’re getting some interoperability. For clients that are aware of our custom Arrival Time Waypoint Driver interface and the new message we created, they can use the arrival time message to take advantage of the new functionality.
Of course, the best way to achieve interoperability is to get new services published. I strongly encourage folks to get engaged with the Committee. If something is lacking, bring it to our attention. Give us your interfaces (not your implementations!) and we’ll do our best to incorporate into the published sets.
Thanks for reading!
