38
04-99 GSAW 99 1 ALTAIR AEROSPACE CORPORATION 4201 Northview Drive Bowie, MD 20716 1-800-7-ALTAIR [email protected] Automated, Reusable Mission Control System Architecture using Finite State Modeling and Object Oriented Technologies

Automated, Reusable Mission Control System Architecture ...sunset.usc.edu/GSAW/gsaw99/pdf-presentations/breakout-1/sage.pdf · 04-99 GSAW 99 1 ALTAIR AEROSPACE CORPORATION 4201 Northview

  • Upload
    ngonhu

  • View
    220

  • Download
    3

Embed Size (px)

Citation preview

04-99 GSAW 99 1

ALTAIR AEROSPACE CORPORATION4201 Northview DriveBowie, MD 207161-800-7-ALTAIR

[email protected]

Automated, Reusable Mission ControlSystem Architecture using Finite State

Modeling and Object Oriented Technologies

04-99 GSAW 99 2

Introduction

❖ Problems endemic to the present way of doingbusiness

❖ SOTG Participation Summary and Importance ofPlug and Play design

❖ Interface architecture that will support operationsthrough the 21st century

❖ A general overview of Altair COTS technologyapproach

04-99 GSAW 99 3

Classical System Development

❖ Monolithic, single contractor at best, multiple contractorsat worst, terrible history of over-runs

– contractor selection decision based on trust, difficult to reverse– PDR/CDR too little, too early, often plagued with politics– non-linear (and asymptotic) capability with time and cost

CAPABILITY

TIME

Requirements

Schedule Goals

AchievementsPDR CDR

“As good as it isgoing to get”

Linear Prediction of Capabilities

04-99 GSAW 99 4

Future System Development

❖ Typical spacecraft and missions are complex– 10’s of kparameters, multiple experiments, multiple link paths, complex

command load generation, payload and bus scheduling

❖ We should endeavor not to repeat past failures– standards selected were not standards, and OOD without knowledge

and commitment only adds difficulty

– monolithic system designs are dangerous– operations requiring extensive manning around the clock

❖ Any single system solution must be suspect– frying pan > fire syndrome (how can you tell?)

– there is a good, robust, low risk engineering solution based on modernarchitecture, commercial standards, multiple platforms

❖ plug and play for all functions/vendors/products/teams

❖ There is hope for a brighter, cooperative, future

04-99 GSAW 99 5

Top Level Goals

❖ Enable Mission Flexibility– at present systems must be chosen well before mission

❖ they cannot be changed as the mission matures

❖ they are difficult/embarrassing to change if there are development problems

❖ changing hardware OS

– plug and play architecture avoids these limitations

❖ Enable adoption of future standards– half the planet is working on web applications– hardware and OS are changing at an ever increasing rate

❖ it is impossible to predict development with any certainty

❖ we need to stay up with latest standards

❖ non - OO systems are already outdated, and will be dinosaurs by the timeEOS matures

❖ It is time for us to do better as MCS engineers

04-99 GSAW 99 6

High Level Goals

❖ Enable Mission Focus– too many spacecraft control systems are science experiments in

themselves❖ MCS should be routine engineering❖ User should be able to concentrate on mission/service

❖ Enable Teams– there are often many groups at present competing between

themselves and with commercial vendors for the same work❖ they have no alternatives at present - they all use mutually

incompatible architectures - it is compete or die

– a common architecture will allow different groups to apply theirexpertise to team problems

04-99 GSAW 99 7

OOD, Plug and Play

❖ Based on standard objects, good team dynamics, order ofmagnitude gains in “-ilities”

– functional system decision based on best performers, easy tochange decisions

– constant JTRs to review progress

– linear capability after object development

CAPABILITY

TIME

Requirements

Schedule Goals

Achievements

Linear Prediction of Capabilities

PDR CDR

04-99 GSAW 99 8

Plug and Play Designs

❖ Common MCS functional design– OOD, CORBA, IDL

❖ Common controlled system design– Model based approach

❖ FSM gives– common physical and functional models– coherent data organization (time, function)

– common data structures

– automatic data distribution– automation

• state recognition

• state transition

• automatic trends• automatic status

04-99 GSAW 99 9

SOTG Membership

❖ National Reconnaissance Office

❖ NASA/GSFC❖ Altair Aerospace Corporation

❖ Computer Sciences Corporation❖ Raytheon

❖ TASC

04-99 GSAW 99 10

SOTG Work

❖ To define CORBA based standard interfaces forSpace-related command and control systems

❖ To formalize these standards as the SpaceDomain Interface Specifications that will includeInterface Definition Language (IDL) code

❖ To make this standard IDL freely available to becompiled and used by any vendor

04-99 GSAW 99 11

SOTG Work - continued

❖ To provide an architecture that will enable vendorsto create truly “plug” and “play” products

❖ To develop a prototype command and controlsystem that implements the specification byintegrating at least two vendor products accordingto the specifications

❖ To submit these specifications to the OMG inorder to form a vertical domain to formalize them,including IDL code

04-99 GSAW 99 12

Benefits

❖ Commercial standard, plug and play interfaceand architecture

❖ Any application or team can play (single orparallel)– teams can apply their collective capabilities to tough

problems– can select several solutions for high risk areas– failures are localized to individual functions– data bandwidths can be maximized through

distributed objects and data distribution models

04-99 GSAW 99 13

SOTG Status

❖ Work Completed– Space Object Domain Definition Document Version 1– SOTG Reference Architecture Version 1– Version 1 of Requirements for Data Acquisition and

Automation subdomains

❖ Current work– SOTG services subdomain requirements– IDL for Data Acquisition, Automation and SOTG

services subdomains V1

04-99 GSAW 99 14

SOTG Plans

❖ Future work is being planned and coordinated withSOMO/CSOC and SOMO/Standards and industry

❖ Phase 2 completion Tasks Remaining - Completion a additional iterations of our processes to refine the products - Inclusion of additional “serious” vendors to the group to validate/refine the SOTG products and broaden the base of support (e.g. LMSC) - Submission of products to the OMG and work their processes❖ http://ccs.hst.nasa.gov/ccspages/teaminfo/reuse/sotg

main.html

04-99 GSAW 99 15

AMCS Characteristics

❖ Provide Practical Automation❖ Use Modern Technology❖ Use Open Systems and Standards❖ Separate the Generic from the Mission

Specific– Extend OO benefits to mission data

objects

04-99 GSAW 99 16

Command Acquisition

Interface Architecture

BATTERY 1

BATT1V

BATT1VOLTS

Battery 1

VoltsAmps

Object Management Group

Object and IDLWeb Site

ApplicationModeling

Group

CORBA IPC

BATT1V

BATT1VOLTS

Data Acquisition

VendorApplications

OO Wrappers

Automation

04-99 GSAW 99 17

Altair Mission Control Systems

❖ Full OO implementation with IPC via CORBA (IDL, IIOP)– O2 ODMS with interface to RDBMSs– Plug and play with other systems through common objects– Data distribution model (push, pull)– GUI uses integrated objects

❖ Model, command, data, state, transition access through browser

❖ Dataviews graphics

– Modern scripting language (Tcl, PALS)

❖ Finite State Model (FSM)– System state recognition, state transition, simulation, reactive

control

❖ UNIX (HP, SUN, SGI), WindowsNT

04-99 GSAW 99 18

Overview of AMCS Functionality

❖ Data, command, system, state, transition object buildfrom databases and model structures

– Real time state and status information for all systems down tocomponents

– High level command support through state transitions– Display browsers (data, command, state, transition, model)

access system objects - no requirement to develop or updateany alphanumeric display views

– Integrated mimic display capabilities using Dataviews editor

❖ FOT support through modern scripting language(Tcl/PALS), and FSM development

– Automatic operational control through schedules and reactivelogic (system state enter/exit > state transition)

04-99 GSAW 99 19

Distributed Functionality

❖ DCOM - Microsoft, Distributed Component Object Model❖ CORBA - Common Object Request Broker Architecture

– Defined by commercial OMG, commercial and OSF ORBsavailable

❖ Connectivity across many platforms, architectures

❖ Plug and play at application/object levels

– Pretty much useless for completely non-OO applications

❖ Major programs that have completed studies on AMCS– Delta, Boeing (ordnance, real time, complex)

Colin Helms, The Boeing Company, (714) 896-3311 xtn 61654

– SSF, (complex, hardware plug and play)Pete Souza, Midway Research Center, (703) 690-3614

– Teledesic (very complex, 1.5 Mparameters)Mark Matossian, Teledesic Corporation, (425) 602-6598

04-99 20

Enabling Technology - Finite StateModels

❖ Operational models defined in State Space– developed by operational engineers– scalable

– easily maintained

– fully deterministic– can be tested fully

– object oriented structure

– real time operation

❖ Two functions– state recognition, state transition

04-99 21

State Space

❖ Finite state models are defined in state space– A system equates to a space

❖ Space is an n-dimensional volume

– Models consist of systems

❖ Space has dimensions– Dimensions equate to data– Dimensions have loci

❖ Loci are data values

– Loci define states❖ States are similar to modes or configurations

❖ Systems transition from state to state

04-99 GSAW 99 22

Finite State Models (FSM)

Temp

30

Volts

Amps

20

System: BatteryState: DischargeData:Volts: 27.9Amps: 6.5Temperature: 25.4

04-99 23

Finite State Models

❖ Translate system operations into operationally usable andunderstandable terms

– Developed and operated by system engineers and Flight OperationsTeam

– Define configurations and modes as STATES– Define tasks as TRANSITIONS

❖ Finite State Models provide the framework to define the behavior ofoperational systems

❖ Data are continuously input and transformed into system andsubsystem STATES

04-99 24

State Definitions AvoidThe Limit Problem

❖ States define their own contexts

❖ Parameter limits can be set closely enough to detect subtle andincipient failures, out-of-family data

❖ State definitions can include statistical and temporal functions,dynamic signature analysis (pattern matching)

❖ Easily updated as operational knowledge is gained orcomponents deteriorate with age

04-99 GSAW 99 25

Finite State Modeling

BAT 1, 2...

PCU

TOP LEVEL SATELLITE STATE

EPSACS GNC PAYLOAD 1TT&C PAYLOAD 2

BATTERIES MAIN BUSSOLARARRAYS

DATACOMMANDSSTATESTRANSITIONS

04-99 GSAW 99 26

❖ A data object is a data set and a method– Some projects generate bizarre objects– Finite State Modeling methodology automatically generates

appropriate objects that everyone can understand

Data Objects

BATTERYMANUFACTURERPART NUMBER

DATABATT1V

BATT1VOLTSPOLYNOMIAL METHOD

C0, C1, C2, C3

04-99 GSAW 99 27

Finite State Models

Spectrum AnalyzerFFT

State RecognitionFST

SATELLITE

SUNLIGHTOPERATIONS

❖ Domain transforms provide solutions to complexproblems

RAW SIGNAL

FREQUENCY

INCOHERENT DATA

SYSTEM : STATE

04-99 GSAW 99 28

Transition Vectors

Target State

Entry State

Transition VectorOne or more commands

04-99 29

Transition Vector Structure

❖ Transition Vectors– encapsulate messy/lengthy procedural content into reusable,

structured objects– can call lower level transition vectors– provide a coherent method to accommodate command

failures❖ Control message content

– Control content can be reduced to name of system anddesired state

04-99 GSAW 99 30

Analysis and Trending

❖ Automatic and Off-Line Functionality– automated analysis based on system state recognition– all (relevant) system state data input to z-transformed real time

statistical engine (kalman filters)– output continuous trends (average, deviation, rates, integrals) for

any data item for any system and any state– calculated state exit/transition times based on trends and

dynamic system models using PAL/S

❖ Interfaces for off-line analysis tools (user defined datafiles, COTS and user toolkit integration)

04-99 GSAW 99 31

Statistical Analysis

Eclipse

Time

Solar Array Performance

SA OutputVolts

Attitude Excursion Eclipse

Sunlight

❖ Statistical analysis using conventional methods requires time-consuming, labor intensiveinspection and selection of data samples, but with FSM, data selection is automatic

04-99 GSAW 99 32

Statistical Methods

❖ First find coherent data samples❖ Then form data structures❖ Apply methods

– Continuous statistics are difficult

4 6 4 6 4 6 4 6 4 66 4

Remove old sample Add new sample

04-99 GSAW 99 33

Z -Transformed Statistics

Sample 1 2 3 4 5 6 7 8 9 10Data 4 6 4 6 4 6 4 6 4 6

Average 4 5 4.66 5 4.8 5 4.86 5 4.88 5Zavg 4.9 5.01 4.91 5.02 4.92 5.03 4.93 5.04 4.94 5.05

xnz0 = xnz-1 + x/n - xnz-1/n

Where: x is the datumxn is the average value over n samplesn is the number of samples

❖ Automatic, continuous, real-time statistical data

04-99 GSAW 99 34

Console PALS and Model Explorer

04-99 GSAW 99 35

Intuitive Graphics

04-99 GSAW 99 36

Multi-Mission Operations

❖ Core Software will support any mission– Load Heterogeneous missions from same console– Load multiple mission objects in same console

❖ Allows one person to monitor multiple spacecraft

❖ Let the computers perform the monitoring and alert user

❖ Mission specific software– Little or no coding is necessary

❖ Only for special equipment interfaces❖ FOS interface developed for AM-1

– All other mission attributes defined by databases and text files– Developed and maintained by FOT

❖ Altair office system supports dozen+ heterogeneousmissions with differing requirements at any given time

04-99 GSAW 99 37

AMCS Technology Benefits

❖ Fully object oriented, plug-and-play capability❖ Very low software maintenance❖ Mission extension maintenance by operations and

spacecraft engineers❖ Mission extension development for subsequent

spacecraft by operations and spacecraft engineers❖ Facilitates transmission of corporate mission knowledge

as personnel rotate during system lifetime❖ Automation capability allows greatly reduced staff (lights

out operations possible) to suit tight budgets

04-99 GSAW 99 38

How to Purchase Altairis

❖ Maryland Headquarters:Christopher Wheal, VP Business Development4201 Northview Drive, Suite 410Bowie, MD 20716Voice: (800)7-ALTAIRFax: (301)805-8122Email: [email protected]

❖ Colorado Office:Robert Miller, Principal Engineer, Advanced Systems195 Fox Hill LaneColorado Springs, CO 80919Voice: (719)266-6509Fax: (719)266-6516Email: [email protected]

❖ Web Site: www.altaira.com