[Css-csts] Functional Resources and Monitored Parameters
Wolfgang Hell
Wolfgang_._Hell at t-online.de
Mon Jun 30 10:32:25 EDT 2014
Dear CSTS WG Members,
as a preparation of tomorrow's CSTS telecon, this is to let you know
where I stand and to identify a number of issues for which we may be
able to reach an agreement during that telecon.
The work on the Monitored Parameters is for the most part based on
- the related Excel spreadsheet;
- John's Technical Note "Functional Resources for Cross Support Services";
- the list of Managed Parameters identified in the various applicable
CCSDS Recommendations;
- and for the creation of the XML file the Eclipse based tool developed
by Holger.
John's Technical Note aims at covering at least those FRs that will be
needed as to model the production and provision of the services listed
in the IOAG Service Catalog 1 and the existing SLE service
specification. I have adopted that set of FRs and have reassigned the
OIDs (for now) such that now the OIDs are in the same sequence as they
appear in John's TN. As some initial discussion between John and me has
shown, chances are that the set of FRs will still change, because due to
some restrictions of the cardinality of some FR types that John and I
agreed, it is possible now to merge some FR types. On the other hand, at
least in one case, introduction of an additional FR type would provide
for a more consistent monitoring of the forward link multiplexing tree
structure. Therefore, the present OID assignment may well not yet be the
final version. Also, right now we have a flat FR structure. It may be
better to agree on a hierarchical structure along the color coding
scheme in John's TN. Do you consider the flat OID space good enough?
The work I have done on the forward link FRs reflects the present status
of the related CCSDS Recommendations and their layering. John pointed
out that some (not CCSDS approved) implementations allow convolutional
encoding of the bit stream in a way that is not coupled to the framing
of the to be encoded data. I'm not sure about the details, but I hear
rumors that also for the next generation uplink the decoupling of
synchronization and coding is being discussed. To which extent shall we
take these considerations into account at this time?
Working on the various FRs I noticed that for whatever reason the set of
monitored parameters for the forward link is richer than that for the
return link because quite a number of parameters that reflect the
configuration rather than any dynamically changing observations have
been included while that is not or to a far lesser extent the case for
the return link. A richer set of monitored parameters may be more user
friendly, but requires more implementation and testing effort. In any
case, we should apply the same policy to all FRs. That means that we
either should remove various parameters on the forward side or add
parameters on the return side. Which way shall we go?
Because of the revised FR types, the specification of the monitored
parameters has changed quite a bit beyond simply moving an existing
parameter to a different FR type. As a consequence, a number of the FR
types are for now specified based solely on my personal judgment. Since
Holger has created a style sheet, WG members should be in the position
to review the material that I have generated.
I'm planning to distribute the XML representation of the monitored
parameters that I managed to create so far this evening. This will be a
snapshot of work in progress. There are a number of things that are
still to be done:
- I'm supposed to add the notifications that the existing SLE services
can issue as events. This is pending.
- The SLE Pink Books will contain more gettable parameters than the
current Blue Books. These parameters shall be added to the list of
monitored parameters of the FRs representing these services. I have not
done that yet.
- For various FR types the XML file contains only the FR type OID but
not yet any parameter. For those FRs that represent services that are
not yet specified I plan to leave it that way. However, since it is more
or less clear what will happen on the service production side, I plan to
specify the parameters for the production related FRs even if these FR
types are not needed for those services that are already specified.
- The XML file for now contains an FR type to cover the forward link of
ranging via a CDMA forward link as per CCSDS 415. If we accept John's
suggestion (that I fully support) to model a TDRSS kind of forward link
by means of a dedicated set of FR types, then the FR type as specified
now for CCSDS 415 needs to be removed.
- John and I agree that we should have some kind of connection-trace
information which tells which FR instance(s) are supplying input data to
a given FR instance and which FR instances are consuming which output
data generated by the given FR instance. The xml file does not yet
contain suitable monitored parameters.
- John is also proposing to have a monitored parameter which shall
accommodate descriptive text regarding the role FR instance has in the
specific configuration. Such descriptive text would be assigned to the
parameter as part of the overall configuration. Again, the parameter
required to provide this capability is not yet covered by the XML file.
In addition to the more general considerations listed above I have the
following questions to John that hopefully we can discuss tomorrow:
- It occurs to me that the naming of the entities in the wide arrows
showing CFDP related data flow are not consistent (or I'm missing the
point): The Packet Extraction & De-encapsulation FR type is supposed to
send CFDP PDUs to 'Forward CFDP'. Shouldn't that read CFDP PDUs to CFDP
Sending Entity? Likewise the Encap, MAP Pkt Processing & MAP Mux FR as
well as the TC Encap, VC Pkt Processing & VC Gen FR show CFDP PDUs
coming from 'Return CFDP'. Shouldn't that read 'from CFDP Receiving Entity'?
- MC-Demux & Reception FR and VC Demux & Reception FR represent
production activities that are necessary to provide the RCF service. Why
is the RCF TS Provider supposed to digest all frames rather than taking
advantage of the demuxing performed by MC-Demux & Reception FR and VC
Demux & Reception FR? The same question applies to the ROCF TS Provider.
Since the offline frame buffer contains all frames, also the in case of
offline delivery mode the MC-Demux & Reception FR and VC Demux &
Reception FR could do the job. What is the reason for duplicating that
functionality in the RCF and ROCF TS Provider FRs?
- I understand that the validation of radiometric products made
available via offline delivery is not shown in the FR type figures. But
why is the correlator that consumes the DDOR raw data from two locations
and calculates the associated TDM formatted product not shown either?
How shall the production and delivery of that product be modeled?
Talk to you tomorrow.
Best regards,
Wolfgang
More information about the Css-csts
mailing list