[Css-csts] Using functional resources internally within a Provider CSSS

Wed Jul 4 15:02:59 UTC 2018

CSSA colleagues ---
This email is a follow-up to discussions that were held mostly in the CSTSWG sessions in Gaithersburg. Because the discussions involved concepts and usage of Functional Resources - which is a topic of interest to the whole CSS Area - I am also including the members of the CSSMWG in the distribution.

At the Gaithersburg meeting, some of the discussions regarding functional resources centered on using FRs internally within an Agency network or ground station (formally, a Provider CSSS or ESLT) to represent the functions performed by an ESLT. I.e., a Provider CSSS might use FRs as the organizing principle for its operational consoles and systems. However, both Holger and Wolfgang have stated that ESA is interested in using FRs for this purpose. We agreed in principle that this was valid, and indeed began to account for the effect of such usage on the parameters, events, and directives (PEDs) that would be defined for FRs (more on that in a bit). However, in thinking about it a bit more, there are several issues that arise that would need to be resolved in order to proceed on this path.

As you may know, the initial concept of functional resource was that it is an abstraction of externally accessible aspects of  the functions performed by an ESLT on behalf of a user Mission in a cross-support context (where in this case cross support means that the Provider CSSS/ESLT and the user Mission confine their interactions to the use of CCSDS cross support services such as SLE and CSTS transfer services and the functions performed by the ESLT are defined by CCSDS Recommended Standards).  This externally accessible aspect has several important ramifications for how FRs are structured and used, including:

1.       The only PEDs that are defined for FRs were to be those that were accessible in the cross support context.

2.       The identifiers of the FR instances are created in the context of the user Mission. Originally, the FR instances were identified by character strings that the Mission would specify that would have significance to that Mission. That subsequently morphed into FR instances being named by the combination of FR Type (OID valued) and FRIN (integer). The FR Type is fixed but the FRINs are still (theoretically) left to the Mission to set. Recently, we've come almost full circle by introducing FR Nicknames - Mission-populated text strings set in the configuration profiles that are aliases (at least in Service Management) for the [FR Type: FRIN] names of the FR instances.

3.       As a consequence of FRIN assignments being Mission-specific, the mapping of any set of FRINs is only valid in the context of a given Service Package. Functional resource instances technically don't exist when no service package is executing.

4.       Functional resource instances are bound to specific real resources only within the context of a Service Package. Even at the same ESLT, the TM Sync and Channel Decoding FR instance with FRIN=5 might be bound to the "real" decoder ABC for one Service Package but to decoder XYZ for another Service Package.

These all work in the original FR concept, in which FRs are only used in a cross-support (i.e., external) view of the functions being performed.

It was the ramifications of item (1) above that were first raised in the consideration of allowing FRs to be used internally within a Provider CSSS. One example is the production status parameter, which from the perspective of the user Mission is read-only, but from the Provider it is also a configuration parameter, since it is the provider that must be able to HALT the resource. Another example is the case of configuring the initial pointing angles of an antenna. From a cross support perspective this is not done directly, but rather it is the product of a scheduling process that involves selecting the ESLT that will support the contact, the time of AOS, and the trajectory of the spacecraft. But internally, the initial point angles can be considered the result of that process, full stop.

In Gaithersburg we agreed that there could be multiple "views" or overlays of the Functional Resources, but (tentatively?) agreed that the "core" view would be one that (for lack of a better way of expressing it) looked as though the FR was indeed instantiated as real resource. E.g., production-status of the FR would be configurable (because it would have to be settable in order to take offline a piece of equipment that does the corresponding function) and the antenna FR would have initial pointing angles as configuration parameters because that is what would be "set" on an antenna. It is these core PED definitions that would be used to populate the SANA FR Registry. This core set would also act as the superset of PEDs that various overlays could select from. E.g., a service management cross support overlay would limit production-status and antenna angle values to be read-only. Those overlay restrictions would be specified in the appropriate Recommended Standards: e.g., the aforementioned parameters would NOT appear in the Configuration Profile book. This is the approach that currently forms our "guidance" for what is in vs. out as far as formal FR PEDs.

What did not come up in our conversation was how such internal usage would comply or conflict with the other aspects of the FR concept, as laid out in points 2, 3, and 4, above?

In the thinking that I have done so far regarding this, my first observation is that any such usage is outside the scope of the CCSDS definition of FRs. In a sense we've already made a concession to the internal usability of FRs by defining the core PEDs to be the ones that are useful internally as well as externally. (We could have, for example, alternatively defined the core PEDs to be only those that are externally visible and required any internal-only PEDs to be defined in Agency-specific subtrees/MIBs).

So our concern from a CCSDS (i.e., cross support) perspective should be to ensure that using FRs internally doesn't break or overly constrain the usage of FRs for purposes of cross support.

My current thinking is that it would not be possible to use the "same" FR instance designations for both internal and cross-support purposes, primarily because the need to dynamically bind FR instances to real resources on a Service Package basis, and only having FR instances exist in the context of executing Service Packages, would not give ESLT operators and operational software sufficient, unambiguous access to those real resources 24/7.

Instead, FRs could be used internally by a Provider CSSS/ESLT by defining an independent set of FR instances that persist outside the scope of supported Missions' Service Packages. Unlike the cross support context, these persistent FR instances would be (quasi-)permanently bound to specific real resources. That is, for example, the internally-defined TM Sync and Channel Decoding FR instance with FRIN=10 at ESLT Q would be bound to the real decoder ABC day in and day out. If a Provider CSSS has multiple ESLTs and the purview of some operators is to extend across ESLTs within that Provider CSSS, the FR Names would have to be unique across the whole Provider CSSS. So for example, only ESLT Q would have the TM Sync and Channel Decoding FR instance with FRIN=10.

These internally-defined FR instances would have names that would be independent of the FR names given by the supported Missions and used in their Configuration Profiles. That implies that during the execution of a Service Package, a real resource would be represented simultaneously by two FR instances. E.g., the functionality performed by decoder ABC in ESLT Q would be represented to the ESLT operators/systems by the TM Sync and Channel Decoding FR instance with FRIN=10, and represented to the Mission (e.g., through MD-CSTS) by the TM Sync and Channel Decoding FR instance with FRIN=5. When decoder ABC is not being used in the execution of any Mission's Service Package, the internal TM Sync and Channel Decoding FR instance with FRIN=10 still exists and its PEDs can be accessed (e.g., for testing purposes) even though no externally-visible FR instance exists to map to that real decoder. Presumably, the operational software and console displays would be designed to somehow relate cross-support FR instances (when they exist) to internal FR instances, but that would be an internal matter outside the scope of the CCSDS FR model and concepts.

An approach similar to the one above would allow the FR approach to be used internally while not putting any additional constraints on the use of FRs for cross support purposes. There may of course be other approaches that do not adversely affect cross support.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20180704/3ae93917/attachment.html>