Spacecraft Monitor and Control Protocol

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

2. 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. 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. 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. Introduction

5. 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: Control Center Central Data Handling Payload Processor Device Ground Spacecraft Monitor & Control Elements

6. 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 and Target Pattern Control Controller Target Monitor

7. 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). Standard for Describing Targets

8. 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. Observation Controller Control Spacecraft Target/ Instrument Controller Instrument Target / Component Controller Control Monitor Monitor Standard for Describing Controllers

9. 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. Describing Targets and Controllers • 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.

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

12. 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 Spacecraft Monitor and Control Protocol Messages Types

13. Spacecraft Monitor and Control Protocol Messages <<written feedback requested>> 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

14. Spacecraft Monitor and Control Protocol Messages <<written feedback requested>> • 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.

15. 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. • UML state event signals - Encoding the protocol messages as standard pre-defined signals (well understood). 01 - REGISTER 02 - DEREGISTER 03 - SEND_DIRECTIVE • Content coded messages - Specifically encoding the messages using a content coding scheme. Would need to implement a standard content coding scheme.

16. Spacecraft Monitor and Control Protocol Functions • 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.

17. 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 Standard Protocol between Controllers and Targets

18. SM&C Protocol The SM&C protocol aligns with the UML Statechart behavioral model (very specific messages).

19. SM&C Protocol

20. 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). Onboard Message Enablers

21. 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. Example: SM&C Protocol in AMS PDU SEND_DIRECTIVE…DIRECTIVE:PARAMETERS:TARGET AMS PDU

23. 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. Issues and Concerns

24. <<END>><<supplementary information follows this slide>>

25. SM&C Protocol

26. 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 Message Transfer ServiceMajor Capabilities

27. 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) Message Transfer APIProposed High-Level Functionality

28. 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 Message Passing APIHigh-Level Functionality - Prototype

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

30. 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 Command and Data Acquisition Service