1. PS, et al Page 1 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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

2. PS, et al Page 2 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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. MOIMS: Spacecraft Monitor & Control (SM&C)

3. PS, et al Page 3 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Example Specific Spacecraft M&C Applications Station M&C Flight Dynamics OB Software Management Directive Management Instrument M&C Telecom M&C OB Flight Dynamics OB Software Management OB Directive Execution OB Instrument M&C Standard services SM&C Service Agent App Specific Msgs SM&C PDUs SpacecraftGround Command & Data Acq Storage Management Standard services SM&C Service Agent

4. PS, et al Page 4 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Example M&C Standard Protocol Services 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

5. PS, et al Page 5 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Example SM&C Protocol Services 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 Send Confirmed directiveFile Timed Send directiveExecution Immediate Send Confirmed SWLoad Triggered Send instrumentLoad Immediate Read unConfirmed instrumentState Immediate Read directiveExecutionState Immediate Read SWLoadVerification Immediate Read telecomState Immediate Trigger Confirmed SWLoad Trigger directiveExecution Immediate Trigger Confirmed SWLoad Indicate SWLoadComplete Indicate SWLoadVerificationComplete Indicate telecomSystem1Off Indicate TCM37Complete Event OBCDump Event observation4357Complete Event telecomSystemFault SM&C Examples

6. PS, et al Page 6 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group General SM&C Connectivity Model Target Model SM&C Service Agent Controller SM&C Application Comm. Protocols Target SM&C Service Agent SM&C Application Comm. Protocols

7. PS, et al Page 7 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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).

8. PS, et al Page 8 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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.

9. PS, et al Page 9 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Command and Data Acquisition Service Service Elements C&DA PnP Service DN - EU Conv Data Product Acquisition Data Monitoring Data Repository Transducer Device Access: Conversion of user- supplied logical address into a physical address Device Driver Name/Addr Mapping Engineering Unit Conversion: Conversion of raw sensor data into engineering units Data Product Acquisition: Data from multiple sensors are accessed with a single request and data products are produced Data Monitoring: Comparison of monitored sensor data against red and yellow limits Device Virtualization: Devices are read and controlled using a virtual generic device image or model. May be implemented in Driver or in Transducer itself. Data Repository: Collection of data from sensors into a data base of recent readings Plug & Play Service: Provides means for mapping actual device capabilities (device announced or table driven) onto virtual device model Transducer: Physical sensor or effector connected via some link (physical or RF) Device Driver: Implements virtual device model for specific transducer & link Device Virtualization

10. PS, et al Page 10 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Command and Data Acquisition Service Relationship to Monitor & Control Service C&DA PnP Service DN - EU Conv Data Product Acquisition Data Monitoring Data Repository Transducer Device Driver Name/Addr Mapping Device Virtualization Mon & Con Service Spacecraft Mon & Con Service: S/C service to control, monitor and manage resources, accept ground Data System (GDS) requests and supply responses Command and Data Acquisition Service: send commands to transducers, read, process, and store results, perform limit checking Standard M&C Protocol: Used by both the SM&C and C&DA services. Provides common communication for monitor & control.

11. PS, et al Page 11 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Example C&DA Protocol Services 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 Send Confirmed sensorDirective Immediate Send effectorConfigParam Timed Send sensorDirective Triggered Send Confirmed FPGALoad Triggered Read unConfirmed sensorState Immediate Read effectorExecutionState Immediate Read transducer Immediate Trigger Confirmed FPGALoad Trigger effector Immediate Indicate FPGALoadComplete Indicate FPGALoadVerificationComplete Indicate effectorExecutionComplete Indicate sensorDirectiveTriggered Event overTempDetected Event transducerValue Event sensorFault Event effectorOffLine C&DA Examples

12. PS, et al Page 12 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group SM&C Service Agent (Operations Concept) (Currently) Un-standardized Application Specific Messages Spacecraft Standard Services OB SM&C Service OB Directive Execution OB Instrument M&C OB Telecom M&C OB Software Management OB Directive Management OB Flight Dynamics MOIMS Domain SOIS Domain C&DA Relationship to Monitor & Control Service OB Command & Data Acq Storage Management

13. PS, et al Page 13 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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). Relationship Between SOIS C&DA and MOIMS SM&C Services

14. PS, et al Page 14 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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 Standardized Monitor & Control Service

15. PS, et al Page 15 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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.

16. PS, et al Page 16 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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)

17. PS, et al Page 17 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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.

18. PS, et al Page 18 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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 SOIS: C&DA Recommendations, contd

19. PS, et al Page 19 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group BACKUP SLIDES

20. PS, et al Page 20 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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. Command and Data Acquisition Service

21. PS, et al Page 21 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Introduction 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.

22. PS, et al Page 22 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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

23. PS, et al Page 23 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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

24. PS, et al Page 24 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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. ControllerTarget Control Monitor

25. PS, et al Page 25 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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.

26. PS, et al Page 26 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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

27. PS, et al Page 27 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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.

28. PS, et al Page 28 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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

29. PS, et al Page 29 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group End-to-End SM&C w/ Example Comm Protocols S/C Model SM&C Service Agent Ground SM&C Application TCP/IP, UDP/IP or SPP Spacecraft SM&C Service Agent SM&C Application SPP=Space Packet Protocol Space Data Link RF & Mod TCP/IP, UDP/IP or SPP Space Data Link RF & Mod

30. PS, et al Page 30 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group End-to-End SM&C w/ Relay Orbiter S/C Model SM&C Service Agent Ground SM&C Application TCP/IP Spacecraft SM&C Service Agent SM&C Application Space Data Link RF & Mod TCP/IP Space Data Link RF & Mod Relay Orbiter Space Data Link RF & Mod IP Router Space Data Link RF & Mod

31. PS, et al Page 31 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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 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.

32. PS, et al Page 32 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Simplest On-board C&DA Proxy agent for simplest transducer Device Model Controller Device Onboard Data Link Onboard Physical Onboard Data Link Simplest Transducer Device Proxy / Driver SM&C Service Agent Onboard Physical C&DA Application Device Virtualization

33. PS, et al Page 33 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Simple On-board C&DA Smart Transducer Controller Device Onboard Data Link Onboard Physical Onboard Data Link Device Driver Onboard Physical Transducer Device Model SM&C Service Agent C&DA Application Device Virtualization

34. PS, et al Page 34 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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

35. PS, et al Page 35 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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 SOIS: Command and Data Acquisition Service

36. PS, et al Page 36 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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

37. PS, et al Page 37 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Spacelink Interface Device Spacecraft Executive Subsystem A Processor Subsystem B Processor Payload Processor Data Mass Storage Device Remote Interface Devices Remote Interface Devices Remote Interface Devices Remote Interface Devices Engineering Device Science Sensor Assembly Spacelink = Sensors and Effectors Subsystem A Subsystem B Science Payload Engr I/F High-Speed Payload Data N/W Spacecraft Command & Control N/W Subsystem Command & Control N/W Payload Command & Control N/W Field Bus C&DA Hierarchical Deployment

38. PS, et al Page 38 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Command and Data Acquisition Service Direct Data Link Access Data Link Physical Data Link Physical Transducer PnP Service C&DA DN- EU Conv Data Product Acquisition Data Monitoring Data Repository Transducer on Data Link Device Proxy / Driver Device Virtualization Control Node

39. PS, et al Page 39 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Command and Data Acquisition Service TCP/IP Network Access to “Smart Device ” Data Link Physical Data Link Physical TCP/IP PnP Service Device Driver C&DA DN - EU Conv Data Product Acquisition Data Monitoring Data Repository “Smart” Device Transducer Device Virtualization Control Node

40. PS, et al Page 40 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Command and Data Acquisition Service Using MTS to access device on another node C&DA DN-EU Conv Data Product Acquisition Data Monitoring Data Repository Data Link Physical Data Link Physical TCP/IP MTS PnP Service Remote C&DA Transducer Device Driver Remote C&DA & Device On Remote Node C&DA link to remote device uses remote C&DA agent connected by MTS which provides the message transport function Device Virtualization Control Node

41. PS, et al Page 41 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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. C&DA Device Virtualization

42. PS, et al Page 42 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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/ - 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.

43. PS, et al Page 43 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group C&DA Device Virtualization Plug & Play Service: Provides means for mapping actual device capabilities (device announced or table driven) onto virtual device model

44. PS, et al Page 44 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Real Device Transducer: Physical sensor or effector connected via some link (physical or RF) Device Proxy: Implements virtual device model for specific transducer & link. Encapsulates the device driver. C&DA Device Virtualization

45. PS, et al Page 45 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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.

46. PS, et al Page 46 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group 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. Architecture Study Summary

47. PS, et al Page 47 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Spacelink Interface Device Spacecraft Executive Subsystem A Processor Subsystem B Processor Payload Processor Data Mass Storage Device Remote Interface Devices Remote Interface Devices Remote Interface Devices Remote Interface Devices Engineering Device Science Sensor Assembly Spacelink = Sensors and Effectors Subsystem A Subsystem B Science Payload Engr I/F High-Speed Payload Data N/W Subsystem Command & Control N/W Payload Command & Control N/W Field Bus Spacecraft Command & Control N/W

48. PS, et al Page 48 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Spacelink Interface Device Spacecraft Executive Subsystem A Processor Subsystem B Processor Payload Processor Data Mass Storage Device Remote Interface Devices Remote Interface Devices Remote Interface Devices Remote Interface Devices Engineering Device Science Sensor Assembly Spacelink Sensors and Effectors Engr I/F Remote Data Collection Subsystem/Payload Control Spacecraft Communications and Control High-Speed Payload Data N/W Subsystem Command & Control N/W Payload Command & Control N/W Field Bus Spacecraft Command & Control N/W

49. PS, et al Page 49 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Simple On-board C&DA Smart Transducer Device Model SM&C Service Agent Controller C&DA Application Device Transducer Onboard Physical Onboard Data Link Onboard Physical Onboard Data Link

50. PS, et al Page 50 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Scenario 1: Control of a Payload/Subsystem from the Ground Ground Station C&DH System SM&C UDP IP Space Data Link IP SM&C UDP IP Ground Control Center Apps Payload or Subsystem Apps ControllerTarget App Specific Msgs SM&C PDUs On-board Bus On-board Bus Space Data Link Space Data Link Space Data Link

51. PS, et al Page 51 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Scenario 2: Control of a Payload/Subsystem from the Data Handling Subsystem C&DH System (Controller) Payload or Subsystem (Target) SM&C UDP IP On-board Bus SM&C UDP IP On-board Bus

52. PS, et al Page 52 CCSDS System Engineering Area (SEA) INTERPLANETARY NETWORK AND INFORMATION SYSTEMS DIRECTORATE 10 May 2004 System Engineering Area - System Architecture Working Group Scenario 3: Control of a Device from an Onboard Processor Onboard Processor (Controller) Device (Target) SM&C On-board Bus On-board Bus SM&C