Design Your Data Model Guide Part 2

[#1]

• Design Your Data Model Guide Part 2
• Step 4: Data Sources – Component Breakout
• Step 5: Data Sources – Thing-Component Matrix
• Step 6: Model Breakdown

Design Your Data Model Guide Part 2

 

Step 4: Data Sources – Component Breakout

Component Breakout

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.

Factory Example

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.

Conveyor Belts

The conveyor belt is simple in operation but could potentially have a lot of available data.

• Maintenance Engineer - needs to know granular data for the belt and if it has any alerts
1. emergency shutdown (service)
2. machine state (on/off) (property)
3. serial number (property)
4. last maintenance date (property)
5. next scheduled maintenance date(property)
6. power consumption (property)
7. belt speed (property)
8. belt motor temp (property)
9. belt motor rpm (property)
10. error notification (event)
11. auto-generated maintenance requests (subscription)
• Operator - needs to know if the belt is working as intended
1. belt speed (property)
2. alert status (event)
• Production Manager - wants access to the data the Operator can see but otherwise has no new requirements

Robotic Arm

The robotic arm has 3 axes of rotation as well as a clamp hand.

• Maintenance Engineer - needs to know granular data for the arm and if it has any alerts
1. time since last pickup (property): how long it has been since the last part was picked up by this hand?
2. product count (property): how many products the hand has completed
3. emergency shutdown (service)
4. machine state (on/off) (property)
5. serial number (property)
6. last maintenance date (property)
7. next scheduled maintenance date (property)
8. power consumption (property)
9. arm rotation axis 1 (property)
10. arm rotation axis 2 (property)
11. arm rotation axis 3 (property)
12. clamp pressure (property)
13. clamp status (open/closed) (property)
14. error notification (event) 15.auto-generated maintenance requests (subscription)
• Operator - needs to know if the robotic arm is working as intended
1. clamp status (open/closed) (property)
2. error notification (event)
3. product count (property): How many products has the hand completed?
• Production Manager - wants access to the data the Operator can see but otherwise has no new requirements

 

Pneumatic Gate

The pneumatic gate has two states, open and closed.

• Maintenance Engineer - needs to know granular data for the gate and if it has any alerts
1. emergency shutdown (service)
2. machine state (on/off) (property)
3. serial number (property)
4. last maintenance date (property)
5. next scheduled maintenance date (property)
6. power consumption (property)
7. gate status (open/closed) (property)
8. error notification (event)
9. auto-generated maintenance requests (subscription)
• Operator - needs to know if the pneumatic gate is working as intended.
1. gate status (open/closed) (property)
2. error notification (event)
• The Production Manager wants access to the data the Operator can see but otherwise has no new requirements

Quality Control Camera

The QC camera uses visual checks to make sure a product has been constructed properly.

• Maintenance Engineer - needs to know granular data for the camera and if it has any alerts
1. machine state (property): on/off
2. serial number (property)
3. last maintenance date (property)
4. next scheduled maintenance date (property)
5. power consumption (property)
6. current product quality reading (property)
7. images being read (property)
8. settings for production quality assessment (property)
9. error notification (event)
10. auto-generated maintenance requests (subscription)
11. product count (property): how many products the camera has seen
• Operator - needs to keep track of the quality check results and if there are any problems with the camera setup
1. settings for production quality assessment (property)
2. error notification (event)
3. bad quality flag (event)
4. product count (property): how many products the camera has seen
• Production Manager - wants access to the data the Operator can see but otherwise has no new requirements

Maintenance Request System Connector

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.

• Maintenance Engineer - needs to receive and update maintenance requests
1. maintenance engineer credentials (property): authentication with the maintenance system
2. endpoint configuration for connecting to the system (property)
3. get unfiltered list of maintenance requests (service)
4. update description of maintenance request (service)
5. close maintenance request (service)
• Operator - needs to create and track maintenance requests
1. operator credentials (property): authentication with the maintenance system
2. endpoint configuration for connecting to the system (property)
3. create maintenance request (service)
4. get filtered list of maintenance requests for this operator (service)
• Production Manager - needs to monitor the entire system - both the creation and tracking of maintenance requests; needs to prioritize maintenance requests to keep operations flowing smoothly
1. production manager credentials (property): authentication with the maintenance system
2. endpoint configuration for connecting to the system (property)
3. create maintenance request (service)
4. get unfiltered list of maintenance requests (service)
5. update priority of maintenance request (service)

Production Order System Connector

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.

• Maintenance Engineer - will not need to know anything about production orders, as it is outside the scope of their job needs
• Operator - needs to know which production orders have been set up for the line, and needs to mark orders as started or completed
1. operator credentials (property): authentication with the production order system
2. endpoint configuration for connecting to the system (property)
• mark themselves as working a specific production line (service)
• get a list of filtered production orders for their line (service)
• update production orders as started/completed (service)
• Production Manager - needs to view the status of all production orders and who is working on which line
1. production manager credentials (property): authentication with the production order system
2. endpoint configuration for connecting to the system (property)
3. get a list of production lines with who is working them (service)
4. get the list of production orders with filtering options (service)
5. create new production orders (service)
6. update existing production orders for quantity, and priority (service)
7. assign a production order to a production line (service)
8. delete production orders (service)

Step 5: Data Sources – Thing-Component Matrix

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.

 

Sample Thing-Component Matrix

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.

 

Overlapping Matrix

This matrix represents all the overlapping Components that are shared by multiple types of Things in our system:

Unique Matrix

This matrix represents the Components unique to each type of Thing:

Step 6: Model Breakdown    

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.

 

Entity Relationship Diagram

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.

Breakdown Process

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.

Step	Description
1	Prioritize the Groups of Components from your Thing-Component Matrix by each Group's Component quantity.
2	Create a base Thing Template for the largest group.
3	Iterate over each Group deciding which entity type to create.
4	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.