1. Configuration Profile Development Approach Bakeoff: Build Up Results CCSDS Spring Workshop Pasadena, CA 23-27 March 2015 Anthony Crowson Telespazio VEGA

2. www.ccsds.org Background In London, we discussed two approaches to creating building blocks for Configuration Profiles and Service Agreements o Define Service Component-level templates for the various technologies  Define procedures for combining the various templates to form operational Configuration Profiles o Define some number of “standard” Configuration Profile templates that (as a group) cover common service configurations  Define procedures for trimming down the standard templates to create operational Configuration Profiles We decided to explore both options in a “bake-off” o Anthony would explore the build-up-from-Service-Component approach o John would explore the trim-down-standard-Configuration-Profile approach – a.k.a. the “cookie cutter” approach This is a report on the build-up approach 2

3. www.ccsds.org What is the (Nominal) Build-Up Approach? Mission starts from o Individual predefined templates for each of the end-to-end services (~per IOAG SC#1) to be supported o Service Component specifications for each of the technologies implemented in the mission’s communications stacks Mission creates service profiles o Specifies the modes and options for each template o Specifies the concrete service component for each slot in each template  Some SCs may appear in more than one template o Populates parameter values to configure each service component Mission combines service profiles to create communication profile(s) 3

4. www.ccsds.org Forward Data Delivery o Forward Frame  TC Frame Mode Return Data Delivery o RAF o RCF o ROCF Bakeoff Service Profiles 4 Radiometric Raw Data Radiometric

5. www.ccsds.org Merged Communication Profile 5 Same result as Cookie cutter

6. www.ccsds.org Building Blocks Service Profiles o Defined by CSSM (Magenta? SANA?) o Reflect known valid technology combinations for one service o Allow drop-in technology replacement UNLESS specific technology dependency exists  E.g. F-CLTU specific to TC SDLP and TC Synch & Coding  Where drop-in possible, no need to update profile for new technology Service Component Specifications o Defined nominally per technology specification ~ Blue Book o Correspond roughly to “Managed Parameters” section o Filed with SANA with ref to relevant BB  CSSM / subject WG responsibility? o Should cover Service Catalog / Agreement etc. considerations too… 6

7. www.ccsds.org Service Component Specifications Service Component specification relevant for o Service Catalog o Service Agreement o Configuration Profile o Service Monitoring o Service Control One “Data Sheet” per Service Component o Functional Resources o FR parameters (& directives, events) from FR/OID tree o Wiring rules (internal & external) and cardinalities o Across SM lifecycle o C.f. SOIS/APP Electronic Data Sheets – probably much simpler though 7

8. www.ccsds.org Considerations This is not quite “build up from Service Components” … and work out how to wire them together It is a build-up from o A small number of end-to-end service profiles o Service Component templates corresponding to mission technologies (and largely derived from Blue Books) o Wiring predefined (with some variability) in service profiles 8

9. www.ccsds.org Extensibility – articulation points New technology e.g. optical comms, NG SLP, new transfer service o Drop-in replacement (e.g. RF -> optical under existing SLPs)  New Service Component specification  No change to Service Profiles o Or it has new interactions within comms stack / across stacks  New modes/options in existing profile o Or it provides a new end service to the mission user  Needs new service profile New service profile? o Implies new end-to-end service Bilateral / non-CCSDS technology o As above o Needs mechanism to pull in non-CCSDS (non-SANA?) profiles 9

10. www.ccsds.org More considerations Overlap between different cookie cutters? Do we expect any mission to need more than one cookie cutter for alternative comms configurations? Loose leaf approach o Loose leaf set of technology-specific Service Component “data sheets”  SANA only (i.e. own BBs for most, but no SM book to specify)? o Loose leaf (but less volatile) set of Service Profiles  SM Magenta (?) book, pink pages to add new services o SM BB(s) for SM info entities (SA, CP etc) with construction rules  Stable, references to loose leaf sources (not individual loose leaves)  GB shows worked example Complexity o Many separate definitions imported (10-15 in example) o “Menu” is then limited to selected definitions 10