[Smwg] FW: SMWG: Planning Format Book - Test cases

Mon Jun 15 19:19:48 UTC 2015

Dear Karen,

See our mails below regarding test cases for Planning Book. The respective presentation for the telecon (with more or less the same information as below) I uploaded to CWE:

http://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Planning%20Information%20Book/Prototyping/ActionItem2015-0327-13_Planning_Book_Test_Cases.pptx

I allowed myself to create a subfolder "Prototyping" in Planning Book folder.

Btw. I will try to call in on Thursday, but currently it's 50/50 chance I will make it.

Best Regards
Marcin

From: Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Freitag, 29. Mai 2015 03:12
To: Gnat, Marcin
Subject: RE: SMWG: Planning Format Book - Test cases

Marcin,

Thanks for the inputs and thoughts.  I think :).

I think the first thing to keep in mind is that we are not yet writing any kind of service specification but really just a data format specification. There is a strong tendency of course to make sure we support any eventual service. So if we keep that in mind then I think then the request part of it is definitely a phase 3 type activity. And I think this is perhaps going to be an activity that comes quite a bit later than the main prototyping of the output format. The reason I say that is that we have to first agree on the abstract engineering and then get down to specifics. I know that in the case of the DSN there are a lot of details and options that can be put in the request but those probably don't look very much like what ESA may come up with for more of the "standing orders" type approach. Therefore I think this is going to require some sorting out before we can get into what the prototyping for the request aspect looks like. With any luck, perhaps you can join us on the June 2 teleconference and we can at least touch upon this a bit. I will note that the agenda is getting to be rather "explosive"  in that it will very unlikely be able to fit within the two hour window as there are lots of requests for various topics of discussion and developments to go over in CCSDS.

Best regards,

-Erik

From: Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de> [mailto:Marcin.Gnat at dlr.de]
Sent: Wednesday, May 20, 2015 11:26 PM
To: Barkley, Erik J (3970)
Subject: SMWG: Planning Format Book - Test cases

Hi Erik,

Next week is the due date for the test cases for the Planning Book. As you probably noticed due to my absence in last telecons, I am currently pretty busy with projects and other work here, so no time for CCSDS stuff. Next week also I'm on a vacation, so I will not be able to really work on that. Starting back in June (I hope) I can spend some time for CCSDS finally.

Anyway, just as a starting point for the considerations:

-          For the Simple Schedule Book we've had three phases of testing, manual, tool-supported and "special use" (meaning in this case the unallocated time).

-          Assuming we do testing only of the planning events use case, we may try to go for something similar like above:

o   Phase 1: Manual phase (with creation of the event file manually, either with Notepad or XMLSpy or so) just to give the testing parties the "first feeling". This phase may be keept short, something like two test cases per prototyping side.

o   Phase2: Tool-Supported phase (with some more or less automated conversion tools which convert between internal and CCSDS file formats). This we may elaborate into several test cases and maybe even use cases for the events:

*  Small number of events vs. large number

*  Specific time frame

*  Deeps Space, LEO, GEO events

*  Routine events vs. LEOP events

*  Usage for scheduling, mission planning, etc...

-          How do we want to handle the request? Should it be integral part of the above tests? I would actually go for that, in such a case we may introduce an intermediate test phase where we "just" check the compatibility (I do not know if I use here really the word I want to use ;-), I hope you get what I mean) between the request and the planning information (events). Other possibility would be to test the request as a separate test phase (would be the phase 3 in my above list) where we say "Tool-supported request-reply".

-          Important thing to decide (by us, but maybe by the prototyping parties) is the handling of the request -> means do I just get the request, process it manually (human eyes) and then produce the planning information or explicitly have a prototype software which receives a request file and respectively generates a planning information according to request? The second case is definitely more elegant, but involves definitely some more effort (and for me also would mean involving our Flight Dynamics). On the other hand, we have to test only the interface, so as long the reply fits to the request, prototyping should not care much how one got there? Or?

Best regards

Marcin

--------------------------
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
German Aerospace Center
Space Operations and Astronaut Training | German Space Operations Center (GSOC) | Communications and Ground Stations | Oberpfaffenhofen | 82234 Wessling | Germany

Marcin Gnat | Ground Data System Manager
Telephone +49 (8153) 28 3201 | Telefax +49 (8153) 28 1456 | marcin.gnat at dlr.de<mailto:marcin.gnat at dlr.de>
www.DLR.de<http://www.dlr.de/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150615/3edf9b41/attachment.html>