<font size=2 face="sans-serif">Hi Erik,</font>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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?</font>
<br>
<br><font size=2 face="sans-serif">Wolfgang also pointed out a number of
things like</font>
<br><font size=2 face="sans-serif">- compound directives </font>
<br><font size=2 face="sans-serif">- ways to switch part of the configuration</font>
<br>
<br><font size=2 face="sans-serif">If I understand correctly, the latter
is taken care of by separating the static and dynamic aspects of configuration
profiles.</font>
<br>
<br><font size=2 face="sans-serif">Let's discuss.</font>
<br>
<br><font size=2 face="sans-serif">Kind regards,</font>
<br><font size=2 face="sans-serif">Holger </font>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Barkley, Erik
J (3970)" <erik.j.barkley@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Holger.Dreihahn@esa.int"
<Holger.Dreihahn@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">CCSDS Service Mgmt
WG <smwg@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">27/10/2017 00:59</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">RE: [Smwg] Response
to AI 2017-0512-16</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3 color=#004080 face="Georgia">Holger,</font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia">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.</font>
<br><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 color=#004080 face="Georgia">Best regards,</font>
<br><font size=3 color=#004080 face="Georgia">-Erik</font>
<br><a name=_MailEndCompose></a><font size=3 color=#004080 face="Georgia"> </font>
<br><font size=3 face="Calibri"><b>From:</b> Holger.Dreihahn@esa.int [</font><a href=mailto:Holger.Dreihahn@esa.int><font size=3 face="Calibri">mailto:Holger.Dreihahn@esa.int</font></a><font size=3 face="Calibri">]
<b><br>
Sent:</b> Tuesday, October 17, 2017 4:50 AM<b><br>
To:</b> Barkley, Erik J (3970) <erik.j.barkley@jpl.nasa.gov><b><br>
Subject:</b> Re: [Smwg] Response to AI 2017-0512-16</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=3 face="Arial">Erik,</font><font size=3 face="Times New Roman">
</font><font size=3 face="Arial"><br>
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:</font><font size=3 face="Times New Roman"> </font>
<br><font size=3 color=#004080 face="Georgia">eb> Yes, in general, there
needs to be connection with the FRM. Just what that looks like is still
rather TBD. </font>
<ul>
<li><font size=3 face="Arial">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.</font><font size=3 face="Times New Roman">
</font></ul><font size=3 color=#004080 face="Georgia">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. </font>
<br><font size=3 color=#004080 face="Times New Roman"> </font>
<ul>
<li><font size=3 face="Arial">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.</font></ul><font size=3 color=#004080 face="Georgia">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. </font>
<br><font size=3 face="Times New Roman"> </font>
<ul>
<li><font size=3 face="Arial">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.</font><font size=3 face="Times New Roman">
</font></ul><font size=3 color=#004080 face="Georgia">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.</font>
<ul>
<li><font size=3 face="Arial">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?</font></ul><font size=3 color=#004080 face="Georgia">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. </font>
<br><font size=3 face="Arial"> </font>
<ul>
<li><font size=3 face="Arial">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).</font></ul><font size=3 color=#004080 face="Georgia">eb>
I think this bears further investigation. It sounds to me like the start
of well-defined extension points for the event sequence. </font>
<br><font size=3 face="Arial"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=3 face="Arial"><br>
Holger</font><font size=3 face="Times New Roman"> <br>
</font><font size=3 face="Arial"><br>
Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=3 color=blue face="Arial"><u>http://www.esa.int/esoc</u></font></a><font size=3 face="Times New Roman">
<br>
<br>
<br>
</font><font size=3 color=#5f5f5f face="Arial"><br>
From: </font><font size=3 face="Arial">"Barkley,
Erik J (3970)" <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=3 color=blue face="Arial"><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=3 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=3 color=#5f5f5f face="Arial"><br>
To: </font><font size=3 face="Arial">CCSDS Service
Mgmt WG <</font><a href=mailto:smwg@mailman.ccsds.org><font size=3 color=blue face="Arial"><u>smwg@mailman.ccsds.org</u></font></a><font size=3 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Date: </font><font size=3 face="Arial">12/10/2017
02:39</font><font size=3 face="Times New Roman"> </font><font size=3 color=#5f5f5f face="Arial"><br>
Subject: </font><font size=3 face="Arial">[Smwg]
Response to AI 2017-0512-16</font><font size=3 face="Times New Roman">
</font><font size=3 color=#5f5f5f face="Arial"><br>
Sent by: </font><font size=3 face="Arial">"SMWG"
<</font><a href="mailto:smwg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Arial"><u>smwg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Arial">></font><font size=3 face="Times New Roman">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Times New Roman"><br>
<br>
</font><font size=3 face="Georgia"><br>
CSSM Colleagues,</font><font size=3 face="Times New Roman"> </font><font size=3 face="Georgia"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Georgia"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Georgia"><br>
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.</font><font size=3 face="Times New Roman">
</font><font size=3 face="Georgia"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Georgia"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=3 face="Georgia"><br>
-Erik[attachment "Response to AI 2017-0512-16 (Event Sequence)-11-Oct-2017.pptx"
deleted by Holger Dreihahn/esoc/ESA] </font><font size=3 face="Courier New">_______________________________________________<br>
SMWG mailing list</font><font size=3 color=blue face="Courier New"><u><br>
</u></font><a href=mailto:SMWG@mailman.ccsds.org><font size=3 color=blue face="Courier New"><u>SMWG@mailman.ccsds.org</u></font></a><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg"><font size=3 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</u></font></a><font size=3 face="Courier New"><br>
</font>
<br><font size=3 face="Courier New">This message and any attachments are
intended for the use of the addressee or addressees only.</font>
<br><font size=3 face="Courier New">The unauthorised disclosure, use, dissemination
or copying (either in whole or in part) of its</font>
<br><font size=3 face="Courier New">content is not permitted.</font>
<br><font size=3 face="Courier New">If you received this message in error,
please notify the sender and delete it from your system.</font>
<br><font size=3 face="Courier New">Emails can be altered and their integrity
cannot be guaranteed by the sender.</font>
<br><font size=3 face="Courier New"> </font>
<br><font size=3 face="Courier New">Please consider the environment before
printing this email.</font>
<br><font size=3 face="Courier New"> </font>
<br>
<br><PRE>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.
</PRE>