PTC ThingWorx, a journey through an IoT platform. (Part 1)
As an Analyst/Project-Manager working at Aptus, a young and extremely motivated Belgian IoT company, it’s in our best interest to keep track of what’s available on this market. This time we aimed our analytical view at the PTC ThingWorx platform.
So, PTC?
PTC was established in 1985 and was the first who would market modelling software, Pro/ENGINEER. During that same year, they acquired the legendary John Deere as PTC’s first customer. Throughout the following years, PTC enriched their portfolio with solutions who would cover topics like CAD (Computer Aided Design), PLM (Product Lifecycle Management), SLM (Service Lifecycle Management), AR (Augmented Reality), Smart Manufacturing / Industrie 4.0 and last but not least, IoT (Internet of Things). In this blog, we’ll focus on the IoT part of PTC, specifically “ThingWorx”. PTC ThingWorx is an application development platform for the Internet of Things (IoT) who they acquired back in 2014.
Let’s jump right into PTC ThingWorx!
At this point you probably haven’t a clue what ThingWorx is about and how a company would profit by using IoT and a connected platform.
PTC ThingWorx is in essential a development platform where developers can create solutions. Imagine solutions like dashboards, visual representations of data and many more. ThingWorx does this by using digital representations of physical entities. These entities could be machines, processes, and so on. They can even be persons.
Sensors capture data from some physical “thing” and send this data to the ThingWorx platform. This data is actually ThingWorx’s core. Without data, ThingWorx has no purpose.
What happens next inside ThingWorx is completely up to you. ThingWorx has a lot of built in functions who support the devs in creating the best possible solution.
The reason why i’m putting so much emphasis on the term “digital representation” is because developing in ThingWorx is building everything around “things”.
A “thing” is a digital representation of a physical entity.
If we take a closer look at the image above we see a few layers. The flow of ThingWorx starts at the bottom of the image with sensors, devices and smart products. These are our datasources. By connecting these datasources, this is possible via numerous ways, to the ThingWorx platform we get access to this vast amount of data. In this image the connection is made through the built-in REST API (will be explained in a bit). If the connection is a succes and we start receiving data we can start building our solution. ThingWorx allows us to create views, contextualize and analyse this data. The latter steps are to be discussed in part 2 of this journey.
Let me explain this “thing”-philosophy a bit deeper by using a case.
A company would like to know how hot it is in his warehouses throughout this summer.
Let’s break this question down. They want to know the temperature so it’s quite obvious we’ll need some temperature sensors. In this situation we got 1 sensor per warehouse. Note that this explanation will be a high-level overview on how someone would create a solution. You’ll see some platform screenshots but I won’t go into extreme detail how things are done on this platform.
First step to do is to get the data from these sensors in the platform. This step requires some setting-up in the platform itself. We’ll need to create our “things”, one per warehouse so we can clearly distinguish the warehouses from one and another. Because we use exactly the same sensors for each warehouse we can state that these things will be exactly alike. The only difference between these sensors will be the warehouse and value. This makes it easy for us because we can make a template. People who have an IT-background can refer to this template as some kind of interface. In this template we can define the needed properties. The most important property is temperature. The temperature property will change continuously (hopefully not) through the input of our sensor. Whereas our warehouse property will be constant and will not change unless it’s been repositioned. This change is out of scope for now so we’ll keep this as a manual change.
Let’s set up our sensor thing template. This step is to make it easier for us to create multiple temperature things. If we would create all our things from scratch, we would create the same thing with exactly the same properties and triggers over and over again. This would result in loss of time. Therefore we create our template who’ll hold the basic structure of our things.
When we create our thing, we’ll base it upon our template.
When everything is set up, 4 sensors, North, East, South and West, we created our digital entity but our physical entity is not yet linked to it. To link our entities there are 2 options I’ve tried out. ThingWorx offers more options but I haven’t had the time to dive deeper into them. Another reason I didn’t checked them yet is because our main sensor connectivity protocol is MQTT so it was quite obvious I checked these 2 options first.
- RabbitMQ Extension: subscribing on a queue who’s situated in our RabbitMQ exchange out of ThingWorx.
- REST API: connecting to PTC ThingWorx through an API call
RabbitMQ Extension
For people who don’t know what RabbitMQ is should check out this platform: www.rabbitmq.com
In RabbitMQ data gets pushed to the Exchange from our sensors. the exchange routes the messages to the designated queue. A Queue is a filtered set of messages received by the exchange. This gives you unlimited possibilities to create queue’s of aggregated data. For our purpose we pretend we have a queue who receives data of our 4 temperature sensors. In ThingWorx we subscribe our sensors to this queue with our credentials. In the event of received data in ThingWorx we fill our sensor’s properties with the current value. This extension works with a timer and will automatically check for new values.
REST API
For people who don’t know what a REST API is could check out this link: www.youtube.com/watch?v=7YcW25PHnAA
Basically, we are pushing data from our sensor to the ThingWorx API where we specify what thing needs to be updated. An example of a put action is as follows:
The URL we call:
https://www.MyThingWorxApp.com/Thingworx/Things/TemperatureSensor_WEST/Properties/CurrentTemperature
the values we pass in the form:
value=20&appKey=…
This shows ThingWorx that this thing needs to be updated to the value in the put form. This solution requires some kind of application who will call the ThingWorx API to update these values with the new values from the sensors.
As from now, when the physical thing updates its data, ThingWorx will get notified by this change and the digital representations will get the updated values.
This blogpost discusses and shows you a way to use ThingWorx to connect and retrieve data from physical sensors. In part 2 we’ll discuss how to work with this data in a way to show users what’s going on in their company with the connected entities. I hope this blogpost shows you how data can benefit almost every business in optimising it’s processes and day to day work.
To be continued!
I’m Sybren, working as an Analyst/Project Manager at Aptus. Our mission is to craft digital endpoints for the physical world. We support companies in their new digital ventures by inventing, creating and developing tools, applications and Internet of Things solutions. We are creative technologists who approach innovation differently: we experiment, tinker and make ideas come to life from the earliest moment possible.
