<font size=2 face="sans-serif">Hi Erik,</font>
<br><font size=2 face="sans-serif">Thanks for the opportunity to join the
discussion. Having a second thought about the request and the discussed
option to attach constraints to the provided services I was considering
the following:</font>
<br>
<br><font size=2 face="sans-serif">- for the request itself constraints
make sense to express flexibility, something like 'I need a an 8-10h pass
starting earliest at 12h, latest start at 14h.</font>
<br><font size=2 face="sans-serif">- for the services within the pass I
am not that convinced (anymore):</font>
<br><font size=2 face="sans-serif"> \
not all required details might be known at request time</font>
<br><font size=2 face="sans-serif"> \
according to my experience missions want to prescribe an exact timing when
services (uplink, ranging, doppler measurement etc.) are provided within
a pass</font>
<br>
<br><font size=2 face="sans-serif">In our network we now at pass request
time the set of required services, the station capability in terms of service
provisioning and perform the booking (station allocation plan). However,
at that point in time some details for the service provisioning within
the pass are not known. Typically at a later stage missions provide (often
by providing mission specific events) the details, which allows the production
of executable station schedule, which actually refines the station allocation
plan into a more detailed schedule which logically contains the service
provision times (and parameterisation) of the provided services within
a pass. In addition to that there may be the need to update the pass allocation
timing at a later stage based on updated orbital predictions.</font>
<br>
<br><font size=2 face="sans-serif">I would expect that scenario to be typical
for network: Resources (station and others) are booked quite in advance.
At this time often not all information (e.g. orbital predictions) is available
at the finally required precision to actually schedule station services
correctly. If that is true, shouldn't we reflect that in the abstract service
request, i.e. simplify it to what's needed. In our network the equivalent
of the service agreement captures the rules when services are provided
within a pass, often this is done by referring mission specific events.
Now I do not know exactly, but I would expect the sequence of events to
provide a similar sort of functionality.</font>
<br>
<br><font size=2 face="sans-serif">As such it looks to me we are mixing
up two problems: Station (resources) allocation and service scheduling
within the allocated passes. Is that necessarily a good idea? I think this
is a fundamental point we need to discuss. According to a discussion with
Martin the resource allocation request need the outlined flexibility to
facilitate better resource exploitation. Services within a pass have to
be provided according to precise timings with agreed and validated (parameterised)
setup.</font>
<br><font size=2 face="sans-serif">The resource allocation is typically
an input to mission planning, which results later in the details required
to provide the service within the allocated resource booking.</font>
<br>
<br><font size=2 face="sans-serif">For the constraints of the request itself
I would rate composition (black diamond) as the right way of doing it.
For service specific constraints (or details, rules or what it will be)
I tend to agree that those should be references to, ja, do not know exactly
but some (static) configuration like the rules captured by the service
agreement. </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">"Chamoun, Jean-Pierre
(GSFC-458.0)[Affiliate] (jean-pierre.chamoun@nasa.gov)" <jean-pierre.chamoun@nasa.gov>,
"Marcin.Gnat@dlr.de" <Marcin.Gnat@dlr.de>, "Colin.Haddow@esa.int"
<Colin.Haddow@esa.int>, "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">01/07/2015 03:38</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Abstract service
request telecon notes</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="Calibri">Colin, Marcin, JP, Holger,</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Attached are the notes from our June 30
splinter session teleconference on engineering an abstract service request.
The notes have also been uploaded to the CWE. Corrections and/or comments
appreciated.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Best regards,</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">-Erik[attachment "2015-06-30-AbstractSvcReq-TeleconferenceNotes.docx"
deleted by Holger Dreihahn/esoc/ESA] </font>
<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>