Once you have a full list of Things in your system (as well as requirements for each user), the next step is to identify the information needed from each Thing (based on the user's requirements).
This involves evaluating the available data and functionality for each Thing. You then align the data and functionality with the user's requirements to determine exactly what you need, while eliminating that which you do not. This is important, as there can be cost and security benefits to only collecting data you need, and leaving what you don't.
NOTE: Remember from the Data Model Introduction that a Thing's Components include Properties, Services, Events, and Subscriptions.
Using the Smart Factory example, let’s go through the different Things and break down each Thing's components that are needed for each of our users.
The conveyor belt is simple in operation but could potentially have a lot of available data.
The robotic arm has 3 axes of rotation as well as a clamp hand.
The pneumatic gate has two states, open and closed.
The QC camera uses visual checks to make sure a product has been constructed properly.
Determining the data needed from the Maintenance Request System is more complex than from the physical components, as it will be much more actively used by all of our users.
It is important to note that the required functionality already exists in our system as is, but it needs bridges created to connect it to a centralized system.
Working with the Production Order System is also more complex than the physical components of the lines, as it will be more actively used by two of the three users.
It is important to note that the required functionality already exists in our existing production order system as is, but it needs bridges created to connect to a centralized system.
Now that you have identified the Components necessary to build your solution (as well as the Things involved in enabling said Components), you are almost ready to create your Data Model design.
Before moving onto the design, however, it is very helpful to get a good picture of how these Components interact with different parts of your solution. To do that, we recommend using a Thing-Component Matrix. A Thing-Component Matrix is a grid in which you will list Things in rows and Components in columns. This allows you to identify where there are overlaps between Components. From there, you can break those Components down into reusable Groups.
Really, all you're doing in this step is taking the list of individual Things and their corresponding Components and organizing them. Instead of thinking of each item's individually-required functionality, you are now thinking of how those Components might interact and/or be reused across multiple Things.
As a generic example, look at the chart presented here.
You have a series of Things down the rows, while there are a series of Components (i.e. Properties, Services, Events, and Subscriptions) in the columns. This allows you to logically visually identify how some of those Components are common across multiple Things (which is very important in determining our recommendations for when to use Thing Templates vs. Thing Shapes vs. directly-instantiated Things). If we were to apply this idea to our Smart Factory example, we would create two sections of our Thing-Component Matrix, i.e. the Overlapping versus Unique Components.
NOTE: It is not necessary to divide your Thing Component Matrix between Overlapping vs Unique if you don't wish to do so. It is done here largely for the sake of readability.
This matrix represents all the overlapping Components that are shared by multiple types of Things in our system:
This matrix represents the Components unique to each type of Thing:
Breaking down your use case into a Data Model is the most important part of the design process for ThingWorx. It creates the basis for which every other aspect of your solution is overlaid. To do it effectively, we will use a multi-step approach. This will allow us to identify parts we can group and separate, leading to a more modular design.
To standardize the represention of Data Models, it is important to have a unified view of what a representation might look like. For this example, we have developed an Entity Relationship Diagram schematic used for Data Model representation. We will use this representation to examine how to build a Data Model.
ThingWorx recommends following an orderly system when building the specifics of your Data Model. You've examined your users and their needs. You've determined the real-world objects and systems you want to model. You've broken down those real-world items by their Component functionality. Now, you will follow these steps to build a specific Data Model for your application.
Prioritize the Groups of Components from your Thing-Component Matrix by each Group's Component quantity.
Create a base Thing Template for the largest group.
Iterate over each Group deciding which entity type to create.
Validate the design through instantiation.
In the next several pages, we'll examine each of these steps in-depth.
Click here to view Part 3 of this guide.