Providing an exact definition of a digital twin is a lot like defining IoT itself: if you ask ten different people, you'll get ten different answers. For us, however, Wikipedia's definition does a good job of succinctly describing how we think about digital twins.
With this definition in mind, a Losant Device, with its attributes and tags, are a form of digital twin. Tags describe static physical features such as color or serial number, and attributes describe changing characteristics like temperature, voltage, or fuel level.
As Losant continues to be used for larger and more complex solutions, we're learning that our customers struggle to properly group and organize their devices in order to create accurate models of their environments. Our recommended solution was to use tags to create these models, however, we found that to be unintuitive and sometimes difficult to maintain. In order to solve this problem, we've introduced a new type of device, which we've named System.
Systems, which are made up of one or more system-type devices, provide an intuitive and powerful way to build digital twins of your complex environments.
Systems are first and foremost a grouping mechanism. They are parents to any number of child devices and other child systems. This allows you to create hierarchical or nested models of your environment (i.e. systems of systems). Every device, including system devices, now has a "Parent System" field where you can optionally assign a device to a system. When you're viewing a system device, you'll see an extra tab where you can view and manage its children.
In order to view and navigate your systems, we've created the System Explorer, which can be accessed using a new button on the top right corner of the main device list page.
The above system describes a smart stadium experience we recently did at the Western and Southern Open. We had a pair of side-by-side suites, each made up of three rows of seats, with individual sensors on each seat. With this model, I can quickly see which sensors were located in which rows and in which suite. The System Explorer also has the ability to find devices, which is a convenient tool if you're not sure where a device is located within a complex system.
The physical organization of your devices is only part of the picture when it comes to describing and modeling your environment. You must also be able to model and understand how data propagates from the lowest levels of your system to the very top. To solve this, we've layered a unique data aggregation mechanism on top of the grouping mechanism to automate how data propagates through your systems.
For example, let's look at the Western and Southern example. Each suite contains roughly 20 individual sensors each reporting a value to their "orientation" attribute (0=unoccupied, 1=occupied). In order to calculate the total number of seats occupied for an entire row or an entire suite, I'd have to sum all of the individual sensors together. System devices do these aggregations automatically and store the results on their own attributes, which makes it much easier to use these values on dashboards and in workflows.
Below is a diagram that shows how data is aggregated from the actual sensor devices and up through the system hierarchy.
The diagram above shows how data is propagated from the actual sensors on the right to the top-level system on the left. The aggregation in this example is a sum. Each parent system is taking a sum of an attribute across all of its children and recording that result on one of its own attributes.
Just like all other device types, systems also have attributes, however how the values for these attributes are obtained is very different. Attributes for systems are calculated, or derived, from its child devices. This is how data propagates through your system in order to create a "system view" of your environment. Below is a screenshot of the configuration of one of the row's system attributes that is handling the aggregation of its child devices.
You have a lot of control over which children and which child attributes are used when calculating a system's attributes.
When these attributes are calculated is controlled by your system's query interval.
In the screenshot above, the query interval is set to 30 seconds. This means every 30 seconds Losant will automatically recalculate the values for every attribute on this system. It does this by querying the most recently reported value for all required child device attributes and passing them through your specified aggregation. This results in a single value that can be reported on your system attribute.
So for the Western and Southern Open example, each row's "occupancy" attribute is updated every 30 seconds by summing together the "orientation" attribute of every child device.
We worked directly with a number of customers across a variety of industries when designing systems. During this time, two major concepts continued to rise to the surface. Although systems can certainly be used to solve any number of problems, these are the concepts that guided its design.
Systems help describe and model the physical location of devices in Smart Environments. The distribution, relationship, and location of sensors in a smart environment is a perfect fit for the hierarchical nature of systems. For example, sensors can be placed in conference rooms, which are located on floors, which are located in buildings, which are located on a campus. Building this complex model of an entire campus can easily be achieved with systems.
The data propagation and aggregation mechanisms then make it easy to view building-wide and campus-wide insights. For example, a building can automatically be marked as occupied if any individual motion sensor in any conference room is detecting movement.
Systems help understand and track the distribution of fielded equipment sold by Industrial OEMs. It's common for the channel between the manufacturer and the end customer to be separated by several layers like suppliers, distributors, and resellers. These channels are very well represented by the hierarchical structure of systems.
The data propagation and aggregation mechanisms make it possible for OEMs to view critical pieces of information at the device, customer, and distributor level. This customer-centric data aggregation, combined with our nested experience groups functionality, provides a powerful foundation for the development of multi-tenant IoT applications.
If you've been a Losant Developer for a while, you may see the above System Explorer, with its nested structure, and think it looks very similar to our Experience Groups functionality. You may also wonder how systems are different from the device relationship that's created using gateways and peripherals. Although on the surface these concepts could look similar, they each solve very specific and fundamentally different problems.
Gateways and Peripherals are a device-to-platform authorization mechanism. Gateway devices are permitted by our platform to report state on behalf of its associated peripheral devices. Devices placed in a system do not imply or define any form of authorization.
Experience Groups are a device-to-user access mechanism. Devices are associated with groups as a way to define and control access to those devices by users assigned to that group. Devices placed in a system do not imply or define any form of user access control. There are architectures where a system hierarchy could look very similar or identical to an experience group hierarchy.
Systems are a logical grouping and data aggregation mechanism. They define how devices are organized as part of a larger environment and how data propagates up the system hierarchy. Systems do not affect device-to-platform authorization and they do not affect device-to-user access.
With every new release, we really listen to your feedback. By combining your suggestions with our roadmap, we can continue to make the platform easy for you. Let us know what you think in the Losant Forums.