Many assets like trucks, containers, or vending machines do not have intelligence or connectivity built into them. To enable M2M monitoring and tracking, a wireless tracking device can be attached to these assets, and the tracking device report on behalf of the asset. The Axeda Platform supports this and similar configurations by allowing you to associate the tracking device to the asset.
This article will discuss both how associations work in the platform, and how they are used in real-world applications. In practice, there are several distinct use cases, such as:
- A tracking device attached to an asset, such as a wireless transponder attached to a container;
- An asset which is currently being handled by another asset, such as a truck hauling a container, or a machine processing a particular batch of material;
- A complex system (with a single communications device) which is modeled as a number of distinct assets. This use case is covered in a separate article, Modeling Complex Systems.
The basic idea of associations is that one asset will report data for another: the tracking device will report its location on behalf of the truck, the machine will report the weight of the batch, or the system will forward information from its components.
One thing that these associations have in common is that you can't rely on them being permanent, so any solution will have to make it easy to, say, replace the tracking device in a truck. See this example of a rule that creates associations.
Two kinds of associations
The Axeda Platform provides two kinds of associations: asset-to-asset associations and model-to-model associations. We'll normally abbreviate these as asset associations and model associations.
An asset association links one particular asset to another (or to itself). The effect of an asset association on its own is that the location and alarms of the source will be treated as though they came from the target.
Model associations map data items in one model to data items in another model. For example, data item Vx in model M1 (the source) could be mapped to data item Vy in model M2 (the target). We'll write that as M1(Vx) -> M2(Vy).
When an asset of model M1, say A1, is linked (via an asset association) to an asset of model M2, say A2, the effect is that when A1 reports Vx, the system will treat that as though A2 has reported Vy.
An example
Suppose we have a tracking device A1 attached to a truck A2. In the system, both A1 and A2 are represented as assets, so we might have the following details:
| Asset | Tracking Device | Truck |
| Serial # | A1 | A2 |
| Model | M1 | M2 |
| Data items | v1, v2, v3 | speed, temp |
The tracking device includes a GPS receiver to retrieve its location, and it can use this to calculate its speed, which is reported in data item v1. It has a temperature sensor which is reported in data item v2 and a battery level indicator which is reported in data item v3.
Now we'll set up the right asset-to-asset and model-to-model associations so that the data from the tracking device ends up where we want it on the platform.
Step 1: Collecting the speed and temp of the truck
In order to collect the truck's speed and temp from the tracking device, we want to define the mapping between the data items reported by the tracking device, and the data items in the truck model that they represent:
M1(v1) -> M2(speed)
M1(v2) -> M2(temp)
This mapping applies whenever we create an asset association from a model M1 tracking device to a model M2 truck. We can do this with the asset association:
A1 -> A2
In this case, when the tracking device A1 reports v1, the platform will treat it as though the truck A2 has reported speed. And if A1 reports v2, the platform will treat it as though A2 has reported temp. And a location report or alarm coming from A1 will be treated as though it came from A2.
If we buy another truck, A20, with another tracking device, A10, we just need to create another association:
A10 -> A20
The model association applies to each tracking device and truck that we associate.
However, there is no mapping defined for the v3 (battery voltage) variable of the tracking device A1. In the absence of a mapping, it will be ignored. To solve this problem, we'll need to associate the tracking device model with itself.
Step 2: Collecting battery voltage from the tracking device
Continuing our example, even though the main purpose of the tracking device is to report on the truck it is attached to, we still want to see battery voltage reports from the tracking device itself. We can do that by associating the tracking device's model to itself. To make it more readable, we'll add a new 'voltage' item to M1 and use that:
M1(v3) -> M1(voltage)
The result of these two model associations, one from M1 to M2 and the other from M1 to itself, is that the tracking device A1 can report all three values, v1, v2 and v3, and the right thing will happen: the platform will treat this as speed and temp coming from A2 and voltage coming from A1.
Step 3: Tracking the location of the tracking device
Because the tracking device A1 is associated with the truck A2, A1's location reports are associated with A2, and we can't find out the location of A1, at least not directly. It may not be common, but it may occasionally be convenient to ask, where is the tracking device A1?
In order to do that, we simply associate the asset A1 with itself. A1 is therefore associated both with itself and with A2. When A1 reports its location, the platform will treat that as two reports, one coming from A1 and one coming from A2. If both models (M1 and M2) had MobileLocation expression rules, both would be executed.
Step 4: Reporting the temperature for both assets
The tracking device A1 reports a temperature which we might want to treat differently when applied to the truck versus the tracking device itself. For example, a one-second temperature spike to 200F might damage the tracking device without affecting the truck. Vice versa, a sustained temperature of 120F might damage the truck (or at least its contents) without affecting the tracking device.
We can provide separate temperature rules for the tracking device A1 and the truck A2 by adding the data item 'temp' to M1 (the tracking device's model) and add the following data item mapping to the existing M1 -> M1 model association:
M1(v2) -> M1(temp)
so when the tracking device A1 reports a value for v1, the platform will treat this as reporting temp for A1 as well as temp for A2. The expression rule for M1 (applying to the tracking device A1) might simply need to check:
IF: temp > 200
THEN: CreateAlarm("Temperature spike in tracking device", 500)
and the expression rule for M2 (applying to the truck A2) could call a custom object to check for a sustained temperature rise:
IF: temp > 120
THEN: ExecuteCustomObject("LogTemperature", temp)
Let's review all the associations we've set up. First, the asset associations:
A1 -> A1
A1 -> A2
and second, the model associations:
M1(v1) -> M2(speed)
M1(v2) -> M2(temp)
M1(v2) -> M1(temp)
M1(v3) -> M1(voltage)
We could keep going, but the point is clear: a single data item, location or alarm from a source asset can translate into values or events from multiple target assets.
Accommodating Changes
Once you have set up model associations for the devices and assets you are interested in, you don't need to change them unless you need to define a new model (such as a new model of tracking device or truck) or for some reason the configuration of your models changes. For example, you might decide to add an additional temperature sensor to your refrigerated trucks.
As long as a model is defined, you can add as many assets of a given model as you like. Suppose you have defined a truck model, a tracking device model and a model-to-model association from the device to the truck. When you buy a new truck (serial number T01001) and a new tracking device for it (D02055), you can add the truck asset to the Axeda Platform with its serial number, and the tracking device with its serial number. You define the asset association:
D02055 -> T01001
Now the tracking device will report data on behalf of the truck. If for some reason the tracking device breaks, you can buy a new tracking device (say, D02056) and replace the asset association above with the new one:
D02056 -> T01001
Perhaps these this model of tracking device proves unreliable, and you decide to start using a newer model. You'll need to create a model-to-model association from the new tracking device model to your truck model, but you only need to do that once. Then you can continue as before, adding as many trucks and tracking devices as you like, and replacing the devices as needed. Whenever you install a tracking device of either model in a truck, you just have to declare an asset association between them.
What makes this asset association work is that the platform knows which model each asset is, and hence which model-to-model association(s) to use for a given asset-to-asset association.
