cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can change your system assigned username to something more personal in your community settings. X

Design Your Data Model Guide Part 3

No ratings

 

Design Your Data Model Guide Part 3

 

Step 7: Prioritize

 

IoTProductMgmt_0-1659124094195.png

 

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.

IoTProductMgmt_1-1659124094201.png

 

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."

 

 

Step 8: Largest Group

 

IoTProductMgmt_2-1659124094202.png

 

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.

IoTProductMgmt_3-1659124094206.png

 

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.

IoTProductMgmt_4-1659124094206.png

 

The result is a ThingWorx Thing Template with five Properties, one Event, and one Subscription.

 

 

Step 9: Iterate

 

IoTProductMgmt_5-1659124094207.png

 

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:

IoTProductMgmt_6-1659124094209.png

 

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.

 

Group 2 - "System Connector"

 

The second group represents connectors into both of our internal business systems. We will call them System Connectors.

IoTProductMgmt_7-1659124094212.png

 

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.

IoTProductMgmt_8-1659124094216.jpeg

 

Following this rule, here is the resulting template:

IoTProductMgmt_9-1659124094216.png

 

Group 3 - "Hazardous Asset"

 

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.

IoTProductMgmt_10-1659124094218.png

 

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.

IoTProductMgmt_11-1659124094220.png

 

Following this rule, here is the resulting Thing Template:

IoTProductMgmt_12-1659124094221.png

 

Group 4 - "Inventory Manager"

 

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.

IoTProductMgmt_13-1659124094223.png

 

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.

IoTProductMgmt_14-1659124094225.png

 

Following this rule, here is the resulting Thing Shape:

IoTProductMgmt_15-1659124094225.png

 

Templates for Unique Components

 

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.

IoTProductMgmt_16-1659124094228.jpeg

 

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.

 

Adding Components Directly to Things

 

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.

IoTProductMgmt_17-1659124094230.png

 

Instantiate Your Things

 

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.

IoTProductMgmt_18-1659124094235.png

 

 

Step 10: Validate

 

IoTProductMgmt_19-1659124094237.png

 

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.

IoTProductMgmt_20-1659124094239.png

 

Using this technique on each of your Things, you can explicitly prove that all of the requirements have been met.

 

Step 11: Next Steps

 

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:

  • Create user stories
  • Identify endpoints in your system
  • Break down your data model using an Entity Relationship Diagram
  • Decide when to use Thing Templates vs. Thing Shapes vs. directly-instantiated Things

 

 

The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Data Model Implementation.

Version history
Last update:
‎Aug 19, 2022 10:06 AM
Updated by:
Labels (2)
Contributors