[Css-csts] CSS - CSTS - CNES comments about generic services

Wolfgang.Hell at esa.int Wolfgang.Hell at esa.int
Tue Feb 22 09:55:11 EST 2005


Dear All,

I'm  sending the note below on behalf of Jean-Claude, hoping that I have more
luck than him with the CCSDS Mailman

Best regards,

Wolfgang

> Dear all,
>
> Please find CNES approaches for generic services and some comments about
ESOC technical note and Toolkit WhiteBook from Jaxa :
>
> *          CNES approaches for generic services
> *          Context
>            CNES decides to adopt CCSDS standards for future programs
>            But CNES operates 2 networks of ground stations and
multi-mission facilities used for the control of satellites during
positioning and in-orbit operations based on non-standard protocols> ...>
>            Key idea : migration of our GSN to SLE but keeping a
compatibility > ...>
>            First step : gateways> ...>
>            And after > ...>  we wait for generic services to suppress
gateways
> *          CNES needs
>            Have an unique interface in our entities (ground stations,
control centres) based on TCP/IP and SLE for standards services (as RAF, RCF,
CLTU) and the capability to define some external/internal services based on
the same concepts
>            Possible services :
> *          Data Stream : Return Unframed Telemetry, Ranging Data, Range
Rate Data, Tracking Data, Ground Station Monitoring Data
> *          Bit stream : Encrypted Telemetry
> *          File Transfer : Pass reports, LogBooks
>            How we imagine the implementation : an exemple...
>            > >  <<...OLE_Obj...>>
>
> *          About ESOC Technical Note
> *          We are totally agree with this approach. The generic toolkit has
to define what are the commonalities in the actual services, in the
operations and what parameters have to be mandatory. For these reasons, we
think that it would be better to extract from generic toolkit the service
dependant definition and to move it in the service definition recommendation.
> *          table 3-1 Applicability to Return and Forward Services :
INVOKE-DIRECTIVE is not identified as a generic operation, why ?  Can't we
imagine a future service who needs this operation ? Is it not equivalent to
THROW-EVENT ?
> *          page 21: 'number-of-dataitems-radiated'
>            We are not sure that a forward generic service always use a
radiation status. We propose to change the name of this parameter.
>
>
> *          About JAXA WhiteBook
> *           1-5-2 GENERIC SERVICE DOCUMENTATION TREE (page 1-3) : In the
following sentence "this recommendation is part of a suite of documents
specifying the Ground Domain Services", probably "Ground Domain Services"
should be replaced by "Cross Support Services".
> *          table 2-1 GENERIC service operation : for the case
GENERIC-RETURN-TRANSFER-DATA, in the column "purpose", I think it would be
better to read "to transfer data to the service user" instead of "to transfer
data to the service provider ot to transfer data to the service user". Same
thing for GENERIC-FORWARD-TRANSFER-DATA where we should read "to transfer
data to the service provider".
> *          We dont't find in the white book what are the mandatory
operations. Is it normal ? Do you put this information in the GuideLine ?
>
>
> We are agree to discuss about the documents during the teleconference on
the 24th
> Best regards
>
>
> Jean-Claude RUBIO
> CNES Toulouse - Bpi 1212
> DCT/OP/MR
> * 05.61.27.37.32, Fax 05.61.27.40.77
> * mailto:jean-claude.rubio at cnes.fr <mailto:jean-claude.rubio at cnes.fr>
>
>
>
>






More information about the Css-csts mailing list