The JAUS Discovery service is the service that allows a JAUS Component to discover/find other JAUS Components or be discovered/found by other JAUS Components in a JAUS System.
The component hosting the Discovery service (i.e. the server) acts as a central "repository" which lists all components that has registered with it. Discovery (service) clients can either register themselves with this central "repository" or query it to get a list of components.
Simple Example
Figure 1A shows an example system with 3 JAUS Component (1, 2, 3), where components 2 and 3 are Discovery clients only and JAUS Component 1 is only a Discovery server. In this figure, the 3 JAUS Components have just come online and there has been no interaction between them.
Figure 1A. A JAUS System with 3 Components. Components 2 & 3 are Discovery service clients only and Component 1 is a Discovery service server.
If Component 3 sends a QueryServiceList message to Component 1 asking for all entries, the returned ReportServiceList will contain an only one entry for JAUS Component 1. The Discovery server knows about the Component it lives on and nothing else (figure 1B).
Figure 1B. (1) Component 3 sends a QueryServiceList message asking for all entries (2) Component sends a ReportServiceList with only one entry for Component 1.
If Component 2 wants be discoverable by Component 3 it must register itself with Component 1 using the RegisterServices message. After this registration process occurs, if Component 3 sends a QueryServicesList to Component 1, the returned ReportServiceList will contain 2 entries: Component 1 and Component 2 (figure 1C).
Figure 1C. (1) Component 2 registers itself with Component 1 using RegisterServices. (2, 3) Component 3 sends QueryServiceList and Component 1 reports 2 entries: Component 1 and Component 2.
Discussion
In the above example, there is a single Discovery server in the entire JAUS System to which all components register. However, this is not the only allowed layout and in fact the Discovery service has the flexibility to accommodate any system design.
In addition, the example shows 2 Discovery clients that are acting in different roles. Component 2 wants to be discoverable, so the Discovery client on Component 2 acts as a Discovery Registrant (it does the registration with the Discovery server). However, Component 3 doesn’t care to be discoverable and instead only wants to know about other components in the system, so its Discovery client is a Discovery Querier (it queries the Discovery server for information). A Discovery client can act in either of these roles or both, depending on the system design.
The most common design found in Unmanned Ground Vehicles (UGVs) is to have a single Discovery server on each vehicle, where other on-vehicle JAUS devices (cameras, arms, etc) register with the single on-board Discovery server (Discovery Registrants). An OCU (Operator Control Unit/controller) will find all the Discovery servers on each vehicle in the system and query each vehicle for the list of registered components (figure 2).
However, it is worth repeating that this layout is not the only option and it would be totally acceptable to have each vehicle register itself with a Discovery server on the OCU, have multiple Discovery servers on each vehicle, or have vehicles components register themselves on servers on other vehicles. The final system needs will dictate the most appropriate placement for Discovery servers and clients and their roles.
Figure 2. Common JAUS System configuration for UGVs. Each vehicle has a single Discovery server, to which other on-vehicle components register. OCU queries each vehicle's Discovery server to discover the vehicles capabilities.
Finding the Discovery Server
The simple example assumed that Components 2 and 3 already knew that the Discovery server lived on Component 1 and as such could send message directly to Component 1 to register itself or query for other components. However, in a dynamic system the location of the Discovery server would be unknown. In addition, the Discovery server may come online after the Discovery clients. As such, clients often need to find a Discovery server before they can register or send queries. As this is client behavior, how to find the Discovery server is not defined by the standard; however, it does provide one possible sequence that can be taken by a Discovery client to find a server (or servers). This is an example of a possible sequence only and does not dictate a sequence that must happen.
Although provided for example purposes only, the sequence described in the standard is the basis for most implementations when trying to find a Discovery server. That is, many (if not all) Discovery client implementations will broadcast a QueryIdentification message out to all reachable JAUS components such that any component that responds with a ReportIdentification message is known to be a Discovery server.
Registration
As seen in the simple example, any Component that wishes to be discoverable is responsible for registering itself with the server using the RegisterServices message. However, the characteristics of the underlying transport layer must be considered. If messages can be lost between the Discovery client and the Discovery server, it is the client’s responsibility to ensure that it is properly registered with the Discovery server.
Handling Component Liveness
During system operation either the Discovery server or a Discovery client could go offline, either intentionally or unexpectedly, and the system needs be able to handle these situations. Unfortunately, the standard does not currently address this issue in any way and as such, it is left to the system implementer to handle.
If the Discovery server goes offline, it is the responsibility of the Discovery client to detect this and re-register itself when the Discovery server comes back online or register itself with a new Discovery server.
If the Discovery client goes offline, the Discovery server needs to detect that the client is no longer available and remove it from its reported list of Components such that it is not reporting Components that are no longer available.