spacecraft monitor and control protocol ccsds sm&c working group amalaye oyake nasa/jpl...

Spacecraft Monitor and Control Protocol

CCSDS SM&C Working Group

Amalaye OyakeNASA/JPL April-2005

APRIL 14th 2005 A. Oyake - 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


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.


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.


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

ProcessorDevice

Ground


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


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).


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.

Observation

Controller

SpacecraftTarget/

Instrument Controller

Control

Monitor

InstrumentTarget /

Component Controller

Control

Monitor


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).


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


Describing Targets and Controllers - JPL

Behavior described in Function Block

Device Template Placeholder

Specific device description

Standard header information compatible with IEEE 1451


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


REGISTERAllows a Target to register to a named Controller so as to receive updates via events or reports.

DEREGISTERAllows a Target to deregister a named Controller so as to stop receiving events

SEND_DIRECTIVEAllows a Controller to send a formatted directive to a named TargetThe Target must understand the directive. The directive may have associated with it attributes related to its execution such asExecution 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 TargetThe directive may have associated with it attributes related to its execution such asExecution Time (immediate, relative, or absolute)Confirmed or Unconfirmed

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 TargetThis 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 ControllerThe new state is reported to all clients that have registered for the updateThis 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 UnconfirmedPriority

SEND_EVENTAllows 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 updateThe directive may have associated with it attributes related to its execution such as

Confirmed or UnconfirmedPriority

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

<<written feedback requested>>


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 - DEREGISTER03 - SEND_DIRECTIVE

2. Content coded messages - Specifically encoding the messages using a content coding scheme. Would need to implement a standard content coding scheme.


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


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


SM&C Protocol

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


SM&C Protocol


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).


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.


Example:SM&C Protocol in AMS PDU

SEND_DIRECTIVE…DIRECTIVE:PARAMETERS:TARGETAMS PDU


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.


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


SM&C Protocol


Message Transfer ServiceMajor 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


Message Transfer APIProposed 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)


Message Passing APIHigh-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


Message Transfer Service Context

Application LayerInteraction Model

Message Service API(peer-to-peer)

Transport Layer SharedMemory

CFDP• store & forward• Msg = File• Msg = DGRM

MessageQueue

PIPE UDP

SCPS-TP

TCP

SCPS-TP

Data Link Layer

2. Peer-to-peerP1 P2

3. Pub/SubP S1 S2 S3

1. Client/server(listen/connect/accept)C1 request response C2 request S response

msgInit()bind()/resolve()openChannel()recvMsg()/sendMsg()

Proximity 1memory O.S.Service

Space Link(TC & TM)

Other Data LinkBus Protocol


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

spacecraft monitor and control protocol ccsds sm&c working group amalaye oyake nasa/jpl...

Documents

control smc

control pattern

control systems

control architecture

control protocolccsds

proposed spacecraft

protocol messages

common monitor