Issue 10177: 9 - Add filtering of value threshold to maintain telemetry at certain rates (xtce-rtf) Source: NASA (Mr. Kevin Rice, james.k.rice-1(at)nasa.gov) Nature: Uncategorized Issue Severity: Summary: 9 - Add filtering of value threshold to maintain telemetry at certain rates (ESA-048) Defer (additional discussion, future work area) Resolution: Revised Text: Actions taken: September 1, 2006: received issue Discussion: Resolution: This idea is good, but the clarifications came too late for an implementation. Defer to future release. Revised Text: Disposition: Deferred End of Annotations:===== s is issue # 10177 9 - Add filtering of value threshold to maintain telemetry at certain rates 9 - Add filtering of value threshold to maintain telemetry at certain rates (ESA-048) From: "Kizzort, Brad" To: "Overeem, David T" , "Rice, James K. {Kevin}(GSFC-581.0)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS]" , Rob Andzik CC: "xtce-rtf@omg.org" Subject: RE: Poll 3 for XTCE issue resolutions Thread-Topic: Poll 3 for XTCE issue resolutions Thread-Index: AQHM1VExWBUbaaumt0+lFLRWobhNmpYRTk4A///L9DCAAAjwEIABDHaggAAgrRCAADJo0A== Date: Wed, 18 Jan 2012 19:33:17 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q0IJXTPv024931 I did not make it explicit in the two annotations, but the changeThreshold is a non-negative integer in the IntegerDataEncodingType and a decimal number in the FloatDataEncodingType. There is no changeThreshold attribute for StringDataEncodingType or BinaryDataEncodingType, so I had hoped it was clear that it applied to the raw value (the encoded data type) rather than the engineering unit value (xxxxParameterType) Brad K. -----Original Message----- From: Overeem, David T [mailto:david.t.overeem@boeing.com] Sent: Wednesday, January 18, 2012 11:40 AM To: Kizzort, Brad; Rice, James K. {Kevin}(GSFC-581.0)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS]; Rob Andzik Cc: xtce-rtf@omg.org Subject: RE: Poll 3 for XTCE issue resolutions Okay. I think I see the thought behind this. I looked back at the poll to verify, but I do not see how the implementation indicates whether the threshold is acting on the raw or engineering value. Was that the intended purpose? As an aside - we should also find some time to talk about the latest issue from Harris on the Aggregates. Dave -----Original Message----- From: Kizzort, Brad [mailto:bkizzort@harris.com] Sent: Wednesday, January 18, 2012 7:33 AM To: Overeem, David T; Rice, James K. {Kevin}(GSFC-581.0)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS]; Rob Andzik Cc: xtce-rtf@omg.org Subject: RE: Poll 3 for XTCE issue resolutions I chose the xxxxDataEncodingType for the changeThreshold (aperture) attribute from the implementer's perspective. In that structure, the software has all of the relevant information about the data type, including the size, signed/unsigned, etc. Putting it on the parameter would have required tracing back to the DataEncodingType information to determine how to apply the threshold. -----Original Message----- From: Overeem, David T [mailto:david.t.overeem@boeing.com] Sent: Tuesday, January 17, 2012 5:26 PM To: Kizzort, Brad; Rice, James K. {Kevin}(GSFC-581.0)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS]; Rob Andzik Cc: xtce-rtf@omg.org Subject: RE: Poll 3 for XTCE issue resolutions Any thoughts on my original suggestion from the poll? --- Issue 24/10177 - Would like some elaboration on why it was chosen to include this attribute on the encoding side of the parameter. Since this is a ground artifact and behavior, would it be better to place it as an attribute at /// instead? --- Dave -----Original Message----- From: Kizzort, Brad [mailto:bkizzort@harris.com] Sent: Tuesday, January 17, 2012 2:57 PM To: Rice, James K. {Kevin}(GSFC-581.0)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS]; Rob Andzik Cc: xtce-rtf@omg.org Subject: RE: Poll 3 for XTCE issue resolutions I have never seen an application for aperture on the command side, e.g. don't send a command because the parameter change was not different enough from the previous value, but I guess it is possible. Brad -----Original Message----- From: Rice, James K. {Kevin}(GSFC-581.0)[ASRC RESEARCH & TECHNOLOGY SOLUTIONS] [mailto:james.k.rice-1@nasa.gov] Sent: Tuesday, January 17, 2012 3:00 PM To: Rob Andzik; Kizzort, Brad Cc: xtce-rtf@omg.org Subject: RE: Poll 3 for XTCE issue resolutions Question, not a vote: Does aperture have any meaning on the command side? On the telemetry side, the DataEncoding is the "source data type" ... on the command side it would be interpreted as the "destination data type". If it has no meaning on the command, I think you should include further splitting the underlying schema types so that the attribute appears only on the telemetry meta data side. Otherwise its yet another bit of confusion for implementers. ________________________________________ From: Rob Andzik [andzik@amergint.com] Sent: Tuesday, January 17, 2012 2:49 PM To: Kizzort, Brad Cc: xtce-rtf@omg.org Subject: Re: Poll 3 for XTCE issue resolutions We vote yes on Poll 3. -- Rob On Fri, Nov 11, 2011 at 1:29 PM, Kizzort, Brad > wrote: Time for the next poll. Since there is no way we will get through the remaining 75 or so issues before 11/14, I will continue to set the poll closing two weeks out, i.e. poll 3 closes 11/25/2012, so that you have decent review time. There are 25 issues in poll 3. All but 2 are recommended to be closed with no change, some are no longer issues, some are deemed out of scope for XTCE. There are two issues that are recommended to be resolved: 1. Add an optional attribute for telemetry filtering of insignificant changes, sometimes referred to as an aperture. It is recommended to be an optional attribute on the DataEncodingType for upward compatibility of existing XTCE documents. 2. Update references to the XTCE schema and namespace to be consistent with OMG policy and reflect the 1.2 version. I am projecting a February 2012 stability date for the XTCE namespace. I have attached a zipped version of the specification with the optional attribute from poll 1 and the recommended additional attributes in this poll, along with the poll 3 recommendations. Note that this is NOT A COMPLETE recommended v 1.2 schema, as it only has the changes from the first two polls and the recommendation from this poll for testing/viewing purposes. There are still many more issues to disposition and Kevin's annotations recommended changes from the CCSDS list that need to be reflected in the schema. Please respond with an email to the xtce-rtf@omg.org with a: Yes, I agree with the recommended dispositions, or No, I do not agree with the recommended dispositions and here are my recommendations for issue X. Thanks, Brad Defer (additional discussion, future work area)