[cssm] SACP: configuration of tranfer services
Colin.Haddow at esa.int
Colin.Haddow at esa.int
Wed Feb 10 17:29:12 UTC 2021
Hi Marcin, Anthony,
ESOC has effectivly moved to
permanent SICfs. The NIS (Neywork Interface System - Handles MCS -
Groundstation SLE links) was designed to be able to use dynamic as well as
permanent SICFs and the missions screamed about the prospect of having to
use dynamic ones, much preferring to use permanent ones.
Cheers for now,
Colin
---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.
Phone; +49 6151 90 2896
Fax; +49 6151 90 3010
E-Mail; colin.haddow at esa.int
---------------------------------------------------------------------------------------------------------
From: "Anthony Crowson" <anthony.crowson at telespazio.de>
To: "Marcin.Gnat at dlr.de" <Marcin.Gnat at dlr.de>,
"smwg at mailman.ccsds.org" <smwg at mailman.ccsds.org>
Date: 10/02/2021 18:23
Subject: Re: [cssm] SACP: configuration of tranfer services
Sent by: "SMWG" <smwg-bounces at mailman.ccsds.org>
Hi Marcin,
As I would see it, and as I think we had it in the old Blue-1 book, the
service instance identifiers and the parameters you feel are missing are
part of the service package, not the SA or CP. Your 3 spacecraft
configurations would be 3 configuration profiles. The SP request may
identify a specific station or antenna; at any rate, the SP itself will
identify the aperture and the service instances, and at least port IDs.
There was a discussion which I don?t think was ever fully resolved, about
service instance identifiers. The original concept had them being
dynamically defined for each service package. But the ?stop-gap? SICF
approach ended up with people getting used to ?permanent? SI IDs and being
reluctant to change that. Certainly I think it would be unhelpful to have
to reproduce the same config multiple times just to use different SI IDs
for different apertures.
Basically what you suggest in your second and third bullets looks about
right, modulo discussion on permanence of SI IDs.
I think the FRM parameters identified as just ?reporting? mean they cannot
be changed during production. Clearly they have to be set somewhere, i.e.
?by management?, as part of setting up the service packages.
Anthony
From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of
Marcin.Gnat at dlr.de
Sent: 26 January 2021 15:32
To: smwg at mailman.ccsds.org
Subject: [cssm] SACP: configuration of tranfer services
- CAUTION: This message was sent from outside of Telespazio Germany.
Please do not click links or open attachments unless you recognize the
source of this email and know the content is safe. Please report all
suspicious emails to "support at telespazio.de" as an attachment. -
Dear SMWG,
In course of some implementation work and discussion with my developers, I
came to the point where I think we shall have some closer discussion soon
(in one of our teleconferences and definitely later during spring
meetings).
The protagonist: configuration (profile) of the transfer service (known
currently under nicknames ?SLE configuration? or ?SICF?).
The place and time: somewhere in snowy Bavaria during Winter 2020/2021,
Corona situation.
The Synopsis: during implementation of VEEEEEERY remotely similar profiles
into DLR?s new scheduling system, my developers asked me how they shall
treat the Service Instance Identifiers in the profile. When I looked at
their initial implementation, I noticed, that they did put the complete
configuration (service) profile in ?one piece?, according to the current
list from FRM and to what I told them. It does not correspond to the full
flexibility of the actual planned SACP (this was not the intention).
Anyhow, I realized two things:
1. Not all of SLE parameters were there (GVCID, Port and User
identifiers, etc?)
2. Defined as such now, projects would need to define multiple
configuration profiles, being actually the same, differing only with
Service Instance Identifier, for each Service Instance. In our case, for
example for TerraSAR mission, we have actual 3 spacecraft configurations
for the antenna, but in total 32 service instances for different stations,
antennas and cortexes. This maybe does not multiply 1x1, but at least we
would need 32 configuration profiles (I can almost hear the project people
coming to get me)!
Okay, this is to some extent my own fault, as I burdened the
implementation of ?some kind of configuration profile? to my developers,
and maybe did not thought about it in front. But it shows I think also
some shortcomings we have with the concept (maybe it will shape up still).
To the first point, I quickly noticed, that ? even I made a list of
parameters based on FRM ? actually not all parameters are really exposed.
When looking to the export of Holger out of FRM and the schema files, I
noticed than there is number of parameters which are marked only as
?reporting? thus in first place not visible to SACP (hence my omission).
And so, all Initiator and Responder Id?s as well as PortId?s and the
GVCID?s are marked as ?reporting? or ?read-only? if you like. How are we
going to set them? Shouldn?t they be also configurable, similar like
Service Instance ID?
>From this:
To this:
Second topic is the actual (operational) separation of the antenna
configuration and the transfer services configuration. Currently (at least
at DLR) this looks like this:
There are few antenna configurations (which may be effectively also
identical throughout different antennas) and number of SLE configurations
(Service Instances). To be fully honest, the multiplication of the SLE
config is just due to the different Responder ID and Port ID?s, resulting
also in separate Service Instance ID, the rest of the config is typically
the same (for a specific RCF or FCLTU service).
How do we want to handle that with our current concept of SACP?
I know we had some brief discussions on that, and there is some three page
(chapter 3.4.2) information on intended use in the TechNote of John. It
speaks relatively high level about two options, reusing SICF files (kind
of an extension to the actual SACP config) and also by dynamically setting
the abovementioned parameters.
First option says, that SICF files shall be there, and the Responder and
Provider ID?s and Ports shall be fixed in Service Agreement and for
specific Site and Mission, and later on only these shall be used. It does
not actually however says anything on how actual SICF is bound to the
specific Service Package nor Service Package Request nor Configuration
Profile. We have Ports and their ID?s, but how do I know which SICF shall
I use? Shall there be also predefined ONE fixed SICF?
Second option of using the extended/abstract parameters in Service Package
may allow for dynamic provision of the so called ?scheduledSocket? which
would be just the ProviderPort. So far so good, but still I miss the rest
of the SLE/CSTS configuration, especially wrt to what I wrote above.
Here is where the I lost the trace of the hunted game. And maybe we need
here some discussion. ?
I was thinking ? just to came into with some proposal ? of the following
(better ideas are welcome!):
- To not destroy everything else we already somehow managed to
set up wrt SMURF, SPDF and SACP?
- ?We could use extended list (as at the beginning) in the
Service profile, with Service Instance ID, PortID?s, GVCID?s etc., having
predefined some parameters (i.e. Buffer sizes), whereas leaving all of
these ?variable ones? undefined. That way we would have limited number of
Configuration Profiles (a set of few generic ones for the spacecraft,
universally engageable in every station).
- When booking the Service Package (sending the Request) we could
?overwrite? the previously mentioned parameters using AbstractParameter
Class (for example ?InitiatiorID? and ?ServiceInstanceID? and ?GVCID?).
The same would be true for SPDF ? the values there would be shown in
AbstractParameter class (and for example additionally station defined
PortID would be provided). This would allow to use all of our Books /
Formates as they are, and have individual SLE configuration for each
pass/service package.
- The disadvantage of the above method would be, that there would
need to be some kind of automated generation of Service Instance ID and
GVCID on user side and the ProviderPort on provider side. Otherwise we
come into danger of crazy users/providers not filling these parameters, or
filling them wrongly or even filling them different.
Okay? I?m done for today ?
Cheers
Marcin_______________________________________________
SMWG mailing list
SMWG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210210/088117a8/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8215 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210210/088117a8/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 12585 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210210/088117a8/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 9567 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210210/088117a8/attachment-0005.png>
More information about the SMWG
mailing list