敏捷卫星任务规划系统

SpaceOps 2006 - Conference
th The mission planning system for AGILE mission
G. Del Bello1, A. Michetti1, F. D’Amico2 (*)
1Telespazio S.p.A., a Finmeccanica/Alcatel company, Fucino Space Center, 67050 Ortucchio (AQ), Italy 2Telespazio S.p.A., a Finmeccanica/Alcatel company, Headquarter, 00156 Rome, Italy
1 Why the Agile Mission Control Centre (MCC)
When Telespazio started the analysis of the Agile mission, due to the mission profile, the necessity of a
system devoted to the on board activities planning has immediately been pointed out. Then, during the
system design phase, while executing the “make or buy” analysis, some major considerations like the costs
for proprietary system customization, and the proprietary system characteristics related to the system
reusability and the system configurability lead the decision of an internal mission planning system
development.
Analysis on commercial tools has highlighted how proprietary systems generally provides good technologies
and a good technical support, but unfortunately they always introduced a set of drawbacks too. Each system
supplier, for instance, defined their own proprietary standards, and proprietary file formats, so that the costs
for adaptation becomes often prohibitive for small missions like Agile is.
MCC heritage is based on mission planning solutions used in Telespazio to manage other missions ( e.g.:
Artemis, from ESA, or Sicral, from Italian MoD). Each mission implements a dedicated mission specific
solution. Unfortunately the costs of developing these systems often ran around the 100k’s of Euros : so, for
the Agile mission, but having in mind further application in similar missions, Telespazio decided :
I. to invest time and effort into the identification of a generic mission planning solution
II. to use open source/freeware products as much as possible in order to lower the costs of such a generic mission planning solution to a level which could support the small and cheaper concept
satellites as such Agile.
Telespazio developed MCC based on its experience on mission planning solution and satellite operations
conduction, covering all functionalities required by the Agile mission, but easily expandable by simply
customizing the application database or by adding mission specific functionality.
2 MCC Role in S/C Operations Execution
The purpose of MCC is to ensure the overall consistency of the Payload operational requests, expressed in
an activity plan issued by the Agile payload users, against the operational constraints, prior to convert the
obtained combined operations plan into telecommand sequences for the satellite control center (SCC).
The detailed objectives for MCC are:
• Checks of the operation requests (Payload, Flight Dynamics and Spacecraft) against the rules and constraints.
• Automatic translation of all the payload activities in telecommand sequences suitable for SCOS 2000 Control Centre;
• Automatic translation of the S/C platform activities in telecommand sequences ( e.g.: S/C repointing manoeuvres) suitable for SCOS 2000 Control Centre;
• Automatic send of telecommand sequences to the SCC;
• Automatic management of the file exchange with the ASDC;
• Automatic management of the routine flight operations;
• Replanning management (including on board queue cleaning of previous plan);
SpaceOps 2006 Conference AIAA 2006-5722
• On Demand Payload Configuration; • Messaging System; The following figure describes how MCC interact, exchanging data files, with all the ground segment components:
The main purpose of MCC is to improve efficiency by automating routine tasks during operations whilst minimizing the additional effort in the preparation phase. MCC
SCC
3 MCC subsystem description
The Mission Control Centre (MCC) module is aimed to provide full support for both the payload planning and the creation of command procedures to perform the AGILE flight operations . The Mission Control Centre is completely Data Base driven, and has been developed in Java Programming Language, so it can be run on all the main platform types, including the Linux Operating System on x86 workstation, which is the one used for the Agile Control Centre.
The MCC receives the Payload configuration and observation requests from client and the orbital file, the Sequence of events from the Flight Dynamics Centre, and on their basis is capable to generate the whole set of command sequences needed to the management of the Payload configuration and the Platform operations during all the orbit phases.
The command sequences can be generated to cover all the operations within a configurable time span. These are produced in a format suitable for the SCOS 2000 control centre, and are automatically sent to the AGILE SCS. The MCC also performs a feasibility check for the Payload requests, and generate alert messages to the client in case of detection of violation of any constrain.
The graphical section on MCC can also display graphically the observation requests, the constraints and the constraints violation to the user, giving zooming and time inspection capabilities. A messaging functionality is embedded in the Mission Control Centre for exchange of communications between the various entities involved in the satellite operations.
MCC will be basically constituted of two components :
• Mission Planner
• Scheduler
Each of the above is detailed in the following.
3.1 Mission Planner
Mission Planning is carried out both on a long and short term-basis essentially developing plans for platform and payload utilisation in coordination with the ASDC which provides the skeletal plan for payload use based on user requests . The MCC is responsible for the scheduling of on board operations and station contact, guaranteeing the feasibility of the schedule and maximising compliance to the input schedule provided for the ASDC.
As part of the Agile ground segment, the Mission Planner main tasks are :
• to read mission planning information and command details;
• to interface with the Flight Dynamics for the orbital events collection;
• to get Station Schedule File which summarizes the pass plan of the spacecraft with respect to a chosen Ground Station;
• to collect operations requests from an external entity;
• to produce conflict free Spacecraft Operations plans and Schedules
• Replanning capability taking into account uplinked commands status
• to define the time window for a Task by applying:
o Absolute Constraints relative to an Absolute Date
o Event Constraints relative a specific Event occurrence (e.g.: Starts after the AOS)
Mission Planning does not cover the preparation of the Detailed Schedule of Telecommands , which is specified in the relevant section.
3.2 Scheduler
The Scheduler application is in charged of the translation of the combined observation file resulting as an output of the Mission Planner, into a command file to be uplinked on board by means the satellite control center. The combined observation file contains payload activities, platform activities, eclipses, and configuration data.
Platform activities are based on scheduling activities carried out by the FDC: these are given as input to the Mission Planner and specify a preferred execution time within an allowable interval. Platform and payload configuration activities are to be considered in the telecommand schedule.
Satellite operations resulting from a user request are also available at this stage of the scheduling process. FDC shall provide related command parameters to ensure the feasibility of the user request.
The telecommand schedule is generated, based on the information contained in the combined observation file generated by the Mission Planner; the generated schedule will be editable by means the command stack available at the control center.
To avoid problems with the on board buffer during the command uplink, generated sequence, will be assigned to a satellite passage and time tagged in terms of execution time ( defined during sequence building and managed on board ). The uplink time will be defined, inside the sequence, in terms of relative time established by the operative team and updated in absolute time once the command sequence is loaded and activated on the SCC command stack. The on board execution time will be defined in accordance with the service request and respecting the service activation rules as described in the satellite handbook.
A TC sequence generated by the scheduler will be created in a SSF ( saved stack file ) format and saved on the satellite control center to be immediately uplinked.
3.3 Guaranteeing Command Syntax Consistency
All types of operations requests are referencing procedures that have been established by the Flight Control Team. The Planning granularity is at the level of the flight procedure (command sequence).
MCC uses a copy of the SCC’s database to produce detailed telecommand files for the satellite control center from the operations requests. These are transferred automatically to the satellite control system as time tagged commands in “Saved Stack Files” format, thereby guaranteeing syntax consistency, towards the satellite control center DB, for spacecraft commanding.
3.4 Guaranteeing overall plan consistency in relation to other ground segment facilities
MCC integrates the transfer of products from and towards the various sources within the ground segment, such as Flight Dynamics. Together with these inputs the MCC adds platform operations to the plan to complete the set of activities dedicated for the Spacecraft. Above activities are always referred to the S/C procedures defined in the FOP – Flight Operations Plan - : this closes the loop from the initial design of the S/C procedure until scheduled on board execution, minimizing the probability of error in operations execution.
4 MCC Principle of operations
The functionality of MCC goes beyond payload scheduling by integrating operations defined by flight dynamics, the TT&C station scheduler and the flight control team into a single, consistent mission plan. MCC allows the flight control team to automate routine activities by attaching command sequences to events from various sources. For example:
• Configuration of housekeeping telemetry generation rate, for in-pass and out-of pass operations, based on TT&C station AOS and LOS;
• Modelling of telecommand uplink strategy, based on TT&C station availability;
In practical terms MCC saves a significant amount of manual analysis and command preparation that would otherwise need to be performed by the Flight Control Team.
Aside from the essential task of integrating payload requests with platform operations MCC increases the efficiency of the Flight Control Teams activities in the several important areas. Construction of an appropriate spacecraft operations request file then allows commands for selection of the correct S/C configuration to be included in the mission plan, based on the visibility of the spacecraft over each ground station. Integration of platform and payload operations into a single consistent timeline greatly simplifies the scheduling of pass-based operations.
5 MCC SYSTEM DESIGN
5.1 M CC Design Tools
MCC is constituted by a set of Java programs that can be started independently as a command line from any Linux shell. They can be :
• Program written using Java development language. It will use a dedicated Java interface to access MYSQL database.
• Combination of script files and Java programs.
• MYSQL utilities programs. In particular SQL scripts will be processed by MYSQL tool to create MCC database tables.
• Linux commands.
5.2 M CC System Decomposition Description
Most of the MCC operational information is stored in a MYSQL database, installed on each of the two MCC dedicated PC. The MYSQL server shall be running and accessible for the MCC software to operate.
Two types of data will be stored in the database tables :
• Static data, are needed for the MCC software to operate. They are changed by the operator to alter the MCC configuration.
• Dynamic data, like events or plan activities, are stored by operational processes during MCC operations,
During operation, the MCC software will rely on three types of processes :
• Event driven events, i.e. : events generated from external interfaces or from others processes. ).
• Operational processes are slave processes started by the scheduler in response to incoming events or to achieve specific tasks. They can access the database and exit after they have completed their job.
• MMI processes enables the operator to alter database content through a graphical user interface.
Those processes will rely on the scheduler to trigger operational tasks but can directly access the database.
6 Implementation view
The MCC software will be installed on the local disk of two personal computers in the Agile OCC room.
It shall be able to run at any time from any of those workstation but, to avoid inconsistencies in the generated data, only one instance of the MCC might be running at a time in the overall Agile OCC system. Exchange of files with the SCC shall be done through an accessible shared area; exchange of files with FDC and ASDC shall be done using FTP function through internal LAN and ASINET infrastructure.
Each computer has a specific role in the MCC architecture. Computer role is hereafter described : • MCC#1 : Prime MCC system, devoted to the main MCC system functions
• MCC#2: Backup MCC system, devoted to the backup MCC system and Data Routing functions.
MCC#2 workstation is also configured to host the MCC maintenance environment.
7 Functional view
The figure below shows the functional view of the MCC software.
Not all operational processes are fully represented as they are all started in the same way by the scheduler. Only the main processes, the file sender/receiver, the activity manager and the MMI are explicitly shown.
7.1 M MI description
7.1.1 Main MMI
The main MMI window is formed by a menu bar, from which is possible start and stop the MCC modules, and which can start all the others MMI.
There is also a tabbed panel with two tabs:
• The first shows a group of elements, representing the status of MCC
• The second and will show graphically all the events contained in the plan, the requested observations from ASDC and the constraint violations.
At the bottom of this MMI is present Event Log panel, showing all the last event logs.
7.1.2 Configuration MMI
A maintenance MMI which allow the management of each parameter of MCC.
7.1.3 Sequence Management MMI
This MMI will let the user to build/modify/delete command sequences to be used for both payload and Operational activities.
Each sequence is built by a number of telecommands constructed on the basis of a copy of the S/C database.
For each telecommand parameter the user can set the MCC to use the values coming from FDC or ASDC, to use a fixed value, or to use the DB default value.
Each telecommand can be linked to an event contained in the SOE file from FDC, or to a passage, or can be linked to a configuration request from ASDC. The telecommand will be timetagged automatically by MCC, and the timetag can be set by the user as a configurable relative time from the start or the stop of one of such events.
7.1.4 Planning/Replanning
The planning/replanning modules are simply started from the menu bar of the main MMI.
It is possible to select the time span for the planning, and another time span indicating the period for the uplink of the current plan.
By clicking on the “Generate short term plan” will be started the activity parser and will shown graphically all the events contained in the plan. Then it will be started the Activity Manager to build the Activity Plan consistent with the constraints.
From the same menu is possible start the generation and to send the TC sequences suitable for SCOS2000 CCS.
7.1.5 OSM
This MMI will provide functionalities to write an Operative Service Message, which is a dedicated message which can be exchanged between the system entities.
On the reception of an OSM from an entity, this MMI will be opened showing the message.
8 MCC Development Environment
MCC system development is based on the use of freeware and open-source tools. Table below indicates the development and run-time environments in terms of operating system and development tools :
Programming Language Java
Data Base MySQL ver. 4.0.18 Development Environment NetBeans 4.1
Operating System SuSe Linux 9.1
9 Conclusions
Whatever has been summarized in these few pages, allowed Telespazio to realize a low-cost, extremely flexible mission planning system capable to automate the Payload planning and the daily Flight Operations, requiring low operators workload to manage the AGILE satellite.
10 References
[1] M. Tavani et al., “Science with AGILE”, Gamma 2001, American Institute of Physics 587, p.729, 2001
[2] V. Cocco et al., “The Science of AGILE: Part I”, Nuclear Physics B 113B (2002) 231-238
[3] C. Pittori et al., “The Science of AGILE: Part II”, Nuclear Physics B 113B (2002) 239-246
[4] F. Longo et al., “AGILE and gamma-ray astrophysics”, Nuclear Physics B 124 B (2003) 222-229
[5] r.it/。