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

Holger.Dreihahn at esa.int Holger.Dreihahn at esa.int
Wed Aug 8 07:07:21 UTC 2018


Hi Erik,
I fully agree that M&C as far as CCSDS is concerned should stay at service 
level. The only thing I argue and hope, is that this CCSDS service level 
is adequate for daily routine operations. Moreover I believe that an 
'service level' monitoring is more efficient than a monitoring at the 
level of the very low level parameters. To provide some insight, we have 
the practical problem that the specialists in operations familiar with the 
huge low level, historically grown set of parameters are departing to 
management, retirement or wherever. The new staff are overwhelmed by the 
number and complexity of low level monitoring parameters provided by the 
systems. Here a clear and concise monitoring (one day control and 
configuration) on service level may be beneficial, leaving the exceptional 
cases requiring access and knowledge of low level parameters (equipment) 
to the specialists. In my mind, monitoring Services based on Functional 
Resources may clearly help here. 

Maybe that makes it clearer where I am coming from. I don't even think 
that we need many agency specific FRs if any. What we need for an 
implementation is the mapping of FR parameters / directives / events to 
real world (equipment) parameters, directives (or how you want to call 
that) and events. Yes, this mapping is complex and does not complete 
eliminate the need to monitor low level equipment parameters, but for most 
cases it should do.

To give an idea, currently we have about 30000 - 40000 low level 
parameters in a station. From the top of my head the FR model has around 
600 parameters (let it be 1000 when complete). That sort of reduction to 
meaningful Service Level Parameters together with the notion of a Service 
being provided in a certain Configuration Profile looks to me at the right 
level for efficient routine operations. Moreover it may foster automation 
at a reasonable effort.

Your notion of 'firewalling' is fully supported, in fact I call it 
layering. The FR layer is as specified by CCSDS, noting is equipment 
specific. The layer below is equipment specific, at the end that's where 
you need to look if things go wrong. But as long as things are nominal, as 
an operator I want to be able to configure, provide, monitor and control 
services at CCSDS FR level.

Best regards,
Holger

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc



From:   "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
To:     "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>
Cc:     "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" 
<css-csts at mailman.ccsds.org>, CSS-CSTS 
<css-csts-bounces at mailman.ccsds.org>, John Pietras <john.pietras at gst.com>, 
"CCSDS SMWG ML (smwg at mailman.ccsds.org)" <smwg at mailman.ccsds.org>, 
Wolfgang Hell <wo_._he at t-online.de>
Date:   06/08/2018 23:59
Subject:        RE: [Css-csts] Using functional resources internally 
within a Provider CSSS



Hello Holger,
 
The main concern I have is how far  (or depending on perspective, how 
“deep”) do we as an international standards body have to go to enable 
inter-agency cross support? I would venture that this is essentially to 
the service level and not the level of implementing equipment.  So to the 
extent that there is particular encoding scheme for telemetry, yes, we 
need to state that.  Looking at basic signal characteristics, I think it 
is sufficient to state that we are dealing with a left-hand circular 
polarization, for example, rather than attempting to model that the 
microwave mirrors for a particular type of instance of antenna need to be 
set a certain way to properly achieve reception of the polarized signal.  
I have no quarrel if a particular implementation wishes to detail 
functional resources into its local monitor and control system, but I 
think that any such instances should be carefully “firewalled” from the 
service level FRs.   Taking a look at the CSTS framework, I believe there 
is already a start on this – although perhaps more work is needed.  Below 
is diagram extracted from 921.1-B-1, Annex D.   Here it appears that there 
is an anticipated agencyFunctionalites branch (1.3.112.4.4.2.2). Although 
this is at the level of agency specific functions (at the service level), 
I believe something very similar could be done to put in agency 
internal/implementation level functions which the agency could populate 
internally and which would fit with the particular agencies internal 
review/implementation criteria, rather than being subjected to achieving 
agreement at an inter-agency, CCSDS level. 
 
Best regards,
-Erik 
 
 
 

 
From: Holger.Dreihahn at esa.int <Holger.Dreihahn at esa.int> 
Sent: Monday, July 30, 2018 2:39 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org) 
<css-csts at mailman.ccsds.org>; CSS-CSTS 
<css-csts-bounces at mailman.ccsds.org>; John Pietras <john.pietras at gst.com>; 
CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>; Wolfgang 
Hell <wo_._he at t-online.de>
Subject: Re: [Css-csts] Using functional resources internally within a 
Provider CSSS
 
Hi Erik, 
The idea of using the FRMs also for an internal implementation has of 
course several potential 'pitfalls' but also some justification: 

1) The FRMs must be able to give a comprehensive (high-level) view on a 
ground station for a cross support scenario - otherwise it is useless 
2) if 1) is true, we asked ourselves at ESA if we can use FRMs for a 
general high-level view on all stations - those provided by external 
providers and the ESA internal ones 
3) Of course you need to implement in addition a much more detailed, 
equipment specific low level M&C - finally you must be able to diagnose 
and address all the low level details. Yes, the mapping of the low level 
to the high level is needed and far from trivial. 
4) We need to provide / use FRM based views anyway for external 
stations... 

Maybe we can discuss this layered approach if it is really so horrified or 
if there is some sense to it. 

Best regards, 
Holger 

Holger Dreihahn
European Spacecraft Operations Centre | European Space Agency | S-431
+49 6151 90 2233 | http://www.esa.int/esoc 



From:        "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov> 
To:        John Pietras <john.pietras at gst.com>, "CCSDS SMWG ML (
smwg at mailman.ccsds.org)" <smwg at mailman.ccsds.org>, "CCSDS_CSTSWG (
css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>, Wolfgang Hell <
wo_._he at t-online.de> 
Date:        12/07/2018 20:01 
Subject:        Re: [Css-csts] Using functional resources internally 
within a Provider CSSS 
Sent by:        "CSS-CSTS" <css-csts-bounces at mailman.ccsds.org> 




John, 
  
In all honesty, I have to say I'm rather horrified by the prospect of 
this. I firmly believe that CCSDS shall be required to consider only 
service level interfaces and maintain only standards related to service 
level concerns, and shall not delve into the internals of a particular 
service provider. If an agency wants to apply the functional resource 
model to the internals of its operation then I think as you have noted in 
passing, a separate implementation specific MIB can be established.   
  
I think if you play this out it is not long before you are into a 
standards death spiral: for example, for a  forward carrier, do I ask 
CCSSD to worry about the DSN microwave mirror settings as a functional 
resource –do I have to know that M5 (mirror 5) needs to be interlocked for 
frequency band A for antenna X such that local radiation safety guidelines 
are observed?  Do I need to ask CCSDS to worry about the transmitter 
type/equipment at an aperture such that an FR for transmitter warm up can 
accurately set the warm-up time parameter?  Frankly, to me this is like 
asking the passengers of an airliner to be aware of drag versus distance 
versus fuel efficiency, versus predicted head or tail wind etc in 
calculating how many liters of fuel need to be on board the aircraft 
versus I just want to take a flight to go from Los Angeles to London (the 
service provider handles the details in providing the service to me).   
  
As it is, I think the FRM, as good as it is, is not an easy read.  I think 
adding all the complexities for provider internals to the FRM will in fact 
render us in the domain of (not easy)**2 (maybe cubed?) à verging into the 
impossible to specify.    I strongly urge and recommend the area to keep 
the focus on the FRM to just those service level aspects needed for cross 
support. 
  
Best regards, 
-Erik 
  
From: CSS-CSTS <css-csts-bounces at mailman.ccsds.org> On Behalf Of John 
Pietras
Sent: Thursday, July 5, 2018 6:49 AM
To: John Pietras <john.pietras at gst.com>; CCSDS SMWG ML (
smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>; CCSDS_CSTSWG (
css-csts at mailman.ccsds.org) <css-csts at mailman.ccsds.org>; Wolfgang Hell <
wo_._he at t-online.de>
Subject: Re: [Css-csts] Using functional resources internally within a 
Provider CSSS 
  
Dear all --- 
A minor correction to the email below: the reference to “production 
status” of FRs should be to “resource status”. 
  
(For anyone who cares about the details, we have decided to reserve the 
term “production status” for the parameter of a CSTS that represents the 
rollup of the individual statuses of the production FR instances that 
underlie that CSTS instances. E.g., only if all of the underlying 
production resources are ‘operational’ can the production status of the 
CSTS instance be ‘operational’. Initially we had also used the term 
“production status” to also refer to the status of each individual FR 
type, but we have decided to use “resource status” in the latter case. 
This is targeted for cleanup in the candidate SANA Registry, which still 
uses forms of ‘production status”.) 
  
Best regards, 
John 
  
From: CSS-CSTS [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of 
John Pietras
Sent: Wednesday, July 04, 2018 11:03 AM
To: CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>; 
CCSDS_CSTSWG (css-csts at mailman.ccsds.org) <css-csts at mailman.ccsds.org>; 
Wolfgang Hell <wo_._he at t-online.de>
Subject: [Css-csts] Using functional resources internally within a 
Provider CSSS 
  
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 
  
  
  
 _______________________________________________
CSS-CSTS mailing list
CSS-CSTS at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).



This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20180808/b6a6ab15/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 59630 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20180808/b6a6ab15/attachment.jpe>


More information about the CSS-CSTS mailing list