Transcript A Proposal for a Cross Support Service Architecture

A Proposal for a Cross Support
Service Architecture
Takahiro Yamada (JAXA/ISAS)
Narita Kaneaki [JAXA]
January, 2007 (Issue b)
Editorial comment
Peter Shames,
3 April 2007
1
BASIC CONCEPTS
2
Purposes of the Cross Support Service Architecture



A common architectural framework for cross support services is
needed, with which
 Requirements for cross support can be stated in a common
way;
 Core services and interfaces (which are common to many
agencies) can be specified.
 Agency-specific extensions can be accommodated.
 Priority of the architecture core elements can be assessed.
 Inter-agency collaborative development can be on a solid
basis.
With this framework, coordination and negotiation for interagency cross support can be more efficient.
It will facilitate better planning and interface development for
collaborative missions between agencies.
3
An example: ESA-JAXA/ISAS BepiColombo Mission
MPO
MPO+MMO data
MMO
MPO+MMO data
ESA/Cebreros
JAXA/Usuda
BepiColombo
MOC
SLE Gateway
MMO Ops
System
MMO Ops
System
ESA
ESOC
JAXA/ISAS
SSOC

ESA provides JAXA/ISAS with space and ground services.
 JAXA/ISAS provides ESA with ground services.
4
Cross Support Service Architecture (1/2)


The cross support service architecture (CSSA) is a standard
architecture for cross support service systems.
It is the framework that defines standard services, interfaces,
and their relationships, providing guidance to:
 Service providers
 Ground assets (e.g. GN, ESTRACK, DSN)
 Space assets (e.g. DRS, Lunar relay, Mars relay)
 Service users: flight missions
 Space assets (e.g. Spacecraft, landed vehicles)
 Ground assets (e.g. Mission Operations Center)
5
Cross Support Service Architecture (2/2)

The cross support service architecture employs the conventional
“service-provider/service-user” model to include both space and
ground users.
Space
Service
Users

Space
Services
Cross Support
Service System
(Service provider)
Ground
Services
Ground
Service
Users
The scope of the architecture is limited to four views:
 Service View
 Physical View
 Communications View
 Enterprise View
6
Definitions:
Cross Support Service Systems/Elements



A cross support service system (CSSS) is defined as a set of
cross support service elements that are managed by a single
authority with a single set of management policies.
A cross support service element (CSSE) is defined as a physical
element that can provide one or more cross support services to
any space mission element of any space agency provided that
the customer element conforms to the technical interface
specifications and management policies specified for the CSSE.
A cross support service element can be an element on the
surface of a heavenly body (e.g., Earth, the Moon, and Mars),
an element orbiting around a heavenly body, or an element in
cruise through space.
7
Examples of Cross Support Service Systems

The following are some examples of Cross Support Service
Systems and Cross Support Service Elements.
Cross Support Service System
(Examples)
Cross Support Service Elements
(Examples)
Deep Space Network
Deep space stations
A network control center
Space Network
Tracking and data relay satellites
A network control center
Lunar Network
Lunar relay orbiters
Mars Network
Mars relay orbiters
Ground Network
Tracking stations
8
Cross Support Service Element Basic Configuration
 A cross
support service element has two interfaces (or two sets
of interfaces).
 The interface (or the set of interfaces) closer to the space user
element is called the space side interface
 The interface (or the set of interfaces) closer to the ground
user element is called the ground side interface
Space side interface
of CSSE 1
Space
User
Element
Space side interface
of CSSE 2
CSSE
S1
CSSE
2
Ground side interface
of CSSE 1
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
Ground
User
Element
Ground side interface
of CSSE 2
9
SERVICE VIEW
10
Service View


The Service View of this architecture is used to describe
functional characteristics of the services provided by cross
support service systems and cross support service elements.
Specifically, it describes:
 Functional/performance characteristics of services,
 Methods and/or standards for using services,
 Methods and/or standards for managing services,
 Etc.
Service Management Interface
Service
Utilization
Management
Service
Provision
Management
Service
Provision
CSSE
•
•
Service Interface
Service
Utilization
User Element
11
Types of Cross-Support Services
1. Forward delivery services:
• Command ra diation service
• Command d elivery service
5. Video services:
• Video broa dcast service
• Video enha ncement service
2. Return delivery services:
• Bit stre am service
• Frame service
• Packet service
• Tele metry file service
6. Voice service
3. Tracking services:
• Raw radio metric measurements service*
• Validated radio metric data service
• Delta-DOR/VLBI service
• Optome tric data service
• Position Determination Service
4. Time services:
• Time dis tribution service
• Time sync hroniz ation service
• Spacecraft time correlation service
7. Beacon tone service
8. Ground communications services:
• Ground c ommunications circuit service
• Ground net work service
9. End-to-end network service
10. Launch service
• Range Safety Service
• Launch veh icle telemetry
11. LEOP services
12. Spacecraft emergency service
13. Spacecraft search/rescue services
14. Network security services
* A type of service that is provided only in exceptional cases.
12
Example of Service View
(CSSE Providing Delivery Services)
Cross Support
Service Element
Online Forward
Delivery Service
Offline Forward
Delivery Service
Space
User
Element
Ground
User
Element
Online Return
Delivery Service
Offline Return
Delivery Service
Service Interfaces
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
Service Interfaces
13
Service Attributes of CSSS/CSSE

Each Service provided by a Cross Support Service
System/Element has the following service attributes.
Attribute
Typical values
Direction
Forward, Return
Delivery Mode (Latency)
Online,
Offline (Store & forward)
Quality of service
Timely, Complete, …
Data units delivered
Frames, Packets, Files, …
Online data selection criteria
SCID, VCID, APID, IP address,
…
Offline data selection criteria
Reception times, Service
Instance ID, …
Ground side service protocol
SLE, NASCOM, None, …
14
Example of Service View
(Service Management)
Cross Support
Service Element
Online Forward
Delivery Service
Offline Forward
Delivery Service
Cross Support
Service Element
for Provision
Management
Service
Provision
Management
Service
Utilization
Management
Online Return
Delivery Service
Offline Return
Delivery Service
Internal Service Control Interfaces
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
Service
Management
Interface
15
Service Management Attributes of CSSS/CSSE

Each Cross Support Service System/Element has the following
service management attributes.
Attribute
Typical values
Location of Service Provision
Management
Location, Network address, …
Service Management
Interactions
Online protocol, File transfer, Email exchange, …
Service Management Protocol
SLE SM, SNMP, FTP, SMTP, …
16
Example: Service View of Deep Space Network
DSCC
Online Forward
Delivery Service
Space
User
Element
Ground
User
Element
Online Return
Delivery Service
Offline Return
Delivery Service
Other services were omitted from this diagram.
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
17
Example: Service Attributes of Deep Space Network
Online Forward Delivery Service
Forward or Return
Forward
Online or Offline
Online
Quality of Service
Complete
Data units delivered
CLTUs
Online Data selection criteria
None
Ground Side Service Protocol
SLE FCLTU
Online Return Delivery Service
Forward or Return
Return
Online or Offline
Online
Quality of Service
Complete or
Timely
Data units delivered
Frames
Online Data selection criteria
VCID
Ground Side Service Protocol
SLE RAF,
RCF
Offline Return Delivery Service
Forward or Return
Return
Online or Offline
Offline
Quality of Service
Complete
Data units delivered
Frames
Offline Data selection criteria
VCID,
Reception
Time
Ground Side Service Protocol
SLE RAF,
RCF
18
Example: Service View of Mars Network
Mars Odyssey/MRO
Online Forward
Delivery Service
Space
User
Element
Offline Forward
Delivery Service
Ground
User
Element
Online Return
Delivery Service
Offline Return
Delivery Service
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
19
Example: Service Attributes of Mars Network
Online Forward Delivery Service
Online Return Delivery Service
Forward or Return
Forward
Forward or Return
Return
Online or Offline
Online
Online or Offline
Online
Quality of Service
Complete
Quality of Service
Complete
Data units delivered
Bits
Data units delivered
Bits
Online Data selection criteria
None
Online Data selection criteria
None
Offline Forward Delivery Service
Offline Return Delivery Service
Forward or Return
Forward
Forward or Return
Return
Online or Offline
Offline
Online or Offline
Offline
Quality of Service
Complete
Quality of Service
Complete
Data units delivered
Bits
Data units delivered
Bits
Offline Data selection criteria
None
Offline Data selection criteria
None
20
PHYSICAL VIEW
21
Physical View


The Physical View of this architecture is used to describe the
physical configuration and physical characteristics of cross
support service systems and cross support service elements.
Specifically, it describes:
 Physical location,
 Topology (connectivity),
 Physical medium for accessing,
 Etc.
22
An Example of Physical View
Space
User
Element
CSSS D
CSSS S
CSSE
D1
CSSE
S1
CSSE
S3
CSSE
S2
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
CSSE
D2
Ground
User
Element
23
Physical Attributes of CSSS/CSSE

Each Cross Support Service Element in a Cross Support
Service System has the following physical attributes.
Attribute
Typical values
Element type
On the surface of xx,
Orbiting around yy
Location or Trajectory
Geographical location,
Orbital elements
Space side access medium
RF at Z-band, modulation,
viewperiods, pointing params
Dedicated wired line
Ground side access medium
RF at Z-band, modulation,
viewperiods, pointing params
Dedicated wired line
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
24
Example: Physical Attributes of Deep Space Network
Goldstone DSCC
Element type
On the surface of the Earth
Location
Goldstone, California, USA
Canberra DSCC
Element type
On the surface of the Earth
Location
Canberra, Australia
Madrid DSCC
Element type
On the surface of the Earth
Location
Madrid, Spain
There are attributes for each station (DSS) at each DSCC but they
are omitted here.
25
COMMUNICATIONS VIEW
26
Communications View


The Communications View of this architecture is used to
describe communications protocols used for accessing services
provided by cross support service systems and cross support
service elements.
Specifically, it describes:
 Protocol stacks for accessing services,
 Parameters of protocols used for accessing services,
 Etc.
27
An Example of Communications View
Space
User
Element
Cross Support
Service Element
Ground
User
Element
User
Element
Online Forward
Delivery Service
User
Element
Transport
Protocol
Transport
Protocol
Transport
Protocol
Transport
Protocol
Network
Protocol
Network
Protocol
Network
Protocol
Network
Protocol
Data Link
Protocol
Data Link
Protocol
Data Link
Protocol
Data Link
Protocol
Physical
Protocol
Physical
Protocol
Physical
Protocol
Physical
Protocol
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
28
Communications Attributes of CSSS/CSSE

Each Cross Support Service Element has the following
communications attributes.
Attribute
Typical values
Ground side service protocol
SLE RAF, CLTU, …
Ground side transport protocol
TCP, UDP, …
Ground side network protocol
IP, …
Ground side data link protocol
PPP, …
Ground side physical protocol
ISDN, …
Space side transport protocol
None, TCP, SCPS-TP, …
Space side network protocol
Space packet protocol, IP, …
Space side data link protocol
Space data link protocol, …
Space side coding
Turbo, Reed-Solomon,
Convolutional, BCH, …
Space side carrier frequency
xxxxMHz
Space side modulation
QPSK, PSK-PM, BiPh-PM, …
29
Communications View of Deep Space Network
Space
User
Element
DSS
Ground
User
Element
User
Element
Any
Delivery Service
User
Element
Space Pkt
Protocol
Space Pkt
Protocol
Space Pkt
Protocol
Space Pkt
Protocol
SLE
SLE
Space
Data Link
Protocol
Space
Data Link
Protocol
TCP
TCP
IP
IP
CCSDS
RF&Mod.
CCSDS
RF&Mod.
ISDN or
dedicated
ISDN or
dedicated
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
30
ENTERPRISE VIEW
31
Enterprise View


The Enterprise View of this architecture is used to describe
organizational and administrational features of the services
provided by cross support service systems and cross support
service elements.
Specifically, it describes:
 Organizations that provide services,
 Facilities that deliver services,
 Policies to provide services,
 Contracts to use services,
 Activity for testing the service interface, e.g. compatibility
tests and end-to-end tests
 Documents to use services,
 Pricing information, e.g. reimbursable, quid-pro-quo
 Etc.
32
An Example of Enterprise View
Service Provision Enterprise
CSSE
S1
CSSE
S2
Modified from IOAG / JAXA CSSA,
Jan 2007, rev b
CSSE
S3
Service Utilization Enterprise
Space
User
Element
Ground
User
Element
33
Enterprise Attributes of CSSS/CSSE

Each Cross Support Service System (and its Cross Support
Service Elements) has the following enterprise attributes.
Attribute
Typical values
Agency (or organization) that
owns the CSSS
NASA, ESA, ABC Space
Communications Company, …
Policies for providing services
Available for any science
mission, …
Types of contracts to use the
services
Reimbursable, Cooperative, …
Activity for testing the service
interface
Level of testing support, e.g.
nominal and special tests
Types of documents to use the
services
Service Agreement Document,
Interface Control Document, …
Pricing Information
$xxx/hour + $yyy (fixed)
(Others)
34
Analysis of JAXA Position Paper

The JAXA CSSA approach provides a very useful framework for
describing cross support architectures
 Definitions of terminology
 Viewpoints and representational methods
 Initial set of attributes
 Permits description of cross support architecture from several
viewpoints
 Starting with enterprise level
 Arriving at a deep enough technical level
 Should support presentation of concepts to management and also
allow adequate representation of interface details to define how they
are to be actually implemented
 As presented (with mods) it adheres to the RASDS methodology
 The Service Catalog and attribute sets for interfaces in various
views is a valuable extension, especially for this use
 Enterprise view with facility “cartoons”, ala DODAF OV-1 or SV-1
may be useful as top level view
Provided by Peter Shames
3 April 2007
35
Today’s NASA Network Architecture
Operational View Graphic (OV-1)
DEEP SPACE
NETWORK
MISSIONS
Planetary
Explorations
DSN SERVICES,
INTERFACES,
SPECTRUM
Radio
Astronomy
SPACE
NETWORK
MISSIONS
Space Telescope
Earth Observing
SN SERVICES,
INTERFACES,
SPECTRUM
Space Station
Airborne
Experiments
GROUND
NETWORK
MISSIONS
Space Transportation
GN SERVICES,
INTERFACES,
SPECTRUM
National & DoD
NASA Network Architecture Task
DSN Status, Chuck Tang, Aerospace
23 September 2004
Educational
Users
36
Deep Space Network – Interfaces
System Interface Description (SV-1)
USER SPACE LINK
INTERFACES
•Radio Astronomy
•Goldstone Solar
System Radar
•VLBI
Deep Space Missions
70 m
L-Band
S-Band
X-Band
34 m HEF
BWG
X-Band
34 m BWG
S-Band
X-Band
Ka-Band
34 m HS
BWG
S-Band
26 m
S-Band
Parkes Radio
Observatory,
Australia
Australian
Commercial Carrier
MDSCC
GDSCC
CDSCC
•DSN Resource Allocation
•DSN Scheduling
•DSN Predicts
•DSN SOEs
•Remote Operations
Support Area (ROSA)
•JPL Institutional Flight Projects
Deep Space Operations
Control Center (DSOCC)
GSFC Flight Dynamics Facility
JPL Navigation Services
•Central Communications Terminal (CCT)
•Advanced Multi-Mission Operations System
(AMMOS)
•Network Operations Control Team (NOCT)
JPL Institutional LAN
Flight Projects
Commercial Circuits
Inside JPL Firewall
NASA Network Architecture Task
DSN Status, Chuck Tang, Aerospace
23 September 2004
JPL Institutional
Communications
Building 171
(Contractor Facility - 1400 S.
Shamrock Ave. Monrovia, CA)
Radio Metric
Data
Conditioning
(RMDC)
3 Commercial T-1 Circuits
Inside JPL Firewall
Reference: DSMS Telecomm Link Design Handbook (810-005)
37
Backup Materials
38
ISSUES AND NEXT STEPS
39
Technical Issues (1/3)


There are space and ground users for the same service. We
should consider how to specify these two users. (C. Sunshine)
 I think, for a service provided by a CSSE, we should define
 space user, ground user, and service utilization manager,
and
 space side interface, ground side interface, and service
management interface.
What is the CSSE? Is it the whole ground station or the
equipment that provides the service? (J. Pietras)
 In my opinion, a CSSE is any physical element that has
cross support service interfaces. The user element only
needs to know how to use the services through the service
interfaces without any knowledge of the physical
configuration of the element.
40
Technical Issues (2/3)

There is dependency among views. That is, there are some
attributes that depend on the values of attributes defined in other
views. We need to consider how to describe relationships and
dependency among views. We may also need to reconsider the
definition and number of views. (W. Tai)
 I don’t have any clear response at the moment but will
provide one in one month.
41
Technical Issues (3/3)



We need to categorize services (e.g., layering and/or
composition of services). (J. Pietras)
 I haven’t done this due to lack of time but will provide a draft
material in a month.
We need to define the function and a standard set of attributes
for each of the services. (W. Tai)
 I haven’t done this due to lack of time but will provide a draft
material in a couple of months.
The policy and types of agency-to agency agreements should
be elaborated so that they can be used in any MOU. (W. Tai)
 I agree that we need to define a standard set of attributes
that can characterize any type of agency-to-agency
agreement. I will prepare a draft material in one month.
42
Procedural Issues


IOAG does not have any experience in developing standards, a
procedure to develop them, or technical writers who can write
good technical specifications.
For the Cross Support Service Architecture, there is only an
action item, but I do not believe that a high-quality standard can
be generated only as a response to an action item.
43
PROPOSAL TO CREATE A JOINT IOAG-CCSDS WG




We need to establish a special WG consisting of experts on
cross support and standardization from both IOAG and CCSDS
that will review the Cross Support Service Architecture
document generated by IOAG and add any missing contents.
The WG will then be transformed to develop the architecture
standard specification to be published by CCSDS as a standard.
JAXA/ISAS will lead the WG to review the IOAG cross support
service architecture, in the form of an IOAG guidance document,
and later develop the CCSDS cross support service architecture
standard.
This approach ensures continuity of the activity from the IOAG
focus to the CCSDS focus while meeting the need of the IOAG
stakeholders.
44
Tentative Schedule
Milestone Date
Activity and Milestone
Mid 2-2007
Conduct 2 or 3-day working session between Yamada, Narita,
and Tai to complete the key technical areas of the document.
End of 2-2007
Complete the draft version. Issue the draft version to the
IOAG members and the special WG for review.
End of 2-2007
Distribute the template for the agency asset-specific service
attribute table for the IOAG members to fill it out.
End of 4-2007
IOAG members provide completed agency asset-specific
service attribute tables
End of 4-2007
Review completed by the IOAG members and the special WG.
By IOAG-11
meeting 6-2007
date
Complete the “final” version of the IOAG Cross Support
Service Architecture document with accepted comments
incorporated.
IOAG-11 meeting
Present the key features of the architecture and issues
disposition. Obtain endorsement from the IOAG members.
45
Example: Physical View of Mars Network
Mars Network
Space
User
Element
MRO
Mars
Odyssey
Ground
User
Element
46
Example: Physical Attributes of Mars Network
Mars Odyssey
Element type
Orbiting around Mars
Orbit
Orbital elements = xxxxxx
MRO
Element type
Orbiting around Mars
Orbit
Orbital elements = yyyyyy
47
Communications Attributes of Deep Space Network
Deep Space Station
Ground side transport protocol
TCP
Ground side network protocol
IP
Ground side data link protocol
PPP
Ground side physical protocol
ISDN, Dedicated Circuit
Space side transport protocol
None
Space side network protocol
Space packet protocol
Space side data link protocol
Space data link protocol
(TM/TC/AOS)
Space side coding (forward)
BCH
Space side coding (return)
Turbo, R-S, Convolutional
Space side carrier frequency
(forward)
2025-2120MHz,
7145-7190MHz
Space side carrier modulation
(forward)
PM
48
Communications View of Mars Odyssey
Mars Odyssey
Any
Delivery Service
Space
Packet
Protocol
Space
User
Element
Prox-1
Data Link
Protocol
Space
Data Link
Protocol
Prox-1
Physical
CCSDS
RF&Mod.
Ground
User
Element
49
Communications Attributes of Mars Odyssey
Mars Odyssey
Ground side transport protocol
None
Ground side network protocol
Space packet protocol
Ground side data link protocol
Space data link protocol
(TM/TC/AOS)
Ground side coding (forward)
BCH
….
….
Space side transport protocol
None
Space side network protocol
None
Space side data link protocol
Prox-1 data link protocol
Space side coding (forward)
BCH
….
….
50
Communications View of MRO
MRO
Any
Delivery Service
CFDP
Space
User
Element
Space
Packet
Protocol
Prox-1
Data Link
Protocol
Prox-1
Physical
Ground
User
Element
Space
Data Link
Protocol
CCSDS
RF&Mod.
51
Communications Attributes of MRO
MRO
Ground side transport protocol
CFDP
Ground side network protocol
Space packet protocol
Ground side data link protocol
Space data link protocol
(TM/TC/AOS)
Ground side coding (forward)
BCH
….
….
Space side transport protocol
None
Space side network protocol
None
Space side data link protocol
Prox-1 data link protocol
Space side coding (forward)
BCH
….
….
52