A case study: How we helped increase Government revenues by 350%, with an Oracle-based monitoring system for penalty checks on over-loaded trucks at Gujarat Interstate Check Posts.

Disclaimer: We don’t mean to point fingers at any particular governance issue, or people involved therein. People staying in any part of India would identify with the bleaching problems that bribery and corruption are. The cargo transport domain of the transport industry is no exception to the thorny hands of corrupt officials and bribe-laden intents. However, with the weaving of technology in the fabric of mundane, transparency and system openness automatically become more prevalent in the existing systems. We are documenting this case (more widely known as CICP), so as to focus on how integrating a monitoring system, helped curb a scalding menace.

Year: 1999

Aim: Building an algorithm for an agile monitoring system which kept close eyes on penalty recovery from overloaded trucks, frequenting interstate highways.

Intended impact:

1. Cut down fraudulent penalty exemption related offenses

2. Increase revenues earned through penalty recovery from overloaded cargo trucks.

Time at hand: 5 months

Number of people on the software team: 4

Scope of involvement: Right from defining the programming architecture, to system implementation & hand-holding at individual interstate check-posts

Impacted target group: Truck drivers, officials at interstate check posts, officials at the Central office of Gujarat Transport department.

A broader challenge:

1. Complementing a complex back-end with a front end, so simple, it could be used by people who had never been exposed to such a system previously.

2. Resistance to change from the existing manual system to the new partially automated system. (Reducing human intervention always brings in transparent discipline into systems, thus erasing weak loops, that can be played around with)

3. Working on a component of a larger solution, keeping in mind, time, scope and technical exposure of other stake holders.

Framework used for back-end — Oracle

Framework used for front-end — Visual Basic

What was the core problem?

Cargo trucks carrying goods from one state to another, are often over-loaded….mostly, way beyond their permissible limits. Combine this with drunken and physically tired truck drivers.

Just about anybody can predict a gruesome accident here.

And that’s why, the penalty system. Overloading penalties at check-posts are intended to discourage carriers from buckling up excess tonnage on to their backs.

That this is also a revenue generation path for the State Government, does not come as news.

So now, the issue — penalties for excess tonnage are generally levied in slabs. (INR x for an excess tonnage for ‘a’ tons to ‘b’ tons). The penalty sum is supposed to be recovered from every vehicle that falls under penalty slabs.

Hey, but who is noting that down? Who is keeping track? Who is documenting all the penalty transactions throughout the day? — The officials at the check-posts!

Are they doing it right? Possibly not.

Are they cheating the system? Possibly yes.

So here is a win-win situation….

The check-post guy gives a little penalty relief to the over-loaded carrier (who is looking anyway? Wink…wink…) He gives a clean chit to the carrier, so according to the system, there was never an over-loaded truck. And because he always takes all this pain for every truck from such cargo transport agencies, the agency owners need to reward him! (good people name it bribe).

So you see, every point in the loop is a happy point….the only problem is, there is no correct documentation that Government officials can rely on, and the penalty amount never reached the revenue department!

Oh yes, and because there is no penalty menace, who cares about a dingy drobbly truck and a drunken driver? Duh!

The Envisioned Solution

Pluck that official’s trading capabilities out! Give the monitoring and documenting responsibility to technology!

Without human intervention, the role of a cheating human mind is swept out.

How was the solution supposed to work?

The solution involved a few tweaks — A weigh-bridge to be stuck beneath the halting space near check-post windows, a surveillance camera, display units (for extra tonnage to shine bright and clear for everyone’s eyes), computer systems equipped to run the software, medium capacity servers installed at individual check-posts, internet connectivity (lease lines were prevalent back then) and a central server to be installed at the central transport office.

Let’s look at the actual 10-step process flow here.

Step 1. A truck halts down on the weighbridge on a 6-lane RTO check post

Step 2. Its weight is taken by the weighbridge and communicated to a set of display system. This set has 2 display boards, one for the RTO inspector to look at, and another for the driver’s information.

Step 3. The driver is asked to furnish documents pertaining to the vehicle and its registered capacity.

Step 4. These details are manually tallied with the existing database, to find out the permitted weight.

Step 5. In case the vehicle’s information is missing from the existing database, it is manually fed for future purposes.

Step 6. The extra weight is calculated and penalty is demanded according to pre-determined slabs.

Step 7. The penalty amount is fed into the system.

All this while, photographs are clicked by a monitoring surveillance camera.

Step 8. All this information waits in a locally installed server, for its turn to be communicated to a central server in RTO office, Ahmedabad.

Step 9. On availability of internet connection (BSNL lease lines were used back then, resulting in dormant delays in data flows from one end to another).

Step 10. On getting internet access, this data was transmitted to a central server. It was then possible to retrieve reports for official scrutiny.

The Detailed Mechanism

2 strings of operations take place simultaneously, once a loaded truck steps up on the weigh bridge.

String 1.

1. It starts with a truck coming and taking its position on the weigh bridge.

2. If the vehicle weighs more than 1000 kgs, the surveillance cameras starts capturing images, all at intervals of 5 secs.

3. Simultaneously, the weigh bridge communicates the accurate weight of the vehicle to the server. Weight readings are taken post 8 seconds of the vehicle’s mounting on the weigh bridge. (Those 8 seconds offer the space for the truck to stabilize on the weigh bridge. This brushes out any sort of interference that could affect the precision of weighing).

4. 7 weight readings of the vehicle are taken, all at a second’s interval. 3 readings showing the maximum value are considered final. The average of these 3 values are worked out and sent to the check-post server.

String 2

1. While all of this is happening, an entry operating officer quickly feeds the system with the vehicle’s registration number. The server checks for the correctness of the registration number, based on the existing database. By norm, the first 3 characters of a vehicle’s registration number are alphabets and the next 4 are numeric. Any change in the string is given back as an error.

2. If the registration number of the vehicle is already present in the existing database, the operator would immediately be able to cross check vehicle and driver details. This would include permit scope, permissible weight, license, expiry details and a few more.

3. If not, the operator would make quick entries of all these value fields and update the database

4. Depending on the permissible weight retrieved from the system, and the reading of the weigh bridge, the extra weight is calculated by the system and displayed on the 2 display boards.

5. One display board is for the driver to look at. When the extra weight splashes bright on the screen, the driver is supposed to pay the due penalty.

The enhancement here:

Paying in cash is time consuming. Time taken in exchanging currency, time spent in looking for change, time spent in conversation…..little additions to time that goes unaccounted for… That’s exactly why a smart thing called a smart card was introduced (it’s sort of cool…smart became smart only in the last decade. Considering that, the concept was ahead of its time). It was a prepaid card, wherein, drivers were supposed to pre-pay a certain amount of money towards future penalties.

Every time a penalty was due, the card needed to be swapped on a swapping device at the check-post operator’s desk. The penalty amount got deducted from the prepaid account, leaving the balance amount to be used for future fine payments.

Recording and wiring all this data to the local server and then to the one at Head Office

A penalty event is saved in an 18 character string long format — HHMMSSDDMMYYYYCPLL

HH — hour

MM — minute

SS — second

DD — date

MM — month

YYYY — year

CP — Check Post ID

LL — lane number

Images associated with each penalized vehicle are saved in HHMMSSFF.img format, where FF stands frame number.

Such strings of data, detailing every vehicular event are first stored up in a check-post’s local server. Later, all of this data is routed to the central server at the head office.

Back then, in 1999, internet connectivity was infrequent, interrupted and sort of, snaily. Leased lines were used in this particular project. Due to the interrupted nature of internet connectivity, instantaneous flow of data from client systems and local servers to the central one was not an obvious scenario.

That’s exactly why, Oracle.

Storing, saving and transporting such a massive amount of transactional data needed robustness and uncompromised security from the back-end framework. Oracle was the best candidate.

How would client systems and Check post servers communicate with the Central server?

Whenever a truck was done paying for its heavy back, the operator would initialize, complete and save the transaction. On saving, the Central Server was intimated about the transaction. All of the data was imported from the client system into the Central server.

If connectivity got interrupted during this process, the data would get stored up in the local server.

That brings us to Job Scheduling. The algorithm stated, local servers would try and communicate with the central server constantly. Whenever an internet connection was available, data would be routed to the Central server. In case of unavailability of connectivity, the pushed out data would come back to the local server, again to be sent to the Central server, when connectivity was next available.

When an officer demanded a printed report at the Head Office

Report generation is an extremely important part of any monitoring system. In this case too, it was possible to get consolidated reports based on diverse parameters. Any person, proficient in creating tables, could feed in the desired parametric values, and generate auto-created reports and tables to be printed out and referred to.

All this was theory…what happened during practical implementation?

That’s what we name — hand holding. Caring as much the connotation of this word is, its is just as practically wicked. Specifically when, you build something which everyone knows about, but no one really understands.

Visual basic was used exactly, for this reason. Interfaces had to be easy for non-technical people to grasp technology in all its accuracy.

The team went an extra mile, visiting each check-post, overlooking proper installation and guiding people there, about how to use it. A simple user manual was definitely, not enough.

Worse, on understanding the specifics of the system, it became clear to many check-post officials, that space for transactional discrepancy was bridged up by this system. Unhappiness was the obvious response. At some check-posts, the reaction went to as extreme as threats of demolishing the newly installed hardware.

But then, we have heard stories about good, triumphing….haven’t we?

Though the system was not implemented in its entirety, (additions like the smart card were lined up for the next phase implementation, which never happened), yet, it stayed in use at Interstate Check Posts for almost a decade.

How did all of this impact the different stake-holders?

Well, didn’t we begin with that? Corruption at check-posts was significantly brought down….and revenue generated from penalty realizations shot up commendable.

But there was another benefit, an unintended one, of course. Because manual intervention was cut out, the time spent in human interactions was eradicated. No one had to jot down vehicle registration number, no one had to write receipts and hend them over, no one had to worry about jotting down information wrongly, no one had to tally specifics at the end of the day….and most importantly, interaction between drivers and check-post officials was reduced. 80% of the interviewed drivers (post-implementation of the system), reported considerable reduction in the halting time at check-posts.

4 Take-away’s

1. No matter how big a project and how little the time, all of it depends on how things are managed.

2. Technology will have glitches, we can’t keep cribbing. It’s about building solutions around the system weakness (job scheduling is what we did around a poor internet connectivity….and it was the first time we did it. It struck just perfect).

3. Every solution has a higher motive. The success of the solution lies in how that motive has been addressed to, not in the sophistication of the solution. (What we created was pretty simple, highly logical and quick. That’s exactly what was needed.

4. Working with teams, that don’t belong to your own team, is a challenge as far as communication is concerned. It was an experience and a learning to work with teams of other vendors of the project.

Found this an interesting read? Recommend the case or share your thoughts below.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.