Multilane Free-Flow Tolling Systems - additional information

Additional material for Multilane Free-Flow Tolling Systems

In the book I use the concept of "data items". I'm making the basic assumption that, although tolling systems from different manufacturers work in different ways, at a high level these systems do share common data items. When I talk about a data item, I'm thinking in terms of the classic Java Data Access Object. In the book I've described 19 basic data items, although there will be a lot more in a complete system. What I wasn't really able to do in the book was demonstrate how I think these items mesh together - that really needs a number of diagrams, which is what you get below.

Index

Tag and Vehicle Passages, Transactions
Tags, Vehicles and Licence Plates
Transactions, Trips and Arrangements to Pay
People, Partners and Accounts
Interoperability Invoice
Trips can be tricky

Tag and Vehicle Passages, Transactions

7 March 2018

Data items in themselves are only half the story - the clever parts are the tolling system processes that use the data they contain to construct trips and ultimately financial entities for which we can charge customers. So bear that in mind when we look at the first of these "data item relationship diagrams" - this one bringing together the Tag and Vehicle Passage, the Image Package and the Transaction.

In theory, every time a vehicle passes under a tolling gantry we should get a Vehicle Passage and an associated Image Package - assuming that the roadside equipment is set up to take pictures of every vehicle regardless of the presence of a tag. So the link between the Vehicle Passage and the Image Package should be straightforward.

If a vehicle is carrying a tag, then again the roadside equipment should be able to create and link a Tag Passage to a Vehicle Passage, and for the majority of the time that will be the case. However, if the vehicle is not carrying a tag, then there should be no Tag Passage - just the Vehicle Passage to record the vehicle's movement. A vehicle may be carrying more than one tag - and this is where that "Link List" comes into play. Two or more Tag Passages may be associated with a Vehicle Passage. Another scenario is where we receive the Tag Passage, but the roadside equipment cannot associate that to a Vehicle Passage - an "isolated" Tag Passage.

The clever process within the tolling system has to take the available information and construct the Transaction. The Transaction will be formed with differing amounts of data depending on the presence or otherwise of Tag and Vehicle Passages:

In the "nominal" case the Transaction will be formed from a Vehicle Passage and its associated Tag Passage.
Where there is more than one Tag Passage associated with a Vehicle Passage, the tolling system will have to have business rules to decide which Tag Passage is the best "fit".
Where there is an isolated Tag Passage, the Transaction will have to be created using that data alone.

In the middle of all this is the complex business of image processing. The data in the Image Package enables the tolling system to identify relevant images and so push them through image reading processes to determine licence plate strings and state or country of registration.

Tags, Vehicles and Licence Plates

14 March 2018

One of the most important things your tolling system has to do is correctly identify the vehicles using your road, bridge or tunnel. It goes without saying that unless you get this bit right, accurately charging customers will be very problematic. In my tolling system architecture there are four data items that enable us to this:

DI04 Vehicle Type,
DI05 Licence Plate,
DI06 Vehicle, and
DI07 Tag.

In the book I lay out the case for treating licence plates separately from vehicles. For all practical purposes the licence plate (and state or country of registration) is the key piece of data we use to identify a vehicle, but in my purist object-orientated way of thinking they are separate things. Licence plates do get legitimately moved between vehicles, and stolen, so I think it works to treat them as discrete items.

Vehicles are of a unique Vehicle Type. It's that Vehicle Type that can be used to define the class of the Vehicle for tolling purposes. But a Vehicle may be modified in such a way as to change its class. Thus in most cases the class for a Vehicle is simply inherited from its Vehicle Type, except where that modification - recorded by the tolling system - has altered the "default" class.

When we create our Transaction, the processes within the tolling system can start to search our Tags, Vehicles and Licence Plates to find items that match the data in the Transaction, and then populate the key IDs that nail down unique Vehicles and Tags. I've made the design decision in this case that those IDs - assigned by the tolling system - will be the key identifiers. This is important because it is those same IDs that then go on to link Tags and Vehicles to Accounts - a crucial relationship for subsequent charging.

Transactions, Trips and Arrangements to Pay

24 March 2018

The relationship between Transactions, Trips and Arrangements to Pay looks complicated enough based on the diagram above. But that diagram isn't showing the plethora of complex processes that have to be working in the background to ensure the correct links are made between data items. This is the byzantine realm of trip reconstruction and rating; something that is relatively straightforward for the vast majority of "nominal" trip scenarios but which can get weird very quickly when faced with the idiosyncrasies of human behaviour and real world physics.

In Part 2 of the book, the section "Trip reconstruction and Rating", I talk at some length about the complexities in these processes. To create trips we need a set of business rules and then realise those business rules in the code of the trip reconstruction and rating engine. There is nothing magical about those rules - they can be simple things like:

Trips can only be formed from Transactions with the same Tag ID and/or Vehicle ID - (obviously!),
A Trip can only be formed from Transactions that follow the toll point topology of the road i.e. each Transaction is "further down the road" than the previous one, and
Those Transactions that are "further down the road" must also be later in time - but within an acceptable time limit.

With those simple rules you begin to form a reconstruction engine framework. But then come the "curved ball" scenarios:

Gantries off line and sending Transactions many hours after they were created,
Transactions disappearing into Image Processing and being stuck there for a weekend, and
Customers creating exotic trip looping manoeuvres.

So there is always a need to thoughtfully re-reconstruct trips, and it can be a tricky business.

Likewise with trip rating. A "formed" trip has a start and an end point, a date and time, and an associated vehicle class - everything we need to apply the correct toll charge. Except that every time we re-reconstruct - because of the late arrival of a transaction - we have to adjust the value of our trips. If formed trips have already been sent through and applied to Accounts, then those accounts need to be adjusted - to say nothing of the company's General Ledger.

If you have a reasonably complex road with several toll points and entry and exit ramps, you can quickly generate many tens, even hundreds, of test scenarios for your reconstruction engine. The simple truth is that you just have to try them out - there is no shortcut, as far as I know, to verifying the accuracy of your system. Even then, when you plug the thing into the real roadside equipment and let customers lose you will find Trip combinations you thought weren't possible. It is an entertaining challenge.

People, Partners and Accounts

31 March 2018

At the heart of my tolling system architecture sits the Tolling Account data item, DI16. This structure pulls together all the other data items and lets us form that coherent and hopefully unambiguous link between Tags, Vehicles, the Trips they make and the Person(s) who ultimately pays the bills.

Depending on your particular implementation, the Tolling Account has to be a flexible beast. You may charge it to deal with:

Regular tolling accounts - with good data on your customer, the account holder,
Minimalist or casual tolling accounts which may be little more than a credit card number and a licence plate string,
Interoperable Partner accounts and act as means of resolving interoperable Trips, and
Trip passes or vouchers for casual users of your road.

So the amount and type of data carried by any single instance of a Tolling Account data item may vary quite considerably. The figure above concentrates on two important aspects of accounts, namely who owns and operates them, and their relationship with Arrangements To Pay data items.

In my architecture I've made the decision that there are three distinct types of account owner:

Interoperable Partners,
Businesses, and
A Person.

Interoperable Partners, certainly in Australia, are different from the other two because of the way interoperability agreements are set-up and managed - and by that I mean primarily the way Interoperable Partners pay each other for the travel of their customers on other partners' roads. That sorting of trips and the payments that follow are somewhat outside the "normal" account operations for regular customers.

A regular Tolling Account has a Person who is the account owner and takes responsibility for the financial liability of the account. That Person may nominate one or more Authorised Agents - people who can perform operations on the account. A Business may be an account owner, but a Business must have at least one Person as an Authorised Agent. That makes sense because without real people businesses are "nothing". You have to have a Person to represent the Business and that Person will want to log in to the website - you want to keep track of what they, specifically, are doing so you need to identify the individual through a login ID and PIN. Each Person has a unique login ID and PIN - not the Business.

On the other side is the Arrangement To Pay (ATP). An ATP is linked to a specific Tag or Vehicle. In turn it is linked to the Tolling Account. In this way Trips made by Tags or Vehicles end up on the correct Tolling Account. But the Tolling Account is also constantly working out its status. As Trips are applied to the account so the account balance is updated. Following your business rules, as the account balance changes, so might the account status. That status is used by the ATP data items to drive the Trip Rating engine and ensures that the appropriate Toll Product is used for each Trip at any given time - in the vast majority of cases this only becomes an issue when an account becomes suspended and the "No Arrangement To Pay" rules have to be applied.

There is a whole lot more going on with Tolling Accounts - like the association of Trips to Accounts, like the notifications for account top-ups (more money please) and Statements and Invoices.

Interoperability Invoice

8 April 2018

In the book I spend a whole chapter (at least) talking about Interoperability because it is both very important and quite complicated. It is important because it simplifies life for our toll road customers. Having one tolling account and then being able to use all the roads in an interoperability group is straight forward compared to the challenge of managing multiple accounts and numerous on-board devices. It gets complicated for toll road operators because they have to:

Agree on and follow technical standards for roadside equipment and tags,
Jointly develop and follow business rules for sharing customer arrangement to pay (ATP) data and Trip data,
Have policies and procedures for dealing with Trip and ATP disputes both between themselves and their customers, and with Interoperability Partners, and
Ensure that they pay, and are being paid by those Interoperability Partners.

Much to its credit, Australia has been running a very successful toll road interoperability scheme for many years which for DSRC tags at least, covers every toll road in the country. ATP and Trip data is exchanged between Interoperability Partners every day following a schedule, in large batch files. Files are processed and checked, and a small number of disputed trips are created every day - but the numbers, in the overall scheme of things, are very small. The next day the Interoperability Partners complete a financial settlement for those trips from the previous day. See the diagram above.

In my last article I spoke to the relationships between Interoperability Partners, People, Businesses and Accounts - and this is again reflected in the diagram above for the Interoperability Partner. The Tag ATP and Licence Plate ATP data items link Vehicles and Tags to Accounts and thus form the bridge between the Trips made by those Vehicles and the Account.

An Interoperability Invoice has to be time bound i.e. it has to cover a period of time with unambiguous start and end points. All Trips made within that time period are included in the invoice. If you don't have an existing interoperability system, this is where you have to start making some design decisions along these lines:

We have to exchange Trip and ATP data - but what do we actually need to tell each other?
How are we going to do this - the big Australian style batch files once a day, or should we establish real-time B2B comms and exchange ATP data as it changes, and Trip data as they are completed?
Is the Interoperability Invoice the carrier of Trip data or is it just a summary?
Do we all talk directly to each other or do we establish some kind of central clearing house?
If we have a clearing house, who owns it, how much does the service cost, are there to be SLAs and what financial and legal responsibilities does it carry?

In the diagram above I am assuming that the exchange of ATP and Trip data is by a separate mechanism and the Interoperability Invoice is a data summary, a financial instrument for the Accountants.

This invoice concept is equally applicable for the normal post-paid tolling account invoice and the pre-paid tolling account statement. Obviously the big difference between those two is when you collect the money. In theory, Trips on a Statement have been paid by virtue of the pre-paid account mechanism. The Statement is simply a record of activity. Trips on an Invoice are yet to be paid and carry a "due by" date. Behind the scenes the tolling system has to keep track as to whether any given trip has been paid for - or not.

Trips can be tricky

10 May 2018

Within the context of a tolling system, Trips can be very tricky.

In the book I talk at some length about the complications of Trip Reconstruction. Thankfully most of the time it is quite straightforward. Once a Trip is formed and rated, the simplest scenario is that the Trip is associated to an Account through its Arrangement To Pay and ends up on one particular Statement. Assuming it's a pre-paid Account with an automatic top-up arrangement, the Trip can be marked as paid, money deducted from the account, and the necessary financial movements recorded in the Chart of Accounts - simple, brilliant!

Unfortunately most of the effort that goes into building the logic of a tolling system is aimed at dealing with every other type of scenario. The figure above highlights some of these other scenarios.

Suspended Account: our customer has a tolling account with us, but it is currently in a suspended state. Our business rules mean that we have to issue them with a No Arrangement To Pay (NATP) Invoice. But we want to keep all the detail associated with this customer in one place so that we can better manage them. A Trip therefore has to be identified with the customer's Account, but the Arrangement To Pay is telling us that the Trip also has to become part of an NATP Invoice - not just end up on a regular Statement. The NATP Invoice also has to be associated with the customer's Account. Then the system needs to manage how that trip is paid for. With any luck the customer tops up their account with enough money to get it un-suspended and clear all their NATP Invoices - and the system is smart enough to make that connection. Conversely they may just pay an NATP Invoice.

No Arrangement To Pay: we get a Trip for which there simply is no Arrangement To Pay. The system has to create an NATP Invoice for the Trip. Once we get the details of the Person who made the Trip it makes sense that the system can check to see if have a previous record of that person - it may have already created an (NATP) Account for them. If the system is smart, and you can contact the Person in question, that Account can be turned into a regular tolling Account.

Nominations: can be quite disruptive. If a Trip is on a regular Statement or an NATP Invoice, and the customer doesn't believe they are responsible for it, the Nomination can mean the system has to ripple through all the existing links between data items and form new links - to a new Account for example.

Then just when the system has got all that functionality sorted out, Trip Reconstruction comes back into play and reforms and re-rates the Trip. Everything associated with that original Trip now has to be examined to determine what is to be done with this new version of the Trip - adjusting Account balances, adding adjustments to Statements and Invoices, perhaps even reissuing an NATP Invoice. What the system actually does will depend on how you specify your own business rules.

Finally, lying beneath all this activity are the mechanisms that tie these movements into the company's Chart of Accounts within the corporate financial system. Typically whenever you find yourself moving or adjusting Trips, you have to have a similar action going on in the background to keep your Chart of Accounts aligned.

Special thanks to Luperi for the wheel zoom javascript.