[Css-csts] Questions regarding absence of mdProdConfigurationChange event and mdSetContrParams directive - updated version

[John Pietras]

CSTSWG colleagues ---
Earlier today I had responded to some of Wolfgang’s comments on the MdCstsProvider FR. After sending the email, I came across a statement in the MD-CSTS Blue Book that has caused me to modify my response with respect to the mdProdConfigurationChange event. In my earlier email (below), I said that I had excluded the mdProdConfigurationChange event because of the previous interpretation of MD service production, but that the new interpretation justified inclusion of the mdProdConfigurationChange event. However, my recollection was faulty, as I discovered after having sent the email. The actual reason for excluding the mdProdConfigurationChange event was stated in the last paragraph of  section 8.1 of the MD-CSTS book:

“The Monitored Data service supports the production-status parameter and the production status change event. However, the Monitored Data service does not support the production configuration change event because it is redundant with information that is already available through the MD service.”

The thinking was that since the mdProdConfigurationChange event only indicates that “something” had changed without even identifying the FR instance much less the specific configuration  parameter, the assumption was that the user of the MD service would instead use the On-Change-Option Cyclic Report procedure of the service to monitor the reconfigurable parameters of the monitored FRs, which would identify the exact parameters and FR instances that had changed. If that is still a valid assumption, then there is no need to include the mdProdConfigurationChange event. However, if the WG decides that the mdProdConfigurationChange event is desired anyway, it can be added.

Unless the WG decides that the mdProdConfigurationChange event should be included even though it provides less information than is available through the MD service procedures, this event will continue to be excluded.

Best regards,
John


From: John Pietras
Sent: Monday, November 30, 2020 12:31 PM
To: CCSDS_CSTSWG (css-csts at mailman.ccsds.org) <css-csts at mailman.ccsds.org>; Wolfgang Hell <wo_._he at t-online.de>
Subject: Questions regarding absence of mdProdConfigurationChange event and mdSetContrParams directive

CSTSWG colleagues,
In Wolfgang’s review (below) of the updates that I made to “my” Tier-1 FRs, he observed that I had included neither the mdProdConfigurationChange event nor the mdSetContrParams directive for the MdCstsProvider FR. When we discussed this comment very briefly during last week’s telecon I agreed to revisit the issue. The following paragraphs discus the various issues. For each of the issues, I have highlighted by underline the direction that I intend to take unless otherwise decided by the WG.

First, let me address the absences of the mdSetContrParams directive. As I noted during last week’s brief discussion, the procedures that comprise the MD service (Association Control, On-Change-Option-Cyclic Report (derived from Cyclic Report), Information Query, and Notification) all have configuration parameters that are static (not dynamically reconfigurable). The configurable parameters of the MdCstsProvider FR consist of these static configuration parameters PLUS one other configurable parameter – mdResponseTimeout, which is the service-specific version of the response-timeout parameter mandated for all CSTSes in 3.2.1.2 of (the forthcoming) CSTS SFW B-2. In defining and requiring the presence of the response-timeout parameter, SFW B-2, is mute on the point of whether or not the parameter is dynamically reconfigurable. Because this parameter represents a mutually-agreed value between service user and service provider about when an abort situation exists, my belief is that this should be a static configuration parameter. If that is the consensus of the WG, then there would be no dynamically-configurable parameters of the MD service and thus no need for the mdSetContrParams directive. If the WG decides that response-timeout parameters such as mdResponseTimeout should be dynamically reconfigurable, then the mdSetContrParams directive would be added with the clarification that it applies only to mdResponseTimeout.

Unless the WG decides that the response timeouts should be dynamically reconfigurable, I will continue to exclude an mdSetContrParams directive.

NOTE – it might be worth considering adding an additional sentence, clause, or clarification to 3.2.1.2 of the SFW to reflect the decision regarding the dynamic modifiability of the response-timeout parameters, e.g., add to the end of 3.2.1.2 the sentence “The value of the response-timeout parameter shall | shall not be dynamically configurable while the service instance is bound.” When to include this change will depend on Tom G’s preparation of the SFW for release for CESG polling.


Now turn our attention to the mdProdConfigurationChange event. Originally, (and this is the way it is written in the B-1 version of the MD-CSTS book), I had envisioned a Monitored Data Collection FR to represent the functionality of making the parameter values and events of all FR instances of a Service Package available to the MD service instance. As part of this approach, the production status of the MD service was defined to be strictly and solely the resource status of the MD Collection FR. The motivation for this definition was, frankly, to avoid having to define what an operational production status would be for the MD service when in a sense the true production comprised all of the FRs in the Service Package. The MD Collection FR would have no configuration parameters (hence, no need for an mdProdConfigurationChange event)

Subsequently, I had difficulty justifying the existence of the MD Collection FR, in particular as something that an ESLT would have to “implement” – there was nothing to configure, and its resource status (its only reportable parameter) was itself vaguely and circularly defined. So I deleted the MD Collection FR.

But that deletion re-raises the question that I had tried to abstract away with the MD Collection FR, namely, what is the production status of the MdCstsProvider FR? We not only have address this for the FR definition in the Tier-1 FR SANA registry but also in the upcoming revision of the MD book itself.

My current thinking is to treat the production status of the MD service instance as essentially the status of the Service Package as a whole:

Configured – mdProdStat has the value ‘configured’ when qualified parameters can be generated and event notifications can be emitted for the functional resources that comprise the Service Package. NOTE -The intention of defining “configured” this way is to give the ESLT implementation flexibility in defining when the individual actual resources transition among unconfigured to configured to configured. If the MD service instance is able to report something for every FR in the Service Package, even if that something is ‘unavailable’, then the Service Package – and therefore mdProdStat - is considered to be configured.

Operational - mdProdStat has the value ‘operational’ when the functional resources of the Service Package that are needed to be operational at that given time are all operational. NOTE - The “at that given time” phrase allows the provider the flexibility to, for instance, internally transition resources that aren’t needed at the beginning of the execution of the Service Package from configured to operational later in the execution of the Service Package on a just-in-time basis.

Halted - mdProdStat has the value ‘halted’ when one or more of the functional resources of the Service Package that should be operational at that given time has been halted.

Interrupted - mdProdStat has the value ‘interrupted’ when one or more of the functional resources of the Service Package that should be operational at that given time has been interrupted.

If these interpretations of MD production status acceptable to the WG, I will reflect them in the MdCstsProvider definition in the Tier-1 data set and in Issue-2 of the MD book.

Now, finally, this change in the interpretation of MD production has the corollary reinterpretation of the mdProdConfigurationChange event, in which the change of any configuration parameter in any functional resource instance in the Service Package triggers the event.

I will therefore include the mdProdConfigurationChange event in the MdCstsProvider definition in the Tier-1 data set, defined as above.

NOTE that there is still some ambiguity here:

-        Should the event be emitted if any of the FRs in the whole Service Package has a parameter change, regardless of whether the FR being changed is operational at the time, or supposed to be operational at the time?, or

-        Should the event notifications occur only for configuration changes in FRs that should be operational at the given time?
I think that we can leave this detail to the individual  implementations, but if anyone has any strong feelings one way or another it would be appropriate to raise them now.

I look forward to your comments.

Best regards,
John

From: Wolfgang Hell [mailto:wo_._he at t-online.de]
Sent: Wednesday, November 25, 2020 5:06 AM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>; Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>
Subject: Re: Tier 1 frm file with my updates


Dear John,

Thank you for the updates. Please find some comments in red font inserted into your original message.

Best regards,

Wolfgang


Am 23.11.2020 um 18:46 schrieb John Pietras:

Dear Holger and Wolfgang,

I have updated "my" FRs in the attached file in accordance with the decision made in the WG. I used as the base for my changes the file that Wolfgang sent on 10 November. But before I summarize the changes that I made, I would like to thank Wolfgang for adding the new OperatorNotify event to all of the FRs - I was expecting to have to update "my" FRs.

So here are the changes that I have made:



1.      OfflineFrameBuffer

1.      Changed the OfflineFrameBufferRetentionPolicy parameter choice from ‘never’ to ‘storageLimited’ WH: Because of the CHOICE, in case of never, no engineering unit applies, while in case of timeLimited the engineering unit is hour. In such case I filled in the Engineering Unit field with "N/A / hour". I'm not sating that one has to do it that way - I can also live with leaving the Engineering Unit field blank. But a uniform approach would be nice. Also, to make the ASN.1 as informative as possible, I suggest to add a comment to the timeLimited element specifying the applicable engineering unit. Perhaps I'm overly ambitious by always trying to specify a value range constraint that looks realistic for the specific parameter. LongIntPos is certainly more than ever needed.

2.      Deleted the PurgePriority, PurgeCessationThreshold, PurgeWarningThreshold parameters and PurgeWarningEvent event, as we decided that they were overkill


2.      TdmRecordingBuffer – deleted the RetentionPolicy parameter as overkill (it will simply be FIFO)



3.      MdCstsProvider WH: It occurs to me that the event mdProdConfigurationChange is missing as well as the directive mdSetContrParams.

1.      Changed ddSvcProductionStatus to tdProdStat WH: I can see that you have applied the necessary changes, but apparently you did not run the "Create ASN.1 / XSD types" function. Therefore the Type Definition in the Property view has not been updated and still shows the obsolete type definition MdSvcProductionStatus     ::= SvcProductionStatusVersion1. This also affects the other changes listed below, where Md and Td got mixed up.

2.      Changed type of TdProdStat to ProdStat (was ProdStatV1), no longer external OID for the type

3.      TdProdConfigurationChangeEvtValue type has been changed to ProdConfigurationChangeEventValue, which is defined in the Module as ‘NULL’) (TdProdConfigurationChangeEvtValue had previously been cast directly as ‘NULL’).


4.      TdCstsProvider – same changes as for MdCstsProvider



In moving the MD and TD FRs to SFW V2, we can delete the ProdStatV1 type from the Module, but I did not do that. In the past there were problems with the cross-references when things were changed in the Module. I think that Holger fixed that, but I wasn’t sure. If it is okay to delete that type, Holger, would you please do it? Thanks. WH: On that occasion we shall also remove the no longer needed import of the types from an external ASN.1 module.



Best regards,

John



-----Original Message-----
From: Wolfgang Hell [mailto:wo_._he at t-online.de]
Sent: Tuesday, November 10, 2020 3:54 AM
To: Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>; John Pietras <john.pietras at gst.com><mailto:john.pietras at gst.com>
Subject: Tier 1 frm file updated as per our "Three-way" discussion



Dear Holger and John,



As agreed in yesterday's telecon I have updated the Tier 1 frm file in accordance with the outcome of our discussion. We concluded that in the context of CCSDS 401 there is no need to explicitly reference the FR instance generating the forward carrier. However, given that spacecraft may have more than one forward link typically each of them operating in a different frequency band, one should know to which of the forward links the return signal is coherent. This could be indicated by simply stating the frequency band of the "coherency" forward link.

Alternatively one can express this by means of the transponder ratio.

This option has the advantage that this covers also multi-spacecraft arrangements where those spacecraft share the same forward physical channel, but use different SCIDS or VCID sets or APID sets. In order to get separate return physical channels in the same frequency band, one can use non-standard transponder ratios. Therefore the transponder ratio parameter shall permit the specification of non-CCSDS transponder ratios. At this point we cannot exclude that in the context of CCSDS 415 a different mechanism will be necessary for identifying the forward link to which the given return link is coherent. We agreed that we will work that out when the CCSDS 415 related FR types will be specified, but we will not worry about it in the context of the Tier 1 and Tier 2 FRM delivery.



Please find attached the Tier 1 frm file modified as outlined above.



Best regards,



Wolfgang


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20201201/2e3ac9a3/attachment-0001.htm>