[cssm] Configuration Profile schema update V0.06
Marcin.Gnat at dlr.de
Marcin.Gnat at dlr.de
Mon Feb 21 12:05:59 UTC 2022
I get only headaches when weather is changing. So for now all good 😉….
Generally, we will talk in the meeting, but to your points:
1. We need to define “we”, “really” and “need” in your question 😉. But seriously, this part is optional, and if it does not hurt, I would leave it (we can call it “John Pietras heritage”, hihi). We can always decide on long haul to cut it away.
2. Yes, you are right. This is a topic which we still have to “process” and decide, which FRM parameters are actually needed/required/senseful in context of SM and CP. Maybe you remember I started to make a similar table (I was stuck somewhere at 401 Xmit parameters, I need to continue some day). We should start to consolidate our points (I assume some Excel table? I can offer setting this up, and put on CWE) and then during some session pin down which things stay and which have to go.
From: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Sent: Samstag, 19. Februar 2022 01:16
To: Gnat, Marcin <Marcin.Gnat at dlr.de>; smwg at mailman.ccsds.org; holger.dreihahn at esa.int
Cc: Frase, Wolfgang <Wolfgang.Frase at dlr.de>
Subject: RE: Configuration Profile schema update V0.06
I finally had a few moments to go through your rather impressive .zip file. Attached please find some comments, taking the example configuration profile as the reference point. Essentially the comments come down to
1. Do we really need the “dependency” configuration profile information?
2. The antenna element parameters contain what can be considered FRM “raw” configuration parameters and my contention is that most if not all of these disappear from a cross support service management configuration profile as the configuration of the FRM parameters here would in fact be part of a managed service – i.e., not something that a mission user should have to know about and/or derivable from information that the mission user provides in other parts of their configuration
I propose that we take a look at this at the upcoming teleconference on Tuesday. Also, this has to do with metadata terms with regard to putting the FRM in a managed service context that we plan to talk about at a splinter session in the not-too-distant future.
Hopefully this is not too headache inducing :-)
From: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>> On Behalf Of Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>
Sent: Wednesday, December 29, 2021 6:57
To: smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>; holger.dreihahn at esa.int<mailto:holger.dreihahn at esa.int>
Cc: Wolfgang.Frase at dlr.de<mailto:Wolfgang.Frase at dlr.de>
Subject: [EXTERNAL] [cssm] Configuration Profile schema update V0.06
Attached you can find the “implementation package” with current schema package (latest as from Colin) plus Configuration Profile schemas V0.06 and the FRM Schemas exported from Registry by Holger (with a minor change, but about it later). It also includes latest versions of Blue/Magenta/White books, to help understand stuff. Logically, SACP is still missing (mea culpa, hahaha).
So, except the SMURF, SPDF, CPIF and SSF (plus auxiliary schemas) as provided by Colin with latest “release”, you can find there:
902x05w0_06-ConfPrfl_Template.xsd --> actual Configuration Profile template (can be used to create individual Configuration Profiles)
902x05w0_06-ConfPrflCmnClss.xsd --> main Configuration Profile schema, also being used to include into Service Profiles, SMURF or SPDF.
902x05w0_06-SrvAgr_Template.xsd --> actual Service Profile template, not yet worked out, just a placeholder
Example-902x01b1TC1-SimpleSchedule_2021-11-24_10-10-31.xml --> example Simple Schedule out of GSOC actual schedule (has nothing to do with SACP!)
Example-902x05w0_06_DDOR_ConfigProfile_1.xsd --> example schema for DDOR Configuration Profile (same as what I send before, just updated to V0.06)
Example-902x05w0_06_DDOR-ConfigurationProfile.xml --> example XML Configuration Profile with DDOR (same as previously, please note it does not validate due to multiplicity of scan element)
Example-902x05w0_06_Mission_1_ConfigProfile.xsd --> example schema for typical TMTC config with Angles generation
Example-902x05w0_06_Simple_TMTC.xml --> example XML with configuration for specific Mission
I followed the suggestion of John, and updated apertureFR --> ApertureStratumFR (and so on for all), as well as changed functionalResourceData --> unregisteredFRParameters.
In the folder “SanaRegistry” there are additionally files exported by Holger out of FRM.
@holger.dreihahn at esa.int<mailto:holger.dreihahn at esa.int>: I altered the files you provided me lately, there are two things:
1. The “AbstractFrStrataParameterSets.xsd” includes now new “UnregisteredStratumParameters” element and type definition:
<xsd:element name="UnregisteredStratumParameters" type="UnregisteredStratumType" abstract="true"/>
Please add this to your “export”.
1. All of the element names (and consecutively substitution groups in individual FR Files) have changed the initial letter to capital (following suggestion of John). Example with Antenna is shown below:
AbstractFrStrataParameterSets.xsd: <xsd:element name="apertureStratumParameters" type="ApertureStratumType" abstract="true"/>
Antenna.xsd: <xsd:element name="AntennaElement" type="AntennaType" substitutionGroup="apertureStratumParameters"/>
AbstractFrStrataParameterSets.xsd: <xsd:element name="ApertureStratumParameters" type="ApertureStratumType" abstract="true"/>
Antenna.xsd: <xsd:element name="AntennaElement" type="AntennaType" substitutionGroup="ApertureStratumParameters"/>
Please change you export accordingly.
And yet, something completely different…. (no, not a dead parrot):
I still need to figure out, how I’m going to implement the “Wrapper Class”. Unfortunately I do not have any good examples from other things (Event Seq. or DDOR Pattern). In principle I would need to change the substitution group here:
<xsd:element name="configurationProfileData" type="ConfigurationProfileDataType" substitutionGroup="srvMgtData"/>
<xsd:element name="configurationProfileData" type="ConfigurationProfileDataType" substitutionGroup=" abstractConfigProfileWrapper"/>
But this actually breaks the structure of the Config Profile as such, meaning the actual Config Profile XSD (like the 902x05w0_06-ConfPrfl_Template.xsd) would need to have additional Class which would substitute srvMgtData and it would include the wrapper for the configurationProfileData. If this would be fine, and for the peace in the world, I can do that. But maybe someone has some good solution, example? Or is there a possibility to substitute two different groups out of one class? 😉.
Best regards and hopefully see you next year
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SMWG