Electronic Toll Collection System Presentation Transcript:
1.Automated toll
collection system
2.Introduction
Electronic toll collection systems are designed to assist in the management of toll operations through technology that aids in streamlining traffic movement and through collecting data that can be used to make operational changes. These systems gather and analyze data on traffic volumes, vehicle classifications, and the fares expected and collected. The database and report capabilities allow for better management of tolling operations, ensuring maximum revenues.
3.Problem Statement
A software needs to be developed to automate the toll collection on a newly built
highway. The following are the guidelines for developing the software/system :-
Toll charge based on the category of the vehicle.
Boom barrier will open on receiving the money and a receipt will be generated.
Option of smart cards or tags.
Cards to be flashed against the card readers, sensors will read the tag, which the user will stick on the windscreen.
Programming of smart cards and tags.
A tag will be issued against a single car only and will store all details related to it.
Optical character reader (OCR) will read the car's licence plate and cross check the number stored in the tag.
Recharge for smart cards will be available in flexible denominations.
4.Tags will be of two types - flexi and standard. Flexi tag - validity of 6 months or 1 year depending on the amount of recharge.
Standard tag - 50% discount , fixed monthly liability which includes 60 trips valid for one month.
Refundable security deposit of Rs1000 and Rs500 on tag and smart card respectively.
A sensor to monitor time taken by a tag user to cross toll. If time > 5 min, no toll charged.
Live footage of the cars passing through to be recorded and maintained.
Report generation, traffic analysis.
Blacklisting of tags/cards once the balance gets over, giving the user only one extra trip.
5.Development Life Cycle
The Model selection, after much analysis, condensed to the comparison of
two models which best suited our requirements. They were, namely –
Prototype Model and the Rapid Application Development (RAD).
6.After further analysis between these two development life-cycles, we come to the
conclusion that:
PROTOTYPING MODEL IS MORE SUITABLE FOR US
mainly because of the following reasons :-
The requirements of our system can change from time to time, depending on user feedback, so as to provide better management of the toll plaza. This is an inherent feature of the prototyping model.
Unavailability of highly skilled developers and less experience on similar projects.
Project schedule is tight and an effective system is necessary.
A complex system needs to be built where the stress is on efficiency as the funding is stable.
7.Use Case Examples
Name:
Login
Actors:
Administrator, Off-Road Coordinator, On-Road Coordinator, Security Head
Description:
The login deals with the admission of different type of users into the system depending upon the type
of role they play in the working of the system. The login is user specific, i.e., each user has a
different ID assigned to him/her and has a password requirement on each login. These IDs distinguish
between:
Administrator
Off-Road Coordinator (OffRC)
On-Road Coordinator (OnRC)
Security In charge
As per the role, the different user will have access to the different modules of
the software
Preconditions:
The necessary preconditions are:
The user should be an employee in the Toll Management Office, as the logins are given to each and
every employee. The Login should have the password which is to be defined by the user at the time of
creation of the account.
8.Post-Conditions:
The Users should have access to the various modules of the software depending upon the role that
has been entered by them. The rights for accessing anything outside the prescribed modules will not
be allowed .
Basic Flow of Events
This use case starts when the actor wishes to login to the toll management system.
1.The system requests the actor to enter his/her username, password and select a role.
2.The login ID and password is to be entered into the system and a role selected by the actor.
3.The system validates the entered username and password and gives access to the modules
accordingly.
Alternate Flow of events
If the login ID and password don’t match the Role or either of them in invalid, the user will not be
given any access to the software and an error will be displayed. The actor can then choose to either
return to the beginning of the basic flow or cancel the login.
Related Use Cases:
1. Smartcards and Tags
2. Basic Operations
3. Report Generation
4. Surveillance
5. Update
6. Networking
Name:
Report Generation
Actors:
Administrator
Description:
The module deals with the generation of daily/monthly reports. The reports that will
be generated will give a brief and concise account of all the toll earnings throughout
the day/month, whether cash payment or tag/card transfers. It also deals with
keeping an account of the traffic that passes through , counting the peak and off-
peak hours of the day. It also enables a better understanding of the lane usage
pattern, providing us the ability to manage these lanes and deciding how many lanes
should be functional at a particular time. The reports can be generated for both
online and offline usage.
7.Pre-Conditions:
There should be a certain time period for which the reports need to be generated,
whether a day or a month. The type reports generated must have the specific data.
Post-Conditions:
If the use case was successful, a printed copy or a soft copy will be generated
showing the requested parameters.
Basic Flow of Events:
1.The system requests the user to enter a particular time frame(week/month) and
the required parameters to be reflected in the report.
2.The user provides a time frame and selects different check boxes for different
parameters to be included in the report.
3.The system generates the desired report either as a printout or as a text file.
Related Use Cases:
Login
Smart Cards
Basic Operations
8.Use Case Diagram
9.Context Diagram
10.Entity Relationship Diagram
Source: Power Point Presentations
1.Automated toll
collection system
2.Introduction
Electronic toll collection systems are designed to assist in the management of toll operations through technology that aids in streamlining traffic movement and through collecting data that can be used to make operational changes. These systems gather and analyze data on traffic volumes, vehicle classifications, and the fares expected and collected. The database and report capabilities allow for better management of tolling operations, ensuring maximum revenues.
3.Problem Statement
A software needs to be developed to automate the toll collection on a newly built
highway. The following are the guidelines for developing the software/system :-
Toll charge based on the category of the vehicle.
Boom barrier will open on receiving the money and a receipt will be generated.
Option of smart cards or tags.
Cards to be flashed against the card readers, sensors will read the tag, which the user will stick on the windscreen.
Programming of smart cards and tags.
A tag will be issued against a single car only and will store all details related to it.
Optical character reader (OCR) will read the car's licence plate and cross check the number stored in the tag.
Recharge for smart cards will be available in flexible denominations.
4.Tags will be of two types - flexi and standard. Flexi tag - validity of 6 months or 1 year depending on the amount of recharge.
Standard tag - 50% discount , fixed monthly liability which includes 60 trips valid for one month.
Refundable security deposit of Rs1000 and Rs500 on tag and smart card respectively.
A sensor to monitor time taken by a tag user to cross toll. If time > 5 min, no toll charged.
Live footage of the cars passing through to be recorded and maintained.
Report generation, traffic analysis.
Blacklisting of tags/cards once the balance gets over, giving the user only one extra trip.
5.Development Life Cycle
The Model selection, after much analysis, condensed to the comparison of
two models which best suited our requirements. They were, namely –
Prototype Model and the Rapid Application Development (RAD).
6.After further analysis between these two development life-cycles, we come to the
conclusion that:
PROTOTYPING MODEL IS MORE SUITABLE FOR US
mainly because of the following reasons :-
The requirements of our system can change from time to time, depending on user feedback, so as to provide better management of the toll plaza. This is an inherent feature of the prototyping model.
Unavailability of highly skilled developers and less experience on similar projects.
Project schedule is tight and an effective system is necessary.
A complex system needs to be built where the stress is on efficiency as the funding is stable.
7.Use Case Examples
Name:
Login
Actors:
Administrator, Off-Road Coordinator, On-Road Coordinator, Security Head
Description:
The login deals with the admission of different type of users into the system depending upon the type
of role they play in the working of the system. The login is user specific, i.e., each user has a
different ID assigned to him/her and has a password requirement on each login. These IDs distinguish
between:
Administrator
Off-Road Coordinator (OffRC)
On-Road Coordinator (OnRC)
Security In charge
As per the role, the different user will have access to the different modules of
the software
Preconditions:
The necessary preconditions are:
The user should be an employee in the Toll Management Office, as the logins are given to each and
every employee. The Login should have the password which is to be defined by the user at the time of
creation of the account.
8.Post-Conditions:
The Users should have access to the various modules of the software depending upon the role that
has been entered by them. The rights for accessing anything outside the prescribed modules will not
be allowed .
Basic Flow of Events
This use case starts when the actor wishes to login to the toll management system.
1.The system requests the actor to enter his/her username, password and select a role.
2.The login ID and password is to be entered into the system and a role selected by the actor.
3.The system validates the entered username and password and gives access to the modules
accordingly.
Alternate Flow of events
If the login ID and password don’t match the Role or either of them in invalid, the user will not be
given any access to the software and an error will be displayed. The actor can then choose to either
return to the beginning of the basic flow or cancel the login.
Related Use Cases:
1. Smartcards and Tags
2. Basic Operations
3. Report Generation
4. Surveillance
5. Update
6. Networking
Name:
Report Generation
Actors:
Administrator
Description:
The module deals with the generation of daily/monthly reports. The reports that will
be generated will give a brief and concise account of all the toll earnings throughout
the day/month, whether cash payment or tag/card transfers. It also deals with
keeping an account of the traffic that passes through , counting the peak and off-
peak hours of the day. It also enables a better understanding of the lane usage
pattern, providing us the ability to manage these lanes and deciding how many lanes
should be functional at a particular time. The reports can be generated for both
online and offline usage.
7.Pre-Conditions:
There should be a certain time period for which the reports need to be generated,
whether a day or a month. The type reports generated must have the specific data.
Post-Conditions:
If the use case was successful, a printed copy or a soft copy will be generated
showing the requested parameters.
Basic Flow of Events:
1.The system requests the user to enter a particular time frame(week/month) and
the required parameters to be reflected in the report.
2.The user provides a time frame and selects different check boxes for different
parameters to be included in the report.
3.The system generates the desired report either as a printout or as a text file.
Related Use Cases:
Login
Smart Cards
Basic Operations
8.Use Case Diagram
9.Context Diagram
10.Entity Relationship Diagram
Source: Power Point Presentations
Posts
0 comments