[cssm] [EXTERNAL] CPIF - RIDs 5, 6, and 11 (Keyhole and CableWrap)

[Barkley, Erik J (US 3970)]

Colin,

I think it comes down to whether or not we want to see, relatively clearly, whether or not a general period of visibility is interrupted by an internal provider event versus potentially confusing shorter periods of visibility as indicating that only short tracking passes are potentially available. I do know that the practice is very well-established for the DSN to indicate the overall length of visibility with small interruptions rather than the other way around. I think this is ultimately more useful for planning purposes as it tends to fit the reality of scheduling. In other words, even if there is say, a three minute outage during an eight hour tracking pass, it is eight hours of tracking pass scheduled rather than breaking it up as, for example, five hours and 57 minutes followed by a tracking pass of two hours - it would look odd - why have they scheduled a tracking pass that starts three minutes after the one they just concluded on the same aperture?  -- I think it is cleaner to have the planning information look more like what the ultimate scheduling information looks like.

So, ultimately I prefer putting in the provider internal limitation event to indicate these short outages. I also think that it is more correct, as technically the spacecraft is in view for the entire interval of time but, due to provider internal limitations there will be a short outage in service but not with respect to the spacecraft technically being in view.

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Colin.Haddow at esa.int
Sent: Wednesday, July 8, 2020 06:43
To: CCSDS SMWG ML(smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Subject: [EXTERNAL] [cssm] CPIF - RIDs 5,6,and 11 (Keyhole and CableWrap)

Dear all,
                  just been trying to do the updates to the schema as discussed yesterday at the Webex and was reading the red book before starting the updates (i.e. replace Keyhole and CableWrap with ProviderLimitation), only to find that we may already have this covered and all that needs to be done is remove the Keyhole and CableWrap events.

The reason for saying this is that we have RetComms and FwdComms events already defined and in a note at the bottom of table 3-4 it states;

"NOTE        -        The Forward and Return Communication Start and End events are used by the provider to specify the possible start and end of communication service windows to a user platform, relative to any and all limitations and constraints under which that provider can execute user services.  The specific limitations and constraints are not implied and are left up to the provider to consider, so long as the user platform can plan and request any service whose Start and End times are contained (inclusive) within the timeframe bounded by the COMS_START and COMS_END events.
                Typical limitations and constraints accounted for when defining the COMS_START and COMS_END events are constraints associated with antenna elevation, cable wrap, visibility masks, slew rates, etc."

so the question is to we need the ProviderLimitation events in view of this ?

I can see there may be some use in indicating a limitation rather than just providing an available comms window, but would appreciate other vies.

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/20200708/6dcb43f7/attachment.htm>