Transcript Spacecraft Monitor and Control Architecture Study

INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Architecture Study
SOIS: Command and Data Acquisition
Service
MOIMS: S/C Monitor & Control Service
Peter Shames, Joseph F. Smith, Amalaye Oyake
Jet Propulsion Laboratory/Caltech
Takahiro Yamada
JAXA/ISAS
10 May 2004
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 1
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
MOIMS: Spacecraft Monitor & Control (SM&C)
• Typical SM&C 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 functions interface with other on-board functions,
including instruments, attitude control service, telecom services,
and low level command and data acquisition service.
• Each class of service will have its own application specific
messages that are passed via the generic M&C Protocol Service.
• N.B Failure detection, interpretation and correction or recovery
is a service that operates along side SM&C, but is separate from it.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 2
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Example Specific Spacecraft M&C Applications
Ground
Directive
Management
Flight
Dynamics
Station
M&C
Spacecraft
Instrument
M&C
OB Directive
Execution
Telecom
M&C
Command &
Data Acq
OB Flight
Dynamics
OB Software
Management
Standard
services
10 May 2004
Storage
Management
OB Software
Management
App Specific
Msgs
App Specific
Msgs
SM&C Service
Agent
OB Instrument
M&C
Standard
services
SM&C
PDUs
SM&C Service
Agent
System Engineering Area - System Architecture Working Group
PS, et al Page 3
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Example M&C Standard Protocol Services
10 May 2004
•
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
System Engineering Area - System Architecture Working Group
PS, et al Page 4
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Example SM&C Protocol Services
SM&C Examples
•
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
10 May 2004
Send
Send
Send
Send
Confirmed directiveFile Timed
directiveExecution Immediate
Confirmed SWLoad Triggered
instrumentLoad Immediate
Read
Read
Read
Read
unConfirmed instrumentState Immediate
directiveExecutionState Immediate
SWLoadVerification Immediate
telecomState Immediate
Trigger Confirmed SWLoad
Trigger directiveExecution Immediate
Trigger Confirmed SWLoad
Indicate
Indicate
Indicate
Indicate
SWLoadComplete
SWLoadVerificationComplete
telecomSystem1Off
TCM37Complete
Event OBCDump
Event observation4357Complete
Event telecomSystemFault
System Engineering Area - System Architecture Working Group
PS, et al Page 5
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
General SM&C Connectivity Model
Controller
Target
Model
10 May 2004
Target
SM&C
Application
SM&C
Application
SM&C
Service Agent
SM&C
Service Agent
Comm.
Protocols
Comm.
Protocols
System Engineering Area - System Architecture Working Group
PS, et al Page 6
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Command and Data Acquisition Service
• C&DA is a core SOIS service that provides low overhead
access to read data from simple sensors and to write to
simple hardware interfaces.
• Extended C&DA functions are provided by a set of related
services that perform data fusion, simple analysis, limit
checking and results storage for access by other onboard
services.
• C&DA access to devices is supported by a virtualization
service that implements a set of virtual generic device
model and by device drivers for each class of device/link
that implements the virtual device for the specific
transducer, sensor or effector. This is a hardware
abstraction layer (HAL).
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 7
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Command and Data Acquisition Service, contd
• C&DA access to devices is supported by a virtualization
service that implements a set of virtual generic device
models. This may be provided by device drivers for each
class of device / link that implements the virtual device for
the specific transducer, sensor or effector, or by smart
devices themselves.
– This is a hardware abstraction layer (HAL).
• A Plug & Play Service maps actual device characteristics
onto the virtual device model. It may use information read
directly from the device, ala USB or IEEE 1451, or may use a
table driven approach to identify specific device
characteristics.
– Device characteristics may include: attributes, engineering units,
variables, parameter arrangement & relationships and calibration
information.
• The C&DA services may be called by other onboard services,
such as the S/C Monitor and Control Service.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 8
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Command and Data Acquisition Service
Service Elements
Data Repository:
Collection of data from
sensors into a data
base of recent readings
Data Product Acquisition:
Data from multiple sensors
are accessed with a single
request and data products
are produced
Data
Repository
Engineering Unit Conversion:
Conversion of raw sensor
data into engineering units
Device Access: Conversion
of user- supplied logical
address into a physical
address
DN - EU Conv
Data Product
Acquisition
Data
Monitoring
Name/Addr
Mapping
C&DA
Device Virtualization: Devices are
read and controlled using a
virtual generic device image or
model. May be implemented in
Driver or in Transducer itself.
PnP
Service
Device
Virtualization
Device
Driver
Transducer
10 May 2004
System Engineering Area - System Architecture Working Group
Data Monitoring:
Comparison of monitored
sensor data against red
and yellow limits
Plug & Play Service:
Provides means for
mapping actual device
capabilities (device
announced or table
driven) onto virtual
device model
Device Driver:
Implements virtual device
model for specific
transducer & link
Transducer: Physical
sensor or effector
connected via some link
(physical or RF)
PS, et al Page 9
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Command and Data Acquisition Service
Relationship to Monitor & Control Service
Spacecraft Mon & Con Service: S/C
service to control, monitor and
manage resources, accept ground
Data System (GDS) requests and
supply responses
Data
Repository
Mon & Con
Service
DN - EU Conv
Data Product
Acquisition
Data
Monitoring
Name/Addr
Mapping
C&DA
Command and Data Acquisition Service:
send commands to transducers, read,
process, and store results, perform
limit checking
Device
Virtualization
PnP
Service
Device
Driver
Standard M&C Protocol:
Used by both the SM&C
and C&DA services.
Provides common
communication for
monitor & control.
10 May 2004
Transducer
System Engineering Area - System Architecture Working Group
PS, et al Page 10
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Example C&DA Protocol Services
C&DA Examples
•
Send Directive to Target
– Confirmed or Unconfirmed
– Immediate, triggered, or timed
Send
Send
Send
Send
•
Read State of Target
– Confirmed or Unconfirmed
Read unConfirmed sensorState Immediate
Read effectorExecutionState Immediate
Read transducer Immediate
•
Trigger Execution of Target
•
Send Indication to Controller
– Confirmed or Unconfirmed
•
Send Event to Controller
– Confirmed or Unconfirmed
10 May 2004
Confirmed sensorDirective Immediate
effectorConfigParam Timed
sensorDirective Triggered
Confirmed FPGALoad Triggered
Trigger Confirmed FPGALoad
Trigger effector Immediate
Indicate
Indicate
Indicate
Indicate
Event
Event
Event
Event
FPGALoadComplete
FPGALoadVerificationComplete
effectorExecutionComplete
sensorDirectiveTriggered
overTempDetected
transducerValue
sensorFault
effectorOffLine
System Engineering Area - System Architecture Working Group
PS, et al Page 11
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
C&DA Relationship to Monitor & Control Service
Spacecraft Standard Services
OB Directive
Execution
OB Telecom
M&C
OB Software
Management
OB Instrument
M&C
Storage
Management
SOIS
Domain
OB Directive
Management
OB
Command &
Data Acq
OB SM&C
Service
OB Flight
Dynamics
(Currently) Un-standardized
Application Specific Messages
SM&C Service
Agent
(Operations
Concept)
10 May 2004
System Engineering Area - System Architecture Working Group
MOIMS
Domain
PS, et al Page 12
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Relationship Between
SOIS C&DA and MOIMS SM&C Services
• SOIS / Time Critical On-board Applications
- Concerned with C&DA, as well as other internal onboard
services
- Defines high-level to low-level service interaction
- Work needs to be done to define service access from
external entities and across S/C boundaries.
• MOIMS - Spacecraft Monitor & Control
- Primarily concerned with end-to-end Monitor and Control
- Includes flight and ground elements for M&C
- Operations concept not yet formalized
• Proposal: Standardize a common Operations Concept, device
modeling approach and M&C protocol between onboard
(C&DA) and the external world (SM&C).
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 13
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Standardized Monitor & Control Service
• Candidates for protocol standardization include
- International standard Distributed Management Task
Force (DMTF) Common Information Model (CIM),
http://www.dmtf.org/
- Internet Standard Monitor & Control Frameworks
(SNMP), http://www.rfc-editor.org/rfc.html
- ESA Packet Utilisation Standard (PUS)
- Possible JPL contribution (open-discussion)
• Challenges to this standardization
- Connectivity / protocol mis-match between Internet
environment and space systems
- Differences in typical operations models (packet oriented
vs file based, near Earth vs Deep Space, command /
response vs command file vs goal oriented)
- Lack of existing agreements for openly sharing
intellectual property between agencies
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 14
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
MOIMS: SM&C Recommendations
• Develop standards for:
– Modeling and describing targets (and controllers) as
objects, based on industry standards if possible,
– M&C Service API that can be used by applications in
controllers and targets, and
– M&C Protocols between M&C Service Agents that
implement the services used by controllers and targets.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 15
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
MOIMS: SM&C Recommendations, contd
•
Develop an agreed set of specific Spacecraft M&C
services that will use the M&C Service interfaces.
Examples are:
– S/C directive load and verify (command or goal level
directives)
– S/C directive initiate
– Schedule load, verify & initiate
– Instrument directive load, verify, and initiate
– Telecom system control, verify, and initiate
– On Board Data Management
– On Board Computer (OBC) dumps
– Load and verify ephemeris
– Load and verify OB S/W (full load or patch)
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 16
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
SOIS: C&DA Recommendations
• Develop standards for:
– Modeling and describing sensors & effectors as
objects, based on the same industry standards as
MOIMS SM&C,
– Device virtualization with associated PnP services,
device drivers, and device proxy,
– Generic C&DA Service API that can be used by onboard
applications, and
– Standard C&DA service protocol based on common
M&C protocol.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 17
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
SOIS: C&DA Recommendations, contd
• Develop an agreed set of C&DA ancillary services
for use by the C&DA service. Examples are:
– Provide DN- EU unit conversion
– Data aggregation, fusion, and analysis
– Data monitoring and limit checking
– Data history and summation
– Data repository and management
– Logical device name to physical address mapping
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 18
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
BACKUP SLIDES
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 19
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Command and Data Acquisition Service
• A Plug & Play Service maps actual device characteristics onto the
virtual device model. It may use information read directly from the
device, ala USB or IEEE 1451, or may use a table driven approach to
identify specific device characteristics.
• Device characteristics may include: attributes, engineering units,
variables, parameter arrangement & relationships and calibration
information.
• The C&DA services may be called by other onboard services, such
as the S/C Monitor and Control Service.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 20
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Introduction
•
•
•
•
•
•
10 May 2004
This presentation proposes an architecture to be used as the
basis for developing standards for Spacecraft Monitor and Control
(SM&C).
We assume that Monitor and Control systems are a general class
of applications and that common approaches for building such
services systems can be employed.
SM&C systems are a special case that must deal with the typical
issues encountered while operating systems in space.
We present a view of the common monitor and control pattern and
then demonstrate how it may be applied in space operations.
A typical set of space applications services that may use this
framework is then described. including both ground based and
flight services. This includes the work being done in MOIMS and
in SOIS.
A proposed allocation of responsibility to these two working
groups is provided.
System Engineering Area - System Architecture Working Group
PS, et al Page 21
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Architecture Study
• Provide a context for discussion of end to end
spacecraft/ground control architecture, including:
– SEA Reference Architecture for Space Data
Systems (RASDS)
– MOIMS Spacecraft Monitor & Control Service
– SOIS Command and Data Acquisition Service
• Considerations:
– End to End Flight/ground architecture
– Extensibility
– Definition of functionality
– Definition of interfaces
– Allocation of responsibility
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 22
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
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:
Control
Center
Ground
10 May 2004
Central
Data
Handling
Payload
Processor
Device
Spacecraft
System Engineering Area - System Architecture Working Group
PS, et al Page 23
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Controller and Target Pattern
• In the string, each pair of adjacent elements can be considered as a
pair of controller and target elements.
– 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.
Control
Controller
Target
Monitor
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 24
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Standard for Describing Targets
• 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).
• Objects described with the standard method will be used by
any piece of software that can monitor and control the
targets, but they shall be managed independently of the
software that use them.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 25
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
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.
Control
Observatio
n
Controller
10 May 2004
Monitor
Spacecraft
Target/
Instrument
Controller
Control
Monitor
System Engineering Area - System Architecture Working Group
Instrument
Target /
Component
Controller
PS, et al Page 26
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
MOIMS: Spacecraft Monitor & Control (SM&C)
• Spacecraft Monitor & Control (SM&C) is an
application of generic M&C concepts to an end to
end spacecraft monitor & control domain.
• SM&C provides a framework for the monitoring
and controlling of a variety of different spacecraft
functions.
• The SM&C functions may all be controlled from the
ground, but some may be invoked autonomously
on the spacecraft.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 27
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
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
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 28
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
End-to-End SM&C w/ Example Comm Protocols
Ground
S/C
Model
SPP=Space
Packet
Protocol
10 May 2004
Spacecraft
SM&C
Application
SM&C
Application
SM&C
Service Agent
SM&C
Service Agent
TCP/IP,
UDP/IP or SPP
TCP/IP,
UDP/IP or SPP
Space Data Link
Space Data Link
RF & Mod
RF & Mod
System Engineering Area - System Architecture Working Group
PS, et al Page 29
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
End-to-End SM&C w/ Relay Orbiter
Spacecraft
Ground
S/C
Model
SM&C
Service Agent
Relay
Orbiter
IP Router
TCP/IP
10 May 2004
SM&C
Application
SM&C
Application
SM&C
Service Agent
TCP/IP
Space Data Link
Space Data Link
Space Data Link
Space Data Link
RF & Mod
RF & Mod
RF & Mod
RF & Mod
System Engineering Area - System Architecture Working Group
PS, et al Page 30
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Command and Data Acquisition Service
•
C&DA is a core SOIS service that provides low overhead access to
read data from simple sensors and to write to simple hardware
interfaces.
•
C&DA is intended to provide the means to access sensors, effectors,
and transducers that are connected via a number of different
physical means and deployed in a variety of topologies, including
hierarchical configurations.
•
C&DA implements the common M&C Protocol Services in order to
communicate with other control applications.
•
C&DA also uses the common M&C Protocol Services to
communicate with devices it controls
– Simplest devices may use a proxy to implement M&C functions and
protocols
– More capable devices may directly implement M&C functions and
protocols
•
10 May 2004
Extended C&DA functions may be provided by a set of related
services that perform data fusion, simple analysis, limit checking
and results storage for access by other onboard services.
System Engineering Area - System Architecture Working Group
PS, et al Page 31
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Simplest On-board C&DA
Proxy agent for simplest transducer
Controller
SM&C
Service Agent
Device
Model
C&DA
Application
Device
Device
Proxy / Driver
Simplest
Transducer
Onboard
Data Link
Onboard
Data Link
Onboard
Physical
Onboard
Physical
Device Virtualization
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 32
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Simple On-board C&DA
Smart Transducer
Controller
SM&C
Service Agent
Device
Model
10 May 2004
C&DA
Application
Device
Device
Driver
Transducer
Onboard
Data Link
Onboard
Data Link
Onboard
Physical
Onboard
Physical
System Engineering Area - System Architecture Working Group
Device
Virtualization
PS, et al Page 33
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
SOIS: Command and Data Acquisition Service
•
C&DA provides low overhead access to read data from simple
sensors and to write to simple hardware interfaces
•
Provides access to any sensor or effector to any user
•
Six extended capability sets:
– Engineering Unit Conversion: conversion of raw sensor data
(digital number) into a specific quantity with engineering units
– Data Monitoring: comparing of monitored sensors against
certain limits, such as red and yellow limits
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 34
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
SOIS: Command and Data Acquisition Service
• Six extended capability sets (contd.):
– Data Product Acquisition: data from multiple sensors are
accessed with a single read command, and the resulting product
is a result of calculations based on data from the multiple
sensors
– Data Pooling/Data Base: collection of data from sensors into a
data pool (or data base) of recent readings
– Device Virtualization: where devices are read and controlled
by using a virtual generic device image or model
– Device Access: conversion of user- supplied logical address
into the network address, allowing device to be addressed from
anywhere in the network
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 35
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
C&DA Deployments
• C&DA functions are expected to be executed within a single
spacecraft
• C&DA may have to operate over a variety of onboard links and
underlying connectivity topologies
– Sensors/Effectors directly connected to a data link
– “Smart” sensors/effectors connected via some data link or
networking protocol
– Sensors/Effectors connected to a remote processor, hub or
interface device
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 36
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
C&DA Hierarchical Deployment
Spacelink
Spacelink
Interface
Device
High-Speed Payload Data N/W
Data Mass
Storage
Device
Spacecraft
Executive
Spacecraft Command
& Control N/W
Subsystem B
Subsystem A
Processor
Subsystem A
Subsystem B
Processor
Payload
Processor
Payload Command & Control N/W
Subsystem Command & Control N/W
Remote
Interface
Devices
Field Bus
Field Bus
Remote
Interface
Devices
Science
Sensor
Assembly
Engr I/F
Engr I/F
Engineering
Device
Remote
Interface
Devices
Engr I/F
Remote
Interface
Devices
Science Payload
Field Bus
= Sensors and Effectors
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 37
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Command and Data Acquisition Service
Direct Data Link Access
Control Node
Data
Repository
Data Product
Acquisition
DN- EU Conv
Data
Monitoring
C&DA
PnP
Service
Device
Virtualization
10 May 2004
Device
Proxy / Driver
Transducer
on Data Link
Transducer
Data Link
Data Link
Physical
Physical
System Engineering Area - System Architecture Working Group
PS, et al Page 38
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Command and Data Acquisition Service
TCP/IP Network Access to “Smart Device”
Control Node
Data
Repository
Data Product
Acquisition
DN - EU Conv
Data
Monitoring
C&DA
PnP
Service
“Smart” Device
Device
Driver
10 May 2004
Transducer
TCP/IP
TCP/IP
Data Link
Data Link
Physical
Physical
System Engineering Area - System Architecture Working Group
Device
Virtualization
PS, et al Page 39
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Command and Data Acquisition Service
Using MTS to access device on another node
Control Node
C&DA link to remote device uses remote
C&DA agent connected by MTS which
provides the message transport function
Data
Repository
DN-EU Conv
Data Product
Acquisition
Remote C&DA & Device
On Remote Node
Data
Monitoring
C&DA
MTS
Remote
C&DA
MTS
PnP
Service
Device
Driver
Device
Virtualization
10 May 2004
TCP/IP
TCP/IP
Data Link
Data Link
Physical
Physical
System Engineering Area - System Architecture Working Group
Transducer
PS, et al Page 40
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
C&DA Device Virtualization
• 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.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 41
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
C&DA Device Virtualization Study
• JPL Study: Investigate device models
- JPL RTC Framework
• The Real-time Control software (RTC) was developed as a
toolkit for building optical interferometers. It is used in the
Keck Interferometer, as well as in several testbeds
sponsored by the SIM Flight Project http://rtc.jpl.nasa.gov
- SensorML
• Sensor Modeling Language (SensorML) http://vast.uah.edu/SensorML/
-
10 May 2004
IEEE 1451 TEDS (device attributes)
• "Smart Transducers" with Transducer Electronic Data Sheet
(TEDS) automatically set their own parameters. This
standard is "to make it easier for transducer manufacturers
to develop smart devices and to interface those devices to
networks, systems, and instruments by incorporating
existing and emerging sensor and networking
technologies." - http://ieee1451.nist.gov.
System Engineering Area - System Architecture Working Group
PS, et al Page 42
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
C&DA Device Virtualization
Plug & Play Service:
Provides means for
mapping actual device
capabilities (device
announced or table
driven) onto virtual
device model
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 43
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
C&DA Device Virtualization
Device Proxy:
Implements virtual device
model for specific
transducer & link.
Encapsulates the device
driver.
Real
Device
10 May 2004
System Engineering Area - System Architecture Working Group
Transducer: Physical
sensor or effector
connected via some link
(physical or RF)
PS, et al Page 44
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Architecture Study Summary
• Monitor & Control (M&C) provides a generic pattern for
the management of one function (the target) by another
function (the controller).
• Standard interfaces (API & protocol) may be defined to
implement this generic class of services.
• Application and device specific services may be
implemented by adapting this standard framework and
approach.
• Spacecraft M&C (SM&C) is an application of this M&C
approach that provides end to end services between flight
and ground elements.
• There is a typical set of services that are used in the
SM&C domain to control, manage and monitor onboard
elements from the ground, and optionally from other
flight elements.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 45
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Architecture Study Summary
• Onboard Command and Data Acquisition (C&DA) service is a
basic service to provide access to sensor data and to control
simple effectors.
• C&DA may use a set of ancillary functions to provide data
analysis, aggregation and storage functions on - board the
spacecraft.
• C&DA is a basic function that may be called by Spacecraft
level M&C to access and control simple sensors and effectors.
• C&DA can use the same basic M&C protocol and control
structures as SM&C, but with different application level
commands and different target models.
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 46
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Spacelink
Spacelink
Interface
Device
High-Speed Payload Data N/W
Data Mass
Storage
Device
Spacecraft
Executive
Spacecraft Command
& Control N/W
Subsystem B
Subsystem A
Processor
Subsystem A
Subsystem B
Processor
Payload
Processor
Payload Command & Control N/W
Subsystem Command & Control N/W
Remote
Interface
Devices
Field Bus
Remote
Interface
Devices
Science
Sensor
Assembly
Engr I/F
Engr I/F
Engineering
Device
Remote
Interface
Devices
Engr I/F
Remote
Interface
Devices
Science Payload
Field Bus
Field Bus
= Sensors and Effectors
10 May 2004
System Engineering Area - System Architecture Working Group
PS, et al Page 47
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Spacelink
Spacelink
Interface
Device
Spacecraft
Communications
and Control
High-Speed Payload Data N/W
Data Mass
Storage
Device
Spacecraft
Executive
Spacecraft Command
& Control N/W
Subsystem/Payload
Control
Subsystem A
Processor
Subsystem B
Processor
Payload
Processor
Payload Command & Control N/W
Subsystem Command & Control N/W
Field Bus
10 May 2004
Remote
Interface
Devices
Field Bus
Remote
Interface
Devices
Science
Sensor
Assembly
Engr I/F
Engineering
Device
Remote
Interface
Devices
Engr I/F
Sensors
and
Effectors
Remote
Interface
Devices
Engr I/F
Remote
Data
Collection
Field Bus
System Engineering Area - System Architecture Working Group
PS, et al Page 48
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Simple On-board C&DA
Smart Transducer
Controller
Device
Model
Device
C&DA
Application
Transducer
SM&C
Service Agent
10 May 2004
Onboard
Data Link
Onboard
Data Link
Onboard
Physical
Onboard
Physical
System Engineering Area - System Architecture Working Group
PS, et al Page 49
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
CCSDS System Engineering Area (SEA)
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
Scenario 1: Control of a Payload/Subsystem from the
Ground
Controller
Target
App Specific
Msgs
Ground Control
Center Apps
SM&C
Ground
Station
Payload or
Subsystem Apps
C&DH
System
SM&C
PDUs
UDP
UDP
IP
Space
Data
Link
10 May 2004
SM&C
IP
Space
Data
Link
IP
Space
Data
Link
Space
Data
Link
On-board
Bus
System Engineering Area - System Architecture Working Group
IP
On-board
Bus
PS, et al Page 50
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Scenario 2: Control of a Payload/Subsystem from the Data
Handling Subsystem
10 May 2004
C&DH
System
(Controller)
Payload or
Subsystem
(Target)
SM&C
SM&C
UDP
UDP
IP
IP
On-board
Bus
On-board
Bus
System Engineering Area - System Architecture Working Group
PS, et al Page 51
INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE
Q ui ck Ti m e ™ an d a T I FF ( U nc om p r es se d) de co m pr e ss or ar e n ee de d t o se e t hi s p i ct u re .
CCSDS System Engineering Area (SEA)
Scenario 3: Control of a Device from an Onboard Processor
10 May 2004
Onboard
Processor
(Controller)
Device
(Target)
SM&C
SM&C
On-board
Bus
On-board
Bus
System Engineering Area - System Architecture Working Group
PS, et al Page 52