[Css-csts] SFW BDD updates - some initial conclusions

Fri May 13 15:57:38 UTC 2016

Dear CSTS colleagues,

In following up on my note "SFW BDD procedure specification issues - 
your feedback is solicited" that I have sent to the CSTS WG on May 6, in 
the meantime Margherita, Holger and I discussed the matter further. The 
purpose of this note is to inform you of the conclusions we reached 
during that discussion. We all regard that as a good way forward, but 
you are still invited to provide your thoughts and preferences regarding 
this matter.

Except for the 'recording buffer overflow' event, the BDD procedure does 
not specify if and which events shall be captured in the recording 
buffer for later retrieval from that buffer by a BDD procedure instance 
operating in 'complete' delivery mode. Such specification shall be part 
of the CSTS specification which shall in addition specify the exact 
characteristics of the recording buffer type to be used for that service 
type.

Events associated with the production process that generates the data to 
be stored in the recording buffer will in general be emitted by the 
Functional Resources representing that production process. The CSTS type 
specific recording buffer type will identify the FR types from which 
such event notification shall be accepted for storing them in the 
recording buffer. Recall that it is up to the individual implementation 
to decide to which extent the capabilities of the Functional Resources 
as listed in the dedicated SANA registry will be supported. As a 
consequence, even in cases where a CSTS specification mandates the 
recording of certain events, a given implementation may not be able to 
do so because the FR capabilities are only partially supported. 
Therefore, in a CSTS specification the recording of these events will 
always be optional and this will be represented that way in the ICS 
proforma. Users shall then check the ICS of a given implementation to 
find out if and to which extent the CSTS specified recording and 
playback of such events is supported.

As concerns the production status of a CSTS, it always refers to the 
status at the current time. Taking a service using the BDD procedure in 
complete delivery mode as an example, production status could change 
from operational to interrupted in the event that the recording buffer 
is no longer accessible. However, none of the events possibly stored in 
the recording buffer has any effect on the production status. The 
production status is always associated with the CSTS instance itself and 
therefore a parameter of the Functional Resource representing the 
service instance.

As to have a clear distinction between the status and events reported by 
Functional Resources representing the or a part of a production process 
and the status reported by Functional Resources representing CSTSes, the 
former will be referred to as "resource status" and "resource status 
change", respectively, while the latter retain the classifiers used so 
far, i.e. "production status" and "production status change". The 
production status change event is therefore named after the Functional 
Resource representing the CSTS. Any resource status change event will be 
named after the Functional Resource that emitted that notification. This 
implies that the 'recording buffer overflow' event will be named after 
the recording buffer FR.

Given that the BDD procedure has dynamically modifiable configuration 
parameters, it also needs to be able to notify such configuration 
change. This event is of course named after the procedure. All this was 
specified already in the SFW, but in the state table the associated 
incoming event and the actions to be taken in response to that event 
were missing.

The permissible values of production status and the high level semantics 
of these values are now specified in an enhanced annex A of the SFW. So 
far the specification of the semantic was "hidden" in the definition of 
the event-value to be used when notifying a production status change. 
CSTS specifications may extend the production status, e.g. by 
introducing substates. CSTS specifications shall state how the 
production status value is determined, e.g. by calculating an aggregate 
status based on the resource status of the FRs involved in service 
production while the CSTS instance is 'alive'. In complete mode, this is 
therefore restricted to the recording buffer resource status and 
possibly some CSTS internal status information.

In terms of functionality not yet tested by the prototype, the handling 
of notifications read from the recording buffer is missing. Given that 
there isn't really a difference except for the FR name in the way the 
'recording buffer overflow' event and any other event recorded in the 
recording buffer are handled, it is sufficient when we add to the test 
cases the reading of the 'recording buffer overflow' event from the 
recording buffer and its processing by the BDD procedure.

As to illustrate the consequences of the changes that John and I are 
proposing (see my above mentioned email) I have taken a crack at 
implementing those changes and have uploaded an SFW version modified 
accordingly (mostly the BDD procedure and annex A changed) to the CWE. 
The file is called 921x1r2 20160511 
<http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20and%20Concept/921x1r2%2020160511.doc> 
and it is in the folder Cross Support Services Area (CSS) 
<http://cwe.ccsds.org/css>> Documents 
<http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?View=%7B8045374D-F8E0-4356-83CA-993252A38FE8%7D>> 
CSS-CSTS 
<http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS&View=%7B8045374D-F8E0-4356-83CA-993252A38FE8%7D>> 
CWE Private 
<http://cwe.ccsds.org/css/docs/Forms/AllItems.aspx?RootFolder=%2Fcss%2Fdocs%2FCSS%2DCSTS%2FCWE%20Private&View=%7B8045374D-F8E0-4356-83CA-993252A38FE8%7D>> 
CSTS Framework and Concept. Please note that the focus was on the key 
elements in the specification and the update of those. Chances are, that 
as a consequence of these changes further updates are needed at other 
places in the document for consistency reasons. But in order not to 
waste resources I have decided to perform such sanity checks only when 
we have agreement on the key updates.

Best regards,

Wolfgang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20160513/69e85dd2/attachment.html>