Package org.hlacerti.lib

Class HlaAttributeUpdater

  • All Implemented Interfaces:
    java.lang.Cloneable, HlaUpdatable, Actor, Executable, FiringsRecordable, Initializable, TypedActor, Changeable, Debuggable, DebugListener, Derivable, Instantiable, ModelErrorHandler, MoMLExportable, Moveable, Nameable
    public class HlaAttributeUpdater
extends TypedAtomicActor
implements HlaUpdatable
    This actor is a kind-of output port that sends the data on its input to the HLA federation through the RTI (Run Time Infrastructure). In HLA, the terminology is that this actor "updates" the specified attribute value of the specified instance whenever there is a data on its input. This attribute value will be "reflected" by all federates that have "subscribed" to this attribute. The time stamp of this update depends on the time management parameters of the HlaManager, as explained in the documentation for that class. This actor assumes that there is exactly one HlaManager in the model that contains this actor.

    The attribute of an instance that this actor updates is specified using three parameters: attributeName, className, and instanceName. The updates will be reflected, for example, by an HlaAttributeReflector whose three parameters match those of this actor. The className and attributeName are required to match a class and attribute specified in the FED file that is specified in the HlaManager. The instanceName is an arbitrary name chosen by the designer for the instance of the class. It specifies the instance of the specified class whose attribute this actor updates.

    If the specified class does not have an attribute with the specified attributeName, as defined in the FED file, or there is no class matching className in the FED file, then an exception will be thrown. An exception is also thrown if the attribute name or the class name or the instance name is empty.

    If a federate intends to update N attributes of an instance, then it must contain N HlaAttributeUpdater actors with the same instanceName and same className. A federate can update attributes of M different instances of a same class. In this case, the federate must contain M HlaAttributeUpdater actors for each attribute. During initialization, the HlaManager will notify the RTI of this intention in two steps:

    - it "publishes" a list with all attributes of class by gathering the parameter attributeName of all HlaAttributeReflectable actors having the same className,

    it "registers" each different instanceName of a class className.

    The data type of the input port of this actor must have the same type of the attribute value this actor updates (as defined in the FOM). The data type is used to define the bytes that are transported via the HLA RTI. Currently, only a small set of primitive data types are supported.

    The useCertiMessageBuffer parameter works together with the data type to interpret the bits that are transported over the RTI. Specifically, an HLA RTI will transport arbitrary byte sequences regardless of what they represent. CERTI, the particular RTI that Ptolemy II uses, provides a convenience feature that packs and unpacks the message bytes for a small set of data types. This feature takes into account the annoyance that the byte order can be different on different platforms (big endian or little endian). If the attribute that this actor is updating is reflected by a "foreign" federate (not implemented in Ptolemy II), then this useCertiMessageBuffer parameter should be set to true to ensure that byte order changes are handled. And in this case, only the small set of data types supported by CERTI can be used. On the other hand, if the attribute is reflected by a Ptolemy II model, and the corresponding HlaAttributeReflector does not not specify to use the CERTI message buffer, then this parameter should be false. See also MessageProcessing class.

    FIXME: took from publisher actor description. Keep it or not? In a federation implemented only with Ptolemy II federates, an HlaAttributeUpdater is linked to a unique HlaAttributeReflector. Any data dependencies that the director might assume on a regular "wired" connection will also be assumed across HlaAttributeUpdater-HlaAttributeReflector pairs. Similarly, the type of the HlaAttributeReflector output must match the type of the HlaAttributeUpdater input.

    Since:
    Ptolemy II 11.0
    Version:
    $Id: HlaAttributeUpdater.java 214 2018-04-01 13:32:02Z j.cardoso $
    Author:
    Gilles Lasnier, Contributors: Patricia Derler, David Come
    Pt.AcceptedRating:
    Red (glasnier)
    Pt.ProposedRating:
    Yellow (glasnier)

    • Field Detail

      • attributeName

        public StringParameter attributeName
        The name of the attribute this actor updates. This defaults to an empty string, but it must be non-empty to run the model.

      • className

        public StringParameter className
        The name of the class whose attribute this actor updates. This defaults to an empty string, but it must be non-empty to run the model.

      • instanceName

        public StringParameter instanceName
        The name of the instance of the class to whose attribute this actor updates. This defaults to an empty string, but it must be non-empty to run the model.

      • input

        public TypedIOPort input
        The input port providing the new value that will update the specified attribute of the specified instance. The type of the input port corresponds to the type of the attribute (that would be defined in the FOM, but is not described in the FED file). This type must be the same as attributeType in HlaAttributeReflector.

      • useCertiMessageBuffer

        public Parameter useCertiMessageBuffer
        Indicate whether the attribute value is conveyed through a CERTI message buffer. This is a boolean that defaults to false. It should be set to true if the attribute to which this actor listens is updated by a foreign simulator. It can be false if the attribute is reflected by a federate implemented in Ptolemy II, and if this corresponding parameter in the actor doing the reflecting is also false.