# AI for PTC ThingWorx: Natural-Language Access to Things, Value Streams and ERP Context > Source: https://netray.co/erp-ai/ptc-thingworx-ai-erp > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## Short answer AI for PTC ThingWorx exposes Things, properties, services and value stream history to a private language model through the ThingWorx REST API, then joins that data to ERP production and maintenance records. Engineers ask in plain English, see the calls made, and the model can run on-prem alongside a self-hosted ThingWorx deployment. ## Kind platform ## Erp Family mfg-systems ## Erp Products - PTC ThingWorx ## Industries - Manufacturing - Automotive - Heavy Equipment - Aerospace ## Region Global ## Persona IIoT Architect ## Eyebrow ThingWorx + private AI ## Intro ThingWorx organises industrial data as Things built from Thing Templates and Thing Shapes, each with properties, services and events. Property changes are logged to value streams or streams, and Mashups sit on top for operators. Many plants have a rich model, years of history and a few dashboards, yet the people with questions rarely know which Thing holds the answer. Because ThingWorx can be deployed on-prem, in a private cloud or as managed service, it is common in plants with strict data controls. That makes a public LLM unattractive but leaves a real need: operators and engineers want to ask what happened on a line without learning the model, writing a service, or building another Mashup. The ERP holds the other half of the picture: orders, routings, materials, maintenance plans. ThingWorx can integrate with ERP through connectors and custom services, but the integration is usually point-to-point and built for one dashboard rather than for open questions. This page covers how a private AI layer uses ThingWorx's own REST surface safely, how it stays read-only, and where ThingWorx's built-in analytics and Mashup tooling is the better tool. ## Pain Points ### Hard to know where the answer lives **Detail:** Large ThingWorx models have hundreds of Thing Templates and thousands of Things. Newcomers cannot tell which Thing, property or stream answers a question. ### Every new view needs a Mashup **Detail:** Operator questions that do not fit an existing Mashup wait on a developer. Composer work for a one-off question is poor value. ### ERP integration is dashboard-shaped **Detail:** Connections to the ERP typically feed a specific screen, not open exploration across machine history and production orders. ### Value stream queries are easy to get wrong **Detail:** Historical queries need correct time windows, property names, and paging. Large unbounded queries load the platform and its persistence layer. ### Security posture limits cloud AI **Detail:** ThingWorx installs in regulated plants often cannot use SaaS AI services, so any assistant must be private. ## Use Cases ### Ask about a line in plain English **Description:** Operator asks what stopped Line 3 last night. The agent finds relevant Things, queries property history and returns a timeline. **Erp Objects:** ThingWorx Things, properties, value streams; ERP work centers and production orders **Outcome:** Answers in a minute or two instead of waiting for a developer to build a view. ### Downtime reasons joined to orders **Description:** Match stop events to the production order running, the part, and the shift, then summarise the top causes. **Erp Objects:** Production orders, operation confirmations, shift calendars; ThingWorx event history **Outcome:** Pareto of downtime by product and cause that previously required manual alignment. ### Thing model discovery assistant **Description:** Search the model by meaning: which Things expose spindle temperature, and what units do they use. **Erp Objects:** Thing Templates, Thing Shapes, property definitions; equipment master **Outcome:** Faster onboarding and fewer duplicate Mashups; descriptions flagged for owner review. ### Maintenance triage with live context **Description:** For a condition alert, pull recent property trends, open maintenance orders and spare stock, then draft a note. **Erp Objects:** Maintenance orders, equipment, spare parts; ThingWorx alerts **Outcome:** Technicians start with context; order creation still requires approval. ### Genealogy question support **Description:** Combine machine parameter history with lot and serial data to show conditions a batch was produced under. **Erp Objects:** Lot and serial records, production orders; parameter streams **Outcome:** Faster containment investigations; evidence packaged for quality review. ### Service drafting for administrators **Description:** Draft ThingWorx service JavaScript or query snippets for an administrator to review and test in a dev instance. **Erp Objects:** Thing services, DataTables, Streams **Outcome:** Less boilerplate; code is never deployed without review and test. ### Throughput versus plan summaries **Description:** Compare counted output properties to planned quantity from the ERP and explain the gap. **Erp Objects:** Planned orders, routing standards; production counters **Outcome:** A daily narrative for supervisors that references both sides of the data. ## Architecture **Overview:** An orchestration service calls ThingWorx REST endpoints with an application key restricted to read, and queries the ERP read-only. A private model plans bounded calls, and the UI shows each call. **Layers:** #### ThingWorx connector **Detail:** Uses REST endpoints for Things, properties and services with a dedicated app key and a narrowly permissioned user; value stream queries are always time-bounded. #### Model index **Detail:** A searchable catalogue of Thing Templates, Shapes and property metadata so the model finds the right Thing before querying. #### ERP context **Detail:** Read-only ERP access for orders, routings, maintenance and lots, aligned to Things by equipment or work center keys. #### Private inference **Detail:** Open-weight models on vLLM or Ollama in the customer's data center or private cloud. #### Guardrails **Detail:** Allow-listed services, read-only mode, logging of every call, and human approval for any state-changing action. ## Deployment Options ### Alongside on-prem ThingWorx **Fit:** Plants hosting ThingWorx themselves **Detail:** Model server in the same network zone; no external calls; the simplest compliance story. ### Private cloud tenancy **Fit:** Teams running ThingWorx in their own cloud account **Detail:** Orchestrator and GPUs in the same VPC, with private endpoints between components. ### Air-gapped plant network **Fit:** Defense and high-security sites **Detail:** Model weights loaded offline, no internet egress, ERP replica or direct read-only link inside the enclave. ## Compliance ### Zone and conduit design keeps the AI tier read-only toward OT systems. **Framework:** IEC 62443 ### Segmentation and monitoring consistent with ICS security guidance for the added service. **Framework:** NIST SP 800-82 ### On-prem design lets the customer keep controlled data inside their boundary and scope the system within their own assessment. **Framework:** ITAR / CMMC (customer obligation) ### Parameter evidence referenced in quality records is retrieved read-only and logged. **Framework:** ISO 9001 / AS9100 records ## Integration Notes - Use the ThingWorx REST API with an application key bound to a user that only has read permissions on required entities. - Allow-list the services the agent may call; reject arbitrary service execution. - Always pass explicit start and end times and a row limit when querying value streams or streams. - Index Thing Templates and Shapes first so the model resolves names without scanning all Things. - Join to the ERP through an equipment or work center property stored on the Thing rather than name matching. - Test against a non-production instance, since heavy history queries can load the persistence provider. ## Product Fit ### Custom build **Why:** ThingWorx is an IIoT platform, so this is a custom connector with private model serving and a Thing model index. ### ERPray **Why:** Provides the grounded ERP half of the answer with shown queries and role enforcement. ## Engagement ### Model review **Duration:** 1-2 weeks **Deliverables:** - Thing and template inventory - Priority question list - ERP key alignment - Security zone design ### Connector build **Duration:** 2-4 weeks **Deliverables:** - Read-only app key and permissions - Model index - Bounded query tools - Test instance validation ### Pilot **Duration:** 3-5 weeks **Deliverables:** - Operator and engineer trials - Evaluation questions - Call transparency UI - Audit logging ### Rollout **Duration:** 2-4 weeks **Deliverables:** - Additional lines and Things - Monitoring and runbook - GPU sizing review - Governance for new services ## Buyer Questions - Which ThingWorx permissions does the agent use, and are they read-only? - How are value stream queries bounded to protect the platform? - How does it find the right Thing in a large model? - Can it run in our network with no internet egress? - How is the ERP joined to Things reliably? - Who approves anything that changes state? - How are ThingWorx upgrades handled? - When is a Mashup or ThingWorx Analytics the better tool? ## Faq ### Can an LLM query ThingWorx directly? **Answer:** Yes, through the REST API, but not with free-form access. A safe design exposes a small set of allow-listed tools, such as list Things by template or fetch property history for a bounded window, and the model chooses among them. Credentials are held by the orchestrator, not the model, and every call is logged. ### Does this work with on-prem ThingWorx? **Answer:** That is the most natural fit. The model server sits in the same network zone as ThingWorx and the ERP, so no data crosses the internet. You need GPU capacity sized for your concurrency, which depends on model choice and the number of simultaneous users. ### How is this different from ThingWorx Analytics? **Answer:** ThingWorx Analytics focuses on predictive modelling over your data. A natural-language layer is about exploration and question answering across Things and ERP data. They are complementary, and if your need is a specific prediction, the native analytics tooling may be the simpler path. ### Can it generate ThingWorx services? **Answer:** It can draft service JavaScript or query logic for an administrator, which is useful for boilerplate. Output should be reviewed and tested in a development instance, never deployed automatically. Generated code is treated as a suggestion with the same change control as hand-written code. ### Will heavy queries slow the platform? **Answer:** They can if unbounded, which is why every tool enforces time windows and row limits and the pilot runs against a test instance. Caching summaries and, where justified, replicating selected history to a separate store reduces load on the production persistence provider. ### What about write access? **Answer:** Read-only by default. Anything that would change a property, trigger a service with side effects, or create an ERP order is drafted for a human to approve. Control actions toward machines are outside the scope of a language-model assistant. ### Is it worth it for a small deployment? **Answer:** If you have a handful of Things and a few Mashups that cover the questions asked, probably not. The value appears when the model is large, the questions vary, and engineers spend real time hunting for the right Thing or joining machine data to ERP records. ## Search terms thingworx ai, ptc thingworx llm, thingworx erp integration, thingworx rest api ai, thingworx natural language query, thingworx value stream query, thingworx private ai, thingworx on-prem generative ai, ptc iiot ai integration, thingworx sap integration, thingworx mashup alternative ai, thingworx chatbot --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json