[Css-csts] SFW BDD procedure specification issues - your feedback is solicited
Wolfgang Hell
wo_._he at t-online.de
Fri May 6 09:15:44 UTC 2016
CSTS WG colleagues,
I'm sending out the following considerations regarding SFW updates
because I happen to be the SFW "Book Captain". However, I wish to point
out that the discussion was kicked off by John and the material below is
the result of intense discussion between John and me both by email and
telephone.
Recent activities related to the significance of production status for
the Tracking Data service have uncovered significant ambiguities
regarding the formation and reporting of production status changes by
the Buffered Data Delivery procedure (BDD).
The problem can be summarized as follows: both the CSTS SFW and the
individual Functional Resources currently have events named ‘production
status change’. However, the meaning of “production status” is different
in the two cases. As defined in the CSTS SFW, “production status” *of a
CSTS* is intended to represent some aggregated status of all of the
resources that collectively comprise the production process for that
CSTS. The situation is further complicated by the current requirement
for the BDD procedure to handle ‘production status change’ notifications
in both real-time mode and as production-synchronous notifications
stored in and extracted from the Recording Buffer. But for the
individual FRs that comprise such a production process, “production
status” is the status of the FR itself. The result is an inconsistency
in what the meaning of ‘production status change’ is and/or should be.
More details on this, and an example of how this is problematic, are
provided in the email from J. Pietras to me on 27 April 2016 (below).
That email also outlines an approach that cleans up the ambiguities
and separates the concept of “production status” from a new concept of
“resource status”, and uses that new concept in a reworked BDD procedure.
I subsequently pointed out that another solution would be to return to
the SLE approach, which is to not have any production-related status
notifications inserted into the Recording Buffer in the first place (see
my email to J. Pietras on 28 April 2016, below). This approach would be
easier to implement. However, the lack of information about the status
of the production process when the data were being recorded for use by
offline SLE transfer services has been a source of some operational
ambiguities in the past, which is why the CSTS BDD attempted to remedy
it by recording such notifications.
After discussing the two possible solutions, John and I developed a set
of changes to the BDD procedure and associated Recording Buffer
specifications, and to FR events, that would remove the ambiguities in
the current specifications and allow the recording of ‘resource status
change’ notifications to be recorded in the Recording Buffer, fulfilling
spirit and intent of the current SFW. Wolfgang and John prefer this
solution because it maintains the capability for the user of the
complete-mode service instance to receive indications related to the
status of the production process when the data were being generated and
recorded. However, returning to the simpler SLE approach, in which no
production-related change notifications are recorded in the Recording
Buffer, is also a viable option. This email is intended to spell out the
changes that would result from each such option, so that the WG can
decide which way to proceed.
In discussions and in other emails, John and I also discussed the fact
that the BDD procedure state table does not currently have incoming
events for the generic ‘production status change’ event or the
BDD-specific ‘buffered data delivery configuration change’ event. The
following proposed resolution also addresses those events.
Whether we decide to continue to have production-related change
notifications recorded or revert to the simpler SLE approach, multiple
changes will need to be made to the BDD specification in any case and
the definitions of the ‘production status change’ and ‘production
configuration change’ events to remove the ambiguities. In the following
list, items 1 through 4 apply to both situations. Item 5 applies if we
choose to continue to allow the recording buffer to record
production-related event notifications, and item 6 applies if we choose
to revert to the simpler SLE approach.
1.The key aspect of the clean-up is to reserve production-status and
‘production status change’ as properties of the CSTS itself, and to
represent changes in the aggregate status of the production process as
seen by the CSTS. Since ‘production status change’ is a property of the
CSTS provider, it will be named in the context of the CSTS Provider;
that is, the Event Name will contain the Functional Resource Name of the
CSTS Provider FR.
2.In the BDD state table, in addition to the ‘production status change’
incoming event that is currently specified for the BDD procedure
operation in real-time mode, a new incoming event will be added for when
the BDD procedure is operating in the complete mode.
a)When a ‘production status change’ incoming event occurs when the BDD
procedure is operating in real-time mode, the behavior will change so
that the Return Buffer is released for transmission immediately after
the notification is inserted. This ensures that the notification is
timely with respect to when the change occurs in the production process.
Note that the addition of a complete mode ‘production status event’
incoming event will result in a definition for what constitutes the
complete-mode production process in each CSTS specification that uses
the BDD in complete mode.
b)When a ‘production status change’ incoming event occurs when the BDD
procedure is operating in complete mode, it represents production status
of the production process that exists while the CSTS service with the
BDD procedure is active. That is, the production process includes the
Recording Buffer (and may possibly only include the Recording Buffer,
depending on the type of the service supported by the Recording Buffer).
The behavior of the BDD procedure will be that the Return Buffer is
released for transmission immediately after the notification is inserted
to ensure that the notification is timely with respect to when the
change occurs in the production process.
3.The ‘production configuration change’ event was not explicitly
addressed by the BDD specification in the most-recent release of the
SFW. The changes to the BDD procedure will be to include separate
incoming events for the state table for ‘production configuration change
events’ in each of the real-time and complete modes. The ‘production
configuration change’ event will be changed from being named using the
FR Name of the production-related FR to the FR Name of the CSTS
Provider. This change makes the ‘production configuration change’ event
parallel to the ‘production status change’ event.
a)In real-time mode, the response to a ‘production configuration change’
incoming event is the same as that for ‘production status change’:
attempt to insert the notification into the Return Buffer and release
it for transmission unless back pressure causes it to be discarded.
b)In complete mode, the response to a ‘production configuration change’
incoming event is the same as that for ‘production status change’:
insert the notification into the Return Buffer and release it for
transmission.
c)Note: This item does not affect the SFW as such, but is the
prerequisite for achieving the behavior favored by John and me. A
‘resource configuration change’ event will also be added to every
production-related FR, along with the identification of the directive
that will be used to invoke that configuration change.
4.The ‘buffered data delivery configuration change’ event is defined by
the BDD specification but it was not included in the state table in the
most-recent release of the SFW. The changes to the BDD procedure state
table will be to include separate incoming events for the state table
for ‘buffered data delivery configuration change events’ in each of the
real-time and complete modes.
a)In real-time mode, the response to a ‘buffered data delivery
configuration change’ incoming event is the same as that for ‘production
status change’: attempt to insert the notification into the Return
Buffer and release it for transmission unless back pressure causes it to
be discarded.
b)In complete mode, the response to a ‘buffered data delivery
configuration change’ incoming event is the same as that for ‘production
status change’: insert the notification into the Return Buffer and
release it for transmission.
5.If the production-related events continue to be recorded in the
Recording Buffer in accordance with the current SFW concept, the
Recording Buffer section of the specification (4.5.7) will be expanded
to specify that FR-specific ‘resource status change’ and ‘resource
configuration change’ event notifications are stored in the Recording
Buffer. The set of Functional Resources for which the ‘resource status
change’ and ‘resource configuration change’ event notifications are
generated are relevant to the type of the Recording Buffer, and shall be
specified in the service specification that defines the type of
Recording Buffer that is associated with that service (for complicated
production processes, the service specification could alternatively
specify the mechanism by which FRs are selected for inclusion in the
recording of their events, e.g., by service management). Note that there
is no ‘buffered data delivery configuration change’ event notification
in the Recording Buffer because this event is specific to the CSTS
Provider FR and *is not*generated as a result of anything that occurs in
the production process.
a)The specifications of the Functional Resources that comprise the
various production processes currently have ‘<FR
classifier>-production-status change’ events and <FR
classifier>-production-status parameters. These will be changed to ‘<FR
classifier>-resource-status change’ events and <FR
classifier>-resource-status parameters to clarify that these refer to
the status of the FRs themselves, whereas “production status” is
reserved for use by CSTSes to refer to the aggregate status of the
production process that supports the CSTS service provision.
b)The specifications of the Functional Resources that comprise the
various production processes do not currently have events that notify
that one of their configuration parameter values have changed. An ‘<FR
classifier>-configuration-status change’ event will be added to every
production-process FR type (that is, every non-CSTS Provider or SLE TS
Provider FR type).
6.If the BDD specification reverts to the SLE approach, then no changes
are necessary in the Recording Buffer section. The current silence in
that section with regard to production-related change notifications will
be applicable. However, John and I assume that the Recording Buffer will
still be required to record the 'bdd recording buffer overflow' event
defined in 4.5.7.5, as it is related to the operation of the Recording
Buffer itself and does not require "knowledge" of the various FRs that
comprise the rest of the production process.
Note that there is an intermediate approach between mandatory
implementation of recording production-related FR change events in the
Recording Buffer and reversion to the SLE approach: the recoding of such
notifications in the Recording Buffer could be an optional feature, with
the PICS proforma for any such Recording Buffer calling out whether a
given implementation implements the capability. Likewise, individual
services (or more correctly, the specifications for the Recording
Buffers that support those services) could be extended to include things
like resource status change and resource configuration change even if
the SFW Recording Buffer specification does not require them.
These are many changes, but they are in response to errors in the book
that must be resolved. John and I realize that the amount of changes is
such that the CSTS WG needs to be informed with enough time allowed for
WG members' feedback. I will proceed with the SFW update based on the
feedback I will have received by COB 3 June. In the absence of such
feedback or counter-proposals I will assume that the approach outlined
above as the variant preferred by John and me is accepted.
Best regards,
Wolfgang
*From:*Wolfgang Hell [mailto:wo_._he at t-online.de]
*Sent:* Thursday, April 28, 2016 4:49 AM
*To:* John Pietras
*Subject:* Re: Competing concepts of production status?
John,
Thanks a lot for illustrating your concern and I agree with you that we
have an issue. And here are my initial thoughts on this:
The reason for seeking a way to capture in the recording buffer the fact
that during the time the recording buffer is filled by production
something went wrong is to provide visibility to the service user why
certain data that should be there aren't. In SLE we have avoided this
problem by simply specifying that notifications such as "loss of frame
synchronization" shall not be invoked in the offline delivery mode. As a
consequence, there is no need to record such events in what we call the
recording buffer in CSTS. SLE even excludes the notification of
production status changes in offline delivery mode.
That approach kept the implementation simple and we could do a similar
thing in CSTS by specifying that no notifications are to be written to
the recording buffer. However, as I know from hands-on experience, this
is not very user-friendly. While DSN supported the INTEGRAL mission, for
a while there were unexplained gaps in the telemetry and Michael Stoloff
and I had to analyze tons of log files to understand what the problem
was. On the other hand I certainly concede that for cost reasons user
implementations tend to cover the nominal case only and helpful
diagnostic information is simply dropped on the floor rather than being
handled by the mission control system. In other words, in practice such
simplified implementation may well not make that much of a difference.
And as opposed to the SLE times, we will now have an MD service and a
client mission really interested in what is going on during the space
link session can find out provided the service provider has implemented
an adequate monitoring capability.
I think a further good reason to abandon the storing of notifications in
the recording buffer is the fact that as rightly pointed out by you this
is supposed to be a shared resource. I therefore question that at the
time of the space link session we could already generate those
notifications that later on will be relevant for individual CSTS
instances retrieving input from the recording buffer. An option might be
that we store all notifications issued by FR instances contributing one
way or another to the production of the data that are stored in the
recording buffer. It would then be up to the CSTS retrieving data from
the recording buffer to calculate an aggregate production status on the
basis of the stored notifications, taking into account which of these
notifications report events that were relevant for the data the CSTS
instance shall deliver to the user. This may be quite complex both in
terms of implementation and also in terms of specification. And then we
have the additional complication that at least so far we do not have a
notion of mandatory and optional elements of FR implementations. In
other words, if we were to specify how a CSTS has to calculate the
aggregate resource (to adopt your suggestion) status, we cannot be sure
that a given provider will actually generate all the notifications we
may require.
My conclusion at this point is that we definitely have an issue that
needs to be fixed. And there I see two options: a) We fix the problem
along the lines you outline in your email or b) we adopt the SLE
approach and rely otherwise on the information that can be obtained
using the MD service.
Talk with you soon,
Wolfgang
--------------------------------------------------------
*From:*John Pietras
*Sent:* Wednesday, April 27, 2016 10:31 AM
*To:* Wolfgang Hell
*Subject:* Competing concepts of production status?
Wolfgang,
I’m am sorry to say that I think I’ve come across some inconsistencies
in the way “production status” is interpreted and used in CSTS
.
.
[Here are] some bullet points that are relevant:
1.In SLE, production status represents a “roll up” of the aggregate of
the various production functionalities that support the transfer service
instance.
2.In CSTS, the same concept applies; that is, production status for a
CSTS is the aggregate status of everything beneath it (although how that
aggregate value is formulated is left to the specific service and
possibly even implementation). Phrasing such as “configuration of the
production process has been completed” (3.11.2.2.4.3 (a)) supports this
impression. So production status is a property of the CSTS itself. Even
section 2.2.2.2 states that it can be queried, and the DP procedures
treat the change in production status as incoming events to the state
machine.
3.However, the ‘production status change’ event is named **in terms of
the functional resource that triggers the production change.** I’m
pretty sure that this naming was driven by the BDD procedure and the
perceived need to put production status change notifications in the
Recording Buffer. Since no single CSTS instance is solely associated
with the Recording Buffer, this particular flavor/interpretation cannot
be in terms of a CSTS instance, none of which may even be operating at
the time that the ‘production status change’ takes place. But defining
‘production status change’ in this way causes a problem for the
interpretation of production status as a property of the CSTS, as
illustrated by the following:
a)The return space link carrier FR is interrupted. A ‘production status
interrupted’ notification is sent, named in the context of the return
space link carrier FR. Presumably the production status of the service
goes to interrupted, too.
b)Then the return TM sync and channel decoding FR is also interrupted.
Is another ‘production status interrupted’ notification is sent, this
time named in the context of the sync and channel decode FR, or is no
further notification sent because the production status of the CSTS
itself hasn’t changed from interrupted?
c)Then the return TM sync and channel decode FR is returns to
operational. Is a ‘production status operational’ notification sent for
the sync and channel decode FR, or is nothing sent because the
production status of the CSTS hasn’t changed from interrupted?
4.Presumably, when querying the production status of the CSTS, the FR
that is named is that of the CSTS provider FR, but I can’t find that
obviously specified anywhere
In my opinion, here would be the proper fix:
1.Keep production status purely as a property of the CSTS itself, to
represent some aggregate of the underlying production process.
2.Recast the ‘production status change’ as named by the CSTS Provider
FR, not to individual FRs in the underlying production process.
3.In the Recording Buffer section of the BDD specification, define a new
‘resource status change’ event, named in the scope of the functional
resource.
4.In the BDD spec, add a new incoming event, ‘production status change:
complete mode’, which inserts ‘production status change’ notifications
in the complete way.
In this reworking, ‘production status change’ is clearly distinct from
‘resource status change’, in which ‘production status’ always represents
the real-time status of the production supporting the CSTS instance at
that moment. (As an aside, this would let TD-CSTS report production
status in complete mode after all).
I would also suggest changing ‘production status’ and ‘production status
change’ to resource status’ and ‘resource status change’ in the FR
parameters and events, so as to keep “production status” just a property
of transfer service instances.
Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20160506/f58fd903/attachment.html>
More information about the CSS-CSTS
mailing list