Community Tip - You can change your system assigned username to something more personal in your community settings. X
The first step in the design process is to use the Thing-Component Matrix to identify and prioritize groups of Components that are shared across multiple Things. These groups will be prioritized by number of shared Components, from highest to lowest, enabling is to break out the most commonly used groups of Components and package them into reusable pieces.
Let’s examine our example Thing-Component Matrix to identify and prioritize groups.
In the table below, we have done this and recognized that there are FOUR groups.
NOTE: Each item in our unique Thing-Component Matrix would also count as a group on its own. This can be dealt with almost separately from our process, though, because there is no overlap between different Things. The "Templates for Unique Components" and "Adding Components Directly to Things" sections in the Iterate step of this guide covers these "one-offs."
The base building block we use most often is the Thing Template. To start the design process, the first step is to create a Thing Template for the largest Component group. Applying this to our Smart Factory scenario, we'll take the largest group ("Group 1") and turn it into a Thing Template using the Entity Relationship Diagram schematic.
Since every item on our production line shares these Components, we will name this Thing Template Line Asset.
Now, let's build this using our Entity Relationship Diagram.
The result is a ThingWorx Thing Template with five Properties, one Event, and one Subscription.
Once an initial base template has been created for the largest group, the rest of the groups can be added by selecting the appropriate entity type (Thing Template, Thing Shape, or directly-instantiated Thing).
The following Entity Decision Flowchart explains which entity type is used in which scenario:
Now that we have established our "Line Asset" Thing Template for our largest group, the next step is to iterate through each of our remaining groups. Following the flowchart, we will identify what entity type it should be and add it to our design.
The second group represents connectors into both of our internal business systems. We will call them System Connectors.
If we look at Group 2 versus our "Largest Group" Thing Template, we can see that there is no overlap between their Components. This represents the third branch of the Entity Decision Flowchart, which means we want to create a new Thing Template.
Following this rule, here is the resulting template:
The third group represents line assets that require emergency shutdown capabilities because under certain conditions, the machinery can become dangerous.
We will call these Hazardous Assets.
If we look at our two previous Thing Templates, we can see that there is full overlap of these Components with our previous largest group, the "Line Asset" Thing Template.
This represents the fourth branch of the Entity Decision Flowchart, which means we want to create a CHILD Thing Template.
Following this rule, here is the resulting Thing Template:
The fourth group represents line assets that keep track of inventory count, to ensure the number of assembled-products is equal to the number of checked-products for quality.
If we look at our existing Thing Templates, we can see that there is some overlap of the Components in our "Hazardous Asset" and "Line Asset" Thing Templates.
This represents the second branch of the Entity Decision Flowchart, which means we want to create a Thing Shape.
Following this rule, here is the resulting Thing Shape:
Now that we have handled all our shared component groups, we also want to look at the unique component groups. Since we have already established that each group in our Unique Thing-Component Matrix does not share its Components with other Things, we can create Child Thing Templates for these line assets.
NOTE: Refer to the finished design at the bottom to reference all of the inherited Thing Templates and Thing Shapes for these Child Thing Templates.
In many cases, we will have Components that only exist for a single Thing. This frequently occurs when there will be only one of something in a system. In our case, we will only need one "System Connector" for each of the Maintenance System and the Production Order System.
At this point, the Data Model is fully built. All we need to do now is instantiate the actual Things which represent our real-world machines and digital-connections.
The final step of the model breakdown design process is validation through instantiation.
This is the process by which we take our designed Thing Templates / Thing Shapes / Things and actually create them on the ThingWorx platform to ensure they meet all of our requirements.
This is done by tracing back through the chain of inheritance for all the Things in the data model to ensure they contain all of the required Components from the Thing-Component Matrix.
Once we have verified that each Thing contains all of its requirements, the data model is complete.
Using this technique on each of your Things, you can explicitly prove that all of the requirements have been met.
Congratulations!
You've successfully completed the Design Your Data Model Guide covering the first three steps of the proposed data model design strategy for ThingWorx.
This guide has given you the basic tools to:
The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Data Model Implementation.