[Css-csts] Directive Procedure Document: Rev1
Charles J Ruggier
Charles.J.Ruggier at jpl.nasa.gov
Tue May 30 18:18:53 EDT 2006
Dear Yves,
I would like to thank all who reviewed the document and provided
comments. As this is a draft document, It should be noted that some
additional elements of the directive specification have been introduced for
further review by the CSTS WG without any prior discussion. The review
comments have been greatly appreciated and all of the identified pertinent
issues will be addressed accordingly.
My responses to the review comments are given below.
Regards,
Charles
At 01:28 AM 5/30/2006, Yves.Doat at esa.int wrote:
>Dear Charles,
>
>Looking at your procedure we have the following comments.
>
>A. Throw-Event procedure making use of the CONTROL-DIRECTIVE operation:
> The title of your procedure is CONTROL-DIRECTIVE.
> The working group agreed to name the procedure Throw-Event procedure (See
> Minutes of meeting of our February meeting). The Throw-Event procedure
> would make use of the DIRECTIVE operation.
> The name and the text should be changed accordingly.
There was no intention to replace the THROW-EVENT procedure with the
CONTROL-DIRECTIVE operation. It was well understood that the THROW-EVENT
would remain as a "procedure" and the CONTROL-DIRECTIVE as an "operation"
containing mapped THROW-EVENT parameters. If we have a THROW-EVENT
procedure, could we not use the CONTROL-DIRECTIVE operation, if this common
operation can also be used for other directive-type operations?
The basic idea was to fold all of the directive-type functions into a
single generic operation. This approach attempts to consolidate all
directive-type operations into one operation without discarding existing
procedures and operations that can be applied on top of the
CONTROL-DIRECTIVE. However, it was also understood that these proposed
changes would need to be carefully assessed in terms of the overall benefit
to the SLE services.
In reference to the CONTROL-DIRECTIVE Specification document title, the
term "procedure" will be replaced with the more appropriate term "operation."
> Section 1.1, 1st paragraph
> "The purpose of the procedure is to map the THROW-EVENT, INVOKE-DIRECTIVE,
> TRANSFER-DATA, SET and GET parameters into a generic directive that is
> common to all SLE services".
> This sentence is quite confusing as it gives the impression that the
> CONTROL-DIRECTIVE operation replaces THROW-EVENT, INVOKE-DIRECTIVE,
> TRANSFER-DATA, GET and SET.
As discussed above, the THROW-EVENT, INVOKE-DIRECTIVE, TRANSFER-DATA, GET
and SET operations could be invoked through the CONTROL-DIRECTIVE.
> I am also confused about what you call the procedure, a directive and
> an operation.
The terms procedure, operation and directive are defined as follows:
(1) Procedure consists of a series of operations that perform a specific
task. When a procedure is called, the associated operations can then be
invoked.
(2) An operation is an action resulting from given instructions (parameters).
(3) A directive is assumed throughout the specification document to be an
"operation," and not a "procedure."
> During our February meeting we stated: "The Throw-Event procedure would
> make use of the Control-Directive operation" (Section 2.7 of the Minutes
> of Meeting). As such the CONTROL-DIRECTIVE cannot be an operation that
> replaces all other operations. The procedure should be updated to reflect
> what the procedure covers and what operations are needed.
> It is also not clear to us why you prefix the procedure with the term
> "GENERIC". As all agreed procedures are at the same level there is no need
> to prefix them with GENERIC.
There is no disagreement with Section 2.7 of the February Meeting
Minutes. The THROW-EVENT procedure would make use of the CONTROL-DIRECTIVE
operation. What is not clearly stated in the Meeting Minutes is the full
scope of the CONTROL-DIRECTIVE. Also, there was no explicit agreement to
uniquely limit the use of the CONTROL-DIRECTIVE to the THROW-EVENT
procedure. This open issue led us to consider extending the
CONTROL-DIRECTIVE operation to cover other directive-type operations such
as the TRANSFER-DATA, SET and GET. The prefix "Generic" was added to
distinguish this directive as being a single directive that performs
multiple operations.
> Section 1.1 Properties of the procedure.: "Enables extensibility for
> Directive directive operations of all existing and future new SLE data
> transfer services".
> We have agreed for a number of procedures and this sentence gives the
> impression that your propose procedure covers everything (including data
> transfer). We have identified a set of procedures each of them covering an
> identify behaviour. This procedure is not supposed to cover all possible
> behaviour. I assume that I misunderstood the text. Could you update it.
This section will be updated to clarify the statement.
> Section 1.1.2 Table
> The table in that section should be moved to a section describing the
> operations or I assume this table will disappear in the future.
> I assume this table is a mapping showing that you can cover all those
> operations with the agreed set of operations. If that's correct, then this
> table should not be copied to the future toolkit document. This table
> should either be removed or alternatively copied to an annex that will not
> be part of the ultimate Recommendation.
This table was included to show how the existing parameters can be mapped
into the CONTROL-DIRECTIVE. It was placed here for purposes of discussion
and can be copied to an annex if there is agreement on the form and content.
> Section 1.1.2. Table
> The list of operations seems to cover much more than the Throw-Event
> procedure. My understanding is that GET and TRANSFER-DATA do not belong to
> that procedure.
The GET and TRANSFER-DATA operation types parameters shown in the table
were considered to be within the scope of the CONTROL-DIRECTIVE operation
and were included for purposes of completeness; however, further analysis
and discussion are needed.
> Section 1.2.1.
> Where is the Throw-Event procedure defined? I thought it was that one.
This section states that the detailed THROW-EVENT Procedures have been
defined in another existing document. The full document title and number
will be inserted here.
> Section 1.2.2.1 Why are you describing GET and SET parameters in the
> concept section? I assume this text will disappear.
This section defines the GET and SET parameters shown in the table of
section 1.1.2. The intent here was to define all the parameters shown in
the table and should also include TRANSFER-DATA parameter definitions. The
THROW-EVENT and INVOKE-DIRECTIVE parameters are unchanged and have been
defined in other existing documents.
>B. Other comments:
> Section 1.1 "Promotes reusability, modularity and improves operational
> efficiency"
> That's the purpose of the toolkit and not only of this procedure. This
> text should go into the main document (to be written).
Agreed.
> Section 1.1.2 Example.
> In example 2 the control directive is used to specify the type of report
> that shall be submitted but it is not clear to me how and when the report
> is actually transferred.
Agreed, the text should be more explicit. The SLE Monitoring Service
Procedure Specification (now in review) provides a more detailed
explanation of this example. The procedure shows how the Monitoring
Service can use the CONTROL-DIRECTIVE for delivery of monitor data and the
various reporting modes.
> Section 1.3.1 - PEER-ABORT invocation
> The peer-abort invocation belongs to the association procedure and should
> be removed from the text.
Agreed.
> Section 1.3.1 A lot of checks are performed but the definition lacks
> detailed information on how those check are performed.
> As an example, it is not clear how you identify if a directive-type is to
> be sent to Management? How do you achieve this check?
Only the Type-1 directive is sent to Complex Management, which is an
exclusive characteristic of the THROW-EVENT. The mechanism needed to
identify Type-1 and Type-2 directives is an abstraction here, since it was
considered to be more of an implementation issue rather than behavior. It
is suggested in the table in section 1.1.2 that the THROW-EVENT event-id
parameter could provide this information to distinguish the THROW-EVENT
Type-1 from a Type-2 directive.
> Section 1.3.1. The text addresses the invocation of the operation and then
> what happen on the provider side. I would expect a description of what the
> user is supposed to provide as request parameters. The provider behaviour
> does not belong to that section.
Agreed, but should this apply to the "sequence of events" of all
specification documents?
> Section 1.3.2 If the directive is not successfully executed a negative
> response is sent back. Can you provide a list of possible reasons? Do we
> have to assume that the reasons can only be defined by the application
> executing the DIRECTIVE? I assume that some general reason can be foreseen
> (e.g. 'resource not available', ...).
There could be a number of reasons for a negative response. The details
describing of the reasons for the negative responses need to be identified
and listed. Also, there should be a clear distinction made between
"notifications" and "returns," which was not made clear in the text and the
associated UML Activity diagram. These issues will be addressed following
the completion of this review.
> Section 1.3.3 Complex Management interface
> Directive-Type and identifier
> From the text I have the feeling that Directive-Type and Directive ID are
> known by user, provider and complex management.
> Could you please explain how is this list known? How would it be kept
> consistent?
It is understood that the directive-type and directive -ID could be
transparent to the User. The directive-type is the identity of a directive
requiring Complex Management, while the directive-ID provides the ID number
of the sequence of invoked directives.
> Section 1.8.1: GET and TRANSFER-DATA are not part of this procedure.
The GET and TRANSFER-DATA were included for the reasons discussed above.
> Section 1.8.2.1. 'operation not supported'
> On one hand I consider that if a service selects that procedure, this
> operation must be supported.
> On the other hand in case this error would happen, the provider could not
> decode the operation and would report a decoding error.
This section needs to be made more explicit.
> Section 1.8.2.2. Directive-Type:
> The description should identify if we can have an exhaustive list of types
> or if we have to foresee an extension capability.
The reason for having a directive-type was to determine if Complex
Management intervention is required and there may be other types that need
to be identified.
> Section 1.8.2.3. Directive-Identifier:
> Is the directive identifier a concatenation of the directive-type and a
> directive instance identifier?
The Directive-Identifier could contain the directive invocation ID and also
include the directive-type.
> Section 1.8.2.9 Extension-Parameter.
> The extension parameter ensures a new service to add whatever information
> it needs. Is that what is meant by your text? (this is not what I
> understand).
An extension parameter was understood to mean an additional parameter that
may be added to extend the behavior of an operation relevant to a specific
service.
> Issue: The procedure describes the behaviour up to the handling of the
> request by the Complex Management. Do we want the Toolkit to describe this
> behaviour which is outside the scope of the Toolkit?
Although the handling of the request by the Complex Manager is considered
to be outside the scope of the Toolkit, it would be useful to describe this
behavior within the Toolkit documentation. This would consolidate the
entire procedure and operational behavior of the directive into a single
document.
>Best regards
>
>Yves DOAT
>__________________________________________________
>Head Ground Infrastructure Baseband Section (OPS-GIB)
>ESA/ESOC Robert-Bosch Strasse 5
>D-64293 Darmstadt, Germany
>Tel.: (49 (6151) 90.2288 Fax:+49 (6151) 90.3046
>Internet: http://www.esa.int/
>__________________________________________________
>
>
>
>
> Charles J Ruggier
> <Charles.J.Ruggier
> @jpl.nasa.gov> To
> Sent by: css-csts at mailman.ccsds.org
> css-csts-bounces at m cc
> ailman.ccsds.org
> Subject
> [Css-csts] Directive Procedure
> 07/04/2006 22:55 Document: Rev1
>
>
>
>
>
>
>
>
>
>
>Dear CSTS WG Members:
>
>I have uploaded a revised version of the "SLE Generic Control Directive
>Procedure Specification." This document is being submitted for your
>review in response to Action Item 15-0206 and can be found at the CCSDS/CWE
>CSS-CSTS web site:
><http://public.ccsds.org/sites/cwe/csts/default.aspx>, under Documents -
>SLE Toolkit Procedures folder - SLE Generic Control_Directive_2rev1
>
>The document has been revised to reflect the new procedures and in response
>to review comments from the CSTS Interim meetings held at ESOC in
>February/06. Other changes have been included for consideration in an
>effort to improve the harmonization and overall efficiency of the
>procedure. The major changes to the document are summarized below:
>
>(1) The document text and UML models have been modified per new procedures
>as outlined at the Atlanta and ESOC Interim meetings.
>
>(2) The Control-Directive procedure assumes 3-phase confirmation of the
>processed and executed directive: invoked request, acknowledged return, and
>final confirmed return.
>
>(3) Transfer-Data, Set and Get parameters are included as parameters
>associated with the Control-Directive operation. The underlying principle
>here assumes that the Control-Directive is a generic operation that
>controls service production parameters (except commanding) and the
>retrieval of requested data. Transfer-Data, Set and Get are considered
>here to be directive-mapped parameters and not stand-alone operations.
>
>
>Best Regards,
>
>Charles Ruggier
>
>Jet Propulsion Laboratory
>Telephone: +1 818-354-1823
>Fax: +1 818-393-3505
>
>
>
>_______________________________________________
>Css-csts mailing list
>Css-csts at mailman.ccsds.org
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20060530/c41591a6/attachment.html
More information about the Css-csts
mailing list