1 cross support service architecture takahiro yamada (jaxa/isas) ccsds meeting, heppenheim, germany...
TRANSCRIPT
1
CROSS SUPPORT SERVICE ARCHITECTURE
Takahiro Yamada (JAXA/ISAS)
CCSDS Meeting, Heppenheim, Germany
2 October 2007
2
Purpose of This Presentation
Review the contents of the Cross Support Service Architecture document developed as the response to the following action item assigned to JAXA at IOAG-10. Action Item 6: Develop a framework showing high level
cross-support architecture containing organizational, administrative, and functional features of services for cross-support services.
As the response to action item 6, we distributed to the IOAG members a document that described a framework of cross support service architecture at the end of December 2006.
Since we did not receive any negative comments on the framework document, we proceeded to develop a document that defines the cross support service architecture (IOAG XXX.0-W-1.0), and distributed it to the IOAG members at the beginning of June 2007.
3
BASIC CONCEPTS
4
Cross Support
Cross support is an activity of using resources of one space Agency to support operations of a space mission of another space Agency.
To facilitate cross support, CCSDS developed standard protocols to transfer telecommand and telemetry over space links, which can ensure interoperability between space elements and ground elements belonging to different Agencies.
CCSDS also developed standard services called SLE services to transfer telecommand and telemetry on the ground.
By using these CCSDS protocols and services, interoperability between elements of different Agencies can be guaranteed to some extent, but coordination and negotiation for cross support is still done in mission-specific, labor-intensive ways.
5
Cross Support Service Architecture (1/2)
The Cross Support Service Architecture establishes a common basis for cross support services through the definition of a set of common concepts and terms. It also defines basic cross support service types.
It will facilitate development of cross support systems, description of characteristics of cross support services, documentation of requirements and agreements for cross support.
This will provide 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)
6
Cross Support Service Architecture (2/2)
The cross support service architecture expands the conventional “service-provider/service-user” model to include both space and ground users.
The scope of the architecture is limited to four views: Service View Physical View Communications View Enterprise View
Cross Support Service System
(Service provider)
SpaceServices
GroundServicesSpace
ServiceUsers
GroundServiceUsers
7
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.
8
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 on the ground
9
Simple 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 us
er element is called the space side interface The interface (or the set of interfaces) closer to the ground u
ser element is called the ground side interface
CSSES1
GroundUser
Element
SpaceUser
Element
Space side interface of CSSE 1
Ground side interface of CSSE 1
10
Cascaded Configuration
There are cases in which a space user element and a ground user element are supported by two or more CSSEs.
This figure shows such an example, in which a space user element (a spacecraft) and a ground user element (a spacecraft control center) are supported by CSSE1 (a data relay satellite) and CSSE2 (a ground terminal for the data relay satellite).
CSSE2
CSSE1
GroundUser
Element
SpaceUser
Element
Space side interface of CSSE 1
Space side interface of CSSE 2
Ground side interface of CSSE 1
Ground side interface of CSSE 2
11
SERVICE VIEW
12
Service View
The Service View is used to describe services provided by CSSSs/CSSEs and their functional characteristics, separately from Physical locations where the services are provided (which
are treated in the Physical View), Communications protocols used to access the services
(which are treated in the Communications View), and Organizational or administrational issues involved in using
the services (which are treated in the Enterprise View).
13
Examples of Service View
Cross Support Service Element
Ground User Element
Space User Element
Cross Support Service
Provision
Ground Service
Utilization
Space Service
Utilization
Space User Element
Space Service
Utilization
Cross Support Service Element 1
Cross
Support Service
Provision 1
Ground User Element
Ground Service
Utilization
Cross Support Service Element 2
Cross
Support Service
Provision 2
14
Service Management
Cross Support Service Element
Utilization Management
Element
Cross Support Service
Provision
Service
Utilization Mngmnt Service
Provision Mngmnt
15
Basic Cross Support ServicesCross Support Service Type
Basic Cross Support Service
Forward Delivery Services
Forward Bitstream Delivery Service
Forward CLTU Delivery Service
Forward Packet Delivery Service
Forward File Delivery Service
Return Delivery Services
Return Bitstream Delivery Service
Return Frame Delivery Service
Return Packet Delivery Service
Return File Delivery Service
Cross Support Service Type
Basic Cross Support Service
Tracking Services Radio Metric Data Service
Delta-DOR Service
Orbit Determination Service
Time Service Spacecraft Time Correlation Service
Voice and Video Services
Voice Service
Video Service
Note: 1. IP service is not viewed necessary for the
IOAG cross support purposes other than that for communications in close proximity.
2. The method of “bit stream encapsulation” of the IP over HDLC frame over AOS frame, as suggested by NASA, is not recommended for IOAG cross support purpose.
16
Service Attributes
Each service provided by a CSSS/CSSE is characterized by a set of standard service attributes.
Service attributes for Forward CLTU Delivery Service (example).
Attribute Typical Value s Note s
Delivery Mode Online, Offline See 3.5
Service Access
Method
SLE (Online),
SLE, files (Offline)
Method for accessing the
service from the ground
user element
Data Format
Definition
CCSDS 912.1-B-2 (SLE),
AMMOS SCMF (files)
Format for delivering
CLTUs from the ground
user element
Delivery Latency Less than 125 miliseconds
(Online)
Service Availability 95 % (Nominal), 98% (Critical)
Data Retention Period 14 days Period for which delivered
data is stored.
17
PHYSICAL VIEW
18
Physical View
The Physical View is used to describe
The physical configuration of CSSSs/CSSEs and their physical characteristics, and
The topology and connectivity of the physical elements (including user elements) to support specific space missions.
19
An Example of Physical View
CSSE1 (Mars Relay
Satellite)
Space User Element (Mars Lander)
Ground
User Element (Lander Control
Center)
CSSE2 (Ground Station)
CSSE3 (Ground Station)
20
Physical Attributes
The physical characteristics of each CSSE is characterized by a set of standard physical attributes.
Physical attributes for flight based CSSEs (example).
Attribute Typical Value s Note s
Apogee Height 800 (km)
Perigee Height 600 (km)
Orbital Period 93 (minutes)
Inclination 89 (degrees)
Frequency bands S (forward), S and X (return)
21
COMMUNICATIONS VIEW
22
Communications View
The Communications View is used to describe communications protocols used for accessing cross support services (including service provision management) provided by a CSSS/CSSE.
Its focus, different from that of the Service View, is on the communications interfaces between CSSEs and user elements.
23
An Example of Communications View
Cross Support Service Element
Ground User Element
Space User Element
Cross Support Service
Provision
Ground Service
Utilization
Space Protocol 2
Space Protocol 1
Space Protocol 2
Space Protocol 1
Ground Protocol 2
Ground Protocol 1
Ground Protocol 2
Ground Protocol 1
Space Service
Utilization
24
Communications Attributes
For each of the basic communications protocols, a standard attribute set is provided.
Communications attributes for TC Space Data Link Protocol (example).
Attribute Typical Value s Note s
Transfer Frame
Length
16-1024 Lengths of Transfer Frames
(octets)
Frame Error Control Used, Not Used Whether the Frame Error
Control is use or not
Virtual Channels 8 Number of Virtual
Channels supported
MAPs 8 Number of Multiplexer
Access Points supported
Packet Version
Number
0 Packet Version Numbers
supported (See 7.6 of [12])
25
Combined Tables
In some cases, it is easier to understand the characteristics of the service if the attributes of the communications protocols used to support the service are listed together with the attributes of that service.
The following page contains an example of a table which lists the attributes of the Return Packet Delivery Service together with the attributes of the communications protocols used to support the service.
26
Example of Combined TableCategory Attribute Valu e
Delivery Mode Complete Online, Timely Online,
Offline
Service Access Method SLE (Online),
SLE, files (Offline)
Data Format Definition CCSDS 911.n-B-1 (SLE),
AMMOS SCMF (files)
Delivery Latency Less than 5 seconds (Online)
Service Availability Complete Online, Timely Online,
Offline
Return Packet
Delivery Service
Data Retention Period SLE (Online),
SLE, files (Offline)
Packet Length 16-65542 Space Packet Protocol
APIDs 1024 (max)
Transfer Frame Length 16-1912
Frame Error Control Supported
Virtual Channels 8 (max)
Data Field Contents Packets, VCA_SDU
TM Space Data Link
Protocol
Packet Version Number 0
Convolutional Coding Supported
Randomizer Supported
Turbo Coding Supported
Reed-Solomon Coding Supported
Convolutional Code Rate 1/2, 2/3, 3/4, 5/6, 7/8
Reed-Solomon Error
Correction Capability
8, 16
Reed-Solomon
Interleaving Depth
1, 2, 3, 4, 5, 8
Turbo Nominal Code
Rate
1/2, 1/3, 1/4, 1/6
Turbo Information Block
Length
1784, 3568, 7136, 8920, 16384
TM Synchronization
and Channel Coding
Transfer Frame Length 128-16384
Carrier Frequency 2200-2300 (S-band),
8400-8500 (X-band)
G/T at 45 deg 41.7 (S-band),
53.9 (X-band)
Polarization RCP, LCP
Modulation Type PCM/PM, PCM/PSK/PM
Carrier Modulation Index 0.17-1.57
Subcarrier Frequency 1-2000
Subcarrier Waveform Sine, Square
Symbol rate 8-2200000
RF and Modulation
(Return)
PCM Waveform NRZ-L, NRZ-M, NRZ-S, Biphase-L,
Biphase-M, Biphase-S
27
ENTERPRISE VIEW
28
Enterprise View
The Enterprise View is used to describe processes and rules governing the initiation, negotiation, and agreement between the supported and supporting Agencies for the provision of cross support services.
Differing from the other architecture Views which are technical in nature, it addresses the administrative and contractual aspects of the architecture.
29
An Example of Enterprise View
CSSE 1
Space User
Element
Ground User
Element
CSSE 2
CSSE 3
CSSS
Supporting Agency
Cross Support Service
Agreement
Supported Agency
30
Procedure for Cross Support Service Agreement
1. Each member Agency must specify (1) policies and conditions for providing cross support services, (2) documents used for agreement on cross support services and establishment of cross support interfaces, and (3) pricing information. This information should be documented in a Service Catalogue.
2. If the supported Agency can meet the policies and conditions specified by the supporting Agency, the supported Agency submits necessary documents to request services to the supporting Agency.
3. Both Agencies jointly generate documents specified by the supporting Agency, which must be completed and signed off by the dates agreed upon by both Agencies. (A template for service agreement documents is given on the next pages.)
4. Both Agencies must agree on the types of tests necessary for verifying the cross support interfaces and conduct the tests according to the schedule agreed upon by both Agencies.
31
Template for Service Agreement Documents (1)
Document Number : mmmm
SERVICE AGREEMENT BETWEEN AGENCY_X AND AGENC_Y
FOR PROJECT_Z
Date: YYYY-MM-DD
Version: n.m
Supporting Agency Point of Contact:
Name: FirstName SurName
E-mail: [email protected]
Supported Agency Point of Contact:
Name: FirstName SurName
E-mail: [email protected]
32
Template for Service Agreement Documents (2)
1. Project Information
Supporting Agency Name Agnecy_X
Supported Agency Name Agnecy_Y
Supported Project Name Project_Z
Supported Project Description Planet A Orbiter
2. Support Information
Start of Support Period YYYY-MM-DD
End of Support Period YYYY-MM-DD
Supporting CSSS Name(s) Network_L
Supporting CSSE Name(s) Station_M, Center_N
Supporting CSSE Type(s) Ground Station, Network Control Center
Provided Service Name(s) Forward P Delivery, Return Q Delivery
Space User Element Name ABC Orbiter
Space User Element Type Planet A Orbiter
Ground User Element Name X Space Operations Center
Ground User Element Type Spacecraft Control Facility
Number of Contacts 1/day (nominal), 2/day (contingency),
Contact duration 4-6 hours/contact
33
Template for Service Agreement Documents (3)
3. Document Information
Agency-Agency Agreement Memorandum of Understanding (No. nnn)
High Level Service Agreement This document
Detailed Service Agreement Detailed Mission Requirements (No. ooo)
Space to Ground Interface RFICD (No. ppp)
Ground to Ground Interface GGICD (No. qqq)
4. Testing Information
Interface Test Between Space User Element and CSSE
Required
Interface Test Between Ground User Element and CSSE
Not Required (Already performed for Project W)
End-to-End Data System Test
Required
Operations Readiness Test
Required
5. Pricing Information
Aperture hourly fee: $X.00
Other service fees: $Y.00
Method of service fee attribution:
Reimbursable cash transaction or Quid-pro-quo arrangement
34
NEXT STEPS
35
Next Steps
Cross Support Service Architecture
June 2007 JAXA distributed the draft document.
July-August 2007
IOAG members review the document and provide agency specific attribute tables.
September 2007
JAXA distributes the final document.
Cross Support Service Catalogues
October-December 2007
Using the CSSA document, IOAG members generate service catalogues that describe services they can provide.