[Top] | [Previous] | [Next]

3. Architecture Development Process

Figure 2 depicts the process by which this architecture was developed.

The first step in developing this architecture was identification of requirements that drive technology, workload balancing, and network topology. The SSCS FRD was used by functional area teams to identify requirements that may be architectural drivers. In addition, the teams identified processes, such as orbit determination, that may require significant computer power or disk storage. Once the drivers were identified, benchmark tests were devised and executed where possible. Otherwise, paper analyses were performed with an appropriate level of conservatism.

Next, the results of an object-oriented analysis of the SSCS FRD were applied to develop Data Flow Diagrams (DFDs) for each functional area. These DFDs contain storage, bandwidth, and compute power needs where possible.

This information was then combined with evaluations of the state of technology to devise candidate architectures that provided the needed flexibility and expandability.

The resulting architecture options consist of DFDs, interface definitions, performance analysis documentation, and a proposed network topology that can be scaled to meet the needs of individual programs. In addition, these architecture options can be tailored as the SSCS employment concept evolves.

Figure 2. Reference architecture development process.

This reference architecture will be applied as a baseline for evaluating the DCCS architecture. Differences between the two concepts can be evaluated to identify possible improvements in DCCS. This work will be fed into the ECP applied to DCCS to form the core TT&C system. Cost estimates and trade-offs can be developed to evaluate employment options. In addition, the natural functional decomposition allows SMC SPOs to analyze both core and mission-unique functions to determine what is needed to complete the development of the various integrated mission ground systems.

Ideally, a reference architecture is free of implementation details to allow it to be applied as widely as possible, but in order to achieve the desired level of definition, certain assumptions were made regarding technology. The very concept of a distributed architecture requires that certain technologies be available.

The software architecture relies on the existence of message passing software (middleware) that provides the desired functional segregation. This assumption is evident in Figure 4 of Section 4.1, where the "distribution services" layer represents the middleware and is the exclusive mechanism for passing data between applications. This concept is very important for achieving flexibility with respect to replacing or upgrading an application or service such as the Database Management System (DBMS) or Decision Support System (DSS). This flexibility is particularly important when dealing with Commercial-off-the-Shelf (COTS) software.

Furthermore, a number of database issues need not be discussed here because DBMS products are available that provide automatic replication of data. Similarly, the placement of data stores on the network is not an issue because network management software has matured to the point where, except for certain network capacity issues, placement of data on the network is transparent to applications.

The hardware and network architecture are also affected by the available technology. Allocation of functions between workstations and servers depends on where the line is drawn between the desktop workstation class machine and the server class machine. As computer power increases, more functions can be accommodated on workstations. Another driver has been the emergence of switched hub and Asynchronous Transfer Mode (ATM) network technologies. Both technologies drive the network topology toward a hubbed approach offering network capacity tailorable to the needs of the TT&C system. The availability of fault-tolerant network components alleviates the need to worry about fault tolerance in this architecture. Finally, availability of specialized security hardware and software allows direct connectivity between architecture components operating at different security levels. Additional discussion of technology is provided in Section 6.