1. Spacecraft Monitor and Control Protocol CCSDS SM&C Working Group Amalaye Oyake NASA/JPL April-2005

2. A. Oyake - 2 APRIL 14th 2005 Success Criteria Complete CCSDS Red Book - June, 2005 Interest within JPL as a Mission Operation Methodology Complete Protocol Specification Successful Protocol Demonstration - June, 2005

3. A. Oyake - 3 APRIL 14th 2005 Planned Products Complete Protocol Specification Red Book Current Status: Still draft, but progressing … currently not as polished as I would like BUT, there are many open issues and the document reflects this. Open issues (target- controller description, onboard enablers) are being ironed out via discussions with T. Yamada, S. Burleigh and A. Vaughs. Onboard demonstration - Prototype Everyone is talking about prototyping these days, so this is a good thing. Current Status: Was examining VxWorks prototype, but I have had problems with the vendor supplied 1394 card. I am using an in-house MTS implementation instead.

4. A. Oyake - 4 APRIL 14th 2005 Introduction This presentation outlines the proposed Spacecraft Monitor and Control Protocol to be used as the basis for end-to-end Spacecraft Monitor and Control (SM&C). The Spacecraft Monitor and Control Protocol defines only the syntax and semantics for SM&C messages. It is an application layer protocol that leverages overlying space protocols (SLE, AMS, etc). Monitor and Control systems are a general class of applications and that follow a consistent set of design patterns and operations. We present a view of the common monitor and control pattern and then demonstrate how it may be applied in space operations.

5. A. Oyake - 5 APRIL 14th 2005 Monitor & Control Elements Monitor & Control (M&C) is performed by a string (or a network) of elements. These elements are not necessarily physically separated. A typical example is: Spacecraft Control Center Central Data Handling Payload Processor Device Ground

6. A. Oyake - 6 APRIL 14th 2005 Controller and Target Pattern In the string, each pair of adjacent elements can be modelled using the controller and target pattern. Controller - The element that controls and monitors the target. Target - The element that is controlled and monitored by the controller. A controller can be a ground control system, an onboard data handling subsystem, or a processor of a payload/subsystem. A target can be a device, a subsystem, or even an entire spacecraft. The pattern can be applied recursively. Controller Target Control Monitor

7. A. Oyake - 7 APRIL 14th 2005 Standard for Describing Targets There should be a standard way of describing the interfaces of targets and controllers. Protocol messages should be exchanged at the interface boundary. There should be a standard method for describing the characteristics of targets (which may be spacecraft, subsystems, processors or devices) as objects, abstracting those characteristics that are relevant to monitor and control. In order to develop such a method, there should be a model for characterizing the behavior of targets (including interactions of the objects with controllers).

8. A. Oyake - 8 APRIL 14th 2005 Standard for Describing Controllers Controllers should also be described as objects using the same method for describing targets, if they are controlled by other controllers higher in the control architecture. Observatio n Controller Spacecraft Target/ Instrument Controller Control Monitor Instrument Target / Component Controller Control Monitor

9. A. Oyake - 9 APRIL 14th 2005 Describing Targets and Controllers The method to describe targets and controllers is an open technical issue, but the ideas (CNES, JAXA, JPL) are along the same line. CNES ODISSE describes how to describe instruments using UML state diagrams. Subsystems and Instrument are described with class or object diagrams and behavior is described with UML Statechart diagrams. JAXA (Takahiro Yamada) is using UML to model instruments for the Bepi-Colombo mission. JPL is interested in UML and XML schemes similar to the Fieldbus and IEEE 1451. UML can be converted to XMI (which is XML).

10. A. Oyake - 10 APRIL 14th 2005 Device Virtualization is fundamentally about representation of device characteristics and the propagation of this information. We are primarily concerned with device metadata, and its propagation. Specifically an extensible metadata model, to represent attributes, commands, events, units and other interesting data. Metadata may be embedded in the device, e.g. EPROM or stored in some device driver and loaded via a table. Standard means of providing device descriptions to support device virtualization are under study at JPL. Describing Targets and Controllers

11. A. Oyake - 11 APRIL 14th 2005 Describing Targets and Controllers - JPL Behavior described in Function Block Device Template Placeholder Specific device description Standard header information compatible with IEEE 1451

12. A. Oyake - 12 APRIL 14th 2005 Spacecraft Monitor and Control Protocol Messages Types Send Directive to Target Confirmed or Unconfirmed Immediate, triggered, or timed Read State of Target Confirmed or Unconfirmed Trigger Execution of Target Send Indication to Controller Confirmed or Unconfirmed Send Event to Controller Confirmed or Unconfirmed

13. A. Oyake - 13 APRIL 14th 2005 REGISTER Allows a Target to register to a named Controller so as to receive updates via events or reports. DEREGISTER Allows a Target to deregister a named Controller so as to stop receiving events SEND_DIRECTIVE Allows a Controller to send a formatted directive to a named Target The Target must understand the directive. The directive may have associated with it attributes related to its execution such as Execution Time (immediate, relative, or absolute) Response required (uplink, acceptance, start, success, etc). Confirmed or Unconfirmed With argument EXECUTE, trigger the execution of a named Target GET_STATE (Added to complement SET_STATE) Allows a Controller to read the state of a named Target The directive may have associated with it attributes related to its execution such as Execution Time (immediate, relative, or absolute) Confirmed or Unconfirmed Spacecraft Monitor and Control Protocol Messages >

14. A. Oyake - 14 APRIL 14th 2005 SET_STATE (Added because I recently had to do this to clear a flag on the MARS Rover) Allows a Controller to set a variable in a named Target This is necessary to initialize specific EH&A channels, variables or for setting and clearing flags. SEND_STATE (Added because of feedback stating a REPLY MESSAGE is NOT an EVENT. It is in a sense, but there are 2 distinct meanings and SEND_STATE disambiguates the semantics) Allows a Target to send an reply message event to a Controller The new state is reported to all clients that have registered for the update This is a peer to peer message, where a Target responds directly to a Controller. The directive may have associated with it attributes related to its execution such as Confirmed or Unconfirmed Priority SEND_EVENT Allows a Target to broadcast an event message to a Controller or other Targets. The event may be an asynchronous message, a synchronous event, a time event or a Boolean event. The new state is reported to all clients that have registered for the update The directive may have associated with it attributes related to its execution such as Confirmed or Unconfirmed Priority SEND_REPORT Allows a Target to report a set of changes for one or more items to a Controller. This use case differs from the previous in that it sends a set of changes as a single entity (a report) rather than a set of changes as a set of events that might arrive out of order. Spacecraft Monitor and Control Protocol Messages >

15. A. Oyake - 15 APRIL 14th 2005 Spacecraft Monitor and Control Message Implementation The specific messages can be implemented in various ways, the Red Book implementations will explore the technical aspects of this. 1. UML state event signals - Encoding the protocol messages as standard pre-defined signals (well understood). 01 - REGISTER 02 - DEREGISTER 03 - SEND_DIRECTIVE 2. Content coded messages - Specifically encoding the messages using a content coding scheme. Would need to implement a standard content coding scheme.

16. A. Oyake - 16 APRIL 14th 2005 Typical SM&C Protocol functions include: Directive management, execution and control Instrument management, command and control Telecom system management and control Software management and control Flight dynamics management and control Storage management and control Sensor & effector management, monitor and control SM&C Protocol functions interface with other onboard functions, including instruments, attitude control service, telecom services, command and data acquisition service, etc. Each class of service will have its own application specific messages that are passed via the SM&C Protocol Service. Spacecraft Monitor and Control Protocol Functions

17. A. Oyake - 17 APRIL 14th 2005 Standard Protocol between Controllers and Targets The SM&C service protocol may be operated over different underlying communication protocols depending on the location and characteristics of the communications media used for the communications between a controller and a target. For example: Between the ground and a spacecraft, Between the central data handling subsystem and another onboard subsystem, and Between an onboard processor and a device. Standard SM&C protocol isolates Spacecraft M&C Applications from underlying communications protocols Provides standard communication patterns Provides standard control pattern

18. A. Oyake - 18 APRIL 14th 2005 SM&C Protocol The SM&C protocol aligns with the UML Statechart behavioral model (very specific messages).

19. A. Oyake - 19 APRIL 14th 2005 SM&C Protocol

20. A. Oyake - 20 APRIL 14th 2005 Onboard Message Enablers The onboard messaging system should exhibit the following characteristics: Simple API Low overhead Low latency Small “footprint” Thread - safe Portability & reusability across several different platforms Interoperability among different language and OS platforms and over different communication protocols Dynamic handling of connection state and failure modes. Support for strongly typed messages & type safety checking during connection establishment (optional). There is discussion of using AMS as the wire protocol and MTS as the API (Burleigh, Vaughs et al).

21. A. Oyake - 21 APRIL 14th 2005 Onboard Message Enablers Operating System Messaging Services Pro: Easily implemented. Con: Not feature rich. CORBA Pro: Easily implemented. Con: Code bloat, many active objects holding memory. Message Transfer Service Pro: CCSDS standard, simple API hides complexity. Con: Need draft API ratified AMS Pro: CCSDS draft, feature rich, prototype exists. Con: Need draft ratified and stable implementation. Shared memory schemes Pro: Good solution for passing messages. Con: Need to build custom API to wrap functionality.

22. A. Oyake - 22 APRIL 14th 2005 Example: SM&C Protocol in AMS PDU SEND_DIRECTIVE…DIRECTIVE:PARAMETERS:TARGET AMS PDU

23. A. Oyake - 23 APRIL 14th 2005 Issues and Concerns Stimulating interest in standards. Stimulating commercial interest (SLE has had some success in this area). Protocol format over various data links (RF/internet/onboard). Many of these links use domain specific methods see BIG- PICTURE presentation (one pager sent in email). Software implementation should be applicable to FSW. Compatibility with JPL FSW processes. Potential for follow-on work and mission infusion.

24. A. Oyake - 24 APRIL 14th 2005 > >

25. A. Oyake - 25 APRIL 14th 2005 SM&C Protocol

26. A. Oyake - 26 APRIL 14th 2005 Message Transfer Service Major Capabilities Name Space Lookup- to translate a process name to an address/path of some form Connection establishment - to link two or more processes for communication (early/late binding, service negotiation, policies) Synchronization - events, triggers, and asynchronous or synchronous communication Message Delivery- to send or receive messages Message Type - classes of messages that are transferred Transfer Mechanism- control of the transport protocol or link Error Handling - to detect, report, and recover from errors QoS- link performance and management

27. A. Oyake - 27 APRIL 14th 2005 Message Transfer API Proposed High-Level Functionality Communication Mechanisms Service initiation / termination, authentication Process - Process communication send/receive (two-sided), put/get (one-sided), blocking/non-blocking Multicast / Broadcast - specified set or promiscuous recipients Publish/subscribe - managed delivery of data Callback - event notification and handling Quality of Service Service & connection negotiation, policy management Priority/scheduling/resource management Reliability, determinism, ordering, timeliness Message buffer management (make/free/get/set/init) Error Handling, monitoring, signaling, reporting Group management (joingroup/leavegroup) Derived data types (optional / future) Packing/unpacking (optional / future)

28. A. Oyake - 28 APRIL 14th 2005 Message Passing API High-Level Functionality - Prototype Communication Mechanisms Service initiation / termination, authentication, name space lookup Process - Process communication send/receive (two-sided), put/get (one-sided), blocking/non-blocking, (trigger, polling) Multicast / Broadcast - specified set or promiscuous recipients Publish/subscribe - managed delivery of data Event notification and handling (Callback ) Quality of Service Service & connection negotiation, policy management Priority/scheduling/resource management Reliability, determinism, ordering, timeliness Message buffer management (make/free/get/set/init) (local) Error Handling, monitoring, reporting (simple) Group management (joingroup/leavegroup) Prototype Subset in bold italic

29. A. Oyake - 29 APRIL 14th 2005 Message Transfer Service Context Application Layer Interaction Model Message Service API (peer-to-peer) Transport Layer Shared Memory CFDP store & forward Msg = File Msg = DGRM Message Queue PIPEUDP SCPS-TP TCP SCPS-TP Data Link Layer 2. Peer-to-peer P1 P2 3. Pub/Sub P S1 S2 S3 1. Client/server (listen/connect/accept) C1 request response C2 request S response msgInit() bind()/resolve() openChannel() recvMsg()/sendMsg() Proximity 1 memory O.S. Service Space Link (TC & TM) Other Data Link Bus Protocol

30. A. Oyake - 30 APRIL 14th 2005 Command and Data Acquisition Service C&DA provides access to read data from simple sensors and to write to simple hardware interfaces C&DA provides 3 basic capability sets Device Access Data Product Acquisition Device Virtualization C&DA interfaces with 3 SM&C capability sets Data Monitoring Engineering Unit Conversion Data Aggregation