Hello;

I'm interested in JAUS and potentially will be using it (I'm associated with Thales). Having read some of the literature, various questions have arisen to which I hope I may find the answers. Ok, so it turned into more of a discussion, but any light would be useful!

There seems to be two versions of the AS-4 Unmanned Systems Steering Committee website:
www.sae.org/servlets/works/committeeHome.do?comtID=TEAAS4
sae.org/servlets/works/committeeHome.do?comtID=TEAAS4C

The first one gives the impression that the AS-4 Unmanned Systems Steering Committee is not currently active, in that there are no links to relevant JAUS documentation / works in progress (I think openjaus.com points to the wrong one at the moment). It’s also a bit odd how the main page (for the above links) mentions meetings that are not specifically for the AS-4 USSC.

1. How are change proposals now handled, how long would a typical proposal take to be validated? Is it the AS-4 USSC that now does the validating?

2. There is not too much activity on the various forums associated with JAUS. I understand that there is still a transition stage taking place from the initial project, but I have the impression that perhaps the majority of implementations are taking place behind closed curtains (possibly for proprietary reasons). I’m sure the need for interoperability is one of the aims of JAUS, but if the user base is closeted away developing their own implementations, I imagine this is somewhat difficult to achieve. Particularly when I’ve heard there’s room for different interpretations that produce different (perhaps non-compatible) implementations.

3. Question on a part of Reference Architecture Specification Volume II, Part 1:
Data may be communicated through other means (such as shared memory) that is not in JAUS format – this does not break the interoperability rule (and so remains compliant). Only “when data is sent between JAUS defined components, must it be formatted into a JAUS compatible message ”.
My interpretation of the above is that a JAUS component may have additional methods of communication that do not use JAUS formatted messaging (and are still considered compliant). Is this correct?

4. Considering the desirability of separating subsystems down into individual communicating components, has there been any coordination with the multi-agents standard body FIPA? I can see many similar concepts being employed and there could be many advantages gained for both JAUS and FIPA through considering some level of interoperability.

5. I would have thought some form of security would be provided in JAUS (given latest U.S. drone mishaps). Is there any?
If not, perhaps it could be implemented something along the lines of a robot having an open channel to allow friendly robots/ users to initiate contact. The said robot (with assistance from its operator?) could then determine if communication should continue (and whether to use an open or a secure encrypted channel).

6. Question on quote (2007 RA specification Part 2) :
“Messages larger than 4095 bytes, including the 16-byte header, are considered large data sets. Transmission of dynamic configuration file data or streaming video data are examples of large data sets that will be supported in a future JAUS RA revision.”
Has this been addressed yet?

7. More of a pointer than a question (2007 RA part 2) :
Under the Bit Precedence rule, I assume Bit-6 for the Service Connection is currently defunct? (Given other sections mention the Service Connections is deprecated)
…and also for the ACK/NAK rule (2007 RA part 2):
“The sender shall always set ACK/NAK=0 on service connection messages”
Defunct?

8. The openjaus.com documentation section does not make it clear that there is also the SAE JAUS standards documentation which one may require (I think?), besides the documents provided in its section :
AS5669 JAUS Transport,
AS5710 JAUS Service Set Core,
and AS5684 JAUS Service Interface Definition Language
and the following (considered works in progress): ARP6083, AS5710A, AS6040, AS6057, AS6060, AS6062, AS6063, AS6084, AS6091
Or am I missing something?

9. Given the status of “works in progress” are these additional documents considered ratified (i.e. parts of the JAUS standard)?

10. After purchasing the various SAE documents on JAUS, do they need to be repurchased when they are updated?

I think that’s more than enough from me for now. Stay tuned for my next voyage through JAUS documentational space.

edit:second link was pointing to wrong page (problem still holds though if you navigate to works in progress for the first link)

Hi,

Glad to see that you're taking a serious look into using JAUS. It seems as though you have put a lot of time into this already. Do you think Thales would be interested in using and helping OpenJAUS? We could really use a couple more good sponsors.

I can answer a couple of your questions very quickly, the rest I'll try to get to soon. I need to do a little fact checking first:

1. The process is mostly dependent on how long it takes someone in AS-4 to update the appropriate documents. If you were to become a member of the committee and do all the work, then that would be welcomed by AS-4 and the process would go much quicker. Once AS-4's work is complete it takes a couple of months to finish the SAE approval and voting process.

2. Currently we know of no other SAE JAUS implementation other than the JAUS Toolset and our own upcoming implementation. Several organization have decided not to develop their own because their previous implementations were not very profitable. Some are waiting for the new OpenJAUS.

3. Yes

9. No

Thanks for the quick response. I'm doing a review of various robotics communication methods at the moment, but it is possible my research group may give it a trial run (it seems like a strong contender). So I think it's early days yet concerning the subject of sponsorship (and such a proposal would be made by my manager).

Re. Q2 - In terms of implementations, I meant the way the organisations were developing their systems to use JAUS (perhaps using the toolset). Of course if there is not much interaction with the rest of the community (from the organisation), then bugs tend to hang around longer, not to mention cause the said closeted organisation more problems than they necessary. I suppose the thing I'm wondering about is how open the participating organisations are concerning problems they encounter through use of JAUS. I'm sure for commercial companies, there are IP protection concerns, but do they shut themselves off from the community as a result? I'm more asking this particular question out of curiosity about people's opinions than anything else.

Glad to hear that we're a strong contender. If you end up using something else, please let us know why. The feedback is always helpful for us to improve OpenJAUS.

As for your question, I can speak from my experience in the past with JAUS. Back in the day when everyone in the JAUS working group was developing home grown JAUS 3.2 & 3.3 implementations, we used to have face-to-face interoperability experiments. They were very helpful and open because you got to test your code with everyone else, so you could see first hand the problems that others were facing and fixing. The main issue with that wasn't due to IP protection concerns, rather the problem was that they were too expensive to conduct.

In my opinion the main issue that JAUS has now is that there are too few implementations of SAE JAUS being developed. A lot of folks got burned developing JAUS products in the past and didn't make any money off of them. As a result, almost no one is reworking their implementation to use JSIDL. The JAUS development model that we're trying to propose is for more organizations to use OpenJAUS and contribute to it, at a fraction of the cost of what it takes to develop their own full implementation. Also, by everyone using the same base code, we're able to have very interoperable systems. In effect, the cost used to be: Cost of 1. Participating in the working group + 2. Cost of writing standards documents + 3. Cost of writing a full implementation + 4. Cost of testing interoperability + 5. Cost of fixing interoperability bugs + 6. Cost of code maintenance, ... By everyone using OpenJAUS the cost is now: 1. Cost of contributing partial implementation + 2. Cost of testing interoperability with a single code base + 3. Cost of standardizing what has already been implemented and tested + 4. Cost of contributing to group maintenance.

It makes sense from a cost standpoint, but the problem that OpenJAUS is facing is that we need more organizations to sign up. The attitude we're seeing right now is that folks are waiting for the end product instead of helping to contribute to get an end product sooner. We need help turning that around. Any insight would be appreciated!

I think people were willing to do more work in the past when they saw $$$ in JAUS. Unfortunately standardizing is not profitable. In my opinion standardization is simply an expense, but I think it is a worthwhile one.