[Css-csts] Issues regarding Cyclic and Unbuffered Data Delivery
Procedures - Update
Yves.Doat at esa.int
Yves.Doat at esa.int
Fri Jul 27 09:54:21 EDT 2007
Dear John,
I also looked at the Cyclic procedure and I have the following comments.
While the file title state it's issue 1.4, the document uses issue 1.1.
This is quite confusing.
Requirement 2.3.5.
In case a parameter is undefined, its value shall also be void. The text
should be updated.
I will map the 'void' value to an asn.1 'NULL' in appendix C.2.4,
TypeAndValue definition.
Your comment A related to the list of parameters included in the START. I
looked at my notes and found tat the behaviour text is the correct one. If
at least one parameter of the list is unknown, the START operation shall
return a negative result and the diagnostic shall contain the list of
unknown parameters.
The extended diagnostic shall be updated to reflect this decision.
Your comment B. I agree
Your comment C. I agree with your proposal, i.e.:
- Loosen statement "as soon as generated" in "Unbuffered Data Delivery" so
that to leave to the derived procedures or services to define the proper
behaviour.
- Note that the TRANSFER-DATA defined in the Unbuffered Data Delivery
already has a generation time stamp. I do not see a need to add a
timestamp to each parameter. In case a parameter is not updated during the
cycle, it's value qualifier should be changed to 'unknown'.
Your comment D.
We have to remove this ambiguity and make sure that the "Unbuffered Data
Delivery" identifies what is to be discarded in case of congestion.
I am not sure we can state that the buffer of the "unbuffered data
delivery" contains one invocation only. Depending on the service using it
one can imagine that what is transferred contains more than one
invocation. Can we state that what the "Unbuffered Data Delivery"
procedure transfer one CSTS-SDU per invocation of DATA-TRANSFER?
Your comment E.
You are right the base TRANSFER-DATA already has a generation-time and a
sequence-counter. They have to be removed from the Unbuffered Data
Delivery procedure.
Section 3.3.2.2.2
The description should be extended to cover the various cases linked to
the value qualifier. Should we move the requirement 3.2.5 in that section?
Section 3.3.2.2.3.
Do we have to transfer with each invocation the engineering unit?
Originally I proposed this value but the parameters to be transferred,
their range and their unit should be defined at service (or by management)
level and agreed between the provider and the user. I would propose to
remove that parameter.
Section 3.3.2.2.4.
We have to specify the value qualifier. The ASN.1 of the draft
recommendation list the following possible values valid, unknown,
undefined, error.
Best regards
Yves
John Pietras
<john.pietras at gst.
com> To
Sent by: css-csts at mailman.ccsds.org
css-csts-bounces at m cc
ailman.ccsds.org
Subject
[Css-csts] Issues regarding Cyclic
10/07/2007 21:01 and Unbuffered Data Delivery
Procedures - Update
Members of the CSTSWG --
Last week I sent a message identifying some issues with the latest
release of the Cyclic Data Delivery Procedure Working Note (Issue 1, Rev
2, dated 13 June 2007). I have since found an action item from the
January meeting that modifies previous comments. Below is a re-issue of
the previous comments, with items B and C modified to reflect the action
item.
-----
In reviewing the latest Cyclic Data Delivery Procedure Working Note
(Issue 1, Rev 2, dated 13 June 2007), I've come across what appear to be
several inconsistencies and/or errors. I've tried to go back through the
Minutes of Meetings, etc., for previous discussions and decisions, but
found none that explained or resolved these issues.
A. List-of-parameter member validity as a condition for positive result
of the START operation
In the Behavior section, paragraph 2.2.3 states "If at least one of the
parameters of the list is unknown then the START operation shall return
a negative result and the diagnostic shall contain the list of unknown
parameters."
However, the subsequent definition of the START operation has an
extended diagnostic value 'all parameter names undefined' (paragraph
3.1.6.1 (b)) but makes *no* mention of containing a list of unknown
parameters.
It is my impression that the intention is to allow the START (and thus
the procedure itself) to succeed if *any* of the named parameters in the
list-of-parameters is defined. This interpretation is consistent with
the way the START operation itself is defined in section 3.1, but
counter to the way the behavior of the START operation is defined in
2.2.
The behavior of the TRANSFER-DATA operation as stated in paragraph 2.3.4
- "If the value of a parameter of the 'list-of-parameters' is currently
unknown then the returned qualifier value of the parameter shall be
'unknown value'." - can be strictly interpreted as supporting the
"positive result only if *all* of the parameters are valid" approach.
However, by adding another qualifier value -'unknown parameter'- the
"positive result if *any* of the parameters are valid" approach can also
be supported.
B. Number of parameter values reported in a single TRANSFER-DATA
invocation
As currently defined in section 3.3.2.2, each cyclically-reported
parameter from the list-of-parameters is reported in it's own
TRANSFER-DATA invocation. However, action item#07-0107 states "The
Cyclic Data Delivery procedure delivers a sequence of parameters as part
of the TRANSFER-DATA. The structure should be identical to the list
delivered with the GET. Careful analysis is required as the
TRANSFER-DATA cannot contain this definition and it may be that list is
to be defined in the Cyclic Data delivery procedure." The change has yet
to be made.
Note - there may be a good reason to have the Cyclic TRANSFER-DATA
operation transfer more information than is found in the GET operation -
specifically, a timestamp for each monitored parameter. This is
discussed in more detail in item, C, below.
C. Conflict between cyclic reporting and 'live data' concept in the
underlying Unbuffered Data Delivery procedure
The Cyclic Data Reporting procedure is built around the notion of
reporting data periodically. Section 2.3.2 states" The provider shall
arm a periodic timer to deliver data periodically at the interval of
seconds defined by the value of the parameter 'delivery-cycle'."
However, this procedure is derived from the Unbuffered Data Delivery
procedure(the most recent version of which is called "1.7" in the file
name but "Issue 1 Rev 5" on the cover page), which states in section 1.2
" The provider transmits live data... Transmission of 'live data'
implies that data units are transmitted as soon as possible after their
production."
There is a conflict between stating that the data are delivered both "as
soon as possible after their production" and waiting to "deliver data
periodically at the interval ... defined." This conflict might seem like
a simple issue of phrasing, but taken in conjunction the two statements
could be strictly interpreted as requiring that the data that is being
*reported* at time X be *sampled* at time X. In fact, I have been a
party to a status reporting system design review process where that
exact issue was a point of contention (customer thought he was getting a
sample that was only a few milliseconds old, vendor was actually only
planning to deliver something that had been sampled sometime since the
last (5 second) report was sent), so it is not merely a philosophical
exercise.
My understanding is that for many systems, actually sampling the
measurands within mere microseconds before the report is generated is
not always (or even often) a requirement, and we probably don't want to
implicitly build that into our Cyclic Data Delivery procedure. Some
derived services, or specific implementations of derived services, may
have such split-second requirements, but those can be added for those
cases.
I think the simplest way to solve this problem would be to loosen the
"as soon as generated" wording in the Unbuffered Data Delivery procedure
and find alternate ways to express what is really happening. But there
might be other approaches, also.
If we do decide to construct the Cyclic Data Delivery procedure so that
it can deliver the collection of measurand values at some time other
than when the values were actually sampled, do we need to give each
measurement its own timestamp to identify when that measurement was
actually made (as opposed to the generation-time of the TRANSFER-DATA
invocation that transfers the measurement), or is it sufficient to treat
every measurement in a TRANSFER-DATA invocation as though it had been
actually sampled at that same time (i.e., the generation-time of the
TRANSFER-DATA invocation itself)? Note that if timetagging of individual
measurements is used, then the content of the data parameters will be
somewhat different from those in the GET operation, and the resolution
behind action item #07-0107 will have to be modified (see item B,
above).
D. Ambiguity about data discard policy in the underlying Unbuffered Data
Delivery procedure
This is really an issue regarding the Unbuffered Data Delivery
procedure, but I'll raise it here because it affects (by derivation) the
Cyclic Data Delivery procedure.
Section 2.3.3 of the CSTS Unbuffered Data Delivery Procedure states that
"If the underlying communications service generates backpressure because
of congestion, the service provider shall discard the data and/or
notification." The amount of data to be discarded is ambiguous -
although the intent is to discard only the data that is available for
transmission, it is possible to misinterpret this statement to apply to
all data generated after the congestion occurs.
Contrary to its name, I believe that the Unbuffered procedure really
does have a transfer buffer (although it is constrained to be only one
invocation deep), and that the procedure essentially acts like the
Timely mode of the Buffered procedure. If this is a correct
interpretation, then if the Timely material from the Buffered procedure
specification could be trimmed down to contain only what applies to the
Unbuffered procedure it would provide a much clearer definition of what
is to be discarded (and when) that the current wording of the procedure.
E. Redundant parameters of Unbuffered TRANSFER-DATA and base operation.
Again, this is really an issue regarding the Unbuffered Data Delivery
procedure.
The base TRANSFER-DATA operation is defined in the February draft of the
CSTS Procedures Definition as having generation-time and
sequence-counter parameters. However, the TRANSFER-DATA operation in the
Unbuffered Data Delivery procedure has generation-time and
sequence-counter extension parameters, which are redundant with those of
the base operation.
F. Various typographical errors and editorial issues in the Cyclic Data
Delivery Working Note
a. The file name is CSTS Cyclic Data Delivery Procedure 1.4, but the
cover sheet is "SLE Transfer Service Cyclic Data Delivery Procedure
Working Note Issue 1, Rev 2". The cover sheet name should change to CSTS
(Note - this is a common issue across multiple working notes). What, if
anything, is the relationship between the numbering conventions used in
the file name (e.g., 1.4) and on the cover sheets? (Note - this is a
common issue across multiple working notes)
b. The page header on each page is "CSTS PROCEDURE: STATUS REPORT"
c. The delivery-cycle (section 3.1.3), list-of-parameters (3.1.4),
extension-parameters (3.1.5), and diagnostic (3.1.6) sections should be
under section 3.1.2 (Invocation, Return, and Parameters), not peer with
it. Also, the parameter names should not be enclosed by single quotes -
single quotes are used for parameter values.
Best regards,
John
John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct: +1-240-542-1155
GST Main: +1-301-474-9696
Fax: +1-301-474-5970
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
More information about the Css-csts
mailing list