First, I want to say that I think highly of the JAUS Toolset (JTS) team. I know everyone on that team personally and consider them all my friends. As a matter of fact, Tom Galluzzo and myself (the OpenJAUS founders) worked on the JTS project for over a year (May 2008 – September 2009). During that year we worked with the other members of JTS to get the project started and lay the foundation for the path forward. I’m not sure if many are aware, but the JTS project is sponsored by the Office of Naval Research (ONR) and the people working on it (including me at the time) are having their time & effort funded. In September of last year Tom and myself were not included in an additional round of funding on the project. After that we discussed our personal opinions on the project, the technologies being used and the focus of the work and decided there was a significant opportunity for a different approach to the problem. We wanted to explore that approach through a new OpenJAUS SDK. In December of last year we kicked off heavy development of our SAE JAUS efforts with the focus and tools we felt were best for the job.

So when I compare and contrast the projects, know that I have some intimate experience with both JTS and OpenJAUS. I have also built half a dozen JAUS-based robots in the past, used or interacted with three or four JAUS SDKs from various vendors and spent countless hours working within the JAUS working group as both a document sponsor and developer. I am very invested in the JAUS community and really want the community and the standard as a whole to flourish and be successful.

Project Focus

The first topic I feel is best to address is one of focus. It is my firm belief that the vast majority of JAUS users (currently) are using JAUS on a mandate. Certainly there are users who see JAUS as a feature and want to build it into their systems as such, but most people coming to JAUS or using JAUS in some way are doing so because they are told to do so. Therefore it has been my experience in the past 4 years working on the OpenJAUS project that these people are interested in “The JAUS Standard”. By that I mean they are only interested in the services, messages, etc that are part of the published standard or maybe draft documents. They are not interested in “experimental messages” and “custom components”. Despite those features being in the old RA (and being features I use frequently) they are an issue for interoperability and compliance and therefore most of our users are uninterested in them.

In the new SAE standard, it is relatively easy to build or extend a standard service to add features, messages, etc that are unsupported in the published document. I feel that the JTS project is too focused on that use-case. Rather than publishing a library of usable classes which implement the standard behavior, the JTS project provides a GUI environment in which a service can be imported from the standardized XML or built from scratch. Then C++ code can be generated from that service.

Allow me to stress one thing. This kind of tool is an INVALUABLE resource for people, like me, that are developing the actual JAUS standard. We need a tool that easily allows us to build services, build messages and verify that these things are valid within the semantics of the JSIDL language. The JTS tool provides that capability and the ability to export the resultant XML file(s) for use in the standards documents. This is of enormous value to the portion of the community that will use the tool to build the standard. As a matter of fact, I used the JTS tool in just such a way this past summer in building the XML for the AS6060 Environment Sensing document and it was very valuable.

However, that is not the profile of most of the JAUS users I have interacted with during the past 4 years of OpenJAUS. Those people are interested in code, libraries and APIs which allow them to integrate easily into existing systems and add JAUS functionality. Therefore, that has been a focus of the OpenJAUS team in the past and remains the focus of the OpenJAUS 4.0 SDK. We want to give users a library, documentation and header file(s) which they can use to build their robots or to integrate JAUS functionality into their existing systems. Our first version of this library will be the C++ codebase we are about to put into beta testing.

We have developed the library using some tools within Eclipse based on the ECore modeling language. What this means is that we have modeled the JAUS language and then we build our services inside Eclipse and auto-generate C++ classes which implement those services. I mention this only because a by-product of this development path has been that we have a set of Eclipse plugins which allow us to build JAUS services in a graphical environment, just like JTS. Our plugins work inside Eclipse and we feel this is a better solution for most developers than a stand-alone application built on JMatter (which is what the JTS team uses). These plugins are not part of the beta test. Currently they are pretty rough and lack the polish and ease-of-use we would like to have prior to rolling these tools out to the community. This is something we plan to focus on early next year and make available as part of the OpenJAUS license in the future. Again, I don’t feel this is a need for the vast majority of users, but will be beneficial to those that can and would like to build their own services and messages.

Data Model

Speaking of data and models, that brings up another major difference in the two projects. The new JAUS standard is based on the JAUS Service Interface Definition Language (JSIDL) which is published as an SAE document. This defines the XML schema / language for defining JAUS services. It also formalizes the data model for the standard. During the development and balloting of JSIDL, I had very little opportunity to work personally with the data and the schema and really evaluate some of the features. Now that I have, I feel that JDISL is bloated and in many ways confusing and hard to use. JTS is very faithful to JSIDL and the way services and messages are modeled in that tool is pretty much a 1-to-1 mapping of the language.

When we sat down to build OpenJAUS 4.0, we spent a lot of time becoming frustrated about some of the bloat and nomenclature in JSIDL. It was then that we realized the important parts of the data model are this: the bytes on the wire and the behavior of the state machines. Everything else is free to interpretation. Therefore we have spent a lot of time and effort in minimizing and streamlining the JSIDL model. For example, in JSIDL to define a Scaled Integer type you define a fixed_field and add a scale_range attribute, but in OpenJAUS we define a type called “Scaled Integer” which is just that and don’t overload the fixed_field type. I feel these things help to streamline the user’s experience to the standard by making the data model more intuitive and easier to use. As long as our Scaled Integer type is bite-wise compliant with the fixed_field(scale_range) type defined by JSIDL (and therefore JTS) then the services will be compliant and interoperable. This is just one example of many we have made throughout the JSIDL model to improve it for OpenJAUS users. Once we get a significant amount of experience, some of these changes and simplifications (like removing some redundant complex types) will hopefully find their way back into the published standard in the future.

Advanced Features

Over the last 4 years, we at OpenJAUS have had an amazing number of requests for different features and capabilities. We have also spent a lot of time building systems using OpenJAUS and run into a number of things that would enhance the project. Whenever possible we have built those features into the OpenJAUS SDK. However some of them were just not easily doable given the architecture of the system. When laying out the design for OpenJAUS 4.0, we spent a lot of time gathering those requests and opinions from existing OpenJAUS users. We then built what we felt were the most important of these features into the system architecture (such as dynamic configuration, link compression, link encryption and message timestamps). We have put considerable effort into these features and some are ready to go and others are just conceptual at this point. Everything has been done in a way to guarantee backwards compatibility to other “vanilla” JAUS implementations but expose these capabilities and features at runtime when working between OpenJAUS-based applications.

One of our goals for OpenJAUS and the OpenJAUS community is to leapfrog the current development cycle. Currently the standards body is developing a standard essentially “on paper” and the implementation community is taking that and building implementations. This has been an understandable and appropriate pattern as the standard has migrated from the Reference Architecture to JSIDL and SAE documents. However, going forward, we want to leverage OpenJAUS as a platform to build features and capabilities that our users need, verify the approach is valid and useful to someone and then bring these implementations to the standards body for standardization.

Business Model

The last thing that really separates the two projects is the code licenses, which are very much tied to the business models of the two organizations.

The OpenJAUS organization has existed as a rather ad-hoc collective for 4 years now and had some support in various forms from a number of organizations over that time. The vast majority of the support has been in donating some time to support OpenJAUS from the companies Tom Galluzzo and myself have been employed full-time at during that period. However, Tom and myself have and continue to invest a large portion of our “free time” into OpenJAUS including nights and weekends. We have designed and built the new website, supported users through the forums and continued to use and develop the code base. When all the support and development needs were based on the previous code base, the level of effort was pretty manageable. The code was (and continues to be) free and the expectations of support were relatively low.

However, this new effort has taken a significant amount of time and work. At the beginning of this effort we reached out to the JAUS community asking for other developers and organizations to get on board and help us build the project we envisioned. We had interesting conversations with a number of interested parties, but the end result was that in the down economy people were understandably interested but non-committal. Tom and myself remained steadfast and decided that we would push forward with the work as individuals, but change the license to recoup some of our NRE and support the project by paying for things such as web hosting and other needs. It is also important to note that there will continue to be a free open-source version of OpenJAUS available. A GPL licensed version will be available for non-commercial and educational projects. I feel it is important to continue to support and encourage educational use of the JAUS standard and we absolutely will continue to support that model. However, many of our users develop systems for government and commercial uses and we feel it is justified to expect some return on our investment to building the best JAUS SDK we can and empowering our users to get their jobs done faster.

As I said before, the JTS team is currently sponsored to do their work by ONR. Their webhosting, support time, etc are mostly done on time paid for by ONR. I don’t want to sound negative, but I would not expect ONR to pay for that support and development forever. Many of us know how government funding can disappear quickly. It remains to be seen what will happen to the JTS group at that point. If it has significant industry support and usage, it may survive and flourish as an open-source project; it may not.

I know what the future of the OpenJAUS project is. The same team that has supported it for the last 4 years will continue to support it as long as our customers are there. We have built a user base and community around the OpenJAUS project. We feel that is not because the code is open source and free, but hopefully also because the quality of the project is professional and easy to use. We seek to continue and improve on that level of robustness and ease-of-use going forward and put out a product that not only are we proud to use and support but that will be befitting of the OpenJAUS branding.

Each user of the JAUS standard has a choice. Choice is, as always, good for users and good for the marketplace. The difference in focus of the two projects means that different users might make different choices for which project to support. Money will always be a factor, but I do not feel like it is the only factor involved in this decision. Choice in the marketplace will hopefully cause both projects to improve, innovate and drive the standard forward all the quicker.

Written By Danny Kent, OpenJAUS Co-Founder