Synchronization Service

The following diagram shows how the JAS Synchronization Service fits into the overall communication stack. The Synchronization Service provides a standard interface to applications for sending and receiving time and event messages across a communication link. This service is typically used when the data link supports the ability to send low-latency messages to a broad number of network endpoints simultaneously (i.e. multicast or broadcast). The intent of the Synchronization Service is to keep applications synchronized. The two primary methods by which synchronization is accomplished are to globally distribute time to all nodes within a system in an effort and to provide one-shot or periodic heartbeat events, or alarms, to nodes within a system. It is assumed there is a single application within the network, such as a CCSDS SOIS time access service, providing time messages. There may be more than one application within the network providing event messages. The mapping of which nodes receive time and event messages is implementation specific, but should use lookup tables provided to the Synchronization Service when possible, so applications don’t have to know the specific details. Time is typically distributed to all nodes in the system. Event messages can be directed to specific nodes or groups of nodes.

Applications communicate to the Synchronization Service through an interface described in the CCSDS SOIS subnetwork synchronization service standard. The Synchronization Service is responsible for translating and routing data between the applications and a variety of protocols and/or data links. Routing directly to a data link would be appropriate when the data link supports the protocol directly such as issuing time codes over a SpaceWire data link. The primitive interfaces within the CCSDS SOIS synchronization service standard are written generically enough that JAS-based systems should be able to implement them as is. Note that indication primitives may be sent unsolicited, without a request, by applications within the network. All synchronization messages are typically sent with a best-effort protocol and their delivery is not guaranteed. There should be a single application that receives time and event messages at each node and ensures they get distributed to applications on that node. For example, each node in a network may have a time service that receives global time messages from a single source within the network. The time service would make the updated time available to all applications within that node. The exact method for updating applications is implementation specific but could use a firmware or software based approach.

The Synchronization Service routes requests to the appropriate protocol using either a provided application identifier or using a fixed approach, in the case of time requests. For time requests, it is assumed there will be one data link used to distribute time within the system and therefore, applications won’t need the ability to select more than one. This link would be identified within a lookup table used by the Synchronization Service. For event requests, applications shall have unique identifiers that are specific to the data link they are using. Lookup tables are used to manage this information and are provided at each level of the communication stack. The protocols are responsible for packaging the data and handling the communication with the remote node.

The protocols send the data to their respective data link interfaces for communication across the network. Note that priority and resource reservation are not specified as parameters for the Synchronization Service. These would assume to be fixed and provided directly to the Synchronization Service through lookup tables.

Implementation Approach

The following diagram describes the implementation approach for the JAS Synchronization Service and shows how it maps to the CCSDS SOIS synchronization service standard. It shows the communication service layers from applications to data links and describes the information provided at each layer and how it is used. At each service layer, information is provided through lookup tables or argument parameters are used to route the data through the communications stack. The left hand side of the diagram, the transmit side, describes the information used going down the stack and the right hand side, the receive side, describes the information used going up the stack. Request and indication primitives can go up or down the stack as described in the CCSDS SOIS synchronization service standard.

Lookup tables are stored in configuration data files and provide much of the routing information that is needed. This is referred to as Management Information Base (MIB) within the CCSDS SOIS standards. Using a MIB reduces the need to hard code the data into applications making them more reusable. MIB data is typically stored in nonvolatile memory separate from applications and read in upon startup. The details are implementation specific.

It should be noted that there is at most one synchronization service for each processing node in a JAS system. This eliminates the need for any routing information between the data link protocols and the synchronization service when passing data up the communications stack. It should also be noted that the synchronization service has no responsibility to maintain outstanding time and event requests to ensure they completed successfully.

Application identifiers are used to identify specific applications, typically time services within nodes, that either request or broadcast time and event messages. These identifiers are used to route specific messages within a system when necessary. In the case of multicasting or broadcasting, identifiers can represent a set of destinations.

Event identifiers are used to track a specific type of event and are passed on to receiving applications to assist in the final processing of the event.

Time or event data is based on the type of message being sent. Refer to the definition of each primitive to determine the exact information.

QoS attributes relate directly to the channel and priority. Again, these are not specified by the applications but, if used, are fixed within a system. They are provided to the Synchronization Service directly through lookup tables.

Lookup tables are used by the services to pass data between the layers of the communication stack. The use of these lookup tables is specific for each data link. For example, SRIO may encapsulate the protocol and data link functions within a single interface, while they may be separate and distinct functions for SpaceWire. The mechanism for passing data between the layers is implementation specific but it is expected that the destination application identifiers will be used as indexes into the lookup tables, when necessary, to determine how data ultimately gets transmitted on the data link. On the transmit side, the protocol lookup table and data link lookup table will be indexed by the destination application identifier or will be fixed. On the receive side, the protocol lookup table is indexed by a protocol identifier. This is part of the data link packet, assuming the data link supports more than one protocol. The application lookup table is also indexed by the destination application identifier.

Error Handling

A variety of errors may exist throughout the communication process. Errors should be handled at the lowest level of the communication stack as possible. For example, hardware errors, such as resetting a data link, should be handled at the data link level. The CCSDS SOIS synchronization service standard doesn’t provide any primitives to provide feedback to applications in the event of errors associated with failures to complete task.