cssm meeting summary
DESCRIPTION
CSSM Meeting Summary. CCSDS CSSM Technical Meetings Noordwijkherhout , The Netherlands 31 March – 03 April 2014. Agenda (As adjusted during the meetings). Monday, 31 March 0830: CCSDS Plenary 0930: CSS Opening Plenary - PowerPoint PPT PresentationTRANSCRIPT
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