[Css-csts] Updated draft Next Gen SCCS-SM Concept Green Book on CWE

[John Pietras]

SMWG and CSTSWG colleagues ---

As many of you know, the Functional Resources concept that began in the
CSTSWG has been adopted as a part of the Next Generation Space
Communication Cross Support Service Management SCCS-SM) Framework. The
Next Gen SCCS-SM (hereinafter referred to as Next Gen SM) Framework
includes an SCCS Functional Resource Model that defines a set of
top-level abstract FR classes from which concrete FR types can be
defined. The top-level classes allow not only for the definition of the
FR types that we know of today, but also provide for the definition of
new FR types in the future. 

 

NOTE -   For those of you familiar with the draft Monitored Data CSTS
Red Book, the concrete FR types in the Next Gen SM framework correspond
(or at least are intended to correspond) to the FR types that are used
to name the monitored parameters and notifiable events that are reported
by that CSTS.

 

In draft version 0.7 of the Next Gen SM Concept Green Book, I had
included a section describing the functional resource model classes.
During the discussion of that section (3.2) at the SMWG telecon on 27
June 2012, Anthony Crowson correctly pointed out that whereas the model
should be an abstract one that can be subsequently expanded by the
derivation of concrete functional resource types, the one in v0.7
included a number of concrete types without including the abstract
classes from which future concrete types can be derived. This was
particularly obvious in the SLE and CSTS Provider types. 

 

I have significantly reworked section 3.2 of the Concept Green Book. In
addition to developing a higher-level, more-abstract class diagram, I
have also generated an Example diagram that illustrates the current and
(near) future FR types and shows how they are derived from the top-level
classes. The updated section two is included in the 0.9 version of the
Concept Green Book, available at

http://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Blue-2%20Planning/Fra
mework%20Green%20Book/NextGenSM_GreenBook-G-0.9-2012-07-17.docx

 

This version includes the V0.8 updates that Anthony made to the Concept
Overview section (section 2), so this version represents all of the
latest material. Changes are marked with respect to version 0.7 - that
is, Anthony's update and the changes in section 3.2 are marked.

 

It should go without saying that this is a strawman effort that is
intended as a jumping-off point for further development of the FR class
model and the derived FR type. My main purpose was to perform a
first-level sanity check to see that the class model could encompass all
of the FR types that come to mind, and in this it appears to have been
successful.

 

To the members of the CSTSWG - There are a few discrepancies between the
types presented in the Next Gen SM Framework Green Book and those in
Wolfgang's taxonomy. For example, Wolfgang groups the monitored data
associated with the Return Symbol Stream and Return Synchronization and
Channel Coding FR types into a single "Downlink Data Interface" FR type.
This types of discrepancies will need to be worked out in the coming
months. 

 

A few comments and caveats ---

1.       It has been noted that the SCCS FR class model and the derived
FR types need to be checked for consistency with the evolving Cross
Support Architecture. This has not yet been done.

2.       When I started to rework the class model, I initially kept the
top-level carrier/subcarrier/symbol stream classes. However, as I
thought about it more, it occurred to me that this might itself be too
constraining (e.g., would these apply to optical links?). So instead I
abstracted these 3 to an even higher level - Space Link Physical Channel
- and allowed (in the class model) for recursive associations. Thus
Space Link Carrier, Space Link Subcarrier, and Symbol Stream are all
derived types of the Space Link Physical Channel class. 

3.       For now at least, only with the derived FR types need be
registered with SANA. This is consistent with the current approach of
the CSTSWG. I don't know if there would be any benefit to also
registering the abstract classes. If we do decided to register the
abstract classes, a logical next question would be whether there should
be any registration tree  relationship among an abstract class and its
derived types. For me, it might be "nice" but I don't see it as
necessary.

4.       The question arises regarding whether there needs to be some
subclassing of FR types. For example, is the single Return Space Link
Carrier FR type suitable for all RF carrier types, even if we find that
we have different managed parameters/monitored parameters/notifiable
events for different "flavors" (e.g., 401 vs. CDMS)? My assertion at
this point is that we *can* use just the single FR type, even though
some of the parameters may not be applicable to all instances of that
type (e.g., CDMA PN code-related managed parameters would be not
applicable to pure 401 carriers). Keeping the set of FR types as small
and stable as possible is desirable.

5.       The FR class and FR type example subsections of section 3.2
forward reference to the Baseline Functional Resource Types section
(section 4.5). It's not clear to me what should be in 4.5 vs. 3.2. 4.5
is now inconsistent with the  FR types, classes, and categorization
presented in 3.2, but I've left it unchanged until we figure out what
the relationship between 3.2 and 4.5 should be.

6.       The FR types example in 3.2.2.4 is quite extensive and may be
overkill for section 3. We may want to cut it down, or move it to an
informative annex. 

7.       In previous drafts of the Concept Green Book, I proposed that
the categorization "SLE" also be applied to any CSTS-based transfer
service that transfer space link data units. However, I neglected that
return SLE services have specific offline, online complete and online
timely delivery modes that are defined in the Cross Support Reference
Model that are *not* supported by CSTS In the same way. To the extent
that these delivery modes are an important aspect of the definition of
"SLE" services I'm withdrawing my suggestion. If we find that we need a
subcategory of transfer services that includes SLE and CSTSes that
transfer space link data units, we could come up with a new collective
term, e.g., Space Link Data Unit (SLDU) transfer services.

 

Best regards,

John

 

John Pietras

GST, Inc.

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120717/c6d18cc6/attachment.html