[cssm] FW: Rough rapid prototype - update

Holger.Dreihahn at esa.int Holger.Dreihahn at esa.int
Tue Jun 16 12:55:23 UTC 2020


Dear CSS Colleagues,
As promised an export of the Functional Resource Model to XSD has been 
prepared, an example is attached. This is fresh from the press and may 
contain errors and of course things we want to add / change / change in 
the future. However, syntactically the XSD validates for me and can serve 
as a starting point to start the discussion.

Some notes:
For every 'SANA' published type (type definition, OID, classifier, 
description etc.) two types are generated: One with the pure type 
definition, another one using that type definition and adding the OID and 
the classifer as an attribute. The pure type definition is needed, as we 
allow FRM local type references - the referenced types should of course 
only provide the type definition, not OID attributes and the like. In 
addition there is a corresponding element to use the generated types in as 
a substitution of 'AbstractParameter'.
Also type definitions for event values and directive qualifiers are 
generated, although we may decide to generate only parameter types as XSD 
- TBD
The reference to the attached CSSM schemas for the AbstractParameter is at 
the moment hard-coded, in the future that should be configurable via 
preferences in eclipse

Looking at the export I am again impressed about the amount of valuable 
material produced by John and Wolfgang as the main FRM contributors. 
Thanks at that point!
I think we have a good chance here to make additional use of the FRM: 
On-the-wire type definitions in ASN.1 and the corresponding XSD 
definitions for use in configuration profiles, SMURF and so on. This 
approach  guarantees consistency and I have the hope that it eliminates 
the need to repeat similar (identical) definitions for CSSM purposes. 

Best regards,
Holger

Example:
<!--
This parameter identifies the antenna that is involved in providing a 
given support.
 The antenna may either be identified by its name where typically this 
name is defined
 by the operating agency so that no guarantee can be given that the 
identifier is
 globally unique. Alternatively the antenna may be officially registered 
in SANA
 in which case it has a globally unique Object Identifier. Knowledge of 
which antenna
 is being used is needed for a number of aspects, e.g. to assess the 
observed signal
 levels with respect to the antenna performance or to perform time 
correlation that
 requires knowledge of the exact geographical location of the given 
antenna.
Note:
 In case the antennas used for uplink and downlink are not identical, the 
Functional
 Resource (FR) instance number shall be used to differentiate them. 
Antenna arrays
 will be modeled by a dedicated FR type
-->
 
 <xsd:element name="AntIdNamedElement" type="AntIdNamed" substitutionGroup
="cssm:AbstractParameter" />
 <xsd:complexType name="AntIdNamed" >
  <xsd:complexContent >
   <xsd:extension base="cssm:AbstractParameterType" >
    <xsd:sequence >
    <xsd:element name="AntId" type="AntId" />
    </xsd:sequence>
    <xsd:attribute name="oid" type="ObjectIdentifier" fixed=
"1.3.112.4.4.2.1.10100.1.2.1.1" />
    <xsd:attribute name="classifier" type="xsd:string" fixed="AntId" />
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>
 
  <xsd:complexType name="AntId" >
   <xsd:choice >
    <xsd:element name="antennaName" >
     <xsd:complexType >
      <xsd:attribute name="value" use="required" >
 
       <xsd:simpleType >
        <xsd:restriction base="xsd:string" >
         <xsd:minLength value="3" />
         <xsd:maxLength value="16" />
        </xsd:restriction>
       </xsd:simpleType>
      </xsd:attribute>
     </xsd:complexType>
    </xsd:element>
    <xsd:element name="antennaOid" >
     <xsd:complexType >
      <xsd:attribute name="value" use="required" >
 
       <xsd:simpleType >
       <xsd:restriction base="ObjectIdentifier" />
       </xsd:simpleType>
      </xsd:attribute>
     </xsd:complexType>
    </xsd:element>
   </xsd:choice>
   </xsd:complexType>







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



From:   "John Pietras" <john.pietras at gst.com>
To:     "CCSDS SMWG ML (smwg at mailman.ccsds.org)" <smwg at mailman.ccsds.org>
Cc:     "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>, "Wolfgang 
Hell" <wo_._he at t-online.de>
Date:   26/05/2020 20:31
Subject:        FW: Rough rapid prototype - update



CSSMWG colleagues ---
At today’s telecon, we discussed the results of the SACP splinter meeting 
on 14 May. Below is the summary email that I sent out following that 
meeting, along with Marcin’s response and Erik’s comments. In order to 
make the summary more efficient, I have collapsed my responses to Erik’s 
comments into red responses interleaved in Erik’s comments. I have also 
added two more diagrams that I hope will be helpful. All of the diagrams 
and supporting material re in the attached zip file.
 
Best regards,
John
 
From: Barkley, Erik J (US 3970) [mailto:erik.j.barkley at jpl.nasa.gov] 
Sent: Wednesday, May 20, 2020 5:06 PM
To: Marcin.Gnat at dlr.de; John Pietras <john.pietras at gst.com>
Cc: Colin.Haddow at esa.int; Holger.Dreihahn at esa.int; wo_._he at t-online.de
Subject: RE: Rough rapid prototype
 
John,
 
I started to take a look at the proposal/prototype. I encountered errors 
using Oxygen to look at the XML instance document.  I don't know if you 
are using a fairly old version of an XML editor but it seems to let things 
pass that perhaps may be are no longer accepted in XML? In any case, 
please see the screenshot below. It appears that the use of quoted angle 
brackets in the value for attributes is causing a problem. Going through 
by hand and removing the angle brackets made Oxygen happy (three instances 
altogether). 
 
 
That was my mistake and was not a characteristic of the version of XML Spy 
that I used. I habitually use angle brackets as a notation for giving a 
descriptor of a thing instead of the thing itself, e.g., “<Antenna FR 
OID>” instead of “1.3.112.4.4.2.1.10100’. My 2008 version of XML Spy 
actually flagged the errors, but I somehow ignored them. I have changed 
the notation to “{Antenna FR OID}”, etc., and XML Spy (and presumably 
Oxygen) are okay with that. I have also corrected the instance document in 
the zip file and in my email below.
 
It does seem like the approach has some promise. Putting most of the 
functional resource information into attributes is I think not a bad way 
to go. Here again I expect system implementers won't really care about 
this information but it does tend to be a bit more out of the way so to 
speak but available for the "cognoscenti". (In some sense it comes down to 
how much of the functional resource model we expect implementations to 
understand -- I tend to think of this as an internal to CCSDS engineering 
toolkit rather than something that is "sold" to system implementers).
 
Having looked at this for a little bit though I must say that it seems to 
me some obvious parameters are missing. For example, given that this is 
telecommand, I would've expected to easily find a modulation index? Or 
modulation mode (residual or suppressed?)  Or how about subcarrier shape? 
(Sine wave versus square wave).  Also, it seems like basic forward carrier 
parameters needed to support the telecommand service are not here such as 
carrier frequency or subcarrier frequency. And in addition to this, I do 
see some parameters that don't make the most sense to me in terms of a 
profile with regard to forward carrier to a spacecraft – for example, I 
think that antenna pointing mode tends to be rather idiosyncratic to the 
aperture and tends to look more like a status parameter rather than a 
configuration parameter. Similarly transmit status such as "radiating into 
space” are more execution time values rather than configuration parameters 
for a carrier going to a spacecraft. 
 
I did just a few parameters for each FR, enough to demonstrate the concept 
with parameters that are actually in the FRM database – there are MANY 
more configuration parameters in that database. I just picked a few at 
random to illustrate the concept. Regarding the various parameters that 
you would have expected in the Ccsds401SpaceLinkCarrierXmit FR –it was a 
quick, late night proof-of-concept. But I know that you are anxious to 
know what *is* in the FRM, so I’ve attached the ASN.1 definitions of the 
Ccsds401SpaceLinkCarrierXmit FR configuration parameters that are 
currently in the FRM (the ASN.1 listing is already a product of the FRM 
Editor). Please take a look at it, and I refer you to Wolfgang for your 
questions regarding the individual parameters that you called out. 
Regarding the particular Antenna parameter that you make remarks about, 
Wolfgang assures me that it is a configuration parameteras far as ESA 
stations are concerned. The antenna has been perhaps the hardest FR to 
nail down, because we don’t have any “standard” definition for them. Those 
FRs that are the result of CCSDS standards are the easiest to define FRs 
for, especially those that already identify the necessary managed 
parameters. Once we do arrive at a consensus definition about what does 
need to be configured regarding antennas, it would probably be a good idea 
to beef up the Antenna FR description in the draft FR Ref Model Magenta 
Book to provide some motivation for defining the configuration parameter 
that we (will) have for it.
 
Also, I have to wonder about what all of the off-line storage is about 
with regard to configuration for a carrier going to a spacecraft.
 
The reason that off-line storage is includes in SLS (aka on-line) 
configurations is because (e.g., in the return direction,  data must be 
recorded in s data store for it to be subsequently retrieved in off-line 
service instances. The data store FR represents the allocation of storage 
to the Mission, and the current usage of that allocated storage. Having 
said that there is an error in the schema, assuming that the schema 
represents the SLS/online case. The schema currently allows return data to 
flow out of the data store through a transfer service. That is incorrect – 
data flow from a data store to/through a transfer service must be 
represented by an offline service instance. I.e., the data store is common 
to both online and offline services – it is the “buffer” between the two 
types of service. The schema needs to be modified.
 
Having said all of that, I am happy that we can at least start to have 
these kind of conversations. As I said I think this starts to show some 
promise and I look forward to further discussion at our upcoming 
teleconference on the 26th.
 
Best regards,
-Erik
 
From: Marcin.Gnat at dlr.de <Marcin.Gnat at dlr.de> 
Sent: Monday, May 18, 2020 13:05
To: EXTERNAL-Pietras, John (US 332C-Affiliate) <john.pietras at gst.com>
Cc: Colin.Haddow at esa.int; Barkley, Erik J (US 3970) <
erik.j.barkley at jpl.nasa.gov>; Holger.Dreihahn at esa.int; wo_._he at t-online.de
Subject: [EXTERNAL] RE: Rough rapid prototype
 
John,
 
I took a deeper look, and I must say I get probably the same kind of 
excitement as you. It looks really promising now. Almost pity you took me 
the fun of searching for that XSD-clonk ;-). No, but seriously, this 
resembles what I would more or less do, thus when we already have it, we 
can speed up.
 
As you mentioned, it would be enough to (re)generate the 
ConfigProfFrParametersSchemas XSD from FRM. The another XSD you provided 
is a “glue” between my Config Profile and the FRM Schema. We can even mix 
unregistered parameters, interfaces and FRM Parameters, which is great.
 
Best Regards
Marcin
 
From: John Pietras [mailto:john.pietras at gst.com] 
Sent: Freitag, 15. Mai 2020 04:55
To: Gnat, Marcin; Holger.Dreihahn at esa.int; Wolfgang Hell
Cc: Colin.Haddow at esa.int; Erik.J.Barkley at jpl.nasa.gov
Subject: Rough rapid prototype
 
Gentlemen,
I think that we made excellent progress today in our FRM/Config Profile 
telecon. 
 
To briefly summarize my understanding of what we have agreed to as an 
approach (please correct me if I’m wrong):
-          The config profiles will be based on Marcin’s (relatively) 
simple FR Strat-oriented schema.  This schema accommodates both FR-defined 
configuration parameters and “locally-defined” configuration parameters in 
any combination, which in turn supports purely-local use of the schema by 
an Agency to fully-compliant, cross-supportable configuration profiles.
-          Regarding the compliance with the FRM, we identified two levels 
at which configuration profile data could be automatically generated from 
the FRM database for use in developing configuration profiles. The first, 
and simplest, level would be to generate XSD type files corresponding to 
“only” the configuration parameters of each FR. These parameter type 
definitions would be made available through SANA (or some other 
mechanism). This level provides only information about the configuration 
parameters - for example, any constraints about which specific FRs are 
allowed to be combined with other FRs (e.g., encoders must be combined 
with transmission carriers and not reception carriers) would be outside 
the scope of the tool(s) (more on this approach in a moment). A second, 
and somewhat more sophisticated level, would involve automatically 
generating schema types for full FRs, including built-in constraints of 
what kinds of FRs are permitted to be “strung together”. The information 
to build these kinds of schema files is already supported by the FRM 
database.
-          We decided that we would explore the first (simpler) level in 
the near term, and depending on the success possibly also looking deeper 
into the second level. Holger plans to have a demonstration ready by the 
end of June of automated XSD schema type generation from the FRM database.
 
I was so motivated by the approach that we have tentatively adopted that I 
decided to do a rough rapid prototype of what I think the first level will 
look like. The attached zip file contains 3 XSD files, one XML instance 
document, and 4 XML Spy diagrams. The following explains and uses these 
files.
 
The core XSD file (902x05w0_01-ConfPrflComnClss-200514B.xsd) is based on 
Marcin’s config profile file 902x05w0_01-ConfPrflComnClss.xsd. Marcin’s 
file had INCLUDE statements for several other file that linked the config 
profile into what Marcin referred to as the “service management 
landscape”. Since I did not have those files readily available, I 
commented out those INCLUDE statements and dummied out the few parameters 
and data types that those files provide. None of the removed material is 
needed for this prototyping effort, and in any case it would be trivial to 
re-insert that excluded material.
 
In keeping with Marcin’s approach, the schema has abstract elements that 
correspond to FRs in the different FR Strata, with relationships 
established among these abstract strata-level FRs. E.g., the abstract 
ApertureFR class contains the abstract PhysicalChannelFR class. The  major 
change in the 902x05w0_01-ConfPrflComnClss-200514B.xsd file (with respect 
to Marcin’s original 902x05w0_01-ConfPrflComnClss.xsd file) is that 
whereas in the original file the base FunctionalResourceType type 
contained an element for “sanaRegisteredFrParameters”, that element has 
been removed from the base FunctionalResourceType. Instead, each abstract 
strata-level class now contains its own abstract xxxFrStratumParameters 
element, plus abstract elements for the FR strata that can be contained by 
that stratum. E.g., the ApertureFR type extends the base 
FunctionalResourceType with an optional ApertureFrStratumParameters 
element and an optional physicalChannelFR element. Here’s what the base 
FunctionalResourceType looks like now:
 
 

 
And here’s what the ApertureFR type looks like as extended by the 
ApertureFrStratumParameters element:
 

 
 
Here’s what the schema in the 902x05w0_01-ConfPrflComnClss-200514B.xsd 
file looks like expanded for the four strata (Aperture, Physical Channel, 
Sync and Channel Coding, and Data Transfer Service) when the 
FR-parameter-specific schema file is included:
 

 
Now for the fun stuff. I created the 
AbstractFrStrataParameterSets-200514A.xsd file to contain the abstract 
XxxFrStratumParametersType types and the corresponding 
xxxFrStratumParameters elements for the Aperture, Physical Channel, Sync 
and Channel Coding, and Data Transfer Service strata. The 
AbstractFrStrataParameterSets-200514A.xsd file is INCLUDEd in the 
902x05w0_01-ConfPrflComnClss-200514B.xsd file.
Note - I first tried to create these elements and types within the 
902x05w0_01-ConfPrflComnClss-200514B.xsd file itself, but these type and 
element definitions also have to be accessed by the 
ConfigProfFrParametersSchemas-20200514B.xsd file (which I’m going to 
discuss momentarily), which is also INCLUDEd in the 
902x05w0_01-ConfPrflComnClss-200514B.xsd. Not surprisingly, having two 
schema file attempt to INCLUDE each other (file A INCLUDEs file B, and 
file B INCLUDes file A) does not sit well with the schema parser. However, 
having file A INCLUDE file B, and file C INCLUDE both file A and file B, 
works fine so that’s what I did. 
 
Once the AbstractFrStrataParameterSets-200514A.xsd file is fleshed out 
with the remaining 6 XxxFrStratumParametersType types, theoretically 
that’s all that needs to be done for the core 
902x05w0_01-ConfPrflComnClss-200514B.xsd and 
AbstractFrStrataParameterSets-200514A.xsd files. Beyond that, everything 
related to the actual FR types is handled by (automated) updates to the 
third XSD file.
 
The remaining file, ConfigProfFrParametersSchemas-20200514B.xsd, 
represents the file that contains the parameter types for the actual 
individual functional resource types. That is, this file represents the 
file that would be automatically generated out of the FRM database. For 
the purposes of this quick and dirty “prototype”, I hand-generated the 
parameter definition elements and corresponding XML schema type for a few 
configuration parameters for each of the Antenna, 
Ccsds401SpaceLinkCarrierXmit, TcPlopSyncAndChnlEncode, and FCltuTsProvider 
functional resources. The names (“classifiers”) and schema type 
definitions for these parameters was taken from the FRM database. 
Purposefully, these 4 FRs also happen to be the same FRs as in the F-CLTU 
Space Link Service Profile. Each <FR name>FrParameters parameter is a 
substitute for its corresponding xxxFrStratumParameters element. E.g., 
antennaFrParameters is defined as a substitute for aperture 
FrStratumParameters. When the ConfigProfFrParametersSchemas-20200514B.xsd 
file is INCLUDEd in the 902x05w0_01-ConfPrflComnClss-200514B.xsd file, 
this is the resulting XML Spy diagram:
 

 
Details will probably vary in the final standard, but this represents the 
gist of the concept. 
 
Finally, here’s the grid view of an instance document generated from the 
above schema, where the non-relevant elements have been removed:
 

 
Please let me know if this aligns (at a high level) with what you thought 
we discussed today. Thanks.
 
Best regards,
John[attachment "SACP_schema_development_20200526.zip" deleted by Holger 
Dreihahn/esoc/ESA] [attachment 
"Ccsds401SpaceLinkCarrierXmit-configParams.asn.txt" deleted by Holger 
Dreihahn/esoc/ESA] 



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/smwg/attachments/20200616/aaf513c8/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 16827 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/aaf513c8/attachment-0004.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 26002 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/aaf513c8/attachment-0005.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 91816 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/aaf513c8/attachment-0006.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 162937 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/aaf513c8/attachment-0007.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 258431 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/aaf513c8/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SchemaCssmAbstractParameter-v1_0_0.xsd
Type: application/octet-stream
Size: 5502 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/aaf513c8/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SchemaCssmCcsdsTimecodes-v1_0_0.xsd
Type: application/octet-stream
Size: 847 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/aaf513c8/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FunctionalResourcesMaster200520.xsd
Type: application/octet-stream
Size: 798328 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/aaf513c8/attachment-0005.obj>


More information about the SMWG mailing list