JAUS Tool Set Forum - Blogs

Multiple Services per Component: A Simple Solution

ArfathPasha — Wed, 25 Aug 2010 13:23:46 GMT

In an earlier blog, I outlined the problem with having multiple services per component. I also ended the blog by stating,

Quote:

it was an architectural design decision to not address the need for multiple leaf services per component in the first step of transitioning from JAUS RA to SAE-JAUS JSS specifications. To use JSS v1.* to implement such components would result in implementations that are not equivalent with the specifications they implement.

Well, upon yet another close inspection of the problem and JSS v1.* services, I found that we have addressed the problem quite unknowingly!! The solution is AccessControl. Access control ensures mutual exclusion among clients. This means that once a client has acquired mutually exclusive control over a component with multiple leaf services, there is no danger of other clients attempting to make the "unspecified state changes" that I described in my earlier blog.

So as long all the leaf services that have common base services with more than one state inherit from AccessControl, there should be no problem. This I believe is the case with JSS v1.* services. Voila!!

Look out for my next blog on a simple solution for access control for a group of services distributed across multiple components, nodes and/or subsystems.

Multiple Services per Component:

ArfathPasha — Wed, 18 Aug 2010 19:33:30 GMT

The case for them, and the rational behind the lack of support for them in JSIDL v1.1 and JSS v1.*

Acronyms used:
JSS - JAUS Service Sets (SAE)
JSIDL - JAUS Service Interface Definition Language
RA - the now old Reference Architecture

From the recent deluge of enquiries we have received, there seems to be a need for having multiple

Attached Images

unspecifiedStateChanges.jpg (15.9 KB, 312 views)

Major changes between the JAUS Reference Architecture and SAE-JAUS JSS v1.* Specs

ArfathPasha — Wed, 18 Aug 2010 18:48:40 GMT

Aside from the main objective of converting the informal JAUS RA specification into a set of formal, machine readable specifications, the AS4-C committee set the objective in the transition from the JAUS RA to SAE JSS to a direct translation of the RA components into services with as few changes as possible. This was an important and necessary objective since it would not have been a transition if the JSS specifications had little or no resemblance to the JAUS RA components that existing JAUS users were already familiar with. Besides, it is hard to make large leaps especially when it comes to design-by-committee. With the publication of JSS v1.*, the objective has now been met. For instance, a JSS based PrimitiveDriver component (or a WaypointDriver component) when built, bears a lot of resemblance to the corresponding JAUS RA components specifications. Aside from fixing gaping holes and errors that existed in the RA, the only major changes that were introduced during the transition were,

1. Breaking the tie between component function and component ID.

2. Removal of the instance ID in the JAUS ID tuple.

3. A clear separation between application and transport with the introduction of the layer design pattern.

All this means is that,

- A component with ID=33 does not have to be a Primitive Driver anymore.

- A component cannot contain more than one instance of say, a Primitive Driver for redundancy or any other relevant purpose.

- Components exist in the Application Layer and use the underlying Transport Layer to communicate with one another.

Building for Windows

Dave — Wed, 24 Feb 2010 14:41:38 GMT

I'm excited to report that Jr Middleware (www.jrmiddleware.org) has now been integrated into the JTS Software Framework. This brings with it a fully featured transport layer, capable of JUDP, JTCP, and JSerial transport using both 5669 and 5669A headers. In this blog, I'd actually like to talk about a side benefit: The ability to compile generated code natively in Windows.

Since Jr Middleware is intended for cross-platform use (Windows, cygwin, linux), it features a modest OS-abstraction layer (cleverly hidden in OS.h and OS.cpp). By extending this layer to include mutexes and condition variables, we are able to eliminate the direct calls to the pthread library that previous generations of the code had been using.

There are several installation requirements to build for windows:

Install a Microsoft C++ compiler. Note that the "Express" edition available free from Microsoft is fine; you don't need the full blown Developer's Studio.
Install python for windows (www.python.org). Make sure the installation directory is added to your PATH environment variable. From a command prompt, type "python --version" to make sure it's installed correctly.
Install scons for windows. From a command prompt, type "scons --version" to make sure it's installed correctly. (NOTE! I've had problems with installation, such that the scons.bat script is not copied from /Scripts to . If this happens, you can manually copy the scons.bat file or add /Scripts to your PATH).
As with the Linux build, you'll need to set the JTS_COMMON_PATH environment variable. See Chapter 4 of the User's Guide for more details.

Lastly, remember that not all command shells are created equally. The required environment variables are not set from a basic command prompt; that is, typing "command" from the "run" prompt won't get you where you need to be. Look for the command prompt installed by your Microsoft C++ edition, usually hidden under a menu item named "Visual Studio Tools". This will automatically set the necessary paths to find the windows components required.

Once you're set-up, building is as simple as type "scons" from the command prompt in the directory to be built. As always, visit us on the forums if you run into trouble!

Dave

Rationale behind the Transport Service

ArfathPasha — Tue, 09 Feb 2010 03:41:04 GMT

The questions and answers contained in the document below bring out the rationale behind the transport service.

Attached Files

why a transport service2_5.docx (25.6 KB, 432 views)

How do I use the Transport Service in generated code?

Dave — Mon, 08 Feb 2010 21:43:29 GMT

The published JAUS Service Sets all make use of the Transport Service at the top-level of the food chain; that is, all services derive from Transport Service. Depending on who you ask, the Transport Service is either a critical requirement for formalization of the service interfaces or an academic left-over with no real practical impact. I

Managing the Database. How to backup, restore, etc.

ArfathPasha — Wed, 03 Feb 2010 12:54:33 GMT

This blog contains instructions on how to clean, rebuild, backup, restore and update the database.

Clean:

The ant target for this operation is "clean-database". This operation only cleans the current database. It does not clean a backup of a previous version of the database that may have been created.

Rebuild:

The ant target for this operation is "schema-export". All data that exists in the database is lost when the database is rebuilt.

Backup:

The ant target for this operation is "backup-database". This will create a backup copy of the database. Only one backup copy is maintained at any given time. i.e. each time a backup is created, the new backup copy wipes out an earlier backup if one existed. It is a good practice to make frequent backups.

Restore:

The ant target for this operation is "restore-database". The database is restored to the last backup version, if one exists.

Update:

The model on which JTS is built closely resembles JSIDL. As the JAUS standard and JTS evolve, it is highly likely that both JSIDL and the model behind JTS may change. Each time this happens, existing databases and its data may get out of synch with the new model and schema and may need to be updated.

The easy way to perform an update is to use the "schema-update" ant target. This can be used if the change is a typical backwards compatible change that involves the addition of new attributes to types.

For more complex changes, follow the procedure below (courtesy the jMatter user guide).

1. Dump your data out of the database
2. ant schema-export (wipes out the data)
3. restore the data

The restoration of data usually needs to be broken down into at least these steps:

1. drop constraints on your schema
2. restore the data
3. add the constraints back in

Working with elements, how to delete & who references who

ArfathPasha — Tue, 02 Feb 2010 20:34:52 GMT

Each user created object in JTS may reference (or be referenced by) other user created objects to which it shares an association (see The "Model" behind the "Model Driven Development" methodology employed in JTS for information on entities, value objects and associations). Objects can be deleted only if they are not being referenced by other objects. This is explained below with the help of an example.

For instance, the fixed field X in the figure below contains a forward reference to a value set (which happens to be empty). It also contains a backward reference to a record called LocalWaypointRec that uses X in its specification.

X cannot be deleted as long as LocalWaypointRec holds a reference to it. To delete X, either the referencing object LocalWaypointRec must be deleted first (thereby removing the reference), or just the reference between LocalWaypointRec and X must be removed.

Every element UI contains a button at the top right corner for a tree view. The tree view provides a clear picture of the forward and backward references as seen in the figure below. The blue icons in the tree view represent backward references.

Attached Thumbnails

Attached Files

The "Model" behind the "Model Driven Development" methodology employed in JTS

ArfathPasha — Tue, 02 Feb 2010 19:31:44 GMT

In the JTS code, we use the concepts of Entities, Value Objects and Associations (courtesy jMatter).

Entites and Value Objects are model elements that further qualify an object.

An object defined primarily by its identity (rather than its attributes) is called an Entity. Entities can be tracked through time by virtue of their identity.

A Value Object on the other hand, is defined primarily by the values of its attributes. It has no identity. Value Objects represent the descriptive aspect of the information contained within Entities.

Associations abstract the relationships between entities.

The JTS GUI was built based on a model containing entities, value objects and associations. Naturally, there is almost a 1-1 mapping between this model and JSIDL. A few differences between the two were introduced to simplify the JTS view and also to enhance the JTS feature set. A sample view of the mapping between the model and the GUI implementation is shown in the figures below.

A complete treatment of these concepts can be found in "Domain Driven Design" - by Eric Evans.

Attached Thumbnails

Attached Files

Help! I can't import my JAUS Service Set!

Dave — Mon, 01 Feb 2010 23:16:42 GMT

During development of JTS, and particularly the code generator, we relied on the XML published by the various JAUS Service Sets (Core, Mobility, and Manipulation) to serve as test cases. In almost all published services, we found minor inconsistencies that prevented the code from generating correctly the first time through. My goal with this blog is to help those who look to import and generate services from the published material.

I have to preface this post with an unfortunate fact: I cannot distribute the

Why don't I find a Node Manager in SAE JAUS?

Dave — Mon, 01 Feb 2010 15:33:44 GMT

For those new to the JAUS Tool Set or SAE JAUS, the purpose of the node manager can be confusing. In this blog, I

Build and run the example waypoint driver

Dave — Fri, 29 Jan 2010 22:32:00 GMT

The Waypoint Driver example is based on six independent components that demonstrate waypoint following of a simulated vehicle. The simulator itself is very primitive, as the goal is not to demonstrate vehicle behavior but rather to show how multiple complex components can be integrated in a distributed system using published SAE JAUS services generated by JTS.

There are six components required to run the simulator:

� Node Manager: The Node Manager provides component-to-component message transport for local and remote entities. It is required for virtually any implementation that uses more than a single component.

� Discovery: The Discovery component provides a run-time directory of known services. At start-up, each component may register with the Discovery component to advertise its available services. When a component needs to make use of one or more of these services, it can query the Discovery component for the JAUS ID of an available host. This component is based on the Discovery Service published in SAE AS-5710.

� Vehicle Simulator: The Vehicle Simulator is a JTS-specific service that is not published by SAE JAUS. It provides basic vehicle simulation capabilities by updating the vehicle position based on wrench effort commands.

� Pose Sensor: The Pose Sensor Component gets the vehicle position from the Vehicle Simulator and makes it available in a JAUS compliant service. This component is based on the Local Pose Sensor Service published in SAE AS-6009.

� Waypoint Driver: The Waypoint Driver component gets a list of waypoint command from the OCU and implements a primitive waypoint tracking scheme. The algorithm generates primitive wrench effort commands to the Vehicle Simulator based on the position currently reported by the Pose Sensor Component. This component is based on the Local Waypoint List Driver Service published in SAE AS-6009.

� Example OCU: The OCU sends a list of waypoint commands to the Waypoint Driver and monitors the current (active) waypoint. The display is text only. This component is a JTS-specific service that is not published by SAE JAUS.

The waypoint example is intended to show how published SAE JAUS services can interact with one another. Note that the architecture is very hierarchical; the Pose Sensor provides a service to the Waypoint Driver but is a client of the Discovery and Vehicle Simulator. Since it is a client of other services, we can expect the Pose Sensor to have an increased message vocabulary that extends beyond that published by SAE JAUS. For example, the Pose Sensor will broadcast a Query Identification when searching for the Discovery Component. Once found, it will send a Register Services message to publish its interfaces as well as a Query Services to find the Vehicle Simulator service on which it depends. As a result of these queries, the Pose Sensor component can expect to receive the Report Identification and Report Services messages, neither of which are part of the Local Pose Sensor Services input vocabulary.

To receive and process these extra messages, we have two design choices: 1) We can extend the published input_set and protocol of the Local Pose Sensor Service to handle these messages; or 2) We can add a new �companion� service to the Pose Sensor component. Because we wanted to keep the example as close to published SAE JAUS services as possible, we elected to implement companion or client services that would specifically handle messages coming from services on which the Pose Sensor depends. Since the Pose Sensor uses both Discovery and the Vehicle Simulator, we created both a DiscoveryClient service and a VehicleSimulatorClient service.

Since each service is generated as a separate library, we also need a mechanism for sharing data between the service implementations. For example, when the VehicleSimClient gets a ReportSimulatedPose from the Vehicle Simulator that provides an update on the vehicle position, it needs to make that information available to the LocalPoseSensor service. This is achieved by sharing a common PoseSensorSharedData object that is made available to the state machines of each service in the component. Other data sharing data techniques are available, such as a shared memory map or data file; this technique was selected only for its simplicity.

Of course, the Pose Sensor is just one example of a component that is a client-of other components. Here is a complete list of all components, and the services they host (for brevity, inherited services such as Management and Access Control are not listed):

� Discovery Component: Discovery Service
� Vehicle Simulator Component: SkidSteerVehicleSim, DiscoveryClient
� Pose Sensor Component: LocalPoseSensor, DiscoveryClient, VehicleSimClient
� Waypoint Driver: LocalWaypointListDriver, DiscoveryClient, VehicleSimClient, PoseSensorClient
� Example OCU: Example OCU Service

The JSIDL for each non-standard service can be found in examples/xml.

Running the waypoint driver is simply a matter of building each of the six components using the �scons� build script, and running each resultant executable from the �bin� directory. Start-up order is important, so readers are encouraged to start the components in the order listed at the front of this article.

How We Develop JTS

ParagBatavia — Thu, 28 Jan 2010 15:57:21 GMT

I wanted to post a bit of information on our development process, how we do things, and why we do things that way. The purpose is mainly informational, but I'd certainly like to hear feedback.

For the last 4 months, the JTS Team has consisted of the following folks:

Arfath Pasha - Wintec Inc - New York
Dave Martin - Devivo AST - Huntsville
Drew Lucas - U Florida - Gainsville
Parag Batavia - Neya - Pittsburgh

You can see that we're obviously geographically separated, which makes development of a complex, systems-level tool like JTS a challenge. Luckily, all the folks on the team are good communicators, and understand what it takes to work with remote teammates.

In terms of development process, we've adopted the following practices. We're not extremely rigid about how we do this - but there are some principles that we always keep in mind:

1) Daily communication is necessary
2) Short iterations are good
3) Tracking daily progress is good
4) Tracking, communications, etc, should be low overhead

We've adopted the Rally set of tools (http://www.rallydev.com), which is used for Agile software development. While I don't claim that we have a full Agile process by any means, we have made good use of the planning and task tracking tools.

We operate with two week iterations, and chunk out User Stories that (ideally) fit within what can be accomplished by a developer in 2 weeks. At the beginning of each two week period, we have a planning session where we review existing bug and enhancement tickets, along with issues raised during the previous iteration, and develop user stories which are broken down into actionable tasks, with each task ideally being 0.5-2 days in duration.

We also have daily standup meetings (ideally capped at 10 minutes, but we've been hit and miss on that) via Skype, during which we review our progress via Rally, bring up any issues that may be blocking folks, and go over what was done the previous day, and what's expected to be done the current day.

My job is to coordinate this process, help set priorities for what should be worked on, and in general manage the development process.

I've found our approach has worked reasonably well, largely in part because the team is extremely professional about adhering to our (relatively simple) guidelines. It's definitely added transparency to what we do, why we are doing something, and how long it's taking. This is (slowly) helping us refine our internal estimates for how long tasks should take, which helps globally in meeting release schedules.

None of this is rocket science, and it's a pretty standard way of managing a small development team.

Philosophy of jMatter. Why it was chosen for JTS.

ArfathPasha — Wed, 27 Jan 2010 20:43:07 GMT

jMatter is a software framework that implements the infrastructure of the typical application that requires CRUD (create, read, update and delete), persistence and search. The framework is built around speed and agility for the developer and the end user of the application. An application can be built very quickly with minimal coding, and if needed, the framework can be extended efficiently to adapt to changing user needs. The features implemented in jMatter allow users to complete their tasks quickly and with ease. The end result is a powerful combination of large time savings and enormous flexibility for both the developer and the end user.

jMatter satisfied the initial set of requirements that were set forth for JTS. These requirements were,

1. Reuse of an open source software framework that is well written, actively being supported and stable. This was an important requirement for JTS given the short time frame in which JTS had to be developed.

2. Software must be based on strong fundamentals. This was also an important requirement since a strong foundation will have a lasting effect on the entire life of the application. jMatter is built using a powerful software methodology called Model Driven Development. The quality of this methodology is akin to the methodologies followed in most other engineering disciplines where the creation of an object begins with a formal design and process. For example, a Civil Engineer constructs a building from a blue print. The blue print tightly relates the building to an underlying model that gives the building (structural) meaning and thereby makes the model relevant mainly from the perspective of formal reasoning about the building.

3. Implements the model-view-controller pattern. This makes it very easy to change the model, view or controller components to adapt to changing user needs.

4. Reuse of existing service specifications. jMatter is integrated with a lightweight, yet powerful back-end database system that encourages the reuse of existing specifications.

5. User-friendly front-end features. jMatter comes with front-end tools for making powerful queries to the database and other useful UI features like dragn'drop, copy-paste etc.

6. Comes with a basic UI that is extensible. The jMatter UI is highly extensible.

7. Looks cool! :)