Things are representations of physical devices, assets, products, systems, people, or processes that have properties and business logic. All Things are based on Thing Templates (inheritance) and can implement zero, one, or more Thing Shapes (composition). It is a best practice to create a Thing Template to describe a Thing, and then create an instance of that Thing Template as a Thing. This practice leverages inheritance in your model and lowers the amount of time you spend maintaining and updating your model.
A Thing can have its own properties, services, events, and subscriptions and it can inherit other properties, services, events, and subscriptions from its Thing Template and Thing Shapes. How you model the interconnected Things, Thing Templates, and Thing Shapes is key to making your solution easy to develop and maintain in the future as the physical assets change. End users will interface with Things for information in applications and for reading/writing data.
A device or data source that is remote from ThingWorx and is accessed over the network (Intranet/Internet/WAN/LAN) is represented by a Remote Thing.
Once you have defined the types of Things your model will contain (using Thing Shapes and Thing Templates), you can start to create specific Thing instances. In a truck example, you might define a truck Thing instance for every truck in your fleet. Each instance would track the information about itself and share that information for use in your applications, reports, and mashups. For a manufacturer, you might create a Thing instance for every machine, work center, or manufacturing unit, depending on your use cases. The granularity of asset management, product tracking, and data collection will influence how you model your equipment.
Was this helpful?