[cssm] Fw: DDOR configuration template

Tue May 26 14:49:00 UTC 2020

Hello

Quick answers to your comment.

1) DDOR patterns used operationally ALL follow that pattern:
Start = BOT + time to execute any previous scan + fixed time margin to 
point to the next target.
End =   BOT + time to execute any previous scan + fixed time margin to 
point to the next target. + duration of the scan.

I can not remember anything else since ESTRACK has started providing DDOR 
services for multiple agency. This pattern is a de-facto standard.

If someday, someone as the very unusual need to have target with odd 
absolute time computation, he just need to send multiple single target 
request. Mentioning absolute time (computed from the formula above). In 
the past, request template was written with absolute time, with the only 
result of producing copy/paste/manual editing incoherency with no added 
value.

What matter for DDOR is that all stations start/end at the same time. 
Absolute time is the outcome of the process, not an input.

Their is no outgoing station for DDOR. DDOR is DL only.

2) The receiver_2 refers to the on board receiver. This information drives 
the which DL frequency and DDOR tones that will be used for that support. 
I agree that to be more generic, the element <receiver> could be rename to 
something more neutral. e.g <configuration> 
It is safe to assume that most satellites will have more than one 
transponder and/or DDOR tones options.

3) I assume that the SMURF already specify the aperture(s) requested.
My draft cover only the information which are needed to specify a DDOR 
support within a SMURF.

Regards
________________________________________
Martin UNAL
Ground Operation Manager
Ground Facilities Ops HSO - ONO
H-376
ESOC
Robert-Bosch Strasse 5
64 293 Darmstadt
Germany
Tel +49 6151 90 2959 
________________________________________

From:   "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>
To:     "EXTERNAL-Unal, Martin P (9110-Affiliate)" <Martin.Unal at esa.int>
Cc:     "CCSDS Service Mgmt WG" <smwg at mailman.ccsds.org>
Date:   21/05/2020 23:43
Subject:        RE: [cssm] Fw: DDOR configuration template

Dear Martin,

Now that I finally have a copy of what you sent to Colin, of course, I 
have some comments :-)

First, the instance document is not quite proper XML -- at least as Oxygen 
on this end looks at it. Please see the screenshot below. Attached is what 
I believe to be a properly formed version of the instance document. 

To set the context, as I recall, the basic question was whether or not we 
needed to look at another standard or augmentation to the SMURF to 
accommodate the interagency ground sequence for conducting a DDOR 
observation. I think the answer tends to be yes to the general question 
here. Presumably the spacecraft event sequence will cover when DOR tones 
are on/off but then of course there is the scan pattern and that has to be 
coordinated between multiple agencies. I think the instance you have 
submitted is a step in the right direction.  Here are some comments, 
questions, observations:

1.      It seems like this is something of a cross between a template and 
a fully stated instance. For each of the targets to be in the scan 
pattern, there appears to be a presumption that the scan will start at BOT 
plus the delay. Is it fair to assume that the DDOR supports for a mission 
will always fit this kind of pattern?  I suspect the answer is no and that 
there are either multiple patterns.  At a minimum, depending upon whether 
the groundstation is the "incoming" groundstation with regard to 
communications geometry or the "outgoing" groundstation then this would 
probably also have to have something that is stated as the offset relative 
to the EOT? Or perhaps we should think about allowing absolute times to be 
stated?
2.      Recevier_2 -- this seems like an internal concern to the 
implementation -- I think for international standard the main thing would 
be to have the scan pattern identified and not which particular 
(open-loop) receiver is being used.
3.      Given that DDOR requires a fair amount of interagency coordination 
and there are constraints with regard to communication geometries and 
quasar of visibility, should there be some sort of provision for 
indicating the ground stations involved in this? I'm not sure that this is 
really needed but then again it does seem like if we are doing this 
interagency the data standard has to allow for being very precise and 
clear as to the exact apertures being requested to support the scan 
pattern -- that of course could be indicated in the aperture constraints 
of the SMURF.

Assuming you can attend our teleconference on May 26, I look forward to 
discussing this further.

Best regards,
-Erik

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of 
Colin.Haddow at esa.int
Sent: Thursday, May 7, 2020 08:18
To: smwg at mailman.ccsds.org
Subject: [EXTERNAL] [cssm] Fw: DDOR configuration template

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

----- Forwarded by Colin Haddow/esoc/ESA on 07/05/2020 17:17 ----- 

From:        Martin Unal/esoc/ESA 
To:        Colin Haddow/esoc/ESA at ESA 
Cc:        Holger Dreihahn/esoc/ESA at ESA 
Date:        06/11/2019 17:24 
Subject:        DDOR configuration template 

Hello

I have drafted a proposal of xml layout for DDOR support based on our 
experience on ESTRACK 

This need to be tune to the SMURF, but all the element of information 
shall be there. 

>From our operational experience, using the formulare in the magenta leave 
room to build invalid contradicting entries. 
And it did happen many time. 

This minimum set of value, together with the element contain in the SMURF 
request could be used to write the old text format in the magenta book 
(see below) to support backward compatibility if needed. 

For memory 

C1 EXAMPLE 1 
<Maven-Abbrev>_DDOR_2014_228_2014_250_v2.des 
$ddorGroundObservationsEventSequence 
RequestId = 2014-205T15:50:00; 
FormatVersion = 1; 
orginatingOrganization = DSN; 
MissionId = <Maven-Abbrev>; 
$START 
ddorConfigProfileId = 202F2; 
ScIndex____ScId____DorOn____DorOff = 
SC01 <Maven-Abbrev> 2014-228T02:25:00 2014-228T03:25:00 
; 
QuIndex____QuId____QuFlux = 
QU01 P_1504-167 0.52 
; 
TrkStnId____TrackStart____TrackEnd = 
<Site1>-<Apper1> 2014-228T02:25:00 2014-228T03:25:00 
<Site2>-<Apper2> 2014-228T02:25:00 2014-228T03:25:00 
<Site3>-<Apper3> 2014-228T02:25:00 2014-228T03:25:00 
; 
DdorEpoch = 2014-228T02:25:00; 
ScanNum____ScanSource____ScanStart____Duration = 
1 SC01 00:00:00 00:01:00 
2 QU01 00:03:00 00:05:00 
3 SC01 00:10:00 00:06:00 
4 QU01 00:18:00 00:07:30 
5 SC01 00:27:30 00:06:00 
6 QU01 00:35:30 00:07:30 
7 SC01 00:45:00 00:06:00 
8 QU01 00:53:00 00:05:00 
; 
$END 
$START 
ddorConfigProfileId = 202F2; 
ScIndex____ScId____DorOn____DorOff = 
SC01 <Maven-Abbrev> 2014-250T01:25:00 2014-250T02:25:00 
; 
QuIndex____QuId____QuFlux = 
QU01 P_1519-273 1.12 
; 
TrkStnId____TrackStart____TrackEnd = 
<Site1>-<Apper1> 2014-250T01:25:00 2014-250T02:25:00 
<Site2>-<Apper2> 2014-250T01:25:00 2014-250T02:25:00 
<Site3>-<Apper3> 2014-250T01:25:00 2014-250T02:25:00 
; 
DdorEpoch = 2014-250T01:25:00; 
ScanNum____ScanSource____ScanStart____Duration = 
1 SC01 00:00:00 00:01:00 
2 QU01 00:03:00 00:05:00 
3 SC01 00:10:00 00:06:00 
4 QU01 00:18:00 00:07:30 
5 SC01 00:27:30 00:06:00 
6 QU01 00:35:30 00:07:30 
7 SC01 00:45:00 00:06:00 
8 QU01 00:53:00 00:05:00 
; 
$END 
$$EOF

Regards
________________________________________
Martin UNAL
Ground Operation Manager
Ground Facilities Ops HSO - ONO
H-376
ESOC
Robert-Bosch Strasse 5
64 293 Darmstadt
Germany
Tel +49 6151 90 2959 
________________________________________ 
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).[attachment 
"DDOR-request-element-eb.xml" deleted by Martin Unal/esoc/ESA] 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200526/2d8f2230/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 99281 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200526/2d8f2230/attachment-0001.png>