Asset Premises Tracking Using Disruptive Technologies Sensors
Managing large amounts of assets can be a logistical challenge. Whether it is storage containers spread over several warehouses or components in a supply chain, the ability of real-time identification of an asset's location can save time and money. A solution requiring human intervention through manually scanning and logging individual units as they move between locations can be suboptimal due to human error, slowdowns, or sheer volume. Instead, a fully automated system that tracks, stores, and logs environmental temperature and humidity could prove useful.
In this application note, a method of using Disruptive Technologies (DT) Wireless Sensors for tracking assets between locations is presented. With their small size and long-lasting battery life, the aim is to highlight how simple it is to get started with an asset tracking system using the DT solution. As all the necessary functionality is already native to the sensors and cloud connectors (CCON), the application focuses on aggregating and presenting the information with an example code repository. Figure 1 shows the timeline of a single asset tracked between 4 unique locations over a few weeks.
Figure 1: An asset tracked between 4 locations over a few weeks. Here, locations 0, 2, and 3 each consist of a single CCON, while location 1 is larger and combines three different CCONs to cover the area.
For best asset tracking performance, some considerations should be had when placing sensors and Cloud Connectors (CCONS).
Sensors should be placed so that there are no obvious hindrances to the radio communication between the sensor and CCON. As the sensors are quite robust, it is recommended that the sensors are placed on the outside of the asset, if possible. If placed on the inside, make sure that the object encapsulating the sensor does not form a Faraday Cage, which can completely or significantly reduce the range.
Regarding CCON placement, the simplest and most robust implementation is one that has predefined locations far enough apart, say different buildings, so that a sensor only ever is within range of a single location. A location can be defined by at least one CCON, but if coverage is desired over a larger facility, several CCONs can be combined. If an application with more closely spaced locations is desired, time-averaging could be applied to the data to counter the natural noise in radio signal strength. For this, consider using the DT EN12830 Wireless Sensor with a more rapid 5.5-minute heartbeat instead.
Figure 2: By placing a Disruptive Technologies Wireless Sensor, one or several assets can be tracked between locations in a supply chain.
The implementation is built around using the DT Developer API to interact with a single DT Studio project containing all sensors that should be tracked. If not already done, a project needs to be created and configured to enable the API functionality.
The 'track' label should be given to any sensor included in the asset tracking scheme. Labels can be set in the sensor details page in DT Studio, as shown in figure 3. If a sensor resides in a different project, the option for moving it can also be found here.
Figure 3: Sensor overview page in DT Studio where labels can be assigned.
An example code repository is provided in this application note. It illustrates one way of implementing asset tracking using the DT solution and serves as a precursor for further development and implementation. It uses the Developer API to interact with the DT Studio project.
The code has been written in and tested for Python 3. Required dependencies can be installed using pip and the provided requirements text file. While not required, it is recommended to use a virtual environment to avoid package conflicts.
pip3 install -r requirements.txt
Using the details found during the project authentication section, edit the following lines in sensor_stream.py to authenticate the API with your DT Studio project.
USERNAME = "YOUR_SERVICE_ACCOUNT_KEY_ID"
PASSWORD = "YOUR_SERVICE_ACCOUNT_SECRET"
PROJECT_ID = "YOUR_PROJECT_ID"
If the example code is correctly authenticated to the DT Studio project described above, running the script sensor_stream.py will start streaming data from each labeled sensor in the project for which tracking is commenced in realtime.
For more advanced usage, such as looking at tracking data for historical events, one or several flags can be provided upon execution.
usage: sensor_stream.py [-h] [--starttime] [--endtime] [--timeout]
Implementation For Tracking Assets Between Locations of Cloud Connectors.
-h, --help show this help message and exit
--starttime Event history UTC starttime [YYYY-MM-DDTHH:MM:SSZ].
--endtime Event history UTC endtime [YYYY-MM-DDTHH:MM:SSZ].
--timeout Seconds before an asset is considered between location.
--no-plot Suppress streaming plot.
The arguments --starttime and --endtime should be of the format YYYY-MM-DDThh:mm:ssZ, where YYYY is the year, MM the month, and DD the day. Likewise, hh, mm, and ss are the hour, minutes, and seconds respectively. Notice the separator, T, and Z, which must be included. It should also be noted that the time is given in UTC. Local timezone corrections should, therefore, be made accordingly.
By providing the --timeout argument, the seconds before an asset is considered in none of the pre-defined locations can be updated. For instance, when in transit between locations where no CCON is within reach, the implementation will note a timeout represented as a hole in the timeline. By default, this value is set to 3600 seconds, 1 hour.
All the necessary features required for building a simple tracking system for multiple assets and locations are already native to the DT API. Therefore, it is only necessary to fetch and categorize the information, presenting it in a readable manner. Therefore, the process can be done quickly and efficiently without heavy processing, making it feasible to implement it on almost any device.
When fetching either historical data or streaming real-time events, for each CCON a sensor is within range of, an individual 'networkStatus' event is generated and available through the API. The event JSON contains, among other things, the CCON name, signal strength, and timestamp information. Using this, by implementing a simple buffering scheme, the related networkStatus events for all the CCONs communicating with the sensor can be grouped. Then, if one or several CCONs are mapped to a given location, it can be assumed that the sensor, and therefore asset, is also at that location. Figure 4 shows the signal strength matrix of a single sensor in time, where each row represents the signal strength of one CCON. It can clearly be seen that CCON 1, 2, and 3 are all in the same location due to their overlapping signals.
Figure 4: The raw signal strength data of a sensor. Each column represents an event in time, and each row a CCON signal strength for each event. The red line is the strongest connection for each event.
If it is known that each predefined location and their related CCONs are outside of each other's range, the location can be determined by finding each event's maximum strength. However, in cases where the ranges overlap, an evaluation scheme for determining the most likely location should be implemented. While it is not the focus of this application note, this could be solved by including temporal averaging between events.
To relate one or several CCONs to a location, the included file ./config/locations.py can be edited. Each element in the list represents one location, where a name and a list of CCON identifiers should be provided. A location can contain any number of CCONs, but stacking them on top of each other would be redundant. The recommended best practices for mounting CCONs can be found in this guide.
locations = [
'name': 'loc 0',
'name': 'loc 1',
'ccons': ['ccon_1_id', 'ccon_2_id', 'ccon_3_id']
If a sensor communicates with a CCON that is not defined in the locations list it will be appended to the end and categorized as an unknown location.
After the signal strength data has been aggregated, and the closest location has been determined, all prior information can be combined into a choice representation. Here, as shown in figure 5, a timeline-based visualization where the y-axis represents the different locations and related CCON groupings have been chosen. As only four different assets are tracked in this implementation example, this method is simple, yet clear. If many assets are tracked at once, a more statistical approach could give a better overview.
Figure 5: Four individual assets tracked over a few weeks between four predefined locations.