[Smwg] Response to AI 2017-0512-16

Thu Oct 26 22:59:14 UTC 2017

Holger,

Thank you very much for the comments, analysis. Please find responses embedded below. I hope you do not mind that I am copying the working group for cognizance.

Best regards,
-Erik

From: Holger.Dreihahn at esa.int [mailto:Holger.Dreihahn at esa.int]
Sent: Tuesday, October 17, 2017 4:50 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Subject: Re: [Smwg] Response to AI 2017-0512-16

Erik,
Very interesting presentation. Some thoughts I had reading and thinking about it, especially if we can model this with based on what the Functional Resources provides:
eb> Yes, in general, there needs to be connection with the FRM. Just what that looks like is still rather TBD.

  *   For the sake of x-support, would it be possible to express an event sequence as a set of time tagged directives, as they are (will) be specified in the Functional Resource Model? To be more precise, the fact that we will have several instance of the same Functional Resource (type) calls for a sequence of directives acting on Functional Resource Instances. What could be added, if needed, are 'expected' events, which are observed in real time, see next point.

eb> Even though the functional resource model is abstract, I think that the event sequence is potentially yet at another level of abstraction.  For example, it seems that it should be possible to express something like a spacelink change event for a return carrier from 1-way tracking to 2-way tracking without the need to state the underlying functional resource directives.  I think this is more clear at the level of service events rather than a series of functional resource directives to change the receive frequency, to start carrier loop acquisition, to start sub-carrier loop acquisition, to start symbol loop acquisition, etc.   All of these are (I think) legitimate aspects of the functional resource model, but the event sequence is really just happy to state the transition event and then whatever directives are required can be assumed to occur.  I think is ultimately cleaner, and more straightforward from a standardization point of view.  It may be that ultimately there is some sort of guide of the expected directives vs events, but I think have to list out all the directive will soon make the event sequence loose it cogency.

  *   In my mind most of the directives would be time tagged with absolute UTC time, as most of the events (all?) are predicted events. Are there cases when a directive execution should be linked against a real time occurrence of an event (equivalent to the Functional resource Event)? UTC time would leave the responsibility of translating on-board time or anything subject to another calendar to the creator of the event sequence.
eb> I think linking directives against real time occurrence of an event could be something that we do consider eventually. But note that I say eventually :-) I think we will have enough work ahead of us to just to define the sequence itself. I think there may be something of a continuum of scenarios to address. I think it is not too much more that we start to then get into things like standardized procedures -- for example, if acquisition of telemetry does not occur with the nominal configuration profile, then attempt to open the loop bandwidth by xxx Hz and try again.  But I think this is veering into a whole other body of work.

  *   Do you have in mind to formalize the state machines for e.g. the level Functional Resources? States are TBD for each FR (e.g. Data Transport State), inputs to the state machine could be the Functional Resource Directives and observed (FR) events (e.g. Carrier lock). Would be interesting, allows systematic creation and validation.
eb> To start with, just a state machine sufficient for expressing the events as outlined in the presentation. In the service management working group one of the issues that is being wrestled with is to separate the static aspects of the configuration (which tend to be more about what the functional resource model addresses) from the dynamic or temporal aspects of the configuration (i.e. those things that vary as a function of time during a tracking pass).  I agree that ultimately there could in fact be a unifying model to all of this and it would be a good idea to work toward that.  At the same time we also have to consider that implementations should not be presented with an all or nothing approach and we have to allow for incremental, piece-by-piece, agency adoption. To me, the risk is getting "lost" producing the "theory of service management" rather than practical standards that can be fairly readily adopted by implementations that exist. So I think just taking the step of defining the state machine for expressing the events is a good starting point for now.

  *   What is about the configuration aspect? In our implementation the configuration of equipment (~ Functional Resources) are part of the event sequence (we call it executable schedule), especially reconfiguration during a pass (track) should be part of it, no? Could this be the activation of a configuration profile (one or more?). Would it be possible to have a Functional resource 'station controller' providing a directive to activate a configuration profile?
eb> I think for things like the activation of a configuration profile this would indeed be something that SC-CSTS would orchestrate. I think this indeed could be a directive to the "station controller functional resource.

  *   Ladt but not least, at ESA we also allow missions to supply mission specific (predicted) events to the scheduling system; finally they are translated to time tagged directives, geared towards the supporting aperture (station with specific equipment).
eb> I think this bears further investigation. It sounds to me like the start of well-defined extension points for the event sequence.

Best regards,
Holger

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc

From:        "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
To:        CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Date:        12/10/2017 02:39
Subject:        [Smwg] Response to AI 2017-0512-16
Sent by:        "SMWG" <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>>
________________________________

CSSM Colleagues,

Attached please find the response to AI-2017-0512-16, "Provide strawman of proposed event sequence structuring". I propose to walk through the presentation at the next working group teleconference which is scheduled for next Tuesday, 17 October.

Best regards,
-Erik[attachment "Response to AI 2017-0512-16 (Event Sequence)-11-Oct-2017.pptx" deleted by Holger Dreihahn/esoc/ESA] _______________________________________________
SMWG mailing list
SMWG at mailman.ccsds.org<mailto:SMWG at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20171026/5cb51bb3/attachment.html>