IoT & Connectivity Tips

  Step 5: Create Services   Below shows how we can create the GetCustomerPackages Service for the PTCDeliversBusinessLogic Thing.   Create Service Definition   On the home page, filter and select the PTCDeliversBusinessLogic Thing. Switch to the Services tab. Click + Add.   Enter the name of the Service, GetCustomerPackages. Switch to the Output tab of the Service. Select InfoTable from the list as the Base Type. When prompted for the DataShape, select CustomerDataShape. Switch to the Inputs tab of the Service. Click the + Add button.   Enter the name CustomerId. Check the Required checkbox. Click Done.   Add Service Functionality   Switch to the Me/Entities tab. Switch the radio option to Other Entity. Filter and select PackageDataTable as the Entity. A list of all accessible Services for the PackageDataTable will appear. In the search bar for Services, enter QueryDataTableEntries in the Services section and click the arrow next to it. Update the inserted code to use the input parameter, CustomerId, in the query. An example is below and more information can be found on queries on our Query Help Page. Click Done and save your work.             / Provide your filter using the format as described in the help topic "Query Parameter for Query Services" var query = { "filters": { "type": "EQ", "fieldName": "CustomerId", "value": CustomerId } }; // result: INFOTABLE dataShape: "" var result = Things["PackageDataTable"].QueryDataTableEntries({ maxItems: undefined /* NUMBER */, values: undefined /* INFOTAB             After saving changes and closing the Service edit view, you can test the method by selecting the Execute play button.   The Service we created will query PackageDataTable for any packages with the CustomerId you entered. If no data has been added to the DataTable as yet, open PackageDataTable's Services tab and execute the AddDataTableEntries Service with test data.       Step 6: Create Subscriptions   Subscriptions are based on tracking the firing of an Event. When the Event is triggered or fired, all entities with a Subscription to the Event will perform the script as defined. The JavaScript interface and script tabs are the same as those utilized for the Services interface.   Subscriptions are a great resource for making updates in other Entities, Databases, or even just logging this information to your liking. On the home page, filter and select the PTCDeliversBusinessLogic Thing. Switch to the Subscriptions tab. Click + Add.   For Source, select *Other Entity. Filter and select PackageStream. Check the Enabled checkbox. Using a Stream to track events in the application allows for one source to watch for activity. The source for a Subscription can be other Entities if a single Entity is wanted. In order to capture all source data from the PackageStream, you will need to set it as the Stream for the Entity you would like to track. Switch to the Inputs tab. Select the Event drop-down and pick the PackageDelivered Event. This PackageDelivered Event only exists in the completed download. If you are not using that download, create your own Event based on the PackageDataShape. Update the script area of the Subscription using the below code. This JavaScript code will take the information from the triggered Event and add it to the DeliveryDataTable.           / tags:TAGS var tags = new Array(); // values:INFOTABLE(Datashape: PackageDataShape) var values = Things["DeliveryDataTable"].CreateValues(); values.Customer = eventData.Customer; // THINGNAME values.Content = eventData.Content; // STRING values.ID = eventData.ID; // INTEGER [Primary Key] values.Weight = eventData.Weight; // NUMBER // location:LOCATION var location = new Object(); location.latitude = 0; location.longitude = 0; location.elevation = 0; location.units ="WGS84"; var params = { tags : tags, source : me.name, values : values, location : location }; // AddOrUpdateDataTableEntry(tags:TAGS, source:STRING("me.name"), values:INFOTABLE(DeliveryDataTable), location:LOCATION):STRING var id = Things["DeliveryDataTable"].AddOrUpdateDataTableEntry(params);                 Step 7: Next Steps   Congratulations! You've successfully completed the Implement Services, Events and Subscriptions guide.   In this guide you learned how to to create Events, Services and Subscriptions you can utilize to monitor and optimize your IoT applications.   The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Build a Predictive Analytics Model.    The next guide in the Monitor Factory Supplies and Consumables learning path is Build a Predictive Analytics Model.   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Build Create Custom Business Logic Guide Secure Configure Permissions Connect SDK Reference   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Help Center  

Data Model Implementation Guide Part 1   Overview   This project will introduce you to methods for creating the data model that you have designed and are ready to implement. Following the steps in this guide, you will implement the Data Model you've already designed. After having insight into your desired Data Model, this guide will provide instructions and examples on how to build out your application using the ThingWorx platform. We will teach you how to utilize the ThingWorx platform to implement your fully functional IoT application. 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. Please go to this link for more details.     Step 1: Completed Example   Download the completed files for this tutorial:  DataModelEntities.xml. The DataModelEntities.xml file provided to you contains a completed example of the completed data model implementation. Utilize this file to see a finished example and return to it as a reference if you become stuck during this guide and need some extra help or clarification. Keep in mind, this download uses the exact names for entities used in this tutorial. If you would like to import this example and also create entities on your own, change the names of the entities you create.   Step 2: Data Model Scenario   This guide will implement the scenario shown in the Data Model Design guide. Let's revisit our Smart Factory example scenario. Name Description Operations User to keep the line running and make sure that it’s producing quality products Maintenance User to keep machines up and running so that the operator can crank out products Management User in charge of dispatching production orders and making sure the quotas are being met Conveyor Belts Thing on factory line to pass items along to the next stage Pneumatic Gate Thing on factory line Robotic Arm Thing on factory line Quality Check Camera Final Thing on factory line to ensure quality In order to add this to our solution, we will want to build a "connector" between ThingWorx and the existing system. These connectors will be Things as well. Internal system connection Thing for Production Order System Internal system connection Thing for Maintenance Request System Operator   Required Functionality Description 1 File Maintenance Request 2 Get quality data from assets on their line 3 Get performance data for the whole line 4 Get a prioritized list of production orders for their line 5 Create Maintenance Requests   Required Information Description 1 Individual asset performance metrics 2 Full line performance metrics 3 Product quality readings   Maintenance   Required Functionality Description 1 Get granular data values from all assets 2 Get a list of maintenance requests 3 Update maintenance requests 4 Set triggers for automatic maintenance request generation 5 Automatically create maintenance requests when triggers have been activated   Required Information Description 1 Granular details for each asset: In order to better understand healthy asset behavior 2 Current alert status for each asset: to know if there is something going wrong with an asset 3 When the last maintenance was performed on an asset 4 When the next maintenance is scheduled for an asset 5 Maintenance request info: Creation date, due date, progress notes   Management   Required Functionality Description 1 Create production orders 2 Update production orders 3 Cancel Production orders 4 Access line productivity data 5 Elevate maintenance request priority   Required Information Description 1 Production line productivity levels (OEE) 2 List of open Maintenance requests   Overlapping Matrix   This matrix represents all of the overlapping Components that are shared by multiple types of Things in our system:   Unique Matrix   This matrix represents the unique Components to each type of Thing:     Step 3: LineAsset Thing Template   After prioritizing and grouping common functionality and information, we came up with the list below for the first Thing Template to create, LineAsset with five Properties, one Event, and one Subscription. The breakdown for the LineAsset Thing Template is as follows:   Follow the below instruction to create this Entity and get the implementation phase of your development cycle going.   Line Asset Properties   Let's build out our Properties. In the ThingWorx Composer, click the + New at the top of the screen. Select Thing Template in the dropdown.        3. In the name field, enter LineAsset and set the Project (ie, PTCDefaultProject). 4. For the Base Thing Template field, select GenericThing.     5. Click Save.  6. Switch to the Properties and Alerts tab.  7. Click the plus button to add a new Property.   The Properties for the LineAsset Thing Template are as follows: Name Base Type Aspects Data Change Type State String Persistent and Logged ALWAYS SerialNumber String Persistent, Read Only, and Logged NEVER LastMaintenance DATETIME Persistent and Logged VALUE NextMaintenance DATETIME Persistent and Logged VALUE PowerConsumption NUMBER, Min Value: 0 Persistent and Logged ALWAYS Follow the next steps for all the properties shown in our template property table. Click Add. Enter the name of the property (ie, State). Select the Base Type of the proprty from the dropdown. Check the checkboxes for the property Aspects. Select the Data Change Type from the dropdown.   Click Done when finished creating the property. Your properties should match the below configurations.     Line Asset Event   Switch to the Events tab. Click Add. Enter the name of the Event (ie, Error). Select AlertStatus as the Data Shape. This DataShape will allow us to provide simple information including an alert type, the property name, and a status message.   Click Done. Your Event should match the below configurations.          Line Asset Subscription   Switch to the Subscriptions tab. Click Add. Check the Enabled checkbox. Switch to the Inputs tab. Select the name of the Event (ie, Error). Click Done. Your Subscription should match the below configurations.             Challenge Yourself   We have left the Subscription code empty. Think of a way to handle Error Events coming from your line asset and implement it in this section.   Click here to view Part 2 of this guide. 

Data Model Implementation Guide Part 2   Step 4: SystemConnector Thing Template   After grouping our second set of common functionality and information, we came up with the list below for the second Thing Template to create, SystemConnector with 3 Properties. The breakdown for the SystemConnector Thing Template is as follows:   Follow the below instruction to create this Entity and get the implementation phase of your development cycle going.   System Connector Properties   Let's jump right in. In the ThingWorx Composer, click the + New at the top of the screen.        2. Select Thing Template in the dropdown. 3. In the name field, enter SystemConnector and select a Project (ie, PTCDefaultProject). 4. For the Base Thing Template field, select GenericThing. 5. Click Save. 6. Switch to the Properties and Alerts tab. 7. Click the plus button to add a new Property.   The Properties for the SystemConnector Thing Template are as follows: Name Base Type Aspects Data Change Type EndPointConfig String Persistent and Logged VALUE OperatorCredentials PASSWORD Persistent VALUE ProdManagerCredentials PASSWORD Persistent VALUE Follow the next steps for all the Properties shown in our template property table. Click Add. Enter the name of the property (ie, EndPointConfig). Select the Base Type of the proprty from the dropdown. Check the checkboxes for the property Aspects. Select the Data Change Type from the dropdown.   Click Done when finished creating the property. Your Properties should match the below configurations.            Step 5: HazardousAsset Thing Template     After another round of prioritizing and grouping common functionality and information, we came up with the third Thing Template to create, HazardousAsset. It is a child of the LineAsset Thing Template with one added Service. The breakdown for the HazardousAsset Thing Template is as follows:   Hazardous Asset Service   In the ThingWorx Composer, click the + New at the top of the screen. 2. Select Thing Template in the dropdown. 3. For the Base Thing Template field, select LineAsset and select a Project (PTCDefaultProject). 4. In the name field, enter HazardousAsset. 5.  Click Save then edit to store all changes now. 6.  Switch to the Services tab. 7.  Click Add. 8.  Enter EmergencyShutdown as the name of the service. 9. Switch to the Me/Entities tab. 10. Expand Properties. 11. Click the arrow next to the State property. 12. Modify the generated code to match the following:       me.State = "Danger!! Emergency Shutdown";       Your first Service is complete! 13. Click Done. 14. Click Save to save your changes. Your Service should match the below configurations.     Step 6: InventoryManager Thing Shape   This time around, we will create our first ThingShape, InventoryManager with 1 Property. The breakdown for the InventoryManager Thing Shape is as follows:   Follow the below instruction to create this Entity and get the implementation phase of your development cycle going. System Connector Properties The properties for the InventoryManager Thing Shape are as follows: Name Base Type Aspects Data Change Type ProductCount INTEGER Min Value:0 Persistent and Logged ALWAYS In the ThingWorx Composer, click the + New at the top of the screen. Select Thing Shape in the dropdown. In the name field, enter InventoryManager and select a Project (ie, PTCDefaultProject).       4. Click Save then Edit to store all changes now.         5. Switch to the Properties tab.        6. Click Add.       7. Enter ProductCount as the name of the property.       8. Select the Base Type of the proprty from the dropdown (ie, INTEGER).       9. Check the checkboxes for the property Aspects.      10. Select the Data Change Type from the dropdown.            11. Click Done when finished creating the property. Your Properties should match the below configurations.   Add Thing Shape to Template   We can see that there is some overlap in the components of our HazardousAsset and LineAsset ThingTemplates. In particular, both want information about the product count. Because HazardousAsset inherits from LineAsset, would only need to change LineAsset. Follow the steps below to perform this change: Open the LineAsset Thing Template. In the Implemented Shapes field, enter and select InventoryManager. Save changes.         Click here to view Part 3 of this guide.   

  Design Your Data Model Guide Part 3   Step 7: Prioritize     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.   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     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.   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.   The result is a ThingWorx Thing Template with five Properties, one Event, and one Subscription.     Step 9: Iterate     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:   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.   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.   Following this rule, here is the resulting template:   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.   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.   Following this rule, here is the resulting Thing Template:   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.   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.   Following this rule, here is the resulting Thing Shape:   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.   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.   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.     Step 10: Validate     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.   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.

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 emergency shutdown (service) machine state (on/off) (property) serial number (property) last maintenance date (property) next scheduled maintenance date(property) power consumption (property) belt speed (property) belt motor temp (property) belt motor rpm (property) error notification (event) auto-generated maintenance requests (subscription) Operator - needs to know if the belt is working as intended belt speed (property) 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 time since last pickup (property): how long it has been since the last part was picked up by this hand? product count (property): how many products the hand has completed emergency shutdown (service) machine state (on/off) (property) serial number (property) last maintenance date (property) next scheduled maintenance date (property) power consumption (property) arm rotation axis 1 (property) arm rotation axis 2 (property) arm rotation axis 3 (property) clamp pressure (property) clamp status (open/closed) (property) error notification (event) 15.auto-generated maintenance requests (subscription) Operator - needs to know if the robotic arm is working as intended clamp status (open/closed) (property) error notification (event) 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 emergency shutdown (service) machine state (on/off) (property) serial number (property) last maintenance date (property) next scheduled maintenance date (property) power consumption (property) gate status (open/closed) (property) error notification (event) auto-generated maintenance requests (subscription) Operator - needs to know if the pneumatic gate is working as intended. gate status (open/closed) (property) 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 machine state (property): on/off serial number (property) last maintenance date (property) next scheduled maintenance date (property) power consumption (property) current product quality reading (property) images being read (property) settings for production quality assessment (property) error notification (event) auto-generated maintenance requests (subscription) 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 settings for production quality assessment (property) error notification (event) bad quality flag (event) 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 maintenance engineer credentials (property): authentication with the maintenance system endpoint configuration for connecting to the system (property) get unfiltered list of maintenance requests (service) update description of maintenance request (service) close maintenance request (service) Operator - needs to create and track maintenance requests operator credentials (property): authentication with the maintenance system endpoint configuration for connecting to the system (property) create maintenance request (service) 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 production manager credentials (property): authentication with the maintenance system endpoint configuration for connecting to the system (property) create maintenance request (service) get unfiltered list of maintenance requests (service) 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 operator credentials (property): authentication with the production order system 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 production manager credentials (property): authentication with the production order system endpoint configuration for connecting to the system (property) get a list of production lines with who is working them (service) get the list of production orders with filtering options (service) create new production orders (service) update existing production orders for quantity, and priority (service) assign a production order to a production line (service) 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.   

Build a Predictive Analytics Model Guide Part 1   Overview   This project will introduce ThingWorx Analytics Builder. Following the steps in this guide, you will create an analytical model, and then refine it based on further information from the Analytics platform. We will teach you how to determine whether or not a model is accurate and how you can optimize both your data inputs and the model itself.   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete ALL 2 parts of this guide is 60 minutes.      Step 1: Scenario   MotorCo manufactures, sells, and services commercial motors. Recently, MotorCo has been developing a new motor, and they already have a working prototype. However, they've noticed that the motor has a chance to FAIL CATASTROPHICALLY if it's not properly serviced to replace lost grease on a key moving part. In order to prevent this type of failure in the field, MotorCo has decided to instrument their motors with sensors which record vibration. The hope is that these sensors can detect certain vibrations which indicate required maintenance before a failure occurs. MotorCo has decided to utilize ThingWorx Analytics to scan their prototype data for any insights they can gain to address this issue. Challenges: There is a known failure mode of a prototype, but it is not currently possible to predict when the failure might happen Until this failure mode is mitigated, the prototype cannot move into full production While connected data is being monitored, what to do with that data is not currently known The additional sensors are adding to the overall cost of the product   Step 2: Settings   If you manually installed the Analytics extension, then you need to complete the steps below to finalize the connection.  On the ThingWorx Composer Analytics tab, click ANALYTICS BUILDER > Settings. In the Analytics Server field, search for and select your Server Thing Entity, such as AnalyticsServer_Thing or localhost-AnalyticsServer. Click Verify Configuration.   Click Save. WARNING: You MUST CLICK SAVE or the configurations will be lost when you move to Data in the next step.   Step 3: Upload Data   We will now load the data that ThingWorx Analytics will use to generate a model. Download the attached analytics_vibration.zip to your computer. Unzip the analytics_vibration.zip file to access the vibration_data_and_header.csv and vibration_metadata.json files. On the left, click ANALYTICS BUILDER > DATA.   Under Datasets, click New.... The New Dataset pop-up will open.         5. In the Dataset Name field, enter vibration_dataset. 6. In the File Containing Dataset Data section, search for and select vibration_data_and_header.csv. 7. In the File Containing Dataset Field Configuration section, search for and select vibration_metadata.json.   8. Click Submit. Note that it will take a variable amount of time for the data-upload to complete, based on the size of your dataset.              Step 4: Signals   The Signals section of ThingWorx Analytics looks for the most statistically correlated single field in the dataset which relates to your selected goal. This doesn't necessarily indicate that it is the cause of your goal, whether maximizing or minimizing. It just means that the dataset indicates that this single field happens to correlate with the goal that you desire. On the left, click ANALYTICS BUILDER > Signals.   At the top, click New…. A New Signals pop up will open.   3. In the Signal Name field, enter vibration_signal. 4. In the Dataset field, select vibration_dataset. 5. Leave the Goal field set to the default of low_grease. 6. Leave the Filter field set to the default of all_data. 7. Leave the Excluded Fields from Signal field set to the default of empty. 8. Click Submit. 9. Wait ~30 seconds for Signal State to change to COMPLETED The results will be displayed at the bottom.             The results show that the five Frequency Bands for Sensor 1 are the most highly correlated with determining our goal of detecting a low grease condition. For Sensor 2, only bands one and four seem to be at all related, and bands two, three, and five are hardly related at all.   Click here to view Part 2 of this guide. 

Create Industrial Equipment Model Guide   Overview   This project introduces how to model industrial equipment in ThingWorx Foundation. NOTE: This guide’s content aligns with ThingWorx 9.3. The estimated time to complete this guide is 30 minutes.    Step 1: Learning Path Overview   This guide explains the steps to get started modeling industrial equipment in ThingWorx Foundation and is part of the Connect and Monitor Industrial Plant Equipment Learning Path. You can use this guide independent from the full Learning Path. Other guides are available for more complete Data Model Introduction. When using this guide as part of the Industrial Plant Learning Path, you should already have ThingWorx Kepware Server installed and sending data to ThingWorx Foundation. In the next guide in the Learning Path, we'll use Foundation's Mashup Builder to construct a GUI that displays information and from ThingWorx Kepware Server. We hope you enjoy this Learning Path.   Step 2: Create Thing Shape   Thing Shapes are components that contain Properties and Services. In Java programming terms, they are similar to an interface. In this section, you will build Thing Shapes for an electric motor. Motor Start on the Browse folder icon tab of ThingWorx Composer. Under the Modeling section of the left-hand navigation panel, hover over Thing Shapes, then click the + button. Type MotorShape in the Name field. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. Click Save.   Add Properties   Click the Properties and Alerts tab at the top of your Thing Shape.   Click + Add. Enter the Property name from the first row of the table below into the Name field of the Thing Shape. Name Base Type Persistent? Logged? serialNumber String X   currentPower Number   X 4. Select the appropriate Base Type from the drop-down menu. 5. Check Persistent and/or Logged according to the table. NOTE: When Persistent is selected, the Property value will be retained when a Thing is saved. Properties that are not persisted will be reset to the default after every Save of the parent Thing. When Logged is selected, every Property value change will be automatically logged to a specified Value Stream. 6. Click ✓+ button. TIP: When adding multiple Properties at once, click Done and Add after each, once you've entered a Name, selected a Base Type and any other criteria. If adding a single Property, click Done. 7. Repeat steps 2 through 5 for the other Properties in the the table. 8. Click the done ✓ Button. You'll see that these Properties have been created for the Motor Thing Shape. 9. Click Save.   Step 3: Create Thing Template   You can create reusable building blocks called Thing Templates in ThingWorx to maintain scalability and flexibility of your application development. With Thing Templates, you define a set of similar objects by specifying the Properties (characteristics) and Services (behaviors) that are common for all the objects. In Java programming terms, a Thing Template is like an abstract class and can be created by extending other Thing Templates. Once a Thing Template is defined and saved in ThingWorx Foundation Server, you can replicate multiple Things to model a complete set without duplicating effort. In this step, you will create a Thing Template that defines Properties for a pump. This pump Template could be used to create multiple Things that each represent a specific pump used in an industrial facility. Start on the Browse folder icon tab on the far left of ThingWorx Composer. Under the Modeling section of the left-hand navigation panel, hover over Thing Templates and click the + button. Type PumpTemplate in the Name field. NOTE: Thing Template names are case-sensitive.       4. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject.       5. In the Base Thing Template box, click + to choose GenericThing as the Template.              6. In the Implemented Shapes field, click the + to select the MotorShape Thing Shape.              7. Click Save.   Add Properties   In this step, you will specify the Properties that represent the characteristics of a Pump. Some Properties like the location may never change (static), while other Properties like power and temperature information may change every few seconds (dynamic). Select the Properties and Alerts tab under Thing Template: PumpTemplate.   Click the Edit button if the Template is not already open for editing, then click + Add next to My Properties. Enter the Property name in the Name field copied from a row of the table below. Name Base Type Persistent Logged PlantID STRING x   plant_lat_long LOCATION x   watts NUMBER x x 4. Select the Base Type of the Property from the drop down menu. 5. Check the appropriate Persistent and Logged check box. NOTE: When Persistent is selected, the Property value will be retained when the parent Thing is saved. Properties that are not persisted will be reset to the default during a system restart and whenever the Thing is saved. When Logged is selected, every Property value change will be automatically logged to a specified Value Stream. 6. Click the ✓+ button. TIP: When adding multiple Properties at once, click Check+ after each, once you've entered a Name, selected a Base Type and any other criteria. If adding a single Property, click Check button. 7. Repeat steps 3 through 6 for each of the Properties in the rows of the table. 8. After entering the final Property, click the ✓ button. 9. Click Save. You should see the following Properties in your Composer.   In the next guide of this Learning Path, we will create a single Thing based on this Template to represent a specific Pump.     Step 4: Next Steps   Congratulations! You've successfully completed the Create Industrial Equipment Model tutorial, and learned how to: Use Composer to create Thing Shapes and Thing Templates Create Model Tags to keep entities organized   The next guide in the Connect and Monitor Industrial Plant Equipment learning path is Build an Equipment Dashboard.    

Build an Equipment Dashboard Guide Part 2   Step 5: Display Data   Now that you have configured the visual part of your application, you need to bind the Widgets in your Mashup to a data source.   Add Services to Mashup   In the top-right, ensure the Data tab is selected. Click the green + symbol. In the Entities Filter field, search for and select MyPump. In the Services Filter field, type GetPropertyValues. Click the right-arrow beside GetPropertyValues. Note how GetPropertyValues was added to the right-side under Selected Services Check the checkbox for Execute on Load. This causes the Service to execute when the Mashup starts.        7. In the Services Filter field, type QueryPropertyHistory. 8. Click the right-arrow beside QueryPropertyHistory. 9. Check the checkbox for Execute on Load. 10. Click Done to close the pop-up. Note how the Services have been added to the Data tab in the top-right.          11. Click Save. Now that we have access to the backend data, we want to bind it to our Widgets.   Value Display   Configure the Value Display to display the SerialNumber of the pump. Under the Data tab, expand GetPropertyValues > Returned Data > All Data. Drag-and-drop GetPropertyValues > serialNumber onto the Value Display Widget in the top section. On the Select Binding Target popup, select Data. Image   We want to use an Image Widget to display a thumbnail picture of the pump for easy reference. To do that, though, you first need to upload an image to Foundation by creating a Media Entity. Right-click the image below, then click "Save image as..." to download. Click Browse > Visualization > Media. Click + New. In the Name field, type pump-thumbnail. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. Under Image, click Change. Navigate to and select the pump-image.png file you just downloaded. On the navigation pop-up, click Open to close the pop-up and confirm the image selection. At the top of Foundation, click Save. Change Image to pump   We will now update the Image Widget to display the ThingWorx Media Entity we just created. Return to the pump-dashboard Mashup. Click the Image Widget to select it, and ensure that the bottom-left Properties tab is active. In the bottom-left Properties' Filter field, type SourceURL. For the SourceURL Property, search for and select pump-thumbnail. Click Save.   Line Chart   Configure the Line Chart to display Property values changing over time. In the top-right Data tab, expand QueryPropertyHistory > Returned Data. Drag and drop QueryPropertyHistory > All Data onto the Line Chart Widget in the bottom-right Canvas section. On the Select Binding Target pop-up, select Data. Ensure the Line Chart Widget is selected. On the Line Chart's Property panel in the bottom-left, in the Filter field, type XAxisField. For the XAxisField Property, select timestamp. In the Filter field, type LegendFilter. Check the checkbox for LegendFilter. Click Save.   Verify Data Bindings   You can see the configuration of data sources bound to Widgets in the bottom-center Connections pane. In the top-right Data tab, click GetPropertyValues. Check the diagram in the bottom-center Connections window to confirm a data source is bound to the Value Display Widget.       2. Also in the top-right Data tab, click QueryPropertyHistory. Confirm that the diagram shows it is bound to the Line Chart.         3. Click Save.     Step 6: Test Application   Browse to your Mashup and click View Mashup to launch the application. NOTE: You may need to enable pop-ups in your browser to see the Mashup. 2. Confirm that data is being displayed in each of the sections. 3. Open the MyPump Thing, then click the Properties and Alerts Tab. 4. Click Set Value on the line of the serialNumber Property. 5. Enter a value for the serial number, then click the Check-mark button. 6. Click Refresh to confirm the value is changed. 7. Refresh the browser window showing the dashboard to see the new serial number value.     Step 7: Next Steps   Congratulations! You've successfully completed the Build an Equipment Dashboard guide, and learned how to: Use Composer to create a Thing Shape and a Thing Template Make a Thing using a custom Thing Template Store Property change history in a Value Stream Create an applicaton UI with Mashup Builder Display data from connected devices Test a sample application   If you like to return to previous guides in the learning path, select Connect and Monitor Industrial Plant Equipment.    

Build an Equipment Dashboard Guide Part 1   Overview   This project will introduce you to the principles of ThingWorx Foundation by creating an eqipment dashboard. Following the steps in this guide, you will create the building blocks of your first IoT application, including Things and Streams. We introduce the basics for creating an IoT application. NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete ALL 2 parts of this guide is 30 minutes.    Step 1: Learning Path Overview   This guide explains the steps to create an Industrial Eqipment Dashboard, and is part of the Connect and Monitor Industrial Plant Equipment Learning Path. You can use this guide independently from the full Learning Path. If you want to learn the basics of creating an eqipment dashboard with ThingWorx, this guide will be useful to you.When used as part of the Industrial Plant Learning Path, you should already have ThingWorx Kepware Server installed, and it should be sending data to ThingWorx Foundation. You also need to have previously created the Thing Shape and Thing Template used for this dashboard. We hope you enjoy this Learning Path.   Step 2: Create Thing   A Thing is used to digitally represent a specific component of your application in ThingWorx. In Java programming terms, a Thing is similar to an instance of a class. In this step, you will create a Thing that represents an individual Pump using the Thing Template we created in the previous guide. Using a Thing Template allows you to increase development velocity by creating multiple Things without re-entering the same information each time. In ThingWorx Foundation, navigate to Browse > Modeling > Things. Click + New. In the Name field, type MyPump. NOTE: This name, with matching capitalization, is required for the data display created in a later step.       4. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject.       5. In the Base Thing Template field, search for and select the previously-created PumpTemplate.       6. At the top, click Save.          Manage Property Bindings At the top, click Properties and Alerts. At the top, click Manage Bindings. In the top-left Local > Search Things field, search for and select IndConn_Tag1. Drag-and-drop Simulation_Examples_Functions_Random3's + symbol onto the watts Property on the right. At the bottom-right of the pop-up, click Done. Note how the Tag from ThingWorx Kepware Server is now bound to the the watts Property. Click Save. Click Refresh repeatedly to confirm the watts Property value is changing.     Step 3: Store Data in Value Stream   Now that you have created the MyPump Thing to model your application in ThingWorx, you need a storage Entity to record changing Property values. This step shows how to save time-series data in a Value Stream already created in a previous guide. To learn more, refer to the Methods for Data Storage guide. Navigate to Browse > Modeling > Thing Templates. Click the previously-created PumpTemplate Thing Template to open it. Confirm you are on the General Information tab. If necessary, click Edit to allow changes. In the Value Stream field, search for and select IndConn_ValueStream. Click Save.   Step 4: Create Application UI   ThingWorx Foundation is used to create customized web applications that can display and interact with data from multiple sources. These web applications are called Mashups and are created using the Mashup Builder. The Mashup Builder is where you create your web application by dragging and dropping Widgets such as Grids, Charts, Maps, and Buttons onto a Canvas. All of the user interface elements in your application are Widgets. We will build a web application with three Widgets: Image showing a picture of the pump Value Display showing the pump serial number Line Chart showing the value of watts Property trend over time.   Create New Mashup   Navigate to Browse > Visualization > Mashups.   Click + New.   Keep the defaults and click OK.   In the Name field, type pump-dashboard. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. Click Save.   At the top, click Design.   Define Mashup Areas   At the top-left, ensure the Layout tab is selected. Click Add Bottom to split your UI into two halves.   Click the newly-created bottom-half to select it. Click Add Left.   Click the bottom-left container to select it. In the top-left Layout section, scroll down and select Fixed Size.   Type 200 in the Width text box that appeared, then press your keyboard’s Tab key to record your entry.   Add Widgets   In the top-left, click the Widgets tab.   In the Filter field, type image.   Drag-and-drop an Image Widget onto the lower-left area of the central Canvas. This Widget will show an image of the pump in use. 4. In a similar manner to what was just done with the Image Widget, drag-and-drop a Value Display Widget onto the top area. 5. Likewise, drag-and-drop a Line Chart Widget onto the lower-right area.   6. Click Save.          Click here to view Part 2 of this guide. 

    Step 5: Log to Value Stream   Now that you have explored the Properties of IndConn_Tag1, you’ve seen how ThingWorx Kepware Server feeds information to ThingWorx Foundation. To get an even better indication of changes and confirm continued connectivity, we will log the changes to a Value Stream in order to record the values with a TimeStamp.   Create Value Stream   Return to the ThingWorx Foundation New Composer browser. Click Browse. Click Data Storage -> Value Streams. Click + New. In the Choose Template pop-up, select ValueStream. Click OK. Type IndConn_ValueStream in the Name field. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. In the Description field, enter an appropriate description, such as Value Stream to record changes from ThingWorx Kepware Server. Click Save.   Bind Value Stream   Open the IndConn_Tag1 either by clicking on the tab at the top, or by clicking on PTCDefaultProject on the left At the top, select General Information. In the Value Stream field, enter indconn. Select IndConn_ValueStream from the sorted list. At the top, select Properties and Alerts. Click Simulation_Examples_Functions_Random3. A new set of options will expand from the right. Check the box for Persistent. Check the box for Logged. Click the Check button to close the expanded options. Click Save. All changes to the Random3 Tag, fed from ThingWorx Kepware Server, are now stored and TimeStamped in the Simulation_Examples_Functions_Random3 Property.   Step 6: Visualize the Data   We'll now create a Mashup to visualize the record of information from ThingWorx Kepware Server. In ThingWorx Foundation's Browse, click Visualization -> Mashups. Click +New. In the New Mashup pop-up, leave the default selections. Click OK. In the Name field, enter IndConn_Mashup. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. At the top, click Save. At the top, click Design. In the Filter Widgets field at the top-left, enter chart. Drag-and-drop a Line Chart onto the central canvas area. Add Data   On the right-side of the Mashup Builder, click the Data tab. Click the + button on the Data tab.        3. In the Add Data pop-up, enter indconn in the Entity field, overwriting Filter. 4. Select IndConn_Tag1 from the sorted list. 5. In the Filter field below Services, enter queryprop. 6. Click the right arrow button beside QueryPropertyHistory. The QueryPropertyHistory Service of the IndConn_Tag1 Thing will appear on the right in the Selected Services field. 7. Check the box under Execute on Load in the Selected Services field.' 8. Click Done. Note that the QueryPropertyHistory Service now appears on the right side Data tab. 9. Click the arrow to expand QueryPropertyHistory, then click to expand Returned Data. 10. Drag-and-drop All Data from the QueryPropertyHistory Service from the right onto the Time Series Chart in the center. 11. In the Select Binding Target pop-up, select Data.        Configure Chart Properties   In the bottom-left Properties of timeserieschart-1, enter xaxisfield in the Filter Properties field. Expand the drop-down for XAxisField. Select timestamp. Click Save. Click View Mashup. (You may have to enable pop-ups to view the mashup.) The IndConn_Mashup will show you the recorded history of property changes that came from ThingWorx Kepware Server. NOTE: If the Mashup visualization is blank, confirm your connection to IndConn. Return to the Test Connection section of the Bind Industrial Tag step.   Step 7: Next Steps   Congratulations! You've successfully completed the Connect Kepware Server to ThingWorx Foundation guide. You've learned how to: Connect ThingWorx Foundation to ThingWorx Kepware Server Map Tags to Properties     The next guide in the Connect and Monitor Industrial Plant Equipment learning path is Create Industrial Equipment Model. 

Configure Permissions Guide Part 2   Step 5: Permissions   These permissions can be accessed on any Entity created on the platform. All Entities have permission control for both design time and run time. Permission Time Control Design time Controls what Users are able to do with Entities themselves while building the solution. Run time Controls what the Users are able to do with the data for an Entity when they use the solution.   Permission Type Description Property Read Read property values Property Write Update property values Service Execute Execute Services in this Entity Event Execute Queue or fire Events in this Entity Event Subscribe Ability to subscribe to Events in this Entity   Access Type Description Allow Allow the User's access to this feature. Deny Deny the User's access to this feature. Inherit Set the User's access to this feature based on permissions in Entities this Entity is based on or the configurations at a higher level.   Add Permissions for an Entity   Once an Entity has been selected for editing, select the Permissions tab. Based on what you would like to edit, select the Visibility, Design Time or Run Time tab. The All Properties, Services, and Events section provides blanket security to all of these features for a User Group or User. The Property, Service, or Event Overrides section is used for any overrides that need to be made for specific features. In the example blow, the User a.jones has the ability to read properties, fire events, and subscribe to events. The User does not have the ability to update a property or execute a Service. In the second section, a.jones is allowed to call the GetConfigurationTable Service (even though he was restricted from doing so in the other section).   To set a permission, filter and select a User/User Group. When their name is in the table, click the Permission Type you would like for this Entity. Default permissions are added to the User or User Group you filtered and selected. This will be full access permissions unless you've changed one of the fields.   Set Permissions Programmatically   In some cases it will be useful to set permissions using a programmable interface. This can be done through a built-in set of services which can be accessed in many different ways including: Internal service call through an entity’s service Service call using the extension framework, or REST API call to a service on the platform. The following is a list of services built into all entities on the platform. Service Name Description AddDesignTimePermission Adds a new design time permission AddRunTimePermission Adds a new run time permission CheckDesignTimePermission Checks to see if an entity has a specific design time permission for the current User CheckDesignTimePermissionForGroup Checks to see if an entity has a specific design time permission for a given User Group CheckDesignTimePermissionForUser Checks to see if an entity has a specific design time permission for a given User CheckPermission Checks to see if the entity has a specific run time permission for the current User CheckTimePermissionForGroup Checks to see if the entity has a specific run time permission for a given User Group CheckDesignTimePermissionForUser Checks to see if the entity has a specific run time permission for a given User DeleteDesignTimePermission Delete a design time permission DeleteRunTimePermission Delete a run time permission GetDesignTimePermission Get a list of design time permissions in Info Table format GetDesignTimePermissionAsJSON Get a list of design time permissions in JSON format GetPermissionsForCurrentUser Get the run time permissions for the current User GetPermissionsForGroup Get the run time permissions for a given User Group GetPermissionsForUser Get the run time permissions for a given User GetRunTimePermissions Get a list of assigned run time permissions in Info Table format GetRunTimePermissionAsJSON Get a list of assigned run time permissions in JSON form SetDesignTimePermissionAsJSON Sets all of the run time permissions for a given Entity to the given JSON list You may want to apply a set of permissions to a large group of Entities at once. This can be done using either the projects or the tags feature on the platform through the EntityServices resource. The EntityServices resource has many useful services in it, but for the purpose of this section, we will only talk about the run time permission service. This will act on all entities with the provided tags or assigned to the given project. Service Name Description SetEntityPermission Sets run time permissions for a set of Entities   Step 6: Application Keys   Application Keys   Application Keys or appKeys are security tokens used for authentication in ThingWorx when not using a standard credentials method of authentication. They are associated with a given user and have all of the permissions granted to the user to which they are associated.   Create an Application Key   Using the Application Key for the default user (Administrator) is not recommended. If administrative access is absolutely necessary, create a user and place the user as a member of the SecurityAdministrators and Administrators user groups. Create the User the Application Key will be assigned to. On the Home screen of Composer click + New. In the dropdown list, click Applications Keys. Use MyAppKey  for the name your Application Key. Set the User Name Reference to a User you created and set the Project field (ie, PTCDefaultProject). The Expiration Date field will default to 1 day. Click Save. A Key ID has been generated and can be used to make secure connections.   IP Whitelisting for Application Keys   One of the features of an Application Key is the ability to set an IP whitelist. This allows the server to specify that only certain IP addresses should be able to use a given Key ID for access. This is a great way to lock down security on the platform for anything that will maintain a static IP address. For example, connected Web-based business systems may have a static IP from which all calls should be made. Similarly, you can use wildcards to specify a network to narrow the range of IP addresses allowed while still offering some flexibility for devices with dynamic IP addresses. Extremely mobile devices should likely not attempt to implement this however as they will often change networks and IP addresses and may lose the ability to connect when the IP whitelist feature is used.   Interact with Application Keys Programmatically   Service Name Description GetKeyID Returns the ID of this application key GetUserName Get the user name associated with this application key IsExpired Returns if this application key is expired ResetExpirationDateToDefault Resets the expiration date of the application key to the default time based on configuration in the UserManagement subsystem SetClientName Sets the client name for this application key SetExpirationDate Sets the expiration date of this application key to a provided date SetIPWhiteList Sets the values for the IP whitelist for this application key SetUserName Sets the associated user name for this application key TIP: To learn more about Application Keys, refer to the Create an Application Key Guide.   Step 7: Organizations   Organizations are hierarchical structures that allow the user to assign visibility to entities in the ThingWorx Model. This model provides the top down structure from the highest level in an organization or department, to the lower levels of said entity. Each level within this structure also allows for users and groups to be added. This provides a greater level of customization to resources within the ThingWorx Composer.   Create an Organization In the ThingWorx Composer, click the + New at the top of the screen. Select Organization in the dropdown. Name your Organization Constructors. Set the Project field (ie, PTCDefaultProject) and click Save Select the Organization tab to see the hierarchy. With the top organization selected, in the Members search bar, search for the user you have created yourself and add them.   Create Organizational Units   Click the green + under the structure you would like to expand. Name your Organization unit UpperManagement. In the Members search bar, search for the user or user group you created and add it. Click Save. Repeat the steps to create the full heirarchy of the organization and its department/unit members.   Setup Entity Visibility   ThingWorx provides added security checks and access control with Entity visibility. Visibility ensures an entity is accessible to members of an organizational unit. Those members will then have access to the entity and the underlying security model determines what specific interaction any users that are members of that organization unit may have with a specific asset. If a user in the system is not granted visibility, then that asset essentially does not exist within that user’s domain. Select the Permissions tab of any custom Thing in Composer. Filter and select Constructors in the Search Organizations field. Click Save. Login Pages for Organization   Creating an Organization automatically creates a login page for you. If you would like to add more to this login screen and customize it to fit your needs, create a Mashup and set it to the Organization's Home Mashup field. If you plan to use a Login Screen, use the View Mashup URL generated from the Login Mashup you create. To view the login page of your application (whether custom or default), type the following URL: [server]/Thingworx/FormLogin/ (ie, localhost/Thingworx/FormLogin/Constructors).     Step 8: Next Steps   Congratulations! You've successfully completed the Configure Permissions guide, and learned how to: Configure and utilize the user access system Control permissions at design time and run time   The next guide in the Getting Started on the ThingWorx Platform learning path is Build a Predictive Analytics Model.    If you are completing the Connect and Configure Industrial Devices and Systems learning path, the next guide is Choose a Connectivity Method.   Learn More   We recommend the following resources to continue your learning experience: Capability Guide Build Design Your Data Model   Additional Resources   If you have questions, issues, or need additional information, refer to: Resource Link Support Help Center    

Connect Kepware Server to ThingWorx Foundation Guide Part 1   Overview   This guide has step-by-step instructions for connecting ThingWorx Kepware Server to ThingWorx Foundation. This guide will demonstrate how easily industrial equipment can be connected to ThingWorx Foundation without installing any software on production equipment. NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete ALL 2 parts of this guide is 30 minutes.    Step 1: Learning Path Overview     This guide explains the steps to connect ThingWorx Kepware Server with ThingWorx Foundation and is part of the Connect and Monitor Industrial Plant Equipment Learning Path. You can use this guide independently from the full Learning Path. If you want to learn to connect ThingWorx Kepware Server to ThingWorx Foundation, this guide will be useful to you. When used as part of the Industrial Plant Learning Path, you should have already installed ThingWorx Kepware Server and created an Application Key. In this guide, we will send information from ThingWorx Kepware Server into ThingWorx Foundation. Other guides in this learning path will use Foundation's Mashup Builder to construct a website dashboard that displays information and from ThingWorx Kepware Server. We hope you enjoy this Learning Path.   Step 2: Create Gateway   To make a connection between ThingWorx Kepware Server and Foundation Server, you must first create a Thing. WARNING: To avoid a timeout error, create a Thing in ThingWorx Foundation BEFORE attempting to make the connection in ThingWorx Kepware Server. In ThingWorx Foundation Composer, click Browse. On the left, click Modeling -> Things.   Click + NEW. In the Name field, enter IndConn_Server, including matching capitalization. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. In the Description field, enter an appropriate description, such as Industrial Gateway Thing to connect to ThingWorx Kepware Server.   In the Base Thing Template field, enter indus, then select the IndustrialGateway Thing template from the sorted list. Click Save.   Step 3: Connect to Foundation   Now that you’ve created an IndustrialGateway Thing and an Application Key, you can configure ThingWorx Kepware Server to connect to ThingWorx Foundation. Return to the ThingWorx Kepware Server Windows application. Right-click Project. Select Properties….       4. In the Property Editor pop-up, click ThingWorx.       5. In the Enable field, select Yes from the drop-down.       6. In the Host field, enter the URL or IP address of your ThingWorx Foundation server, Do not enter http://       7. Enter the Port number. If you are using the "hosted" Developer Portal trial, enter 443. 8. In the Application Key field, copy and paste the Application Key you just created. 9. In the Trust self-signed certificates field, select Yes from the drop-down. 10. In the Trust all certificates field, select Yes from the drop-down. 11. In the Disable encryption field, select No from the drop-down if you are using a secure port. Select Yes if you are using an http port. 12. Type IndConn_Server in the Thing name field, including matching capitalization. 13. If you are connecting with a remote instance of ThingWorx Foundation and you expect any breaks or latency in your connection, enable Store and Forward. 14. Click Apply in the pop-up. 15. Click Ok. In the ThingWorx Kepware Server Event window at the bottom, you should see a message indicating Connected to ThingWorx.   NOTE: If you do not see the "Connected" message, repeat the steps above, ensuring that all information is correct. In particular, check the Host, Port, and Thing name fields for errors.   Step 4: Bind Industrial Tag   Now that you've established a connection, you can use ThingWorx Foundation to inspect all available information on ThingWorx Kepware Server. ThingWorx Kepware Server includes some information by default to assist you with verifying a valid connection with ThingWorx Foundation. Create New Thing Return to ThingWorx Foundation. Click Browse. Click Modeling -> Industrial Connections.   Click IndConn_Server. At the top, click Discover.   The Discover option is exclusive to Things inheriting the IndustrialGateway Thing Template and displays information coming from ThingWorx Kepware Server. Expand Simulation Examples. Click Functions.   On the right, you’ll see several pre-defined Tags to assist with connectivity testing. Click the checkbox next to Random3. Click Bind to New Entity.   In the Choose Template pop-up, select RemoteThing and click OK.   Finalize New RemoteThing   You’ll now be in an interface to create a new Thing with a predefined Property based on ThingWorx Kepware Server Tag1. Type IndConn_Tag1 in the Name field. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. In the Description field, enter an appropriate description, such as Thing with a property fed from an Kepware Server Tag. The Base Thing Template has been automatically set to RemoteThing. The Implemented Shapes has been automatically set to IndustrialThingShape. 4. Click Save.   Test Connection   The IndConn_Tag1 Thing you created now has a Property with a value that will change with each update from ThingWorx Kepware Server. The Tag1 we utilized is a 'ramp' and therefore, the value will increase at regular intervals. At the top, click Properties and Alerts. Under Inherited Properties, you will see entries for both RemoteThing and IndustrialThingShape. The Property isConnected is checked, indicating a connection from Foundation to ThingWorx Kepware Server. The Property IndustrialThing has been automatically set to IndConn_Server. Notice the predefined Property named Simulation_Examples_Functions_Random3.   Click Refresh repeatedly. You’ll see the value increase with each Refresh. This represents data being simulated in ThingWorx Kepware Server. Click  here to view Part 2 of this guide.  

  How to Display Data in Charts Guide Part 3   Step 6: Configure Charts   You now have a test Thing that has an Info Table Property and Time Series Property with values appropriate for display in various Chart Widgets, as well as a Mashup with those charts inside. However, in order for the Widget to display data, you need to bind it to the data source.   Bring Data into the Mashup   Select the Data tab in the top-right section of Composer.   Click the green + button under Data.   In the Entity Filter field, search for and select DDCThing. In the Services Filter field, type GetProperties. Click the right-arrow beside GetProperties The GetProperties Service will now appear on the right under Selected Services. Check the Execute on Load box under Selected Services. This will cause the GetProperties Service to execute as soon as the Mashup is loaded.   6. In the Services Filter field, type QueryPropertyHistory. 7. Click the right-arrow beside QueryPropertyHistory. 8. Check the Execute on Load box under Selected Services. 9. Click Done to close the Add Data pop-up window.   Drag-and-Drop Data Bindings   Under the Data tab, expand the Things_DDCThing > GetProperties service.   Drag GetProperties > InfoTableProperty to the Pie Chart Widget in the top-left section of the Canvas.           3. On the Select Binding Target pop-up, select Data. 4. Repeat steps 2-3 for the Label, Proportional, and Bubble charts. Note that the Bubble chart will be bound to DataSource1 rather than Data.     5. Drag-and-drop QueryPropertyHistory > Returned Data > All Data to the Line Chart Widget in the bottom-middle section of the Canvas. 6. On the Select Binding Target pop-up, select Data. 7. Repeat steps 5-6 for the Event Chart in the bottom-right of the Canvas.   Configure Chart Properties   Click the Pie Chart in the top-left of the Canvas to select it. In the bottom-left section of Composer, showing the Properties of the Pie Chart, type LabelField in the Filter Properties field. For the LabelField drop-down, select Label.   In the Filter Properties window, type ValueField. In the ValueField drop-down, select Value.       Repeat steps 1-5 for each of the other charts, making the following Widget Property changes: Chart Property Setting Label XAxisField XAxis Label DataField1 Data Proportional XAxisField XAxis Proportional DataField 1 ASensor Proportional DataField 2 BSensor Proportional DataField 3 CSensor Bubble XAxisField1 XValue Bubble YAxisField1 YValue Bubble BubbleValueField1 BubbleValue Line XAxisField timestamp Event XAxisField timestamp Event LabelField TimeSeriesProperty 7. At the top, click Save. 8. Click View Mashup.     Step 7: Next Steps   Congratulations!  In this guide, you learned how to:   Create a Data Shape to format an Info Table Create a Value Stream to record Property Value changes Create a Thing with an Info Table Property and a Time Series Property Create a Mashup with various Chart Widgets Link your Thing's Properties to the Chart Widgets   This is the last guide in the Customize UI and Display Options to Deploy Applications learning path.    Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Widget Help Center    

  Basic Mashup Widgets Guide Part 2    Step 3: Slider   A Slider allows your application users to interactively select a numeric value. When the user changes the position of the slider bar, an event is fired and the value property is changed. On the New Mashup tab, enter slider inside the Filter field in the top left. Drag-and-drop the Slider widget onto the top-right Container of your Mashup. 3. In the lower panel of the left dock, scroll to the Maximum property and change the value to 1000. 4. Change the Value property to 500 set the default position of the slider.   Add Value Display To demonstrate the Slider functionality we will add a Value Display Widget within the same Container of your Mashup as the Slider and bind the slider widget output to the input of the Value Display.         1. In the Filter field where you entered slider, enter value.        2. Drag-and-drop a Value Display widget onto the same upper-right Container as the Slider widget. 3. Click the drop-down arrow on the left side of the Slider widget. 4. Click and drag the Value property listed in the Slider drop-down onto the Value Display widget. 5. Click the Data property that is available from the Select Binding Target pop-up. 6. Click Save to save your Mashup. 7. Click View Mashup then adjust the slider to see the changing value shown in the Value Display widget.             Many properties are available that give control over how a Slider widget will be displayed. Properties can be changed both statically when designing the Mashup, and dynamically in response to changes in property values.   Bindable Name Type Default Direction Description Value Number 0 Input/Output Value defined by position of Slider that can be used by downstream widgets or services Minimum Number 0 Input/Output Value for left-most position of Slider, bottom-most position of Vertical Slider Maximum Number 100 Input/Output Value for right-most position of slider, top-most position of Vertical Slider HandleSize Number 34 Input Size in pixels of the slider handle Visible Boolean True Input Widget is visible if set to true StepSize Number 1 Input Smallest change in value when slider is moved   Static Name Type Default Direction DisplayName String None Name used for widget in user-facing interactions Description String None Description used for widget in user-facing interactions HandleIcon None/Circle/Split Circle Slider handle style SliderBar Thick/Thin Thick Slider bar style SteppingMode Boolean False When True, moves the slider by Step amount toward the click on the Slider bar TrackingMode Boolean False When True, the slider generates events as it changes value. Use with caution, this mode generates many events rapidly. DisplayMinMaxLabels Boolean True When enabled, displays the minimum and maximum values of the slider DisplayValueLabel Boolean True When enabled, displays the value of the slider   Widget Events Name Description ValueChanged Fired when Slider Value changes   Widget Services Name Description Increment Increase value of Slider by Step amount Decrement Decrease value of Slider by Step amount     Step 4: Toggle Button   A Toggle Button widget is used when a Mashup user may select only one choice from two options. On the Widgets tab in the top-left, enter button in the Filter field. Drag-and-drop the Toggle Button widget onto the lower left container of the mashup.   Scroll to the State property in the lower panel of the left dock where Toggle Button widget properties are shown. Click the check box to set the default state to true.   Add Value Display To demonstrate the toggle Button, we will add a Value Display Widget to the same Mashup container and bind the toggle Button State property to be shown by the Value Display. Drag-and-drop a Value Display Widget onto the same lower left container of the Mashup where the Toggle Button was placed. Click the drop-down arrow on the left side of the Toggle Button Widget. Click and drag the State property listed in the drop-down onto the Value Display Widget and a Select Binding Target pop-up will appear.  Click the Data property that is available from the Value Display Widget. Click Save to save your Mashup so it can be tested. Click View Mashup then click the Toggle Button to see the value of the button shown in the Value Display Widget.   Other properties are available to provide control over how a Toggle Button Widget will be displayed. Properties can be changed both statically when designing the Mashup, and dynamically in response to changes in property values.   Bindable Name Type Default Direction Description State boolean false Input/Output Value of toggle, can be used by downstream Widgets or Services Label String None Input Text that is displayed next to toggle button Visible Boolean True Input Widget is visible if set to true   Static Name Type Default Description DisplayName String auto-generated Name used to identify Widget in Mashup Builder Description String None Description used for Widget in user-facing interactions Height number autosize Sets the height of the widget in pixels LabelAlignment Left/Right Left Where label is shown relative to toggle button   Widget Events Name Description StateChanged Fired when user clicks the button   Click here to view Part 3 of this guide.

Basic Mashup Widgets Guide Part 1    Overview   This project will introduce how to use some basic Widgets in a Mashup. Following the steps in this guide, you will create a Mashup that reacts to user input using a Button, Toggle Button, and Slider Widget. We will also teach you how to display data to users with the Grid Advanced, Gauge, and Property Display widgets. NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete ALL 3 parts of this guide is 60 minutes.    Step 1: Create Mashup   Build Mashup Click the Browse folder icon on the top left of ThingWorx Composer. Select Mashups in the left-hand navigation, then click + New to create a new Mashup.        3. For Mashup Type select Responsive. NOTE: A Responsive Mashup scales with a browser’s screen size. In the steps below we will create 5 containers, one for each widget, to organize how the widgets are presented.          4. Click OK. 5. Enter a name for your Mashup. 6. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. 7. Click Save. 8. Select the Design tab to display Mashup Builder. 9. Select the Layout tab in the upper panel of the left dock. 10. Click Add Bottom to split the Mashup canvas into two halves. 11. Click inside the bottom container to selected it, then click Add Left. 12. Click inside the bottom-right container to select it, then click Add Right. 13. Click inside the top container to select it, then click Add Right again. You should now have 5 containers in two rows, ready to have widgets added.   Step 2: Button   A button allows users to trigger an action, or stop and start long-running processes. Select the Widgets tab in the uppper panel of the left dock, then enter button inside the Filter field in the top-left. Drag-and-drop the Button widget onto the upper left container.        3. Click the drop-down arrow on the left side of the Button widget. 4. Click and drag the Clicked service shown in the drop-down onto a free area of the Mashup canvas.         5. When the Select Service pop-up appears, Click the ResetInputsToDefaultValues service that is provided by the Container. 6. Click Save. 7. Click View Mashup then click Show/Hide Debug Info. 8. Click the Trace tab and click Start Trace. 9. Click the button you created in your Mashup then click Stop Trace to see the log of the Clicked event triggering the ResetInputsToDefaultValues service.   Many properties are available that give control over how a Button widget will be displayed. Many properties can be changed both statically when designing the Mashup, and dynamically in response to changes in property values.   Bindable Name Type Default Direction Description ContextId String None Input/Output User-definable value that can be used by downstream triggered widgets Disabled Boolean False Input Widget is not usable and is displayed greyed-out if set to true Label String Button Input The text that appears on the button ToolTipField String None Input Text shown when user hovers over widget Visible Boolean True Input Widget is visible if set to true CustomClass String None Input/Output User-definable CSS class applied to top di of the button   Static Name Type Default Direction DisplayName String auto-generated Descriptor used for referring to widget in Composer and Mashup Builder Description String None Description used for widget in user-facing interactions TabSequence Number 0 Tab sequence index Height Number Autosize Height of button Width Number Autosize Width of button Z-index Number 10 Controls widget placement on top or below other widgets   Widget Events Name Description Clicked Fired when user clicks button   Click here to view Part 2 of this guide. 

  Create An Application Key Guide   Overview   In order for a device to send data to the Platform, it needs to be authenticated. One authentication method is to use an Application Key. Application Keys, or appKeys, are security tokens used for authentication in ThingWorx. They are associated with a given User and have all of the permissions granted to the User with which they are associated. This is one of the most common ways of assigning permission control to a connected device. NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 30 minutes.    Step 1: Learning Path Overview   This guide explains the steps to create a ThingWorx Application Key, and is part of a Learning Path. You can use this guide independently from the full Learning Path. If you want to learn to create a ThingWorx Application Key, this guide will be useful to you. When used as part of the Industrial Plant Learning Path, you should already have installed ThingWorx Kepware Server. We will use the Application Key to send information from ThingWorx Kepware Server into ThingWorx Foundation. Other guides demonstrate Foundation's Mashup Builder to construct a website dashboard that displays information from ThingWorx Kepware Server. We hope you enjoy this Learning Path.   Step 2: Create Application Key   Application Keys are assigned to a specific User for secure access to the platform. Using the Application Key for the default User (Administrator) is not recommended. If administrative access is absolutely necessary, create a User and place the User as a member of the SecurityAdministrators and Administrators User groups. Create the User the Application Key will be assigned to. 1. On the Home screen of Composer click + New. 2. In the dropdown list, click Applications Key. 3. Give your application key a name (i.e. MyAppKey). 4. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. 5. Set the User Name Reference to a User you created. 6. Update the Expiration Date field, otherwise it will default to 1 day. 7. Click Save. A Key ID has been generated and can be used to make secure connections.   IP Whitelisting for Application Keys   One of the features of an Application Key is the ability to set an IP whitelist. This allows the server to specify that only certain IP addresses should be able to use a given Key ID for access. This is a great way to lock down security on the platform for anything that will maintain a static IP address. For example, connected Web-based business systems may have a static IP from which all calls should be made. Similarly, you can use wildcards to specify a network to narrow the range of IP addresses allowed while still offering some flexibility for devices with dynamic IP addresses. Extremely mobile devices should likely not attempt to implement this, however, as they will often change networks and IP addresses and may lose the ability to connect when the IP whitelist feature is used.   Interact with Application Keys Programmatically Service Name Description GetKeyID Returns the ID of this Application Key GetUserName Get the username associated with this Application Key IsExpired Returns if this Application Key is expired ResetExpirationDateToDefault Resets the expiration date of the Application Key to the default time based on configuration in the UserManagement subsystem SetClientName Sets the client name for this Application Key SetExpirationDate Sets the expiration date of this Application Key to a provided date SetIPWhiteList Sets the values for the IP whitelist for this Application Key SetUserName Sets the associated user name for this Application Key   Tip: To learn more about Application Keys, refer to the Help Center   Step 3: Next Steps   Congratulations! You have successfully created an application key. We hope you found this guide useful.     The next guide in the Connect and Monitor Industrial Plant Equipment learning path is Install ThingWorx Kepware Server.    The next guide in the Azure MXChip Development Kit learning path is Connect Azure IoT Devices.   The next guide in the Medical Device Service learning path is Use the Edge MicroServer (EMS) to Connect to ThingWorx.   The next guide in the Using an Allen-Bradley PLC with ThingWorx learning path is Model an Allen-Bradley PLC.

Introduction With ThingWorx 10.1, we're excited to announce MQTT support for IoT streams for data egress as Private Preview. This is a significant value add that allows ThingWorx to continue to be used as a DataOps layer for end-to-end industrial data management. With its ability to ingest data from disparate sources, contextualize and transform it, and send data in a custom-defined format over Kafka, and now MQTT, ThingWorx enables real-time consumption of data by end applications, allowing necessary interoperability without the worry of data lock-in. Especially in the age of AI, customers can use ThingWorx not only to ingest data from connected machines, systems, and people but also to push processed, contextualized, AI-ready data outward. This enables external systems, data lakes, cloud systems, or UNS layers to consume the data in real time, making IT/OT convergence seamless. With this capability, having a Sparkplug B connector built in, users can use ThingWorx to directly load contextualized data onto MQTT brokers that is transformed into Sparkplug B format, helping them achieve their goals for establishing a decoupled, modular, and modern manufacturing architecture allowing complete access and traceability of their own data. Modern Manufacturing Architecture   Built for Reliability and Scale MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe protocol designed for IoT efficiency. The ThingWorx 10.1 implementation uses the Durable Queue Framework, the same foundation behind IoT Streams, to ensure reliable message delivery even under network fluctuations. Developers can configure MQTTQueueProviders to define topics and manage data publishing with minimal setup. Each queue can dynamically format its topic names, ensuring scalable routing for multiple devices or templates. The system supports both MQTT 3.1.1 and 5.0 for broad compatibility. Seamless Setup, Strong Integration New ThingWorx entities such as SparkplugBQueueProvider, SparkplugBDevice ThingShape, and related services simplify setup and connection management. Administrators can create and associate IoT Streams with MQTT queues in a few clicks, route property updates to external topics, and monitor connection health directly within Composer. This unified workflow makes it easy to connect ThingWorx data to external analytics systems, industrial data lakes, or cloud-based applications using low-code tools from ThingWorx. Adding Structure with Sparkplug B Beyond raw MQTT data, ThingWorx now supports Sparkplug B, an open industrial data specification that brings structure and state awareness to MQTT communications. Sparkplug B defines a common topic format and uses birth and death messages to indicate device lifecycle events, ensuring that systems always know which devices are online or offline. Payloads are serialized using Protocol Buffers (Protobuf) for lightweight, high-performance communication, making it ideal for bandwidth-constrained environments. Together, these enhancements position ThingWorx as both a data receiver and publisher, a core participant in UNS-aligned ecosystems where structured MQTT data flows freely across IT and OT systems, simplifying IT/OT convergence. Feature Summary   Capability Description MQTT Publishing Send Thing property data to brokers like HiveMQ or Mosquitto. Sparkplug B Support Structured MQTT with standardized topics and lifecycle management. Durable Queue Integration Ensures reliable, ordered message delivery. New Queue Providers MQTTQueueProvider and SparkplugBQueueProvider for outbound data. Unified Namespace Alignment Enables ThingWorx to act as a UNS-compliant data source. Join the Private Preview The MQTT Egress capability extends ThingWorx interoperability beyond ingestion, allowing contextualized data to be shared across the enterprise or to the cloud. You can now join the Private Preview to gain early access to this key building block of the future UNS-enabled ThingWorx ecosystem and contribute feedback that helps shape its evolution. To understand what Private Preview means in ThingWorx, check this overview here Vineet Khokhar Principal Product Manager, IoT Security Stay tuned for more updates as we approach the release of ThingWorx 10.1, and as always, in case of issues, feel free to reach out to <support.ptc.com>

Hello ThingWorx community!   I’d like to invite you to join me and our ThingWorx experts for an exclusive webinar on October 30 at 11:00 AM (EDT) to explore the transformative potential of Agentic AI within the ThingWorx Industrial IoT and AI platform. In this session, you’ll gain insights into ThingWorx’s AI strategy, focused on delivering actionable intelligence and accelerating digital transformation across the product lifecycle. You’ll also see in action: Hands-on demos integrating Large Language Models (LLMs) with ThingWorx 10.X How to enable agentic automation using Model Context Protocol (MCP) Ways to enhance industrial apps with real-time decisions, natural language, and computer vision AI So, register here:   [Webinar]: ThingWorx Innovation With Industrial IoT and AI    Also, here is a personal video invitation message to you all!      Post webinar, please provide your feedback and comments below!    We look forward to having you join us!     Cheers, Ayush Tiwari Director Product Management  

Often when we think about monitoring an applications health, we look to performance metrics and observing changes over time.   However, when it comes to critical issues which need immediate attention, alerts setup on relevant ThingWorx logs are the way to notify Ops Teams of events.  Logs provide contextualised detail of an event that has occurred, allowing for triage and directing troubleshooting.   Let me illustrate an example: ThingWorx is a database application and requires that DB for proper function.  A log message indicating that the DB connection has been severed, and another one indicating that a connection to the database cannot be established immediately tells you that your problem is with the DB - right when it occurs, no analysis required.   Given this, here is a list of some log message substrings to use as examples to build out your own production system monitoring aimed at detecting common critical or high severity issues using your log management system (Splunk, Loki, DataDog, ElasticSearch, etc.).   ThingWorx Platform Apparent Deadlock org.postgresql.util.PSQLException: Connection to *:* refused Unable to write entry in stream Data store unknown error org.postgresql.util.PSQLException: Connection to *:* refused Error getting database connection Unable to connect to the PTC license server Unable To Initialize Entity Unable to persist metric Unable to persist entries Error executing batch Too many open files CRITICAL ERROR: EventRouter is over capacity OutofMemoryError Client timed out while waiting to acquire a resource (2,002) No connection Acquisition Attempt Failed Connection Servers io.vertx.core.VertxException: Thread blocked network unavailable Lost connection to platform Have any log messages that you've found that could be added here?  Post them in the comments and I'll add them to the list.  

Overview A global leader in chemical processing and industrial manufacturing, with a strong international footprint and multiple production sites worldwide, set out to transform its production ecosystem by adopting Industrial IoT (IIoT). The objective was to unify fragmented factory data, enable real-time analytics, and drive operational efficiency through AI-powered insights. Based on detailed use case documentation and architectural workshop findings, this reference architecture outlines a robust, scalable solution designed to integrate factory systems, deliver AI-supported insights in real time, and empower teams through self-service applications.   The solution leverages PTC’s ThingWorx suite—along with Microsoft Azure services and complementary technologies—to address key challenges in production, quality, and efficiency across engineering, manufacturing, and operations. About Beyond the Pilot series Use Case   A. Engineering – Process Optimization & Quality Control   Problem: Resolving Data Integration & Visibility Challenges   Customer’s engineering teams struggled with fragmented data across various factory systems, limiting their ability to analyze process performance and optimize production parameters. Without a unified data platform, engineers could not effectively compare historical and real-time machine center lining values, making it difficult to maintain consistent production quality.   Solution: Unified Data Integration & Advanced Process Analytics   The reference architecture establishes a central, cloud-based data platform that aggregates and correlates machine data from various sources in real time. By integrating OPC Aggregators and Kepware with Azure IoT Hub, factory data is ingested, processed, and made accessible via ThingWorx applications. Engineers can now visualize mechanical and digital process values, set dynamic thresholds, and receive alerts when deviations occur—ensuring precise process control and quality optimization.   Role of PTC Products:   PTC Kepware: Standardizes and integrates machine data from disparate factory systems, ensuring a seamless flow of real-time process variables. ThingWorx Platform: Provides a robust dashboard for analyzing centerlining data, visualizing production trends, and enabling data-driven decision-making. ThingWorx Digital Performance Management (DPM): Automates the identification of process inefficiencies, allowing engineers to fine-tune machine settings dynamically.   B. Manufacturing – Scrap Reduction & Production Efficiency   Problem: Enhancing Scalability and Reducing Operational Inefficiencies   Customer faced challenges in scaling its IIoT solution as new sensors and data sources were introduced. Traditional systems struggled with the increased volume of factory data, leading to slow system response times and ineffective real-time analytics. Additionally, manual process adjustments resulted in inconsistencies, contributing to increased scrap rates and wasted materials.   Solution: Cloud-Scalable Infrastructure with Real-Time Process Optimization   To address these issues, the architecture leverages Azure IoT Hub, Azure Data Explorer (ADX), and Influx DB to handle massive data streams and provide low-latency analytics. This ensures that production trends, environmental conditions, and machine parameters are continuously monitored and optimized in real time. Advanced machine learning models predict process inefficiencies, enabling operators to make automatic adjustments to reduce scrap and optimize yield.   Role of PTC Products:   ThingWorx Platform: Acts as the central command hub, enabling real-time decision-making based on factory data trends. ThingWorx Digital Performance Management (DPM): Uses historical data to provide AI-supported recommendations for reducing material waste and improving overall equipment effectiveness (OEE). PTC Kepware: Ensures reliable, high-speed data acquisition from sensors, production lines, and environmental monitoring systems, feeding critical information into ThingWorx for optimization.   C. Driving Digital Transformation & Quality Optimization   Problem: Lack of Digital Process Automation & AI-Powered Decision Making   Customer’s previous factory systems relied on manual reporting and fixed thresholds for process control, limiting the ability to detect and respond to process inefficiencies in real time. Operators needed a system that could provide intelligent, self-service applications with AI-driven recommendations for optimal production performance.   Solution: AI-Driven Automation & Dynamic Quality Control   The IIoT architecture integrates AI-powered predictive analytics to analyze deviations in real-time and suggest automatic machine adjustments. Real-time applications, customizable process recipes, and dynamic alerting systems empower production teams with actionable insights. By embedding self-service applications in ThingWorx, engineers and operators can fine-tune process settings and receive automated recommendations for improving quality and efficiency.   Role of PTC Products:   ThingWorx Platform: Serves as the central analytics hub, delivering AI-powered insights for continuous process improvement. ThingWorx DPM: Uses machine learning to correlate scrap rates with process variables, recommending changes that minimize waste and enhance quality. PTC Kepware: Captures real-time process data, ensuring that AI models receive accurate inputs for predictive analysis.   Customer’s digital transformation journey is now backed by a robust, PTC-powered IIoT ecosystem that delivers continuous improvement, higher production efficiency, and proactive maintenance capabilities—ultimately driving the future of smart manufacturing. Technical Architecture and Implementation Details   This section combines detailed technical descriptions with the overall reference architecture. It describes the core components, integration points, and implementation strategies that deliver a robust IIoT solution for the customer.   A. Architecture Overview Diagram       High-level architecture diagram for the final solution B. Detailed Technical Components     Component Role Key Features OPC Aggregators & Kepware Stream and bridge machine data from production, DEV, and QA environments to Azure IoT Hub for real-time processing in ThingWorx. Scalable ingestion; latency monitoring; secure device connectivity; segregated closed environments for DEV/QA. Azure IoT Hub Ingests and secures machine telemetry data for analytics. Centralized data ingestion; integration with Azure services. ThingWorx on VMs Hosts the core IIoT application that processes data, provides end-user applications, and manages workflows. High performance; disaster recovery via VM snapshots; enhanced security through Azure AD integration and SSL support. Managed PostgreSQL Provides high availability for persistent application data through replication and failover. Data redundancy; managed service benefits; automated backup and recovery. Azure Data Explorer / Influx DB Handles advanced analytics, timeseries visualization, and predictive insights for telemetry data. Real-time analytics; anomaly detection; cost-effective long-term storage. Monitoring & Logging Tools Ensure comprehensive observability and prompt incident response across all components. Real-time applications monitoring; alerting; centralized log aggregation. RESTful APIs Enable seamless integration with ERP systems, legacy data sources, and other IoT devices. Secure data exchange; standardized connectivity protocols.     C. User Personas   The success of this solution relies on a well-defined team of technical experts responsible for deployment and ongoing management:     Persona Key Responsibilities Plant Manager Oversee overall factory performance and use data insights for strategic decision-making Drive process improvements and efficiency Digital Transformation Lead Analyzes and prioritizes valuable use-cases for the business Implement IIoT solutions across factory operations and scale AI-driven automation and data analytics Ensure long-term digital innovation and adoption Operations Manager Oversee production lines and ensure efficiency and optimize machine settings based on real-time insights Troubleshoot and resolve process issues quickly Quality Assurance Engineer Monitor production quality in real time and ensure compliance with quality standards Reduce scrap and rework by addressing deviations early Maintenance Engineer Monitor equipment health and respond to alerts and perform predictive maintenance to prevent failures Minimize downtime through proactive repairs Software Engineer Develop and maintain IIoT backend and frontend systems and ensure seamless data integration and API connectivity Optimize system performance and scalability Cloud Architect Design and manage IIoT cloud infrastructure and ensure scalable and secure cloud deployments Optimize data storage and processing in the cloud Security Analyst Implement and monitor security measures for IIoT systems and conduct risk assessments and threat analysis Ensure compliance with cybersecurity standards DevOps Engineer Manage CI/CD pipelines for IIoT applications and automate deployments and infrastructure management Optimize system performance and reliability     NOTE : Although these personas were required, the needs were fulfilled by a team of only 4–5 developers effectively playing multiple roles. Outcome   Optimized Production Efficiency By unifying machine telemetry, process parameters, and historical trends, customer empowers engineers with real-time insights. AI-driven recommendations and automated adjustments replace trial-and-error, enabling precise, dynamic optimizations. Bottlenecks and inefficiencies are identified instantly, allowing rapid corrective actions for peak performance.   Reduced Waste & Enhanced Quality Real-time process optimization and automated quality control significantly reduce material waste and variability. The system detects deviations at the source, enabling instant adjustments and ensuring consistent product quality, minimizing scrap, rework, and compliance risks.   Seamless Data Visibility & Collaboration A centralized dashboard provides real-time access to critical metrics, eliminating fragmented reports and delays. Engineers and operators can compare production data across sites, standardize best practices, and drive continuous improvements across the network.   Future-Ready Innovation Beyond immediate gains, this IIoT transformation lays the foundation for scalable sensor integration, AI-driven automation, and advanced predictive analytics. It’s not just a solution for today—it’s a long-term framework for sustained digital innovation in smart manufacturing. This reference architecture is not just about solving today’s challenges—it establishes a long-term, adaptive framework that will continue to evolve, enabling our customer to remain at the forefront of smart manufacturing and industrial digitalization. Additional Information   This section provides further insights into the project implementation and future strategic direction.   Parameter Description Example/Notes Time to First Go-Live Estimated duration from project initiation to initial production deployment. Approximately 16 weeks Partner Involvement Key strategic and technical partners collaborating on the deployment. Microsoft, Ansys, and Deloitte were supporting the digital transformation initiative centered around ThingWorx. Customer Roadmap Future enhancements planned by customer, such as AI-based predictive analytics and further automation. An expansion to incorporate AI and advanced machine learning–driven insights is planned       Vineet Khokhar Principal Product Manager, IoT Security   Disclaimer: These reference architectures will be based on real-world implementation; however, specific customer details and proprietary information will be omitted or generalized to maintain confidentiality.   Stay tuned for more updates, and as always, in case of issues, feel free to reach out to <support.ptc.com>  

Hello ThingWorx'ers!   First off, we’re pleased to see the excitement around ThingWorx 10.0! Your feedback on features like the Debugger, Caching, and the Windchill Navigate View Work Instructions app has been fantastic. I’m especially amazed by the rapid adoption of IoT Streams over the past two months. I'm glad it’s delivering value!   Join us for an exclusive ThingWorx 10.0 Launch Webinar on September 9, 2025, at 11:00 AM EDT. We’ll dive into the latest features, including real-time IoT Streams, enhanced scalability, stronger security, and exciting AI updates that will power your Industrial IoT journey. Register now: ThingWorx 10.0 Webinar   After the webinar, we’d love to hear your thoughts! Share what you’re loving about 10.0 and any feedback you may have.     Keep pushing the boundaries of innovation!   Cheers, Ayush Director Product Management, ThingWorx