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

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

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

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

Merged Communication Profile 5 Same result as Cookie cutter

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

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

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

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

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