AME - Syteem Design

The Advanced Mission Executive (AME) combines a Client/Server system design with communications protocols to provide a comprehensive processing scenario that supports all software control and data exchanges, especially among multiple, distributed mission operations and data processing sites.

Note in the system diagram above that the Server provides all of the AME's network communications to the Client. Service Module descriptions as well as their configuration parameters are sent from the Server to the Client, which, in turn, sends configuration parameters to the Server for application to the Service.

In order to establish a Service, the Client provides all of its required configuration parameters along with a Processing Slot identifier to determine in which slot the process will execute.

Each AME Server stores available Service Modules in a central repository. This repository, called the Service Module Library, contains all the processes with which a local or remote user can select from to configure the AME.

A Processing Slot may contain a collection of routines and/or protocols that move data from an input source, to a process, and then to one of several output destinations.

As seen below, the AME passes two streams of data from Slot to Slot and from Server to Server. One data stream is binary, while the other is a Meta data stream appended to the binary stream. XML-based “tags” are passed along from upstream processes.

The AME communicates via several layers of protocols. First, a light MissionSpace network layer lies on top of a standard TCP layer. On top of these layers lies an additional layer of simplified XML strings. The AME utilizes the XML strings to pass control and status information. All other data is in binary format and is passed directly via MissionSpace's network layer.

The AME's TCP layer is a standard Internet TCP layer. The decision to use TCP as the AME's primary network protocol was based on TCP's capability to automatically retransmit damaged or missing packets. This capability is especially valuable for real-time, mission-critical applications and thus was incorporated into the AME infrastructure so that data can be sent over regular TCP/IP networks.

On top of the TCP layer lies MissionSpace's Network Protocol (MNP). This lightweight, robust network transfer protocol was developed to provide users with a highly reliable capability to transmit multiple, simultaneous streams of data.

The XML-formatted data is not really a network layer. It consists of XML-formatted strings which represent keyword/value pairs of data. These appended values provide operators with real-time information about their data stream, without having to first process the data.

Service Modules are placed into these slots to achieve the desired level of processing. By allowing users to configure Processing Slots with multiple data acquisition, processing, and output services, the AME is capable of processing very complex data streams.

For example, Processing Slot 0 is executed first, followed by Slot 1, then Slot 2, etc. Outputs may be fed into the next processing slot or sent to any of the outputs provided in the Service Module Library. It is through this process that a “string”, or multiple strings, of Service Modues can be "plugged" into the AME Server.

This high degree of modularity allows the AME to support an innumerable variety of processing configurations, simply by changing the configuration of the Service Modules.

Each Service Module in the AME's processing string generates some Meta data (e.g. Ground Receive Time, Reed-Solomon errors, etc.). The AME then compiles the Meta data from the processing string to enable operators to see at a glance what occurred to the data as it was processed. The quantity of Meta data produced by each Service Module can also be tailored according to user requirements. Thus, the Meta data generated by the AME provides high levels of transparency as to the performance and status of all processes on the AME network.