Figure 3 illustrates the system domain of AFSPC programs that must be supported by this architecture. It also shows the relationship between the ground system processes and the data needed by these processes.
In the center circle are System Services including (1) the Operating System (O/S); (2) data management, including database management, file archiving, and configuration management services; (3) middleware, including message passing, timing, security services, and support for all platforms across the Local Area Network (LAN); (4) the Human Computer Interface (HCI); and (5) a DSS consisting of stored procedures and an expert system inference engine.
The next layer consists of SSCS TT&C applications used by all ground systems, mission-unique applications, and support applications. SSCS TT&C Applications are the focus of this architecture and include:
Mission Planning: which includes (1) general mission/activity timeline generation, room activity scheduling and scheduling of network resources via the Resource Management Segment (RMS), (2) basic orbit/attitude maneuver planning, and (3) preparation of Satellite Support Plans.
Telemetry: which includes (1) synchronization and extraction of raw measurands, (2) formation of derived measurands, Engineering Unit (EU) conversion/calibration, (3) Space Vehicle (SV) state monitoring (expert system), and (4) alarm notification and operator interface.
Commanding: which includes (1) execution of command plan, (2) constraint checking, (3) command transmission, (4) command verification, and (5) anomaly notification and user interface.
Orbit: which includes (1) pointing Remote Ground Facility (RGF) antennas, (2) processing tracking and crosslink data, (3) determining orbit, (4) generation of orbit ephemeris and events, and (5) detection of Radio Frequency Interference (RFI) conflicts.
Attitude: which includes (1) computing sensor coverage, (2) processing raw attitude data, (3) determining attitude, and (4) generation of attitude ephemeris and events.
Support applications include resource management and simulation. Resource management involves management of SCN network resources and the mission operation center, including: controlling and monitoring the RGFs during contacts, in-room system and data archive management, and resource performance evaluation. These functions, while very important, were not considered performance drivers and are implementation-oriented, so, except for ground system status processing, they were not included in the detailed software architecture.
The mission-unique applications include payload mission planning, specialized maneuver planning, all mission data processing and analysis, and any specialized command generation.
The outer ring contains mission-specific information sources such as Databases(DBs), Knowledge Bases (KBs), and any specialized code. Collectively we will refer to these as an Information Base (IB). Figure 3 depicts the relationship between the IBs and TT&C or mission-unique applications. Clearly, at the detailed level the relationship is not necessarily as clean as depicted, but at a very high level, one can see that certain information from each mission area will be required by both the TT&C and mission-unique applications. The support information is needed by the simulation and resource management functions as shown.
Figure 4 shows an alternate view of the overall software architecture. This view indicates how the system components fit together. It also identifies the scope of the SSCS (i.e., what is internal or external to SSCS) and classifies system components as either applications or services.
The need for mission-specific IBs is indicated by the boxes attached to the top of each application. These IBs include databases, knowledge bases, and conversion code. They may be populated by the satellite contractor, operations center personnel, or the applications themselves.
The distribution services layer represents a component of what is called middleware. This layer ensures that data is passed properly from one application to another. This hand-off may be done across the network when necessary and may involve secondary storage and certain security considerations. Hence, the middleware may employ other system services such as the DBMS, the O/S, security, file, configuration management, timing, and network services.
Applications communicate with other applications and with system services through agreed-upon APIs. APIs specify the syntax and semantics for communication. API implementations may involve certain object-oriented technologies or language bindings, depending on the languages employed in the applications and conventions of the middleware. From a data content perspective, it is hoped that these interfaces can be generically defined and provide information encapsulation to increase interoperability and overall supportability. For each SSCS application, this reference architecture attempts to define these generic APIs with respect to the other applications in SSCS.
Figure 5 shows the primary application-to-application interfaces for SSCS. These interfaces are only those internal to SSCS. A complete description of these interfaces can be found in the TT&C API definitions in Appendix F.