Is Satellite the best solution for "Dangerous Cargo"?

A recent History channel show “Modern Marvels: Dangerous Cargo” talked about using satellite technology to track Hazmat cargoes moving around the States. I have both satellite radio in my car and satellite television in my home. While both normally perform fine I find that occasionally, usually in a city or in a heavy foliage area, my satellite radio (in my moving car) will cut out and display “no signal”, and when a storm moves into the line of sight from my home (which doesn’t move) to the satellite signal is lost.

Now consider your fleet management systems for fuel or hazardous materials. Could these signal loss periods lead to “lost” cargoes that need to be tracked? In an August 2004 report, the US DOT stated that:

“Satellite systems, which include GPS, voice and text communications, and other satellite-based functionalities, presently require good satellite coverage and the well known "line-of-sight" condition (i.e., to be effective, they cannot be blocked by thick vegetation, tall buildings, or tunnels). Therefore, vehicles can lose satellite signals in urban areas, underpasses, and, more rarely, areas with a gap in satellite coverage. From a security standpoint, solutions to this inherent problem are challenging since a conservative policy would be to initiate some action whenever there is a loss of signal. An evolving solution is to utilize hybrid systems that automatically switch between satellites and terrestrial systems based on signal strength and availability.”

While the technology is advancing it doesn’t seem ready yet to deliver 100% consistent reliability to tracking of these cargoes.

Ref. http://www.fmcsa.dot.gov/safety-security/hazmat/fot/finalrpt/index.htm

Author: Gerry Kirouac

Summary from SearchEnterpriseLinux.com

We recently had a great discussion with TechTarget on the use of Oracle and Linux for the PowerVue fleet management system. Check out the article:

"Firm picks Oracle 10g on Red Hat Enterprise Linux for the long haul By Jack Loftus, News Writer, 19 Oct, 2007 SearchEnterpriseLinux.com"

When it came time for fleet tracking and management software provider Cadec Global LLC to rebuild its software as a Software as a Service (SaaS) offering, Cadec's chief architect, Heimir Sverrisson, knew it had to be deployed on Linux, not Microsoft Windows or a proprietary Unix flavor like Sun Microsystems' Solaris or IBM's AIX.

Cadec's old system, Mobius TTS, was a client/server application based on Microsoft Windows running SQL Server. From the outset, Windows was eliminated because of scalability concerns; it didn't scale well enough to be used as a mission-critical SaaS platform. "On system administration tasks and operations, it was cumbersome and hard to script, and as a platform, hidden registries were a nasty thing, and you couldn't move components across machines very easily," Sverrisson said.

Click here for full article: http://searchenterpriselinux.techtarget.com/originalContent/0,289142,sid39_gci1277719,00.html

Author: Heimir Sverrisson

DOT compliance, driver productivity and data accuracy

We have been very busy here at Cadec lately working on the first release of our brand new PowerVue platform. Of course we build on the thirty years experience of mobile computing and many generations of DOT-compliant software within the company. The top priority is to capture all the driver activity correctly and make sure the system computes hours-of-service correctly depending on the DOT-rule in effect.

In order to collect the information form the driver most systems rely on manual driver input for things like duty status changes. This is true for the Cadec Mobius TTS system which we are improving on now with PowerVueTM. During the design of PowerVueTM we’ve found several ways to reduce manual input of the driver and improve accuracy at the same time. A good example is how we now handle stops. If a vehicle is in motion (automatically detected from the ECM) the driver has to be in DOT-drive status. When the vehicle stops we now wait a configurable period of time, say 5 minutes, and if we do not get any interaction from the driver during that period of time we prompt him for his activity. This way we remind the driver to register his activity correctly and when he does we can safely change his DOT-drive status from the beginning of the stop to DOT-On-Duty status associated with the particular activity. His DOT-drive hours are thereby minimized, we collect the correct timestamps without relying on the driver to push a button at a certain time and register the correct activity for payroll and/or data-mining.

Now a driver doing a delivery at a customer site can jump right out of the truck when he arrives and begin his delivery. When he comes back the on-board computer waits for him with a prompt for his activity, which he can then register just before leaving for the next stop. If he does not even bother registering the activity he only has to confirm his DOT-location and take off. In this case PowerVue will register his activity as an unknown stop and as we know his precise location we can later change that on-duty activity to a delivery at the customer in question but the drivers hours-of-service are correct and he is completely legal all the time.

Author: Heimir Sverrisson