[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