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. Virtual 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. Virtual Spacecraft A Spacecraft B Spacecraft A Spacecraft C Design Tool Operations System Testing System Virtual Spacecraft C Virtual Spacecraft 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 Virtual Spacecraft

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 testing and operating spacecraft. ◆ A Functional Object is characterized by its operations and attributes. ◆ An operation is something performed by the Functional Object started with a request by another Functional Object. ◆ An attribute is a parameter that represents the status of some part 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-Ray Detection Functional Object Operations: M, N, … Attributes: x, y, … Observation Management Functional Object Operations: G, H, … Attributes: t, u, … X-Ray Detection Functional Object Operations: J, K, … Attributes: v, w, … Data Management Functional Object Operations: A, B, … Attributes: p, q, … Attitude Control Functional 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 internal 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 tables 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 and 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 Observation Management Functional Object Command Packet Telemetry Packet Data Management Functional Object X-Ray Detection Functional Object Command Signal Telemetry Signal

13 How to Manipulate Virtual Spacecraft Spacecraft Information Base (SIB) Virtual Spacecraft Definition of Functional Object A Definition of Information Object X SIB Access Library Standard Spacecraft Model (Template for Object Definitions) Subsystem/Instrument Designers Design Tool Operations System Testing System SIB Generation Tool 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 Devices Instrument 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. Target Application Controller Application 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 Controller Application Communications Service Provider Information Object Definition Testing/ Operations Procedures Functional Object Definition Target Node Controller Node

26 Standards We Need Target Controller Target M&C Service Provider Controller M&C Service Provider Target Application Controller Application Information Object Definition Testing/ Operations Procedures Functional Object Definition Controller M&C Service API Target M&C Service API M&C Protocol

27 Proposed Deployment Schedule Development of specifications (version 0) of necessary standards Development of Generic Controller, M&C Service Provider and SIB (version 1) to be used for component testing Development of Generic Controller, M&C Service Provider and SIB (version 2) to be used for autonomous control of instruments Development of Generic Controller, M&C Service Provider and SIB (version 3) to be used for system testing Development of Generic Controller, M&C Service Provider and SIB (version 4) to be used for flight operations