[CESG] PICS text in A02.1-Y-2.1d

[Nestor.Peccia at esa.int]

Dear all,

The above mentioned doc is not aligned with the CESG agreements reached at 
our meeting in Berlin. I attach below, for the sake of completeness, the 
text from Tom's  CESG raw notes + the PICS overview in Annex F of the doc.

The protocol definition was also not accepted
"protocol: A set of rules and formats (semantic and syntactic) which 
determines the communication behavior of (N)-layer protocol entities in 
the performance of (N)-layer protocol functions"
CESG agreed to discuss the ICS at the next meeting at Boulder

ciao
nestor

===========================================================================

1000
1.      Decision on PICS/Proformas
P Shames
Peter led PICS Proforma discussion.  Peter?s expanded definition of 
?protocol? was not embraced.   It was proposed that all BBs should have 
either a PICS (ICS) Proforma or a statement explaining why one is not 
included.

Action on Peter:  Supply example of ICS.




ANNEX A 
CCSDS PICS Proforma
A1      Overview
This annex provides the rationale, content guidelines and nominal 
structure for a CCSDS Protocol Implementation Conformance Statement (PICS) 
proforma. The PICS proforma is a required normative annex in all CCSDS 
Blue Books.
CCSDS standards are required to clearly document, and in a ?terse style?, 
just what is required and what is optional in the specification.   In 
doing this they will include specific guidance on how to define all of the 
technical details of the standard.  The specification itself, must define, 
clearly and unambiguously, just what the specification is, using text, 
diagrams, tables, state machines, etc.  Even in a ?terse style? this may 
consume many pages of specification and detail.  As a result it may be 
difficult to discern, in any compact form, just what is required and what 
is optional.
The PICS proforma is not intended to recapitulate all of this information. 
 A typical PICS proforma is a succinct statement of just which sections of 
the specification are required and which are optional.  Any given PICS 
proforma will include an introduction, some fields for documenting 
compliant implementations, and one or more tables.  A simple specification 
with few options will have a very simple PICS proforma.  A complicated 
specification will have a correspondingly complex PICS proforma, 
potentially with several sub-sections.
The PICS proformahas two primary purposes:
a)      To succinctly state in one compact form which elements of the 
specification are mandatory and which are optional;
b)      To provide a template that shall be filled in by all CCSDS 
prototype implementers to document which of the features of the standard 
that they have implemented and what the status of their implementation is.
A filled out version of a PICS proforma for a given implementation is 
called a PICS. The PICS proforma may be used as a template by any 
implementers of the standard to document which features they have 
implemented and who the pint of contact for the implementation is.
A typical PICS proformawould include one or more tables containing columns 
for Item number (simple reference ID), Item Description (one or two 
words), Standard Reference (a reference to the paragraph in the standard), 
Status (of Item Number, as mandatory, Optional, Conditional, Prohibited, 
or N/A), and Support (when filled in, the terms yes, no, or N/A).  Other 
columns such as Constraint, Predicate, Sender, Receiver, Initiator, 
Responder, may also be adopted if they are necessary.  There may be more 
than one table used for different sections of the document, using 
different columns where required.  Normally the sub-sections of the PICS 
proforma will align with the sub-sections in the document itself.
Each of these tables for a protocol specification will have arow for each 
relevant clause in the specification and may also have rows for PDUs, PDU 
parameters, Timers, Negotiation Capabilities, Error Handling, 
Dependencies, and any other required or optional features of the standard. 
 Information object standards (i.e., data exchange specs like TDM or XFDU) 
would use the same column form, but include a different set of 
specification clauses, like object classes, packages, attributes, and 
operations.  In a similar fashion service specifications, coding 
specifications, modulation specifications, and compression specifications 
would each have sections appropriate to their complexity, type and 
structure.
The PICS proforma for a coding spec would be similar to a protocol one, 
except it would contain rows relating to algorithms, rates, constraint 
lengths, randomization, interleaving, symbol inversion, and use within the 
rest of the protocol stack.  Modulation would use the same columns, but 
include rows for algorithms, encoding rules, power and spectral 
efficiency, applicable bands, filtering, pre-coding, constraints on use, 
and bandwidth limitations.
This guidance captures the salient features of the required PICS proforma 
for protocols, data exchange standards, coding and modulation.  Each of 
the required types of rows for any given standard can be directly 
determined from the Blue Book itself and the WG members are in the best 
position, given some simple guidance, to state just what must be included 
for any given type of Blue Book.  The coverage of items in the 
specification must be complete enough to cover all topics of significance 
in any specification, to allow users to determine just what is required 
and what is optional, and to eliminate any ambiguities.  The depth of 
coverage of minute details may be moderated to balance completeness with 
conciseness.
For a CCSDS protocol example of a PICS proforma please refer to the 
document ?SPACE COMMUNICATIONS PROTOCOL SPECIFICATION (SCPS)?TRANSPORT 
PROTOCOL (SCPS-TP)?, CCSDS 714.0-B-2. For more extensive guidance on the 
structure and content of a PICS proforma consult the ISO document 
?Information Technology - Part7: Implementation Conformance Statements, 
Open Systems Interconnection Conformancetesting methodology and 
framework?, ISO/IEC 9646-7:1995.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110704/d7ff97c7/attachment.htm