Modeling: Why do I have Thing Shapes and Thing Templates?
Because of the object oriented nature of the ThingWorx model, you can define reusable "components" and then use those components to define the Things in the model. Changes to the reusable components are automatically reflected in the Things that are defined by those components. The idea is to define behaviors in one place only, and have all inherited objects behave per the current definition of the parent objects. This way, you do not need to make the same changes to many Things when an update is required.
Thing Shapes and Thing Templates were implemented to make the inheritance model simple to maintain. Thing Shapes are the base definition components. When a Thing or Thing Template is to share the definition of a Thing Shape, the Thing or Thing Template is said to "implement" the Thing Shape. Generally, Thing Shapes should have unique behaviors, meaning they execute a unique set of services and capabilities. A Thing Template can implement more than one Thing Shape. It is recommended that a Thing be defined by using a Thing Template.
Let's walk through a simple example. A site has several different types of equipment. Each piece of equipment performs a very different function for the site. For simplicity, let's assume three types of equipment:
• Transformer
• Mixer
• Air Handler
The site may have five transformers, twenty air handlers, and twelve mixers. Each of these three types of equipment is very different. But there may also be some commonalities. Let's assume that each piece of equipment is tracked by the company ERP system, and therefore have common data (Thing properties). Let's also assume that the air handlers and transformers need to update the maintenance management system on specific metrics used for Condition Based Maintenance (CBM).
When analyzing this physical model and deciding how to translate it into a ThingWorx Model, there are three distinct groupings of behavior to consider:
1. ERP Asset behavior
2. Condition Based Maintenance behavior
3. Equipment type specific behavior
In this example, you would want to define at least two Thing Shapes to take advantage of how the ThingWorx model works. They are as follows:
1. ERP_Asset Thing Shape - because each piece of equipment in the site has this in common. That way any change to the ERP_Asset Thing Shape would automatically be reflected in each piece of equipment at the site.
2. CBM_Asset - because more than one asset type needs this capability, define it as a Thing Shape and any changes will be inherited by implementing Things. If the maintenance of the mixers moves to a CBM model in the future, you can have the mixers implement this Thing Shape through the mixer Thing Template (discussed below) and not have to update all your mixers.
Now, you can create three Thing Templates, one for each of the equipment types. Thing Templates were designed to make it easy to create and maintain Things of a specific definition. Using the three equipment type Thing Templates for this example allows you to create a Thing that represents a specific asset by just using the Thing Template and giving the Thing a unique name.
Transformer Thing Template
The transformer Thing Template would be defined by implementing the ERP_Asset and CMB_Asset Thing Shapes. All the specific properties, services, events, and subscriptions of the transformers should also be defined within the transformer Thing Template. Then, for each transformer, use the transformer Thing Template and a unique name to define the transformer in the ThingWorx model.
Alternatively, you could have also defined a transformer Thing Shape. In that case, your transformer Thing Template would implement three Thing Shapes, the ERP_Asset, CMB_Asset, and transformer Thing Shapes. This approach works fine, but is not necessary if other Thing Templates will not implement the transformer Thing Shape.
Mixer Thing Template
The mixer Thing Template would be defined by implementing the ERP_Asset Thing Shape. The mixers do not use the CBM maintenance model, so the related Thing Shape is not needed. All the specific properties, services, events, and subscriptions of the mixers should also be defined within the mixer Thing Template. Then, for each mixer, use the mixer Thing Template and a unique name to define the mixer in the ThingWorx model.
AirHandler Thing Template
The AirHandler Thing Template is similar to the transformer Thing Template. It should implement both the ERP_Asset and CMB_Asset Thing Shapes. All the specific properties, services, events, and subscriptions of the air handlers should also be defined within the AirHandler Thing Template. Then, for each air handler, use the AirHandler Thing Template and a unique name to define the air handler in the ThingWorx model.
Now that all the assets have been defined, you have a very maintainable model. If any changes are required to the ERP_Asset, it can be done in a single place and tested. Once deployed, each piece of equipment on the site would automatically inherit the new functionality.