CSSM Meeting Summary

CCSDS CSSM Technical Meetings

Pasadena, CA USA

23 – 27 March 2015

Agenda & Coverage at Meeting Conclusion

TIME CSSMCSSM

(Moore 70)

CSSM

(Moore 70)

CSSM

(Moore 70)

CSSM

(Moore 70)

8:45-9:45(Generic) Service

Request Engineering

Inter-

recommendation

tracking concerns,

engineering (inc l

svc agreement

9:45-10:30

Planning Data Book:

Communication

Geometry Review

<Working Session:

Abstract Request

Engineering>

10:30-10:45 Break Break Break Break

10:45-11:15

Service Package

Request Abstract

Model Development

(Extensibility, toward

recommendation)

Trajectory Prediction;

Recommendation

Development;

Planning Data

Protoype

11:15-12:30

Introduction; London

Recap; Interim

Progrfess; Agenda

Approval; Action

Items (Moore 70)

Service Package Result

Abstract Model

(Extensibility, toward

recommendation)

Event Sequencing

Recommendation

Development

Trajectory Prediction

Prototype

12:30-13:30 Lunch Lunch Lunch Lunch Lunch

13:30-:14:30

XML Schema

namespaces and

schema management

Service Package

Request/Service

Package Prototype

14:30-15:30

<Working Session:

Abstract Service

Request Engineering>

Future Services

Planning: Service

Catalog;

15:30-1545 Break Break Break Break Break

15:45-16:30

(Generic) Service

Request Engineering

Update

Generic File Transfer;

recommendation

development

(protocol/directories)

Future Services

Planning:

Accountability Data

16:30-17:30J oint Mtg DDOR/CSSM

WGs coordination

SC-CSTS & F-FRAME;

Management

Consiiderations

Resource

projections

17:30 Adjourn Adjourn Adjourn Adjourn Adjourn

CSSM Agenda, Pasadena Meetings

Monday, March 23 Tuesday, March 24 Wednesday, March 25 Thursday, March 26

CSS Area Closing

Plenary

(Moore 70)

CCSDS Opening

Plenary

(Beckman Institute)

8:45 - 9: 45

Friday, March 27

Configuration

Profile/Service

Agreement; Abstract

Model, Cookie Cutter

"Bake-off"; (toward

recommendation)

CSS Opening Plenary

(Moore 70)

09:55 -- 11:15

Incl introduction to SC-

CSTS, F-FRAME and Off-

line Radiometric data

transfer

SoS: Finalization Plan

Working session as

needed (main items

standard header, any

other updates

needed)

Plenary Session: SC-CSTS,

F-FRAME, TGFT (and

fwd/rtn file) Coordiation;

CSTS project chartering

discussion

Work plan -->

November 2015

meetings

J oint Working Session

with CSTS; functional

resource modeling

Action Items, wrap-

up/conclusion

Work plan -->

November 2015

meetings

All topics addressed;Also briefly addressedManagement services

Simple Schedule of Services Finalization

• Recommendation updated during the meeting to include• Standard header definition worked out• Addition of request reference

• Schema updates in progress

Standard Header Analysis Conclusion

srvMgtMessageType (m)Mandatory; values

governed by Annex SoS BB

originatingOrganization (m)

Mandatory – for those information entities

that “wrap” other CCSDS formats this indicates the party doing the

wrapping

generationTime (m)

Mandatory – for those information entities

that “wrap” other CCSDS formats this indicate the time of wrapping

status (m) [IES]

Mandatory – each information entity

recommendation defines the values to use

version (m) [IES]

Mandatory – each information entity

recommendation defines the values to use

startTime (o) [IES]Optional – each

information entity indicates if used

endTime (o) [IES]Optional – each

information entity indicates if used

purpose (o)

Optional – a general comment field for all

CSSM information entities

description (o)

Optional a general comment field for all

CSSM information entities

Service Package Request Functional Components Model

• White-board engineering discussions; derived an outline, taking into account London sketch for Service Request and draft Planing Request; see result on next slide

• See CWE Spring 2015 meetings folder for further details.• Note – even though this says service package request, this is really

about the abstract service request with application to planning and service package requests

www.ccsds.org

Fwd Offline eSLS Retrieval

OfflinePlanning

Flexibilities and Constraints

Config Modifier

Set/Scenario

Flexibilities and Constraints

Config Modifier

Flexibilities and Constraints

Config Modifier

Set/Scenario

Flexibilities and Constraints

Config Modifier

Output Type

Configuration Profile

Configuration Profile

Configuration Profile

Configuration Profile

Referential Framework

Referential Framework

Referential Framework

Referential Framework

ABSTRACT SERVICE REQUEST : AGREED (META) MODEL AT CONCLUSION OF DISCUSSIONS

Currently only Planning has “two” possible type of outputs, but all requests have an output type.

Output TypeOutput TypeOutput Type

Identification Identification Identification Identification

This allows for the option of referencing a profile or defining it within the request.

Currently we have not identified an application for this component for “offline” types but could be applied for those types and other types if it becomes relevant.

Set/ScenarioSet/Scenario

Flex/Constr may reference the request or service they apply to …

Joint Meeting with DDOR WG

• Reviewed the DDOR WG concept of a service request• Agreed to take an action to look at DDOR service request material and

determine how this maps to the CSSM recommendations• Follow-up with DDOR WG

Configuration Profile/Service Agreement (1/3)

• Reviewed Tech Note on Service component vs IOAG service definition ASC ->

------------IOAG service

v

Aperture

Forward Physical Channel Xmission

Forward Sync &

Channel Encoding

Forward Space Link Protocol Xmission

Return Physical Channel

Reception

Return Sync &

Channel Decoding

Return Space Link Protocol

Reception

SLS Data Delivery

Production

SLS Radiometric

Data Production

Offl ine Data Storage

Data Transfer Services

Forward CLTU M M M M C 1 C 1 C 1 MForward Space

PacketM M M M C2 C2 C2 M

Forward Frame

M M M C3 C5 C5 C5 M

Forward File M M M M C4 C4 C4 M MRAF (online) M M M M MRAF (offl ine) M M M MRCF (online) M M M M MRCF (offl ine) M M M M

ROCF M M M MRUFT (real-

time)M M M M

RUFT (complete)

M M M

Return File M C4 C4 C4 M M M M MValidated

Radiometric M M M M M

Raw Data Radiometric (real-time)

M M M M

Raw Data Radiometric (complete)

M M M M M

Delta-DOR M M M MOpen Loop M M M M

ConditionsC1

C2

C3C4C5

Required if forward link status is required to control production status

Required if forward link status is required to control production status or if the services is running over COPRequired if service is transferring TC Frames or AOS framesRequired if the service is operating in Reliable Transfer Required if the servce is operating in TC Frame mode and forward link status is required to control production status

See tech note for more detail:

http://cwe.ccsds.org/css/docs/CSS-SM/Meeting%20Materials/2015/Spring/ServiceComponentsInServiceProfiles_TechNote-TN-0x03-d2014-08-14.docx

Configuration Profile/Service Agreement (2/3)

Approach to combine service components into service profiles…

Forward Data Delivery

Return Data Delivery

Tracking/Radiometric Data Delivery

To be worked:How are theseCaptured? SANA?

Configuration Profile/Service Agreement (3/3)

…And service components into service profiles into Service Agreement, Configuration Profile Recommendations*

AperturePhysical Channel

Sync and Channel Coding

Space Link

Protocol

SLS Radio Metric Data Production

RF Aperture

CCSDS 401

Forward Physical ChannelTrans-

mission

CCSDS 401 Return

Physical Channel

Reception

TC Sync and

Channel Encoding TC SLP

Rtn TM Sync and Channel

DecodingRtn TM/

AOS SLP

Offline Frame Buffer

SLE Fwd Space Pkt

SLE RAF

SLE RCF

SLE ROCF

Real-Time Radio Metric

Data

TD CSTS

Offline Data

Storage

Data Transfer Services

0..1

CL

CW

s to

Fw

d

Ca

rri e

r a

nd

FO

PC

LC

Ws

to F

OP

TDM Recording

Buffer

SLS Data Delivery

Production

Frame Data Sink

* and likely applicability for Service Catalog and strong relation to SC-CSTS and MD-CSTS

Terrestrial Generic File Transfer (TGFT)

• Reviewed concept presentation from C. Haddow• Made decisions for advancing draft recommendation, including

• Assume DMZ configuration? Yes• WebDAV for protocol ? Yes• Use of Zip? Yes• Use of XFDU? Yes

• Discussed other issue with preliminary decision indicated as follows• Push vs Pull operations: Allow both or restrict? Restrict to push only

as a first cut for review• Rationale: Simplifies recommendation, less options left for ICD

negotiations; WG membership inputs requested (canvassing of agency operations)

• Filename case sensitivity – an issue in that file systems (largely OS dependent) vary re case sensitivity and case preservation; decision pending but it seems that all upper case filenames is the least likely to cause problems (albeit at the expensive readability for humans)

Joint Session, CSTS + CSSM WGs (1/2)

• SC-CSTS (Service Control) and CSSM-ES (Event sequences)• Functional resource model has been updated to include “setable”

parameters – essentially “directives” • Event sequences are pre-planned set of setable changes, but are

defined via a communications service state model • OID definitions are not currently in the event sequences• Likely that SC-CSTS takes precedence over event sequence• Question of whether or not SC-CSTS takes over the pre-planned

event sequence completely or “returns” to pre-planned event sequence

• Stating semantics properly for this will need to be studied if “simple” semantics are not assumed – ie, once an SC-CSTS “directive” issued event sequence no longer applies

• Does SC-CSTS need a service profile in the configuration profile to be referenced by a service package request or assumed to be part of service package by default

• Also, how does this relate to the configuration profile book and its service profile approach?

• How does this fit with service accounting?• Event sequences have numbered states to facilitate post-pass

accounting• AD to coordinate follow on sessions with members of CSTS and CSSM

WGSs

Joint Session, CSTS + CSSM WGs (2/2)

• New Services disucssion• Forward Frame service definition – agreed to use definition derived from

CSA Requirements document (not IOAG svc catalog)• AD to work on use case idenitification for forward and return file Service• Noted that W. Hell is working on consideration for off-line radiometric

data transfer service, leveraging TGFT

Trajectory Prediction

• Re Editorial question from London Meetings: will there ever be a need for mixing bi-lateral and CCSDS standard trajectory prediction formats?

• No. Any mixing is by definition bi-lateral and to be treated as such

• Reviewed presentation provided by J. Reinert – see meetings material folder in CWE

• Agreed to bi-lateral format identifier for bi-lateral extension point• WG, please confirm

• Worked on standard header parameters for T.P. information entity• Agreed that timestamps/originator apply to when “wrapping function”

was applied (ie., TDM or other bi-lateral “payload” retains its definition and meaning for any similar meta-data items) (see standard data header analysis for more information)

• Schema development/“ownership” – both J. Reinert and J. Pietras

Event Sequences

• Reviewed presentation material provided by P. Pechkam – see meetings material in CWE

• Draft book is available

• Discussed use of start-time/end-time wrt to standard header – can now be defined directly for this information entity as needed (see standard header slide)

• Noted that communication geometry related event sequence state transitions are not captured in functional model and do not have counter parts in SC-CSTS

• Ie., mode-changes – 1-way to 2-way to 3-way communication

XML Schema Namespace

• Reviewed namespace organization on per information entity basis• Action to C. Haddow to suggest division of namespace for common

schema components• How many divisions are needed and what are some likely notional

names?• Don’t think this was captured in the official action item list

Joint Engineering Session with CSTS WG

• Functional Resource model• In general functional model appears to be a good input for SE Area

ontology work• Noted that a annotation for a directive parameters for functional

resources should be able to address such situations as EIRP offset (which can not really be commanded for the ground station, but is something the ground station should be aware of)

• Current (beta) registry in SANA does not have the settable (“directive”) side of the functional resources

• Update pending that will provide this• OIDs will be versioned – last position of the OID is the version

number• Action item (but best efforts basis only) to provide an overview

diagram showing how functional resource model is managed for the CSS Area including engineering maintenance and release to SANA for registered models

• If possible, by the time of the fall 2015 meetings• Action to J. Pietras. H. Dreihan, and…?

Inter-Recommendation Tracking

• Updated the Class, Model and Document numbers tabs and cleaned up the spreadsheet

• The File Transfer, Ground Segment Profile document number was added• Class Folder was to the Inter-Recommendation Folder

• To be a repository for the Class Diagrams • C. Haddow to add the finalized SoS and Standard Header to this folder

• Model Folder (for other than info entity class diagrams) added to the Inter-Recommendation Folder to be a repository for the Models

• M. Gnatt’s document model was moved to this folder• Please use this folder for your models called out in the Inter-

Recommendation Spreadsheet

• Folder is located in CWE at:

http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS-SM%2FCWE%20Private%2FInter-recommendation%20Spreadsheet

Prototype Planning

• Communication Geometry • Potential agencies identified are CNES (output), DLR (output), ESA

(input – request/output), NASA/GSFC (output) and NASA/JPL (output)

• K. Tuttle has agreed to be the test report lead for this prototype• Trajectory Prediction

• Potential agencies identified• CNES• NASA/GRC • NASA/JPL• UKSA

• K. Tuttle has agreed to be the test report lead for this prototype• Need to look into (re-)use/leveraging of TDM prototyping

• Service Package/Service Request • Potential agencies identified are DLR, ESA• Note – this may benefit from and/or be coordinated with planning

request for communication geometry output• K. Tuttle – test report lead?

Service Catalog

• Agreed to research the material circa 2012 (at time of de-scoping of CSA WG charter)

• In particular provide comparative analysis on this material vs existing service catalogs

• Action to H. Kelliher for fall meetings• Noted that there is a relationship to the functional resource model that

needs to be worked out

Service Accounting

• Reviewed response to AI 2014-1113-03 from J. Reinert, comparing DLR, ESA, and NASA/SN (SGSS) received so far

• Discussed some options for reporting• E.g., per service, such as runs of successfully decoded frames vs

gaps for telemetry• Level of services, such as service packages executed per unit of

time• Action to E. Barkley – provide 1st cut of metrics for telemetry, command,

and ranging services for Fall 2015 meetings

Management Services

• Agreed to look re-visit earlier management services material and do a preliminary trade-type study re SOAP v REST

• To support discussions related to operations that have begun to surface in looking at abstract request engineering

• Action to A. Crowson and U. Müller-Wilm for Fall meetings

Work Plan Fall Meetings

Thank You

• Thank you to• Participants for traveling to and contributing to

productive meetings• NASA/Caltech-JPL for excellent hosting and facilities