Evolution of a stateofthe art multi vehicle test system to mission operation system by using enhance

1
Evolution of a state-of-the art multi vehicle
test system to mission operation system by using
enhanced MMI technology for commanding
2
Abstract

• Evolution of state-of-the art multi vehicle test
  system to mission operation system by using
  enhanced MMI technology for commanding.
• K. Burmeister, W. Schneider
• EADS Space Transportation, 28361 Bremen, Germany.
• In the past space developments clearly
  distinguished between support tools for test and
  checkout activities during the C/D phases of
  manned and unmanned space projects and tools for
  mission operation support. The COLUMBUS C/D
  development activities established a
  configuration controlled mission database already
  in the early phases. It is continuously filled
  with spacecraft relevant data describing the
  onboard system, data exchange formats and the
  ground data necessary to perform test and
  checkout of the COLUMBUS spacecraft as well as
  crew training. The kernel SW using the database
  which is configured for all different COLUMBUS
  scenarios is the COLUMBUS ground system (CGS).
• Due to budgetary constraints and the idea to
  gain benefit from the COLUMBUS database in terms
  of completeness, integrity and configuration
  control CGS was reused to serve as well for multi
  mission control. The CGS tool set as the kernel
  SW of the control center provides a smooth
  transition from the Columbus development to the
  operational phase and contributes significantly
  to a cost effective and risk less operation
  setup.
• Main emphasis to implement a smooth
  transition was spent on the command mechanism due
  to different requirements on checkout tasks and
  mission's operation tasks. Mission operation is
  rather driven by commanding as interactive
  process of preparation/execution of single
  commands or command stacks then by automatic
  testing. The development challenge was to combine
  the reused CGS (developed in ADA) with an state
  of the art command interface implemented in JAVA
  to satisfy the mission operation tasks and to
  harmonize the man machine interfaces (MMI's).
• Beyond the standard support requirements for
  check out systems safety and redundancy
  requirements have been implemented to ensure save
  ground operations for a multi mission scenario.
  Operators in the COLUMBUS control center will be
  able to control the system and a large number of
  payload activities as well as being able to
  follow the ground communication control links
  between other control centers located in Houston,
  Huntsville, Moscow and Toulouse. Payloads can
  also be controlled remotely from the user
  operations center, facility responsible center or
  even via Internet from the scientist located in a
  University. In all cases the basic configurable
  toolset of CGS and its enhancements is used.
• Large benefits will be realized in the
  maintenance phase while using a homogeneous SW
  system incl. a database for check out and mission
  operation. Main drivers are the Database
  build-up/usage throughout all phases from initial
  tests until mission operation, continuous
  operation of the spacecraft and its payloads lead
  to improvements of the ground facility software
  including both test system and multi mission
  control and finally test and training procedures
  will be reused for mission operation and vice
  versa.

3
Session Roadmap
Requirements for Mission Control
Analysis of Re-usable Items
Building Block EGSE architecture
Programmatic Issues

• - Conclusion on Feasibility
• Implementation experience
• Future outlook

Mission Control Architecture based on Core EGSE
software
Redundancy Reliability Security
Columbus special features
New Command system for Columbus Mission Control,
USOCs UHBs
4
The main drivers for selection of reusable SW
components from the EGSE

• A configuration database which is established for
  Columbus within the C/D phase of the project
• CGS as an established and mature system existent
  in Release 5 used for COLUMBUS, ATV and several
  satellite system for check-out activities
• Columbus special features and functions
• Homogenous tool environment throughout all
  Columbus facilities

5
Requirements specifically related to Mission
Control

• Redundancy
• Security
• Specific requirements for monitoring
• Processing status information, flagging of
  parameters with conventions as in mission
  operations (e.g. alarm conditions D danger
  limit high violation)
• Line plots and line graph improvements
• Online Playback mode, Freeze mode
• Various improvements in the existing monitoring
  windows, such as raw data dump tool, monitoring
  window, out-of-limit display.
• Large set of requirements towards dedicated
  commanding
• Checking of command execution
• Authorization of commands, authorization concept
  in the MDB on enditem level
• Command history with special features (such as
  command identification (incl. pathname /
  nickname)
• Filter functions to retrieve in the command
  history
• Improvements on the UCL library functions (as the
  compatibility between the basic CGS system and
  the MCS toolset needed to be guaranteed.

6
Decision relevant programmatic topics

• Cost effective smooth transition from development
  to operational phase
• Program wide configuration management and
  consistency checking out of a central mission
  database for COLUMBUS
• Data compatibility between development and
  operations as repetitive process for each Flight
  Increment
• Compatibility with support team facilities.
• Compatibility with Columbus flight system
  schedule and Columbus software validation tests
  (SVT).
• Long-term Maintenance and extension.

7
EGSE related architecture
The main building blocks of the CGS system
architecture used for EGSE consists of

• The test execution nodes (1 or more)
• The database server
• The man machine interface (HCI from 1 up to 32
  clients)

8
Mission control related architecture

• Reuse of main building blocks from EGSE/CGS
• Slightly different architecture due to
• Requests for individual setup on operator
  consoles
• Data storage and data playback
• Redundancy and reliability
• System control from centralized component

9
Extended features Redundancy Security

• Cluster SW and nodes for DB services
• Redundant servers controlled by heartbeat
  exchange
• Security features by authentication and
  authorization via user roles linked with
  privileges information in the MDB

10
Telecommand Sources and Chains

• Tele-commands either from the MCS consoles or
  from remote USOC or UHB consoles
• Cascading architecture for CD-MCS

• Command control flow from UHB/USOC via MCS
• Web based applications
• Command consistency checks and responsibilities

11
Extended commanding features Integrated toolset
Command stack
MDB navigation
Command history
12
Synoptic Display for Onboard file transfer
13
Columbus special features

• Software Commands (SWOP commands),
• FLAP (flight application automated procedures)
• Execution commands and Pre-Defined TC's

available in the MDB
14
Feasibility Experiences

• Transition from CGS/EGSE to Mission Control
  System feasible by
• The smooth transition of 'old' code fragments via
  POSIX compliance to LINUX
• The implementation of enhanced features in the
  man machine interface area
• The development of a new command interface
• The extensions for redundancy, security and
  reliability capabilities
• Experiences and obstacles
• more than 2 Million lines of ADA code led to
  implementation compromises
• there was an underestimated effort in transition
  of SUN OS system based applications to LINUX
• the Monitoring system (user definable synoptic
  displays) were based on commercial tool DataViews
  not fully compliant to requirements and not cost
  efficient due to high runtime licence costs

15
Future Outlook

• User demands
• ease the handling within the command toolset
• unify the 'Look and Feel' of the standard MMI
  applications with the new displays developed in
  JAVA.
• Additional user demands (operational aspects)
  upon experiences with delivered system
• Initiatives taken to replace Monitoring system
  (building block -gt GWDU and synoptic displays) by
  unified synoptic system (USS)
• Harmonize the MMI between command interface and
  synoptic displays
• to eliminate completely commercial tool
  dependencies

16
Benefit for ground facility maintenance
Consistent Architecture throughout Columbus
facilities