Asset tracking and remote monitoring: choosing what to actually build

Two problems, frequently conflated

Requests in this area usually arrive as “we want to track our assets”, and that phrase covers two quite different engineering problems.

Where is it. Location, movement, arrival and departure. Applies to things that move: vehicles, containers, tools, trailers, plant hired out to sites.

How is it. Condition, operation and status. Applies to things that stay put but are distributed: tanks, pumps, cabinets, remote stations, equipment at customer premises. For rotating plant specifically, see condition monitoring for motors, pumps and compressors.

The technologies, power budgets and economics differ substantially between them, and systems designed to do both without acknowledging the distinction tend to compromise on each. Establishing which problem you actually have, or whether you genuinely have both, is the first step.

A useful test: if the asset never moved, would the system still be worth having? If yes, the real requirement is condition monitoring and location is secondary. If the only question is whether something arrived, condition measurement may be unnecessary.

Positioning, and what each approach costs

Two points worth drawing out. First, combinations are normal: satellite outdoors falling back to cell estimation when no fix is available, or beacons indoors with satellite outside. A tracker that reports “no position” whenever it goes inside is less useful than one that reports a coarse position.

Second, passive tags are underrated. Where the question is whether something passed a gate, left a store or arrived at a bay, a tag with no battery read at a fixed point answers it for a fraction of the cost of an active tracker, and needs no maintenance.

Power, which decides tracker design

On a battery-powered tracker, the dominant consumer is usually not the radio but the position fix, which surprises people coming from other connected products.

A satellite receiver starting with no recent information has to search for signals, and that search can take a long time with the receiver drawing current throughout. Starting with recent satellite information available makes the fix dramatically quicker, which is why fetching that information over the network, or retaining it between fixes, has such a large effect on battery life.

The design levers follow from that.

• Fix less often. The single largest lever, and usually the one with least impact on usefulness.
• Fix on movement rather than on a timer. An asset that has not moved does not need a new position. A motion sensor waking the device costs almost nothing and eliminates most fixes.
• Help the receiver start warm. Retaining timing and satellite information, or supplying it over the network, shortens the fix and therefore the energy per position.
• Accept a coarser position when the accurate one is expensive. If no fix is available quickly, reporting a cell-based estimate may be better than continuing to search.
• Batch and send. Several positions in one transmission costs far less than one transmission each.

The wider energy design is covered in battery life in connected devices, and the choice of radio in choosing IoT connectivity.

Build, buy, or subscribe

Unlike most areas of industrial engineering, tracking has a mature market of off-the-shelf products, and building custom hardware is frequently the wrong answer.

The honest advice for a first deployment is usually to start with off-the-shelf equipment. It answers whether the data is useful at all, which is the question that matters, and it does so in weeks rather than months. If the data proves valuable and the fleet grows, the economics of subscription fees eventually justify building, and by then the requirements are known.

Custom hardware is genuinely warranted where the mounting or environment defeats standard products, where additional measurements are needed alongside position, where the tracker is part of a product you sell rather than equipment you operate, or where fleet size makes recurring fees the dominant cost.

The question worth asking a platform vendor early: can you export your data, in bulk, in a usable form, and what happens to it if you leave. The answer determines whether a later migration is feasible.

Getting a fix faster, which is the whole battery problem

Because position acquisition dominates tracker energy, the techniques that shorten it deserve more detail than they usually get.

A satellite receiver needs three things to compute a position: which satellites are overhead, precise timing, and signals from enough of them. Starting with none of that, it must search across possibilities, and the search is what consumes time and current. Starting with recent information about satellite positions and an approximate location narrows the search dramatically.

Retain what you learn. A device that keeps its last known position, the time, and recent satellite information can start a subsequent fix knowing roughly where and when it is. This requires the information to survive between wake cycles, which means either a small always-on domain or non-volatile storage, and it is a design decision rather than an afterthought.

Supply the information over the network. Where a connection is available, downloading current satellite data is far quicker than deriving it from the satellites themselves. This costs a small amount of data and saves substantially more energy than it consumes, which makes it worthwhile on almost any connected tracker.

Cap the attempt. A receiver searching indoors will search indefinitely and flatten the battery. A time limit, after which the device gives up and reports a coarse position or no position, prevents a device that has been taken inside from exhausting itself.

Consider computing the position elsewhere. Some designs capture raw satellite measurements briefly and send them to a server to compute the position, which shortens the time the receiver must be powered. This trades network data for energy and suits devices where fixes are infrequent and battery life is paramount.

Use motion to decide. An accelerometer consuming almost nothing can determine whether the asset has moved since the last fix. For assets that are stationary most of the time, which is most assets, this eliminates the majority of fixes and is usually the single largest saving available.

Geofencing, and where to evaluate it

A geofence is a boundary that produces an event when an asset crosses it: arriving at a site, leaving a yard, entering an area it should not.

Where the crossing is detected matters more than it appears. Evaluating the boundary on the server requires a continuous position stream, which is exactly the expensive behaviour described above. Evaluating it on the device means the device knows the boundary, tracks its own position, and transmits only when something happens.

For battery trackers this is transformative: a device reporting only arrivals and departures may transmit a handful of times a day rather than continuously, with the corresponding effect on life and running cost.

The trade-off is that changing a boundary means updating devices, which requires a configuration path and a way to confirm each device has the current set. That is device management work, as described in cloud backends and dashboards.

Connectivity for things that move

A moving asset presents a connectivity problem that a fixed one does not, and it rules out several options that would otherwise suit.

Mobility constrains the choice. Some low-power cellular variants handle movement between cells poorly, which matters for anything travelling. Technologies depending on local infrastructure, such as private gateways or beacons, work only within their own coverage, so an asset leaving the site goes dark unless something else takes over.

Crossing borders complicates it further. An asset travelling internationally raises roaming arrangements, differing regional frequency allocations, and in some countries restrictions on devices operating indefinitely on a foreign network. These are covered in choosing IoT connectivity, and they matter more here than in almost any other application because the asset physically leaves the jurisdiction it was provisioned in.

Coverage varies along a route rather than at a point, which makes a site survey inapplicable. The realistic approach is to assume gaps, buffer locally, and forward when a connection returns. A tracker that only reports when connected will have gaps exactly where coverage is poor, which is frequently where you would most like to know an asset has been.

Dual arrangements are common. A satellite fallback for assets that travel beyond terrestrial coverage, or a local link that hands off to cellular when the asset leaves a site. Each adds cost and complexity, and whether it is justified depends on how often assets go beyond coverage and what not knowing costs.

The design principle that carries across all of this: a tracker should behave sensibly when it cannot report, continuing to record and forwarding later, rather than treating connectivity as a precondition for doing its job.

Remote monitoring of fixed assets

The other half of this subject: equipment that stays where it is but is distributed across sites nobody visits often. Pumping stations, tanks, cabinets, remote plant, equipment installed at customer premises.

The engineering differs from tracking in several ways.

• Power is often available, or at least a larger battery or solar is practical, which removes the constraint that dominates tracker design.
• Connectivity is the harder problem. Remote sites have poor coverage, and the device must tolerate long outages with local buffering.
• The measurements matter more than position. Level, pressure, flow, temperature, run state, and whether anything has been tampered with.
• The value is usually avoided visits. A site visited weekly to read a gauge can be visited when there is a reason, which is frequently where the business case lives.
• Alarms need to reach someone. A tank overflowing at a site nobody is at is exactly the case where an alert must be delivered reliably and to a person who can respond.

The measurement side is covered in sensor selection and signal conditioning, and where the equipment predates any interface, in legacy machine retrofit.

Measuring more than position

Position alone answers fewer questions than expected, and a tracker that also measures something about the asset is considerably more useful for very little additional cost.

• Movement and orientation. An accelerometer is cheap, consumes almost nothing, and enables motion-triggered fixes, impact detection, and knowing whether equipment has been tipped or dropped.
• Run hours. Whether the asset was working rather than merely present. This can come from a vibration threshold, a current measurement, or the equipment’s own output, and it is usually what turns a tracking system into a utilisation system.
• Temperature. Essential for anything with a cold chain requirement, and useful generally as context.
• Door or lid state. For containers and cabinets, when something was opened is frequently more informative than where it was.
• Battery or supply voltage of the asset itself, distinct from the tracker’s own, which for vehicles and equipment left standing predicts a failure to start.
• Tamper and enclosure state. Whether the device has been interfered with.

The accelerometer deserves particular emphasis because it earns its place several times over: it reduces energy consumption through motion triggering, provides utilisation data, detects impacts, and gives a cross-check against implausible position reports. Very few additions to a tracker offer that much for so little.

Cold chain, as a specific case

Monitoring temperature through transport has requirements that general tracking does not. The record usually needs to be complete rather than sampled, because a gap covering an excursion is the gap that matters. It frequently needs to survive periods with no connectivity, which means local logging with later upload rather than live reporting. And where the record has contractual or regulatory weight, traceability of the sensor’s calibration becomes part of the system rather than an operational detail, along the lines described in sensor selection and signal conditioning.

Attaching the device to the asset

A tracker is only useful if it stays on the asset and keeps working, and the physical design carries more risk than the electronics.

• Mounting. Magnetic, bolted, adhesive or enclosed. Each trades installation speed against security and survivability, and vibration defeats several of them over time.
• Antenna position. A satellite receiver needs sky visibility. A tracker mounted inside a metal container or under a steel panel will not obtain a fix, and this is a common reason a deployment underperforms.
• Environment. Outdoor trackers face rain, washdown, temperature extremes, ultraviolet exposure and impact. Ingress rating and material choice need to match reality rather than a nominal specification.
• Tamper. Whether removal should be detected and reported, which matters for high-value assets and for anything where a person might prefer not to be tracked.
• Serviceability. Whether a battery can be replaced in the field, or whether the unit is sealed and replaced whole. This decision interacts with fleet logistics substantially.

Installing across a fleet, which is most of the project

Fitting one tracker takes minutes. Fitting four hundred, across sites, on equipment that is in use, is a logistics exercise that routinely takes longer than everything else combined and is rarely scheduled properly.

• Access to the assets. Equipment out on hire, vehicles in use, plant on customer sites. Gathering them is often impossible, so installation happens opportunistically as assets return, which stretches the rollout over months.
• Who fits them. Trained installers give consistency and cost more; site staff are cheaper and produce variation in mounting quality that shows up later as unreliable devices.
• Recording what went where. The single most error-prone step. A device fitted to an asset without the association being recorded correctly produces data attributed to the wrong thing, which is worse than no data. A scan-based process, where installers scan the device and the asset, removes most of this.
• Verifying each installation. Confirming that a device reports, and reports a plausible position, before the installer leaves. A device that was fitted but never worked is expensive to revisit.
• Mounting consistency. Position affects antenna performance, so a documented standard with a photograph is worth more than a verbal instruction.
• Dealing with the exceptions. Some assets will not accept the standard mounting, and a plan for those prevents them being quietly skipped and forgotten.

A practical approach is to install in batches with a verification step at the end of each, rather than fitting everything and checking afterwards. Problems found in the first batch, whether mounting, association or coverage, then get corrected before they are replicated across the fleet.

Managing a fleet of trackers

A hundred devices distributed across sites is an operations problem as much as a technical one, and the difficulties are consistent.

Battery replacement. Unless devices report their reserve, the first sign of a flat battery is an asset that has quietly stopped reporting, and by then you have lost the data. Reporting reserve turns an unpredictable stream of failures into a scheduled round.

Knowing which device is on which asset. Devices get swapped, moved and replaced. A record that says device A is on asset B, maintained as changes happen, is what allows history to be reconstructed. Without it, an asset’s record is fragmented across whichever devices were attached at the time.

Finding the silent ones. A report of devices that have not been heard from recently, reviewed regularly, is the single most useful operational tool. Devices fail, are removed, get buried under a load, or sit somewhere with no coverage.

Coverage blind spots. Some locations will not work, and knowing where they are prevents repeated investigation of the same non-fault.

Tracking people, which is what vehicle tracking often is

This deserves direct treatment because it is frequently handled badly and carries genuine obligations.

A tracker on a vehicle driven by an employee records that person’s movements, including outside working hours if the vehicle is taken home. Whatever the stated purpose, the data reveals individual behaviour, and in most jurisdictions that brings requirements around informing people, having a lawful basis, limiting purpose, restricting access and retaining data no longer than necessary.

The specific obligations vary by country and by employment arrangement, and we are engineers rather than legal advisers. Take advice for your jurisdiction before deploying.

What we would say from an engineering standpoint is that systems handling this well share some characteristics. People are told clearly what is recorded and why, before deployment rather than after. Data outside working hours is either not collected or is handled differently. Access is restricted to those with a defined reason. Retention is bounded rather than indefinite. And the stated purpose matches the actual use, because a system introduced for vehicle security and then used for performance management produces justified resentment and, in some jurisdictions, a problem.

The engineering decisions follow from that: whether to collect continuously or on events, whether to record detailed routes or only site arrivals, and how long to retain. A design that collects only what the stated purpose requires is both easier to defend and cheaper to operate.

Turning positions into things people use

A map with dots on it is where most tracking systems stop, and it is rarely what makes them valuable. The useful output is derived: journeys, dwell times, utilisation, exceptions.

• Journeys. Grouping positions into trips with a start, an end and a route, which is far more usable than a stream of points. The logic is fiddlier than expected, because deciding when a journey ends requires distinguishing a genuine stop from a traffic queue.
• Dwell time. How long an asset spent at a location, which is what answers questions about utilisation, site visits and where time goes.
• Utilisation. How much of the time an asset was working rather than merely present. This usually needs something beyond position, such as run hours or a vibration indication, and it is frequently the figure that justifies the whole system.
• Exceptions. Arrivals at unexpected places, absence from an expected one, movement outside hours, prolonged stillness. These are what people want notified rather than discovering in a report.
• Idle and overdue. Assets that have not moved for a long period, which frequently reveals equipment that could be redeployed or is being paid for unnecessarily.

That last one recurs. The most common valuable finding when a fleet is first instrumented is not theft or misuse but under-utilisation: assets sitting idle at one site while another hires in replacements. Discovering that usually pays for the system faster than any other outcome.

Maps are a poor primary interface

A map answers “where is this one thing” well and “what should I do today” badly. For daily use, a list of exceptions, an asset with its current status, or a utilisation summary is more actionable than a view of everything at once.

A good arrangement puts exceptions and status first, with the map available when somebody needs to see a specific asset or route. The same audience-first principle described in cloud backends and dashboards applies: build the view around the decision, not around the data.

Data, and how it accumulates

Position data grows quickly and has properties that make it awkward.

A device reporting every minute produces well over a thousand points a day, and across a fleet the volume becomes significant. The useful structure separates the raw position history from the derived events that people actually look at: arrivals, departures, journeys, dwell times. The events are small, valuable indefinitely, and what dashboards query. The raw history is large and mostly useful for a limited period or for reconstructing a specific question.

Two further considerations. Positions are not always accurate, and a poor fix can place an asset somewhere implausible. Filtering obviously wrong positions, using reported accuracy where available, prevents a map showing an asset jumping across a city. And asset identity should be separate from device identity, so that replacing a tracker does not break the asset’s history, the same principle described in cloud backends and dashboards.

Making the case, and what it usually rests on

Tracking projects are proposed for security and justified by something else, which is worth knowing when building the case.

Theft recovery is the reason most often given and rarely the largest return. It matters for high-value mobile assets, and the value is real but episodic.

Utilisation is usually the larger number. Knowing that assets sit idle at one location while another hires replacements changes purchasing and allocation decisions, and that effect recurs continuously rather than occasionally.

Avoided journeys justify most fixed-asset monitoring. A site visited on a schedule to check a gauge can be visited when there is a reason, and for organisations with many remote sites that is a substantial ongoing saving in time, mileage and staff.

Billing and evidence. For hired equipment, accurate run hours or on-site time can directly affect revenue, and a record of where an asset was resolves disputes that would otherwise be settled by argument.

Compliance and duty of care, where a record is required or where knowing that a lone worker’s vehicle has arrived matters.

The practical approach is the same as elsewhere: pick one measurable claim, instrument a subset, run for a defined period, and compare against criteria agreed beforehand. Fleet-wide deployment on the strength of a vendor’s case study tends to produce a system that reports faithfully and changes nothing.

What a pilot should establish

• Does the technology work at your sites? Coverage and fix reliability at the actual locations, including the awkward ones.
• Does the battery life hold? Measured over a real period with real movement patterns, not estimated.
• Does the mounting survive? Vibration, washing, weather and handling.
• Is the data usable? Not merely present, but sufficient to answer the question that motivated the project.
• Will anyone act on it? The measure that decides whether the rollout is worth anything.

Three worked situations

Plant hired out to customer sites

Equipment that moves between sites and needs to be located and monitored for utilisation. Satellite positioning with motion-triggered fixes, cell fallback where no fix is available, and engine run-hours from a simple sensor or the equipment’s own output. Geofences evaluated on the device so arrivals and departures are reported rather than continuous position. Reporting daily when stationary, more often when moving. The business case is usually utilisation and recovery rather than continuous visibility.

Tools and containers within a site

Items that do not leave the premises but are routinely mislaid. Satellite positioning is unnecessary and would not work indoors. Bluetooth tags read by fixed receivers give zone-level location, which answers the actual question, which is usually which building or bay rather than which metre. Passive tags at chokepoints are an even cheaper option where knowing when something passed a point is sufficient.

Distributed fixed installations

Tanks or stations across a region, visited on a schedule regardless of need. Measurement of level or condition, cellular connectivity chosen for coverage at the specific sites rather than from a map, solar with storage sized for the worst month, local buffering for outages, and alerting that reaches a person. Position is fixed and recorded once. The value is in replacing scheduled visits with triggered ones.

When the answer is a process change rather than a system

Part of scoping honestly is recognising when tracking is treating a symptom.

Assets going missing is frequently a sign that nobody is accountable for them rather than that nobody can find them. Where a clear owner and a simple booking-out procedure would solve it, a tracking system adds cost and continues to report the same losses in more detail.

Equipment sitting idle is usually a scheduling and visibility problem between departments rather than a location problem. Tracking will quantify it, which is genuinely useful, and the fix is organisational.

Sites being visited unnecessarily is sometimes a policy that has never been questioned rather than a lack of information. It is worth asking whether the visit could stop without any monitoring at all, because occasionally the answer is yes.

None of this argues against tracking. It argues for being specific about the problem, because a system deployed against a vague objective produces data that confirms the objective was vague. Where the process change is available and cheaper, doing that first and instrumenting afterwards, if still needed, is the better sequence.

It is also worth being clear that measurement itself changes behaviour. Assets that are known to be tracked tend to be returned more reliably, independently of anyone looking at the data. That effect is real and it is a reason to be straightforward with people about what is being recorded, rather than relying on them not knowing.

Mistakes worth avoiding

• Specifying accuracy without a decision behind it. Metre precision is expensive and rarely changes an action.
• Continuous reporting by default. On-event reporting usually answers the same questions for a fraction of the cost.
• Server-side geofencing on battery devices. Requires exactly the position stream you are trying to avoid.
• Mounting where the antenna cannot see sky. A common cause of a deployment that underperforms.
• No battery reporting. Failures then arrive as silence, after the data is lost.
• No device-to-asset record. History fragments the first time a tracker is swapped.
• Trusting every position. Poor fixes produce implausible jumps that undermine confidence.
• Deploying people-tracking without telling people. A legal and relational problem, entirely avoidable.

How we help

• Requirements. Establishing what decision the data informs, which usually narrows the technology considerably.
• Technology selection. Positioning approach, connectivity and power, assessed against your sites rather than in the abstract.
• Hardware. Tracker or monitoring device design where off-the-shelf equipment does not suit the environment or the mounting.
• Firmware. Fix strategy, motion triggering, on-device geofencing, buffering and power management. See embedded firmware practice.
• Backend. Position and event storage, device-to-asset mapping, dashboards and alerting.
• Fleet operations. Battery reporting, silent-device detection and the records that keep a deployment manageable.

Related service pages: IoT development and fleet and smart infrastructure.

Security, and what a tracker is worth stealing

A tracking system is a target in ways that other monitoring is not, because the data says where valuable things are.

The position data itself is sensitive. A list of where a company’s assets are, and when they are unattended, is useful to somebody planning to take them. Access control on that data matters more than on most operational data.

Devices get removed. Anyone taking an asset deliberately will look for the tracker. Concealed mounting, tamper detection and a report sent immediately on power loss all raise the effort required, and none makes it impossible.

Spoofing is possible. Satellite signals can be jammed or faked, and jammers are readily available. A device that suddenly reports an implausible position, or stops receiving signals entirely while the accelerometer says it is moving, is reporting something worth investigating. Detecting that disagreement is straightforward and rarely implemented.

The backchannel needs protecting. A tracker that accepts configuration or firmware without verification is a device somebody else can reconfigure or silence. The same principles apply as in device security and OTA updates.

Proportion matters here as elsewhere. A tracker on a skip needs less protection than one on high-value plant, and designing for the worst case across an entire fleet is expensive. But the asymmetry is worth noting: the device is cheap and what it protects may not be.

A short glossary

If you take one thing away

Almost every decision in this area follows from one question that is frequently skipped: what will somebody do differently because of this information.

If the answer is “dispatch the nearest unit”, you need current position with reasonable accuracy. If it is “know whether it arrived”, you need an event at a boundary. If it is “decide whether to buy another one”, you need utilisation over months and position barely matters. If it is “stop driving to a site to read a gauge”, you need a measurement and no position at all.

Each of those implies a different technology, a different reporting rate, a different power budget and a substantially different cost. Starting from the decision rather than from the technology is what produces a system that gets used, and it usually turns out to need less than was first specified. For the wider picture these systems sit within, see what industrial IoT actually is.

Questions we are asked about this

Common questions

What clients ask before starting

Do we need metre-level accuracy?

Usually not, and it is expensive. Ask what decision the location informs. Knowing an asset is on site, in a particular yard, or through a particular gate is enough for most purposes, and zone-level positioning costs a fraction of precise positioning.

Why do trackers use so much battery?

Mostly the satellite fix rather than the radio. Acquiring position from cold can take a long time with the receiver drawing current throughout. Reducing how often you fix, and helping the receiver start warm, matters more than almost anything else.

Can we track assets indoors?

Not with satellite positioning, which needs sky visibility. Indoors you need infrastructure: Bluetooth beacons for zone level, ultra-wideband for precision, or readers at chokepoints. Which is appropriate depends on whether you need to know the area or the exact position.

What about assets with no power at all?

Passive tags read at chokepoints require no battery and record movement past fixed points rather than continuous position. For pallets, tools and containers this is frequently sufficient and far cheaper than active tracking.

How often should a tracker report?

As rarely as the decision allows. Reporting frequency drives battery life and running cost directly, and most operations discover that hourly or on-event reporting answers their questions as well as continuous tracking does.

Is tracking vehicles the same as tracking people?

No, and the distinction matters legally and practically. A vehicle driven by an employee reveals that person's movements, which brings obligations around notification, purpose and retention that vary by jurisdiction. Take advice before deploying, and be transparent with staff regardless.

What is a geofence and where should it run?

A boundary that triggers an event when an asset crosses it. Evaluating it on the device means only the crossing is transmitted rather than a continuous position stream, which saves considerable energy and cost on battery trackers.

How do we manage batteries across hundreds of trackers?

By having devices report their own reserve, so replacement becomes a scheduled round rather than a series of failures. Without that, the first sign of a flat battery is an asset that has silently stopped reporting.

Start a conversation

What do you need to know, and why?

Tell us what the assets are, where they go or where they sit, and what decision the information would change. That usually determines the technology quickly.

Leave empty

Your name *

Email address *

Company

Country *

What are you working on? * I agree that iTechGeeks may use these details to respond to my enquiry. Privacy policy. Send enquiry ↗

Prefer email? Write to info@itechgeeks.in