1. Global Science and Technology, Inc., Greenbelt, MD, USA
Models for Extensible Functional Groups and Functional Resources for SCCS Services
28-31 October 2013
San Antonio, TX
John Pietras
Global Science and Technology, Inc., Greenbelt, MD, USA

2. Purpose
Define the models for extensibility of Functional Groups and Functional Resources
NOTES
This presentation and the current version of the Models
focus on the Space Link Session (online/real-time) aspects
of the Functional Groups. Retrieval (offline/complete) aspects
need to be addressed and may affect the SLS aspects
The UML diagrams in this presentation (and in the
current version of the Tech Note) use UML 1.4 graphical notation.
They will be updated to UML 2 when the concepts are
sufficiently stable

3. “Boxes & Arrows” Model of SLS SCCS Functional Groups for Earth-Space Link Terminals (ESLTs)

4. UML Modeling of ESLT SCCS FGs
SCCS Functional Groups are represented as UML components
Relationships among FGs are represented by port pairs
Service Access Point (SAP) port provides “service” (functionality of the FG) to one or more other FG types
Accessor port is the peer of the SAP – it uses the “service”
“User/provider” roles of ports is different from the use of those terms for cross-support services
Follows ISO/OSI concept that service is provided by the lower layer of a protocol stack to a higher layer
SAP ports can either be the sources or sinks of primary data flows; correspondingly, accessor ports can be either the sinks or sources of primary data flows
The direction of the flow is indicated by the name of the port pair, e.g., Forward modulated Waveform
SAP/accessor port pairs establish the relationships among FGs for the purpose of identifying sources and sinks across those FG
Data does not necessarily flow through those ports
Sap/accessor port pairs represent all data associated with the primary data flow type identified by the port pair names
E.g., production status and throw events

5. UML 1 Model of ESLT SLS Functional Groups

6. Registration of Functional Group Object Identifiers (OIDs)
Functional Resource OIDs (called Functional Resource Types) are already planned to be registered under a new crossSupportResources node under the CCSDS/CSS node of the ISO registration tree
{iso identified organization (3) standards producing organization (112) ccsds (4) css (4) crossSupportResources (2)}
Functional Groups will be registered under a new crossSupportFGs node
{iso identified organization (3) standards producing organization (112) ccsds (4) css (4) crossSupportFGs (3)}
The abstract FGs will be the first-level nodes under the crossSupportFGs node, e.g.:
apertureFgId OBJECT IDENTIFIER ::= {crossSupportFGs 1}
fwdPhysicalChannelXmitFgId OBJECT IDENTIFIER ::= {crossSupportFGs 2}

7. UML1 Model of Abstract FG Template

8. Specializations of FG Classes
Specializations of the FG classes are derived for specific technologies and standards
The currently-identified FG specializations are:
RF Aperture (Aperture)
CCSDS 401 Forward Physical Channel Transmission
TC Sync and Channel Encoding
AOS Forward Sync and Channel Encoding
TC Space Link Protocol Transmission
Forward AOS Space Link Encoding Transmission
CCSDS 401 Return Physical Channel Reception
Return TM Sync and Channel Decoding
Return TM/AOS Space Link Protocol Reception
Multiple service-unique specializations of Data Delivery Production and Data Delivery Services
Validated Data, Raw Data, and Delta-DOR specializations of Radio Metric Data Production and Radio Metric Data Services
Monitored Data CSTS specialization of Service Management Functions
Specializations are composed of Functional Resource Types and concrete SAP/accessor port pair types
Concrete SAP/accessor port pairs are assigned OIDs under their respective abstract FG nodes

9. Functional Group Representation in Service Agreements
FGs are represented in Service Agreements as compositions of Service Agreement Functional Resources and (depending on the FG type) Service Agreement SAP ports and Service Agreement Accessor ports
The ServiceAgreementFunctionalResource class extends the FunctionalResource class with 2 additional parameters
functionalResourceAgreementNumber: an integer that distinguishes the instances of the same Functional Resource Type in a Service Agreement
functionalResourceAgreementDescription (optional?): A text-string description of the functional resource in the Service Agreement, intended to provide a “user friendly” tag
Concrete specializations of the ServiceAgreementFunctionalResource class have parameters that define the ranges or sets of possible values to be used in configuration profiles
The ServiceAgreementExtensionPointPort class extends the ExtensionPointPort class with one additional parameter
providingFunctionalResourceAgreementName: the name of the Service Agreement Functional Resource (FR Type: FR Agreement Number) that provides the SAP port
Used by the Accessor port to “know” which SAP port to access (connect to)

10. UML 1 Model of Abstract FG Service Agreement Template

11. Functional Group Representation in Configuration Profiles
FGs are represented in Configuration Profile as compositions of Configuration Profile Functional Resources and (depending on the FG type) Configuration Profile SAP ports and Configuration Profile Accessor ports
The ConfigProfileFunctionalResource class extends the FunctionalResource class with 3 additional parameters
functionalResourceProfileNumber: an integer that distinguishes the instances of the same Functional Resource Type in a Configuration Profile
functionalResourceProfileDescription (optional?): A text-string description of the functional resource in the Configuration Profile, intended to provide a “user friendly” tag
functionalResourceAgreementNumber: an integer that, when combined with the FR Type, identifies the instance of the FR Type in the Service Agreement that constrains this configuration profile FR instance
Concrete specializations of the ConfigProfileFunctionalResource class have parameters that define the specific values to be used in the execution of a Service Package
The ConfigProfileExtensionPointPort class extends the ExtensionPointPort class with one additional parameter
providingFunctionalResourceProfileName: the name of the Configuration Profile Functional Resource (FR Type: FR Profile Number) that provides the SAP port

12. UML 1 Model of Abstract FG Configuration Profile Template

13. FG Specialization Configuration Profile Examples
The following slides provide examples of the Configuration Profile representations of FG specializations
For brevity, the ConfigProfileFunctionalResource and the ConfigProfileExtensionPointPort classes are shown including the parameters that they inherit from their parent classes

14. RF Aperture

15. CCSDS 401 Forward Physical Channel Transmission - Configuration Profile

16. TC Sync and Channel Encoding FG – Configuration Profile

17. AOS Sync and Channel Encoding FG – Configuration Profile

18. SLE Forward CLTU Data Delivery Service FG – Configuration Profile

19. Possible Alternative Representation
One class for each FR Type and Port type, with different subclasses for Service Agreement aspects and Configuration Profile aspects
Pros
Keeps class names simpler and minimizes number of classes
Might be helpful in creating combined Service Agreement/Configuration Profile information entities for simple missions
Issues
Not yet clear how multifaceted FR Type classes and multifaceted Port type classes can relate to each other in a single containment hierarchy

20. Issues with the FG Model (for Discussion)
Multiple physical channels (carriers) sharing the same antenna
Migrating the same transfer service instance over different space links
Retrieval services

21. Multiple Physical Channels (Carriers) Sharing the Same Antenna
Depending on Service Package Request constraints and Space Communication Service Profile composition, multiple physical channels may be allowed or required to share, or prohibited from sharing, the same antenna
How can these different options be accommodated by representing the connection as a Space Link Carrier Transmission Profile FR bound to an Aperture Profile FR?
Current “solution” appears to be to define Carrier Profiles for every possible sharing combination and specify in the Service Package Request whether sharing is permitted or required
Minimizes reusability of Carrier Profiles
Possible alternative – define simpler Carrier Profiles and use profile respecification in Service Package Request to stitch up antenna-sharing configurations on a Service Packet Request basis

22. Migrating the Same Transfer Service Instance over Different Space Links
Intended to allow scenario changes and handovers (under special circumstances) using the same SLE transfer service instance
Realized in Blue-1 through TS mapping to join multiple Carrier Profiles to the same TS instance
In the extensible FG model, a TS instance port must bind to a specific SAP port
Current “solution” is that all Space Link Carrier Profiles that are intended to share a TS Provider instance must contain the same Profile Name for the FR that contains the SAP port to which the shared TS Provider instance
Minimizes reusability of Carrier Profiles
Possible alternative – define simpler Carrier Profiles and use profile respecification in Service Package Request to stitch up TS instance-sharing configurations on a Service Packet Request basis

23. Retrieval Services
Should there be a separate set of FGs for Retrieval services?
Retrieval Data Delivery Services
Retrieval Data Delivery Production
Retrieval Radio Metric Data Services
Retrieval Radio Metric Data Production
What is the role (if any) of Frame Buffer and Recording Buffer Functional Resources in Retrieval configuration profiles?
Are they really functional resources, as that concept is generally used?
They are statically configured outside of any Service Package
They (currently) generate no monitored parameters or notifiable events that are available to the User