1 W.Hell (ESA) November 2015 FR Model and Registry Considerations FR Model and Registry Considerations November 2015

2 W.Hell (ESA) November 2015 Status “Holger” Tool The tool has been extended such that it permits the definition of directive qualifiers, directive guard conditions and event values For the sake of simplicity the parameter “template” is used for both directive qualifiers and event values Given that we will have ‘generic’ directives permitting the setting various FR parameters, the possibility to specify guard conditions as part of the definition of a controlled parameter has been added Due to the above mentioned extensions, convenient viewing of the now generated XML files tool using a browser requires a revised style sheet that is being prepared by Holger

3 W.Hell (ESA) November 2015 Status “Holger” Tool

4 W.Hell (ESA) November 2015 Status “Holger” Tool

5 W.Hell (ESA) November 2015 Status “Holger” Tool

6 W.Hell (ESA) November 2015 Status “Holger” Tool I’m using the capability of the tool to automatically generate OIDs. That means that OIDs no longer in use because e.g. a parameter was deleted get recycled. I plan on working that way as long as we do not have an official registry. We will need to discuss [scheduled for Wednesday, 16:30] with SANA as the XML they will have to digest for the “official” registry differs from what was used for the beta registry For those who intent to participate in the creation of the SANA FR registry, it is probably more convenient to use the “Holger Tool” rather than a browser – generation of alternate specifications can than easily be done

7 W.Hell (ESA) November 2015 Status FR Model The so far existing (revised) FR definitions are based on the July version of John’s “FR Master Diagram” At least so far I have not run into structural issues; in some cases some minor corrections of the characterization of the types of data exchanged between the FR instances is needed which may already be fixed in John’s September version of the FR Master Diagram Where we have/had discrepancies between the FR type naming in the model and the tool generated XML file, I’m adopting the diagram names (so far one suggestion to change an FR name)

8 W.Hell (ESA) November 2015 Status FR Model

9 W.Hell (ESA) November 2015 Status FR Model We should be aware that both the FR diagram and the corresponding XML file are incomplete in the sense that there are not (yet) covered Recommendations (CCSDS B-1 (CDMA link incl. associated ranging), CCSDS B-1 (high rate TM link and coding), CCSDS B-1 (DVB-S2 coding), and CCSDS B-1 (Space Data Link Security Protocol), and things in the pipeline such as ranging over suppressed carrier, sliced LDPC, USLP). Also DTN related Recommendations except IP over Encap are not covered yet. An all-in-one-go delivery of the FR definitions appears not to be feasible – we should discuss needs and priorities and a resulting delivery plan

10 W.Hell (ESA) November 2015 Status FR Definition At the moment I’m in the process of revising and extending the existing FR definitions for the forward link; given that almost all fwd FR type parameters can not only be monitored, but also be controlled, this is the most demanding part in terms of extensions The most important extension is the addition of the directives (including guard conditions) and the associated directive qualifiers that permit setting of controllable parameters; the approach taken is “full control” such that a future SC-CSTS can offer the flexibility needed for intra-agency use

11 W.Hell (ESA) November 2015 Status FR Definition No attempt has been made yet to define FR events As pointed out already on various occasions, I feel uncomfortable because the FR definitions as they exist so far are in essence my personal view / taste and have not been subject to any serious review Also, depending on the target delivery date and scope of the “official” registry and depending on other activities I may be asked to do, putting at least one additional person on the job will probably be necessary and provide for the advantage that there is at least a second opinion governing the definition work. Ideally, such person will have good knowledge of in particular SLS CCSDS Recommendations and hands-on operational experience

12 W.Hell (ESA) November 2015 Specific FR Definition Topics Directive Guard Conditions These conditions can be “elegantly” expressed by means of a “formal” clause when the condition depends on FR parameters. However, other conditions are in free text format. Examples: “commanded-maximum-mc-tc-frame-length ≤ TC MC Mux: maximum- tc-frame-length” “The fwd-401-carrier-status can be set to 'up' only if in view of the given antenna pointing, the EIRP and the spectrum of the radiated signal the ITU limits regarding the permitted spectral power density are respected. Furthermore, the following parameters must have a valid value: - fwd-401-carrier-eirp; - fwd-401-carrier-polarization; - commanded-401-nominal-fwd-carrier-frequency.”

13 W.Hell (ESA) November 2015 Specific FR Definition Topics The Directive Guard Conditions defined so far are the result of some initial thoughts rather than in- depth analysis of what it takes to get an operationally robust system. As a very minimum, the above mentioned “second opinion” is needed. Trajectory predicts Some FRs need predicts to do their job (antenna steering, carrier frequency ramping). So far this is not modelled in any way. Is it good enough to add a dedicated parameter to those FRs the value of which is the name of the required file? It occurs to me that there is no need to show the flow of such files in the FR diagram.

14 W.Hell (ESA) November 2015 Specific FR Definition Topics FR behavior wrt. different data types as input Normally the configuration process and the directive guard conditions should prevent that an FR receives input data it is not supposed or not able to process in its current configuration. But what if the “impossible” happens? Shall we add a parameter that reports the type of input data the FR instance is configured to handle? (In some cases this will also help to express the guard conditions in a formal way rather than by means of free text) Shall the FR instance silently disregard false input or shall such input trigger a notifiable event? In case of a configuration error, how do we prevent a notification “storm”?