[Top] | [Previous] | [Next]

B-6.4 Telemetry Software Architecture

The Telemetry Contact software architecture was determined based on telemetry requirements as well as assumptions concerning technology projections and limitations. A high level notional view of the contact software architecture is depicted in Figure B-10.

Figure B-10. Telemetry software architecture.

This architecture is based on the assumption of a distributed (client/server or object-oriented) architecture and a distribution service (middleware) layer that allows components to communicate through the passing of messages. Figure B-10 shows the Telemetry application components (Sync, Extract, Convert, Monitor, and Display) across the top. It shows the system service components (OS, DSS, DBMS, File, Security, etc.) along the bottom. Each of these components is connected to the distribution services layer via an API, which defines the set of messages each component can send and receive, and the actions associated with them. As a simple example, consider the situation of a telemetry alarm being sent to the SV operator. The component Convert would generate a message that would be output from its API, addressed to the Display application. The Display application would receive the message via its API and ultimately display the message on the screen to the operator.

In an ideal world, each of the Telemetry functional components depicted in Figure B-10 would be vendor independent and easily substituted. However, in practice we would expect to see certain components grouped together into higher level modules. Figure B-11 illustrates a common grouping seen in several COTS telemetry products.

Figure B-11. Telemetry software architecture implementation.

The Extract and Convert functions are grouped to provide a "Telemetry Engine". This component would typically reside on a front-end, server or workstation. Real world examples of this component would include the Loral System 500 Application module and the Veda ITAS-30 Omega application. The Sync component would typically stand alone and would serve as the PCM telemetry interface on the TFE. The Monitor and Display components may be combined or stand alone. An example of a combined component in a COTS application is the G2 application from Gensym Corporation, which provides the inference engine for executing Monitor knowledge bases and a graphics application for display of satellite diagrams. An example of separate components would be a rule base built in the NASA Clips inference engine and a display built with the DataViews GUI builder or with the Loral 550 DataScope application.