Functional Resource and Service Component Information Maintenance 9 November 2015 Darmstadt, Germany

Drivers for Functional Resource and Service Component Information Maintenance 2  Addition of a new technology/capability  Substitutes for existing technology, e.g., a new space data link protocol or transfer service Typically addressed in CCSDS by a new Recommended Standard Addressed in Functional Resource (FR) and Service Component (SC) Reference Model and SANA Registry by the addition of a new specialization of an Abstract Service Component (ASC)  Adds a new mode to an existing technology Typically addressed in CCSDS by additions to an existing Recommended Standard (e.g., a new coding scheme) Addressed in FR & SC Reference Model and SANA Registry as revisions of the FRs within, and/or the addition of new FRs to, the affected SC  Service Management additions to/modifications of SM parameters, events, and/or directives of existing FRs  Typically not addressed by the parent Recommended Standard  Process covered here is the CCSDS-standard process Similar process assumed for maintenance of Agency-specific FRs and SCs

3 Formal “Documentation”  Functional Resource and Service Component Reference Model (prospective Magenta Book)  Defines concepts of Functional Resources, Abstract Service Component, Service Components, and how they relate to each other.  Defines the Abstract Service Components and the CCSDS-standard Service Components that specialize them  Defines the Functional Resources that comprise each of the Service Components, and the ports used to associate FRs of different Service Components for the purposes of constructing Configuration Profiles  Defines mapping of IOAG services to Service Components and Functional Resources  Defines the SANA Cross Support Service Management OID registration tree (to be added)  SANA Registry  crossSupportResources subtree of css node Registration of Functional Resource OIDs, definitions and OIDs for parameters, events, and directives Add a subtree for generic Functional Resource parameter, event, and directive identifiers  abstractServiceComponent subtree of css node (new) Registration of Service Component OIDs and port pair OIDs  Service Agreement and Configuration Profile Formats (Draft) Recommended Standard  Defines FR and SC-related data structures for Service Agreements and Configuration Profiles  Functional Resource and Service Component Model Maintenance Tool(s)  XML documents and Eclipse environment  Used to render SANA registry updates, FR and SC Reference Model Pink Sheet revisions  Distributed today. Plans for a single integrated tool in the future.

Extended Object Identifier Registration Tree (Proposed Candidate) 4 functionalResource GenericIdentifiers (3) functionalResource GenericIdentifiers (3) abstractService Components (3) abstractService Components (3) crossSupportASCs (1) agencyASCs (2) apertureSCs (1) forwardPhyiscalChannel TransmissionSCs (2) forwardPhyiscalChannel TransmissionSCs (2) ServiceManagement FunctionsSCs (13) ServiceManagement FunctionsSCs (13)

FR and SC Information Maintenance Process – Part 1: Addition of New Technology/Capability 5 [outside scope of current abstract service component model] [within scope of current abstract service component model] [adds new mode to existing SC] new technology/ capability defined - add new ASC to reference model 2 - add new node to crossSupportASCs in FR&SC tool - create new SC in reference model 2 - add new SC node under new ASC node in crossSupportASCs in FR&SC Tool {xor} -define replacements 1 for P/E/Ds of existing FRs as appropriate -add new P/E/Ds to existing FRs as appropriate [substitutes for existing SC] {xor} - create new SC in reference model - add new SC node under appropriate ASC node in crossSupportASCs -define new FR(s) and P/E/Ds as appropriate - add new FR(s) to SC in reference model 2 -add new FR nodes and P/E/D nodes to crossSupportFunctionalities in FR&SC Tool -update definition of revised FR(s) in reference model 2 as appropriate -Replace 1 P/E/D nodes in crossSupportFunctionalities in FR&SC Tool as appropriate KEY Source of new technology specification (e.g., another CCSDS WG) CSSA maintenance team, supported by tools CSSA maintenance team working with subject matter expert group Update affected SANA registries

Footnotes for Part 1 Diagram 1. Replacement of FR P/E/Ds  When a P/E/D need to be revised, a new one to replace it is defined (with a new OID), and the old P/E/D is deprecated  This allows different installations to update on different timescales and not require massive concurrent updates 2. Updates of the FR & SC Reference Model  Updates of the Reference Model may be some combination of changes to the main text and addition of supplemental annexes Addition of a new Abstract Service Component warrants an update to the main text (rare occurrence) Addition of a new SC specialization of an existing ASC could be done in in annex (more routine occurrence) What about revisions of core (i.e., main text) SCs due to addition of modes? 6

7 FR and SC Information Maintenance Process – Part 2: SM Additions/Modifications of Existing P/E/Ds need for new/revised P/E/D(s) identified -define replacements for P/E/Ds of existing FRs as appropriate -add P/E/Ds to existing FRs as appropriate -update definition of revised FR(s) in reference model as appropriate -replace P/E/D nodes in crossSupportFunctionalities in FR&SC Tool as appropriate KEY Source of new technology specification (e.g., another CCSDS WG) CSSA maintenance team, supported by tools CSSA maintenance team working with subject matter expert group Update affected SANA registries