1 UML Modeling of Spacecraft Onboard Instruments Takahiro Yamada, JAXA/ISAS April 2005

2 Purposes of This Presentation 1.To show the functional model of spacecraft that ISAS is developing. 2.To explain the concept of the generic controller that ISAS is planning to develop for testing and operations of future spacecraft. 3.To show examples of the description of Functional Objects generated with a UML tool. 4.To discuss some issued related to the specification of the CCSDS Spacecraft Monitor & Control Service and Protocol.

3 1. Functional Model of Spacecraft

4 Functional Model of Spacecraft ◆ The functions performed by spacecraft are described as Functional Objects. ◆ Each onboard subsystem or instrument has one or more Functional Objects.  Note: There are Functional Objects also on the ground for testing and operating spacecraft. ◆ Functional Objects are characterized by their attributes and operations. ◆ Attributes are parameters that represent the status of some parts of Functional Objects. ◆ Operations are actions performed by Functional Objects started with requests by other Functional Objects.

5 Behavior of Functional Objects ◆ The behavior of Functional Objects can be described with:  Constraints on the values of attributes, and  Rules on how the values of attributes can change. ◆ Spacecraft have some rules on their static behavior.  Example: When the transmitter is in the High Power Mode, the transmitter power should be greater than some value.  Described as constraints on the values of a group of attributes.  Specified with the Object Constraint Language of UML. ◆ Spacecraft have some rules on their dynamic behavior.  Example: Off -> Standby-> On, but not directly Off -> On  Described as rules on transitions of the values of attributes.  Specified with State Diagrams of UML.

6 Interactions Between Functional Objects ◆ Most interactions between Functional Objects can be modeled in such a way that one Functional Object (Controller) monitors and controls the other Functional Object (Target). ◆ The Controller  Reads the values of attributes of the Target,  Changes the values of attributes of the Target, and  Invokes operations of the Target. ◆ The Target  Sends to the Controller the values of some attributes according to a predefined schedule, and  Notifies the Controller of changes in the values of attributes. Controller Control Monitor Target

7 Monitor & Control of Functional Objects Controller Node Testing/Operations Procedure Target Node Controller Functional Object Verifies the validity of the given procedure Controls the Target according to the procedure Monitors the reaction of the Target Determines whether the Target is functioning correctly Target Functional Object Performs what it is told by the Controller Generates data to be monitored by the Controller

8 2. Concept of Generic Controller

9 Layered Implementation of Controller Communications Layer: Performs communications Application Layer: Performs functions that require knowledge of the behavior of the Target Monitor and control of the Target Data Conversion Layer: Performs data conversion and formatting Controller Node Data communications Data conversion and formatting

10 Generic Controller Generic Data Conversion ◆ If the characteristics of the Target is supplied as the definition of Functional Objects and Information Objects in SIB, we can develop a generic Controller that can be used for any Target. Generic Controller Application Communications Protocols Information Object Definition Testing/ Operations Procedure Functional Object Definition Controller Node SIB

11 Applications of the Generic Controller ◆ The generic Controller can be used for ANY Target (which can be an instrument or a spacecraft) by supplying  The definition of the Functional Objects that describe the Target,  The definition of the Information Objects that the Target generates and consumes, and  The communications protocols used for communications with the Target. ◆ The generic Controller can be used for  Testing of onboard instruments (on the ground),  Testing of integrated spacecraft (on the ground),  Flight operations of spacecraft in orbit (on the ground), and  Autonomous operations of spacecraft in orbit (onboard).

12 3. Examples of Functional Object Definitions

13 Overview of the Diagrams ◆ The functions and behavior of each Functional Object are described with a Class diagram and a State diagram. ◆ The UML diagrams contained herein were generated with MagicDraw. ◆ Class diagrams are used to describe:  Attributes,  Operations, and  Static behavior. ◆ State diagrams are used to describe:  Dynamic behavior.

14 Class Diagrams ◆ Each class describes:  The name of the Functional Object,  Static behavior (with OCL),  Attributes, and  Operations.

15 State Diagrams ◆ Each state describes:  The name of the state, and  The attribute name and its value that indicate that the Functional Object is in that state. ◆ Each arrow describes a transition triggered by a command (i.e., invocation of an operation) or by an internal event.

16 Register Functional Object

17 Detector Functional Object

18 4. Issued Related to SM&C Service and Protocol

19 How to Set Values to Attributes ◆ Basically, there are two ways to set values to attributes: 1. To use a special primitive and a special message for setting values to attributes (SNMP uses this method), and 2. To use a generic operation and a generic message for invoking an action (Both the SM&C Core Service Specification and the SM&C Protocol specification use this method). ◆ I preferred the 1st method to the 2nd, but after drawing the UML diagrams, I have come to think that the 2nd method matches better with the UML model because all external triggers can be specified uniformly by the 2nd method. ◆ I think this issue should be discussed by the SM&C WG.

20 How to Model Notifications ◆ Basically, there are two ways to notify the user of the occurrence of an event: 1. To use a special primitive and a special message for notifying an event (Both the SM&C Core Service Specification and the SM&C Protocol specification use this method), and 2. To use a generic primitive and a generic message for notifying the change in the value of an attribute. ◆ I think that the 2nd method matches better with the UML model because everything that happens in the target can be described with attributes, but if any event notification is defined using an attribute value, the 1st method is also OK. ◆ I think this issue should be discussed by the SM&C WG.