"There are eight different verifiers each associated with *difference* states in command processing"
Missing the word, "of" between "instances" and "this" in "...Interlocks apply instead to any Commands that may follow instances this MetaCommand."
inability to describe sets of limits (alarms) and conversions (polynomials) and then select a set per parameter depending on mission phase (JWST)
JWST hold conversion and limits in a seperate file that are grouped. Certains "sets" can be used for different mission phases such as test, on-orbit and so on, or for any reason deemed appropriate. XTCE allows one to specify at MOST one of each of these per parameterType
MER supports a Union construct because their abstract data types live past decomm. ASIST also supports the same idea – that an abstract data type onboard the spacecraft MAY live past decomm. Although it is possible to let multiple parameters overlap, in a sense allowing for a Union in XTCE. The issue arises that validating software cannot differentiate this with a bug in a container specification. A union tag or element of some sort is needed.
Description Kevin Rice 2007-10-22 21:04:10 BST
Move Alarms outside of Type area. Alarms may change a lot and it may be easier
to have them set in the Parameter area, further alarms and calibrators, as well
as the time types reference Parameters directly which seems inconsistent with
them being in types.
C-S/CNES
Ludovic Faure
Description Kevin Rice 2007-10-22 21:11:43 BST
Message, IncludeCondition and BaseContainer do similar things and should be
unified
Comment 1 Kevin Rice 2007-10-22 21:21:03 BST
Message, IncludeCondition and BaseContainer do similar things and should be
unified
Description Kevin Rice 2008-03-04 22:57:09 GMT
Expand NameReference concept to allow specifying items in precise locations
such as TelemetryMetaData, CommandMetaData, etc...
Description Kevin Rice 2008-05-28 21:35:39 BST
CustomAlgorithm which appears in many places in the schema should be a
namereference to AlgorithmSet. To enforce the proper semantics the Ref should
"name" which algorithm type it referes to such as "InputAlgorithmRef" or
"InputOutputAlgorithmRef", etc...
Description Kevin Rice 2008-05-28 21:39:55 BST
RestrictionCriteria seems incorrect for commands. the value checked are
inserted to form the command, operators seem a little strange, maybe only '=='
makes sense, etc...
XTCE alarms are associated with data types and come in a default and context set form. A variety of alarm types are associated with each data type, some specific to it (such enum alarms). However this is too restrictive to meet the needs of many of organizations. Specifically the following is requested: allow set of alarms without a required context by data type. Original reporter is JPL.
A mask alarm applies to numerics and enums – although usage in floats is discouraged. It defines 16-states which map 1 to 1 with values (say 1-16), it's a 16-bit mask – each bit is either a care or don't care. If set to 1, it's a care bit. If the value associated with that bit appears, it is in alarm. If the mask bit is set to 0, it's a don't care bit – and the value associated with it will not trip an alarm. When used with enums it's almost like an enum alarm list,except the states can go "past" the range of values given in the enum list itself. For example, suppose an enum had the values of OPEN=1, SHUT=2. The mask could be 0xfffffffc - as one and two are allowed and valid. And any other value would be in alarm. Because there's only two enum values and each of these is green but any other value is read, it is hard to completely simulate this alarm with the enum alarm list. It's possible to use a condition perhaps in this one example but the current syntax requires the enum alarm list. Further transferring this information through to another party will be hard in that case. Reported by JPL.
Variables are local values created from bit/sub-bits specified in the entry list of container. They are similar to parameters but exist only within the scope of the container they are defined – they are of type integer. Reported by JPL.
Outside of the SpaceSystem and systemName, a general mechanism for categorizing @name elements into one or groups is needed. Reported by JPL.
A switch entry is similar to the switch/case statement provided in most programming languages, and would improve upon the include condition currently found in XTCE. Reported by JPL.
Added specific support for reed-solomon and turbo encoding, among others in the stream set. Reported by JPL.
Description Kevin Rice 2007-10-22 21:09:15 BST
CheckWindow has no way to vary window size based on context
Description Kevin Rice 2007-10-22 21:48:47 BST
Some organizations wish to capture counts to units on the telemetry side & then
units to counts on command side (often called reverse or inverse calibrators).
In some cases they may wish to both for various reasons, often in testing
scenarios to validate their operation calibration. XTCE does not provide an
easy way to mark a calibrator as either 'reverse' or 'forward'.
For some reason this idea flew into my funnel this morning. I was looking at the ComparisonList and noticed the annotation to it said there's an implied 'and' between all the comparisons in the list.
I then thought: Why not add an attribute to override that to set to it all ORs? Why would that be a bad thing?
Unable to come up with any reason that this would be a bad thing, I decided it must be a good thing and that a good thing should be an issue.
The main reason to support the OR case is that it's simply a little easier to build out the comparisonlist than the booleanexpression. And one assumes that if it's a good thing to have an ANDed ComparisonList for convenience, that it seems like symmetrically speaking it would be a good thing to have ORed ComparisonList for conveniences as well. Basically this is just a suggested small change for the convenience purposes.
FixedValueEntry has a hard coded hexBinary value that's supposed to be in "spacecraft order". There's a now optional name in 1.2.
ITOS and ASIST capture the same info slightly differently. The value is in human-readable form, (e.g "5331" or whatever it is that you can read and understand). But Bit/Byte order are provided as modifiers to the field/entry definition so that the software will do the right thing and encode it properly for the final destination on the spacecraft. ITOS/ASIST require the name and other associated the meta data for these fields.
So there's similarities overall between them but the encoding aspect is the key difference.
The upsides to their approach are (there may be more):
The downsides are (could be more):
Is there a case to be made to change, or modify the existing fixedvalueentry? What would the approach be?
1) maintain pure backwards compatibility: add a second variation "uservalueentry" that supplies it as described above and includes a local bit/byteorder
2) modify fixedavalueentry itself and keep a kind of conceptual compatibility...
What do you think?
Currently the FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm are allowed only for BinaryDataEncodingType with the comment "Used to convert binary data from an application data type to binary data". However the binary data encoding is used to encode/decode binary data, so not any application data (float, integer, time,...).
We believe it is more beneficial to allow these algorithms to all data encoding types.
For example a FromBinaryTransformAlgorithm attached to a IntegerDataEncoding can extract a varint like the ones used in protobuf (https://developers.google.com/protocol-buffers/docs/encoding#varints).
Similarly a ToBinaryTransformAlgorithm attached to a FloatDataEncoding can be used to encode a floating point number in an exotic format; for example bfloat16 is commonly used in AI chips (https://en.wikipedia.org/wiki/Bfloat16_floating-point_format)
This is more for discussion. our syntax is ok but when the schema types that control the syntax in parameter/argument type are manifest into classes, the result is less than ideal.
Firstly all our parametertype/argumenttypes have NameDescriptionType as the root. It might for example make sense to have as a root "DataType" or something of that nature – and maybe to then ScalarDataType and ComplexDataType which seems natural.
Secondly we now have split the parameter type and argument types because we had to support looking up parameters and arguments in the latter. And these appear deep in the syntax trees. More ideally we'd just bolt on those latter in the hierarchy so as to show more schema types.
Finally somehow array and aggregate didn't get the message – and the time types have their own data encoding syntax.
The result is this:
BaseDataType – all the scalars on the parameter type side have this as a parent.
XXXDataType – next up the various scalars have this interim schema type. This is a vestige from 1.1. So for example IntegerDataType.
BaseTimeDataType – absolute and relative use this though.
ArrayDataTypeType and AggregateDataType – array and aggregate follow this line
Then on the argument side, this is mirrored but with "argument" stuck in front of it all:
ArgumentBaseDataType, ArgumentBaseTimeDataType – oddly Array and Aggregate on this side have ArrayDataTypeType and AggregateDataType as parents.
In the end we up with lots of "root" schema types that are all children of NameDescriptionType – BaseDataType, BaseTimeDataType, ArgumentBaseDataType, ArgumentTimeBaseDataType, ArrayDataTypeType and AggregateDataType.
There's no DataType, ScalarDataType or ComplexDataType which might more natural organize it.
Conclusion: this could all be better.
Dynamic lookup is sprinkled about the text to (only?) retrieve a numeric value but perhaps there should be an integer and float form. For example in calculating a dynamic array index, would it make sense if the referred to parameter is a float? we can agree any non-numeric is a error. If it's a float or integer, the slope and intercept are doubles – suggesting a double result. Well that may produce a fractional value of an array index – that doesn't make sense. one can round or chop as one sees fits but that's not documented. in this case integer only dynamic value would make more sense – the slope and intercept would be int/long and it would be in error to ref anything but an integer parameter type. other cases may allow for either data type. [edit] Discrete lookup DOES NOT have the same issue – it's value is a float. It however does need a default. I made an issue for that.
XUSP 1.2 changed the base type of CalibratorType from OptionalNameDescriptionType to the new BaseCalibratorType. This change eliminated the previous support for <LongDescription> and <AliasSet>. These elements are supported in the XUSP 1.0 profile and are used in existing databases.
"The issue is declared Closed.
The problem has not been fixed. It is still impossible to reference an argument in a CommandContainerSet/CommandContainer/RefEntry."
Much of the annotation is gone in InputAlgorithmType in 1.2 in its major elements. These were turned into schema types for 1.2, and somehow the annotation was not copied over from 1.1.
Draft version of XTCE v1.2 defined dataSource attribute as:
<attribute name="dataSource" type="xtce:TelemetryDataSourceType" default="telemetered">
Published version is v1.1:
<attribute name="dataSource" type="xtce:TelemetryDataSourceType" use="optional">
The IndirectParameterRefEntry is a clever construct that has the potential to be useful, although I am not aware of anyone who has used it.
I suggest that we consider removing it because it is a limited case of the more general case solved by the IncludeCondition element. The IncludeCondition can provide this functionality and a lot more. As a result, this element is effort for implementers that doesn't add anything really "new". In addition, it leaves a case where the need is addressed in more than 1 way - which is generally not the best idea.
Even message support is need in XTCE. Adding an EventSet to TelemetryMetaData would be an appropriate location.
After jaxb runs on the current XTCE 1.2 (after ballot 28) schema. The following methods show weaknesses in the schema type hierarchy (below). It's been shown they schema types can be meaningfully tweaked and these items will map cleanly. It also suggest but is not clear the order of the items in some the lists may not be enforced. for two of the items below this would be bad. this is conjecture however.
>> ArgumentInputSetType.java: public List<Object> getInputParameterInstanceRefOrInputArgumentInstanceRef() {
>> InputSetType.java: public List<Object> getInputParameterInstanceRefOrConstant() {
>> ParameterSetType.java: public List<Object> getParameterOrParameterRef() {
>>
>> ArgumentComparisonCheckType.java: public List<JAXBElement<?>> getRest() {
>> ComparisonCheckType.java: public List<JAXBElement<?>> getRest() {
>> MathOperationCalibratorType.java: public List<JAXBElement<?>> getValueOperandOrThisParameterOperandOrOperator() {
>> MetaCommandSetType.java: public List<JAXBElement<?>> getMetaCommandOrMetaCommandRefOrBlockMetaCommand() {
>>
Description Kevin Rice 2007-10-22 21:37:38 BST
AbsoluteTimeParameterType do not have alarm elements associated with it. In
the current schema this may be by design – an example of a usage for an
alarming absolute time could be helpful. JWST claims to alarm on occurrences
of reverse time which in fact would probably be a packet ordering issue.
Allow for local argument types to be defined in MetaCommand, helps avoid collisions with arguments in other commands of the same name but different properties.