[cssm] [EXTERNAL] Re: FW: Rough rapid prototype - update
Barkley, Erik J (US 3970)
erik.j.barkley at jpl.nasa.gov
Tue Jun 16 21:18:12 UTC 2020
Dear Holger,
Impressive work. There is clearly a lot of good careful work that has gone into developing this and getting this to the point of having the XML schema for the functional resource model.
Not to take anything at all away from the excellent work here, but just to perhaps set the tone for the conversation tomorrow, one of the things I'm looking for is a way to easily extract the parameters that are most applicable to the configuration profile for service management and perhaps there may be some extensions that the functional resource model would not "logically" support. I suspect the former is supported by the multiple type definitions and classifiers such that we could extract the configuration parameters of interest and leave what, tends to me to be more of the monitoring parameters out of the service management configuration profile definition. For example, with regard to the
“Ccsds401CarrierXmitPhysChnlNameNamedElement”, there are items such as commanded azimuth and commanded elevation. These kind of items, to me, do not really belong in a mission configuration profile but rather as part of monitor data reporting at service execution time.
An example, of where we may need some sort of extension to the functional resource model is if we consider management of the forward carrier from the spacecraft perspective. I believe it is feasible for many spacecraft to "flywheel" for a certain amount of time without receiving the forward carrier signal such that they can continue to receive and process commands without requiring the forward carrier tuning process again. Perhaps operationally this is not a common practice and so we may need yet even further configuration parameters to indicate whether or not this is to happen/is allowed (something along the lines that would indicate a re-sweep is always required after breaking the forward carrier versus re-sweep only required after 15 minutes of idle time or something like that).
Thanks again for the impressive work, and I look forward to an interesting conversation tomorrow.
Best regards,
-Erik
From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of Holger.Dreihahn at esa.int
Sent: Tuesday, June 16, 2020 05:55
To: EXTERNAL-Pietras, John (US 332C-Affiliate) <john.pietras at gst.com>
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>; Wolfgang Hell <wo_._he at t-online.de>
Subject: [EXTERNAL] Re: [cssm] FW: Rough rapid prototype - update
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:
1. 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'.
1. Also type definitions for event values and directive qualifiers are generated, although we may decide to generate only parameter types as XSD - TBD
1. 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
1.
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
1.
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>
1.
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<mailto:john.pietras at gst.com>>
To: "CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>)" <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Cc: "Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>" <Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>>, "Wolfgang Hell" <wo_._he at t-online.de<mailto: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<mailto:Marcin.Gnat at dlr.de>; John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Cc: Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>; Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>; wo_._he at t-online.de<mailto: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<mailto:Marcin.Gnat at dlr.de> <Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>>
Sent: Monday, May 18, 2020 13:05
To: EXTERNAL-Pietras, John (US 332C-Affiliate) <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Cc: Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>; Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>; Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>; wo_._he at t-online.de<mailto: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<mailto:Holger.Dreihahn at esa.int>; Wolfgang Hell
Cc: Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>; Erik.J.Barkley at jpl.nasa.gov<mailto: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:
[cid:image001.jpg at 01D643E4.F766C400]
And here’s what the ApertureFR type looks like as extended by the ApertureFrStratumParameters element:
[cid:image002.jpg at 01D643E4.F766C400]
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:
[cid:image003.jpg at 01D643E4.F766C400]
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:
[cid:image004.jpg at 01D643E4.F766C400]
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:
[cid:image005.png at 01D643E4.F766C400]
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<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/c0b3811a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 16827 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/c0b3811a/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 26002 bytes
Desc: image002.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/c0b3811a/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 91816 bytes
Desc: image003.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/c0b3811a/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 162937 bytes
Desc: image004.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/c0b3811a/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 258431 bytes
Desc: image005.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200616/c0b3811a/attachment-0001.png>
More information about the SMWG
mailing list