date de la réunion / 26-30.10.2009 / ref./réf. / CSTS-WG-301009 / page/page / 2
20
meeting date / 26-30.10.2009 / ref./réf. / CSTS-WG-301009 / page/page / 1
date de la réunion / 17
meeting place / ESTEC (Fall 2009) / chairman / Y.Doat (ESA, )
lieu de la réunion / présidant
minute’s date / 30.10.2009 / participants / M.Goetzelman (DLR-Vega, ),
F.Lassere (CNES, ),
J.Pietras (p.t) (NASA-GST, ),
D.Richter (DLR, ),
M.di Giulio (ESA, ),
T.Ray (NASA-GSFC, ),
W.Hell (ESA, )
F.X.Mouy (CNES, )
M.Ferreira ( INSE ) PT
V.Schuchev () PT
dates de minute / participants
subject/objet / CCSDS CSTS Working Group / copy/copie / CCSDS CSTS Working Group Members
Description/description / action/action / Due date/date limite
T.Ray to prepare the book describing the Return Unframed Telemetry service based on the generic services and the guidelines for the definition of new services.
16.06.2006: Action moved from CNES to GODDARD
06.10.2009 – RUFT First presentation of service for discussion / A#6-1104 / Spring meeting 2010
T.Ray proposed to compile the User States tables for all procedures and propose it as a Green Book that would not be binding for implementation.
T.Ray to draft the User State Tables as Annex of the Guidelines (TBC). / A#09-0107 / Spring meeting 2010
W.Hell to review the ESA combined parameters list and distribute it to CSTS (Copy M.Stoloff). / A#05-1008 / 25.04.2009
End 2009
Y.Doat to clarify with Secretariat on a location to store the ASN.1 files in text format for retrieval by the developers.
26.10.2009 As an intermediate solution the text files were uploaded to the private area of the CWE. As a long term solution the ASN.1 shall be delivered with the book to be published together with the book. (same approach as for Service Management XML schema) / A#02-0109 / Closed on 26.10.2009
Y.Doat to prepare dummy specifications (in a TN) covering the possible derivation cases (Note: in each case we need a new procedure derived from an existing one):
a. Extend a parameter;
b. Extend an operation with a new parameter;
c. Extend a procedure with a new operation.
24.04.2009 – Presentation attached in Annex
Still to be checked: import of tagging in a CHOICE
24.06.2009: Prepare examples for the Guidelines. / A#01-0409 / 25.04.2009
August 2009
End 11/2009
M.di Giulio (ESA) and T.Ray (NASA) to organise TCP connectivity tests (firewall setup, …)
06.10.2009 – Initial discussions between ESA and NASA experts.
26.10.2009 - Closed / A#04-0409 / Closed
F.Lassere (CNES) to investigate security constraints and organise connectivity with T.Ray (NASA). / A#05-0409 / End June 2009
End 2009
W.Hell & M.Flentge to prepare a draft data dictionary that will be the base for the monitoring service. / A#08-0409 / End 2009
T.Ray to draft an overview presentation to be presented in all Agencies at the beginning of the review.
26.10.2009 – Draft presentation uploaded to CWE. / A#10-0409 / Closed
File Transfer: Initial concept/questions: M.di Giulio (ESA), F.X.Mouy (CNES) / A#12-0409 / Closed
Considering that the Forward-AOS service requirements are not totally clear for the CSTS, J.Pietras will work out a use case explaining the proposed approach and the possible impacts on the Framework. / A#02-0609 / End 2009
The version 0.21of the Framework contains ASN.1 updates that shall be considered for the MD service prototype. F.Lassere to confirm the migration. / A#01-1009 / End 11/2009
T. Ray will update the Presentation for the Agencies, according to the comments received by the W.G. / A#01-1009F / End 2009
Tim Ray will produce an ICD (Interface Control Document) describing the detailed settings of the parameters for the interoperability test with the Provider prototype. / A#02-1009F / End 2009
J.Pietras will modify the MD CSTS and the TD CSTS Books in order to contain the Service OID:
trkDataService
trkDataDerivedServices
trkDataExtServiceParam
trkDataExtServiceProcedures
mdDataService
mdDataDerivedServices
mdDataExtServiceParam
mdDataExtServiceProcedures / A#03-1009F / End 2009
M.Goetzelman will analyse if CSTS RUFT is a self standing service on top of the Framework, or if it will be derived from the Return Abstract Service / A#04-1009F / End of 2009
J.P. will address with the SM W.G. the issue of general management requirements for all Services. / A#05-1009F / Spring Mtg 2010
Table Of Contents
1 Review of Actions 5
2 SLE 5
3 Framework 0.20-CCSDS 921.1-R-n 5
3.1 General 5
3.2 Standard Header 5
3.3 Service Instance Identifier 5
3.4 Procedure Identifier 5
3.5 Association Control 5
3.6 Information Query Procedure 6
3.7 Cyclic Report 6
3.8 Unbuffered Data Delivery Procedure 6
3.9 Buffered Data Delivery Procedure 6
3.10 Notification procedure 6
3.11 Throw-Event procedure 6
3.12 Data Processing procedure 6
3.13 ASN.1 6
4 Concept 0.13 - CCSDS 920.0-G-n 6
5 Guidelines 0.6- CCSDS 921.2-R-n 6
6 Services 7
6.1 Monitored Data Cross Support Transfer Service 0.8 (CCSDS 922.1-R-n) 7
6.1.1 Splinter Meeting on SM aspects of the MD CSTS. 7
6.2 Tracking Data Service 0.2A 8
6.3 Return Unframed Telemetry 9
7 Prototype 9
8 AOS Forward Service – CLTU Based 10
9 File Transfer 10
10 Planning 11
11 AOB 11
11.1 Presentation to the Agencies. 11
11.2 Presentation and demo of WireShark 12
12 ANNEXES 13
1 Review of Actions
See actions above.
2 SLE
All SLE Books have been completely updated according to the Pink Sheet review. The complete set of RIDs and the relevant disposition is available with WH.
The Books will be submitted to the Secretariat for publication.
3 Framework 0.20-CCSDS 921.1-R-n
3.1 General
All the service State Tables have been moved from the Guidelines into the Framework. In this way, the State Table will be available in the appendix E of the that Book (which will become Blue).
The Guideline will become a Magenta Book.
3.2 Standard Header
In the Standard Header new diagnostics have been added (Req. 3.3.2.6.2.1) :
- ‘unsupported option’
- ‘invalid-procedure-instance-identifier’
3.3 Service Instance Identifier
N/A
3.4 Procedure Identifier
N/A
3.5 Association Control
Requirement 3.3.2.5.1
In the Association Control procedure, the procedure-instance-identifier, the identification will differentiate association control procedure from prime and secondary procedures.
The ASN.1 has been updated accordingly.
3.6 Information Query Procedure
N/A
3.7 Cyclic Report
N/A
3.8 Unbuffered Data Delivery Procedure
N/A
3.9 Buffered Data Delivery Procedure
Section 4.5.1.2.2.2
The synchronous notifications to be stored in the recorded buffer are limited to the event relevant to the Service Production.
3.10 Notification procedure
N/A
3.11 Throw-Event procedure
N/A
3.12 Data Processing procedure
N/A
3.13 ASN.1
Considering that the extensions are defined by a pre-defined syntax, the word “transfer syntax” shall be replaced by “syntax” (Note: “transfer syntax” would refer to ASN.1 or XML or …).
This update of the document is considered to be the final one. This version of the document will be assigned the number 0.21. After completing the editing the document will be issued to the Secretariat.
4 Concept 0.13 - CCSDS 920.0-G-n
The book has been reviewed, the comments have been embedded by M.G. and the Book has been assigned version 0.14.
The Book has been uploaded in the Private Area.
This version will be sent to the Secretariat.
5 Guidelines 0.6- CCSDS 921.2-R-n
Blue or Magenta Book
According to the CCSDS definition a Blue Book can be directly implemented and guidelines are of Magenta type.
The WG agreed to move the service state tables to an Annex of the Framework and convert the Guidelines to a Magenta book.
(This has been done by Y.D., see 3.1).
The requirement 3.12.3.2 states “The procedure instance number of the Association Control procedure instance of a CSTS shall be specified as “1””. By setting this value, the ASN.1 implies that the Association Control procedure is a secondary procedure.
The WG agreed that the Association Control procedure is neither prime nor secondary. A statement in the Framework is required stating that the Association Control procedure is a special type that do not follow the procedure rules.
Y.Doat analysed the impact on the book if such a change is introduced at this stage: the Procedure Instance Identifier has been modified to treat the Association Control Procedure as a special case, as discussed. The ASN.1 has been updated accordingly.
Considering that the extensions are defined by a pre-defined syntax, the word “transfer syntax” shall be replaced by “syntax” (Note: “transfer syntax” would refer to ASN.1 BER or XML or …).
The section 3.11.2 attempts to list the requirements to be considered for Service Management when a new service is specified. The WG agreed that such statements should be covered by a SM book explaining what is to be identified when a new service is specified.
Until this is done, the description remains in the Guidelines.
6 Services
6.1 Monitored Data Cross Support Transfer Service 0.8 (CCSDS 922.1-R-n)
MD CSTS - CCSDS 922.1-W-0.9 has been reviewed.
Comments have been provided by W.G. . All comments have been agreed.
J.P. will update the document accordingly.
6.1.1 Splinter Meeting on SM aspects of the MD CSTS.
A splinter meeting about definition, within SM, of monitoring objects names for MD CSTS has been held on 27 October.
Notes have been produced by E. Barkley and Yves Doat.
Notes on CSS Joint Splinter session -- CSTS + SM WGS re Monitored Data Service
27-Oct-09
Functional Resource
Name to be unique
Issue: Length of the resulting name
Registering for a Functional Resource list
pros: register to functional resource and receives the parameters w/o the
functional resource path
cons: user has to register to an entire Functional Resource (no way to get
a subset)
To get multiple functional resource, activate several procedures
Service Management:
SLA for list of parameters or list of supported functional resources?
Can we define the MD as a default service and the parameters to be
reported depends on the service package?
Data Dictionary:
Action in CSTS. Data dictionary will be a dedicated book.
Functional resource identification: who will do it?
Can we get the parameters as part of the SM parameters? The SM parameters
are configurable. Identified MD parameters (e.. meteo) are not part of the
SM parameters
Books:
MD Service (Blue): John
Data Dictionary: (Magenta?) could be covered by SANA
SM refactoy will cover adding new services.
6.2 Tracking Data Service 0.2A
TD CSTS - CCSDS 922.2-W-0.2A has been reviewed.
The OID in Chapter 3.1 shall contain:
trkDataService OBJECT IDENTIFIER ::= {servicesIdentifiers 2}
trkDataDerivedServices OBJECT IDENTIFIER ::= {trkDataService 1}
trkDataExtServiceParam OBJECT IDENTIFIER ::= {trkDataService 2}
trkDataExtServiceProcedures OBJECT IDENTIFIER ::= {trkDataService 3}
Those OIDs have been removed from the Framework.
All comments have been agreed.
J.P. will update the document accordingly.
A Presentation on the TD CSTS has been given by J.P. to the Navigation W.G. in a joint meeting.
Meteo, clock and media data may be needed only in off-line service, and may not be needed in real-time service. The relevant metadata differ from those of other data types.
(This may be the case also for the Doppler data, they are needed only in real-time.)
Basically, it is required to select different types of tracking data, and different delivery modes.
The W.G. believes that all these capabilities are already available with the CSTS Framework.
6.3 Return Unframed Telemetry
T.Ray presented the paper that introduces the concept.
The Return Unframed Telemetry service has many commonalities with the SLE return services (SLE-RAF).
The Service returns bit-synchronized data, organized into fixed-length data blocks.
NASA and CNES identified the need for a frame service (SLE RAF like) with automatic switch capability to unframed telemetry.
Two possible approaches:
CSTS Abstract Return service used as the basis for:
- either Pure RUFT
- or RAD (RAF type supporting RUFT capability)
The Service entails also :
- the Cyclic Report procedure
- the Information Query procedure
- the Notification Procedure, to report, e.g., about production status changes.
It is stressed, that this will be the case for all Return Services based on the CSTS Framework.
7 Prototype
During 2009 the CSTS Prototype has been developed by ESA/Vega, and it has been validated and accepted. The Design documentation as well the SVTS (SW Validation Test Specification) have been distributed to CNES and to T.Ray/Goddard.
This prototype implements the Buffered Data Delivery procedure, where ASCII data are read from a file and are delivered to the User.
Inter-operability tests with the User element developed at Goddard have just started.
So far, only the BIND operation has been successful, then the tests have been interrupted due to the participation to CCSD.
What still needs to be clarified is why the BIND operation has been successful, despite an unclear value for the OID for the service (20, instead of 1).
The Provider Prototype code has been delivered to CNES, for building the other part of the Provider Prototype on it. That part will implement the Cyclic Data Delivery offering monitoring data (read from file).
The first validation to check connectivity between CNES and NASA will be done with the Dummy Service Prototype.
8 AOS Forward Service – CLTU Based
NASA is going to implement the Forward AOS Service Orange Book. The W.G. considers the work on this book to be completed , and the Book will be sent to the Secretariat.
J.P. reported about potential problems with the existing Data Processing Procedure. Namely: an expiring latest radiation time may cause one (or more) enqueued CLTU to be discarded with reason “sldu expired”.
In this case the Service gets blocked and all the outstanding CLTU will be purged.
In order to understand to what extent this affects the CSTS Framework, J.P. will provide the requirements for Forward AOS Service.
In the Annex, a summary of the concepts for Forward AOS Service (by J.P.) is provided.
9 File Transfer
Identified areas of investigations are:
1) define the file types to be considered in the file transfer operations: these are the files identified in the IOAG Service Catalogue 1 document, table 3.1, plus possibly files for TM off-line delivery and associated catalogue files.
2) The initial need is to define the overall file transfer profile, which shall be described in the document: CSTS File Transfer Service [CFXS].
3) The detailed aspects of file characteristics will be documented in the service specific recommendations, like CSTS Offline Radio Metric Service [CORS], etc.