[cssm] FW: Rough rapid prototype - update

John Pietras john.pietras at gst.com
Tue May 26 18:31:14 UTC 2020

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,

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


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 "'. 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,

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


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

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

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:image005.jpg at 01D6336A.5011C4A0]

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

[cid:image010.jpg at 01D6336A.5011C4A0]

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:image011.jpg at 01D6336A.5011C4A0]

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 01D63062.007F0160]

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:image012.png at 01D6336A.5011C4A0]

Please let me know if this aligns (at a high level) with what you thought we discussed today. Thanks.

Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200526/d6e7dca9/attachment-0001.htm>
-------------- 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/20200526/d6e7dca9/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 16827 bytes
Desc: image005.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200526/d6e7dca9/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.jpg
Type: image/jpeg
Size: 26002 bytes
Desc: image010.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200526/d6e7dca9/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image011.jpg
Type: image/jpeg
Size: 91816 bytes
Desc: image011.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200526/d6e7dca9/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image012.png
Type: image/png
Size: 258431 bytes
Desc: image012.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200526/d6e7dca9/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SACP_schema_development_20200526.zip
Type: application/x-zip-compressed
Size: 164326 bytes
Desc: SACP_schema_development_20200526.zip
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200526/d6e7dca9/attachment-0001.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Ccsds401SpaceLinkCarrierXmit-configParams.asn.txt
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200526/d6e7dca9/attachment-0001.txt>

More information about the SMWG mailing list