Step-By-Step Guide to Building an Asset Tracking System

Step-By-Step Guide to Building an Asset Tracking System

In this article, I will explain the technical details of an asset tracking system SSP implemented at MLGW. You might have seen this project presented live at GeoConX 2016 by MLGW’s Arnisa Davis and SSP’s Joaquin Madrid. In case you missed it, here is the written project details.

The Role of Asset Tracking


asset tracking

SSP implemented a rule-driven, fully configurable asset tracking system into MLGW’s GIS.  The rules help determine:

  • What network elements will be tracked as assets.
  • What asset attributes will be monitored.
  • How and when these attributes may change.

The rules are coded in a fully configurable component. This lets the asset tracker:

  • Assign and maintain asset numbers.
  • Track asset creation.
  • Track asset-information updates.
  • Track asset removal.

Beyond Asset Tracking: Helping Workflows with Related Integrations


Besides these asset tracking capabilities, SSP has also built an SOA-based integration with Oracle eAM. The Oracle eAM is MLGW’s newly adopted Enterprise Asset Management System.

By having both asset tracking and an EAM, MLGW can provide all the required asset information from their GIS to their EAM.

So how did we build all of this?

Going Deep into Details: The Asset Tracking


The main worker of asset tracking is a GIS auto updater. The GIS updater tracks every edit in ArcMap for given set of feature classes within edited version. The GIS updater determines if an edit made by a GIS user must be tracked or not. It also determines what operation has been done to an asset: either a creation, update or deletion. You can see how this GIS updater is critical to creating any asset tracking system.

The interesting part here is that not every feature edit is considered an asset edit.

For example, a GIS user may edit a feature attribute (aka a GIS Update operation), but this attribute will not be valuable for the EAM. In this case, the GIS updater will simply skip this edit.

Another good example occurs when the GIS user changes the “owner” attribute; this will indicate that from now on, an asset should no longer exist in the EAM. From the GIS point of view, this was an edit. However, the smart updater knows that the EAM will consider this a deletion.

Creating the Rules


We designed the tracking system to have be driven by configuration. But as we know, configuration usually is a list of some core parameters; the code is the one that does all the logic based on these parameters. We needed something more. We wanted configuration to be responsible for the logic.

Help came from IT – my previous work experience includes building and configuration of Unix systems. If you ever had a chance to set up firewalls, mail servers or a filtering proxy, I am sure you know that rules drive all these smart systems. The basic idea of rules is that whatever item (e.g., an IP packet, e-mail, requested URL, or the GIS feature in our case) comes into a system is being conditionally compared — starting from the top of rule’s list and going down until item being accepted or rejected. Also, we know if there is no rule for an item, the default rule will be applied.

For asset tracking, every asset attribute is a rule or set of rules. A rule can be very simple, stating that the value of the asset attribute is just a value of the corresponding GIS attribute. Or, a rule can be more complex. It could parse multiple GIS attributes and, based on attribute values, set the specific asset attribute.

Finally, a rule can take only part of a GIS attribute value – for instance, the first N characters, only numbers, or only third letter in upper case.

Rules are the core of the whole asset tracking system. Even the deployment is based on rules — a script will create a GIS field only if such a rule exist. And a batch process will generate asset numbers for a set of features within feature class based on the rules for the feature class.

asset tracking

The Last Part of the System: Subtask


The subtask is the last component of the MLGW asset tracking system. The subtask gathers all the tracking records made by auto updater in a version. Then it generates additional asset attributes that have not been created by auto updater performance-wise. And finally, it posts everything into interface table.

Afterwards, it is up to the EAM to grab these records from interface table and proceed with them.


Which Asset Management is Right for You?

Looking to make a smart change?  Learn why Cityworks Asset Management is not just for cities any more.


We Wrote the Book

The Indispensible Guide to ArcGIS Online

Download It for Free

Konstantin Korchakov

Senior Software Engineer

Joaquin Madrid, Ph.D.

Principal Solution Engineer

What do you think?

Leave a comment, and share your thoughts

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.