[Css-csts] RE: When does the 'productionConfigured' event notification get sent?

[John Pietras]

Yves,
I think that it would be helpful to the reader to clarify that the 'production configured' notification is sent only upon transition out of'halted' . This could be done either with a NOTE or by changing the changing the definition of 'production configured' to something like "following the halting of the production process, the Production Status has been returned to Configured. Unless otherwise specified ..."

Also, this email exchange reminded me of a suggestion that I made last August (see the copy of the email at the end of this message) in which I suggested that production status be given "special term" status and have initial caps (Production Status) because it is formally and normatively defined in Annex A. If that suggestion is accepted, then the various instances of "production status" should be changed to 'Production Status".

Finally, there are still a number of references to the "production-status parameter" in the SFW, although it was removed from the book as a parameter (see our email exchanges between 6 August and 12 September of last year). These reference should be changed. Many (perhaps most) can be fixed by simply changing "production-status" or "production-status parameter" to "Production Status". However, a larger fix is needed in section 2.2.4.2:
"The status of the service production resource is reported by means of the production-status parameter and is made available to all service instances accessing the same production resource.  The CSTS Specification Framework defines the permissible values of production-status and the transitions between these values in abstract terms; these values may be refined by service specifications based on the Framework.  Service specifications may also define substates for one or more of the production-status values where appropriate.

Production status changes are notified to the Service User via the Notification procedure (see 4.8) or via associated NOTIFY operations included in other procedures.  The current value of the production-status may be obtained using the Cyclic Report procedure defined in 4.7, if that is supported by the service.

The states of the production process, the permissible state transitions, and the effects of these states on common operations are described in annex A."


1.       The first sentence of the first paragraph is incorrect, because it refers to the non-existent production-status parameter. It should be deleted. Also, the second sentence could be modified to read "The CSTS Specification Framework defines the permissible values of the status of the service production resource and the transitions ...", but that is not strictly necessary.



2.       The second sentence of the second paragraph is incorrect - the Framework Cyclic Report procedure currently makes no provision for reporting Production Status. This sentence should be removed. (Of course, any derived service could add it, but it would have to be as an extension parameter to that service.)


3.       Regarding the "effects of these states on common operations" (the third paragraph), in Annex A:

a.       NOTE 1 states "The notification 'production operational' is only sent to those service instances that were not yet notified since the most recent BIND operation of the 'operational' status and/or were notified of a production-status different from 'operational'." First, for this to be an NOTE (that is, informative) it would have to reflect behavior that is normatively stated elsewhere in the book. It sounds like the intent of this is to make each service instance send a 'production operational' notification at the start of whatever procedure is sending notifications, but I can't find any normative statement to this effect. Second, how can the production process know which service instances were or were not notified since their most-recent BINDs?  Third, I don't think that this makes sense for the Buffered Data Delivery procedure, since the notifications are put in the shared Recording Buffer regardless of the states of the services instances that pull data from it.

b.      NOTE 2 states "The notification 'production interrupted' is only sent to those service instances that are affected by the possibly transient production fault."  If this is normative behavior of the production process then it should be stated normatively. How does the production process know which service instances are affected by an interruption? And again, I don't think that this will work for the Buffered Data Delivery procedure.

c.       The sentence "When the production-status parameter value is 'halted' the BIND operation is rejected" is not phrased as a NOTE, but should be because Annex A is a normative annex and therefore all non-NOTEs are supposed to be normative statements. Also, a cross-reference to the relevant normative requirement (3.4.2.3.1 (h)) would be helpful.

Best regards,
John

From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Monday, May 13, 2013 2:41 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: Re: When does the 'productionConfigured' event notification get sent?

Dear John,

The table A-1 (I will correct the label) is a copy from the CLTU book (Table G-1) and is not in line with the text discussed in CSTS. I will correct the table A-1 to allow the agreed notification 'production configured'.

Regarding the transition from unknown state (the twilight zone), I agree with you and I do not see a need to add a notification that would never be sent. Do you think we should add a statement?

Best regards
Yves

From:

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

To:

"Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>" <Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>>

Cc:

"CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)" <css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>>

Date:

25/04/2013 17:32

Subject:

When does the 'productionConfigured' event notification get sent?


________________________________



Yves,
Section 3.10.2.2.3.2 includes the four standard Production Status-related events, including 'production configured'. However, the table in Annex A (labeled "4-40" in the March CSTS SFW draft but it should be A-1) states that there is no notification when Production Status transitions from 'halted' to 'configured', which is the only transition into 'configured' that is addressed by the table.

Figure A-1 also shows the transition from an unknown state (the Twilight Zone?) into 'configured', which theoretically could be accompanied by the productionConfigured notification. But, practically speaking, will a CSTS ever be active before it's association production process is even configured? In other words, will the productionConfigured notification ever be sent?

Of course, the notification *could* be sent on the transition from 'halted' to 'configured', but this is explicitly ruled out by the table. Why was it decided to not send a notification on this transition?

Thanks.

Best regards,
John

________________________________

From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Tuesday, August 21, 2012 8:57 AM
To: Yves.Doat at esa.int
Cc: css-csts at mailman.ccsds.org
Subject: [Css-csts] RE: deprecated production-status parameter?

Yves,
I agree with your proposal, with one additional proposal - that production status have initial caps (Production Status) to indicate its "special term" status. We have used this approach elsewhere in the CSTS SF (some cases that come immediately to mind are Transfer Buffer and Release Timer). (Perhaps it would also be useful to add it to the Additional Definitions in section1.6.1.4.)

Best regards,
John


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130513/0ea839a1/attachment-0001.htm