cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
Sort by:
    Step 4: Use Collection Widget   At this point, you have created the following   Entities:   A   Thing   with data stored in an   Info Table Property   (columns defined by a   Data Shape)   A base   Mashup   (containing Gauge, LED Display, and Text Field   Widgets) that displays an individual row of data from the table   Now, you need to use the   Collection Widget   to display this Mashup for   every row of data in the table.   On the ThingWorx Composer   Browse   tab, click   Visualization > Mashups,   + New              2. Keep the default of   Responsive   with no Templates chosen, and click   OK.        3. In the   Name   field, enter   cwht_collection_mashup              4. If Project is not already set, search for and select PTCDefaultProject.        5, Click   Save.        6. Click   Design               7.  On the top-left   Layout   tab, ensure that the default of   Positioning > Responsive   is selected.  You want the "base" Mashup to generally be   Static, while the "collection" Mashup should be   Responsive   to allow it to grow to an appropriate size.         8.  From the top-left  Widgets  tab, drag-and-drop a  Collection  Widget onto the central Canvas area.       Access Mashup Data Service   Click the   + icon   at the top-right to open the   Add Data   pop-up menu.               2. In the   Entity Filter   field, search for and select   cwht_thing.         3. In the   Services Filter   field, enter   getproperties.         4. Click the   right arrow   beside   GetProperties   to add the GetProperties Service to the right-side of the pop-up menu.         5. Click the   Execute on Load   checkbox             6. Click   Done   to close the pop-up menu. The GetProperties Service of the cwht_thing is now shown on the right under the Data tab.         7. On the top-right, expand   GetProperties.           8.  Drag-and-drop  GetProperties > infotable_property  onto the  Collection  Widget            9.  On the  Select Binding Target  pop-up, click  Data     Configure Properties   In the Collection Widget's   Filter Properties   field in the bottom-left, enter   mashup. This will limit the displayed Properties of the Collection Widget (in the bottom-left section) to only those containing the word "mashup".            2.  For the   Mashup   Property, search for and select   cwht_base_mashup.  Choosing "cwht_base_mashup" lets the Collection Widget know which base Mashup to repeat in every Cell               3. In the   MashupHeight   field, enter   250   and hit the   Tab   keyboard key to apply the change. This Property changes the height of each Cell of the Collection Widget. Ensure the height is large enough to fit all of the Widgets.          4. In the   MashupWidth   field, enter   500   and hit the   Tab   keyboard key.  This Property changes the width of each Cell of the Collection Widget. Ensure the is large enough to fit all of the Widgets.            5. In the   Filter Properties   field, enter   uidfield.          6. In the   UIDField   drop-down, select   first_number.  The UIDField sets the unique identifier for the Collection Widget.            7. In the   Filter Properties   field, enter   sort.          8. In the   SortField   drop-down, select   first_number.  SortField determines which sub-section of the Infotable to use for sorting purposes.          9. Check the   SortAscending   checkbox            10.  n the  Filter Properties  field, enter  mashupprop           11. Click   Add, copy-and-paste the following JSON into the   MashupPropertyBinding   Property, replacing the existing curly braces {}, then click   Done.   The point of this JSON is to relate the columns of the Infotable Property to the Mashup Parameters that we previously defined in the base Mashup. { "first_number" : "first_number" , "second_number" : "second_number" , "third_number" : "third_number" }                12. Click   Save, then   View Mashup.     Notice that the base Mashup we previously created has been replicated multiple times, corresponding to each row of the Info Table Property.   As an extension exercise, go back into   cwht_thing   and add another row of data. Refresh the   Collection Widget   Mashup to see another instantiation of the base Mashup automatically added to display that new row.   A Mashup utilizing the Collection Widget   dynamically expands   to accommodate both the user and the available data.   Step 5: Next Steps   Congratulations! You've successfully completed the   Organize Your UI   guide, and learned how to: Create a Datashape to define columns of a table Create a Thing with an Info Table Property Create a base Mashup to display data Utilize a Collection Widget to display data from multiple rows of a table Learn More   We recommend the following resources to continue your learning experience: Capability Guide Build Application Development Tips & Tricks Experience ThingWorx Application Development Reference   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource  Link Community Developer Community Forum Support Collection Widget Help Center  
View full tip
    Select the right database to use with your ThingWorx installation.   Guide Concept   When you develop an application with ThingWorx, you must save the configuration data that defines the data model and the user interface. You also need to store the dynamic data that is generated by devices at runtime (such as temperature or location).   ThingWorx uses the term Persistence Provider to refer to any type of service that saves application data, usually it is a database.   When your application moves into production you must choose and configure a Persistence Provider that meets your requirements.     You'll learn how to   Pros and cons of different databases that can be used as persistence providers for ThingWorx The database best suited to certain applications Where to find detailed information about the Persistence Providers   NOTE: The estimated time to complete this guide is 30 minutes       Step 1: Persistence Provider Options   There are many factors that will influence your decision for which Persistence Provider to use with your ThingWorx instance. On this page we compare and contrast different methods and provide examples for where each one is a natural fit.    Persistence Provider             Typical Use H2 Bundled with ThingWorx server for proof-of-concept trials PostgreSQL Standard production database for use up to 15,000 Property writes per second InfluxDB High volume data ingestion (>25,000 property writes per second) into one database Microsoft SQL Server SQL database available from Microsoft in a dozen different editions Azure SQL Server SQL database managed by Microsoft in Azure   When ThingWorx is installed with default configurations, it uses the embedded H2 database as its Persistence Provider. This configuration is suitable for evaluations and proof-of-concept applications with a limited number of Things. Before an application is used in production, you must provision a more capable persistence provider. The available options for Persistence Provider are summarized below.   H2   Pros                            Cons                     Typical Use Case                                DBA Skills       Required Cost No Database set-up required Not for use in production Start testing ThingWorx with no additional configuration None No additional cost   H2 is an open source, full-featured relational database that is embedded in the ThingWorx Foundation server. No additional database set-up is required before developing a proof-of-concept application with ThingWorx. Using H2 should provide satisfactory performance for applications with less than 1000 Things.   WARNING: Due to the inability to back-up and recover the database, H2 should never be used in production.   PostgreSQL    Pros                    Cons                        Typical Use Case                     DBA Skills               Required Cost Widely used database Requires some configuration Workhorse database appropriate for many applications Basic SQL skills No additional cost   PostgreSQL is the default choice for ThingWorx cloud hosting servers. It complies with many database standards and is open source with no extra license fee required. It can be configured for high availability to minimize the chance of down-time or data loss. It has been tested up to 15,000 property writes per second and depending on other factors may give satisfactory performance up to 25,000 writes per second.   Learn more about using PostgreSQL:   Using PostgreSQL as the Persistence Provider ThingWorx PostgreSQL Administrator's Guide   InfluxDB   Pros                      Cons                            Typical Use Case            DBA Skills Required           License Cost Handle high volume data ingestion InfluxDB is not supported as a Property provider Application requiring >25,000 Property writes/second Professional services likely required Multi-node requires license fee   If your system intensively deals with time series data and your implementation heavily depends on Value Streams or Streams for persistence/retrieval of data, we recommend using InfluxDB as the Persistence Provider in ThingWorx. InfluxDB is a high-performance data store written specifically for time series data and is a good choice when high volume data ingestion of more than 25,000 property writes per second must be saved into one database.   Learn more about InfluxDB:   Using InfluxDB as the Persistence Provider   Microsoft SQL Server   Pros                     Cons                       Typical Use Case                    DBA Skills                      Required Cost Available in multiple editions Only runs on Windows Data stored in Microsoft SQL Server Configure settings License fee required   More than a dozen different versions of Microsoft SQL Server are used by customers for workloads ranging from small single-machine applications to large enterprise applications. Connecting ThingWorx to an existing Microsoft SQL Server can make that data readily available to use in ThingWorx Mashups.   Learn more about using Microsoft SQL Server:   Using Microsoft SQL Server as the Persistence Provider Getting Started with MS SQL and ThingWorx   Azure SQL Server   Pros                                    Cons                        Typical Use Case              DBA Skills         Required Cost Cloud deployment and scaling No on-premise option Data stored in Microsoft SQL Server Configure settings Subscription required   Fully managed database service operated and updated by Microsoft Learn more about using Microsoft SQL Server:   Using Azure SQL Database as the Persistence Provider   Step 2: Next Steps   Congratulations! You've successfully completed the Compare Persistence Providers guide. At this point, you can make an educated decision regarding which Persistence Provider is best suited for your ThingWorx application development environment.   Learn More   We recommend the following resources to continue your learning experience:    Capability    Guide Connect ThingWorx Application Development Reference Build Get Started with ThingWorx for IoT Experience Create Your Application UI   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource        Link Community Developer Community Forum Support Microsoft SQL Technical Support Support Persistence Provider Help Center
View full tip
  Step 8: Troubleshooting   Issue                                       Resolution CSS does not seem to be applied to the Mashup. Verify your CSS is included in the runtime TWX CSS. Clear Browser cache if your CSS is not merged to the combined TWX CSS. (under debug mode: Hold refresh button->Clear Cache). TWX fails to import the extension. If the extension is already installed, but you made recent changes, you need to bump the Version number in the metadata.xml. Recent CSS changes are ignored. Clear browser cache if your CSS file has changed recently.     Step 9: Next Steps   Congratulations! You've successfully completed the   Add Style to Your UI with CSS   guide, and learned how to:   Create custom CSS classes using the integrated CSS editor Bind CSS classes to a Mashup and to individual Widgets Use Media queries to dynamically apply styling   Learn More   We recommend the following resources to continue your learning experience:    Capability     Guide Build Application Development Tips & Tricks Experience ThingWorx Application Development Reference   Additional Resources   If you have questions, issues, or need additional information, refer to:  Resource       Link Community Developer Community Forum Support Help Center
View full tip
    Learn how ThingWorx can be deployed in a clustered environment   Guide Concept   Web applications have increased reliability and performance by using a "pool" of independent servers called a cluster. It is important to understand what benefits the different methods of clustering provide, and what the different methods can mean for your system.   ThingWorx Foundation can be deployed in either an Active-Active clustered architecture or a standard single-server deployment. This guide describes the benefits of an Active-Active clustered architecture over other clustering methods and provides a system administrator with resources to navigate the different architecture options.     You'll learn how to   Overview of different server clustering techniques Pros and cons of the different clustering configurations that can be used with ThingWorx Where to find detailed information about ThingWorx server clustering   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 30 minutes       Step 1: Clustering Overview   Clustering is the most common technique used by web applications to achieve high availability. By provisioning redundant software and hardware, clustering software can automatically handle failures and immediately make the application available on the standby system without requiring administrative intervention.   Depending on the business requirements for High Availability, clusters can be configured in any of the following configurations:    Cluster Configuration           Description                                                                                       Recovery Time Cold Standby Software is installed and configured on a back-up server when the primary system fails. Hours Active-Passive A second server is provisioned with a duplicate of all software components and is started in case of failure of the primary server. Minutes Hot Standby Duplicate software is installed and running on both primary and secondary servers. The secondary server does not process any data when the primary server is functional. Seconds Active-Active Both the primary and one or more secondary servers are active and processing data in parallel. Data is continuously replicated across all running servers. Instantaneous   Cold Standby   ThingWorx installed in a default single-server configuration is not inherently a cold standby system. Periodic system backups can be used to bring the system back online in the event of system failure.   Note: A cold standby configuration does not constitute high availability   Active-Passive   High availability can be achieved with an Active-Passive configuration.     One “active” ThingWorx server performs all processing and maintains the live connections to other systems such as databases and connected assets. Meanwhile, in parallel, there is a second “passive” ThingWorx server that is a mirror image and regularly updated with data but does not maintain active connections to any of the other systems.   If the “active” ThingWorx server fails, the “passive” ThingWorx server is made the primary server, but this can take a few minutes to establish connections to the other systems.   Active-Active   ThingWorx uses Active-Active architecture for achieving high availability.   Active-Active configuration differs from Active-Passive in that all the ThingWorx servers in the cluster are “active.” Not only is data mirrored across all ThingWorx servers, but also all servers maintain live connections with the other systems. This way, if any of the ThingWorx servers fail, the other ThingWorx servers take over instantaneously with no recovery time.   Because all ThingWorx servers are active and processing data in parallel, the cluster can handle higher loads than the single running server in an Active-Passive configuration. An Active-Active deployment leverages the investment made in multiple servers by providing not only greater reliabilility, but also giving the ability to handle demand spikes. When server utilizations exceed 50%, customers can easily scale their deployment by adding more ThingWorx servers to the cluster - horizontally scaling. This also avoids the limitations of vertically scaling - provisioning a single server with more and more CPU cores and RAM.   Benefits of Active-Active Clustering   Higher Availability You can avoid single points of failure and configure the ThingWorx Foundation platform in an Active-Active cluster mode to achieve the highest availability for your IIoT systems and applications. Increased Scalability You can horizontally scale from one to many ThingWorx servers to easily manage large amounts of your IIoT data at scale more smoothly than ever before.     Step 2: ThingWorx Active-Active Architecture   An Active-Active Cluster configuration introduce two software components and two components that are optional in a standard ThingWorx architecture are now required.   The reference architecture diagram below shows ThingWorx deployed with multiple ThingWorx Foundation servers configured in an Active-Active Cluster deployment.   Note: This is an example of a possible ThingWorx deployment. The business requirements of an application will determine the specific configuration in an Active-Active clustered environment.   Load balancer was optional in a single-server deployment, is now a requirement. ThingWorx Connection Server is also now required. Apache ZooKeeper is used to coordinate multiple running servers. Apache Ignite is used to share current state between servers.  Component       Description                                                                                          Provider Load Balancer Distributes network traffic to servers ready to accept it. In Active-Active Cluster configuration, the load balancer is used to direct WebSocket based traffic to the ThingWorx Connection Services while user requests (http/https) traffic is directly distributed to the ThingWorx Foundation servers. Example load balancers: HA Proxy Azure Application Gateway AWS ALB See the ThingWorx High Availability Documentation for details. ThingWorx Connection Server Handles AlwaysOn connections with devices and multiplexes all messages over one connection to ThingWorx Foundation Servers. In an Active-Active configuration, it handles all WebSocket based traffic to and from the ThingWorx Foundation Server. PTC Apache ZooKeeper A centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. It is a coordination service for distributed application that enables synchronization across a cluster. Apache Software Foundation Apache Ignite Used by ThingWorx Foundation Servers to share state. It may be embedded with each ThingWorx instance or can be run as a standalone cluster for larger scale. Apache Software Foundation Data and Model Provider Provides persistent storage of application data. All ThingWorx 9 supported database options: PostgreSQL Microsoft SQL Server Microsoft Azure SQL InfluxDB (only available as a data provider)         Step 3: Next Steps   Congratulations! You've successfully completed the Active-Active Clustering with ThingWorx guide.   At this point, you can make an educated decision regarding which clustering architecture is best suited for your ThingWorx application. Whether you already use ThingWorx or pursuing ThingWorx, its important to understand how Active-Active clustering is achieved and whether it is right for your system.   Learn More   We recommend the following resources to continue your learning experience:       Capability Guide Manage ThingWorx Application Development Reference Build Get Started with ThingWorx for IoT Experience Create Your Application UI   Additional Resources   To learn more about Active-Active Clustering and general ThingWorx deployment guidelines, there are ample resources available through our Help Center and PTC Community:   Resource Link Community Developer Community Forum Support ThingWorx Platform Sizing Guide Support ThingWorx Deployment Architecture Guide Support ThingWorx High Availability Documentation
View full tip
    Use Analytics Manager to automatically perform engine analytical calculations.   Guide Concept   This guide will use ThingWorx Analytics Manager to compare external-data from an Edge MicroServer (EMS) "Engine Simulator" to a previously-built analytical model.   Following the steps in this guide, you will learn how to deploy the model which you created in the earlier Builder guide.   We will teach you how to utilize this deployed model to investigate whether or not live data indicates a potential engine failure.   You'll learn how to   Deploy and execute computational models Define and trigger Analysis Events Map incoming data to the Model Map analytic outputs to applications   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 60 minutes       Step 1: Scenario   In this guide, we're continuing the same MotorCo scenario, where an engine can fail catastrophically in a low-grease condition.   In previous guides, you've gathered and exported engine vibration-data from an Edge MicroServer (EMS) and used it to build an engine analytics model.   The goal of this guide is to now operationalize that previously-created model to analyze individual, external readings to see if the "low grease" condition is currently happening.     Analytical model creation can be extremely helpful for the automotive segment in particular. For instance, each car that comes off the factory line could have an EMS constantly sending data from which an analytical model could automatically detect engine trouble.   This could enable your company to offer an engine monitoring subscription service to your customers.   This guide will show you how to put an analytic model of your engine into service to actively monitor performance.       Step 2: Configure Provider   In ThingWorx terminology, an Analysis Provider is a mathematical analysis engine.   Analytics Manager can use a variety of Providers, such as Excel, Mathcad, or even Analytics Server pre-built ones.   In this guide, we use the built-in AnalyticsServerConnector, a Provider that has been specifically created to work seamlessly in Manager and to use Builder Models.   From the ThingWorx Composer Analytics tab, click Analytics Manager > Analysis Providers > New....   In the Provider Name field, type Vibration_Provider. In the Connector field, search for and select TW.AnalysisServices.AnalyticsServer.AnalyticsServerConnector.   Leave the rest of the options at default and click Save.     Step 3: Publish Analysis Model   Once you have configured an Analysis Provider, you can publish Models from Analytics Builder to Analytics Manager. On the ThingWorx Composer Analytics tab, click Analytics Builder > Models.   Select vibration_model_s1_only and click Publish.   On the Publish Model? pop-up, click Yes. A new browser tab will open with the Analytics Manager's Analysis Models menu. Close that new browser tab, and instead click Analysis Models in the ThingWorx Composer Analytics navigation. This is the same interface as the auto-opened tab which you closed.   Click the model to select it. At the top, click Enable. Note the pop-up indicating that the Enable was successful.       Step 4: Modify EdgeThing   In previous guides in this Vehicle Predictive Pre-Failure Detection Learning Path, you have created various Entities, including Things such as EdgeThing.   In order to automate the process of pushing data from EdgeThing to Analytics Manager, we need to add a few more Properties to EdgeThing.   These Properties are simple STRING variables, and we'll also set Default Values for them to configure parameters of Analytics Manager.   The first is causalTechnique, which tells Analytics Manager which criteria to use when measuring the impact of a feature on a range of goal values.   The second is goalField, which is simply the data field for which Analytics Manager should try to identify the correlation. In this case, it'll be our primary issue, i.e. low_grease.   It is not mandatory that these suggested Property names match, but they are the names used within ThingWorx Analytics. You could use any Property name you wanted, as you'll be mapping from a particular Property to the functionality within Analytics in a later step.   Return to EdgeThing > Properties and Alerts.   Click + Add.   In the Name field, type causalTechnique. Check Has Default Value. In the text field under "Has Default Value", type FULL_RANGE. Note that you MUST type FULL_RANGE, including capitalization, as that is a command within Analytics Server.   Click the "Check with a +" icon for Done and Add. In the Name field, type goalField. Check Has Default Value. In the text field under "Has Default Value", type low_grease. Note that you MUST type low_grease, including being all lower-case, as that is the exact name of the Analytics Server goal.   Click the "Check" icon for Done. Click Save.   Results Storage   We also need a place in which to store the results that Analytics Manager returns. We'll utilize a few additional Properties for that as well.   On the EdgeThing > Properties and Alerts tab, click + Add. In the Name field, type Result_low_grease. Check the Base Type to BOOLEAN. Check Persistent.   Click the "Check with a +" icon for Done and Add. In the Name field, type Result_low_grease_mo. Change the Base Type to NUMBER. Check Persistent.   Click the "Check" icon for Done. Click Save.       Step 5: Create Event   Events are automatic analysis jobs which are submitted based on a pre-defined condition. In this step, we'll configure an Analysis Event, which will execute automatically whenever there is a data-change in our simulated engine.   On the ThingWorx Composer Analytics tab, click Analytics Manager > Analysis Events.   Click New.... If not already selected, change Source Type (Required) to Thing.   In Source, search for and select EdgeThing. In Event, select DataChange. In Property, select s1_fb1. If there are multiple s1_fb1 Properties, select the first one, as the second one is the s1_fb1 entry in the Info Table Property. In Provider Name, select Vibration_Provider. In Model Name, select the published Model.   Click Save.       Click here to view Part 2 of this guide.  
View full tip
  Basic Mashup Widgets Guide Part 3   Step 5: Gauge   A Gauge is best for displaying a quickly readable approximate value. Select the Widgets tab in the uppper panel of the left dock, then enter gauge inside the Filter field in the top left. Drag-and-drop the Gauge widget onto the bottom-center container. We will now bind the Slider to the Gauge. Click the Slider Widget in the top-right Container. Click the drop-down arrow on the left side of the Slider widget. Click and drag the Value property listed in the Slider drop-down onto the Gauge widget.   Click the # Data property that is available from the Select Binding Target pop-up.   Click Save to save your Mashup. Click View Mashup then adjust the slider to the left to see the changing value shown on the widget. Many properties are available that give control over how the Gauge 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 Data Number None Input Value displayed by gauge indicator MinValue Number 0 Input Value used for lowest gauge display MaxValue Number 100 Input Value used for highest gauge display Legend String None Input Text Shown under Gauge ToolTipField String None Input Text shown when mouse hovers over gauge Visible Boolean True Input Widget is visible if set to true   Static Name Type Default Description DisplayName String None Name used for widget in user-facing interactions Description String None Description used for widget in user-facing interactions MinorTicks Number 4 Number of minor ticks per interval TickLength Number 8 Tick mark length MinorTickLength Number 4 Minor tick length ValueDisplayMode None/Top/Bottom/Inside None Location on gauge where numeric value is shown. LabelDigits Number 3 Number of digits for label display LabelDecimals Number 0 Number of decimals for label display ValueDigits Number 3 Number of digits for value display ValueDecimals Number 0 Number of decimals for value display LegendDisplayMode None/Top/Bottom None Location on gauge where Legend is displayed ReferenceAngle Number 225 Angle that controls the gauge orientation (degrees) Aperture Number 270 Angle that controls the gauge size (degrees) NeedleDiameter Number 10 Diameter of the gauge needle (pixels) CenterDiameter Number 20 Diameter of the gauge center (pixels) GaugeBorder Number 20 Width of the outside gauge border (pixels)     Step 6: Grid Advanced   A Grid Advanced widget is used to display data to a mashup user in a table Select the Widgets tab in the uppper panel of the left dock, then enter grid inside the Filter field in the top-left. Drag-and-drop the Grid Advanced widget onto the top-left container on your Mashup that already has the Button Widget. Add Data Source   Before you can customize the Grid display, you must first bind an Infotable to the Grid's Data property. In this example we will use the QueryImplementingThingsWithData Service to bind a group of Things created with the same Template. We have created a file with sample entities for this exercise. Download the attached demoTractors.xml. Click Import/Export in the lower left of Composer, then select Import   Click From File in the drop down, then Browse. Browse to the demoTractors.xml file and click Open. Click Import, then Close after entities are successfully imported. Click the green + button in the Data tab on the right side of the Mashup Builder window. In the Select Entity panel click Thing Templates from the drop down.   Scroll through the available Thing Templates and select the Connected Tractors Template that was imported. Enter query into the filter text box then click the arrow to the right of QueryImplementingThingsWithData. Click the Execute on Load check box, this option will execute the QueryImplementingThingsWithData Service when the Mashup is loaded.   Click Done. Click the arrow icon to expand QueryImplementingThingsWithDate, and Returned Data. Click and drag All Data onto the Grid widget.   Click Data in the Select Binding Target pop-up.   NOTE: The Grid widget now shows Property names in the column headers.  15. Click the drop down in the upper left of the Grid widget, then click Configure Grid Columns to show the Configure Grid Columns pop-up. 16. Uncheck the check box next to the property names in the left-hand panel that you don't want shown in the Grid. NOTE: You can drag and drop the property names to change the display order. You can customize Column names and formatting by making changes in this window. 17. Click Done when you are satisfied with the column formatting options. 18. Click Save to save your Mashup. 19. Click View Mashup.         In addition to properties that give control over how a Grid widget will be displayed, the scroll position of a Grid can be read in the CurrentScrollTop property and can be set with the ScrollTop property.   Bindable Name Type Default Direction Description Data Infotable None Input The data that is displayed in the Grid EditedTable Infotable None Output The data that is in the Grid after a user edit CurrentScrollTop Number 0 Output How far down (in pixels from the top of the full data list) the Grid is currently scrolled ScrollTop Number 0 Input How far down (in pixels from the top of the full data list) the Grid will be scrolled. Visible boolean true Input Widget is visible if set to true   Static Name Type Default Description DisplayName String None Name used for widget in user facing interactions Description String None Description used for widget in user facing interactions RowFormat StateDefinition None Specify a State Formatter to control display of the data in each grid row AlignHeader Boolean False When enabled, align column headers with their data MultiSelect Boolean False allow multiple items to be selected IsEditable Boolean False Allow grid value editing in Configure Grid Columns pop-up AutoSelectFirstRow Boolean False Automatically select the first row upon initial loading of data. CellTextWrapping Boolean False Enable or disable text wrapping within the grid cells. TabSequence Number 0 Tab sequence index   Widget Events Name Description DoubleClicked Fired when user double clicks on the grid   Step 7: Next Steps   Congratulations on completing the guide!   The next guide in the Customize UI and Display Options to Deploy Applications learning path is Define Your UI Style.    If you have questions, issues, or need additional information, refer to: Resource Link Experience ThingWorx Application Development Reference Community Developer Community Forum Support Button Widget Help Center Support Slider Widget Help Center Support Gauge Widget Help Center Support Advanced Grids (Themable) Help Center    
View full tip
  Guidelines for selecting the optimal method for connecting to ThingWorx   GUIDE CONCEPT   In the world of IoT application development, connectivity refers to the infrastructure and protocols which connect devices to the cloud or network. Edge devices handle the interface between the physical world and the cloud.   ThingWorx provides you with several different tools for connecting to the Thingworx platform.   This guide is designed as an introduction to these tools, and will help you determine which to choose based on your specific requirements.   YOU'LL LEARN HOW TO   Pros and cons of different connection methods The connection method best suited for some typical applications Where to find detailed information about any connection method   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 30 minutes   Step 1: Connectivity Method Options   There are many factors that will influence your decision about the ideal mechanism to connect to ThingWorx. On this page we compare and contrast different methods and give examples for where each one is a natural fit.   Connectivity Method Developer Benefit REST API Integrate seamlessly using dynamically-generated API calls Azure IoT Hub Connector Connect devices that use Azure IoT Hub Edge SDKs Build full-featured integrations for any platform ThingWorx Kepware Server Connect out-of-the-box with over 150 protocol drivers for industrial equipment Edge MicroServer Establish bi-directional connectivity with this complete, ready-to-run agent   REST API   Pros Cons Typical use case Skills Required Connection Type  Web developer can easily create integration ThingWorx cannot trigger action on the edge Push data from small devices to ThingWorx REST API development Request/Response   Using the ThingWorx REST API is an easy way for low-capability devices to connect with a ThingWorx platform. Any edge device that can make an HTTP POST can read and update properties or execute services on a ThingWorx platform. The disadvantage of this method is that it is one way from edge to platform. There is no way for the platform to initiate a service on the remote device and properties are only updated when the edge device initiates a connection with ThingWorx.   Learn more about the ThingWorx REST API:   Use REST API to Access ThingWorx Using the   Connect an Arduino Developer Board   tutorial REST API Documentation   Azure IoT Hub Connector   Pros Cons Typical use Case Skills Required Connection Type  Easily connect devices that use Azure IoT Hub Adds dependency and cost to application Add ThingWorx for devices connected with the Azure cloud Azure edge development AlwaysOn™   The diagram illustrates device-to-cloud integration with the Azure IoT Hub.   The ThingWorx Azure IoT Hub Connector establishes network connections to both ThingWorx Foundation and the Azure IoT Hub. Data flows in from devices, through the Azure IoT Hub hosted in the cloud, to the ThingWorx Azure IoT Hub Connector configured for a specific ThingWorx instance. The ThingWorx Azure IoT Hub Connector translates messages from the Azure IoT Hub format, to the native ThingWorx format and uses an established AlwaysOn connection to forward the information to ThingWorx Foundation.   Azure IoT Hub   Connect Azure IoT Devices   Edge SDKs   Pros Cons Typical Use case Skill Required Connection Type  Fully integrate device or remote system with ThingWorx platform Most developer flexibility All functionality must be developed by programmer Full customization or tight integration required Application development in Java, C, or .Net AlwaysOn™   These SDKs are developer tools that wrap the protocol used to connect to the ThingWorx Platform. There are SDK's available for Java, C, and .Net languages. The Edge MicroServer uses the C SDK internally. All SDKs use the ThingWorx AlwaysOn binary protocol together with the HTTP WebSocket protocol for transport. WebSocket connections can operate through a firewall allowing two-way, low latency communication between the device and server. The SDKs support the following key concepts that allow a Thing developed with an SDK to be a full-fledged entity in the ThingWorx environment:   Remote properties   — Entities that define the types, identities, and values from a device or remote system Services   — Actions that can be performed on demand by a device or remote system Events   — Data that is sent to a subscribed device or remote system whenever the Event is triggered   You can choose from any of the SDK's to create a custom application that meets their exact requirements.   C SDK   The C SDK is the most lightweight of all the SDKs and will result in an application that uses the least amount of RAM, frequently requiring less than 200kB. It is the only SDK that is distributed as source code, allowing compilation of C SDK applications on any platform even those without an operating system.   Learn more about the C SDK:   C SDK Tutorial C SDK Documentation   Java SDK   The Java SDK is designed for portability and simplicity to ease connecting any Java-enabled device or system to ThingWorx. The Java SDK is provided as .jar files and sample Java source code. Any system that can run Java 1.7.51 or later should be able to build and run the example applications.   Learn more about the Java SDK:   Java SDK Tutorial Java SDK Documentation   .Net SDK   The .Net SDK is provided as .dll files with sample Visual C# project files and source code. Any system that can run Microsoft NET 3.5 SP1 Framework development environment should be able to build and run the example applications.   Learn more about the .Net SDK:   .Net SDK Documentation   ThingWorx Kepware Server   Pros Cons Typical Use case Skill Required Connection Type  Easily connect to hundreds of different types of industrial equipment Requires computer running Windows physically connected to device Adding ThingWorx to an industrial setting Configure settings AlwaysOn™   The ThingWorx Kepware Server Windows client lets users quickly and easily connect real-time, bi-directional industrial controls data to the ThingWorx IoT Platform via the ThingWorx AlwaysOn protocol. ThingWorx services enable users to browse, read, write, and interact with ThingWorx Kepware Server, and includes intuitive tools that simplify the modeling of industrial things.   Learn more about the ThingWorx Kepware Server:   Connect Industrial Devices and Systems ThingWorx Kepware Server Documentation ThingWorx Kepware Server Manual   Edge MicroServer   Pros Cons Typical Use case Skill Required Connection Type  Easily connect with simple scripting Requires a device running Windows or Linux Customization with Lua scripting Connecting gateway router to ThingWorx Configure settings AlwaysOn™   The ThingWorx Edge MicroServer is a binary executable available for Windows and Linux running on either ARM or x86 processors. The EMS establishes an   AlwaysOn, bi-directional connection to a destination ThingWorx platform when it is started. The EMS is configured by editing a json text file to specify the target platform and credentials. The EMS uses the always on connection to provide a local HTTP server that is a reflection of the platform REST API. This local copy of the platform API allows devices that are not capable of making encrypted connections across the open internet to securely interact with the platform. The EMS package also includes the Lua Script Resource application. This application extends the ThingWorx Foundation server by connecting through the EMS HTTP server and provides a Lua interpreter that can be used to connect local resources to the ThingWorx server.   Learn more about the ThingWorx Edge MicroServer:   Connect a Raspberry Pi to ThingWorx using the Edge MicroServer Edge MicroServer Documentation   Step 2: Next Steps   Congratulations! You've successfully completed the   Choose a Connectivity Method   guide.   At this point, you can make an educated decision regarding which connection methods are best suited for your application and infrastructure.   The next guide in the Connect and Configure Industrial Devices and Systems learning path is Use REST API to Access ThingWorx   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Connect ThingWorx Application Development Reference Build Get Started with ThingWorx for IoT Experience Create Your Application UI   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support ThingWorx Connectors Help Center
View full tip
  Connect   Connect Your Data to ThingWorx In the world of IoT application development, connectivity refers to the infrastructure and protocols which connect devices to the cloud or network. Edge devices handle the interface between the physical world and the cloud. ThingWorx provides you with several different tools for connecting to the ThingWorx platform. Your decision on which connectivity method to pick will be dependent on your individual use case.   Learning Paths Connect and Configure Industrial Devices and Systems   Featured Guides Install ThingWorx Kepware Server Connect to an Azure OPC UA Server   REST API Use the REST API to Connect Low-Capability Devices to ThingWorx   Using the ThingWorx REST API is an easy way for low-capability devices to connect with the ThingWorx platform and push data to the platform. Any edge device that can make an HTTP POST can read and update properties or execute services on the ThingWorx platform.   Choose a Connectivity Method Use REST API to Access ThingWorx Connect an Arduino Developer Board   Edge SDKs Connect natively to ThingWorx using an AlwaysOn protocol SDK.  Secure, embeddable, and easily deployable communications designed for connecting sensors, devices and equipment across any network topology and any communication scenario.   SDKs are available for Java, C, .net and allow you to connect your devices to ThingWorx with the AlwaysOn protocol. Using the Edge SDKs will give you all the flexibility you need to meet your application's requirements and build robust, secure, full-featured edge integrations and gateways for any platform.   ThingWorx Edge SDKs SDK Reference C SDK Tutorial Java SDK Tutorial   Edge Microserver The Edge Microserver proxies connections via AlwaysOn   Connect your devices to the ThingWorx platform with the Edge MicroServer, a pre-built application that enables devices incapable of making TLS connections to securely interact with the platform.   Connect Raspberry Pi to ThingWorx Choose a Connectivity Method   Kepware Server Access data from industrial machine controllers   ThingWorx Kepware Server with 150+ industrial protocol drivers allows you to easily connect to different types of industrial equipment. The interface provides real-time, bi-directional industrial controls data to the ThingWorx Platform via the AlwaysOn protocol.   Install ThingWorx Kepware Server   Device Cloud Connectors Connect devices with the adapter of your choice and integrate with ThingWorx to build scalable IoT applications.   Connect Azure IoT Devices     Analyze   Analyze and Visualize IoT Data The AI and Machine Learning technologies used in ThingWorx Analytics automate much of the complex analytical processes involved in creating data-driven insights for your IIoT application. Simulate behavior of physical products in the digital world, use predictive analytic algorithms to find patterns in your business data and generate a prediction model, or build a real-time anomaly detection model by monitoring for data points that fall outside of an expected range.   Learning Paths Monitor Factory Supplies and Consumables Design and Implement Data Models to Enable Predictive Analytics   Featured Guides Operationalize an Analytics Model Build a Predictive Analytics Model   Perform Analytical Calculations Embed analytics capabilities into your industrial IoT applications in order to monitor real-time data, predict future events and conditions, and optimize performance of devices and organizations.   Operationalize an Analytics Model Build a Predictive Analytics Model Monitor an SMT Assembly Line Statistical Monitoring with Descriptive Analytics Perform Statistical Calculations with Descriptive Analytics     Build   Rapid, Model-based Application Development Build your industrial IoT application using ThingWorx’s drag-and-drop GUI development environment, model-based development platform. Using the ThingModel to describe assets, processes, and organizational elements and how they relate to each other. Define the functional behavior, add business logic, and extend your application with pre-built plugins. With a properly-constructed framework, your application will be scalable, flexible and more secure.   Learning Paths Medical Device Service Design and Implement Data Models to Enable Predictive Analytics   Featured Guides Get Started with ThingWorx for IoT Data Model Introduction   Build the Data Model Define the properties, services, and events of Things you want to expose to your application developers. The ThingWorx Data Model is a logical representation of the physical devices, systems, and people that interact with your application.   Data Model Introduction Monitor an SMT Assembly Line Data Model Implementation Design Your Data Model   Leverage the Data Model Leverage your data model using events subscriptions, and custom business logic.   Monitor an SMT Assembly Line Methods for Data Storage Bind Data to Widgets Implement Services, Events, and Subscriptions Create Custom Business Logic Application Development Tips & Tricks Create Session Parameters   Extend the Platform Capabilities Take advantage of extensions from partners and third-parties to add new functionality into your system in a seamless manner. Extensions can be service (function/method) libraries, connector templates, widgets, and more.   Create An Extension Create A Mashup Widget Extension Create An Authentication Extension     Manage   ThingWorx Platform Management Efficiently manage your assets with visibility and control over your IoT solution. Install, configure and troubleshoot your application, while monitoring performance and communication with devices. Offering a comprehensive set of tools and features, ThingWorx enables remote access, file transfers, software upgrades, logging, debugging, and more.   Learning Paths Getting Started on the ThingWorx Platform Using an Allen-Bradley PLC with ThingWorx   Featured Guides Deploy an Application   Manage Your Platform Compare Persistence Providers   Manage Your Applications Operationalize application updates, OS upgrades, patches and documentation.   Deploy an Application Compare Persistence Providers     Experience   Design Engaging Experiences Use the industry’s first purpose built IoT application development environment to design engaging experiences for web and mobile applications. Designed to reduce the time, cost, and risk required to build new innovative IoT applications, this layer has two distinct functions: build-time and run-time. Build-time encompasses the technology to create the things in your Industrial IoT solution while Run-time includes the operational permissions to execute and manage those things.   Learning Paths Getting Started on the ThingWorx Platform Customize UI and Display Options to Deploy Applications   Features Guides Create Your Application UI   Application Layout (UI)  Utilize the ThingWorx Mashup Builder tools to design and create engaging IoT applications.   Define Your UI Style Add Style to Your UI with CSS Effective UI Implementation   Charts & Graphs Bring your IoT data to life with dynamic charts and graphs.   How to Display Data in Charts   Reusable Components Leverage the ThingWorx widget library to create a robust user experience and enhance your application capabilities.   Object-Oriented UI Design Tips Display Geolocation Data Using Google Maps Organize Your UI with the Collection Widget     Secure   Securely Collect and Process Data ThingWorx is secure by design and offers multiple authentication options to increase the security of your IoT application. From TLS-encrypted communication and role-based access controls to the distribution of security patches, ThingWorx integrates a range of security features that you can leverage in your development process.   Learning Paths Getting Started on the ThingWorx Platform   Featured Guides Configure Permissions   IoT Application Security Authenticate devices on our platform. ThingWorx handles data transformation, data persistence, and business logic so you can focus on developing your application.   Configure Permissions Enabling LDAP Authentication in ThingWorx Create An Authentication Extension Create An Application Key
View full tip
  GUIDE CONCEPT   This guide introduces connecting an Allen-Bradley PLC to ThingWorx Kepware Server.   YOU'LL LEARN HOW TO   Create and run a simple ladder logic application on an Allen-Bradley PLC Connect the PLC to ThingWorx Kepware Server   NOTE: The estimated time to complete this guide is 30 minutes.      Step 1: Learning Path Overview   Assuming you are using this guide as part of the   Rockwell Automation Learning Path, then you have now completed each of the following installations:        1. Connected Components Workbench       2. ThingWorx Kepware Server       3. ThingWorx Foundation (for Windows)   In this continued step, you'll now connect an   Allen-Bradley PLC   to   Connected Components Workbench   and then to   ThingWorx Kepware Server.   In a later guide, we'll propogate that information further from ThingWorx Kepware Server into ThingWorx Foundation.   NOTE: Both Rockwell Automation's Connected Components Workbench and ThingWorx Kepware Server are time-limited trials. If significant time has passed while persuing this Learning Path, you may need to reinitialize them. Consult the Troubleshooting step of this guide for more information.       Step 2: Setup PLC   This guide uses an inexpensive Allen-Bradley Micro820 PLC as a demonstration.   ThingWorx Kepware Server offers drivers for hundreds of devices, making this step the only one that contains device-specific instructions.   Read and understand installation instructions before making any electrical connections to the PLC.   1. Connect the postive lead of a 24V power supply along with a 6" test lead to Terminal 1 of the output terminal block.   2. Connect the negative lead of the power supply to Terminal 2.     3. Confirm the test lead is secure from making contact with anything conductive; it will be  connected to +24V. Power on the supply and confirm the LEDs briefly light.       4. Carefully touch the test lead to the Input 1 terminal and confirm the indicator LED for Input 1 turns on.     5. Power off the supply before continuing to the next step.       Step 3: Create PLC Project   In this step, you will create a simple PLC application. This application will connect to a ThingWorx Mashup in subsequent guides in the Learning Path.    1. After opening Connected Components Workbench, click New... in the Project section.   2. Enter ThingWorxGuide in the Name field and click Create.   3. Browse to the PLC model you are using and click Select, then Add to Project.     4. Right-click Program, then left-click Add > New LD: Ladder Diagram     5. Double-click Prog1 to open the ladder window.     Ladder Logic   You will create a simple application that will turn on output 2 when there is a signal on input 2.    1.. Right-click in the box to the left of the rung, hover over Insert Ladder Elements, then click on Direct Coil   .     2.  Click the  I/O - Micro820 tab  towards the right and select an  output coil  - this guide uses  _IO_EM_DO_02 . Then click  OK                  3. Add an input contact by right-clicking in the   box to the left of the rung, hover over   Insert Ladder Elements, then click on   Direct Contact.   4.  Click the  I/O - Micro820 tab  and scroll down to select an  input  - this guide uses  _IO_EM_DI_02 . Then click  OK .        5. The program window should now look like this:     Upload   Next, you will propagate the program to the PLC.   1. Secure the test lead then apply power to the PLC.   2. Connect an ethernet cable directly between the PLC and your Windows computer.   3. Click Device > Connect to connect to the PLC; a pop-up will appear saying the project does not match the program in the controller.     NOTE: When either your PLC or computer are restarted, they may be assigned a new IP address, requiring you to reconfigure the connection. Click the tab labled with your PLC, then click the pencil icon next to connection path, click Browse, expand the Ethernet driver, highlight the active controller, and click OK. Click Close and then Connect.       4. Click Download current project to the controller   5. Confirm overwriting any program in the controller by clicking Download.   6. After your project is downloaded, run it on the controller by clicking Yes.     7. Touch the test lead to the I-02 terminal, and your program will turn on the #2 output. You can confirm your project is working by both hearing the soft click from the PLC and seeing the output indicator turn on.       Step 4: Configure ThingWorx Kepware Server   Now that you have a simple project running on the PLC, you need to configure ThingWorx Kepware Server to monitor it.   1. Open   ThingWorx Kepware Server, right-click on   Connectivity, and click   New Channel.   2. Select   Allen-Bradley Micro800 Ethernet   from the drop-down, then click   Next.       3. Click Next to accept the defaults, and click Finish to create Channel2.   4. Click Click to add a device below Channel2, enter myPLC in the name field, and click Next.   5. Enter the IP address of your PLC, then click Next. The IP address of your PLC is shown in Connected Components Workbench in Device > Configure.       NOTE: The IP address of the PLC may change when it is power cycled and must be updated in ThingWorx Kepware Server to match   6. Click Next to accept default values for each pop-up, and click Finish to create the myPLC device.       7. Click the Click to add a static tag message.   8. Enter Coil2 in the Name field, _IO_EM_DO_02 in the Address field, change the Data Type drop-down to Boolean, and click OK.  The address must exactly match a variable name in the PLC.       9. Create a second tag by right-clicking on myPLC again and clicking New Tag.   10. Enter Coil3 in the Name field, _IO_EM_DO_03 in the Address field, select Boolean from the Data Type drop-down, and click OK.         Step 5: Troubleshooting   1. If the connection to the PLC stops working and there is a   Thumbs Down   icon next to your Properties, the   ThingWorx Kepware Server   trial edition drivers are not connected to your PLC. The trial edition stops running after 2 hours and must be stopped and restarted. Right-click on ThingWorx icon in system tray.     Click Stop Runtime service. Wait a minute for the process to stop, then click Start Runtime service.   2.  If Connected Components Workbench does not connect to PLC, check the IP address of the PLC using RS Linx Classic software that was installed as part of Connected Components  Workbench. RS Linx Classic is located Start > All Programs > Rockwell Software > RSLinx > RSLinx Classic Click AB_ETHIP-1, Ethernet and IP addresses of connected PLCs will be discovered   NOTE: A changed PLC IP Address (typically seen through Connected Components Workbench) will require an IP Address change in ThingWorx Kepware Server settings.       Step 6: Next Steps   Congratulations! You've successfully completed the   Connect to an Allen-Bradley PLC   tutorial. You've learned how to:   Create and upload a simple ladder logic application to a PLC Connect a PLC to ThingWorx Kepware Server   The next guide in the Using an Allen-Bradley PLC with ThingWorx learning path is Create an Application Key.   Learn More   Capability Resource Analyze Monitor an SMT Assembly Line     Additional Resources   For additional information on ThingWorx Kepware Server:   Resource Link Website Connecting & Managing Industrial Assets Documentation Kepware documentation Support Kepware Support site
View full tip
Pre-built apps for manufacturing operations that rapidly deliver value.   Overview   Think Big, Start Small, Scale Fast   Getting started on an industrial IoT project can be daunting, especially deciding where and how to begin. After collecting the experiences gained by working with over 1500 companies on IIoT applications, PTC has made the process to get up and running easier. By grouping IIoT capabilities together in functionally oriented programs, PTC built out-of-the-box applications that rapidly deploy and scale across new or existing system infrastructure. Instead of starting from scratch, you can use ThingWorx ready-to-configure apps to quickly lay the foundation for industrial transformation and implement IIoT solutions in as little as 90 days. ThingWorx Apps offer a comprehensive, basic IIoT scheme to connect to your equipment, collect real-time data, create notification work flows, deliver role based dashboards, and more. Need something more tailored to your operation? No problem. You can iteratively extend and customize ThingWorx Apps into additional use cases for continuous innovation.     Manufacturing Apps   Manufacturers are under constant pressure to minimize downtime, improve quality, and respond faster to individual customer requirements, all while lowering costs. The ThingWorx Manufacturing Apps are pre-built solutions that can be tried in less than 60 minutes without disrupting production. These apps provide manufacturers with real-time visibility into factory floor operations, from individual PLCs to assets to plants to enterprise-wide operations.   ThingWorx Connected Work Cell   Connected Work Cell streamlines how information is delivered to frontline workers by aggregating critical data from multiple data siloes into a simplified visual application. It presents step-by-step work instructions with accurate, up-to-date information to drive efficiency, links instructions to work orders, assigns resources, and validates proper execution to ensure quality. Capabilities Lite work instruction authoring with multiple step types and versioning Workpiece routes editor and work order scheduling Step-by-Step tracking of operator execution  Smart tool configuration Work station dashboard display File storage and document management Benefits Present accurate, up-to-date work instructions using 3D models Aggregate work requirements from multiple sources into one simplified display at the work station Increase workforce flexibility by reducing upfront training before being assigned to a new work cell Improve quality by collecting actual tool use data Rapid implementation and fast time to value   ThingWorx Real-Time Production and Performance Monitoring   Real-Time Production and Performance Monitoring provides manufacturing executives and plant managers with top-down, real-time visibility into consistent KPIs such as overall equipment effectiveness, mean time between failure, and mean time to repair.   Capabilities Connect existing assets and gather real-time data View overall equipment effectiveness (OEE), mean time between failure (MTBF), and mean time to repair (MTTR) in real-time  Compare geographically separated assets, lines, or products based on date, time, shift or crew Benefits Improve operational performance of existing assets by increasing throughput and decreasing waste Balance labor vs. capital expenditures to meet production needs Determine true overall equipment effectiveness for multiple facilities   ThingWorx Asset Monitoring and Utilization   Asset Monitoring and Utilization helps manufacturers connect to existing assets, remotely monitor them in real-time, generate alerts based on abnormal conditions, and deliver critical insights with data trending and analysis tools.   Capabilities Performance Dashboards with real-time access to open alarms Email and SMS distribution rules for messaging and alarm acknowledgment Integration to maintenance systems Detailed screens showing asset health, configuration parameters, and sensor trends  Benefits Quickly identify anomalous data trends and perform Root Cause Analysis Maximize asset uptime and availability with alerts on critical issues before they impact performance Rapidly connect to and catalog existing assets Quickly Identify Anomalous Data Trends and perform Root Cause Analysis  
View full tip
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. 
View full tip
Learning Paths combine guides into one experience to teach related skills efficiently from start to finish. Begin your learning journey to reduce time to proficiency to get up and running with ThingWorx quickly.   Featured Learning   Utilizing ThingWorx to Secure Your Aerospace and Defense Systems Connect and Monitor Industrial Plant Equipment Vehicle Predictive Pre-Failure Detection with ThingWorx Platform   Industry Solutions   Complex and Automatic Food and Beverage Systems Connect and Configure Industrial Devices and Systems Medical Device Service Monitor Factory Supplies and Consumables Using an Allen-Bradley PLC with ThingWorx   Learn ThingWorx   Getting Started on the ThingWorx Platform Design and Implement Data Models to Enable Predictive Analytics Customize UI and Display Options to Deploy Applications Azure MXChip Development Kit    
View full tip
Use the Edge MicroServer (EMS), Foundation, and Analytics to engineer a Smart, Connected Products play for the Automotive segment.   NOTE: Complete the following guides in sequential order. The estimated time to complete this learning path is 240 minutes.   1. Use the Edge MicroServer (EMS) to Connect to ThingWorx  Part 1 Part 2 Part 3 2. Use the EMS to Create an Engine Simulator  Part 1 Part 2 Part 3 Part 4 3. Engine Simulator Data Storage  Part 1 Part 2 4. Build an Engine Analytical Model  Part 1 Part 2 Part 3 5. Manage an Engine Analytical Model  Part 1 Part 2 6. Engine Failure-Prediction GUI 7. Enhanced Engine Failure Visualization  Part 1 Part 2 Part 3
View full tip
Challenges Manufacturers of factory equipment often rely on manual processes to maintain adequate supply levels of consumables in equipment at customer sites. But a clipboard-and-pen process for ordering supplies are error prone, and can quickly grow wrought with problems that often go unreported until they affect assembly line production, resulting in unexpected costs—such as overnight shipping charges—and risking downtime, which ultimately leads to customer dissatisfaction.   Solution One such manufacturer implemented ThingWorx to connect to equipment installed at customer sites, and created a custom web application using ThingWorx Foundation to remotely monitor supply levels. ThingWorx Industrial Connectivity provides the bi-directional connection to send data that is displayed in graphs on the web application created using ThingWorx Mashup Builder. Features of ThingWorx Analytics were used to generate alerts before maintenance problems affected production.   Outcomes The manufacturer is able to monitor supply levels to more effectively anticipate when consumables will need to be replenished. Supplies are now consistently ground shipped on time to meet assembly line demand, reducing interruptions to operations and allowing expansion to multiple plants with improved service level.   NOTE: Complete the following guides in sequential order. The estimated time to complete this learning path is 120 minutes.   1. Implement Services, Events, and Subscriptions  Part 1 Part 2 2. Build a Predictive Analytics Model  Part 1 Part 2
View full tip
Build a Predictive Analytics Model Guide Part 2   Step 5: Profiles   The Profiles section of ThingWorx Analytics looks for combinations of data which are highly correlated with your desired goal. On the left, click ANALYTICS BUILDER > Profiles. Click New....The New Profile pop-up will open. NOTE: Notice the Text Data Only section which is new in ThingWorx 9.3.         3. In the Profile Name field, enter vibration_profile. 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 Profile field set to the default of empty. 8. Click Submit. 9. After ~30 seconds, the Signal State will change to COMPLETED. The results will be displayed at the bottom.                 The results show several Profiles (combinations of data) that appear to be statistically significant. Only the first few Profiles, however, have a significant percentage of the total number of records. The later Profiles can largely be ignored. Of those first Profiles, both Frequency Bands from Sensor 1 and Sensor 2 appear. But in combination with the result from Signals (where Sensor 1 was always more important), this could possibly indicate that Sensor 1 is still the most important overall. In other words, since Sensor 1 is statistically significant both by itself and in combination (but Sensor 2 is only significant in combation with Sensor 1), then Sensor 2 may not be necessary.     Step 6: Create Model   Models are primarily used by Analytics Manager (which is beyond the scope of this guide), but they can still be used to measure the accuracy of predictions. When Models are calculated, they inherently withhold a certain amount of data. The prediction model is then run against the withheld data. This provides a form of "accuracy measure", which we'll use to determine whether Sensor 2 is necessary to the detection of a low grease condition by creating two different Models. The first Model (which you will create below) will contain all the data, while the second Model (in the next step) will exclude Sensor 2. On the left, click ANALYTICS BUILDER > Models.   Click  New… . The New Predictive Model pop-up will open.   3. In the Model Name field, enter vibration_model. 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 Model section at its default of empty.       8. Click Submit. 9. After ~60 seconds, the Model Status will change to COMPLETED.   View Model   Now that the prediction model is COMPLETED, you can view the results. Select the model that was created in the previous step, i.e. vibration_model. Click View… to open the Model Information page.   Review the visualization of the validation results. Note that your results may differ slightly from the picture, as the automatically-withheld "test" portion of the dataset is randomly chosen. Click on the ? icon to the right of the chart for details on the information displayed.   The desired outcome is for the model to have a relatively high level of accuracy. The True Positive Rate shown on the Receiver Operating Characteristic (ROC) chart are much higher than the False Positives. The curve is relatively high and to the left, which indicates a high accuracy level. You may also click on the Confusion Matrix tab in the top-left, which will show you the number of True Positive and True Negatives in comparison to False Positives and False Negatives.     Note that the number of correct predictions is much higher than the number of incorrect predictions.     As such, we now know that our Sensors have a relatively good chance at predicting an impending failure by detecting low grease conditions before they cause catastrophic engine failure.     Step 7: Refine Model   We will now try comparing this first Model that includes both Sensors to a simpler Model using only Sensor 1. We do this because we suspect that Sensor 2 may not be necessary to achieve our goal. On the left, click ANALYTICS BUILDER > Models.   Click New…. In the Model Name field, enter vibration_model_s1_only. In the Dataset field, select vibration_dataset. Leave the Goal field set to the default of low_grease. Leave the Filter field set to the default of all_data.   On the right beside Excluded Fields from Model, click the Excluded Fields button. The Fields To Be Excluded From Job pop-up will open. 8. Click s2_fb1 to select the first Sensor 2 Frequency Band. 9. Select the rest of the Frequency Bands through s2_fb5 to choose all of the Sensor 2 frequencies. 10. While all the s2 values are selected, click the green "right arrow", i.e. the > button in the middle. 11. At the bottom-left, click Save. The Fields To Be Excluded From Job pop-up will close.           12. Click Submit. 13. After ~60 seconds, the Model State will change to COMPLETED. 14. With vibration_model_s1_only selected, click View....   The ROC chart is comparable to the original model (including Sensor 2). Likewise, the Confusion Matrix (on the other tab) indicates a good ratio of correct predictions versus incorrect predictions.     NOTE: These Models may vary slightly from your own final scores, as what data is used for the prediction versus for evaluation is random. ThingWorx Analytics's Models have indicated that you are likely to receive roughly the same accuracy of predicting a low-grease condition whether you use one sensor or two! If we can get an accurate early-warning of the low grease condition with just one sensor, it then becomes a business decision as to whether the extra cost of Sensor 2 is necessary.   Step 8: Next Steps   Congratulations! You've successfully completed the Build a Predictive Analytics Model guide, and learned how to:   Load an IoT dataset Generate machine learning predictions Evaluate the analytics output to gain insight    This is the last guide in the Getting Started on the ThingWorx Platform learning path.   This is the last guide in the Monitor Factory Supplies and Consumables learning path.   The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Operationalize an Analytics Model.     Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Support Analytics Builder Help Center    
View full tip
  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  
View full tip
    Step 7: Add Grid   It might also be helpful to display the data you've used to build the ThingWorx Analytics model.   In the future, this might be split out into an entirely separate page/Mashup that is exclusively devoted to backend model creation, but that would be beyond the scope of this guide.   For now, we'll simply display that collected data via the Grid Widget      1. On the EEFV_Mashup, drag-and-drop a Grid Advanced Widget onto the bottom-left Canvas section..     2. On the top-right Data tab, click the green </> button beside Things_EdgeThing. Note that this will open the Add Data pop-up, but with EdgeThing pre-selected.   3. In the Services Filter field, type getproperties.   4. Click the right-arrow beside GetProperties to add it to Selected Services on the right.   5. Check Execute on Load.     6. Click Done.   7. Under the Data tab, expand GetProperties to reveal the options.     8. Drag-and-drop Things_EdgeThing > GetProperties > infoTableProperty onto the Grid Advanced Widget.     9. On the Select Binding Target pop-up, click Data.     10. Click Save.   11. Click View Mashup.         Step 8: Add Controls   Throughout this Learning Path, it has been recommended that you stop Analysis Events when not actively using their functionality.   However, this requires going into the backend of ThingWorx Analytics to disable the event, which is not ideal.   Instead, let's enable or disable the Analysis Event from inside the Mashup by adding some Button Widgets to directly interface the Analytics backend for us.       1. Click the bottom-right Canvas section to select it.         2. In Mashup Builder top-left, click the Layout tab.         3. Under Positioning, click the Static radio-button.         4. Click the Widgets tab.       5. Drag-and-drop a Button Widget onto the bottom-right section.         6. Drag-and-drop another Button Widget onto the bottom-right section.       7. Drag-and-drop a Text Field Widget onto the bottom-right section.       8. Click Save.       Bring in More Data   Now that we have Buttons to trigger enable/disable, as well as a Text Field to display information, we now need to bring in some additional Mashup Data Services to interact with the ThingWorx Analytics backend.       1. Click the green + button at the top of the Data tab.       2. In the Entity Filter field, search for and  select TW.AnalysisServices.EventManagementServicesAPI.       3. In the Services Filter field, search for and add QueryAnalysisEvents by clicking the right arrow.       4. Check Execute on Load.         5. In Services Filter, search for and select EnableAnalysisEvent by clicking the right arrow. Note that you should NOT check "Execute on Load", as we'll trigger this Service only when the Button is clicked.     6. In Services Filter, search for and select DisableAnalysisEvent by clicking the right arrow. Likewise, do NOT check "Execute on Load" here either.       7. Click Done.         8. Click Save.     Display Event Key   To enable or disable Analytics Events, we need to know the eventId, which is returned by QueryAnalysisEvent Service as the parameter labeled key.   We'll bind that to the Text Field Widget for later usage in enabling/disabling.        1. Change the top-button's Label Property to Enable Analytics Event.       2. Change the bottom-button's Label Property to Disable Analytics Event.         3. Under the Data tab, expand QueryAnalysisEvents > Returned Data > All Data to reveal the options. .       4. Drag-and-drop QueryAnalysisEvents > Returned Data > All Data > key to the TextField Widget.         5. On the Select Binding Target pop-up, click Text.         6. Click Save.     Enable/Disable Analytics Events   Now that we know the key/eventId, we can call the EnableAnalysisEvent and DisableAnalysisEvent services.       1. Under the Data tab, expand EnableAnalysisEvent > Parameters to reveal eventId.       2. Click the Text Field Widget to select it, and then click the top-left drop down to reveal the options.         3. Drag-and-drop the Text Field's Text Property onto EnableAnalysisEvent > Parameters > eventId.         4. Repeat steps 1-3 for DisableAnalysisEvent.         5. Click the Enable Analytics Event Button Widget to select it, then click the top-left to reveal the drop down option .       6. Drag-and-drop the Clicked Event onto the EnableAnalysisEvent Service under the Data tab.         7. Repeat steps 5-6 for DisableAnalysisEvent, using the other Button Widget.         8. Click Save     Step 9: View Mashup   Throughout this guide, we've added various additional functionality to our MVP Mashup. At this point, you could continue to update the Mashup as you see fit.   For instance, you could change the background color of the top-left section to better match the header. Or you could further modify the original Mashup shown in the Contained Mashup Widget so that it better fits in the allowed space. You could add another Label Widget to the Header section to also display the company's motto / tag-line.   Regardless, when you are done with modifications, Save and click View Mashup.     Note that you can left-click-and-drag on the Time Series Chart to select particular time ranges. Or you could add a Time Selector Widget to the bottom-right section to control it there.   Similarly, you could add controls for the Grid Widget to only show the Identifier ranges in which you were interested.   Or you could split out the Model-creation values to a completely separate Mashup as previously discussed.   The extent to which you develop your Mashup is entirely up to you.        Step 10: Next Steps   Congratulations. You've completed the   Enhanced Engine Failure Visualization   guide. In this guide, you learned how to:   Create a Mashup with a Header Divide your Mashup into Sub-sections Use a Contained Mashup to reuse development Store historical data in a Value Steam Display historical data in a Line Chart Show spreadsheet data via a Grid Advanced Widget Tie Mashup controls into the ThingWorx backend   This is the last guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path.   Learn More   We recommend the following resources to continue your learning experience:   Capability  Guide Build Implement Services, Events, and Subscriptions Guide   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Analytics Manager Help Center
View full tip
  Create an Engine Failure Prediction GUI to warn about customer issues.   GUIDE CONCEPT   This guide will use ThingWorx Foundation's Mashup Builder to create a Graphical User Interface (GUI) to display results from Analytics Manager comparisons of your analytical model to real-time data.   Following the steps in this guide, you will learn how to utilize Widgets and backend data to quickly visualize customer failure conditions.     YOU'LL LEARN HOW TO   Create a Mashup Add Widgets to represent different data Bring Backend Data into the Mashup Tie data to Widgets View Analytical Results in a convenient GUI   NOTE:  The estimated time to complete all parts of this guide is 30 minutes.     Step 1: Scenario   In this guide, we're finishing up with the MotorCo scenario where an engine can fail catastrophically in a low-grease condition.   In previous guides, you've gathered and exported engine vibration-data from an Edge MicroServer (EMS) and used it to build an engine analytics model. You've even put that analytical model into service to give near-immediate results from current engine-vibration readings.   The goal of this guide is to   create a GUI   to visualize those predicted "low grease" conditions to facilitate customer warnings.     GUI-creation to visualize analytical model deployment can be extremely helpful for the automative segment in particular. For instance, each car that comes off the factory line could have an EMS constantly sending data from which an analytical model could automatically detect engine trouble.   This could enable your company to offer an engine monitoring subscription service to your customers.   This guide will show you how to visualize the results of an engine analytic model for a "smart, connected products" play.     Step 2: Create Mashup   Mashups are ThingWorx Foundation's method of creating Graphical User Interfaces (GUIs).   Mashups are created through the Mashup Builder interface.   Before you can use this drag-and-drop interface, you must first create a new Mashup.      1. In ThingWorx Foundation Composer, click Browse > Visualization > Mashups.      2. Click + New.        3. Leave the defaults and click OK.        4. In the Name field, type EFPG_Mashup.      5. If Project is not already set, search for and select PTCDefaultProject.        6. At the top, click Save.        7. At the top, click Design. You are now in the Mashup Builder interface, where you can drag-and-drop graphical elements (Widgets) to create your GUI.      8. At the top-left, click the Layout tab.        9. Change Positioning to Static. This removes any auto-positioning or dynamic-sizing from our Mashup, so that we can place and size Widgets manually.      10. At the top, click Save again.       Step 3: Add Widgets   We now want to add several   Widgets   to our Mashup by dragging-and-dropping them into the central   Canvas   area.   Return to the   Widgets   tab in the top-left.       2. In the   Filter Widgets   field, type   label.        3. Drag-and-drop five (5) Label Widgets onto the central Canvas area.      4. Select the Label Widgets, go to the Properties in the bottom-left, and change the Label's LabelText to s1_fb1 through s1_fb5.         5. Filter Widgets for text field, and then drag-and-drop five (5) Text Field Widgets onto the central Canvas area.        6. Drag-and-drop two (2) more Label Widgets onto the central Canvas area.      7. Change their LabelText Properties to Result_low_grease and Result_low_grease_mo.        8. Drag-and-drop two (2) more Text Field Widgets onto the central Canvas area.        9. In the top-left Widget's tab, change Category to Legacy.      10. Drag-and-drop an Auto Refresh Widget onto the Canvas.        11. At the top, click Save.         Step 4: Add Data   Now that we have a rough set of Widgets in place to display Data in our Mashup, we need to bring in backend Data from Composer.      1. In the top-right, ensure the Data tab is active.      2. Click the green + button.        3. In the Entity Filter field, search for and select EdgeThing.      4. In the Services Filter field, type getprop.      5. Click the right-arrow beside GetProperties.      6. On the right, check Execute on Load.        7. In the bottom-right, click Done.      8. On the right, expand GetProperties.        9. At the top, click Save.       Step 5: Bind Data   Now that backend Data is accessible inside Mashup Builder, we need to bind it to the various Widgets.   Drag-and-drop Data > Things_EdgeThing > GetProperties > s1_fb1 to the top-left Text Field under the s1_fb1 Label Widget.           2. On the Select Binding Target pop-up, click Text.         3. Repeat for s1_fb2 through s1_fb5 on the 2nd-5th Text Field Widgets.       4. Drag-and-drop Data > Things_EdgeThing > GetProperties > Result_low_grease to the top-right Text Field under the Result_low_grease Label Widget, and select Text on the Binding pop-up.       5. Repeat for Result_low_grease_mo on the Text Field just below.       6. Click the Auto Refresh Widget to select it.       7. In the bottom-left Properties, set RefreshInterval to 1.         8. With the Auto Refresh Widget still selected, click the top-left corner to reveal a drop-down.       9. Drag-and-drop the Refresh Event onto Things_EdgeThing > GetProperties.       10. On the right, click the GetProperties Mashup Data Service to reveal all of its interactions in the bottom-center Connections window.              11. At the top, click Save.       Step 6: View Mashup   In the last guide, we disabled the Analysis Event after confirming that appropriate analytical jobs were being created and completed whenever new data from our EMS Engine Simulator entered Foundation.   We now need to re-enable that Event so that we can see the results in our Mashup.       1. Return to Analytics > Analytics Manager > Analysis Events.       2. Select the Event, and click Enable.   View Analytical Results   With the Analysis Event enabled, we can now view our Mashup to watch engine-failure-predictions be displayed in real time.       1. Return to EFPG_Mashup.       2. At the top, click View Mashup.       3. Wait and notice how the refresh occurs every second, including both true and false analytics results for the "low grease" condition.      4. When you are satisfied that you have observed enough true/false results, return to Analytics > Analytics Manager > Analysis Events and Disable the event.   Through this Learning Path, you have done all of the following:   Connect a remote device to Foundation using the Edge MicroServer (EMS) Fed relevant product-data to the Foundation backend Formatted and exported that data in a manner which Analytics could understand Imported that data and used it to build an Analytics Model of your remote device Started feeding real-time remote data into the model to achieve immediate failure-prediction results Create a GUI to easily visualize those results   You now have a completed Minimum Viable Product (MVP) for a Service Play with MotorCo's new engines.   These new engines may have a known-failure condition, but (because you've instrumented those engines to provide constant data) you can monitor them and predict failures before they actually happen.   This could easily be an up-sell scenario for MotorCo's customers. They could simply purchase the engine. Or they could both purchase the engine and enroll in a service contract where you notified them of impending issues.   What was originally a single-point source of income is now ongoing        Step 7: Next Steps   Congratulations. You've completed the   Engine Failure-Prediction GUI   guide. In this guide you learned how to:   Create a Mashup Add Widgets to represent different data Bring Backend Data into the Mashup Tie data to Widgets View Analytical Results in a convenient GUI   The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Enhanced Engine Failure Visualization.   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Build Implement Services, Events, and Subscriptions Guide   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Analytics Manager Help Center
View full tip
    Step 6: Map Data   Now that the event is created, we need to map the Properties of EdgeThing to the fields required to invoke an Analysis Job.   We'll start with the Inputs.   Select the previously-created Event, and click Map Data....   Click Inputs Mapping.   In Source Type, select Thing. In Source, search for and select EdgeThing.   On the left, scroll down and select s1_fb1. Note that you do NOT want the s1_fb1 that is part of the InfoTable Property, because the Info Table Property only stores recorded data, not live data. On the right, select _s1_fb1, the first frequency band required for the Model to make a prediction.   Click the Map button in the center.   Repeat this mapping process for for s1_fb2 through s1_fb5.   Map causalTechnique to causalTechnique in the same manner. This is a String Property in EdgeThing with a Default Value of "FULL_RANGE". Map goalField to goalField in the same manner. This is a String Property in EdgeThing with a Default Value of "low_grease".   Map Results   Now that the Inputs are mapped, we also want to map the Results.   Click Results Mapping on the left.   Map _low_grease to Result_low_grease. Map _low_grease_mo to Result_low_grease_mo.   Click Close to close the mapping pop-up.   Enable Event   Now that we've done the mapping from Foundation to Analytics, let's Enable the Analysis Event so that it can automatically generate and process Analysis Jobs. Select the mapped Analysis Event. Select Enable.   Now that you have enabled the Analysis Event, the new data will be submitted to Analytics Manager whenever EdgeThing's s1_fb1 Property changes.   An Analysis Job will automatically run, with a predictive score sent back and stored in EdgeThing's Result_low_grease (Boolean) and Result_low_grease_mo (Number) Properties.     Step 7: Check Jobs   In this step, we'll confirm that the automatic analysis of information coming from remote devices is operational.   On the ThingWorx Composer Analytics tab, click Analytics Manager > Analysis Jobs.   Uncheck Filter Completed Jobs.   Select a Job and click View.... Click Results.   NOTE: You will see true or false, corresponding to either a low grease or no low grease condition. Using this technology, you could create a paid customer service, where you offered to monitor remote engines, in return for automatically shutting them down before they experience catastrophic engine failure.   For that example implementation, you would utilize the EdgeThing.Result_low_grease BOOLEAN Property to trigger other actions.   For instance, you could create an Alert Event which would be triggered on a true reading.   You could then have a Subscription which paid attention to that Alert Event, and performed an action, such as sending an automatic shutdown command to the engine when it was experiencing a likely low grease event.   NOTE: We recommend that you return to the ThingWorx Composer Analytics > Analytics Manager > Analysis Events tab and Disable the Event prior to continuing. Since the simulator generates an Event every ~1 seconds, this can create a large number of Events, which can fill up your log.       Step 8: Next Steps   Congratulations. You've completed the Manage an Engine Analytical Model guide. In this guide you learned how to:   Define an Analysis Provider that uses the built-in Analytics Server Connector Publish a Model from Analytics Builder to Manager Create an Analysis Event which takes data from ThingWorx Foundation and decides whether or not a failure is likely   The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Engine Failure-Prediction GUI.   Learn More   We recommend the following resources to continue your learning experience:    Capability     Guide Build Implement Services, Events, and Subscriptions Guide   Additional Resources   If you have questions, issues, or need additional information, refer to:    Resource              Link Community Developer Community Forum Support Analytics Manager Help Center      
View full tip
  Step 7: Real World Model   We’ll now rerun model creation with the Real World data.   Even though Signals and Profiles are possibly telling us that only Sensor 1 is needed, the   first Model   you’ll create will contain   all the data, while the   second Model   will   exclude Sensor 2. We’ll then compare the Models to see which one is going to work the best for predicting engine failures.   On the left, click   Analytics Builder > Models. Click   New….   In the   Model Name   field, enter   vibration_model. In the   Dataset   field, select   vibration_dataset.   Click   Submit. After ~60 seconds, the Model Status will change to   COMPLETED. Select the model that was created in the previous step, i.e.   vibration_model. Click   View…   to open the Model Information page. Note that your model may differ slightly from the picture below, as the automatically-withheld "test" data is randomly chosen.       Unlike our simulated dataset, this real-world data is not perfect. However, it’s still pretty good, and is much more representative of what a real-world scenario would indicate.   The   True Positive Rate   shown on the Receiver Operating Characteristic (ROC) chart are much higher than the False Positives.   The curve is relatively high and to the left, which indicates a high accuracy level.   You may also click on the   Confusion Matrix   tab in the top-left, which will show you the number of True Positive and True Negatives in comparison to False Positives and False Negatives.     NOTE: The number of correct predictions is much higher than the number of incorrect predictions.   As such,   we now know that our Sensors have a relatively good chance at predicting an impending failure   by detecting low grease conditions before they cause catastrophic engine failure.   Refined Model   We can now compare this   first Model   that includes   both Sensors   to a   Model using only Sensor 1, since we suspect that   Sensor 2 may not be necessary   to achieve our goal. On the left, click   Analytics Builder > Models. Click   New…. In the   Model Name   field, enter   vibration_model_s1_only. In the   Dataset   field, select   vibration_dataset.   On the right beside   Excluded Fields from Model, click the   Excluded Fields   button.   Select   s2_fb1   through   s2_fb5.   While all the s2 values are selected, click the green "right-arrow", i.e. >   button, in the middle.   At the bottom-left, click   Save.   Click   Submit. After ~60 seconds, the Model State will change to   COMPLETED. With   vibration_model_s1_only   selected, click   View….     The ROC chart is comparable to the original model (including Sensor 2).   Likewise, the Confusion Matrix (on the other tab) indicates a good ratio of correct predictions versus incorrect predictions.     NOTE: These Models may vary slightly from your own final scores, as what data is used for the prediction versus for evaluation is random.   ThingWorx Analytics’s Models have indicated that you are likely to receive roughly the same accuracy of predicting a low-grease condition whether you use one sensor or two!   If we can get an accurate early-warning of the low grease condition with just one sensor, it then becomes a business decision as to whether the extra cost of Sensor 2 is necessary.     Step 8: Next Steps   Congratulations! You've successfully completed the   Build an Engine Analytical Model   guide, and learned how to:   Load an IoT dataset Generate machine learning predictions Evaluate the analytics output to gain insight   The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Manage an Engine Analytical Model.   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Analyze Operationalize an Analytics Model Build Implement Services, Events, and Subscriptions Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Analytics Builder Help Center
View full tip
  Step 5: Import Extension   Now that we have a valid dataset, we want to export it as a   .csv file, which can be imported into ThingWorx Analytics in a future guide to generate an analytical model.   An easy way to do this is with the   CSV Parser Extension, which you’ll now import.       1. Download the CSV Parser Extension from our third party provider IQNOX.   Note:  An account is required but the download is free.     2. At the bottom-left, click Import/Export.       3. On the drop-down, click Import.       4. For Import Option, select Extension.       5. Click Browse and navigate to the extension you downloaded above.       6. Click Open.       7. Click Import.       8. Click Close.       9. On the Refresh Composer? pop-up, click Yes.      Step 6: Create File Repository   ThingWorx Foundation uses File Repositories to read and write files from disk (including .csv files created by the CSV Parser Extension).   In this step, we’ll create a File Repository Entity.       1. Return to Browse > All.       2. Click MODELING > Things.       3. Click + New.       4. In the Name field, type ESDS_File_Repository.       5. If Project is not already set, search for and select PTCDefaultProject.       6. In the Base Thing Template field, search for and select FileRepository.      7. At the top, click Save.        Step 7: Create .csv Export Service   We have imported an Extension which gives us tools to manipulate .csv files. We have created a File Repository to which the export can save the file. We'll now make use of some of this new functionality.    We’ll do so by creating a   Service   which calls built-in functions of the CSV Parser Extension.       1. Return to EdgeThing.       2. Click Services.       3. Click + Add.       4. On the drop-down, select Local (JavaScript).       5. In the Name field, type exportCSVservice.       6. In the blank JavaScript field, copy-and-paste the following code:         var sFile = "vibrationCSVfile.csv"; var paramsCSV = { path: sFile, data: me.infoTableProperty, fileRepository: "ESDS_File_Repository", withHeader: true }; Resources["CSVParserFunctions"].WriteCSVFile(paramsCSV);             7. Click Save and Continue. Note that you should NOT click the top Save button, as that will erase your Service.         Step 8: Export the Engine Data   We now have all the tools in place to export the infoTableProperty as a .csv file to our new File Repository.   All that’s left is to call the appropriate functions.       1. Ensure that you’re still on the Services tab of EdgeThing, and have the exportCSVservice open.       2. At the bottom, click Execute.       3. Return to ESDS_File_Repository.       4. Click Services.       5. Scroll down and find the GetFileListingsWithLinks Service.       6. Click the “Play” icon for Execute service.       7. At the bottom-right, click Execute.       8. On the right, click Thingworx/FileRepositories/ESDS_File_Repository/vibrationCSVfile.csv.     9. The .csv export of the vibration data will now be in your local folder to which your browser saves downloads.       Step 9: Next Steps   Congratulations! You've completed the   Engine Simulator Data Storage   guide, and learned how to:   Create a Timer Subscribe to a Timer to Trigger a Service Generate Mass Amounts of Test Data Import the CSV Parser Extension Create a File Repository Export the Test Data as a Comma-Seperated Values (.csv) file Download from a File Repository   The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Build an Engine Analytical Model   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Analyze Build a Predictive Analytics Model Build Implement Services, Events, and Subscriptions   Additional Resources   If you have questions, issues, or need additional information, refer to:        Resource Link Community Developer Community Forum Support Analytics Builder Help Center
View full tip