[Css-csts] production status and the complete mode of the Buffered Data Delivery procedure

[Martin Götzelmann]

Dear John,

I need to correct one point of my e-mail: I notice that row 9 of the BDD procedure state table also deals with production status changes. You certainly right that the procedure in complete mode does not deal with these events at the time they occur, but as these events are part of the specification, I feel we cannot just silently remove them from the state table for the complete mode. Could we enter "ignore" and add a note that the notification will be added to the RC?

Martin

From: Martin Götzelmann
Sent: 17 March 2013 11:23
To: 'John Pietras'; CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: RE: [Css-csts] production status and the complete mode of the Buffered Data Delivery procedure

Dear John,

Here are some initial thoughts concerning your observations.

My understanding of the intended behaviour is exactly as you describe it.

I think we need to distinguish between 'interrupted' and 'halted' . Interrupted is supposed to be of transient nature. In the scenario you describe, what would happen would be that the latest transfer buffer would be transmitted once the timer has expired and then no more data would be sent. When the provider recovers from the transient fault then data would be sent again and if there was data loss due to the interruption, then the notification would be inserted in the stream where the fault occurred. If the provider was not able to insert anything into the RC at the time of failure I would expect he does so at the time the fault is cleared.

The situation is different when the fault persists. In that case the PS should be set to halted and according to the current specification adopted from SLE the notification would be inserted into the RC. Again the transfer buffer would be sent when the timer expires but then nothing more would happen.

We do distinguish between events that notified synchronously and events that are notified asynchronously and the SFW says that this is defined by the procedure. As far as I can see the BDD says that all events are notified synchronously. One could consider notifying the 'production halted' event asynchronously, such that the user is informed at the time the event occurs. On the other hand, a Service can always add an instance of the cyclic report procedure by which the user can monitor the PS and other relevant parameters or query them when he does not receive data any more.

The BDD adds only two events (end of data, data discarded due to ...) and these must be clearly synchronous. The 'end of data' event is covered by row 7 of the state table and the 'data discarded event' cannot occur in complete mode. It is not clear to me why the BDD also deals with events that might be added by derived procedures. I do not think we do that in other procedures and I feel it is problematic as we cannot really anticipate what the type of event and the suitable behaviour should be. I would therefore suggest to remove that event and to remove clause 4.5.3.2.6 as this is a statement that just repeats the general concept of derivation. If we do this then row 9 indeed becomes superfluous and should be removed.

Regards, Martin

From: css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org> [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 15 March 2013 19:53
To: CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)
Subject: [Css-csts] production status and the complete mode of the Buffered Data Delivery procedure

CSTSWG colleagues ---
I mentioned in my previous email that while updating the TD-CSTS book I had come across some issues regarding production status and the complete mode of the Buffered Data Delivery procedure.

Let me start by stating my understanding of what the intended behavior is. Assuming that that understanding is correct, I'll then explain the issues that I've encountered.

My understanding of the intended behavior is that when the production status changes, the associated notifications are placed into the Recording Buffer. The effect is that when a complete-mode BDD instance pulls the notification from the Recording Buffer and sends a production change notification to the user, that notification doesn't necessarily have anything to do with the production status at the time that notification is being transferred.

Assuming that's the intent, here's my first issue. Since the Recording Buffer (RC) is part of production, what happens if for some reason the RC becomes disabled? As described, a 'production interrupted' notification should be popped into the RC, but even if the RC is capable of ingesting data it still can't pass the data to the BDD instance.

I looked again at the BDD specification in the December CSTS SFW for some possible help, but there too I found some issues in the BDD state table. There are two rows in the state table that deal with production status change, rows 8 and 9. The first  incoming event in both rows is 'production status change', but it is pretty clear from the context that the intent is that row 8 applies when the procedure is in real-time mode, and row 9 applies to the complete mode.

Let's consider row 9 first. Row 9 deals with data going into the Recording Buffer from upstream production. This is the state table for the Buffered Data Delivery "Service" provider, but putting a notification into the RC is independent of the state of the CSTS that implements the BDD procedure, and indeed the CSTS could be in no state at all. So I don't think that row 9 even belongs in this state table. The only way that the CSTS (procedure) instance deals with production status notifications is when it pops those notifications out of the Recording Buffer in the same way that it deals with "data" (or Service Production Data Units), which is covered by the 'data read from recording buffer' event (row 4). [However, this still does address or solve the issue of how to react to the interruption/halting of the Recording Buffer itself.]

Row 8 (real-time mode) covers the only case in which a CSTS instance "sees" a production status change when it actually occurs.

The final issue has to do with "derived procedure events" There are really two kinds of derived procedure events, although the BDD specification doesn't always keep the distinction clear. The first kind is the Service Production Event Notification, which is generated by service production and affects the data that is available to all services instances associated with that production process. The second kind of notification, which I'll call "procedure instance-generated", is related to the individual CSTS instance, like 'end of data'.

For the real-time mode, row 8 already covers both cases - there's no need to distinguish between Service Production Event Notifications and procedure instance-generated notifications because they are all occurring in real-time.

For the complete mode, the Service Production Event Notification case is covered by row 4, as described above. That is, the only way the procedure instance deals with the Service Production Event Notifications is when they come out of the Recorded Buffer.

But the state table does *not* cover procedure-generated notifications when the service/procedure is in complete mode. The behavior with regard to a procedure-generated notification should be that it should be put in the Transfer Buffer as soon as it is generated. This may cause a momentary delay in the transfer of data from the Recorded Buffer, but that doesn't matter because it is the complete mode. The state table should cover this case. At a quick look, it appears that the action would be the similar to that for row 4, substituting "notification" for "data". It may also require bringing out the distinction between Service Production Event Notifications and procedure instance-generated notifications in the normative behavior text.

I look forward to your comments.

Best regards,
John

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