American Institute of Aeronautics and Astronautics 092407

1

Using Design Patterns, Components and Metadata to design

the Command and Monitoring Frameworks of the INPE´s

Satellite Control System

Paulo E. Cardoso, Joaquim P. Barreto, Luciana S. Cardoso and Leandro T. Hoffmann

National Institute for Space Research – INPE, Sao Jose dos Campos, SP, 12227-010, Brazil

The Ground System Development Division at National Institute for Space Research

(INPE) is developing the SATellite Control System (SATCS) which shall be easily

configurable for different satellites. This system will provide a common infra structure for

satellite control that will be customized to comply with the operational requirements of each

INPE´s space mission. Considering the purpose of reaching a high degree of system

reutilization and lowering its development costs, the concepts of frameworks, design

patterns, component-based development and metadata are being widely used in the SATCS

design. This paper aims to present the Commanding and Monitoring object oriented

frameworks. The design of these frameworks took into account the common and variable

requirements that can occur among different missions in order to make it easier to create the

monitoring & control applications required for each specific mission. Using design patterns

brings flexibility to change the code to comply with new requirements, since the code is

designed to accept changes, thus saving time and reducing future developments costs.

Breaking down the frameworks in modules makes it easier to change a specific part of the

problem domains because the change would be concentrated in a specific module. By using

metadata is possible to reduce drastically, or, in some cases, even to eliminate the need to

adapt the application codes to comply with the requirements of new satellites. A specific

component was developed to hide the metadata complexity and provide to the SATCS

subsystems a simpler interface for accessing the real data they need. This component can be

used not only by the mentioned frameworks but also by others SATCS subsystems, satellite

simulators and by other systems whose designs may take advantage from a component that

is able to move their data structure definition from code to a database. However, by

documenting the knowledge through metadata creates a complexity in the database that

makes the data representation very hard to understand. For overcoming this difficulty, a

database editing tool needs to be designed with different views: meta-information input for

developers and real information input for system operators.

I. Introduction

HE Ground System Development Division (DSS) team is developing the SATellite Control System (SATCS),

which is intended to be a product line to provide a common ground software infrastructure for satellite control.

This infrastructure is composed of several software elements, such as: components, class library, frameworks, and

data bases which will be customized to comply with the operation requirements of each INPE’s space mission1.

Further, the project of SATCS proposes a logical architecture template to be used as a standard in the design of its

subsystems.

The Commanding and Monitoring frameworks were created according to this architecture. They are a set of

integrated classes that provides a pre-defined base infrastructure to support the development of applications for the

remote control and monitoring domains. Those domains include control and monitoring functions of both satellites

and ground stations.

These frameworks allow creating applications that could achieve highly software reuse and a low cost on

development. To reach these targets, the following concepts have been widely used in the design: design-patterns2,

component-base development3, and metadata

4.

This paper presents, in section II, the generic logical architecture defined in SATCS project for the development

of its subsystems. This logical architecture is layer based and makes use of a Support component, which provides

T

SpaceOps 2008 Conference (Hosted and organized by ESA and EUMETSAT in association with AIAA) AIAA 2008-3591

Copyright © 2008 by National Institute for Space Research (Brazil). Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

American Institute of Aeronautics and Astronautics 092407

2

basic services to all layers. Taking into account this architecture, the third section shows the logical architecture of

Commanding and Monitoring frameworks and also the design solutions adopted to achieve a high level on the

reusability of these structures. Both Commanding and Monitoring frameworks make use of a Data Stream module,

part of the Support component, which avoids the necessity of implementing a specific routine to code and decode

each specific command or monitoring data message structure. The section IV describes the Data Stream module,

highlighting how its objects can be created from data descriptions stored in the Operation data base (metadata) and

the use of design patterns to make easy to add code to comply with new requirements. However, the task of

documenting the real data knowledge, which is the data related to the final user view, becomes more difficult and

more complex when one works with metadata. The section V shows the solution adopted by the data base edition

tools to permit dealing with specific problem domains. The conclusion of this work is presented in section VI.

II. SATCS Generic Logical Architecture

The SATCS system is composed by several subsystems that together provide a complete set of services for

controlling a satellite from ground. These subsystems can be customized to comply with the operation requirements

of each INPE space mission. On the purpose of increasing the system reusability and decreasing the development

costs, a software architectural template was defined to guide the design of these subsystems.

As shown in Figure 1, the generic logical architectural template establishes that the functions of each subsystem

must be organized in

four layers: UserView,

Subsystem,

Archiving&Retrieving

Services and

Persistence. Besides

that, the template

includes an

independent

component that is

responsible for

providing support

services for the first

three layers.

The Persistence

layer includes two

databases: Operation

data (mission and

software parameters)

and mission Historic

data. Metadata was

used in the design of the Operation database to increase the flexibility for complying with the specific data

structures requirements of each mission.

The Archiving&Retrieving Services layer makes possible to design the subsystem independently of the

implementation of the Persistence layer databases, by providing services for storing data and retrieving data from

the Operation and Historic databases.

The functions related to the role of each subsystem, as part of the SATCS system, are included in the Subsystem

layer. Taking advantage of the experience gained in earlier ground control systems, another logical architecture

template was defined to guide the design of this layer. This template establishes, whenever it is applicable, the

breakdown of the problem domain functions in at most three parts: (i) Communication functions, which includes

modules for implementing the interfaces to other SATCS subsystems or external entities; (ii) Problem Domain, that

includes one or more modules for complying with the subsystem core functions and; (iii) Playback, which includes

functions for processing historic data. The Problem Domain interfaces must be able to receive and process data

independently of its source: real-time communication interfaces or data retrieved from the Historic database.

The UserView layer includes only functions related to the interaction with the subsystem users: presentation of

data managed by the Subsystem layer modules and activation, by the user, of services provided by these modules.

The design of this layer produces one or more modules for complying with the subsystem user interface

requirements and most of the time each module corresponds to one executable application with a graphical user

Figure 1. Generic Logical Architecture Template.

American Institute of Aeronautics and Astronautics 092407

3

interface. This layer also includes special applications for accessing the two databases of the Persistence layer:

visualization of raw data stored in the Historic database, external data transfer to/from the Historic database and

tools for editing the Operation database.

The Support Component isolates some operating system implementation details in the development of the

Layers. Some of its features include:

• Communication: supports synchronous and asynchronous communication services over TCP/IP

protocols, using sockets;

• Configuration Parameter: retrieves user configuration parameters stored in the Operation database;

• Event Message: stores log messages generated during the execution of the SATCS applications;

• Event Visual: provides services to visualize log messages generated by SATCS applications;

• File Manager: transfers and deletes files over LAN or Internet, using FTP, SSH or NetBIOS protocols;

• Special Types: contains classes to handle special types of data (for instance: date-time, and arrays of

bits);

• Timer: schedules services to be executed in a predefined time;

• User Interface: implements general user interface services (for instance: date-time input masks) and;

• Data-stream: provides data message coding and decoding functions by using metadata information

stored in the Operation database.

Besides the two logical architecture templates, a set of design solutions were adopted in the SATCS project to

make it easier and efficient to reconfigure the software: (i) use of design patterns; (ii) use of metadata for modeling

data structures through the Operation database; (iii) definition of standards to describe the interfaces among modules

and subsystems; (iv) creation of independent components as much as possible; (v) designing the modules as class

frameworks to make it easier to modify the design and code for complying with special requirements of the missions

and; (vi) the subsystem design must allow to create different software products by selecting a subset of the

subsystem modules.

III. Commanding and Monitoring Frameworks

This section presents the Commanding and Monitoring frameworks whose developments were based on the

architectural templates and design solutions described in the previous section. The operation requirements associated

to the telemetry, telecommand and ground station monitoring & control functions are fulfilled through an adequate

configuration of these frameworks.

The Commanding framework covers functions of preparing, validating, sending, verifying and logging control

messages (commands). This applies to any commandable entity like satellite (telecommand) and ground station

(remote command) for which command messages can be defined.

The Monitoring framework covers all monitoring functions in which all data, regardless of the source (telemetry

or remote monitoring), can be extracted, calibrated, subjected to a range monitoring checks, archive in Historic

database, and displayed. It is also able to play back and display the data stored in the Historic database.

Figure 2 presents the logical architecture of the two frameworks, including the modules that were defined for the

Subsystem and UserView layers. Rectangles with solid lines represent the logical modules of the frameworks.

Through the combination of these two frameworks, it is possible to create applications for controlling a remote

entity in the manual, automatic or supervised mode. Requests for connection to a ground station, transmission of

commands and others can be performed manually by an operator, through the application user interfaces which are

represented in the Figure 2 by the TXUserInterface and VisParam modules, or automatically by the CMDAutComm

and MONAutComm modules, that process requests sent by the SATCS Scheduling subsystem. In the supervised

mode a request sent by the Scheduling subsystem needs to be confirmed by an operator before its associated

function is executed.

Whatever is the operation mode of the Commanding framework, all requests for transmitting commands are

inserted in a queue of commands to be transmitted. The TXController module is responsible for controlling this

queue and notifying the user interface whenever there is a change in the queue or in the execution state of a

command. Depending on the operation mode, the commands are transmitted manually by an operator or

automatically. The Transmission module controls the command transmission, by checking the range values of

possible monitoring parameters associated to each command (pre and post verification), and notifies the Monitoring

framework, due to command execution, about changes in the expected state of a remote entity. The communication

between Command framework and ground stations are performed by the CMDGSComm module.

American Institute of Aeronautics and Astronautics 092407

4

On the other hand, monitoring packets sent by a satellite (telemetry), through a ground station, or sent directly by

a ground station (ground station remote monitoring) are received by the MONGSComm module. This module allows

connections to one or more ground stations, storing the received packets in the Historic database and broadcasting

them to several computers. Depending on the computer where it is installed, the MONGSComm module also plays

the role of a client that receives the packets that were broadcasted. The packets are processed by the ProcParam

module, whose functions includes: obtaining all monitoring parameter values and checking these values using

monitoring laws. The ProcParam module also makes available these values and lists of parameters with values out

of normal ranges to the VisParam module. Besides presenting the current values and processing states of the

monitoring parameters, the VisParam module is also in charge of presenting the command queue to the user. Other

feature of this module is that it can be configured to present both real time and playback data. The only difference is

that in the playback mode the ProcParam module processes packets retrieved from the Historic database, through

the Historic module services, and not real time packets received through the MONGSComm module. Other SATCS

subsystems can interface the Monitoring framework through the ProcParamServer module to receive parameters

values extracted from Historic data. The ProcParamServer module is implemented as a server that receives requests

from the SATCS subsystems and uses the ProcParam and Historic modules to provide the data these subsystems

ask for.

All communication interfaces between the Commanding and Monitoring frameworks are placed in the

MONComm and CMDComm modules. The Commanding framework: (i) sends information about expected change

in the state of a remote entity, due to command executions, so that the Monitoring framework can reconfigure the

monitoring laws of parameters associated to these commands; (ii) receives parameter current values and uses them

to check the pre and post verification rules associated to the transmission and execution of a command and; (iii)

sends information about the command queue and its updates to allow the user to monitor it.

The Commands and EndtoEndComm modules were designed as independent components that can be used by

any subsystem or system that needs to code/decode the application data of a command and to pack/unpack the

protocol data layers that can exist to allow the communication with remote entities (ground-board protocol and/or

ground node to ground node protocol). These components can be used in the design of a satellite simulator and also

in software applications for preparing special commands of each mission.

Aiming to provide flexibility to adapt the software to comply with new requirements, the design pattern

technique was widely used in the design of the framework classes. Whenever there is a synchronous communication

among modules, the design of those interfaces makes use of the Facade pattern. The Observer pattern is used when

one or more modules need to be notified that an event occurred in another module. The Factory pattern is used to

make it easier to select and create objects associated to functions that can have small changes to comply with

specific requirements of a mission. The Builder pattern is used to create and connect the framework objects by using

one or more Factory objects to create these objects. The Singleton pattern is used mainly together with the Facade

pattern since this one usually represents single objects.

Figure 2. Commanding and Monitoring Framewoks Logical Architecture.

American Institute of Aeronautics and Astronautics 092407

5

The impact of eventual changes is minimized by splitting the frameworks in modules with very specific and

cohesive functions. For instance, the ground station communication modules (CMDGSComm and MONGSComm)

are designed to make easy the compliance with the requirements of a new kind of ground station. The Figure 3

presents the classes of the CMDGSComm module, where to handle the communication protocol of a NNN ground

station is necessary just to create the CCMDNNNGroundSation class and add code in the CCMDGSFactory class to

create its objects. The CCMDNNNGroundSation is a specialization of a generic ground station which is represented

by the class CCMDGroundStation. The inclusion of the new class does not affect the CMDIntGSComm class, which

is the interface of the communication module to the other modules.

The design of the Commands,

EndtoEndComm, CMDGSComm,

MONGSComm and ProcParam

modules makes use of the Data

Stream module of the Support

component to minimize the need of

changing the code for complying with

requirements of mission specific

monitoring and command data

structures. For instance, to code

telecommands for a specific satellite

or remote commands for a ground

station, the Commands module needs

just of an application identification

which was configured in the

Operation database. Using this

identification, the services of the

Data Stream module get, from the

Operation database, the description

of all command data structures and

theirs parameters. Thus it is possible to define and use, without changing the code, communication messages

exchanged with different kinds of ground stations and monitoring/command packets for different satellites or ground

stations. The advantages of the Data Stream module, as well as its features to make easy to add code to comply with

very specific requirements, are described with more details in the section IV.

The framework customization allows creating software products for different mission phases. During the

operation phase all framework modules will be assembled to build application programs for monitoring and

controlling the satellite as well as the ground stations. In the AIT phase, some modules of these frameworks will be

used inside EGSE to control and to monitor the satellite during testing, thus eliminating the need to develop two

nearly identical systems, one for AIT and another for ground segment operations. In addition to the in-flight

operations systems and AIT, framework modules can also be used in the Satellite Simulator project (SIMS) and for

testing the on-board computer during its development. Some frameworks modules can be used in SIMS to decode

the telecommands received from the Satellite Control Center (SCC), and code/decode data structures of the

protocols used for communication between the SCC and the ground station simulator. The onboard computer

development and testing team may customize the frameworks to monitor and control the satellite on-board

equipment during its testing phase by inserting new equipment data in the Operation database. This will replace

several tests programs, which currently are created for each piece of equipment, because the same on-board

computer test application can be used to test all the equipment.

IV. Data Stream Module

The implementation of the frameworks are strongly based on the Support Component. This component is a class

library that provides several services to isolate the problem domain from each specific service interface provided by

different operating systems, as described in Ref. 1. One of its elements is the Data Stream Module which provides

services for creating and accessing data structures in the memory. These data structures are created based on

description data stored in the Operation database. The services can be used to handle the command and monitoring

messages that are exchanged with a remote entity (satellite or ground station).

«Factory»

CCMDGSFactory

«Observer/Abstract»CCMDAbstractGSObserver

«Abstract»CCMDGroundStation

CCMDNNNGroundStation

CSPTTcpComm

CCMDGSComm

«Facade»

CCMDIntGSComm

m_objGSComm

m_objGsComm

m_objGroundStation

create

Figure 3. Class diagram of CMDGSComm Module.

American Institute of Aeronautics and Astronautics 092407

6

The use of this module starts by defining, in the Operation database, the fields of a particular data message.

These fields can represent message payloads or control values of a protocol. The description of the relationship

among these fields, as well their positions, allows representing the complete data message in the Operation database.

Once instanced into memory, the Data Stream’s functional schema is based on the pattern Composite to allow

data structures handling in execution time. Through this pattern it is possible to recursively define tree data

structures. For instance, in a protocol’s message, each element of tree models generically a message field. The

message fields can be atomic fields, representing valued parameters (leaf nodes of the tree), or be structures

composed of other structures or parameters (parent node). The representation of this tree structure is illustrated in

Figure 4 by a class diagram, where a parameter (class CSPTMetaParameter) and a structure (class

CSPTMetaStructure) are specializations of a generic field (class CSPTMetaField) and the structures can be

composed of other fields.

The service set provided by Data Stream module hides

all complexity behind the process of coding and decoding

data structures. These services also include methods for

setting and getting parameter values.

The use of Data Stream services brings great flexibility

in modeling applications which require manipulating

protocol’s messages in different formats. Additionally,

because it is a generic mechanism based on metadata the

whole source code of this module can be reused in each

new project, by only changing the structures defined in the

Operation database. Several requirements can be easily

met by just modifying, in the Operation database, the

attributes of message fields or their relationship. Hence, let

a particular hardware of a satellite family be responsible for coding and decoding messages of a communication

protocol. If replacing this hardware implies in changing the word format of messages, from big-endian to little-

endian, it is enough to alter the type attribute of the affected parameters. Thus, not even a single line of source code

would have to be rewritten.

On the other hand, if a new requirement needs a change, which is much more than a simple database

modification, it is feasible to incorporate new portions of source code into Data Stream module. This is possible,

because several kinds of design patterns were used in the module’s model in order to make it easier to specialize

new classes to comply with new requirements. Thus, the Strategy pattern was applied to model the different types of

parameters and provide a generic interface to set and get their raw value. Each specialized class, named binary

transfer function, implements a specific conversion process according to its type attribute. Currently, nine types of

these functions are defined: float (32 bits) little-endian or big-endian, unsigned or signed int (1 to 32 bits) little-

endian or big-endian, Hexa-decimal array (1 to 32 bits) little-endian or big-endian, and byte array. If a new

requirement leads to a specification of a new type, it implies only on the codification of a new class and the

inclusion of this class into the component library.

The Strategy pattern is applied also to build derived parameters. The values of these special parameters are

obtained based on an expression, also described in the Operation database, that takes into account the values of

other parameters. This feature is implemented by the Data Stream module through a set of classes that represent the

operators that can be used in the expression. Each class performs a specific arithmetic operation using values gotten

from other parameters. At present, 19 operators are available and the inclusion of a new operator just requires

creating a new class to implement it and add its object creation in the class which is responsible for creating the

operator objects.

Very specific formats of message fields, or still, the use of pieces of legacy software, can be included into the

Data Stream module through a Dynamic Linked Library (DLL). This feature is applied in the process of converting

parameter values from raw to engineering units. For complying with the most usual conversion requirements, there

are linear invertible transfer functions that can be customized in the database. However, if a mission defines a

special requirement which is not able to be met by linear transfer functions, then an API is provided and an external

implementation can be incorporated into the Data Stream runtime code.

Other features of the Data Stream module include the monitoring and labeling of parameters according values or

ranges of values previously defined in the Operation database. Presently, it is possible to monitor parameter values

using alert and warning zones described in the Operation database as value ranges, discrete values and discrete

values plus/minus value deltas. The implementation of a new class, which meets a new monitoring criteria, requires

CSPTMetaField

CSPTMetaParameter CSPTMetaStructure

Figura 4. Tree structure classes.

American Institute of Aeronautics and Astronautics 092407

7

only the modification of a Factory class to create its objects and the inclusion of a service to access the new

monitoring description in the Operation database.

Both Commanding and Monitoring frameworks make use of the Data Stream module, reducing significantly the

effort of implementing routines to coding and decoding messages. At the Commanding framework, the Data Stream

module is used as follows: (i) in the Commands module for coding/decoding the command’s inner structure; (ii) in

the EndToEndComm module to pack/unpack the layers associated to data messages of ground-board protocols or

ground station remote control protocols; (iii) in the CMDGSComm module to pack/unpack the layers of data

messages of ground-ground protocols. Yet, at the Monitoring framework, the ProcParam module is composed of

just a few interface classes, which make use of the Data Stream module’s services to decode monitoring data

packets, extract parameters values from these packets, convert theses values to engineering units and also monitor

them. The MONGSComm module also uses the Data Stream module to pack/unpack the data messages layers of

ground-ground protocols. Thus, the Data Stream module has been used for implementing several functions of both

frameworks requiring just the description of their data structures in the Operation database.

V. Metadata Edition

The Persistence layer of the SATCS logical architecture contains the Operation database which is responsible

for storing all parameters needed to configure software and mission data. The database tables are organized in three

categories: Metadata, Problem Domain and Support, as shown in Figure 5.

The Metadata category tables allow configuring data

structure in such a way that this information can be used

by SATCS subsystems through the Data Stream module

objects. Inside the Problem Domain category are the

tables created to store the information needs of a specific

problem domain. In general, this category has

relationships with the Metadata category to configure

specific data structures. Finally, the Support category

includes tables whose information are used by several

common services available in Support component

library, like client-server communication addresses,

descriptions of events that can occur in subsystems and configuration parameters that can be redefined by SATCS

users.

The User View layer (see Figure 1) includes editors for data insertion in all three categories of the Operation

database. These editors are responsible, together with the rules existing in the database manager, to assure the

integrity and consistency of the information in the database. They also provide a friendly interface to the users which

are in charge of inserting data. For the Support category only one editor is enough to access all the information,

since their data has the same meaning for any user. But in the Metadata category, the information meaning is

specific for each domain. Its tables, combined or not with the ones from the Problem Domain category, can be used

to represent data structures from different sources such as telemetry, telecommand and ground station protocol data

messages. Besides that, documenting the knowledge through metadata creates a complexity in the database that

makes the data representation very hard to understand. For overcoming this difficulty, the database editing tool

needs to be designed with two different views: SATCS-Developer view and Problem Domain view.

The SATCS-Developer view comprises an unrestricted access to the database. It is addressed to SATCS project

developers who, knowing the database structure, do not need a very sophisticated tool to insert data. This editing

tool view is responsible for maintaining data integrity. It also allows inserting information of any problem domain,

in the database, in a generic way. For instance, a telemetry message is represented generically in the database as a

group of information about data fields, where these fields can represent parameters or data structures to compose a

data structure associated with a telemetry message. The data messages of other domains are also represented in a

similar way.

The Problem Domain view is addressed to framework users that desire to customize it for a specific application

but do not need to know the database complexity to perform this customization. The editors available in this vision

will focus on the group of information related to each problem domain and not in the database structure. Therefore,

in this vision a telemetry message will no longer be seen as a group of information about data fields (SATCS-

Developer view) but as a group of monitoring parameters that will be part of the telemetry message header and

body. The editor will be responsible for guiding the whole process of a specific domain information edition and

Figure 5. Database data categories.

American Institute of Aeronautics and Astronautics 092407

8

linking database tables and relationships in a transparent way. This view will be designed to be used by two groups

of users: Application Developer and End User.

The Application Developer group is responsible for customizing the framework for a specific problem domain

and will use the editing tool to build in the database the fundamental data structures that are necessary for

configuring that domain. The End User group will be responsible to fill the data structures, created by an user of

Application Developer group, with real values of a specific satellite or ground station. The edition tool will only

permit to this group access to add data to complement the information previously inserted by the users of the

Application Developer group.

The Figure 6 illustrates the Problem Domain view with an example of edition of the Operation database. It

considers the customization of the Commanding framework for sending telecommands to satellites of the CBERS

family. First, an Operation database instance is made available to be edited. This instance should include data

required by the framework implementation (software configuration data) such as the set of event messages that the

framework can generate during its processing and the type of data contained in a command. This kind of information

is strictly connected to the existence of a specific code used by the framework model. By using this Operation

database instance, an user of the Application Developer group can insert the types of commands required for

CBERS mission, the data

structures associated to these

command types, the description

of the message layers of the

ground-board and ground-

ground protocols and the data

structures associated to each

protocol layer. After the edition

of this database instance by

users of the Application

Developer group, all the

common CBERS family

information will be available for

later use. Finally, this database

instance shall be replicated for

each one of the CBERS satellite

(CBERS2B, CBERS3 and

CBERS4) and the specific

values associated to each

satellite shall be included by

users of the End User group.

These users will be able to

create specific satellite

telecommands based on the command type structures previously defined and insert specific values for parameters

defined as fixed in the database source instance.

VI. Conclusion

The DSS team experience was vital in Commanding and Monitoring frameworks design, since it allows

identifying the variability points in both problem domains and making adequate design decisions in order to make

flexible the insertion, edition and selection of code to meet the requirements of each software product.

This design has become easier due to the use of the proposed logical architecture template and the adoption of

the design rules established for the SATCS project (design patters, metadata and component-based development).

Once the frameworks are inserted in the Subsystem and UserView layers, the project focus got centralized

exclusively in the scope of command and monitoring domains, since basic services are provided by other layers and

by the Support component.

Nowadays, the Commanding and Monitoring frameworks are being customized to create two software products

for CBERS 3&4 satellite: a TM&TC application which makes use of all the framework modules and will be

installed at INPE´s Satellite Control Center and, a DLL library which makes use of some framework modules and

will be used in the EGSE software. The use of the same commanding and monitoring kernel and Operation database

Figure 6. Database instances for the Commanding framework.

American Institute of Aeronautics and Astronautics 092407

9

in both systems will reduce the verification and validation effort of the ground control systems before the start of the

flight operation phase.

The use of metadata and the Data-stream module made it possible to reduce drastically the need to adapt the

framework codes to comply with specific requirements of CBERS satellites. A large number of requirements were

implemented by configuring the satellite Operation database. The code customization that was necessary for

CBERS satellites confirmed the variability points already identified in the frameworks. The preparation of the

Operation database was performed using the SATCS-Developer view and required a lot of work. This motivated the

necessity of creating the Problem Domain view to make it easier the task of preparing the Operation database.

Because different software products can be created using the frameworks, an important point to be considered is

the definition of well defined control configuration and validation processes. Since changes can occur in several

interdependent levels (Persistence layer, Archiving & Retrieving layer, Support component and framework), a

suitable process for updating and testing the framework elements need to be set up to assure their reliability.

References 1Cardoso, P. E.; Barreto, J. P.; Dobrowolski, K. M., “A Ground Control System for CBERS 3 and 4 Satellites,” 9th

International Conference on Space Operations, AIAA, Rome, Italy, 2006 2Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software, 1st ed.,

Addison-Wesley, Reading, Massachusetts, 1995, pp. 395. 3 Sommervile, I., Software Enginnering, 6th ed., Addison-Wesley, Harlow, England, 2001, pp. 310-318. 4Johnson, R.; Wolf, B., “Type object,” Pattern languages of program design 3, edited by R. C. Martin, D. Riehle and F.

Buschmann, Addison-Wesley, Reading, Massachusetts, 1998, cap. 4, p. 47-66.