I've been reviewing the SAE JSS Core document and it's clear that we will need to implement the following services to fully support the Core:

1. Transport
2. Events
3. Access Control
4. Management
5. Time
6. Liveness
7. Discovery

As I read through the document a number of things still aren't clear and I wanted to post a list of my questions to the forum, so that we might get a discussion going about some of these. Here is what I'm wondering right now:

1. I don't understand why all of the services need to inherit from transport, events, and access control. If we are to have a component host multiple services, how can we implement inheriting these same services if only one is allowed per component?
2. The management service state transitions seem very ambiguous. There is a dependence on the parent service (Access Control) states and it seems like it would be possible to transition to the standby state directly from init state without truly being Initialized if access control goes into the Controlled state. What is the correct behavior?

Just to help visualize what I'm talking about. I attached a diagram of the Core SAE JAUS services. The services inherit from the service they are connected to from below.

So I still need to review JSS-Core again in minute detail, but I was thinking about this problem last night. I don't think that you can only have one transport service per component. Rather, I think each transport service is what we refer to as a TransportInterface in ojNM. So we used to have some rigidity and rules applied to Transport Interfaces based on their type (cmpt, node, subs), but I think those rules, at least on receipt, go away. Then each transport interface provides a unique point for receiving messages, dependent on the particular medium or underlying technology (sockets, UDP, TCP, Serial, etc). Services will each have a transport service which provides an IPC-style interface to the "master" or "main" component transport service. This "master" will be the runtime engine, its job is to simply provide Component, Node and Subsystem message routing based on the transport services registered to it.

The nomenclature is different, but the architecture is the same as NM 2.0.

I'm thinking along the same lines. The problem is that each service defined in Core inherits a transport service and each transport service has to define a (subs, node, cmpt) endpoint in the system. Maybe they intended for multiple services to share the same inherited parent transport service, but I'm thinking that we can just apply stricter rules to OJ. I think I'd like to make each service it's own component endpoint. Then we can have a master component like you talked about, that would implement the discovery service. It would be like the new NM, and the other services or transports could get the information they needed by IPC with that master.

I like the idea of having a component be an instance of a service. In this sense the service is like a Class and the component is like an Object. I think this would allow us to actually implement the services as their own Classes and use C++ inheritance to implement service inheritance. Then when you instantiate a service, you will automatically get the proper access control -> event -> transport services supporting it. The more I think about it the more I like one service to one component. It makes things a whole lot simpler and it is also compliant.

I'll talk a little about how the generated code works in JTS.

Each component has 2 interfaces. I call them messageRouter and jausRouter.
The messageRouter is the mechanism for sending messages between services, that is not using JAUS and requires that you know that the other service lives within the same component and is accomplished by passing pointers around.

the jausRouter is the Interface for sending messages over the JAUS transport and this is were you could implement your different interfaces (UDP to a NM component, JUDP, etc). The implemented interface assumes there is a NM so it sends all messages to the loopback to an assignable port (usually the JAUS port), similar to the current nmi.


Each has service 3 mechanisms for receiving data.
An internal event handler: which alerts the service that an internal even has occurred and allows inter service communication (between threads that may belong to the same service).
A message handler: which alerts the service that a message has been received and the appropriate transition in state machine needs to occur.
A jaus message handler: which alerts the service that a JAUS message has been received and the appropriate transition in state machine needs to occur.
All three have queues where the internal event or messages sit until they are processed.

The message handler and jaus message handler could replaced with 1 handler but there are 2 because of the format difference between the messages. The message handler expects messages to be formatted in the new JSIDL message format, the jaus message handler uses the old RA format. I think this might also be the reason why there are 2 routers.


The component constructor takes 5 parameters, the subsystem, node, cmpt ids, the udp port that the component uses for incoming messages, the port that nm uses to receive messages. The component constructor then constructs all the services and passes the messageRouter and jausRouter to the services during construction. This way every service uses the same instance of the transport mechanism.

When a service is constructed it creates its own instances of the internal event handler, message handler, and jaus message handler. Then it initializes its input and output message lists and finally registers the input messages with the routers. Registration is required since the only way to route messages to the correct service is based on the message code. Therefore, only 1 service is allowed to handle a message ( you cannot have 2 services receive the same message ).

Finally the service's state machines are constructed. This is the class that the user implements all the actions and guards which are executed within the state machine. For example the Event service has an action called createEvent which the user implements. When the state machine is constructed it is passed the internal event and message handlers so that it can use the transport mechanism. That way in the sendEvent action for the Event service the user can use the corresponding message handler to send the message.

A thing to note is that the state machine transitions are implemented using the SMC compiler.

This is probably very confusing but if you have access to the code it will be a little clearer.

Danny and Tom, see my notes on the way JTS is implemented, it is similar to what you are thinking.

One thing about only having a single service per component though is that you eliminate the ability to tell if a component is alive or not since you can't put say a PD service together with the Liveness service.

I also think that you won't be able to have a component "with a built in nodemanager", that is you would always need to have a separate NM process. The current NM allows you to have the component and NM live together so they are running in the same process. I think this is useful for something like an OCU where you run a single executable and it automatically connects to the JAUS network.