Connect and Monitor Your Products with ThingWorx

The first step: Understand exactly what information you need. Use the initial design of your application to identify the data required for your use case.

Your requirements should include:

• The data you need
• Note the specific pieces of data or metrics you need to build the application for your use case.
• How often that data needs to be updated
• Does the data being used in your application need to be updated frequently to be useful?
• Keep in mind that the higher the frequency of updates, the more transactions your infrastructure will need to support.
• What format the data should take
• Does the information need to be presented as a number, integer, string, Boolean, etc.?
• Where that data lives
• Whether in a third-party system, an in-house solution, a .csv file, or something else, identify where this information currently lives.
• Whether the connection needs to be unidirectional or bidirectional
• Does ThingWorx need to be able to pass information back?
• If so, what happens once data is passed back?
• Why you need the data
• It can be tempting to ask for every data point available for your product, but that often leads to an overload of data. For each piece of data you’re requesting, make sure you know exactly why you need it to accomplish your use case.
• Categorize each piece of data to help understand if you need it.
• Actionable data typically triggers some sort of action or response. This data tends to be acquired and published near real time.
• Informational data represents various properties of your products or assets and typically changes infrequently.
• Historical data is used to represent rends or maintain a short-term record of information and events.
• Cold storage data is often used for data mining and analytics purposes and doesn’t need to be accessed or seen often.

Understanding what data you need and why you need it will help you have more effective conversations when you’re trying to determine how your organization will actually go about retrieving that data. The requirements you lay out will likely be negotiated and reworked as those conversations continue. ThingWorx collects data in 2 ways:

1. Integrations: You integrate with systems that house data.
2. Connectivity: You connect to products, machines, or other physical assets, typically at the edge.

When it comes to integration, ThingWorx has a number of integration connectors built in and ready to use but custom-built options could also be needed depending on what kind of integrations are required.

To decide on the best approach for your organization and selected use case, we recommend having a detailed conversation with your solution architect (who has extensive ThingWorx knowledge) and IT and OT experts. Include any others who have deep understanding of the specific data and systems with which you’re trying to connect.

To understand how to gather data from the edge, work with a solution architect and technical subject matter experts. Get understanding and agreement on:

• The data that needs to be collected at the edge
• How you plan to retrieve that data
• Where the data will be processed and how it will be sent the ThingWorx Platform
• What edge agent you'll use
• Where the edge agent will live and how many you'll need

It is critical to your success to create a strong plan for your edge. We recommend working with PTC or an experienced partner to find the best edge strategy for your organization.

Get product data to the edge agent

There are numerous ways to get product data to your edge agent. To understand your best option, find out if it’s possible to either influence the product design to help you collect data directly, or if you’ll need to rely on using logs, files, or databases to which your product sends data.

Consult with the team responsible for making the product, typically Research and Design (R&D). If R&D is open to incorporating software required for your edge within or on top of the product, decide if it’s more efficient to pull or push the data. Either 1) have the agent pull data from the product through something like a REST API or 2) have the product push data to the agent through a web service.

Processing and sending data

Decide if your data will be processed at the edge or at the ThingWorx platform, then determine when and how the data will be sent to the platform. PTC recommends processing data and incorporating business logic at the edge, if possible, in addition to these best practices:

• When possible, only send properties to the platform when the value has changed
• Also consider the precision required for your data value. For example, if you’re monitoring temperature and only need to know if the value has changed at the tenth of a degree, do not send a change at the hundredth or thousandth level.
• Consider using a “deadband” to identify the acceptable range for the property being measured. Only send data to the platform if it falls outside of the deadband.
• Build in business logic at the edge to help minimize the load on your ThingWorx server(s).

Choose an edge agent

An edge agent collects data from products in the field and then sends the required data to the ThingWorx Platform. Customers typically choose from 3 edge agent options:

1. ThingWorx Edge SDK
2. ThingWorx Edge Microserver
3. ThingWorx REST API

To choose the edge agent that’s best for your organization, consider:

• The skill sets of those building the edge agent. What languages are the developers already familiar with? No matter what agent you choose, you will likely need additional coding to make the agent work properly.
• You can build SDKs using C, Java, .NET, Objective-C, and Swift.
• You will have to do programming for the ThingWorx Edge Microserver in Lua.
• The functionality you want at the edge.
• Understand the foundation and basic capabilities provided with each agent. The ThingWorx Edge SDKs are the only agent options that give you access to the source code and are therefore the only options you can fully customize. The other agents will still allow you to build in additional functionality, but the foundation itself can’t be updated or changed.
• Once you understand what is included with the agent, explore what additional features you can build and support. Most agent options allow for basic functionality, including file transfer, file browsing, property updates, ability to run service calls, and remote access. Reference the use case(s) and goals you set earlier in the project and make sure the edge agent you choose will help you achieve them.
• One of the most important functions to consider is software updates. Not all agents allow software updates at the edge through software content management. You would need to consider alternate techniques, such as building in file transfer capabilities or using field technicians to update each product. Edge agents should never be deployed without an understanding of how they will be updated. Updates are required for security, bug fixes, and incorporating new functionality.
• What operating system(s) the agent needs to support.

Where the edge agent will live

Customers typically choose from 3 options to decide where the edge agent will live:

1. The edge agent lives on a computer that is part of the product itself. If this is the desired outcome, you’ll need to partner with R&D to work out the details.
2. In a tethered case, the agent lives on a secondary computer that is either attached to the product or lives generally close to the product.
3. A central agent, often called a “gateway”, is used to monitor and communicate to multiple products.

Once you know where the agent will live, consider how you will monitor the health of the computer hosing your edge agent. You can do this through Windows or Linux calls to check on things like memory and CPU.

Impacts of the edge on your solution

• Make sure your edge is secure by referring to your security requirements created earlier in the project. You may also consult the “ThingWorx Secure Deployment Guide.”
• Make sure the decisions you make regarding the edge comply with any compliance and regulatory requirements you gathered earlier in the project.
• The plan you make to collect product data at the edge and send it to the ThingWorx platform will have major implications on your infrastructure. Every decision you make will have an impact on the footprint at the edge and the performance of the platform. Make sure you stay in close contact with your IT team to find the best approach.

The power of ThingWorx comes from its ability to aggregate disparate data into a single place. Structure that data in a way that your ThingWorx applications can use it. Your data model architecture will be a digital representation of everything that provides data in ThingWorx and the relationships between those things.

Your ThingWorx data model is comprised of these entities:

• Things are digital representations of all products, assets, devices, systems, people, or processes that provide data.
• Thing Templates store core functionality (properties, services, events, and subscriptions). All Things need to be associated with a Thing Template, inheriting its identified functionality.
• Thing Shapes also store functionality but can be applied to single or multiple Thing Templates or Things. We recommend using Thing Shapes when there are properties, services, events, or subscriptions that span across multiple Thing Templates or Things across several Thing Templates.

While ThingWorx allows your data model to evolve, spend time determining how to structure your data early in the project. The best place to start: compile a list of Things required for your use case. From there, start to understand the relationships between those Things.

When planning your data model, meet with the developers who will be building the application in ThingWorx. Create standard naming conventions together. These naming conventions should be consistent throughout your organization. They will help keep the information in the ThingWorx platform clean and easy to find. Changing names of items in ThingWorx as an afterthought is challenging and time consuming, so making these decisions early on is important.

This is just a brief introduction to the ThingWorx data model. Use the recommended resources below to learn more and prepare to design your data model. We recommend working with a system integrator, programmer, or developer with object-oriented programming experience.

You’ve decided what agents you need, where they’ll live, and what functionality they’ll have. Now, determine how your agents will be distributed and connected in the field.

If the agent is part of or tethered to the product itself, we recommend partnering with R&D to have the agent creation and custom configurations, such as serial number, built into the manufacturing process.

If the agent can’t be included in the manufacturing process, consider who will be responsible for the installation—a field technician or the end customer. Provide clear documentation or training to help get the agent properly installed and connected.

To combine data from many disparate sources into a coherent and compatible data model in ThingWorx, understand the current relationships between the data in existing sources. This is critical to understanding if the data will need to be translated, linked, or manipulated to meet the requirements of your ThingWorx application. For example, ERP may have an asset “ABC” defined but that same asset may be defined as “ABC1” in the EAM system.

Now that you know which data sources you need to connect to and how you plan to connect to them, compile this information in a documented integration support strategy. This document will help inform other decisions that need to be made. It will help you make any changes to your infrastructure and create a timeline for your ThingWorx project.