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

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

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

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

UML 1 Model of ESLT SLS Functional Groups

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}

UML1 Model of Abstract FG Template

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

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)

UML 1 Model of Abstract FG Service Agreement Template

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

UML 1 Model of Abstract FG Configuration Profile Template

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

RF Aperture

CCSDS 401 Forward Physical Channel Transmission - Configuration Profile

TC Sync and Channel Encoding FG – Configuration Profile

AOS Sync and Channel Encoding FG – Configuration Profile

SLE Forward CLTU Data Delivery Service FG – Configuration Profile

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

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

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

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

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