[MOIMS-NAV-EXEC] FW: [CCSDS] PRM Test Plan

Sun Oct 9 14:38:31 UTC 2016

All:

Attached is the draft PRM Prototyping Test Plan that Fran and I have iterated on a couple of times. At the telecon last week I realized I had never sent it around to the group.

We will be discussing this material on Monday 17-Oct-2016.

Regards,
David

From: Fran Martínez Fadrique <fmartinez at gmv.com>
Date: Tuesday, September 6, 2016 at 12:06 AM
To: "Berry, David S (3920)" <david.s.berry at jpl.nasa.gov>, "Frank.Dreger at esa.int" <Frank.Dreger at esa.int>
Subject: RE: [CCSDS] PRM Test Plan

David,
Find attached the revised document with most proposed modifications accepted. Those remaining relate to questions that may require some additional interaction; in particular the decision to nominate the Test Judge and who should play this role depending on who is implementing the prototypes. There is also the definition of the test for the general pointing case (no template) that may have to be agreed rather than dictated.
Best regards,
Fran

From: Berry, David S (3920) [mailto:david.s.berry at jpl.nasa.gov]
Sent: lunes, 5 de septiembre de 2016 21:19
To: Frank.Dreger at esa.int
Cc: Fran Martínez Fadrique <fmartinez at gmv.com>
Subject: FW: [CCSDS] PRM Test Plan

Frank:  I should have copied you on this as well.

David

From: David Berry <david.s.berry at jpl.nasa.gov<mailto:david.s.berry at jpl.nasa.gov>>
Date: Monday, September 5, 2016 at 12:18 PM
To: Fran Martínez Fadrique <fmartinez at gmv.com<mailto:fmartinez at gmv.com>>
Subject: Re: [CCSDS] PRM Test Plan

Fran:

I've attached a copy of your draft test plan for the PRM with my comments and suggestions (in MS Word changes tracked) for your consideration.

I think we could be getting close (if you approve of my comments/suggestions). Maybe we can talk about this a bit during the telecon on Wednesday.

Regards,
David

From: Fran Martínez Fadrique <fmartinez at gmv.com<mailto:fmartinez at gmv.com>>
Date: Saturday, July 16, 2016 at 11:12 AM
To: David Berry <david.s.berry at jpl.nasa.gov<mailto:david.s.berry at jpl.nasa.gov>>
Subject: RE: [CCSDS] PRM Test Plan

Hi David,
Find attached the preliminary version of the test plan for the PRM.
It contains the approach for all templates.
The approach for section 5 requires some additional thoughts.
There are some yellow marks for the pieces of information that require some evolution of the situation (e.g. test entities)
Best regards,
Fran

From: Berry, David S (3920) [mailto:david.s.berry at jpl.nasa.gov]
Sent: jueves, 30 de junio de 2016 1:01
To: Fran Martínez Fadrique <fmartinez at gmv.com<mailto:fmartinez at gmv.com>>
Subject: Re: [CCSDS] PRM Test Plan

Fran:

Sounds good.  The sooner you can write up the notional Test Plan (brief) I can find the second prototyping Agency.

David

From: Fran Martínez Fadrique <fmartinez at gmv.com<mailto:fmartinez at gmv.com>>
Date: Wednesday, June 29, 2016 at 9:42 AM
To: David Berry <david.s.berry at jpl.nasa.gov<mailto:david.s.berry at jpl.nasa.gov>>
Subject: RE: [CCSDS] PRM Test Plan

Hi David,

Let’s try to converge on the approach and then close one of the outstanding actions. This may still be linked to other actions before the prototyping can really start but at least we’ll have the technical approach ready to go.

Agreed then to approach a prototyping scheme that does not require software development.

What you propose for section 4 can be made common for section 5. One definition of the pointing scenario, in the case of section 5 this means just one and in the case of section 4 it means one per template.
The rest of the procedure stays as you describe in your e-mail completed with the details on the steps in the procedure that I provided.
I think that the approach can be justified from the point of view that section 5 or each individual template mean to cover any possible pointing scenario and therefore prototyping 2 or more is equally representative as it is not possible to cover every possible case. Defining only one pointing scenario in each case and doing two independent implementation of the scenario should be sufficient to guarantee the approach and fulfill the requirement of two independent prototypes.

If you agree I can rework the procedures with this ‘simplified’ approach and send it back to you. Then we can probably think of distributing it for confirmation of the approach.

Best regards,
Fran

From: Berry, David S (3920) [mailto:david.s.berry at jpl.nasa.gov]
Sent: lunes, 13 de junio de 2016 1:01
To: Fran Martínez Fadrique <fmartinez at gmv.com<mailto:fmartinez at gmv.com>>
Subject: Re: [CCSDS] PRM Test Plan

Fran:

Sorry for the delay in responding to you... it is partly due to my very small budget and partly due to having spent some time thinking about what you have written.

I very much like the approach of avoiding software development, because I agree with you that is really "outside the standard".

I think the approach for Section 5 seems reasonable, and probably required, because it is a situation that by definition cannot be resolved with the templates.

For Section 4, I wonder if a viable approach might be the following. Step 1 is the similar to that of Step 1 for Section 5, i.e., a defining strategy of pointing, however, one that can be satisfied by using the templates.  This pointing strategy is sent to each of the prototyping agencies. Each prototyping agency fills in the template with values that satisfy the pointing strategy, the two agencies exchange the filled in templates, and then compare the message filled in by the other agency to the one they filled out. If the pointing strategy is well defined, and the templates are used properly, presumably the differences between the two messages would be either small or nonexistent. As a final step, the messages could be sent to the person who defined the strategy to confirm that the intent is satisfied.

This proposal for the prototyping of Section 4 also does not require software development; it also tests consistency of the templates I think.

Your thoughts?

From: Fran Martínez Fadrique <fmartinez at gmv.com<mailto:fmartinez at gmv.com>>
Date: Monday, May 23, 2016 at 7:50 AM
To: David Berry <david.s.berry at jpl.nasa.gov<mailto:david.s.berry at jpl.nasa.gov>>
Cc: "Frank.Dreger at esa.int<mailto:Frank.Dreger at esa.int>" <Frank.Dreger at esa.int<mailto:Frank.Dreger at esa.int>>
Subject: [CCSDS] PRM Test Plan

David:

As part of action #7, this is my initial approach for the prototyping (test plan) of the PRM.

Main driver: no software development required, at least not for the conversion of the PRM into actual attitude or telecommand timelines. This of course unless ESOC software can be easily tailored for this purpose in which case we may select some of the cases below to be ingested by the software; but this must be analysed separately in more detail with Frank.
In some cases it may be necessary to actually read the XML document to perform some basic operations as part of the coding and decoding of the messages. This can be done easily using e.g. Excel and then refer to the read fields for the computations. OF course other more sophisticated alternatives should be left to the discretional decision of the prototype implementers.

I’ll use the terms emitter for the entity generating the requests and receiver for the entity receiving and interpreting the request.

I hope this stablishes CCSDS acceptable basis for the prototyping of the PRM. In the end I believe it should be a proof of concept and use rather than a software exercise and this has been my rationale for the processes defined below.

Best regards,
Fran

The steps to follow for the templates in section 4 are:

1.       Select the template subject of the prototyping (there is one test for each template)

2.       Define in human language the characteristics of pointing associated with the selected template. Of course the description is bound to specific template in use but it should identified as minimum. This step is formal and shall be properly documented in writing.

a.       For the definition part of the pointing request message

                                                               i.      All header and general metada information is provided (e.g. ORGINATOR, TIME_SYSTEM, OBJECT_NAME,…) according to their mandatory property.

                                                             ii.      The reference frames involved in the pointing process. Certainly the root frame and subsequently any additional secondary frame as required

                                                            iii.      Define the trajectories of the objects involved in the proves

                                                            iv.      Define the pointing direction

                                                             v.      Define the direction to be pointed

                                                            vi.      The start and end times of the applicable attitude time line.

All the definitions should be such that cover all the relevant parameters of the definition section of the pointing requests, including units in which the parameters are provided as well as the representation when applicable. The definition must also take into account those elements that are fully defined in the definition section and those whose definition must be completed in the pointing request data section.

b.       For the data request part of the pointing request message

                                                               i.      The attitude timelines defined for the request. In this case it is the prototype decision to define the number of timelines and their start and end. Actually part of the prototyping exercise is to demonstrate that receiver of the message can interpret not only the static part of the request but also the dynamic part regarding the evolution of the pointing.

                                                             ii.      The completion of the pointing elements whose definition is left open in the definition section (e.g. where to point the boresight)

3.       Implement the template filling the parameters with the values intended for the test as the result of converting the human language into the actual message parameterisation. In this process of the prototyping it is important to note:

a.       It shall be possible and consistent to fill all parameters that have the same name with the same value.

b.       The same property having the same value within the template shall not be identified by two different parameter names (this does not prevent that occasionally some parameters may have the same value).

c.       There are no parameters defined whose value cannot be unambiguously defined. This includes that all parameters have sufficient information regarding their representation (e.g. deg or rad) and units.

d.       There are no parameters in the definition sections that are not used, directly or indirectly, in the pointing data section.

e.       There are no references in the pointing data sections that have no corresponding parameter in the definition section (or element containing the parameter directly or indirectly).

f.        All properties required to define the pointing have a parameter that can receive the information.

g.       No parameter at the end of the process is left without an assigned value.

4.       Send the PRM to the receiver. We are not testing transmission but it would be good if as part of the process it is ensured that

a.       When sending by e-mail the XML files is not removed by the e-mail service. Some firewall and spam filters do

b.       A CRC of some kind is generated to ensure completeness and consistency of the delivered message. Since there is no schema to use as confidence check, this simple approach may help to provide an initial consistency check (even with a schema it would be useful for the sake of formality)

5.       The receiver must interpret the message back to human language taking into account

a.       The template being used. This information need to be figured out by the receiver and it is a fair assumption that both emitter and receiver know the type of message being exchanged.

b.       The information contained in the exchanged message only. No other context information or ICD should be required for the proper interpretation of the message at this level. Exceptions may be made for the most complex templates provided that the need is clearly identified by the emitter when preparing the message.

c.       The interpretation of the received message is formal and shall be documented in writing.

d.       The receiver shall verify the same details as the emitter in 2.a above.

6.       Send the human interpretation of the message back to the emitter to verify is interpretation by the receiver.

The steps to follow for the templates in section 5 are essentially the same as for a template taken from section 4 but with the freedom of the emitter to define a message of his/her own without the constraints of the template. I believe that in this case it is more relevant to prototype the procedure in section 5 rather than focusing on the actual contents of an specifically generated message (that of course must also be tested in similar way as the template cases for completeness and consistency). The steps to follow are then the following:

1.       Define a strategy of pointing to be constructed following the steps in section 5. This is a formal process to be documented in human terms in writing.

2.       Follow the steps in section 5 to construct the message. The steps in section 5 must be taken as steps in a procedure where some may optional and ins some there may be branching depending on the select strategy for the type of pointing (e.g. pointing to a celestial body, to another satellite or inertial causes some elements to be optional and to branch or skip sections in chapter 5)

3.       Check the message for completeness and consistency in similar terms as for the template cases described above.

4.       Submit the message similarly as for those generated using templates.

5.       The receiver shall decode the message back to human interpretation. This is a formal step to be implemented in writing.

6.       Send the human interpretation of the message back to the emitter to verify is interpretation by the receiver.

P Please consider the environment before printing this e-mail.
________________________________
This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it.
________________________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener información clasificada por su emisor como confidencial en el marco de su Sistema de Gestión de Seguridad de la Información siendo para uso exclusivo del destinatario, quedando prohibida su divulgación copia o distribución a terceros sin la autorización expresa del remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboración.
________________________________
Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informação confidencial, de acordo com nosso Sistema de Gestão de Segurança da Informação, sendo para uso exclusivo do destinatário e estando proibida a sua divulgação, cópia ou distribuição a terceiros sem autorização expressa do remetente da mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o remetente e apague-a. Obrigado pela sua colaboração.
________________________________

P Please consider the environment before printing this e-mail.
________________________________
This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it.
________________________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informaci�n clasificada por su emisor como confidencial en el marco de su Sistema de Gesti�n de Seguridad de la Informaci�n siendo para uso exclusivo del destinatario, quedando prohibida su divulgaci�n copia o distribuci�n a terceros sin la autorizaci�n expresa del remitente. Si Vd. ha recibido este mensaje err�neamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboraci�n.
________________________________
Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informa��o confidencial, de acordo com nosso Sistema de Gest�o de Seguran�a da Informa��o, sendo para uso exclusivo do destinat�rio e estando proibida a sua divulga��o, c�pia ou distribui��o a terceiros sem autoriza��o expressa do remetente da mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o remetente e apague-a. Obrigado pela sua colabora��o.
________________________________

P Please consider the environment before printing this e-mail.
________________________________
This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it.
________________________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informaci�n clasificada por su emisor como confidencial en el marco de su Sistema de Gesti�n de Seguridad de la Informaci�n siendo para uso exclusivo del destinatario, quedando prohibida su divulgaci�n copia o distribuci�n a terceros sin la autorizaci�n expresa del remitente. Si Vd. ha recibido este mensaje err�neamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboraci�n.
________________________________
Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informa��o confidencial, de acordo com nosso Sistema de Gest�o de Seguran�a da Informa��o, sendo para uso exclusivo do destinat�rio e estando proibida a sua divulga��o, c�pia ou distribui��o a terceiros sem autoriza��o expressa do remetente da mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o remetente e apague-a. Obrigado pela sua colabora��o.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20161009/4f23719e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 509x0y1_20160715-prm-test-plan_20160906.doc
Type: application/msword
Size: 183296 bytes
Desc: 509x0y1_20160715-prm-test-plan_20160906.doc
URL: <http://mailman.ccsds.org/pipermail/moims-nav-exec/attachments/20161009/4f23719e/attachment.doc>