[Smwg] Response to AI 2017-0512-16

Thu Nov 2 08:44:14 UTC 2017

Hi Erik,
We had a little discussion at about your response on the event sequence, I 
try to give some give a consolidated feedback. In our discussion we saw 
the event sequence rather as a sequence of states than of events. Looking 
at your example of the  1-way tracking to 2-way-tracking transition 
confirmed our understanding that something like 2-way-tracking is perhaps 
rather a state than an event.

As a rough picture we thought that the definition of state machines 
providing valid state sequences is a good start (as you point out below). 
However, we believe that the inputs to the state machine should conform in 
a way to the events (predicted or real time) and directives provided by 
the FR model. We do not believe that this imposes an all or nothing 
approach, it rather ensures consistency and that it can be implemented; 
the CSTS-MD and CSTS-SC clearly (will) rely on the FR model parameters, 
events and directives. Finally these state sequences and underlying state 
machines form a layer on top of the FR model.

When thinking further we thought that the FR model by definition has to 
provide all events observable on ground (e.g. receiver looses lock), 
including the CLCW related information like the on-board lock. Likewise 
the FR model abstracts all actions in form of directive you can execute on 
ground, as well as parameters reflecting the state. As such it has to be 
kind of complete, no?

Wolfgang also pointed out a number of things like
- compound directives 
- ways to switch part of the configuration

If I understand correctly, the latter is taken care of by separating the 
static and dynamic aspects of configuration profiles.

Let's discuss.

Kind 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>
To:     "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>
Cc:     CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Date:   27/10/2017 00:59
Subject:        RE: [Smwg] Response to AI 2017-0512-16

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> 
To:        CCSDS Service Mgmt WG <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> 

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
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.

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/20171102/f277e401/attachment.html>