We were recently asked to review a MindSphere asset model for one of our customers. They wanted to make sure their approach was informed by best practices and that their modeling strategy would stand up to their evolving MindSphere usage. It is a question everyone asks when starting a MindSphere project, but one that is not always easy to answer. In this post we’ll focus on using asset variables and static aspects for modeling assets. But first let’s start with some basic MindSphere terminology.
Asset – the digital instance of your physical device — the root of your device’s digital twin. Assets are hierarchical and, therefore, may model a single device, parts of a device, or groups of devices such as a site where devices are located. Each asset is associated with an asset type that describes the asset such as its name, description, location, parent asset (remember that assets are hierarchical), as well as a set of custom variables and aspects.
Asset Types – the starting point for creating an asset model that represents your digital twin. You can’t create an asset without associating it with a type. Asset types are templates from which assets are created. Asset types, like assets, are hierarchical — they have a parent type and a collection of properties that define the asset type’s characteristics. MindSphere has multiple built-in types you can use as the basis for your custom types. An asset type has a set of asset variables and aspects that can be used to store (generally static) information about the asset.
Asset Variable – a variable has a name and a value, and assets have a collection of these name-value pairs. The variable’s name and type must be defined on your asset type (or one of its ancestors) before you can use it. They are defined individually on an asset type and, thus, are not grouped and shared through inheritance. If an asset of a certain type always has a property you’d like to save with the asset, then you can use an asset variable for that property.
Aspect Type – an aspect is a set of variables that together represent related properties of an asset. An aspect can be “dynamic” or “static”. A dynamic aspect describes things that change over time and usually have sensors for gathering values. Access to dynamic aspect information is enabled through MindSphere’s IoT Time Series and Time Series Aggregate Services. A static aspect contains descriptive information (like asset variables) that doesn’t change and doesn’t need to be tracked over time, but can be edited if required. Static aspects are stored and retrieved with the asset itself.
Creating an Asset Model
Given MindSphere’s modeling flexiblity, where should an asset’s traits (properties, characteristics, variables, etc.) and their associated metrics be described and stored? Sensor enabled properties (metrics) that change over time should be tracked using the IoT Time Series Service, which means they must be associated with dynamic aspect types. When traits are relatively static, (e.g., physical dimensions, model number, installation date, etc.) they can be stored in either a static aspect or an asset variable. There are a couple of reasons you would want to use a static aspect type rather than an asset variable. Let’s consider a use case for tracking dimensions of a widget asset.
Approach 1 – Asset Variables
Using this approach, we will create an asset type called MyWidget by extending MindSphere’s core asset type BasicDevice (core.basicdevice). We will add 3 variables to the MyWidget type called height, width, and depth. We will then create a new widget, as an asset, of type MyWidget and set these variables as appropriate for that specific widget. Although Approach 1 works fine for some assets, but it does not work well for assets with multiple dimensions.
For example, let’s say we create a new device type called MyGadget. If we want a gadget to have dimensions, we could add height, width, and depth variables to the MyGadget asset type. Alternatively, we could create a base type for our devices with dimensions called MyDevice3D and add the 3 variables to that type. Instead of extending BasicDevice for MyWidget and MyGadget, we will extend MyDevice3D.
Figure 1 below uses Edge2Web Director’s Hierarchy renderer to show an asset hierarchy that models MyDevice3D (among other elements). Figure 2 uses Director’s free Asset Browser app to show asset variables defined on the MyDevice3D type.
Figure 1: Asset Type Hierarchy with MyDevice3D highlighted (click image to enlarge)
Figure 2 – Asset Variables defined on the MyDevice3D type (click image to enlarge)
Approach 2 – Static Aspect
Using this technique, we will create an asset type called MyWidget and extend a core asset type of BasicDevice. However, instead of adding 3 variables, we will create a new static aspect. We’ll call the static aspect “Dimensions” and use it for our height, width, and depth variables. We will add this aspect to our MyWidget type, providing a place to hold our dimensions. We will then create a new widget of type MyWidget and set these static aspect variables appropriately.
Now let’s create the new device type called MyGadget. All we have to do is add the static aspect type to MyGadget, thereby creating a place to hold the gadgets’ dimensions. No need to extend a common base type for reuse and all our dimensions are grouped together.
Another nice feature of static aspects is that they are named in the asset type so we can define multiple instances of an aspect type in an asset type. You might ask why we would need that. Let’s extend the dimensions use case by adding PackagedDimensions – the outer dimensions of MyGadget after it has been packaged. Adding the PackagedDimension aspect to MyGadget is easier and less brittle than maintaining three different asset variables with unique names. Figure 3 uses Director’s free Asset Type Browser to display our MyWidget Asset Type with two sets of Dimensions.
Figure 3: MyWidget Asset Type with two sets of dimensions (click image to enlarge)
So when would we use asset variables, having now seen the powerful benefits of static aspects? Asset variables are best used for stand alone asset traits such as a manufacturer, serial number, or link to a product catalog reference. For those familiar with object-oriented concepts, a static aspect is analogous to an interface, where many asset types (object classes) can expose the same aspect (interface).
Applying the same o-o concepts, asset variables are properties of an object. In a single inheritance system (like the asset type model), reuse of asset variables requires the asset type to be extended.
The MindSphere asset type system is flexible and powerful for digitally modeling physical assets. While there are different ways to achieve your asset modeling goals, make sure you keep reuse and variable relationships in mind during your design process. Hopefully this post gives you ideas about how MindSphere aspect types – specifically static aspects – can help you on both those fronts. The screen shots provided in this post were taken using Edge2Web Director, which understands MindSphere assets as well as the types they are built upon.
In the next edition of this series, we’ll examine a use case for static aspects in storing spatial information like floor plans associated with area assets.
MindSphere Reference Links
Modeling Hierarchical Asset Structures: https://developer.mindsphere.io/apis/advanced-assetmanagement/api-assetmanagement-samples-breadcrumbs.html
Using Default Values in Asset Types: https://developer.mindsphere.io/apis/advanced-assetmanagement/api-assetmanagement-samples-defaultvalues.html