[Css-csts] prime and secondary instances of the same procedure
John Pietras
john.pietras at gst.com
Tue Feb 5 08:21:00 EST 2008
Yves,
Thanks for your reply. I had not looked at the 0.12 version of the
Procedures Definition before I sent my note (at least, not in regard to
this particular point). I'm glad that we came to the same conclusions.
Regarding "optional" - what I perhaps should have used was "maximum
allowed". That is, I don't think that we have any way of enforcing, for
example, a user to start, say, three instances of a particular secondary
procedure, only that the service must allow up to the specified number
of secondary procedure instances.
But I think that we still do have the "optional" issue that we discussed
last time - that is, how to support different levels of what is the same
base service. I plan to send a note out later today that will attempt to
summarize the issue as we discussed it last time and perhaps offer some
further suggestions for discussion tomorrow.
Best regards,
John
John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct: +1-240-542-1155
GST Main: +1-301-474-9696
Fax: +1-301-474-5970
> -----Original Message-----
> From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
> Sent: Tuesday, February 05, 2008 2:49 AM
> To: John Pietras
> Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
> Subject: Re: [Css-csts] prime and secondary instances of the same
> procedure
>
>
> Dear John,
>
> I have to admit that I did not write anything in the MoM. However,
reading
> at
> the draft 0.12 of the Recommendation I came to the same conclusion as
you:
> there is no reason to prevent a secondary procedure to be of the same
type
> as
> the prime.
> The Recommendation 0.12 states:
> 4.4.2.5.2 The procedure-instance-identifier of the prime procedure
shall
> be
> set to 0
> 4.4.2.5.3 The procedure-instance-identifier of the secondary
procedures
> shall
> be set to an incrementing number starting with 1.
> 4.4.2.5.4 Each secondary procedure type has its own incrementing
> procedure-instance-identifier
> Therefore your assumption for the Monitoring service looks reasonable
to
> me.
>
> Regarding the profile description in the MoM.
> Appendix A.3 defines a service where a derived procedure is prime.
> Appendix
> A.4 defines another service where a private procedure is prime. Those
two
> services defines the derived/private procedure to have two instances
and
> for
> me one instance is prime and the other is secondary.
> In your text you come to the same conclusion but you state that the
> secondary
> derived/prime procedure is optional. We did not discuss "optional"
> procedure
> instances and as I did not think about that possibility and so far I
> cannot
> conclude. My only concern about "optional" is that it may add
complexity
> in
> the specification and implementation.
>
> I hope this clarifies the matter, nevertheless we should address the
point
> tomorrow during the teleconference.
>
> Best regards
>
> Yves
>
>
>
>
> "John Pietras"
> <john.pietras at gst.
> com>
> To
> Sent by: <css-csts at mailman.ccsds.org>
> css-csts-bounces at m
> cc
> ailman.ccsds.org
>
> Subject
> [Css-csts] prime and secondary
> 04/02/2008 22:52 instances of the same
procedure
>
>
>
>
>
>
>
>
>
>
> Members of the CSTSWG ---
> I am in the process of updating the Monitored Data CSTS White Book.
You
> may recall that the version that we reviewed in Heppenheim had two
> different procedures derived from the Cyclic Report Procedure: the
Prime
> Monitor Cyclic Report Procedure and the Secondary Monitor Cyclic
Report
> Procedure [note - the names have been updated to reflect the name
change
> at Heppenheim from "Cyclic Data Delivery" to "Cyclic Report"].
>
> The sole purpose for defining two derived procedures was the
prohibition
> against having prime and secondary procedures of the same type. I seem
> to recall a discussion of this issue in Heppenheim, but my notes don't
> contain any information about the issue and I can't find anything
about
> it in the official MoM written by Yves. I would like to summarize what
I
> thought was the discussion, and I hope that some of you can confirm
that
> we discussed it and add any details (especially regarding resolution)
> that you might recall.
>
> Here is how I recall the discussion going:
> I explained that the only reason for the two versions of the Cyclic
> Report procedure was that we needed one instance to be the prime
> procedure but that there needed to be the possibility of multiple
> secondary procedures, and the Toolkit restriction that there could be
> only one instance of a procedure if it is prime forced me to create
two
> different derived procedures. Someone else in the CSTSWG then said
that
> perhaps the prohibition was unreasonable and should be dropped. I then
> noted that if we reserve the procedure instance number "1" to be used
> only by prime procedures, then it would be possible to distinguish the
> single prime instance of a procedure from any other secondary instance
> of that same procedure, without having to create different procedures.
>
> As I said, I don't have the notes to support these recollections, and
in
> particular I don't remember if we came to any decisions.
>
> For the purposes of the next version of the Monitored Data CSTS White
> Book, I am assuming that the approach outlined above is to be taken.
>
> As agreed in Heppenheim, I will use Yves' Service Profile table as the
> basis for the table in section 3 (Monitored Data Cross Support
Transfer
> Service Composition). In the Profile Example that Yves presented in
> Heppenheim (Annex A of the Heppenheim MoM), section A.2 includes an
> example Service Profile table that is the basis for the table that
will
> appear in the XXX CSTS Composition sections of the various service
> specifications. In this Service Profile table, for each procedure that
> is used in the service, there are rows to designate: (a) the version
of
> the procedure used in the service; (b) whether the procedure is prime
or
> secondary; and (c) the number of instances that can appear.
>
> In Yves' example tables in sections A.3 and A.4, he shows a "Derived
> Procedure 1" and "Private Procedure 1" (respectively) designated as
> prime ("P") with "Nb of service instances" = 2. I don't remember how
> this was intended to be interpreted, but clearly there can't be two
> prime procedure instances. However, one interpretation that can be
taken
> that would be consistent with the notion of allowing both prime and
> secondary instances of the same procedure would be as follows:
> 1 - If the "Prime/Secondary" row reads "P" (prime), then the "Nb of
> instances" has to contain at least "1". If it has a number greater
than
> 1, then it is assumed that the other instances are optional secondary
> instance.
> 2 - If the "Prime/Secondary" row reads "S" (secondary), then the "Nb
of
> instances" has to contain at least "1", but whatever number has is
> assumed to be the maximum number of optional secondary instances.
>
> For the next draft of the Monitored Data CSTS White Book, I will
> populate the Monitored Data Cross Support Transfer Service Composition
> table according to the above interpretation unless directed otherwise.
>
> Best regards,
> John
>
>
> _______________________________________________
> Css-csts mailing list
> Css-csts at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
>
More information about the Css-csts
mailing list