[Css-csts] Functional Resources in Service Management and Service Package Execution

John Pietras john.pietras at gst.com
Mon Aug 27 15:55:03 EDT 2012


SMWG and CSTSWG colleagues ---

At the Darmstadt meeting, the SMWG and CSTSWG jointly adopted the
approach for specifying Functional Resource (FR) Identifiers.
Specifically, the Functional Resource Types would be defined ahead of
time (and registered with SANA), and the individual FR instances in a
Service Package would be subsequently identified by Service Management
in the process of scheduling that Service Package.  I took the action to
develop and exercise some use cases to confirm this approach. In the
process, I developed an extended scenario that addresses the role and
use of functional resources, functional resource types, functional
resource identifiers, and the monitored parameters, notifiable events,
and directives that are named in the context of functional resources.
The purpose of this scenario is to confirm that the functional resource
concepts that are being applied to both Cross Support Transfer Services
(CSTSes) and Next Generation Space Communication Cross Support Service
Management (NextGen SCCS-SM) will provide unambiguous naming of
monitored parameters, notifiable events, and directives.

 

The result of that analysis, the technical note "Functional Resources in
Service Management and Service Package Execution", has been uploaded to
the CWE at URL

http://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Functional%20Resource
s/FRsInSvcMgmtAndSvcExec.docx

 

The technical note extends the analysis that Yves Doat that performed
and documented in his note "Operational Scenario Implementation" in May
2012. 

 

Overall, I was able to confirm that the use of Functional Resources is a
viable approach for integrating the configuration and operation of
monitored data and service control services into SCCS-SM with minor
modifications to the current (B-1) SCCS-SM architecture. While such
modifications are not currently envisioned to be retrofit into the B-1
architecture, such accommodations should be easy to make for the Next
Generation SCCS-SM architecture. 

 

During the course of exercising the detailed scenarios of the technical
note, several areas of mismatch or ambiguity were encountered. None of
these were show-stoppers, but rather areas for further work. They are
documented in the technical note.

 

I must warn you - the "note" is 42 pages long. I extended the original
scenario from the draft MD-CSTS specification that Yves used in his
paper to ensure that  enough complexity existed to flush out any issues
that might be hiding therein. Even so, I found that I had to pare down
the scope as I proceeded with the paper in order to complete it in a
reasonable amount of time. For example, I had begun the paper with
examples of both a Space Link Session Service Package and a Retrieval
Service Package, but ultimately only followed the SLS Service Package
through scheduling and execution. Rather than deleting the incomplete
material ,  I have left it in the paper for future development if and
when it might ever become useful to do so.

 

Best regards,

John

 

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


More information about the Css-csts mailing list