CSSM Meeting Summary

CCSDS CSSM Technical Meetings

Noordwijkherhout, The Netherlands

31 March – 03 April 2014

Agenda (As adjusted during the meetings)

Monday, 31 March0830: CCSDS Plenary0930: CSS Opening Plenary1100: Introduction, recap of San Antonio meetings, subsequent progress, agenda adjustments (Barkley/Haddow)1130: Introductory survey of information entities and general extensibility considerations (Barkley)1230: Lunch1330: Service Request/Service Package formal extensibility points (Pietras, Barkley)1515: Break1530: Review of Schedule of Services prototype test report (Tuttle, Gnat) 1730: Adjourn  Tuesday, 01 April0845: Timelines Overview – as a basis for planning information in general (Haddow)0930: Event Sequence extensibility dimensions1000: Toward accountability (Barkley) – inter specification meta-data engineering1030: Break1045: Planning information – toward 1st issue of blue book 1 (work on elaboration of section 5.6 in green book)1200: Schedule of Services Agency Review planning (Haddow, Barkley)1230: Lunch1330: Configuration Profile/Service Agreement vs IOAG Catalog 11430: Joint Mtg w CSTS on SANA OID Registration tool1530: Break1545: Configuration Profile/Service Agreement vs IOAG Catalog 1 (cont’d)1630: Planning Information Preview (Haddow)1730: Adjourn

Wednesday, 02 April 0845: Joint meeting, generic file transfer BOF (or maybe a splinter session)1045: Break 1100: Blue book development planning (planning info, svc req/pkg, config profile/svc agreement, event sequence)1230: Lunch1330: Planning information engineering working session (Haddow)1500: Break1515: WG Planning, with emphasis for next 6 months (Barkley/Haddow), incl prototype development1730: Adjourn  Thursday, 03 April0845: discuss SANA registration considerations0930: TP Engineering discussion1015: Blue-1 5 year confirmation?1030: Action Items Review (Tuttle)1100: AOB, meeting summary, wrap-up1230: Lunch1330: Reserved Planning Information working session (if needed) 1530: CSS Closing Plenary1730: Adjourn 

Brief Survey of Extensibility

• Brief introductory working session• Capture/sketch shown below• Intention is to track extensibility mechanisms as the

recommendations develop as tool to help keep the various information- Note that further information re Service Package

is later in the summary

Service Package/Service Request Extensibilty• General goal is to develop an M2 model of service request and

service package such that extensibility concerns are identified; first step is to abstract the components

• See next two slides for current status re service request and service package respectively

• Presentation for service package is available viahttp://cwe.ccsds.org/css/docs/CSSSM/Meeting%20Materials/2014/Spring/AbstractServicePkgResultModel-140326.ppt

• Further work/study required for these efforts

Draft Svc Request Extensibility Component Model

• Discussion Notes• The notion of a multiple Service (Contingency) Scenario Specification was challenged as not being in-line with current

agency practices- Noted, with conclusion that restriction (per Svc Agreement) to only 1 scenario per request adds very minimal

overhead and for time-being, SCSS remains in component model• The (Stored) Data Retrieval Service likely needs to be further abstracted for general pre-cached/off-line type data sources

such that forward direction is also accommodated (e.g, forward file services and/or coupling with GFT for files of CLTUs to be radiated)

Draft Svc Request Extensibility Component Model

• Discussion Notes• Still very much work in progress• Complete CSTS service instance that “span” service packages needs further discussion• Retrieval SP and Retrieval TD may in fact be grouped under a general off-line retrieval component/capabiltiy

- Does this tie into generic file transfer?

Schedule of Services Prototype Test Report• 3 Test Cases presented

• Manually building/exchanging of schedule of services (DLR NASA in all cases)

• Use of automated tools for building/exchanging of schedules of services

• Building/exchange of unused/unallocated times

• Test results by and large positive – key findings• Correction to XML schema • Clarification re semantics for beginningOfActivity (BOA),

beginningOfTrack, endOfTrack, and endOfActivity for unused time publication in draft BB- BOA and EOA are set NULL (only BOT and EOT used in

this case)

• See presentation in CWE for more details• http://cwe.ccsds.org/css/docs/CSS-SM/Meeting

%20Materials/2014/Spring/SSFS%20test%20report%20status.pptx

Timelines Discussion• Discussed in the context of planning information entities

• Envisioned that these entitles will all be time-series data• Also noted that event sequences may be a candidate for timelines

expression• Key point for considerations is to consider provenance or

namespaces in constructing timelines• E.g, rather than a (with respect to prototypical communications

geometry events) consider an abstract representation such as- T1: AOS- T2: ENTER OCCULTATION- T3: LOS- T4: EXIT OCCULTATION- T5: AOS (etc)

- An alternate abstract representation may be- AOS: T1, T5- ENTER OCCULTATION: T2- EXIT OCCULTATION T4- LOS: T3

• Noted that given timelines data exchange (TDE) current BOF of status that a recommendation is not likely for 1st draft of planning information book• Agreed to examine concept and consider adoption of conceptual

approach

Event Sequencing Extensibility Considerations• Introductory presentation only• Extensibility model discussion differed until late July 2014• See next slide for introduction to state model for event sequencing

• Note: this may be (eventually) be represented by an activity timeline

Trajectory

Spacelink availability

Start of Spacelink

Start data transport

End spacelink

Start spacelink

Data availability at lower symbol rate

Data availabilityat higher symbol rate

t1 t2

Start data transport

End of Spacelink

Symbol rate change

Stop data transport

t3 t4 t5 t6 t7 t8

Event Sequencing Overview (telemetry example)

Space Link Available State

Data Transport State

Space Link Available State

Data Transport State

(In fact, spacecraft may continue to make return space link available so this may in fact be space link available state definition – more later)

L o n g t i m e

Planning Data Format – 1st Release Discussion

• Part 1 of the Discussion focused on overall meta data, especially in relation to communications geometry

• Following are the pieces of meta data identified and notes where appropriate• Time

- Absolute (yes)- Relative (no; does not appear to be a general

agency practice)- Duration (? – to be determined)

• Spacecraft Id• Events

- AOS, LOS etc (see next slide)• Event Id• Orbit number (optional parameter)• Timeline Id (maybe)

Planning Data Format – 1st Release Discussion

• Part 2 of the Discussion focused on event definitions• Following are the preliminary set of events identified with

notes as appropriate• Planning Information Events discussion

• AOS/LOS• Elevation (relative to ground station)

- physical terrain mask- uplink lo + hi power masks- down link mask- fixed elevation (an elevation of interested to the mission)

• Rise/Set• Occultations• O|RTLT (One-way or Round Trip Light Time)• Max Elevation (relative to the ground station)• Keyhole• Sun Alignment Angle• Cable Wrap

• Range {? – technically O|RTLT cover this }• Noted that 1st items are closely related – some classification work

likely needed

JP Chamoun (GSFC) to provide relay satellite inputs once initial event list determined

Configuration Profile/Service Agreement vs. IOAG Catalog 1 (1/2)

• Reviewed analysis of functional group combinations needed for configuring data delivery and radiometric services as identified in IOAG Service Catalog 1

• Main conclusion there are 14 FG combinations that in total address configuration for all of the IOAG C1 services

• “infinite” extensibility is not required• We can likley delivery the CP/SA book with “shrink-wrapped” FG

combinations and treat extensibility as maintenance updates (similar to that already for RF modulation related books)

• See next slide for summary of IOAG C1 service vs. FGs

Configuration Profile/Service Agreement vs. IOAG Catalog 1 (2/2)

FG ->------------

IOAG servicev

ApertureForward Physical Channel Xmission

TC Sync & Channel Encoding

Forward AOS Sync &

Channel Encoding

Forward TC Space Link Protocol Xmission

Forward AOS Space

Link Protocol Xmission

Return Physical Channel

Reception

Return TM Sync &

Channel Decoding

Return TM/AOS

Space Link Protocol

Reception

SLS Data Delivery

Production

Offline Data Delivery

Production

Data Delivery Transfer Services

SLS Radio Metric Data Production

Retrieval Radio Metric Data Production

Radio Metric Data

Services

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

Packet M M M M C2 C2 C2 M

Forward Frame M M C3 C4 C5 M

Forward File (SLS) M M C6 C7 C6 C7 C8 C8 C8 M M

RAF (online) M M M M RCF (online) M M M M

ROCF M M M M Offline Frame

Buffer M M M M M

RUFT (real-time) M M M M

TM Segment Buffer M M M M

Return File (SLS) M C8 C9 C10 C9 C10 M M M M M

Validated R-M (SLS) M M M M M

Raw Data R-M (real-time) M M M M M

TDM Recording Bufffer M M M M M

Delta-DOR (SLS) M M M M

ConditionsC1 Required if forward link status is required to control production status C6 Required if the service is operating over a TC link

C2Required if forward link status is required to control production status or if the services is running over COP C7 Required if the service is operating over an AOS link

C3 Required if service is transferring TC frames C8 Required if the service is operating in Reliable Transfer mode

C4 Required if service is transferring AOS CADUs or AOS frames C9 Required if the service is operating in Reliable Transfer mode and the forward link is TC

C5 Required if service is transferring AOS frames C10 Required if the service is operating in Reliable Transfer mode and the forward link is AOS

Summary of FGs Needed to Support IOAG C1 Services;Full presentation at http://cwe.ccsds.org/css/docs/CSS-SM/Meeting%20Materials/2014/Spring/StandardServiceConfigurations-140319.ppt

Joint Mtg w CSTS re Object Identifiers, SANA

• MD-CSTS will register OIDs with SANA – based on functional resource definitions

• “Root” defn is: 3/112/4/4/2 • ISO numbers are: identified-organization (3) standards-producing organization(112) ccsds(4)

css (4) crossSupportResources (2)• Specific functional resources subsequently identified from here on down

• CSTS scheme is that the version number will be the last digit of the OID

• The CSSM configuration profile and service agreement information entities will reference selected OID numbers that represent the function group

• These will be carried in the XML Schema for the CP and SA

• As we have inter-specification dependency, this implies that SANA registration policy for functional resource/group OIDs is necessarily coordinated at the area level

Toward Service Accounting

• Preliminary/Initial discussion• Main goals/concerns identified

• Consistent coherent inter-recommendation meta-data• Usage foreseen for

- forensic analysis- Specific contact/tracking pass summarization- Longer term trending re service level/quality

commitments- E.g, Over a period of a Week, a Month, a Year

• Noted that- Standard defintion of metrics, on a service basis

will be useful- E.g, telemetry frame gaps and runs- Functional groups may be a good intial basis against

which to provide some of the key service metrics• Agency reps to begin gathering input on reporting

metrics for fall meetings

Trajectory Prediction

• Concluded that as a pure data format project not really needed• Existing ODM Book (502.0-B-2) already addresses this

• Green Book to be updated• Project to be removed from CWE Framework

SANA Registry Discussion

• (See also notes on CSTS OIDs/joint CSTS mtg)

• Need to consider namespaces for schemas• Likely to have common schema – inter

recommendation• Common schema defn probably only possible once

"payload" schemas developed• Policy needs to fit with overall area-level

approach• SSoS - White book -- relies on spacecraft Ids;

"creates" station/antenna Id registry • Agreed to confer with CESG to see if there are any

concerns re “ownership” of stations/antenna identifiers registry by CSS Area

Blue-1 Reconfirmation

• August 2014 will mark 5 years since B-1 published

• Should recommendation be re-confirmed?• DLR: Yes• NASA: Yes• UKSA: Yes• No opinions to the contrary

• Minor updates are needed (e.g, proper inclusion of trajectory prediction)

• Anticipate project initiation for minor revisions in Spring 2015

Long Range Book/Recommendation Planning Discussion

• Conclusions• Need to develop an inter-recommendation tracking tool (e.g, spreadsheet or other

similar mechanism) to include items such as- Common terms- Dependencies

• This may also have a bearing on XML Schema structuring

Plan for next 6 months

• RID resolutions for SoS by Aug 2014 (assuming agency review completes)• Any updates needed done by Nov 2014

• SoS Prototype Test Report: June 2014

• Complete draft of planning re communications geometry: Nov 2014

• Preliminary write-up configuration profile/service agreement: Nov 2014

• Service Request/Package component write-ups: September 2014

• Preliminary draft of Event Sequencing: Nov 2014

• Telecon Schedule- T1: 28 April - T2: 14 May - T3: 03 Jun- T4: 17 Jun- T5: 15 Jul- T6: 05 Aug- T7: 26 Aug- T8: 16 Sep- T9: 07 Oct - T10: 04 Nov

Thank you

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

productive meetings• ESA for excellent hosting