IT706A HT15 - Assignment

Group 7
Petersson, Andreas
Mohamed, Hilal S.
Nawaz, Amir

Table of Contents
Table of Contents
1. Roles and contributions
1.1 Andreas
1.2 Hilal
1.3 Amir
2. Specification of the application scenario (Hilal S. Mohamed)
3. System specification
3.1. Functional and non-functional aspects of the application system (Andreas)
3.1.1. Receiver box
3.1.1.1 Functional aspects
3.1.1.2 Non-functional aspects
3.1.2. Checkpoint system
3.1.2.1 Functional aspects
3.1.2.2. Non-functional aspects
3.2. Diagrams (Andreas)

4. Theory and application

4.1 Andreas
4.1.1 Complexity theory (Andreas)
4.2 Hilal
4.3 Amir
References

1. Roles and contributions

Listed below are the various roles of the group members and what they contributed to this
assignment.

1.1 Andreas

1. Roles and contributions

3.1 Definitions of the functional and non-functional characteristics of the information
system
4.1 Complexity theory
3.2 System architecture diagrams

1.2 Hilal

2. Specification of the application scenario

1.3 Amir

2. Specification of the application scenario (Hilal S.

Mohamed)
Road toll collection is one of the activities that ensure the sustainability of the surface
transportation infrastructures of many countries. Collections from tolls augments the
budgetary allocations for financing the construction of new infrastructure as well as the
maintenance of the existing ones.
Apart from infrastructure sustainability, road tolls are also used as a means of reducing
congestion and the overall improvement of traffic flow in the road networks. Naturally road
segments where tolls are levied are normally avoided in preference of alternative routes and
thus improving traffic flow in these segments. As a result an efficient and reliable road toll
collection system is an important and a primary requirement of the so called Intelligent
Transport Systems (ITS), a strategy adopted by many countries as a way of achieving a
sustainable and efficient transportation network or infrastructure.
However these toll collection systems can also be bottlenecks in the road networks
especially when the toll is manually collected and cars are required to stop at the toll
collection plazas. This can result in congestion in the road segment passing through the toll
collection plaza that can also propagate to other segments in the road network. This can

result in undesirable consequences as wastage of time, reduced fuel economy or even an

increase in air pollution at the toll collection site.
Automated Road Toll Billing System is proposed as a solution or a replacement of the
manual road toll collection system. The proposed system will not require cars to stop at the
toll collection plazas for making the payments but rather the payments will be automatically
deducted from a prepaid account associated with an individual car passing through the toll
plaza. This will greatly help in addressing the problems of the manual toll collection system
identified above i.e. wastage of time, reduced fuel economy and an increase in air pollution
at the toll collection site.
The main features of the proposed Automated Road Toll Billing System include the following:
Automatic Car/Vehicle Identification - essential for correct road toll billing transactions
Automatic Car Classification - essential for determining the amount of toll to be
deducted, for instance for buses (passenger vehicles), trucks, taxi cabs etc as
different classes of vehicles will be levied a different toll amount.
Communications Subsystem - essential for enabling communications between the
roadside toll collection system and vehicles passing through the plaza for
identification,classification and billing transactions to be conducted.
Billing Subsystem - essential for carrying out and recording the billing transactions.
Given this background, the proposed Automated Road Toll Billing System is supposed to
perform its transactions in real time as they happen. This requirement impose some
technical difficulties which need to be overcome for the system to be useful for its intended
purpose.

Some of these difficulties are highlighted below:

1. Requirement for the system to correctly detect, identify and classify all vehicles
passing through the toll collection site within a very short time period (milliseconds)
as vehicles are not required to stop at the toll collection plaza
2. Within this short period of time the system should perform the billing transaction
successfully
3. The system should identify and record all vehicles that have successfully performed
the transaction and update their account balances accordingly
4. The system should also identify and record all vehicles that have not performed a
successful transaction say due to insufficient balance in their pre-paid account or due
to communication problems and initiate a follow-up procedure
5. The system should record all vehicles not correctly identified due to lack of matching
details in the system database and initiate a follow-up procedure
6. For the case of a multi-lane toll plaza, the system should communicate with all
vehicles within the communication zone and maintain secure communication with
each vehicle for the period of time necessary for the billing transaction to be
completed for each individual vehicle

3. System specification

3.1. Functional and non-functional aspects of the application

system (Andreas)
One solution to identifying vehicles that pass through the toll collection sites is using a small
box that the customer has in their car that identifies them. This approach is in use by the
resund Bridge.
There are two subsystems of this automated road toll system. The receiver box, which is a
small integrated unit that sits in the vehicle, and the checkpoints which handle
communication with the box and the billing system to bill the customers.

3.1.1. Receiver box

The receiver box needs a number of features to be usable for automatically billing the
customer for using roads that have tolls on them.

3.1.1.1 Functional aspects

The box needs to transmit some form of identification that can be used to find the customer
in the billing system and correctly identify the vehicle type associated with the box. It should
only transmit this data when asked to do so by a checkpoint.
The box should be able to tell the customer how much toll that has been accumulated given
the number of checkpoints theyve passed the current driving session. A driving session
being defined as being between when they get on the highway and when they leave the
highway or a similar stretch of road where the customer has to go through one of the
checkpoints to leave the tolled road.

3.1.1.2 Non-functional aspects

The information transferred between the receiver box and the checkpoint billing system
should be transferred in a secure manner. For example using encrypted communication.
The handshake between the receiver box and the billing checkpoint needs to be very quick
to allow the customer to travel through the checkpoint as fast as possible.
The receiver box should be simple to use, e.g. checking how much has been billed this
session or month should be a simple task.

3.1.2. Checkpoint system

The checkpoint needs a number of features to be useful for the company.

3.1.2.1 Functional aspects

The checkpoint system should communicate with the receiver box wirelessly to enable the
customer to travel through the checkpoint at a reasonable speed (preferably legal limit) while
travelling down the road.
When the system has received the identification information it should subtract the cost for
using the toll from the customers balance. If identification fails some other kind of
identification (e.g., license plate) should be stored to perform follow up procedures. Similarly,
if the transaction fails due to the customer having insufficient balance in their account
information should be stored to allow follow up.
The checkpoint should update some information available on the receiver box that would be
of use for the customer. For example, current cost for the road they have travelled on and if

this is a start station (e.g., a checkpoint leading up to a highway) or an end station (a

checkpoint on an exit road).
The checkpoints should be able to communicate with several boxes at once to facilitate
multi-lane checkpoint plazas.
The checkpoint should request the information from a box when it detects that a car has
entered the checkpoint zone.

3.1.2.2. Non-functional aspects

The system running on the checkpoints should be able to communicate with the system that
the company uses for billing their customers.
The billing system should perform well enough to handle a reasonable amount of cars
travelling through the checkpoint.

3.2. Diagrams (Andreas)

Figure 1. Diagram of the flow of information and the various states of the checkpoint
Until a car arrives at the checkpoint (which could be detected by pressure plates or cameras)
the system idles at the starting node (the circle). When a car arrives at the checkpoint it
requests the customer data from the receiver that should be located in the customers car
(see Figure 2 for how that works).
If requesting the customer data succeeds then the system attempts to withdraw from the
customers balance. On success it returns the transaction details to the customers receiver
box. If the attempt fails then the system takes a picture of the cars license plate with a
camera and requests a follow-up procedure (most likely to be handled by a human).
If requesting the customer data fails the system requests a picture of the cars license plate
to request follow-up (send an invoice to the owner of the car or similar).
When either of these paths finish the system returns to waiting for cars to arrive.

Figure 2. Diagram of the flow of information in and out of the receiver box.
When the receiver box gets a request for the customer data it responds with the customer
data stored on the device (a customer ID and vehicle classification) and starts waiting for the

checkpoint to confirm the success of the transaction. If the transaction was successful the
box updates its local data (monthly use/session use) and returns to waiting for requests. If
the transaction times out the box notifies the user that something went wrong (this means
they can stop nearby and get support) and then goes back to waiting for requests.

4. Theory and application

This section deals with the various methodologies, theories and techniques from the course
that are useful or relevant to the application scenario.

4.1 Andreas
4.1.1 Complexity theory (Andreas)
One of the requirements of the system is to perform well enough that vehicles can travel
through the checkpoints and still be properly processed by the billing system. This means
that effective algorithms have to be picked for the actions the system is required to do.
Picking the wrong algorithm (e.g., a slow queuing algorithm) could have a negative impact on
the number of cars the system can handle per second and how fast they can travel through
the checkpoints.
This theory is mostly useful in the system design phase of the development cycle. In this part
of the system development life cycle the algorithm to use for a certain feature can be decided
upon by viewing the alternatives and comparing them.
In the case of the automated road toll system the most interesting aspect of complexity
theory is the worst-case analysis which, according to Sipser (2013), is the longest running
time for all an input of a particular length. This is useful in designing the road tolling system
because the performance of the system (both the checkpoint system and the boxes) directly
translates to the speed at which the customers can travel through the checkpoint.
Weiss (2014) lists a few complexity classes that are common in algorithms:
Complexity

Name/Explanation

O(1)

Constant

O(log n)

Logarithmic

O(log n)

Log-squared

O(n)

Linear

O(n log n)
O(n )

Quadratic

O(n )

Cubic

O(2 )

Exponential

Table 1. A number of the classes of order of complexity from Weiss (2014).

These complexity classes are written in whats known as Big-O-notation, which defines the
upper bound of a function that defines the growth of the time or space complexity (Sipser,
2013).
When selecting an algorithm for the various tasks in the checkpoint system and the receiver
box the goal should be to find a balance between time complexity (the time it takes to
compute) and space complexity (the amount of memory it takes up). For example, the
receiver box will most likely be a very small box that can be put in the front of the vehicle.
This means that the box will not have very much computational power or very much memory.
Depending on the restrictions on production cost for these boxes the algorithms associated
with its operations will either favor time or space complexity.

4.2 Hilal
4.3 Amir

References
Sipser, M., 2013. Introduction to the theory of computation. Thomson Course Technology, Boston
Mass.
Weiss, M.A., 2014. Data structures and algorithm analysis in C++. Pearson, Harlow.