Datapoint and Property Types

IAP Types provide the machine-readable description of datapoint types, property types and profiles.

For example, one simple data type for use with a datapoint could be described as an unsigned integer value with a range from 0 to 100, in steps of 0.01, and a unit of “%”.  Another data type could be more specific to a physical entity, perhaps described as a signed integer, a temperature value with a range from -273.15 to 7000 Kelvin, in steps of 0.01.

Other datapoint types include different numeric types and aggregates such as structures and union types, all with a number of aspects, such as minimums, maximums, or resolution, and units and descriptions for human consumption.

Types for use with properties typically carry semantics along with the value range, resolution, and units. For example, one property type might be described as the pasteurization temperature for milk in cheese making, another property might be described as the light color temperature of a light bulb. Both temperature properties could be based on the same -273.15 to 7000 K temperature datapoint, but the added semantics define what their value means.

Property types support all types that can be used with datapoints, but properties may also be implemented as property arrays. For example, one property type may use the temperature datapoint to provide one linearization point for a PT-100 temperature sensor, while a property array of several of these items describe the complete linearization curve.

Profiles

A profile is a combination of datapoints and properties to serve one shared purpose.  For example, a simple temperature sensor profile could include a single temperature datapoint, whose value provides the current sensor output. Another profile could require the implementation of three temperature datapoints for setpoint and process value inputs, and control value outputs of a temperature controller, alongside a number of mandatory and optional properties for the controller coefficients and so on.

Profiles typically allow for degrees of freedom in the implementation. A block implementing a profile can often choose which optional member to implement, but must always implement all mandatory datapoint or property members.

Datapoint and property members defined in a profile may allow for implementation-specific detail, such as an implementation-specific default value. Details of the implementation of profiles in blocks and their datapoint and property members are discussed in Interface Blocks.

Enumerations

Enumerations are lists of literals, where each literal has a corresponding numeric value. With IAP types, enumerations cannot be used directly, but datapoint or property types can implement or include enumerations.  Enumerations in IAP always map to signed integer values.

Applications

Applications can be described in a similar fashion to profiles and data types, supporting the declaration of application-specific alarm conditions and similar information.

Application-specific meta data is reported in res/application using the rules outlined in Data Type Definitions.

Type Names and Sets

IAP objects reference type definitions by name using a two-part name separated with a forward slash:   8000011E00000000−4/UFPTluxSensor

Type names can be any name made of characters a-z, A-Z, 0-9, hyphen, period, and underscore. The type name must be unique within the set that contains its definition.The first part of the name defines the set of definitions which contains the type, the second part references the type within that set by name.

Some type systems follow a convention to prefix user-defined and standard profile names with UFPT and SFPT, user-defined and standard datapoint types with UNVT_ and SNVT_, and user-defined and standard property types with UCPT and SCPT.  IAP types support, but do not require this convention. 

The set name is made from the same alphabet as the type name. The set name must be unique within the IAP segment, and is typically allocated by agreement between the different edge protocol processors that reside on that segment.

For example, a LonTalk protocol processor would follow a type system and set naming convention that is well-established within tools and users of this protocol, perhaps defining a datapoint type as:  9000010100000000−4/UNVT_channel_index.

Another protocol may draw on similar analogies to existing type systems, or may simply report a flat type system, choosing the edge protocol name for the set name:   cm/light−level

Type References

IAP objects reference their type definition with a type property, which includes the set name and type name, separated by a slash.

For example, a light controller interface block within a Control-M device could report its block to be based on profile
cm/top900−light or cm.top900/profile−light.

This can be used to reference the type definition.