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

[John Pietras]

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/20130315/f4ef6da8/attachment.html