Keywords

1 Introduction

Space TT&C Network is a special network by which orbited spacecrafts are tracked, measured and controlled [1]. With the expanse of the space enterprise, space TT&C center and the space application center need highly cooperate with each other to complete the complex tasks. Space TT&C center is the main control node of the TT&C network, in which TT&C software plays a key role to automate and intellectualize the system. Software support framework provides a deploying and running environment for the function components, and is foundation of space TT&C center software. With increase of mission requirements, TT&C center software’s architecture is making the transit to the network one. All in all, software support framework is now facing with new challenge.

In the past 10 years, TT&C center software architecture went through three phases. The first one is vertical architecture, including many representations, such as independent software, module function and client/server. The second one is hierarchical architecture, including many representations, such as client/server, three-layers, N-layers and distributed structure. The Last one is grid architecture, including many representations, such as distributed structure, reused component and SOA. As Shown in Fig. 48.1.

Fig. 48.1
figure 1

Evolvement of TT&C center software architecture

Full size image

By Far, hierarchical architecture is mainstream and popular for TT&C center software. With increase of requirements, some of TT&C center software is adopting grid architecture.

Component-Based Development (CBD) [2] builds software system by combining the developed components, which can reduce development cost, and improve reuse rate of developed components [3].The developed components are the base units of combination, describe the offered service by interface, define the demand for environment, and can be independently deployed by a third party.

The support framework provides the running and deployable environment for components [4], and is fundamental of the component-based distributed development. During the running state, support framework builds and manages instances of components, allocates system resources, maintains intercommunications of components, and transparently heads off request of the outer system. As support framework has achieved common design and implementation [5], developers only need to focus on certain parts, without considering common parts.

Product line engineering is a software engineering technology which develops special domain product series by using common kernel assets [6]. It involves three phase: domain analysis, domain design and domain completion. Domain analysis is different with common requirement analysis, adds description for commonness and variability of the special domain, and guides the manufacture of reused software assets. Product line architecture (PLA) [7] is a product of domain design. By supporting the domain requirement and implementing the common requirement, PLA realizes systematic reuse. Research on PLA can promote structural reuse of support framework, and improve productivity and quality.

2 Domain Analysis of Support Framework

2.1 Component Sort

Considering universal principle of function definition in the field of TT&C, TT&C system falls into two categories: task function component and system manage component. Task function component satisfies requirements of special tasks, including compute component, satellite control component, equipment control component, customer data relay component and customer data parse component. System manage component satisfies requirements of system support framework, including task layout component, task schedule component and status surveillance component. The following lists are the details of each component function:

  1. 1.

    Compute component. It receives and deals with the trajectory data, and computes the orbits and the control coefficients of satellites.

  2. 2.

    Satellite control component. It implements the TT&C operations of the satellites.

  3. 3.

    Equipment control component. It remotely monitors and controls of the ground stations.

  4. 4.

    Customer data relay component. It exchanges customer data customer data between the ground stations and the customer centers.

  5. 5.

    Customer data parse component. It deals with data of satellites.

  6. 6.

    Task layout component. It allocates the resources of Space TT&C Network, establishes and manages the task layout.

  7. 7.

    Task schedule component. According to the layout or human instruction, it schedules the all function components of the software system.

  8. 8.

    Status surveillance component. It shows the task progress and system status.

Relation among aforementioned components is described in Fig. 48.2.

Fig. 48.2
figure 2

Relation among function components

Full size image

Liu Guo-Liang [8] details the analysis framework of the component model. The author aims at the software system of space TT&C.

2.2 Component Common Requirement Analysis

The common requirements of component support framework include component deployment, component running, and component maintenance. There are five actors associated with component support framework, which are deployer, manager, operator, resources, and component instance. By analyzing relation among actors and the support framework, domain case model is educed as shown in Fig. 48.3.

Fig. 48.3
figure 3

Domain case model

Full size image

By decomposing cases into a series of independent acts, it is achieved that the function requirements refine. In outer view, each act is indivisible. For example, the task cooperation case represents components’ cooperates in task. It includes scheduling synchronization, data synchronization, and operation synchronization.

2.3 Component Variant Requirement Analysis

There are five sorts of variant requirements, which are symbol configuration, script template, network configuration, display configuration, and special algorithm. As shown in Table 48.1.

Table 48.1 Analysis of component variant requirement
Full size table

3 Product Line Architecture for TT&C Software Support Framework

3.1 Development Structure

The development structure includes two parts. See Fig. 48.4.

Fig. 48.4
figure 4

Development structure

Full size image
  1. 1.

    Basic software layer. It contains support framework and component set. It mainly solves the problem of the system common function design, and builds basic platform for task expanse. The edition of basic software is independent with task.

  2. 2.

    Task software layer. Aiming at the special requirements of tasks, it is developed based on basic software layer. It mainly contains various configuration files and some programs for special algorithm. Each task software is independent.

Under this development structure, maintenance of basic software and task software can be simultaneously implemented, and different editions of softwares are managed and upgraded respectively.

3.2 Layer Structure

The analysis of variant requirement is the base of the component reuse. There are four layers for the component reuse. See Fig. 48.5.

Fig. 48.5
figure 5

Layer structure

Full size image
  1. 1.

    Task Procedure. A series of acts make up of one task procedure. Each act matches one component.

  2. 2.

    Component support framework. It provides the running environment for component.

  3. 3.

    Component module. It is component set, and in.

  4. 4.

    Component configuration set. It includes series of configuration files.

Every Task Procedure uses the command interface to send instruction to the component support framework. The component support framework parses the instruction and uses the module loading interface to initialize component. The component module uses the file configuring interface to get task arguments, so as to configure itself at initialization time.

3.3 Running Structure

Based on support framework, task software implements the unity among development, deployment, and maintenance. However, in running structure, each task software is independent. According to the task requirements, the editions of configuration files are finished. By configuration files, we initialize the instances of the requisite components. See Fig. 48.6.

Fig. 48.6
figure 6

Running structure

Full size image

In the system runtime, there are three kinds of initialization modes for all component instances. Firstly, it’s task layout component which initializes only one instance in the whole system. This instance provides service for all customers and confirms the exclusive result of resource layout. Secondly, they’re task schedule component and status surveillance component, which initialize one instance for each task. They build the independent platform for special task to be monitored. At last, all other components are initialized on demand. Every instance is independently running and focus on single function.

In a word, ultimate purposes are achieved, including consistent layout, centralized-control based on task and distributed running of component.

4 Software Product

By adding a new satellite to space TT&C Network, we validate the effect of PLATSSF. The task requirements of the satellite have two ways. The one is providing management of satellite platform from orbiting, which includes three stages: going into orbit, on-orbit, seceding orbit. The other one is providing service of data relay.

4.1 Task Analysis

4.1.1 Management of Satellite Platform

The task requirements include position keep, attitude control, power management, and orbit calculation etc. We take more complex position keep as case and analyze the task requirements. See Table 48.2.

Table 48.2 TT&C task analysis
Full size table

4.1.2 Service of Data Relay

Through operating satellite and station equipment, we build a data link and implement application data exchange between customer and satellite. See Table 48.3.

Table 48.3 Data relay task analysis
Full size table

4.2 Maintenance Requirement and Product Format

According to the function of all components, we divide task requirements into sixteen parts, get the maintenance requirement of the software, and design the product modes for every function. See Table 48.4.

Table 48.4 Maintenance requirement and product format
Full size table

Through combining the above software products, we get the special software product line of the TT&C center, and make the reuse rate of the software greatly improved. See Table 48.5.

Table 48.5 Summarization of software reuse
Full size table

5 Conclusion

According to theories of software product line and support framework, software requirement of the TT&C domain is analyzed, including component sort, common requirement and variant requirement. Product line architecture is designed for TT&C Software support framework. From three views of development structure, layer structure, and running structure, Systematic structure is described in detail to achieve a software system based on the support framework. Aiming at adding a new satellite into TT&C network, task requirements are analyzed, maintenance requirement and product format of software system are demonstrated, and the reuse rate of software systems is simply summarized.