[Css-csts] Extending diagnostics

Yves.Doat at esa.int Yves.Doat at esa.int
Thu Dec 14 04:21:37 EST 2006


Dear John

Thank you for your question as you are addressing one of the key part:
extensibility.

I have to apologise as the version you have in hand is becoming obsolete.
During the meeting in CNES I received many good comments and I am now
updating the book. Please find below a clarification to your question.


The Standard Header identifies the diagnostics common to all operations (and
of course to all procedures), i.e.: 'duplicate-invoke-id', 'other reasons'
and 'extension diagnostics'.

The approach has to allow an operation to define additional diagnostics. In
the case of the PROCESS-DATA the following additional diagnostics are added:
'unable to process', 'unable to store', 'out of sequence', 'inconsistent time
range', 'invalid time', 'late data' and 'data error'.

A procedure using this operation may in turn define additional diagnostics.

A service using this procedure may in turn define additional diagnostics.

=====================================================================
ASN1 representation:

The diagnostics are carried with the StandardReturnHeader as follows:
   StandardReturnHeader       ::= SEQUENCE
   {  performercredentials    Credentials
   ,  invokeId                InvokeId
   ,  procedureInstanceId     SEQUENCE
      {     procedureType           ProcedureType
      ,     instanceId              IntPosShort
      }
   ,  result                        CHOICE
      {     positive    [0]   EXTERNAL    -- To carry the positive results
      ,     negative    [1]   Diagnostics
      }
   }

with the Diagnostics defined as follows:
   Diagnostics                      ::=   CHOICE
   {  duplicateInvokeId                   [1]   NULL
   ,  otherReason                         [2]   NULL
   ,  extensionDiagnostics                [100] EXTERNAL
   }

The PROCESS-DATA operation is defined as follows:
   ProviderToUserPdu          ::= CHOICE
   { ... (I do not list them all here) ...
   , processDataReturn           [7]      StandardReturnHeader
   }
The StandardReturnHeader carries the positive and the negative results.

In case of positive result, the operation, the procedure and (or) the service
may add additional information in the field 'positive [0]   EXTERNAL'.

In case of negative result, the diagnostic to be used is either one of the
diagnostics defined above, or one of the additional diagnostics that will be
defined as follows:
   -- Negative PROCESS-DATA Return:
   -- EXTERNAL component of the StandardReturnHeader containing
   -- the value of the negative result diagnostic following a PROCESS-DATA
   -- invocation.
   ExternalProcessDataReturnNegative      ::= CHOICE
   {  unableToProcess               [1]   NULL
   ,  unableToStore                 [2]   NULL
   ,  outOfSequence                 [3]   NULL
   ,  inconsistentTimeRange         [4]   NULL
   ,  invalidTime                   [5]   NULL
   ,  lateData                      [6]   NULL
   ,  dataError                     [7]   NULL
   ,  externalDiagnostics           [100] EXTERNAL
   }

The procedure(s) that will use the PROCESS-DATA shall define (if needed) its
own additional diagnostics that would be carried via the 'externalDiagnostics
' of the 'ExternalProcessDataReturnNegative'. The procedure shall in turn
foresee an 'externalDiagnostics' for services that will use this procedure.

I hope the above clarification helps you. Please do not hesitate to contact
me if the description is unclear.

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/
__________________________________________________



                                                                             
             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] Extending diagnostics     
             13/12/2006 21:51                                                
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             




Members of the CSTSWG:
I reading through the PROCEDURES DEFINITION FOR CROSS SUPPORT TRANSFER
SERVICES - DRAFT document that was circulated prior to the November
telecon, I have become a bit confused about how the valid values of the
diagnostic parameter are extended.

In section 4.2.2.7, which defined the base diagnostic values inherent in
the Standard Confirmed Operation Header, specific values are named
(e.g., 'duplicate Invoke-ID'), but one value is 'extension diagnostics',
with the definition "The set of diagnostics may be extended by
operations and possibly by procedures and services."

Now consider section 4.9.2.9.1, which addresses the value of the
diagnostics parameter for the PROCESS-DATA operation. Here it states "If
result is 'negative result', the common PORCESS-DATA operation uses the
diagnostics specified in 4.2.2.7, or one of the following diagnostics:",
and then follows with specific diagnostic values (e.g., 'unable to
process").

Section 4.9.2.9.1 gives the impression that these new values are simply
added onto the list of diagnostics specified in 4.2.2.7.

Is the 'extension diagnostics' value for the diagnostic parameter just a
placeholder that is always replaced by real values, or is it somehow a
"value" that can somehow "contain" other values (i.e., the extended
diagnostic values)?

I tried to look at the ASN.1 to understand this better, but the ASN.1
lobe of my brain has become rusty from lack of exercise. I hope to get
my brain  back in ASN.1 shape over the coming months, but for now a
simple explanation of how this is intended to work would be very
helpful. Thanks.

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