Print

Print


At a prior PDG session, Bjoern, showed a mistaken interpretation of Required attribute where required meant present in every update call.  He asked why would anyone would think this? I believe it is likely they are using the common interpretation of update not the HLA one.  If that is the case, then saying they should have used the HLA definition won’t help.  If a new definition doesn’t help then perhaps

 

Optional:  An attribute for which no calls to the Update Attribute Service need to be made. Other federates must be able to react to the object instance appropriately without receiving a value for that attribute.

 

Required:  An attribute for which at least one call to the Update Attribute Service must be made for  each instance  of the attribute’s Object Class. Typically, the call to the Update Attribute Service is made right after the object instance is registered. Other federates do not have to react to the object instance until all of its required attributes have been received.

 

From: SAC-PDG-RPR: Roger Jansen [mailto:[log in to unmask]]
Sent: Friday, March 22, 2013 9:50 AM
Subject: RE: GRIM clarification - when to update required fields ofBaseEntity

 

From: "Roger Jansen" ([log in to unmask])

*** This message was generated from SAC-PDG-RPR ***

I don't think that introducing a new term makes things clearer. We are talking about HLA and thus about the Update as meant in the HLA context.

I think that the text "must be updated, at a minimum according to its update type" is confusing, because it can be interpreted as "may be updated at a very high rate, regardless wheter the value has been changed or not". The common way within HLA is that attributes are only updated when the value has been changed, and in case of the RPR spatial attribute it should only be updated when needed according to the deadreckoning rules. So the text "must be updated, at a minimum according to its update type" means imo "must be updated, according to its update type or when requested". If a federation needs to use a higher update rate, it should be an additional federation agreement.

Roger


From: SAC-PDG-RPR: Andy Ceranowicz [[log in to unmask]]
Sent: 21 March 2013 22:08
Subject: RE: GRIM clarification - when to update required fields ofBaseEntity

From: "Andy Ceranowicz" ([log in to unmask])

*** This message was generated from SAC-PDG-RPR ***

In my opinion, some of the confusion of interpreting what an required vs optional updating means is due to the uncommon use of “update” in HLA terminology.  In common  speech  update means a change to something that has already been issued.  In HLA terminology it means to invoke the Update Attribute Values service for one or more instance attributes which is done to both send out the first issue and to subsequently update it.  I frequently want to use “publish’ for an attribute instance value to express the first issue but in HLA publish only refers to the class attribute.   I find the wording suggested precise, but hard to interpret.   The following is  my attempt at something more straightforward based on defining a use of the term “provide”. If that is too close to the HLA term, then perhaps “issued” could be used, but “provided” sounded better.

 

An attribute for an object instance is provided to a federation by calling the Update Attribute Values service for that attribute with a value  at least once during the object’s lifetime.

 

Optional attribute.

An attribute that does not need to be provided to the federation.

 

Required attribute.

An attribute that must be provided to the federation for each instance  of the attribute’s Object Class. Typically, the attribute is provided right after the object instance is registered.

 

 

From: SAC-PDG-RPR: Aaron Dubois [mailto:[log in to unmask]]
Sent: Thursday, March 21, 2013 3:13 PM
Subject: Re: GRIM clarification - when to update required fields of BaseEntity

 

From: "Aaron Dubois" ([log in to unmask])

*** This message was generated from SAC-PDG-RPR ***

At today's meeting we discussed the need to define the terms "required attribute" and "optional attribute" to make them less ambiguous. We also discussed clarifying when updates should be provided at a higher level, in one of the general sections, since this really affects all object classes, not just BaseEntity. Below is some proposed text. I propose adding the following two new terms to the Definitions section as well as a new section, 7.2, that discusses update types. Please let me know if you have any feedback.

 

optional attribute

An object attribute that may or may not be updated by a publishing federate for a particular object instance, based on the federation agreement.

 

required attribute

An object attribute that must be updated, at a minimum according to its update type, by publishing federates for all object instances.

 

 

7.2 Attribute Update Types

HLA provides a means for specifying the update type of each object attribute. The update type indicates when an update of the attribute is expected to be provided by the publishing federate. For some update types an additional update condition is specified to further identify specific conditions that should result in an update. The RPR FOM specifies an update type for all attributes and an update condition where appropriate. Publishing federates shall update all required attributes and all provided optional attributes at a minimum as specified by the update type and update condition. Publishing federates may provide updates more frequently, but this is not necessary.

 

 

Aaron

To reply: [log in to unmask]
To start a new topic: [log in to unmask]
To view discussion: http://discussions.sisostds.org/threadview.aspx?fid%9&threadidS235#83191

To (un)subscribe: Send a message to [log in to unmask] with the word unsubscribe in the message body.
Important: the unsubscribe email needs to be in plain text format, and needs to have no subject line.

SISO: http://www.sisostds.org/

 

To reply: [log in to unmask]
To start a new topic: [log in to unmask]
To view discussion: http://discussions.sisostds.org/threadview.aspx?fid%9&threadidS235#83194

To (un)subscribe: Send a message to [log in to unmask] with the word unsubscribe in the message body.
Important: the unsubscribe email needs to be in plain text format, and needs to have no subject line.

SISO: http://www.sisostds.org/

 

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

To reply: [log in to unmask]
To start a new topic: [log in to unmask]
To view discussion: http://discussions.sisostds.org/threadview.aspx?fid%9&threadidS235#83203

To (un)subscribe: Send a message to [log in to unmask] with the word unsubscribe in the message body.
Important: the unsubscribe email needs to be in plain text format, and needs to have no subject line.

SISO: http://www.sisostds.org/

 



To unsubscribe from the SAC-PDG-RPR list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-RPR