1

2

Purpose of This Presentation

◆ To explain how spacecraft can be virtualized by using a standard modeling method;

◆ To introduce the basic concept of modeling spacecraft as a set of Objects;

◆ To explain how virtual spacecraft can be manipulated using the standard spacecraft model;

◆ To present the basic architecture for spacecraft monitor & control;

◆ To introduce the basic concept of standard monitor & control services and to explain how the standard spacecraft model is related to these services;

◆ To show relationship with other similar projects; and◆ To present a proposed schedule for deployment of the outcome

of this research.

3

What is Virtualization of Spacecraft?

◆ Virtualization of spacecraft is to present the information on the spacecraft as a set of parameters so that the information can be commonly used for the design, testing, and operations of the spacecraft.

◆ The virtual spacecraft can also serve as an online version of the specification and the operations manual of the spacecraft.

VirtualSpacecraft

Spacecraft

Information on the spacecraft presented as

a set of parameters

Design

Operations

Testing

4

Standard Method for Virtualizing Spacecraft

◆ If there is a standard method for virtualizing spacecraft, any tool for designing, testing, or operating spacecraft can be used for any virtual spacecraft.

◆ This will save cost of development of tools because the same tools can be used for multiple spacecraft.

VirtualSpacecraft A

Spacecraft B

Spacecraft A

Spacecraft C

Design Tool

Operations System

Testing System

VirtualSpacecraft C

VirtualSpacecraft B

5

A Standard Model for Virtualizing Spacecraft

◆ The standard method for virtualizing spacecraft can be provided by a standard spacecraft model.

Spacecraft

Standard Spacecraft Model

VirtualSpacecraft

6

Then, What is a Standard Spacecraft Model?

◆ A standard spacecraft model provides a common framework for describing the characteristics and internal organization of spacecraft.

◆ The model specifies a standard set of elements (or objects), relationships between elements, attributes of elements, and attributes of relationships.

◆ Note: In the first stage of this project, only the functional aspect (i.e., the functions performed by spacecraft) and informational aspect (i.e., the information exchanged with and within spacecraft) will be modeled. Other aspects (structural, thermal, etc.) will be treated at a later stage of this project by extending the method described here.

7

Functional Model (or Functional View)

◆ The functions performed by spacecraft are described as a set of Functional Objects that interact with each other.

◆ Each onboard subsystem or instrument has one or more Functional Objects. Note: There are Functional Objects on the ground, too, for te

sting and operating spacecraft.◆ A Functional Object is characterized by its operations and attrib

utes.◆ An operation is something performed by the Functional Object s

tarted with a request by another Functional Object.◆ An attribute is a parameter that represents the status of some p

art of the Functional Object. It may have a discrete value, an analog value, or a complex value like an array or a table.

◆ Operations and attributes are defined in terms of their functionality, not in terms of how they are implemented.

8

Example of Functional Objects

Gamma-RayDetection

Functional Object

Operations: M, N, … Attributes: x, y, …

ObservationManagement

Functional Object

Operations: G, H, … Attributes: t, u, …

X-Ray DetectionFunctional Object

Operations: J, K, … Attributes: v, w, …

Data ManagementFunctional Object

Operations: A, B, … Attributes: p, q, …

Attitude ControlFunctional Object

Operations: D, E, … Attributes: r, s, …

9

Types of Attributes of Functional Objects

◆ Some attributes are writable (e.g., on/off of switches and modes of operations). The value of writable attributes can be set by requests from

other Functional Objects. The value of writable attributes may change by some interna

l activities without receiving requests.◆ Some attributes are non-writable (e.g., readings of sensors).

The value of non-writable attributes cannot be changed by other Functional Objects.

10

Behavior of Functional Objects

◆ The behavior of Functional Objects can be described as rules on how attributes change or how they are interrelated with each other.

◆ The value of some discrete attributes may only change according to some rule (e.g., Off to Standby to On, but not directly Off to On). Such rules can be specified by state transition diagrams (or t

ables and how to specify state transition rules should be part of the standard spacecraft model.

◆ There may be constraints on the values of a group of attributes. Such constraints can be specified with a formal language an

d how to specify constraints should be part of the standard spacecraft model.

11

Informational Model (or Information View)

◆ The information exchanged between Functional Objects is described as a set of Information Objects.

◆ An Information Object is characterized by its semantics (what it means) and syntax (how it is realized or encoded).

◆ The semantics of Information Objects can be specified using the Functional View to some extent. For an example, see slides on Monitor and Control Services.

◆ An Information Object may be realized as a physical signal, a word or byte (i.e., a short string of bits), a data unit like a packet (i.e., an organized string of bits), or a file (i.e., a large amount of bits).

12

Example of Information Objects

ObservationManagement

FunctionalObject

CommandPacket

TelemetryPacket

DataManagement

FunctionalObject

X-RayDetectionFunctional

Object

CommandSignal

TelemetrySignal

13

How to Manipulate Virtual Spacecraft

Spacecraft Information Base (SIB)

Virtual Spacecraft

Definition of Functional Object A

Definition of Information

Object X

SIB AccessLibrary

StandardSpacecraft Model

(Template for Object Definitions)

Subsystem/Instrument Designers

DesignTool

OperationsSystem

TestingSystem

SIB GenerationTool

Note: The SIB used for the current ISAS missions only contains the definition of Information Objects

Note: This will be a UML (meta-)model

but the users are not required to have

knowledge of UML.

Note: This will be

an XML-based database.

14

Interactions Between Functional Objects

◆ Interactions between Functional Objects can be classified into the following types: Synchronization between Functional Objects (such as

synchronization of the internal clocks of different Functional Objects),

Monitor and Control (see next slides), and Bulk data (such as memory upload/download and transfer of

observed data).◆ There may be interactions that have characteristics of two types

(for example, upload of a sequence of control requests).

15

Monitor and Control Interactions

◆ Interactions of the Monitor and Control Type are modeled in such a way that one Functional Object monitors and controls the other Functional Object.

◆ The Functional Object that monitors and controls the other Functional Object is called the Controller. The other Functional Object that is monitored and controlled is called the Target.

◆ There may be Functional Objects that play the role of both Controller and Target.

◆ A Controller may monitor and control multiple Targets.◆ A Target maybe monitored and controlled by multiple

Controllers.

Controller

Control

Monitor

Target

16

Interactions Between Controller and Target

◆ The Controller can control (start/stop/suspend/resume) operations of the Target.

◆ The Controller can read the value of attribute attributes of the Target (either by explicit requests or by according to a predefined schedule)

◆ The Controller can change the value of writable attributes of the Target.

Controller

Control

Monitor

Target

17

Monitor & Control Configurations (1)

◆ What happens in the following different configurations is essentially the same.

Onboard Components

GSE

(1) Component Testing at the Developers’ Site

SpacecraftGSE

(2) System Testing at the Test Facility and Pre-

launch Checkout at the Launch Site

18

Monitor & Control Configurations (2)

◆ What happens in the following different configurations is essentially the same.

(3) Flight Operations at the Spacecraft

Operations Center on the Ground

Central Data Handling System

(4) Autonomous Operations on the

Spacecraft

SpacecraftOperations System

Onboard Components

19

Monitor & Control Configurations (3)

◆ What happens in the following different configurations is essentially the same.

(5) Autonomous Control of an Instrument

Central Ground Controller

(6) Monitor and Control of a Ground System

DevicesInstrument Processor

Ground Components

20

Monitor & Control, In Essence

◆ What happens in these configurations can be summarized as:

Controller Node

Testing/Operations Procedures

Target Node

Controller

• Controls the Target according to the procedures

• Monitors the reaction of the Target

• Determines whether the Target is functioning correctly

Target

• Performs what it is told by the Controller

• Generates data to be monitored by the Controller

21

How Monitoring is Performed (An Example)

Target Node

Data Collection

Data Generation

Data Formatting

Data Transmission

Controller Node

Limit Checking

Decision Making

Eng. Unit Conversion

Data Reception

22

Layered Implementation of Monitoring (1)

Target NodeController Node

Communications Layer:

Provides generic communications services depending on the environment (RF, LAN, etc).

Application Layer:

Developed separately for each Controller or Target.

Data Generation

Data Collection

Data Formatting

Data TransmissionData Reception

Decision Making

Limit Checking

Eng. Unit Conversion

23

Layered Implementation of Monitoring (2)

Communications Layer:

Provides generic communications services.

Application Layer:

Developed separately for each Controller or Target.

Data TransmissionData Reception

Data Collection

Data Formatting

Data Generation

Limit Checking

Eng. Unit Conversion

Decision Making

M&C Layer:

Provides generic M&C services.

Target NodeController Node

24

Layered Implementation of Monitor & Control

Target M&C Service Provider

Controller M&C Service Provider

◆ In order for the M&C Service Provider to be used for any Target, the definition of the Information Objects accepted and generated by the Target must be supplied as a database.

TargetApplication

ControllerApplication

Communications Service Provider

Communications Service Provider

Info. Object

Definition

Info. Object

Definition

Target NodeController Node

25

Generic Monitor & Control Application

Controller M&C Service Provider

◆ In order for a Controller Application to be used for any Target, the definition of the Functional Object (i.e., the Target Application) must be supplied as a database.

Generic ControllerApplication

Communications Service Provider

Information Object

Definition

Testing/Operations Procedures

Functional Object

Definition

Target Node

Controller Node

26

Standards We Need

TargetController

Target M&C Service Provider

Controller M&C Service Provider

TargetApplication

ControllerApplication

Information Object

Definition

Testing/Operations Procedures

Functional Object

Definition

Controller M&CService API

Target M&CService API

M&CProtocol

27

Proposed Deployment Schedule

2004-2005

Development of specifications (version 0) of necessary standards

2005-2006

Development of Generic Controller, M&C Service Provider and SIB (version 1) to be used for component testing

2006-2007

Development of Generic Controller, M&C Service Provider and SIB (version 2) to be used for autonomous control of instruments

2007-2008

Development of Generic Controller, M&C Service Provider and SIB (version 3) to be used for system testing

2010-2011

Development of Generic Controller, M&C Service Provider and SIB (version 4) to be used for flight operations