[cssm] Use of SICF in Service Management - again

[Marcin.Gnat at dlr.de]

Dear all,

below some of my answers.

Have a good weekend
Marcin

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Colin.Haddow at esa.int
Sent: Donnerstag, 25. Februar 2021 13:29
To: smwg at mailman.ccsds.org
Cc: Jean.Schuetz at esa.int
Subject: [cssm] Use of SICF in Service Management - again

Dear all,
                  I've been checking how the SICF is originated at ESOC and it appears that generally (but not always) the Service provider is proposing the SICF and the managed parameters set up. Not sure how other agencies handle this.

It does however leave me somewhat confused with how the SICF is supposed to fit in with the SMURF and SPDF, e.g.

  1.  Who submits the SICF?
[Marcin] Normally it would go from Mission (User) to the Station (Provider). In many cases we (DLR) do that. There are some (mostly small) projects, which do not care (have no know-how in that area), and we set it up for them. In general I'd say, currently the one decides (and defines SICF) who has the biggest network / connections to manage (which typically is some Control Center with attached Network Operations Center -> ESTRACK, etc...). So, for example:
If ESA approaches us to have a support from Weilheim, for us (DLR) it is a Mission/Customer/User who tells us what SICF (or actually SICF contents) we shall use (--> ESA, User). From ESA point of view, it may be ESTRACK who decides actually internally, and this can be seen as "provider" provided SICF (--> ESTRAC, Provider). So, I'd say It actually depends on actual visibility of an enterprise model.

  1.  Does a SICF needs to be referenced in a Service Package Request?
[Marcin] I'd say yes (how otherwise one should know which SICF shall be used for requested Service Package / Pass?)

  1.  Does the SICF get referenced at the Service Package level, or do we need to specify the SI at service level (possibly in both SMURF and SPDF)?
[Marcin] As already written in one of my previous mails, DLR typically uses separate SI (or actually even multiple SI's!) per Service (whereas one must admit, the "service" as such is not really divided to separate carriers, etc, as in SM given). One could say, in other words, the actual individual SI's define services.
BUT, I admit, this may complicate things, and also for the phase-over, we could agree to have one FILE per all SI's (and then bilaterally agreed what it should exactly look like).

  1.  How do we handle the different approaches to the SICF, i.e. some agencies have multiple SIs per SICF, others have a one to one mapping of SI to SICF?
[Marcin] As written above, I'd propose to have one SI-Package per Service Package, and the contents of this package file shall be bilaterally agreed. It could be than ESA-DSN-Like single SICF file, or it could be a zip file with individual SI's. That way we do not obstruct current world of SI's and we get the most important aspect - binding to the Service Package.

  1.  Do we need to come up with a standard SICF format? (I hope the answer to this is no...)
[Marcin] Assuming we do it as I propose above - no.

Perhaps we need a splinter webex or 2 to try and thrash this out ?

[Marcin] Not that I have too much time for extra meetings, but it may be good, as long as we focus on this specific topic (i.e. I would not like to discuss if the permanent SI's are better or not, because in my opinion, this is not the point).


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<mailto:colin.haddow at esa.int>
---------------------------------------------------------------------------------------------------------

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<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210226/c81b4006/attachment.htm>