Saturday, July 27, 2013

2.IntroductionElectronic 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 StatementA software needs to be developed to automate the toll collection on a newly builthighway. 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.

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 CycleThe Model selection, after much analysis, condensed to the comparison oftwo 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 ExamplesName: LoginActors:Administrator, Off-Road Coordinator, On-Road Coordinator, Security HeadDescription: 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:AdministratorOff-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 softwarePreconditions: 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 eventsIf 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. NetworkingName: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.