1. 1

2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16 Spacecraft Monitor & Control Architecture ◆ Spacecraft operations are usually performed with a string (or a network) of Functional Objects. ◆ In the string (or the network), each pair of adjacent Functional Objects can be considered as a pair of Controller and Target. Ground Spacecraft Operations System (Controller) Control Monitor Onboard Data Management System (Target/ Controller) Control Monitor X-Ray Detector (Target) Ground SegmentFlight Segment

17. 17 Standard Monitor & Control Services ◆ The standard Monitor & Control Service is provided for applications through standard APIs. ◆ Monitor & Control Messages (which are Information Objects) are generated by the service entity based on a partial SIB and transferred by underlying communications protocols. Controller Application API Target Application Standard M&C Service API M&C Messages Comm. Protocols M&C Messages Partial SIB Standard M&C Service Partial SIB

18. 18 Implementation of Monitor & Control Services ◆ The standard Monitor & Control Service is implemented as a piece of middleware that can be used by different applications. ◆ Different implementations of the middleware may be required depending on the environment in which it is used. ◆ The middleware also executes procedures (that is, a protocol) necessary for exchanging M&C Messages. API Standard M&C Services API M&C Messages M&C Protocol Partial SIB Standard M&C Services Partial SIB

19. 19 Standard Control Service ◆ The Controller can control (start/stop/suspend/resume) an operation of the Target by sending a requests to the Target. The result of the request is returned to the Controller as a response. ◆ The Controller can read the value of an attribute (or a set of attributes) by sending a requests to the Target. The value is returned to the Controller as a response. ◆ The Controller can change the value of a writable attribute by sending a requests to the Target. The result of the change is returned to the Controller as a response. Request Response Target (Operations, Attributes) Controller

20. 20 Standard Monitor Service ◆ The Target can report the value an attribute (or a set of attributes) according to a predetermined schedule (e.g., every n seconds) by sending a notification to the Target.  Note: The schedule can be an attribute of the Target.  Note: What attributes to be reported can also be an attribute of the Target. ◆ The Target can notify the Controller of a change in the value of an attribute by sending a notification.  Note: The Target can notify the Controller of an occurrence of an event as a change in a relevant attribute.  Note: What changes to be reported can also be an attribute of the Target. Notification Target (Operations, Attributes) Controller

21. 21 How to Develop Necessary Standards (1) ◆ Standard Spacecraft Model  This can be developed by defining a meta-model and/or a model using the standard capability of MOF/UML, which are well-established standards for defining meta-models and models.  To do this, we can borrow some of the outcomes of the CCSDS Systems Architecture WG.

22. 22 How to Develop Necessary Standards (2) ◆ Standard Monitor & Control Service and Protocol  These can be developed based on existing standards in the field of process control.  However, some modifications to them will be necessary because these standards assume that equipment used in factories for process control has much information processing capability, whereas spacecraft instruments do not usually have much information processing capability.

23. 23 Standard Products That will be Developed (1) ◆ Spacecraft Information Base (SIB)  This can be developed using an existing XML-based database management system. ◆ SIB Generation Tool  This can be developed using an existing UML-based editor or an existing data generation tool. (For example, see next slide.) ◆ SIB Access Library  This can be developed using an existing XML parser.

24. 24 Example of a Data Generation Tool

25. 25 Standard Products That will be Developed (2) ◆ Monitor and Control Service Middleware  Several implementations may be necessary depending on the environment in which it is used. ◆ Standard Monitor and Control Application  This can be developed on top of the M&C Service Middleware by adding functions for Issuing requests based on a pre-defined timeline, Checking the validity of the values contained in received notifications, and Issuing requests based on the result of the checking mentioned above.  This application can be used either onboard spacecraft or on the ground.

26. 26 Relationship with Other Activities at ISAS ◆ SpaceCube and SpaceTron (a standard space-oriented processor card and a space-oriented operating system being developed by ISAS)  The standard Monitor & Control service will be a nice extension to SpaceCube/SpaceTron.  The standard Monitor & Control service should be able to run on any operating system, but the definition of API may depend on the operating system. ◆ SpaceWire (a standard space-oriented data bus being developed by ESA)  The standard Monitor & Control service should be able to run on any data bus, but they will be a nice extension to SpaceWire.

27. 27 International Collaboration ◆ NASA/JPL is thinking of developing a standard Monitor & Control Service based on a very similar concept. A discussion on possible collaboration is going on. ◆ ESA/ESOC is developing a UML-based model for describing their ground systems but this can be used as a partial basis to generate the standard spacecraft model proposed here. ◆ ESA already has a standard for Monitor & Control, which is called the Packet Utilization Standard (PUS), but it is hoped that we will develop a standard Monitor & Control service/protocol that can be mapped to PUS.

28. 28 Proposed Deployment Schedule CY 2004Development of a preliminary Spacecraft Model and Monitor & Control Service specifications CY 2005Refinement of the Spacecraft Model and Monitor & Control Service specifications Development of a prototype of the Spacecraft Model and Monitor & Control Service CY 2006- 2008 Development of SIB for selected missions CY 2007- 2009 Development of Monitor & Control middleware for selected missions (on SpaceCube/SpaceTron) CY 2008- 2011 Development of spacecraft and their ground system that use the SIB and the Monitor & Control Service