This project will introduce the process of taking your IoT solution from concept to design.
Following the steps in this guide, you will create a solution that doesn’t need to be constantly revamped, by creating a comprehensive Data Model before starting to build and test your solution.
We will teach you how to utilize a few proposed best practices for designing the ThingWorx Data Model and provide some prescriptive methods to help you generate a high-quality framework that meets your business needs. NOTE: This guide’s content aligns with ThingWorx 9.3. The estimated time to complete ALL 3 parts of this guide is 60 minutes. All content is relevant but there are additional tools and design patterns you should be aware of. Please go to this link for more details.
We will start by outlining the overall process for the proposed Data Model Methodology.
Identify who will use the application and what information they need. By approaching the design from a User perspective, you should be able to identify what elements are necessary for your system.
Identify the real-world objects or systems which you are trying to model. To create a solid design, you need to identify what the “things” are in your system and what data or functionality they expose.
Compose a representative model of modular components to enable uniformity and reuse of functionality wherever possible. Break down user requirements and data, identifying how the system will be modeled in Foundation.
Identify the sources of data, then evaluate how many different types of data you will have, what they are, and how your data should be stored. From that, you may determine the data types and data storage requirements.
Business Logic Strategy
Examine the functional needs, and map them to your design for proper business logic implementation. Determine the business logic as a strategic flow of data, and make sure everything in your design fits together in logical chunks.
User Access Strategy
Identify each user's access and permission levels for your application. Before you start building anything, it is important to understand the strategy behind user access. Who can see or do what? And why?
NOTE: Due to the length of this subject, the ThingWorx Data Model Methodology has been divided into multiple parts. This guide focuses on the first three steps = User Stories, Data Sources, and Model Breakdown. Guides covering the last three steps are linked in the final Next Steps page.
With a user-based approach to design, you identify requirements for users at the outset of the process. This increases the likelihood of user satisfaction with the result.
Utilizing this methodology, you consider each type of user that will be accessing your application and determine their requirements according to each of the following two categories:
Determine what the user needs to do.
This will define what kind of Services and Subscriptions will need to be in the system and which data elements and Properties must be gathered from the connected Things.
What information do they need?
Examine the functional requirements of the user to identify which pieces of information the users need to know in order to accomplish their responsibilities.
Let’s revisit our Smart Factory example scenario.
The first step of the User Story phase of the design process is to identify the potential users of your system.
In this example scenario, we have defined three different types of users for our solution:
Each of these users will have a different role in the system. Therefore, they will have different functional and informational needs.
It is the maintenance engineer’s job to keep machines up and running so that the operator can assemble and deliver products. To do this well, they need access to granular data for the machine’s operating status to better understand healthy operation and identify causes of failure. They also need to integrate their maintenance request management system to consolidate their efforts and to create triggers for automatic maintenance requests generated by the connected machines.
The operator’s job is to keep the line running and make sure that it’s producing quality products.
To do this, operators must keep track of how well their line is running (both in terms of speed and quality). They also need to be able to file maintenance requests when they have issues with the assets on their line.
The production manager oversees the dispatch of production orders and ensures quotas are being met.
Managers care about the productivity of all lines and the status of maintenance requests.
Once you have identified the users' requirements, you'll need to determine what parts of your system must be connected. These will be the Things in your solution. Keep in mind that a Thing can represent many different types of connected endpoints.
Here are some examples of possible Things in your system:
In our Smart Factory example, we have already identified the users of the system and listed requirements for each of those users. The next step is to identify the Things in our solution.
In our example, we are running a factory floor with multiple identical production lines. Each of these lines has multiple different devices associated with it.
Let’s consider each of those items to be a connected Thing.
Things in each line:
Let's also assume we already have both a Maintenance Request System and a Production Order System that are in use today.
To add this to our solution, we want to build a connector between Foundation and the existing system. These connectors will be Things as well.
NOTE: It is entirely possible to have scenarios in which you want to examine more granular-level details of your assets. For example, the arm and the hand of the assembly robot could be represented separately. There are endless possibilities, but for simplicity's sake, we will keep the list shorter and more high-level. Keep in mind that you can be as detailed as needed for this and future iterations of your solution. However, being too granular could potentially create unnecessary complexity and data overload.
Click here to view Part 2 of this guide.