Welcome to My Logistics Magazine. UK Focused Global Outlook.
Publish
Advertise
My Logistics Magazine - Advertise

Advertising Opportunities

Advertise on My Logistics Magazine and connect with a highly targeted audience of logistics professionals and enthusiasts.

We provide a range of advertising options, such as banner ads, sponsored content, job listings, and social media advertising.

This month, Derek looks at cost-efficient temperature logging and real-time alarms during transit.

I’ve had so much response to my article about temperature monitoring in small delivery vehicles that I’m going to expand on it as people have requested, with more detail concerning use and running costs.

To refresh your memory, we were talking about the dangers of fluctuating temperature during a delivery and how a load can partly thaw and refreeze during a journey and still present upon arrival as correct. Only when the historic data log is checked will the danger be revealed – by which time it’s too late, of course.

So let’s take a step back. You may currently have a datalogger which your people remove each time a vehicle returns to base, download it to a computer, reset it and put it back in the van. If you have 20 vans that’s a lot of work each day. There’s also the danger that the wrong logger goes back in the wrong van and then you mix the data. Don’t laugh, it happens.

Or you may now be using (or considering) radio transmitted recording in vehicles. I’m talking now about products that record their data inside a little radio transmitter, with the advantage is that no one has physically remove them.

There’s a little radio receiver in the loading dock and when the trucks come back it detects the van and automatically backfills the data into the database.

All well and good? Or have you spotted what could literally be the fatal flaw already? Correct – reviewing all that historic data the next day or even the following week could show you that you delivered the – say – thawed and refrozen load, or damaged pharmaceuticals or whatever, at precisely 10:15 yesterday morning that went on to poison the end customer that night.

The point here is that historic data is important for proofs, audits, and compliance problems. But monitoring real-time problems is a different animal. And a widely available, inexpensive mobile phone network has made real-time monitoring possible, giving immediate alarms during transit whenever a set parameter is exceeded.

Aha, you say, but I’ve heard they’re expensive to run. The answer to that is ‘only when you set them up incorrectly!’ Let me explain. A GPRS device (such as our own iSense) uses a SIM card – so there’s a small charge by the network each time you connect.

And with the greatest respect, a lot of people who previously collected data once a day become so excited by the new possibilities that they set the device to collect data every 30 seconds! I’m not talking alarms here – you get those instantly since they over-ride the settings. I’m talking data that essentially says ‘all OK here’.

Do you really need that ‘all OK’ type of data uploaded to your system 170,000 times a day? Will anyone actually be doing anything with it – or even looking at it when it arrives? No – a graph showing that everything’s been fine for the past six months will only be viewed historically.

So don’t go there!  If an iSense is set to log, say, every 15 minutes but only to transmit say every four hours, in the UK, Europe and the US that costs around £45 per year to run. Less than £1 per week! And in that figure I’ve allowed for up to 10 alarm triggers per day.

But make it transmit every 15 minutes and you’ll double the cost for no benefit.

Next time, we’ll look at how to store that data, how to expand that monitoring from farm to fork, and look at meeting global challenges in countries with poor network and intranet systems…

Derek Richardson is International Sales Director for The IMC Group

Total
0
Shares
Leave a Reply

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

Related Posts