[Css-csts] CSTS Various Updates and Comments

[Yves.Doat at esa.int]

Dear all,

To conclude my contribution to last week meeting, you will find below:
   Comments to the MD Service (John)
   Comments to the Framework (Wolfgang)
   OID tree and Presentation (Wolfgang and all)
   Comments to the Data Dictionary Excel spreadsheet (John, Wolfgang,
   Fabienne)
   Scenario/Use Cases (Prototype developers)
   ASN.1 Modules (Wolfgang)
   Prototype (François, Tim)

Notes:
   I uploaded my files on the CWE web site under: CSS-CSTS/Meeting
   Materials/2013 Fall.
   Despite the fact that I mentionned who should have a look to which
   section, everybody is welcome to look and provide comments/questions.

1. MONITORED DATA SERVICE (John):

   The operational scenario identifies a default list without a name.
   Running the scenario, I see that the service provider returns an empty
   name.
   I recommend that the default list gets a name so that if the service user
   queries the list names, he gets the name of the default list.

   Section 2.2.2.1, 2.2.2.2 and 2.2.2.3. The options to access the
   configuration are missing.

   Section 2.5.2.4, the document refers to the events:
   [{Return Space Link Subcarrier Reception} : {subcarrierLockAcquired}];
   [{Return Space Link Subcarrier Reception} : {subcarrierLockLost}].
   Those 2 events do not exist in the spreadsheet
   “CCSDS_Monitored_Data_MasterCopy_23102012.xls. Should they be added?

   Section 4.3, Cyclic Report Procedure Derivation states:
   The MD Cyclic Report procedure extends the behavior of the CSTS SFW Cyclic
   Report procedure by modifying the behavior of the procedure when Parameter
   Labels or Functional Resource Types are subscribed
   The Framework defines:
   1.7.1.4.21 extension: the act of extending operations or procedures.
   Operations are extended by a) adding new parameters to the invocation or
   response message or b) extending the range of values for already existing
   parameters or c) changing an unconfirmed operation into a confirmed
   operation. Procedures are extended by a) adding new operations or b)
   extending the used operations.
   While I understand why you come to that statement, it is not in line with
   the Framework definition. In addition I read in the book that the only
   consequence of this derivation is the creation of derived procedures
   without any parameter.
   Considering that the behavior is modified without the addition of new
   parameter, I would call this a refinement.
   The current definition of refinement is:
   1.7.1.4.42 refinement: the act of refining operations or procedures.
   Operations are refined by constraining the values of parameters or by
   detailing the parameter semantics. Procedures are refined by narrowing
   their semantics or defining their behavior or states in more detail.
   To cover your case I would rephrase the refinement definition to:
   refinement: the act of refining operations or procedures. Operations are
   refined by constraining the values of parameters or by detailing the
   parameter semantics. Procedures are refined by modifying their semantics
   or defining their behavior or states in more detail.
   If we agree on such an approach, the procedures would be refined and the
   following OID could be removed:
   monDataCyclicReport, monDataInfoQuery and monDataNotification

   Section 6.5.3.1.1.2 rename
   productionConfigured to svcProductionConfigured
   productionConfigured to svcProductionConfigured
   productionInterrupted to scvProductionInterrupted
   productionHalted to svcProductionHalted
   productionOperational to scvProductionOperational

   Annex C.
   Once the registry in SANA will be published, will we remove that Annex?
   The paragraph: “Monitored Data TS Provider” lists a set of parameters that
   I cannot find in the data dictionary.

2. FRAMEWORK (Wolfgang)
   The Annex C (text) needs to be reworked to reflect the latest OID changes.

3. OBJECT IDENTIFIERS (Wolfgang and all):
   Under the branch ‘fwCrossSupportFunctionalities’ the ‘serviceGenericId’
   block is not a Framework Cross Support Functionality and belongs to the
   service.
   In order to have a clean grouping, I moved the ‘serviceGenericId’ block to
   a dedicated branch ‘serviceGenericFunctionalities’ directly under the
   ‘framework’ branch.
   I created a new ASN.1 module.
   I uploaded the new Tree in PDF format (to be printed on A3 format)
   20131102 CCSDS Object Identifiers CSS.pdf
   20131102 CCSDS Object Identifiers Framework.pdf
   The tree will go into the Framework.
   I uploaded my OID presentation (updated with the latest changes)
   20131102 Object Identifiers - Framework Annex C.pdf
   The ASN.1 modules have been updated to reflect the updates.

4. DATA DICTIONARY (Wolfgang, John, Fabienne):
   OID root number has been adapted to the latest change.
   Production Status:
   I renamed the productionStatus parameter of “Monitored Data CSTS
   Provider”, “Monitored Data Production”, “Real-Time Tracking Data CSTS
   Provider”,  “Service Control CSTS Provider”, “Service Control Production”,
   “Frame Data Sink” to production time to match their description.
I uploaded the new version for comments: "20131031 CCSDS_Monitored
Data_MasterCopy draft.xls"

5. USE CASE / SCENARIOS (Prototype developers)
I prepared the draft 0.1 of the TN we started in San Antonio and added some
more Use Cases.
I recommend to use it for the prototype.
I uploaded this first draft to the CWE site:
"20131102 Use Cases Technical Note d.0.1.docx"

6. ASN.1 MODULES (Wolfgang, François)
The ASN.1 reflects all the discussions we had in San Antonio and includes the
(few) bug corrections identified with the use cases.
I checked the syntax and I uploaded the Word file (needed by CNES for the
prototype).
In order to give the file to the ASN.1 compiler, it has to be saved in text
format.
I uploaded the new version of the ASN.1 "modules: 20131102 ASN1 201310
reorganised OIDs - Word Track Changes.docx"

7. PROTOTYPE (François, Tim)
Following a round-coffee-discussion" with François, I understand François
will arrange with teleconference/Webex session(s) with the prototype
developers to answer.
Tim may be interested to participate.

Sorry for this long message but I wanted to close those items rapidly.
I hope you all came back safely home.

Best regards

Yves DOAT
__________________________________________________
Head of the Ground Facilities Infrastructure Section  (HSO-ONI)
in the Ground Facilities Operations Division
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288               Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.