[Css-csts] Additional questions arising from the MD-CSTS update exercise

[John Pietras]

CSTSWG colleagues ---
At the Bordeaux meeting last week we discussed a number of issues involving the Monitored Data service (as well as others). Two of the decisions that were made that affect the MD-CSTS were:

1.       The monitored parameters and notifiable events for the MD-CSTS will *not* be specified in the MD-CSTS specification itself, but rather they will be documented in the SANA registry under the MD-CSTS Provider Functional Resource Type node under crossSupportFunctionalities.

2.       If the MD-CSTS (or any other service) refines the meaning of Production Status (thus affecting the interpretation of the four standard Production Status-related notifications), the refinement is to be documented by treating the procedure that handles those refined production status notifications as a refined procedure. This in turn requires that the service specification contain a section dedicated to the refined procedure to explain the refinements.

In the process of updating the MD-CSTS specification to reflect these decisions I have come across some questions and issues as a result.


A.      How is the scope of the events and parameters accessible by a procedure instance of a service defined? The MD-CSTS has access to all parameters and events of all Functional Resources executing in the same Service Package as the MD-CSTS instance. However, this is not the normal case. Normally,  the GET, NOTIFY, and Cyclic Report TRANSFER-DATA operations of a CSTS will be confined to the individual instance of that CSTS - i.e., to that specific CSTS Provider Functional Resource instance. Do our specifications need to normatively define the scope of parameters and events available to the services, and if so, how?

One way to make the scope normative is to refine every procedure in a service that contains the Cyclic Report procedure or any procedure that contains the GET and/or NOTIFY operations. Unfortunately, the would essentially eliminate to possibility of directly adopting any such procedures that would otherwise be unchanged from the CSTS SFW.

Another approach would be to insert/modify requirements in the CSTS SFW to make the normative scope of the operations limited to the service instances (Functional Resource instance) with notes that derived services can change the scope. For example, the following requirement could be added to the specification of the GET operation list-of-parameters definition: "Unless otherwise specified by a procedure using this operation, the valid parameter names and Functional Resource Name shall be constrained to the Functional Resource instance of the service instance implementing the operation." With this approach, "normal" CSTSs can directly adopt the operations/procedures without need for modification. This would require the MD-CSTS to derive its procedures to override the scope limitation, but that still isolates the changes to just the MD-CSTS.

Is this something that we should be concerned about?


B.      Can a service have "private" extension parameters or notifiable events for its extended procedures? By "private" I mean ones that can be reported/accessed/emitted by the procedures of the service but that are not "published" (that is, not available to the MD service). As currently supported by the Framework, if a service directly adopts a Framework procedure that has its own set of notifications (e.g., BDD), that service specification does not inherently publish those notifications. Such publication would require an explicit registration in SANA in order for it to be accessible to the MD-CSTS. For example, assume a new Return Space Packet service that uses the BDD procedure. The 'end of data' event is not available to the MD service until the [[{Return Space Packet} : {end of data}] Event Label is registered with SANA. If (for whatever reason) it is decided that the 'end of data' notification should only be reported by the service itself but not be available to the MD service, that that is enforced by not publishing the  [[{Return Space Packet} : {end of data}] Event Label in the SANA registry.

Now consider the case of a Meteorology CSTS with a derived BDD procedure that adds a new 'sun has set' event. The *only* place that we currently have for a service to specify the OID for the 'sun has set' event is the Meteorology CSTS Provider FR Type node under crossSupportFunctionalities, and by definition, anything there is automatically published and available to the MD CSTS.

Is that a problem? I can't think of a reason that it would be a problem, but I thought that I would bring it up now (as we enter the last big push for Red-2) in case anyone can think of a reason that it might be important. And even if such an event is nominally published in this manner, it doesn't require any Complex to actually make it available via the MD-CSTS (another good reason for categorizing the published list as "recommended" but not "required").

This is not an issue for the MD-CSTS, which does not define any new parameters or events.


C.      How to specify extension events for extended parameters? In Bordeaux, we agreed that a CSTS specification did not need to specify the published parameters and events associated with that service - they would be recorded in the SANA registry only. However, in thinking more about that decision, I believe that it might have been biased by the fact that the only notifications under consideration (for MD-CSTS) were the standard production status-related ones that are inherited from the Framework. There is also the case where a derived procedure adds event notifications that are directly related to new behavior associated with new Incoming Events. For example, in Bordeaux we discussed the possibility of a derived BDD procedure adding new incoming events. Any event notifications associated with such incoming events should be explicitly defined in the service specification and not just left to the SANA registry. In this case, the derived procedure would define the extension events and reference the Object Identifiers annex of the specification for the allocation of the OIDs to those events.

This is also not an issue for the MD-CSTS.


D.      Should refinement of parameter and event definitions be indicated in the SANA registry? In the process of refining the meaning of the four production status-related notifications for the MD-CSTS, I realized that those refinements apply only to the definitions as they pertain to production of the MD service. Production status events for other services (e.g., RAF) still have their own service-specific definitions when they are reported via the MD Notification procedure. As it stands now, the user of the MD service would have to understand every service specification to know which services have refined the meanings of parameters and events that it uses from frameworkIdentifiers. Alternatively, the SANA registry template could include a provision for noting that a parameter or event definition has been refined. If there is concern about synchronizing the definitions of the refinements between specifications and the SANA entries, the SANA entries could simply identify that the definition has been reformed and reference the service specification for the exact nature of the refinement.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130425/af347e11/attachment.html