[Css-csts] Re: prototypes updates

Wed Jul 31 12:56:09 EDT 2013

Fabienne,
I can't see any way around mandating that the Provider clearly specify the FR instance number for each parameter and event. My original concept for functional resource names (several years ago) used text strings that might be considered more "user friendly" (e.g., "Return Carrier: X-Band") but over time this concept evolved to the current {OID:FR Instance Number} concept, on the grounds that it is less prone to "typing" errors (e.g., defined as "Return Carrier" but entered in the subscription as "ReturnCarrier") and not requiring specification of a syntax for FR Names.  But even if we kept the text-based FR Names the Provider would still have to ensure that each parameter or event is tagged with the correct name. 

Regarding your concern about whether the user will be able to unambiguously relate a FR Name (FR Type plus Instance Number) to its user-friendly name: when the Mission establishes a Configuration Profile with a Provider, each component of the Configuration Profile that corresponds to a Functional Resource Type and a text identifier parameter (e.g., carrierProfileId). This identifier can be set to whatever the Utilization Management (i.e., the Mission) finds useful for characterizing that Configuration Profile component - for example,  "X-Band Return Carrier". When that Configuration Profile is used to schedule service, Complex Management (or to use the new SCCA-ADD term, Provision Management (PM)) sends the scheduled Service Package Result to UM. The Service Package Result identifies each Functional Resource instance with both the text name of the Configuration Profile component and the Functional Resource Name of the corresponding Functional Resource instance. As long as UM retains the Service Package Result that is sent by PM (UM can also query PM for a re-send), UM has the mapping between the user-friendly text name and the formal, OID-based FR Name.

I attempted to demonstrate how this works in section 7 of the" Functional Resources for Cross Support Services"` technical note (http://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Functional%20Resources/FunctionalResources_TechNote-TN-0.02-2013-05-30.docx). This section needs to be updated but the general idea is described. 

Some changes that I plan to make in the next update (which I plan to make available prior to the fall meeting) are:
1.	Align the example with the most-recent set of FR Types, Parameter Labels, and Events Labels;
2.	Use the Functional Resource Types in the Service Package Results, in addition to the Instance Numbers (which are called functionalResourceInstance and serviceInstanceNumber in the version posted on the CWE). When I originally wrote this section I thought that it would be sufficient for the instance numbers to be present, because UM could know the FR Type by other means. However, including the FR Type eliminates some effort and more importantly removes some chance for misinterpretation. 
3.	Put a text identifier in every Configuration Profile component that corresponds to an FR instance. As currently documented in the tech note last fall,  if a configuration profile component has a one-to-one relationship with another configuration profile component that *does* have a text identifier, no separate text identifier is supported. For example, CCSDS 401 states that a carrier has at most one subcarrier. In the tech note (and, coincidentally, in SCCS-SM-B-1) the Carrier Profile gets and text name but its subcarrier does not because I previously assumed that by the Service Package Result structure the FR instance text name could be inferred from the relationship between the carrier and subcarrier. That is, if the carrierProfileId is "X-Band Return Carrier" then the name of its subcarrier could be inferred to be "X-Band Return Subcarrier". However, this requires some UM process (human or automated) to walk the Service Package Result structure and make these inferences. 

Best regards,
John

-----Original Message-----
From: Fabienne.Delhaise at esa.int [mailto:Fabienne.Delhaise at esa.int] 
Sent: Wednesday, July 31, 2013 10:28 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org; Lassere Francois; Margherita.di.Giulio at esa.int
Subject: RE: [Css-csts] Re: prototypes updates

dear John et al.

>we have all agreed to add the option to ask for the Functional Resource 
>Type
in the GET invocation list-of-parameters, Cyclic Report START invocation list-of-parameters, and Notification START invocation list-of-events.
[Fabienne] this seems to me a good idea (by analogy with the decision taken for parameter name and label)

>For the MD-CSTS, the derived Behavior specification will require that 
>the
Provider send all parameters or events of *all* instance of that Functional Resource Type _in the Service Package_.
[Fabienne] OK with me but can we mandate (i.e. force) the provider to "clearly" specify the FR instance number which is associated to each returned parameter.  I would see a problem if all parameters or events values are returned by the provider and the user could not differentiate which parameter belongs to which FR instance number.  Also the user should be be able to map each FR instance number to the service production (e.g.  "1" is RAF in X-band and "2" is RAF in Ka band)

Best regards
Fabienne

  From:       John Pietras <john.pietras at gst.com>                      

  To:         "Margherita.di.Giulio at esa.int" <Margherita.di.Giulio at esa.int>, "Lassere Francois"
              <Francois.Lassere at cnes.fr>                               

  Cc:         "css-csts at mailman.ccsds.org" <css-csts at mailman.ccsds.org>

  Date:       31/07/2013 15:13                                         

  Subject:    RE: [Css-csts] Re: prototypes updates                    

  Sent by:    css-csts-bounces at mailman.ccsds.org                       

Margherita,
Regarding the MD-CSTS, I will try to get the update on the CWE sometime next week. I assume that we have all agreed to add the option to ask for the Functional Resource Type in the GET invocation list-of-parameters, Cyclic Report START invocation list-of-parameters, and Notification START invocation list-of-events. When Functional Resource Type is used as the argument in list-of-parameters or list-of-events (respectively), the standard behavior will be that the Provider will send the values for all parameters or events
(respectively) of the single instance of that Functional Resource Type that is associated with the CSTS that executes the procedure. This is the nominal definition, and the gist of the last set of CSTS SFW modifications that I sent to Yves.

For the MD-CSTS, the derived Behavior specification will require that the Provider send all parameters or events of *all* instance of that Functional Resource Type _in the Service Package_.

Best regards,
John