ThingModel is one kind of Model (the other kinds are DataModels and AppModels). Therefore it has all the properties of Models (Lifecycle of models, Model Attributes, Unique and Constraints).
A ThingModel has
- a name,
- any number of Model Attributes
- and usually one or more Actions
However, as a recommended practice, the Attributes and Actions related to the interactions with an external thing (sensors, actuators, machines) are often defined in a reusable structure called ThingFacet, and combined into a ThingModel. This relationship was explained in the concept of Models and Model Facets. Application related information are often defined directly as attributes of the ThingModel.
In the following example, the ThingModel PhidgetServoModel combines the ThingFacet PhidgetServoFacet, where:
- PhidgetServoFacet contains the device interaction specific Attributes (e.g. ServoProtocolURL) and Actions (e.g. PhidgetServoAction);
- PhidgetServoModel contains application related Attributes: PhidServoId and InstalledAtZone (assuming the Phidget servo motor is installed in a particular zone within a Greenhouse environment, which has multiple zones).
- Combines is used as a modifier of ThingModel
In the simplest case, a ThingModel may only have one single directly defined attribute of type Sid. Although not required, it is best practice to always create a ThingModel with one attribute that is of type SystemId or Sid.
<ThingModel Name="PhidgetServoModel" Combines="PhidgetServoFacet"> <Sid Name="PhidServoId"/> <String Name="InstalledAtZone"/> </ThingModel> <ThingFacet Name="PhidgetServoFacet"> <String Name="ServoProtocolURL" Default="phid://"/> <String Name="DeviceInterfaceIndex"/> <String Name="PhidgetDeviceType"/> <Integer Name="ServoAngle" KnownBy="PhidgetServoAction"/> <Action Name="PhidgetServoAction" Documentation="Control servo motor"> ... </Action> </ThingFacet>
This pattern allows the ThingFacet to be a reusable artifact, and potentially combined by multiple ThingModels.
Note: One can combine multiple ThingFacets within a single ThingModel using comma separated list of ThingFacets.
For Example Esky ThingModel combining EskyPreset and EskyImage Thing Facets
<ThingFacet name="EskyPreset">
<String name="State" KnownBy="SyncPreset"/>
<String name="Preset" KnownBy="SyncPreset"/>
<Action name="SyncPreset" documentation="Synchronize camera state and preset">
<Workflow Limit="1" Live="1" Timeout="PT20S">
<Task name="Main" while="true">
<Event name="Argument" as="ActionArgument"/>
...
</Task>
</Workflow>
</Action>
</ThingFacet>
<ThingFacet name="EskyImage" combines="Login">
<String name="State" KnownBy="SyncImage"/>
<Clob name="Image" KnownBy="SyncImage"/>
<!-- Actions -->
<Action name="SyncImage" documentation="Synchronize camera state and snapshot image">
<Workflow Limit="1" Live="1" Timeout="PT10S">
<Task name="Main" while="true">
<Event name="Argument" as="ActionArgument"/>
...
</Task>
</Workflow>
</Action>
</ThingFacet>
<ThingModel name="Esky" combines="EskyPreset,EskyImage" documentation="actual single instance camera model">
<Sid name="CameraId"/>
</ThingModel>
In summary
- ThingModels are normally used to represent and define interactions with external physical things. The specifics of interactions are often modeled via ThingFacet.
- ThingModels combine one or more ThingFacets. ThingFacets are reusable artifacts. In runtime, only instances of ThingModels are created and persisted (not ThingFacets).
- ThingModels can contain application related information that are related to things.
When ThingModels do not combine any ThingFacet they are equivalent to DataModel i.e pure Attributes only.
ThingModel can be created, read, update and deleted using TQL queries.